Avoir dû ?
Comme écrit précédement, j’ai encore installé des machines la semaine dernière en Jessie, et virer systemd représente deux lignes
Le fork n’est donc absolument pas une nécessité.
Sauf à utiliser des DE comme Gnome, KDE, Mate, Cinnamon, XFCE … Probablement aussi LXDE, ils sont tous impactés.
Donc, soit on utilise des DE alternatifs comme Fluxbox, Openbox et autres, ou alors en serveur sans interface graphique.
Relis les trois messages précédants;
[quote=“haleth”]Avoir dû ?
Comme écrit précédement, j’ai encore installé des machines la semaine dernière en Jessie, et virer systemd représente deux lignes
Le fork n’est donc absolument pas une nécessité.[/quote]
Techniquement, je suis d’accord, ce n’était pas une nécessité.
En revanche, le vrai problème que me pose ‘systemd’ dans Debian, c’est que l’équipe l’a imposé comme le système par défaut alors que conserver ‘sysvinit’ par défaut aurait très bien fonctionné et n’aurait pas empêché d’installer ‘systemd’ à la place, par exemple pour installer Gnome. Alors qu’avoir ‘systemd’ par défaut exclut tout un tas d’applications taillées pour les systèmes *NIX et casse par défaut la compatibilité avec les noyaux UNIX.
C’est pour moi un problème de gestion du projet plus qu’un problème technique. Je n’ai aucun problème à ce que certaines personnes utilisent ‘systemd’, mais l’imposer dans l’installateur contre l’avis d’une bonne part de la communauté alors que ça casse la compatibilité avec les noyaux UNIX, je trouve ça très discutable. On a eu une résolution pour demander à au moins proposer le choix entre ‘sysvinit’ et ‘systemd’ à l’installation : elle a été rejetée. Et qu’on ne vienne pas me parler de démocratie car on sait très bien qu’aujourd’hui Debian est représentée et donc influencée par des entreprises (Canonical et Red Hat principalement).
Le projet Debian n’est plus celui d’une communauté qui veut faire du libre sa priorité, mais d’un ensemble d’ingénieurs salariés de grands groupes qui utilisent ces personnes comme vecteurs d’influence pour orienter Debian dans le sens qui les arrangent. Voilà pourquoi je doute aujourd’hui de Debian et pourquoi je pense qu’un fork était malheureusement nécessaire.
Je pense éxactement la même chose que Cluxter, malheureusement …
+1, La plupart des gens qui défendent l’intégration de systemd ne comprennent pas ça d’ailleurs, et c’est impossible de discuter avec eux.
Mouais, je suis clairement contre systemd, mais ne vais pas en faire un plat tant que son éjection est rapide.
C’est ce que je me dis aussi pour le moment.
S’il s’avère que ‘systemd’ devient tellement invasif que Debian ne peut plus exister sans autre chose que ‘systemd’, alors je partirai pour de bon. Mais ce que je craignais existe déjà : j’ai voulu installer un logiciel la semaine dernière sous Wheezy qui n’est pas dans les dépôts, mais suggéré par le site de Debian. Je suis donc allé sur le site du projet, et là impossible de l’installer car il dépend exclusivement de ‘systemd’ !! (alors qu’il fonctionnait pour ‘sysvinit’ jusqu’à récemment) Les emmerdes commencent…
Donc je vais quand même commencer à regarder ailleurs pour voir ce qui existe.
Hello et bonne année !
Je viens un peu répondre à des trolleurs à qui ont ne donne pas la réplique.
C’est surtout une question d’inertie d’évolution de ces machines (tu maintiens encore du Bo, non ?). La RHEL qui intègre systemd est récente.
Intéressant, ça pose le problème de la légitimité du commité technique (qui est la plus haute organisation de la structure de Debian).
Je n’ai vu personne parler de cette problématique (faut-il revoir la constitution ?). Mais je vous propose de venir en discuter le week end du 12 avril à la MiniDebConf15 à Lyon 
C’est très subjectif de définir ce qui fonctionne ou non. Etch fonctionne très bien, je vois pas de raison de passer à autre chose.
Tu pense à quoi en particulier ? syslog (qui est compatible avec logind ou autre chose ?
Pour les autres noyaux unix, je ne sais pas ce que fait debian, mais utiliser sysvinit n’est pas une très bonne idée AMHA rc.d est utilisé par tous les unix auquel tu pense autant faire comme eux.
Espèce de gros trolleur, va
Les projets libres se réclament rarement être des démocraties, parce que c’est mal (c’est quoi le peuple d’un logiciel libre ?). On parle plus souvent de méritocratie, c’est pour ça que ce sont les développeurs Debian qui ont le pouvoir et que le projet est grosso modo organisé par un “si tu as envi de faire quelque chose, fais-le”.
La communauté Arch aussi est gangrénée par RH & Canonical ? Canonical qui a était contraint d’abandonner son projet suite au choix de Debian ? Sérieusement des théories du complot sur RH j’en entends depuis que je suis sous linux à une époque où LP n’avait pas encore créé PulseAudio, ni aucun *kit. C’est les plus gros et contribuent à beaucoup de choses donc ils font peur, mais ils n’ont pas d’intérêt à faire du mal à leur écosystème (Debian c’est pas leur concurrent, Canonical ça représente rien, Suse c’est pas loin d’être infime). D’ailleurs chez Novel aussi ils sont contrôlés par RH ? C’est des concurrents, hein ?
Rien que ça ? Debian est fait par ceux qui le font.
Faut arrêter les délires complotistes.
N’empêche que, le vote fut serré (pour une organisation contrôlée par RH & Ubuntu), qu’il y a eu plus d’un an de débat (même chez Arch ça n’a pas était aussi long). Qu’il y a un moment où il faut arrêter et donner une décision pour permettre aux empaqueteurs de faire leur boulot. Donner une position tordue (oui on le prend, mais en fait pas vraiment enfin sauf si vous utilisez la version de bureau parce que vous utilisez Gnome), c’était laisser la porte ouverte à continuer des débats sans fin. La résolution n’empêche pas de continuer à supporter sysvinit ou ce que tu veux, créer son propre installeur ça n’a rien de bien compliqué (en fait tu dois même pouvoir te contenter de créer un preset qui va bien ou quelque chose du genre).
Mais la réalité c’est que tout le monde s’en fou. Il n’était pas simple de créer un script d’init (faire un copier/coller de skeleton et modifier 3 ou 4 trucs ça marche quand t’es dans le cas nominal). Ça touchera assez peu d’utilisateurs au final et comme pour pulseaudio les gens s’y feront une fois que l’intégration sera correct. Les mainteneurs ont laissé sysvinit (qui est sincèrement bidon comme init[1]) pourrir dans son coin, sans s’intéresser aux usages et aux diverses améliorations possibles (utiliser les groupes de contrôle ça n’est pas très compliqué même pour sysvinit).
Je ne dis pas que systemd est parfait loin de là. Pour moi c’est une mauvaise réponse à de vrais problèmes, mais faut arrêter de se faire des nœuds au cerveau pour si peu.
C’est de la faute à Debian ? à RH ? à LP ? ou bien aux développeurs de ce logiciel ?
[1] : il est compliqué comme un logiciel qui offre pleins de fonctionnalités alors qu’en fait niveau fonctionnalité il fait le minimum syndical (et encore)
Je suis d’accord;
[quote=“MisterFreez”]Hello et bonne année !
Je viens un peu répondre à des trolleurs à qui ont ne donne pas la réplique.
C’est surtout une question d’inertie d’évolution de ces machines (tu maintiens encore du Bo, non ?). La RHEL qui intègre systemd est récente.
[/quote]
Non, les serveurs que je gère sont sous wheezy/squeeze-lts/trusty/squeeze/wheezy pour les 5 principaux. Il y avait une machine Bo qui servait de serveur d’imprimante mais l’imprimante a capoté, elle est éteinte.
Si j’installe un sereveur, il est évident que je n’utiliserai pas systemd, préférant le controle et la sécurité de scripts disjoints à un monolythe.
[quote]
[…]
C’est très subjectif de définir ce qui fonctionne ou non. Etch fonctionne très bien, je vois pas de raison
Tu pense à quoi en particulier ? syslog (qui est compatible avec logind ou autre chose ?
Pour les autres noyaux unix, je ne sais pas ce que fait debian, mais utiliser sysvinit n’est pas une très bonne idée AMHA rc.d est utilisé par tous les unix auquel tu pense autant faire comme eux.[…]
[/quote]Je ne comprends pas bien ce que tu dis. Tu as effectivement avec systemd un problème dans le principe en intégrant dans un seul programme la gestion de quantité de services fondamentaux. Il semble même que la gestion du parefeu sera aussi gérer par systemd.
Le principe et la solidité des Unix se fondait sur le principe une tache/un programme et l’un des reproches fait à Linux (qui du coup n’est pas le noyau pour GNU) est son coté monolithique.
Cela peut avoir beaucoup d’inconvénients: multiplication des processus, difficulté de paralléliser le démarrage, etc. Ces inconvénients sont minimes sur un serveur.
Les avantages sont certains. Les soucis de Windows avec svchost sont un très bon exemple des soucis d’un programme pilotant tout.
Faire un tel programme peut être possible, le proposer par défaut pourquoi pas, mais il reste particulièrement étonnant qu’il n’y ait pas d’assurance que ce programme ne devienne pas fondamental et indispensable à tout. Les arguments contre systemd sont légitimes et n’ont pas tous reçus de réponse satisfaisante.
Prend le cas simple de ClefAgreg, l’utilisation d’un système de fichiers constitué d’image squashfs et d’un ramdisk réunis, ainsi que le principe des extensions impose un démarrage séquentiel (je suis même obligé de neutraliser insserv). ClefAgreg est fondée sur Debian. Si systemd devient incontournable, il faudra que je passe à autre chose ce qui serait pénible.
systemd remplace udev, et udev est fondamental. Que va devenir udev? Restera-t-il un udev standalone? En fait Gentoo a développé un fork d’udev qui se passe de systemd. Les linux sans systemd vont donc se développer mais avec des différences avec les linux systemd sans commune mesure avec les différences actuelles entre un ubuntu upstart et un redhat sysvint par exemple.
systemd est censé remplacer les services pam, iptables, les services de logs.
Les conséquences actuelles sont importantes: plusieurs démissions de poids lourds de debian par exemple, notamment parce que le choix entre plusieurs systèmes de démarrage n’a pas été accepté.
Debian perd beaucoup dans cette histoire en terme d’image et de fiabilité dans le temps. Ce virage a 180° sur les principes initiaux fragilise l’ensemble des ses principes.
[quote=“fran.b”][quote=“MisterFreez”]Hello et bonne année !
Je viens un peu répondre à des trolleurs à qui ont ne donne pas la réplique.
C’est surtout une question d’inertie d’évolution de ces machines (tu maintiens encore du Bo, non ?). La RHEL qui intègre systemd est récente.
[/quote]
Non, les serveurs que je gère sont sous wheezy/squeeze-lts/trusty/squeeze/wheezy pour les 5 principaux…[/quote]
Merci d’être à notre service, et félicitation pour ta promotion.
/Respect @toute l’équipe
Édit orthographique
C’est surtout une question d’inertie d’évolution de ces machines (tu maintiens encore du Bo, non ?). La RHEL qui intègre systemd est récente.
[/quote]
Non, les serveurs que je gère sont sous wheezy/squeeze-lts/trusty/squeeze/wheezy pour les 5 principaux. Il y avait une machine Bo qui servait de serveur d’imprimante mais l’imprimante a capoté, elle est éteinte.
Si j’installe un sereveur, il est évident que je n’utiliserai pas systemd, préférant le controle et la sécurité de scripts disjoints à un monolythe.[/quote]
Je ne dis pas le contraire, mais aujourd’hui une entreprise qui monte son serveur linux aura de bonnes chances de le faire avec la dernière RHEL donc avec systemd.
Dis autrement s’il est clairement plus sûr pour quelqu’un comme toi ou moi de rester sur des trucs que l’on maitrise bien, RH supporte systemd (pour les clients ça offre un bon nombre de garantis et la possibilité contractuelle de se retourner contre RH en cas de gros pépins).
[quote=“fran.b”][quote=“MisterFreez”]
[…]
C’est très subjectif de définir ce qui fonctionne ou non. Etch fonctionne très bien, je vois pas de raison
Tu pense à quoi en particulier ? syslog (qui est compatible avec logind ou autre chose ?
Pour les autres noyaux unix, je ne sais pas ce que fait debian, mais utiliser sysvinit n’est pas une très bonne idée AMHA rc.d est utilisé par tous les unix auquel tu pense autant faire comme eux.[…]
[/quote]Je ne comprends pas bien ce que tu dis. Tu as effectivement avec systemd un problème dans le principe en intégrant dans un seul programme la gestion de quantité de services fondamentaux. Il semble même que la gestion du parefeu sera aussi gérer par systemd.
Le principe et la solidité des Unix se fondait sur le principe une tache/un programme et l’un des reproches fait à Linux (qui du coup n’est pas le noyau pour GNU) est son coté monolithique.[/quote]
Il faut voir de quoi on parle. Linux est très modulaire, c’est juste que sa modularité est statique (contrairement aux micronoyau qui peuvent lancer, recharger ou mettre à jour un module en live).
Pour systemd, c’est un peu plus complexe c’est un ensemble de processus qui ont un couplage relativement fort entre eux.
Justement non, tu n’a pas 250 processus systemd, mais une série de processus systemd-* (ou quelque chose du genre). C’est très différents parce que tu diagnostique bien mieux ce qu’il se passe en cas de problème.
Je suis d’accord, même si je ne les connais pas bien (je ne connais pas bien systemd non plus d’ailleurs)
Rien avoir mais tu va bénéficier d’OverlayFS ou c’est trop limité pour ce que tu fais ?
Ta problématique, si je ne me trompe pas c’est que le contenu de ton système de fichier est géré par un empilement d’extensions et selon l’ordre de déploiement des extensions tu risque d’avoir une version différentes d’un même fichier (dans le cas où deux extensions possèdent un fichier au même endroit).
Est-ce qu’il ne serait pas intéressant d’avoir une seule tâche qui va construire l’ensemble du système de fichier (mise en place de la racine, puis des extensions) plutôt que de reposer sur le système d’init pour faire ça ? C’est le principe en tout cas avec sysvinit qui lance une tâche qui va monter tout ce qui va bien depuis le [mono]/etc/fstab[/mono], ça évite d’avoir à tordre le système d’init (que ce soit sysvinit, systemd, upstart, rc.d ou openrc).
systemd remplace udev, et udev est fondamental. Que va devenir udev? Restera-t-il un udev standalone? En fait Gentoo a développé un fork d’udev qui se passe de systemd. Les linux sans systemd vont donc se développer mais avec des différences avec les linux systemd sans commune mesure avec les différences actuelles entre un ubuntu upstart et un redhat sysvint par exemple.
Pour pam je sais pas, pour iptables non, pour les logs il s’interface avec syslog et propose des services très utiles surtout pour serveur (le logging au plus tôt dans le processus de démarrage - très pratique quand tu es à distance).
Pour iptables, non d’une part parce qu’iptables est mort (et ça c’est bien) d’autre part parce qu’il n’ambitionne pas de remplacer ni contourner nftables. C’est un outils qui permet de créer des règles au même titre que les autres firewall sous linux.
[quote=“fran.b”]Les conséquences actuelles sont importantes: plusieurs démissions de poids lourds de debian par exemple, notamment parce que le choix entre plusieurs systèmes de démarrage n’a pas été accepté.
Debian perd beaucoup dans cette histoire en terme d’image et de fiabilité dans le temps. Ce virage a 180° sur les principes initiaux fragilise l’ensemble des ses principes.[/quote]
Debian perds beaucoup oui, mais je ne vois pas de tel virage. Pour moi Debian a toujours était pragmatique et plus dans l’intégration de techno qu’autre chose donc l’utilisation de systemd ne me surprend pas. Par contre j’aurais était fier d’une solution à la gentoo, mais ça n’a jamais était envisagé de manière correcte quelque soit l’époque (que ce soit pour systemd ou pour openrc ou autre).
[quote=“MisterFreez”][…]
Il faut voir de quoi on parle. Linux est très modulaire, c’est juste que sa modularité est statique (contrairement aux micronoyau qui peuvent lancer, recharger ou mettre à jour un module en live).
Pour systemd, c’est un peu plus complexe c’est un ensemble de processus qui ont un couplage relativement fort entre eux.
Justement non, tu n’a pas 250 processus systemd, mais une série de processus systemd-* (ou quelque chose du genre). C’est très différents parce que tu diagnostique bien mieux ce qu’il se passe en cas de problème.
[/quote]
Le problème semble être que non, les composantes de systemd n’existent pas l’un sans l’autre (sinon ça ne poserait pas de soucis). En cas de problèmes on ne sait pas qui coince.
[quote][…]
Ta problématique, si je ne me trompe pas c’est que le contenu de ton système de fichier est géré par un empilement d’extensions et selon l’ordre de déploiement des extensions tu risque d’avoir une version différentes d’un même fichier (dans le cas où deux extensions possèdent un fichier au même endroit).
Est-ce qu’il ne serait pas intéressant d’avoir une seule tâche qui va construire l’ensemble du système de fichier (mise en place de la racine, puis des extensions) plutôt que de reposer sur le système d’init pour faire ça ? C’est le principe en tout cas avec sysvinit qui lance une tâche qui va monter tout ce qui va bien depuis le [mono]/etc/fstab[/mono], ça évite d’avoir à tordre le système d’init (que ce soit sysvinit, systemd, upstart, rc.d ou openrc).
[/quote]Je ne tord pas le système d’init, je’utilise ces possibilités de parfaitement controler simplement le démarrage. Quel que soit le système de démarrage adopté, il est nécessaire de fabriquer la racine au niveau de l’initrd, pas du boot, après ce sont des ajustements liés à la particularité du système.
[quote]
Pour pam je sais pas, pour iptables non, pour les logs il s’interface avec syslog et propose des services très utiles surtout pour serveur (le logging au plus tôt dans le processus de démarrage - très pratique quand tu es à distance).
Pour iptables, non d’une part parce qu’iptables est mort (et ça c’est bien) d’autre part parce qu’il n’ambitionne pas de remplacer ni contourner nftables. C’est un outils qui permet de créer des règles au même titre que les autres firewall sous linux.
[/quote]Je rectifie donc, systemd va intégrer la gestion des règles nftables (cf dernières nouvelles) sur leur page d’information. Il ne reste plus à systemd qu’intégrer la gestion graphique et on aura un beau systemd monolithe où il suffira de péter une colonne pour que tout tombe.[quote]
[quote=“fran.b”]Les conséquences actuelles sont importantes: plusieurs démissions de poids lourds de debian par exemple, notamment parce que le choix entre plusieurs systèmes de démarrage n’a pas été accepté.
Debian perd beaucoup dans cette histoire en terme d’image et de fiabilité dans le temps. Ce virage a 180° sur les principes initiaux fragilise l’ensemble des ses principes.[/quote]
Debian perds beaucoup oui, mais je ne vois pas de tel virage. Pour moi Debian a toujours était pragmatique et plus dans l’intégration de techno qu’autre chose donc l’utilisation de systemd ne me surprend pas. Par contre j’aurais était fier d’une solution à la gentoo, mais ça n’a jamais était envisagé de manière correcte quelque soit l’époque (que ce soit pour systemd ou pour openrc ou autre).[/quote]
Le virage est dans le renoncement à deux principes fondamentaux (i.e ayant été affirmés dans la concetption de debian)
- Le support le plus large possible des plateformes
- Le respect des principes Unix (Une tache un programme et KISS)
Même Mac OS n’a pas osé faire cela, leur système (launchd) gère le démarrage des démons à l’exclusion du reste (en clair atd, inetd, le démarrage et sans doute les démons de surveillance type watchdog).
C’est bien parce que c’est un renoncement complet à ces principes et que c’est debian que ça fait réagir. Debian était la distribution Linux modèle: THE standard avec un respect strict des principes. Ça n’est plus le cas, et il n’y a eu aucune discussion sur l’abandon de ces principes.
Justement non, tu n’a pas 250 processus systemd, mais une série de processus systemd-* (ou quelque chose du genre). C’est très différents parce que tu diagnostique bien mieux ce qu’il se passe en cas de problème.
[/quote]
Le problème semble être que non, les composantes de systemd n’existent pas l’un sans l’autre (sinon ça ne poserait pas de soucis). En cas de problèmes on ne sait pas qui coince.[/quote]
On va arrêter de parler ainsi et rester sérieux et pas se forger des convictions si fortes sur des hypothèses non vérifiées. Sur ma machine systemd c’est ça :
% ps aux | grep 'system[d]'
root 183 0.0 0.0 33064 6188 ? Ss janv.22 0:00 /lib/systemd/systemd-journald
root 196 0.0 0.0 41480 3836 ? Ss janv.22 0:00 /lib/systemd/systemd-udevd
root 618 0.0 0.0 28356 2964 ? Ss janv.22 0:00 /lib/systemd/systemd-logind
message+ 631 0.0 0.0 42928 4092 ? Ss janv.22 0:03 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
michel 1371 0.0 0.0 35616 3960 ? Ss janv.22 0:00 /lib/systemd/systemd --user
Soit 4 processus (+ le processus racine de pid 1) parfaitement identifiés que je peux très bien arrêter chacun leur tour.
Modifier l’ordonnancement globale des étapes de l’init c’est tordre l’init. C’est très contraignant pour l’ensemble du système et si comme je l’ai compris c’est juste pour empiler les systèmes de fichiers dans le bon ordre c’est partir à la cueillette aux champignons avec une faux.
Tu es de mauvaise foie ! Je peux installer 250 gestionnaires de règles iptables/nftables aujourd’hui, sur Bo, sur slack et sur n’importe quel linux ça ne posera jamais le moindre problème (et tu le sais très bien). On parle de quelque chose qui permet d’ajouter, modifier, lister et supprimer des règles. Le runtime c’est toujours le noyau et ces règles que tu utilise iptables, nftables, systemd, nufw ou autre ça ne change rien (comme le fait d’ouvrir un fichier alternativement avec vim et emacs ne pose pas de problème, malgrès la piètre qualité de ce dernier…).
[quote=“fran.b”]Le virage est dans le renoncement à deux principes fondamentaux (i.e ayant été affirmés dans la concetption de debian)
- Le support le plus large possible des plateformes
- Le respect des principes Unix (Une tache un programme et KISS)[/quote]
Le problème c’est que tu parle d’un fantasme. Ça ne fait pas parti du contrat social, ni quoi que ce soit.
Pour le premier c’est encore moins vrai puisqu’il n’a jamais était question de refuser une solution sous prétexte qu’elle ne fonctionne que sous linux. Debian est le système universel, mais ça ne veux pas dire qu’il est parfaitement identique quelque soit la distribution que tu choisi. On va se refuser d’utiliser les jails et zfs avec Debian/kFreeBSD parce que ça ne marche pas avec linux ? Btrfs c’est mal parce que ça ne fonctionne que sous linux ? Il n’a jamais était question d’offrir le plus petit dénominateur commun.
[quote=“MisterFreez”]
On va arrêter de parler ainsi et rester sérieux et pas se forger des convictions si fortes sur des hypothèses non vérifiées. Sur ma machine systemd c’est ça :
% ps aux | grep 'system[d]'
root 183 0.0 0.0 33064 6188 ? Ss janv.22 0:00 /lib/systemd/systemd-journald
root 196 0.0 0.0 41480 3836 ? Ss janv.22 0:00 /lib/systemd/systemd-udevd
root 618 0.0 0.0 28356 2964 ? Ss janv.22 0:00 /lib/systemd/systemd-logind
message+ 631 0.0 0.0 42928 4092 ? Ss janv.22 0:03 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
michel 1371 0.0 0.0 35616 3960 ? Ss janv.22 0:00 /lib/systemd/systemd --user
Soit 4 processus (+ le processus racine de pid 1) parfaitement identifiés que je peux très bien arrêter chacun leur tour.
[/quote]Es tu sur que l’arrêt d’un d’entre eux ne coince pas ta machine y compris les autres processus? Je ne fais que prendre les specifications que donne systemd sur le site et la page wikipedia. Ça me parait sérieux.[quote]
Modifier l’ordonnancement globale des étapes de l’init c’est tordre l’init. C’est très contraignant pour l’ensemble du système et si comme je l’ai compris c’est juste pour empiler les systèmes de fichiers dans le bon ordre c’est partir à la cueillette aux champignons avec une faux.
[/quote]Imposer n’est pas modifier. Ça n’est pas pareil. Encore une fois, le système de fichier est crée dans l’initrd, tu te trompes en disant que ça vient de là. Mais avant de lancer cups, openvpn, ou autres il faut tenir compte des modifications précédemment faites, il faut lancer les éventuels serveurs de licence. Mais surtout ce qu’il y a à lancer est découvert au fur et à mesure, systemd, et autre sont batis sur ube basede données décrivant les processus à lancer. Je ne peux pas connaitre cette base, elle dépend des extensions mises. Donc exit tous ces systèmes et exécution des fichiers d’initialisation suivant les /etc/rc?.d[quote]
Tu es de mauvaise foie ! Je peux installer 250 gestionnaires de règles iptables/nftables aujourd’hui, sur Bo, sur slack et sur n’importe quel linux ça ne posera jamais le moindre problème (et tu le sais très bien). On parle de quelque chose qui permet d’ajouter, modifier, lister et supprimer des règles. Le runtime c’est toujours le noyau et ces règles que tu utilise iptables, nftables, systemd, nufw ou autre ça ne change rien (comme le fait d’ouvrir un fichier alternativement avec vim et emacs ne pose pas de problème, malgrès la piètre qualité de ce dernier…).
[/quote]Non, emacs ou les éditeurs de règles éditent des règles qui sont envoyées au noyau par un processus dédié simple (iptables ou nftables), point. Ici si j’ai bien compris, systemd va travailler directement les règles au niveau du noyau et peut être faire ses propres règles en fonction des processus lancés (genre comme sous windows «Voulez vous autoriser l’application machin/truc à utiliser le port blop») dans la mesure où il gère les sessions. Quel intérêt sinon d’écrire un nf/iptables nouveau?[quote]
[quote=“fran.b”]Le virage est dans le renoncement à deux principes fondamentaux (i.e ayant été affirmés dans la concetption de debian)
- Le support le plus large possible des plateformes
- Le respect des principes Unix (Une tache un programme et KISS)[/quote]
Le problème c’est que tu parle d’un fantasme. Ça ne fait pas parti du contrat social, ni quoi que ce soit.
Pour le premier c’est encore moins vrai puisqu’il n’a jamais était question de refuser une solution sous prétexte qu’elle ne fonctionne que sous linux. Debian est le système universel, mais ça ne veux pas dire qu’il est parfaitement identique quelque soit la distribution que tu choisi. On va se refuser d’utiliser les jails et zfs avec Debian/kFreeBSD parce que ça ne marche pas avec linux ? Btrfs c’est mal parce que ça ne fonctionne que sous linux ? Il n’a jamais était question d’offrir le plus petit dénominateur commun.[/quote]
Tu me parles d’une fonctionnalité, je te parles du système de démarrage et de la gestion des processus. Tu me parles de la possibilité de mettre une caravane, je te parle de la disposition des pédales d’accélarateur, de frein et du volant. Ça n’a rien à voir. systemd n’est pas une fonctionnalité, c’est le démarrage, c’est tout de même différent. Tu ne réponds que sur mon premier point, pas sur le second.
Tu me réponds comme si je voulais supprimer systemd, je ne fais que défendre le principe que systemd doit être rajouté et non se substituer à un système existant fondé sur des principes opposés. Il est quand même étonnant que les débats sur systemd suivent toujours le schéma:
Il faut continuer à proposer les autres systemes de démarrage et ne pas tout faire dépendre de systemd
qui dérive sur
Systemd c’est mieux versus c’est un truc monolithique [note que tu as eu tendance à minimiser cet aspect pourtant flagrant signe que cela te gène aussi je pense]
et finit par
Il faut être moderne et évoluer, systemd est une évolution
avec donc à la fin un débat sur l’existence même de systemd alors que le problème n’est pas là, le problème est que systemd s’insinue partout ou vécu comme tel (avec de bonnes raisons) et que si on ne veut pas de systemd pour des raisons diverses (sérieuses à mon avis, débiles selon le tien), il sera très difficile de le faire car cela ne sera pas proposé. C’est tout de même différent de «Youkaïdi systemd, youkaïda sysvinit!». Il ne s’agit pas de virer systemd, il s’agit de proposer une option avec systemd/sysvinit au début de l’installation. Cela est fait pour XFCE, debian l’a toujours fait. Si debian avait continué à le faire, il n’y aurait eu aucun débat ni aucun fork.
Je n’ai pas de preuves formelles à te fournir, je ne vais pas rentrer dans le code de chacun de ces programmes pour voir comment c’est fait et est-ce que la gestion d’erreur est correct, mais j’en ai fais l’expérience et non ça ne tue pas ma machine. Pour un sujet aussi trollifique wikipedia est à prendre avec des pincettes.
Je ne comprends pas. systemd repose sur une description des dépendances simples et sur une découverte dynamique pour d’autres dépendances (ce qui permet de retarder certains lancement). Après il est toujours possible de forcer l’ordre de démarrage avec systemd et il est même possible de debuger le démarrage en le lançant en mode pas à pas (il te pose la question avant de lancer chaque service).
De ce que j’en ai compris ce seront toujours des règles visibles et modifiables avec nftables ou autre. Ça permet d’envisager de mettre en place des règles dynamiquement (n’ouvrir le port 80 que si le serveur web est lancé et fermer le port lors du redémarrage du serveur web).
Le système de fichier racine c’est une fonctionnalité ? ext4 ça n’est pas très BSD…
D’une part, il ne s’agit que de l’init par défaut (c’est uniquement là dessus que le ctte s’est prononcé, il n’est rien dis des autres systèmes)
D’autre part, tu prends comme beaucoup à l’envers le problème des dépendances, c’est aux projets avales qu’il faut faire comprendre que la portabilité c’est bien. Que Debian fasse un travail de police là dessus c’est envisageable, mais il faut commencer par correctement décrire de quoi on parle. Est-ce qu’un paquet a le droit de dépendre de sysvinit uniquement ? d’une libc particulière ? d’un système de log ? Sous qu’elle condition ? C’est une question intéressante que de définir l’API de base de Debian comme une version plus à jour et plus précise de la LSB (que Debian n’implémente pas dans son installation par défaut).
Le problème c’est que chronologiquement c’est une problématique dont la majeure partie des gens se sont toujours foutu (alors que ça a toujours était un véritable problème notamment pour l’utilisation de logiciels propriétaires) et qui maintenant qu’une partie des gens sont pas content de quelque chose ils se réveillent et se disent que finalement c’est important. Ça sent l’argument pour se raccrocher aux branches…
C’est une problématique intéressante, mais il faut se donner les moyens de le mettre en place et faire une vraie proposition construite, pas ce contenter de coup de gueule répétés. Mais oui, ça demande du travail et tout le monde s’en fout de cette définition d’API, donc ça ne verra probablement jamais le jour. On va continuer à hurler à la mort et ça va s’arrêter là.
Mais ce n’est pas Debian qu’il faut blâmer si Gnome dépend de systemd, mais gnome lui-même (il y a des gens qui se posent des questions à ce sujet : blogs.gnome.org/desrt/2014/02/19/on-portability/).
[quote=“MisterFreez”]
(comme le fait d’ouvrir un fichier alternativement avec vim et emacs ne pose pas de problème, malgrès la piètre qualité de ce dernier…).[/quote]
C’est pas encore clair dans ton esprit ? Je t’accorde deux minutes pour comprendre
Emacs est nécessairement en avance sur vim la preuve en ces temps tourmentés, le créateur Richard Stallman proclamé Saint IGNUcius, un saint de l’ Église Emacs peut réconforter ses adeptes. Emacs d’ailleurs de son propre groupe de discussion sur l’arborescence alt.religion : news:alt.religion.emacs.
Les adeptes de vi n’ont créé que le Culte de Vi, que nous appellerons clairement « une misérable tentative pour singer leurs maîtres ».
Si tu veux plus de détails sur la supériorité d’emacs, je passerais de temps en temps pour t’apporter la Lumière ++
Je t’en supplie, Illumine moi de Ta Divine Sagesse.
Don’t feed the troll, autrement dit ne pas nourrir le troll 