Debian GNU/Linux 8 (Jessie) est sortie le 25 avril 2015 et plusieurs mises à jour ont ensuite été publiées. La dernière en date constituant Debian GNU/Linux 8.5 vient d'être annoncée samedi 4 juin (de nouvelles images d'installation sont disponibles).
À noter aussi la sortie de Debian GNU/Linux 7.11 Wheezy, qui sera la dernière des versions numérotées 7.x (le support longue durée se poursuit jusqu'en mai 2018 pour les architectures i386, amd64, armel et armhf ; le support normal s'est arrêté le 25 avril 2016).
En outre, une nouvelle édition du livre « Le cahier de l'administrateur Debian » vient d'être publiée par Eyrolles. Le contenu est libre et librement accessible sur le site idoine. Avec ses 538 pages, l'ouvrage pèse maintenant plus d'un kilogramme et sa nouvelle couverture, aussi énigmatique qu’hypnotisante, vous assurera l'admiration de vos collègues si vous l'exposez dans un coin de votre bureau.
Quant à ceux qui seraient à la recherche d'un DVD de Debian, ils peuvent farfouiller dans le rayon informatique de leur marchand de journaux, avec un peu de chance ils trouveront Linux Identity Set n°38 qui en contient un, accompagné de 42 pages.
Aller plus loin
- Publication de la mise à jour de Debian 8.5 (602 clics)
- Debian 8 Jessie (Eyrolles) (1060 clics)
- Le cahier de l'administrateur Debian (site du livre) (1872 clics)
- Linux Identity Set (300 clics)
- Debian 8 : Jessie l’écuyère est en selle ! (252 clics)
- Publication de la mise à jour de Debian 7.11 Wheezy (122 clics)
- Support LTS Wheezy (170 clics)
# Support pour Wheezy
Posté par Carl Chenet (site web personnel) . Évalué à 10. Dernière modification le 08 juin 2016 à 10:38.
Une petite précision, le support normal de Wheezy, en accord avec la politique de maintenance des versions stables de Debian, s'est arrêté le 25 avril 2016.
La responsabilité du support a alors été transférée à l'équipe de Support Long Terme qui est une initiative récente et qui nécessite des fonds pour rémunérer les développeurs chargés du travail de support des très anciennes versions des logiciels qui constituent Wheezy. Le besoin d'un support long terme est avant tout un besoin des entreprises. Les dons sont donc les bienvenus pour maintenir le support long-terme des anciennes versions stables de Debian.
[^] # Re: Support pour Wheezy
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Précision ajoutée, merci.
[^] # s/Quand/Quant/
Posté par frayd . Évalué à 1.
dans "Quand à ceux qui seraient…"
[^] # Re: s/Quand/Quant/
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
[^] # Re: Support pour Wheezy
Posté par Nicolas Chevallier (site web personnel) . Évalué à 1.
Une très bonne chose ce support long terme (j'ai d'ailleurs participé) car les cycles ne correspondent pas/plus aux cycles de déploiement/maintenance en entreprise.
# Le support armel/armhf est confirmé pour Debian 7 LTS
Posté par Raphaël Hertzog (site web personnel) . Évalué à 8.
cf https://bits.debian.org/2016/06/wheezy-now-supporting-armel-and-armhf.html
[^] # Re: Le support armel/armhf est confirmé pour Debian 7 LTS
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Le passage à systemd a fait énormément de bruit à la sortie de Debian 8. Maintenant qu'on a un peu de recul, c'est l'occasion de jeter un coup d'œil dans le rétroviseur. Au final, sur des environnements stables et suite à ce passage de Debian 8 à systemd :
Ceci ne permet évidement pas de faire un sondage fiable, mais si tout le monde joue le jeu, c'est l'occasion d'avoir une idée à la fois de la fuite provoquée par ce changement ; ainsi que du rapport bruit / actions sur des sujets aussi polémiques.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par tipic . Évalué à 9.
Pour ma part, je suis passé en Debian avec systemd.
Et bien, c'est convainquant et extrêmement rapide!
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par tipic . Évalué à 5.
…et je rajoute, vu que je n'ai pas pu modifier mon précédent post.
Utilisation particulière :
-Installation minimale + Mate
-Noyau lowlatency ou realtime
-Audio numérique (KxStudio)
Après l'init du bios, chargement en 15 secondes avec l'interface graphique (chargement automatique sans mot de passe)
Oui systemd est convainquant.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par barmic . Évalué à 10.
popcon doit pouvoir t'aider pour ça.
Perso j'étais sous Debian, je reste sous Debian parce que je sais me débrouiller avec et je me fous de l'init que j'ai. Je faisais mes skeletons avant je fais mes units maintenant.
Si systemd est discutable, affirmer qu'il est cataclysmique c'est juste rigolo. GnomeShell ou KDE4 ont représenté un changement beaucoup plus violent pour l'utilisateur final que le fait que screen ou tmux fonctionnent pas dans la configuration par défaut de systemd.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par whity . Évalué à 10.
En effet.
Après, la migration n’est pas sans poser quelques problèmes, mais évidemment pas ceux auxquels on s’attendait ou ceux sur lesquels les détracteurs de systemd s’épanchaient, mais plutôt sur quelques détails. En ce qui me concerne :
À côté de ça, j’en ai vu les bénéfices côté utilisateur : le déploiement d’un service est juste plusieurs ordres de grandeur plus simple à configurer avec les fichiers unit de systemd. Rien que pour ça et le temps de boot, ça valait le coup.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par eingousef . Évalué à 2.
Utilisateur fidèle de Debian GNU/Linux testing, je me suis finalement laissé convaincre par les partisans de systemd qui m'ont dit que sysvinit c'était de la merde et que mon desktop devrait booter en moins de 10 secondes pour increaser ma productivity.
Je suis donc passé à openrc, qui m'a permis de booter mon desktop en moins de 10 secondes, et ce sans rien péter ! Merci les partisans de systemd ! \o/
*splash!*
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Moi.
À noter que sur d'autres systèmes, je suis aussi passé à Debian 8 avec systemd sans problèmes particuliers.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par reynum (site web personnel) . Évalué à 9.
Depuis un certain temps le seul problème que j'ai avec systemd c'est de subir les commentaires foireux de ses détracteurs ! :)
kentoc'h mervel eget bezan saotred
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par KiKouN . Évalué à 2.
C'est inacceptable de dire que sysVinit est trop verbeu quand on voit systemd.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Ms-Mac . Évalué à 2.
Passé en Debian avec systemd
Pour l'instant un seul problème et beaucoup de cheveux en moins.
Le fichier /etc/default/bind9 existe toujours mais (surprise) ne sert à rien, il faut modifier
/etc/systemd/system/multi-user.target.wants/bind9.service.
Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par tipic . Évalué à 1.
J'imagine bien que dans certains cas, cela gonfle.
Je me souviens, sous Mandrake, de l'introduction de shorewall. A l'époque cela m'a gonflé.
Bon un petit peu de patience, un petit peu d'études du système proposé…et du coup, oui pas mal.
Parfait, non ! mais bien quand même.
Bon je sais aussi, de manière personnelle, que l'on a pas toujours le temps. Mais bon, à mon avis cela en vaut le coup.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Ms-Mac . Évalué à 1.
Oups!!
C'est en passant bind9 en chroot que le problème intervient.
OPTIONS="-u bind -t /var/lib/named"
Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Sufflope (site web personnel) . Évalué à 6.
J'ai pas de Debian pour vérifier, mais normalement, ce n'est pas ce fichier qu'il faut modifier.
Ce fichier (dans un target dans /etc/systemd) est en fait un lien symbolique vers la config de base qui est dans /usr/lib/systemd (que tu as donc éditée, qui sera potentiellement écrasée lors d'une mise à jour, etc etc) qui dit en gros que cette cible utilise ce service.
Tu devrais soit mettre tes changements dans un fichier /etc/systemd/system/bind9.service (tu auras sûrement à le créer), en ne mettant que les nouvelles valeurs de clés que tu veux changer (pas la peine de tout recopier du service de base), et systemd utilisera la config de base en lui superposant tes modifs.
Tu peux aussi faire un dossier /etc/systemd/system/bind9.service.d/ et y mettre tous les toto.service, tutu.service etc. que tu veux (si tu veux couper tes modifs en plusieurs configs décorrellées) et qui seront de la même façon superposés à la config de base.
C'est fait automatiquement je crois si tu utilises la commande systemctl edit bind9 (de mémoire) mais je ne l'ai pas encore utilisée, je fais mes mkdir et nano à la main.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Misc (site web personnel) . Évalué à 2.
Je suis pas vraiment sur qu'on puisse blâmer la calvitie sur systemd.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Antoine . Évalué à 2.
Et le principe de précaution alors ?
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par gasche . Évalué à 8.
Pour ma part j'étais passé à Fedora au moment d'installer ma dernière machine parce que j'avais envie de tester systemd pour voir comment c'était en pratique. Je trouve que pour l'utilisateur final l'impact principal c'est plutôt de devoir passer par
systemctl(et journald) pour des tâches qui utilisaient d'autres choses avant (/etc/init.d/…), comme relancer un service ou quelque chose comme ça.Je trouve toujours que le modèle et l'histoire de Debian sont des références dans le monde du libre, et je pense que je repasserai à Debian à ma prochaine machine. Je me retrouve mieux dans son mode de développement très communautaire—même si je ne me suis moi-même jamais impliqué dans le packaging ou l'évolution de la distribution.
(Dans une certaine mesure c'est un peu comme Firefox: sur certains points techniques Chromium a l'avantage (en particulier le modèle de sécurité est bien mieux pensé), mais je me retrouve mieux dans les efforts de développement ouverts à la communauté de Mozilla (même s'ils ne s'en sortent pas toujours bien, on a toujours le Pocket un peu en travers de la gorge, etc.), donc à défaut de pouvoir soutenir par une contribution active je l'utilise et j'en parle positive autour de moi.)
Avec la place de plus en plus importante que prennent les gestionnaires de paquets non-distribution (j'utilise
opampour OCaml par exemple), je défère surtout à ma distribution les parties "chiantes" (les trucs que je veux avoir maintenu et sécurisé, mais pour laquelle à part ça je me moque assez de la version disponible etc.) de mon userland, les trucs qui justent marchent et dont je n'ai pas l'intention de suivre l'upstream. Je pense que mes prochaines aventures d'administration système iront dans le sens de Nix (par dessus Fedora ou Debian), et QubesOS, m'éloignant de plus en plus des distributions classiques.[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par ut0mt8 (site web personnel) . Évalué à 7.
Dans un contexte professionnel, le passage de plusieurs centaines de serveurs de wheezy à Jessie s'est globalement plutot bien passé. Nous trouvons (mes collegues et moi) que l'intégration de systemd dans debian est quand meme très largement perfectible. L'utilisation de systemd ne pose pas de soucis particulier, néanmoins nous avons été confronté à quelques bug rigolos (le dernier en date étant celui de systemd-login qui hang après un update). Mais surtout c'est l'adoption des mainteneurs de paquets qui n'est pas encore au niveau. Des paquets aussi exotiques que snmpd, ntp utilisent encore les scripts d'inits… Et quand l'intégration est faite, elle est parfois faite a minima, j'ai l'exemple de redis qui utilise un unitfile, mais qui ignore bien gentiment le /etc/default/redis.
A noter que quelques refractaires ont tenté de resister (installer sysv-core) mais ce n'est pas viable sur le long terme :p
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Ludo . Évalué à 3.
On a aussi eu ce genre de blagues. Comment tu as résolu ce problème (à part restarter à chaque fois le daemon;-) ) ?
Merci.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par rewind (Mastodon) . Évalué à 10.
En tant qu'utilisateur de base de Debian (depuis potato quand même), j'ai laissé faire l'installation de systemd quand ça s'est présenté. Depuis, bah ça marche pas plus mal que si c'était pire, pas moins bien qu'avant, pas mieux non plus. Il y a quelques détails qui me chagrinent un peu.
Au démarrage, on ne voit plus les logs du kernel et les services qui démarrent. Oui, moi j'aimais bien voir tout ça, notamment les services, parce que des fois, j'installais un truc pour tester et du coup, je voyais le service au démarrage et je me souvenais qu'il fallait que je désinstalle le bouzin. Maintenant, je ne vois plus rien. J'ai essayé de modifier l'affichage de systemd mais là, on voyait beaucoup trop de choses et donc, rien de pertinent. Dans le même ordre d'idée, on ne voit plus la barre de progression de fsck, et comme ça prend un peu des plombes parfois et qu'on a aucun retour, c'est très agaçant. Enfin, il y a tous ces petits trucs à la con du genre la commande
haltqui n'arrête plus complètement la machine (il faut utiliserpoweroff), et l'attente d'1m30 quand un service récalcitrant (dont on n'aura pas le nom évidemment) ne s'arrête pas correctement.Bref, je trouve qu'on perd un peu en maîtrise quand on est simple utilisateur observateur de son système comme moi. Il y a beaucoup de choses qui sont cachées. Pour la vitesse, je n'ai pas remarqué que ça allait particulièrement plus vite ou moins vite.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par barmic . Évalué à 2.
Tiens j'ai oublié ça :) J'ai résolu ce problème avant de passer à systemd avec des partoches en btrfs
^^Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Olivier (site web personnel) . Évalué à 5.
C'est lié au paramètre "quiet" qui est passé au kernel.
Tu as 2 solutions:
- tu veux temporairement voir les lignes de services. Lorsque GRUB2 s'affiche, tu edites les paramètres du menu que tu sélectionnes (ctrl+…), et tu supprimes le mot "quiet" de la ligne "linux ….". Cette modification ne sera pris en compte que pour ce boot-là. Au prochain reboot, les lignes seront de nouveau cachées.
- tu veux systématiquement afficher les lignes de services. Edites le /etc/default/grub, et supprimes le paramètre "quiet". Puis, lances un "update-grub2", et rebootes la machine.
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par rewind (Mastodon) . Évalué à 2.
oui, je sais faire, mais le problème, c'est que quand ce n'est pas quiet, c'est beaucoup trop verbose, il n'y a pas de juste milieu…
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par xcomcmdr . Évalué à 4. Dernière modification le 09 juin 2016 à 10:19.
De toutes façons 99% du temps c'est trop rapide pour voir quoi que ce soit.
Et puis c'est facile de voir qui a merdé au démarrage avec
Et aussi :
(si je me souviens bien pour cette dernière)
Voir ici :
http://linux-audit.com/auditing-systemd-solving-failed-units-with-systemctl/
http://www.linuxtricks.fr/wiki/utiliser-journalctl-les-logs-de-systemd
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par whity . Évalué à 3.
Oui, quand ton système démarre.
Quand il se bloque au démarrage, ça peut vite devenir la merde pour ne serait-ce que comprendre ce qui bloque.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Xavier Verne (site web personnel) . Évalué à 2.
Et parfois c'est pendant la session utilisateur qu'il se blo
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Moonz . Évalué à 2.
Perso j’ai des « fails » (les points de montage Samba, qui sont montés mais qui apparaissent en fail pour je ne sais quelle raison) qui n’apparaissent pas dans «
systemctl status» (je pense que tu voulais diresystemctltout court, sans argument. La sortie desystemctl statusest bien trop verbeuse pour être utile).[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par bobe . Évalué à 2.
Salut,
Moi, j'ai mis ça dans /etc/default/grub :
GRUB_CMDLINE_LINUX="systemd.show_status=1"
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Le Gab . Évalué à 4.
Je suis toujours sous Debian 7 avec un disque mécanique (7200tpm) et Gnome Shell, je suis dans les 15-20 secondes au boot mais vu que je met toujours mon ordi en veille bah, c'est plus de l'ordre de 3 secondes.
Néanmoins, j'ai systemd dans mes VMs, les scripts units, bof . J'avoue que la sortie statut et le rendu des logs sont sympas. Après, c'est tout aussi faisable avec l'avant systemd, c'est juste une question de convention et au pire du niveau du system administrateur qui est très fluctuant… non Michu ne crée pas de services.
Bref, systemd est là, c'est fait. :/
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Tanouky . Évalué à 2.
Pour mon utilisation, je n'y prête même pas attention. J'éteins machinalement plus souvent mon PC, puisqu'il s'allume en 10 secondes montre en main.
# l'installation et le choix des dépôts
Posté par j (site web personnel) . Évalué à 4.
J'ai été intrigué lors de mes test d'installation de Debian Jessie par le fait que, dans certains cas (choix du mode texte ? des sites miroirs ? autre chose ?) j'ai eu le choix d'inclure dès l'installation d'autres dépôts (backports notamment) que le principal (main). Mais comment faire pour obtenir ce choix ? Quel cheminement d'installation doit on choisir ?
[^] # Re: l'installation et le choix des dépôts
Posté par Naabster . Évalué à 1.
Installation en mode avancé dans autre choix d'installation…
[^] # Re: l'installation et le choix des dépôts
Posté par j (site web personnel) . Évalué à 2.
Je n'ai pas le souvenir d'avoir testé le mode expert … mais peut être par inadvertance
# LinuxFR est pro-Systemd
Posté par apkwa . Évalué à 10.
Je dois être maso car je vais atteindre le -10 en un temps record, mais il y a tout de même depuis plusieurs mois un phénomène sans pareil sur LinuxFR.
Si on regarde les votes des commentaires, ceux qui ne parlent pas de systemd tombent dans l'indifférence.
Ceux qui parlent de systemd déchaînent les votes:
- Si le commentaire est pro-Systemd, on peut espérer le +10 de pertinence. Ce qu'on a à dire est donc intéressant.
- Si on est contre systemd, on est systématiquement dans le négatif. Notre commentaire est donc inutile (sûrement car "résistance is futile")
Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd. A la limite, il se limiterait à la fonction d'init pourquoi pas. Ce serait une alternative de plus et puis voilà.
Là, franchement, il est hyper complexe, il peut remplacer le vénérable init mais aussi
fstab,crontab,iptables,su,udev… avec des choix très discutables sur la gestion de l'UEFI ou plus récemment sur la survie des process après logout (nohupca veut dire ce que ca veut dire, il n'y a pas besoin d'une option pour ca).S'il faut à tout prix remplacer l'init, il y a d'autres alternatives mais qui ont a priori le tort de ne faire que ce qu'ils doivent faire (par exemple
openrcsouvent cité, mais aussirunitqui est, lui, vraiment impressionnant de rapidité).Donc non, je ne comprends pas ce mouvement de foule qui ne jure que par systemd.
[^] # Re: LinuxFR est pro-Systemd
Posté par Le Gab . Évalué à 4.
Je viens d'en faire les frais :)
Mon commentaire pourrait paraître simpliste ou occultant que systemd va au delà mais justement, comme tu le pointes, systemd était vendu comme un remplaçant d'init au départ, donc c'est sur cet aspect là que le comparais et de là, il ne m'impressionne pas et ne simplifie pas ma vie d'admin vétéran car il est effectivement d'une complexité effarente en cas de "fail".
Sa nomenclature très laide, j'ai vraiment du mal avec mais ce qui m'inquiète et qui a été mainte fois relevé c'est son intrusivité et là, ce sont les pro-systemd qui l'occultent.
[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 9.
Je pense que ceux qui ne sont pas 100% pour systemd ont juste lâché l'affaire. Ils utilisent autre chose, et basta.
Perso, quand je vois un article qui va clairement faire l'apologie de systemd, en général, je me contente des 10-20 1ères lignes et je passe à autre chose. Je peux limite deviner le reste sans le lire.
Les débats autour de systemd que j'ai lu ont toujours été menés à charge contre sysVinit (et la plupart des arguments étaient fondés) mais pas en montrant en quoi systemd était le meilleur (de tous les init).
Maintenant, parmi les opposants à systemd, certains faisaient de la résistance au changement (genre ceux qui défendaient les scripts de sysVinit…), mais pas tous. D'autres disaient qu'il existe des alternatives, aussi bien voire mieux en terme de maintenance (daemontools/runit étaient régulièrement cités, et je n'ai souvenir d'aucun argument contre eux, étrange… au lieu de ça, la discussion re-déviait sur une attaque à sysVinit qui démontrait combien le bash ne conviens pas pour les scripts d'init, comme si sysVinit en faisait le meilleur usage…).
N'étant pas fan de systemd, et encore moins de sysVinit, j'ai un peu suivi certaines de ces alternatives et lu quelques articles (pas de grands livres rentrant dans les détails, des articles relativement courts, pas plus de 2 pages A4) s'y relatant (donc mon opinion est clairement partielle).
Sur deux VMs, j'ai fait des tests niveau vitesse. À services égaux, runit semble légèrement plus rapide, au démarrage comme à l'extinction.
C'est probablement égal, une fois pris en compte le manque de précision de mon outil de mesure (horloge système de l'hôte, combiné à un regard vissé sur les fenêtres des VMs) biais d'observation et le fait que la nature même d'une VM virtualbox rend les mesures aléatoires.
Je pense que l'engouement est lié à:
Runit, puisque tu le cites, n'a, à priori, pas eu le même nombre de personnalités célèbres derrière. Et il ne cherche évidemment pas à faire autre chose que
C'est tout de suite moins sexy. Du coup, j'imagine que peu de gens on fait l'effort de fournir des scripts d'initialisation pour une distribution, ce qui n'aide pas non plus.
[^] # Re: LinuxFR est pro-Systemd
Posté par Zenitram (site web personnel) . Évalué à -4.
Stats Zenitram, la majorité des gens qui critiquent systemd se défoulent pour le plaisir (ça a l'air de faire du bien) et continue d'utiliser leur distro (avec systemd donc).
Comme beaucoup de changements, les gens réagissent au début et ensuite se rendent compte que rien n'a vraiment changé en fait et/ou que c'est pas si mal en fait, et trouvent alors un nouveau nom à lyncher, et ainsi de suite.
Je me permet de recopier un commentaire qui m'a bien plu :
https://linuxfr.org/nodes/109169/comments/1659972
On m'avais dit qu'une fois que Centos 7 arriverait, les gens partiraient en masse (donc en juillet 2014 ). Puis on a dit "tu verras quand Debian sortira" ( avril 2015 ). Et ensuite "quand ça toucheras Ubuntu" (octobre 2015). Puis "nan mais je voulais dire Ubuntu stable" (avril 2016).[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 7.
Stats Freem, la majorité des gens qui critiquent systemd lui font une critique positive. Ça à l'air de faire du bien :D
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: LinuxFR est pro-Systemd
Posté par Plinn . Évalué à 0.
Je rencontre exactement les mêmes problèmes que toi dans l'administration de tous les jours (Debian Jessie).
[^] # Runit
Posté par rogo . Évalué à 10. Dernière modification le 10 juin 2016 à 10:57.
Pour ma part, j'ai utilisé runit en production, pas juste sur une VM par curiosité. C'est un bon outil, mais j'ai basculé sans hésitation vers systemd quand Jessie est sortie.
D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/. Debian ne les fournit pas et qu'il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).
Mon besoin était de surveiller (monitoring) des services dont l'un n'avait pas de mode démon. Il n'écrivait même pas son PID dans un fichier. Ça a l'air tout bête, mais il n'y a guère d'outil pour surveiller un service de ce type, et le relancer en cas de crash ou de signal d'arrêt. C'est pour ça que j'avais opté pour runit.
Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond. Et Runit n'utilise pas les cgroups, donc un service peut échapper à son gestionnaire — à sa décharge, les cgroups sont apparus bien après lui.
En pratique, je trouvais aussi que runit n'étais pas si simple que ça à administrer. Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec
sudans les scripts shell des services. Autre exemple, la gestion des dépendances est vraiment très sommaire : c'est au script shell de tester si ses pré-requis sont là, et de quitter s'il manque quelque chose, ensuite runit essaie de le relancer plus tard.Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service. De toutes façons, quand une machine démarre en moins de 5 secondes, je ne vais pas faire la course pour quelques dixièmes.
J'ai du respect pour runit, un petit outil bien fait (hélas peu documenté), mais à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.
[^] # Re: Runit
Posté par Anthony Jaguenaud . Évalué à 6.
Et une ligne dans
/etc/inittab?Ça ne marchait pas ?
[^] # Re: Runit
Posté par rogo . Évalué à 6.
Ça aurait sûrement marché, mais j'ai du mal à croire que des gens mettent des services comme apache2 dans leur inittab. Pour arrêter un service on change de runlevel?
[^] # Re: Runit
Posté par freem . Évalué à 3.
Hum… sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
Runit, il lance des services, et il les gère. Au travers de scripts shell.
Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?
Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de
test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.
Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.
Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).
Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:
Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D
C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher… d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?
C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)
Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.
Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.
[^] # Re: Runit
Posté par barmic . Évalué à 8.
Je ne sais pas chez les autres, mais Debian et dérivées avait une bibliothèque (infâme) shell pour simplifier les scripts d'init. OpenRC a un autre exemple de scripts mieux fait c'est déclaratif (globalement). Ce qui est marrant avec systemd c'est que d'un coup on s'est rendu compte que tout était possible et qu'on était à quelques yakafokon de résoudre toutes les lacunes qu'il avait depuis 20 ans…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Runit
Posté par rogo . Évalué à 6.
Comme quoi on peut avoir installé runit, le promouvoir comme alternative à systemd, vanter sa documentation… et ne pas avoir compris les principes de base de runit. Ses scripts de lancement doivent rester en premier plan, contrairement aux lancements de démons qu'on trouvent dans /etc/init.d/.
Merci de ne pas déformer mes propos. Je disais que pour Runit les scripts shell ne suivaient pas la norme de SysVinit. Je n'ai pas comparé avec systemd et son format de configuration.
Mais si tu viens sur ce terrain, alors parlons de la magnifique norme pour lancer un démon avec SysVinit : chacun se démerde comme il peut avec son shell et les outils du bord. Et bien sûr, les outils standard dans le monde Debian (comme
start-stop-daemon) ne sont pas présents chez Redhat. Runit a fait le choix de prendre en charge la démonisation, mais avec l'inconvénient de mal gérer les processus qui forkent. À comparer avec systemd qui s'accommode de tout, y compris les doubles forks. On peut le détester sur plein d'aspects, mais il faut reconnaître qu'il apporte aussi des progrès techniques par rapport à tous ses concurrents, et c'est pour ça qu'il s'est largement imposé.[^] # Re: Runit
Posté par freem . Évalué à 2.
Je sais, oui. Ceci dit, quand on fait une migration, il est quand même utile de pouvoir le faire au fur et à mesure, et c'est d'ailleurs l'impression qui ressort de ce document
Je me trompe? D'ailleurs, pas mal de bordel dans /etc/init.d/ n'a pas vocation à resté lancé (initialisation des partoches/réseau, notamment).
Tu as, bien sûr, noté le smiley?
Yep, sysVinit, c'est le pire qui existe à ma connaissance.
[^] # Re: Runit
Posté par ut0mt8 (site web personnel) . Évalué à 3.
J'ai moi meme utilisé runit pendant des années (et utilise toujours) comme simplificateur de lancement de démon. Je m'explique. Bien souvent nous sommes amenés en mileu professionnel à devoir lancer tel ou tel démon mal packagé et sans scripts (ou avec des scripts d'init moisi). Dans ce cas au lieu de devoir écrire un énieme script j'utilisais runit, avec un certain bonheur. Alors certes il faut que le programme puisse tourner en foreground (j'avoue trouver le fait que chaque programme gére sa propre démonisation pas très bon, et j'aimerais idéalement une version standard de le faire).
Runit est simple et stupide comme j'aime. Je suis d'accord avec les limitations que tu vois; mais certains ont crée un framework par dessus pour palier ses défauts.
Par exemples les appliance F5 utilisaient (utilisent) runit comme init. Et ce sont des trucs sérieux :)
A noter que l'on peut tout à fait utiliser runit (ou un de ces clones) avec les cgroups; il suffit de le wrapper. Bref je vous invinte à tester .
[^] # Re: LinuxFR est pro-Systemd
Posté par barmic . Évalué à 6.
La cabale n'existe pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: LinuxFR est pro-Systemd
Posté par barmic . Évalué à 5.
T'es à +8 malgré le coté victime de ton poste (« tout le monde il est contre moi ! »).
Ce qui est drôle1 c'est que tout ceux qui commence par vouloir prendre de la hauteur finissent par présenter leur poulain.
Le système de notation de linuxfr ne représente pas grand chose, hein ? Faut arrêter de se focaliser là dessus. Il y a des gens qui passent leur temps à expliquer que les like de facebook, les follower de twitter ou les +1 de google sont idiots, mais ils pleures pour des pertinents/inutiles ici…
En fait ça ne l'ai pas. Ça ne l'est plus, des troll sur les systèmes d'init on en a eu énormément. Il y un moment où la majorité des gens veulent juste passer à autre chose et n'ont rien à faire de init, leur distribution fait tout ce qu'il faut pour que ça marche et ça leur suffit. ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: LinuxFR est pro-Systemd
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 10 juin 2016 à 09:50.
Parce que ce n'est pas le sujet.
C'est jugé "inutile" car dans 99% des commentaires, la critique est du troll (dernier journal : il faut une ligne de config pour revenir à "comme avant" et ça râle contre systemd car des gus trouvent "horrible" un choix de config par défaut pour des raisons précises et accusent systemd d'un changement de config par défaut de Debian, n'est-ce pas ridicule?).
Ce que ne comprennent pas les "anti-systemd", c'est qu'en face il n'y a pas de "pro-systemd", juste des mecs qui trouvent que les mensonges trollesques contre systemd sont inutiles (franchement, si on est objectif sur sa critique de systemd, pourquoi a-t-on besoin de mentir dessus? C'est juste du troll dans 99% des cas).
un problème sur ta machine? C'est la faute à systemd, hop accusation par défaut sans réfléchir, c'est d'une banalité dans la notion de bouc-émissaire…
tu commences bien sur la note en te victimisant, mais loupe (encore et encore) le sujet : les anti-systemd n'ont pas affaire à des "pro-systemd", juste à des gens qui rigolent sur les bêtises que peuvent sortir les anti-systemd.
pas foule ne "jure que par", les gens sont surtout utilisateur du choix des mainteneurs, qui eux ont étudié le sujet plus que toi ou moi et on trouvé la chose utile (et ont dit pourquoi), tout en notant que la majorité des administrateurs système pas "du dimanche" apprécient ce changement (c'est que ça soit être utile, non?).
Ce qui est lourd, c'est que les anti-systemd pensent toujours qu'ils ont affaire à des pro-systemd dès qu'on leur montre que leur critique contre systemd est stupide.
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 10.
Et c'est bien triste …
Microsoft fait de l'open source, Il y a même un Windows SubSystem for linux,
vi contre emacs n’intéresse plus personne
et maintenant systemd cela à l'air plutôt bien.
Cela n'augure rien de bon pour linuxfr, plus aucun journal n'atteint le point Godwin, Pbpg ne vient plus nous voir bref c'est le début de la fin …
si cela continue comme cela, on va tous finir par regarder et commenter des vidéos de chat (oui l'animal) sur snapchose
[^] # Re: LinuxFR est pro-Systemd
Posté par chimrod (site web personnel) . Évalué à 5.
faut voir le bon côté des choses : Linux a enfin atteint la maturité pour le desktop !
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 4.
On va tous mourir !
(dixit Homer simpson)
[^] # Re: LinuxFR est pro-Systemd
Posté par patrick_g (site web personnel) . Évalué à 4.
Je te trouve bien pessimiste. Avec le foot et le Brexit il y a du potentiel pour des journaux trollesques ce mois-ci.
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 2.
Le foot ne m’intéresse quasiment pas :
C'est quand même un sport ou les mecs jouent comme des gonzesses et les gonzesses comme des mecs
Le Brexit : A par voir David Cameron patauger dans sa connerie je trouve pas cela marrant
Si ils restent : ils ne pourront plus venir se plaindre comme avant et perdrons de l'influence
Si ils partent : à mon avis le bordel sera phénoménal pour tout le monde
Donc c'est du pipeau
Ya pas de quoi atteindre le point Godwin avec ça …
[^] # Re: LinuxFR est pro-Systemd
Posté par Sufflope (site web personnel) . Évalué à 4.
Une bonne petite histoire autour du code de la route et des motards et tu vas l'avoir ton sport.
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 1.
pfff même pas sur, cela fait longtemps qu'il sont plus en colère …
[^] # Re: LinuxFR est pro-Systemd
Posté par gasche . Évalué à 3.
Je ne vois pas trop de raison de regretter les points Godwin (même pour rigoler), mais les remplacer par des commentaires sexistes c'est quand même assez triste.
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 0.
Ok je reformule :
Le foot est un des rare sport ou les joueurs "masculins" donnent libre cours à leur coté féminin notamment lors des inévitables chocs inhérents à ce sport.
Alors que les joueuses donnent l'impression de déployer beaucoup plus d'énergie dans ce sport et ce de manière inversement proportionnellement à leur salaire.
Désolé ça le fait pas … cette phrase est ridicule
Personne à envie de répondre et je le comprends bien …
Je vais rester sexiste tant pis :)
[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 0.
T'inquiètes pas, Lennart nous sauvera bien à un moment donné…
[^] # Re: LinuxFR est pro-Systemd
Posté par Christophe B. (site web personnel) . Évalué à 2.
Lennart … Linux prêt pour le desktop … 42 … LA LUMIERE !!!!
je vois la lumière au bout du tunnel … merci je suis sauvé
ALLELUIA !!!!
[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 6. Dernière modification le 10 juin 2016 à 16:51.
.
C'est contradictoire, non? Être "pro-whatever", c'est bien être en faveur de whatever? Si on trouve une chose assez utile pour en remplacer une autre, c'est bien que l'on est en faveur de la première, sans obligatoirement considérer que la seconde est absolument mauvaise?
Pour le reste… il n'y a pas que des extrémistes et des aveugles dans la discussion, ce n'est pas parce que l'on n'apprécie pas systemd qu'on le déteste, et j'ose espérer que ce n'est pas parce qu'on l'apprécie que l'on doit jouer les zélotes.
[^] # Re: LinuxFR est pro-Systemd
Posté par Zenitram (site web personnel) . Évalué à -1.
Non : les mainteneurs ne sont généralement pas sur LinuxFr, ceux qui répondent ne sont pas les mainteneurs, mais des gens "lambda" voyant l'énormité des pseudo-critiques (même en connaissant très peu de systemd, on peut voir que c'est du n'importe quoi).
Les personnes critiquées sont celles qui haïssent (il faut voir la haine que ça peut déclencher, pour un truc ridicule comme un système d'init d'un OS, à croire que les gens n'ont rien de plus important dans la vie).
Jette un oeil sur les journaux parlant de systemd, ça y va rapidement dans l'insulte gratuite de son mainteneur et des mots haineux, on n'est pas du tout dans la critique objective / "je n'apprécie pas".
[^] # Re: LinuxFR est pro-Systemd
Posté par Moonz . Évalué à 4.
Et ça n’a bien entendu rien à voir avec de tristes sires qui répandent
de l’huiledu napalm sur le feu avec des sorties genre « ceux qui critiquent systemd sont des esclavagistes ».[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 4.
Il y a besoin d'être mainteneur pour avoir un avis sur systemd? Tout le monde peut avoir un avis, mainteneur ou non. Et donc, tout le monde peut être pro, anti, ou entre les deux.
Enfin, je suis d'accord que les discours autour de systemd virent souvent à l'extrême.
J'ai arrêté de suivre la ml de debian à cause de ça et de certains débordements (tant des utilisateurs que des modérateurs) que j'ai constatés (et non, je n'irai pas exhumer des preuves, ça fait longtemps que je n'en ai plus rien à foutre).
Par contre, je ne crois pas que seuls les anti mènent les «débats» dans la direction des décharges. Pour ma part, j'ai vu pas mal de débats constructifs être pourri par les deux camps extrêmes, ce qui est dommage, parce que j'ai aussi vu des avis constructifs tant des pro que des antis.
[^] # Re: LinuxFR est pro-Systemd
Posté par kantien . Évalué à 2.
Il n'y a pas besoin de faire de l'exhumation : les argumentaires se sont zombifiés ! :-P
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: LinuxFR est pro-Systemd
Posté par Misc (site web personnel) . Évalué à 3.
non, mais y a besoin de faire le taf pour que l'avis compte.
Bien sur, mais au final, ceux qui font le boulot décident. Et quand je vois le temps que Devuan a mis pour sortir une beta (sachant que Mageia a mis 4 mois pour sortir la première stable, avec infra, gouvernance, etc), le fait d'avoir eu 0 exode des utilisateurs (cf le journal sur devuan), j'ai tendance à dire qu'avoir un avis est plus facile que faire le taf. Et même si c'est triste, c'est la dur loi du logiciel libre. Si personne fait le taf, le taf est pas fait.
[^] # Re: LinuxFR est pro-Systemd
Posté par freem . Évalué à 2.
Suis d'accord. Mais dans ce cas, 90% des avis, pro ou anti, sont inutiles :)
C'est bien pour ça que, malgré que je ne sois pas d'accord avec Debian (parce que mes besoins actuels ne collent pas à leurs objectifs) je respecte profondément cette distribution et le boulot de ceux qui la font vivre.
franchement, Devuan, j'ai été sérieusement agacé par leur 1er «nom» (debian-fork, ou un truc à la con du style) et leur argumentaire de base. Le fork était peut-être utile et bon, mais de forker sur un troll, ça ne peut pas attirer les gens, fatalement.
[^] # Re: LinuxFR est pro-Systemd
Posté par Misc (site web personnel) . Évalué à 10.
mais supporte encore /etc/fstab.
mais supporte encore crontab comme avant. Rajouter l'execution periodique, ç'est quasiment logique (cf upstart et launchd). Entre lancer un soft sur un event (genre tel autre soft vient de se lancer) et lancer un soft sur un event temporel, y a pas grand chose de différent, donc y a du sens de faire les 2.
non. ce que systemd fait, c'est d'activer des regles de nat pour lancer des containers. C'est pas vraiment remplacer iptables, sauf si tu as une vision vachement réduite d'iptables.
pas vraiment. su va juste changer le userid, et parfois suivant les options, lancer ou pas l'initialisation. machinectl shell va te lancer une session, mais aussi dans un container. Le fait de lancer ça sans changer de namespace est juste une feature logique (vu que le namespace par defaut est juste un namespace comme un autre).
udev a été mergé par les devs upstreams, au cas ou tu as oublié.
En fait, je pense que si tu prends "le systeme d'init" comme "/bin/init", oui, tu va pas comprendre. Si tu prends en compte "/bin/init et /etc/rc.d" et les fichiers afférants, alors ça prends plus de sens. Genre /etc/rc.d/network, qui va gérer le réseau (comme networkd), /etc/rcS.d/S08mountall.sh va gérer le montage des partoches (d'ou le fait d'avoir un type mount, qui n'est que l'exposition du type interne de systemd pour les montages), et tout les sous morceaux de script qui font l'init.
Ou pour les distros RH-like, le gros bousin de /etc/rc.sysinit
Alors, je suppose que tu parles des machines de MSI (https://github.com/systemd/systemd/issues/2402). Comme dit dans le rapport de bug, il y a des raisons de vouloir écrire dans efivars pour des programmes externes. Et on l'a vu avec les gens de tmux, quand on soumet des demandes pour adopter le comportement d'un soft à un changement de systemd, c'est non car c'est à systemd de rien changer, et quand systemd ne change pas pour ne pas casser les programmes, c'est "très discutables" et le comportement aurait du changer.
On pourrait presque croire qu'il y a aucun moyen de faire le bon choix.
Le pourquoi du comment est pourtant expliqué dans les divers bug reports pour qui veut savoir ce qui est le souci derrière.
Et je vois pas en quoi nohup change grand chose. Ni même ce que ça veut dire en pratique, vu que ça ne s'applique que pour les programmes avec un concept de tty (vu que tout ce que ça fait, c'est d'ignorer le signal qui est envoyé quand tu perds ton port série, et par extension, ton terminal virtuel). Ça ne veux pas vraiment dire "lance ça en background", et par définition, ça n'a aucun sens sur un programme non lié à un tty (genre certains demons utilise SIGHUP pour autre chose que voir qu'il y a plus personne face à eux ).
alors en fait, si tu regardes un peu l'histoire:
- gentoo a remplacé son init (openrc)
- ubuntu a remplacé son init (upstart)
- apple a remplacé son init (launchd)
- sun a remplacé son init (smf)
Fedora avait adopté upstart (et RHEL 6 en a hérité), Suse et Mandriva voulait faire de même. Et je pense que certains BSD ont aussi refait leur init (genre openbsd).
Donc ouais, depuis un bout de temps, les unix veulent changer leur init.
En fait non, le tort, c'est d'avoir intéressé personne.
Sur les tonnes de distros de distrowatch, y en a aucune dans le top 30 qui s'est dit depuis que runit existe "tiens, on va mettre ça".
Openrc, c'est pire. Dans le débat du TC de Debian, personne n'a poussé. Le packager qui s'en occupait était grosso modo tout seul alors que ça aurait collé sans doute mieux aux problématiques de debian. Et dans gentoo, personne n'a corrigé les bugs du au lancement de service en parallèle présent pendant 4 ou 5 ans. Et tout comme upstart, c'était bien dormant avant que systemd n'arrive.
Donc non, leur seul tort, c'est que ça n'a motivé personne. Et en général, si un truc motiv e personne, y a des chances que ça soit pas si bien que ça, que ça répondes pas aux problèmes des gens. Y a pas à
C'est pourtant pas faute d'avoir eu largement le temps de lire les discutions des 5 dernières années.
[^] # Re: LinuxFR est pro-Systemd
Posté par xcomcmdr . Évalué à 1.
Merci. :)
Et c'était très intéressant.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.