systemd versions 212 à 215

Posté par ariasuni le 06 octobre 2014 à 09:59. Édité par esdeem, Davy Defaud, BAud, Nils Ratusznik, palm123, ZeroHeure, Benoît Sibaud, Cyril Brulebois, Pierre Roc, Misc, Nÿco, PolePosition et sanao. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

oct.

2014

systemd est un système de démarrage alternatif au démon init d’UNIX System V spécifiquement conçu pour le noyau Linux, avec une meilleure gestion des dépendances entre services et le chargement en parallèle des services au démarrage. Il est publié sous licence GNU LGPL version 2.11.

Voici une version traduite, réarrangée et non exhaustive des notes de version de systemd des versions 212 à 215. En bref, on ajoute un peu de sucre autour ! Vous pouvez même sauter ce qui ne vous intéresse pas.

Lennart, développeur principal de systemd, posant avec son livre préféré

N. D. M. : cette dépêche est un énorme travail d’eggman et de sinma qui méritent tous les deux des gros remerciements.

Sommaire

Version 212

Divers

systemd gère désormais un état global du système qui prend la valeur starting (en cours de démarrage), running (en fonctionnement), degraded (dégradé, c’est‐à‐dire au moins un service en échec), maintenance (mode de restauration ou d’urgence) ou stopping (en train de s’arrêter), que l’on peut consulter avec systemctl status (sans donner de paramètre). Il est notamment utile lorsqu’on manipule beaucoup de systèmes ou de conteneurs à la fois.

Et puis, enfin, un changement visible par l’utilisateur lambda ! Afin d’éviter que celui‐ci se retrouve avec un écran noir au démarrage, systemd évite le réglage le plus sombre et reste au‐dessus des 5 % les plus sombres lors de la restauration de la luminosité.

Côté fonctionnement interne, logind détruit maintenant automatiquement les objets d’IPC (InterProcess Communication, communication interprocessus) appartenant à un utilisateur quand il se déconnecte complètement, pour libérer des ressources. Cela inclut sémaphores, files de messages et mémoires SysV, ainsi que les files de messages et mémoires partagées POSIX. Les objets SysV et POSIX n’ont traditionnellement pas de cycle de vie, cette fonctionnalité corrige cela.

Outils en ligne de commande

Une nouvelle commande list-machines a été ajoutée à systemctl. Elle liste tous les systèmes d’exploitation dans un conteneur ainsi que leurs états (voir le point ci‐dessus), si systemd est utilisé dans ces conteneurs.

systemctl a également été enrichi d’une option -r pour énumérer récursivement les unités de tous les conteneurs locaux, quand il est utilisé avec la commande list-units (c’est l’action par défaut quand aucun paramètre n’est donné).

On notera aussi que machinectl bénéficie d’une nouvelle commande poweroff pour éteindre proprement un conteneur local.

Journal

journald peut transférer les messages de journal sur les pseudo‐terminaux de tous les utilisateurs connectés (équivalent de la commande wall). C’est désormais la configuration par défaut pour tous les messages d’urgence.

Le nouvel outil systemd-journal-remote permet de diffuser à la volée les flux des journaux journald sur le réseau.

Unités

Les unités minuteur (timer units) ont gagné deux nouvelles options :

WakeSystem= : si activée, les unités minuteur configurées de cette façon provoqueront la sortie de veille prolongée (si le système le prend en charge, ce qui est majoritairement le cas de nos jours) ;
Persistent= : si activée, sauvegarde sur le disque la dernière fois que l’unité a été activée. Cette information permet au redémarrage suivant d’activer les évènements qui auraient dû avoir lieu pendant que le système était éteint (comportement analogue à anacron). La commande list-timers de systemctl a été mise à jour pour afficher cette nouvelle information.

Réseau

Les adresses physiques des interfaces (adresses MAC) créées avec l’option --network-interface= de la commande nspawn sont générées à partir du nom de la machine, ce qui les rend stables entre plusieurs invocations du conteneur.

systemd-networkd alloue désormais des adresses prédictibles en cas d’auto‐configuration avec IPv4LL (IPv4 link-local, une technique qui permet d’assigner une adresse IP automatiquement dans le réseau spécial 169.254.0.0/16, quand il n’y a pas de serveur DHCP).

Découverte automatique des partitions GPT

Le mécanisme de découverte automatique des partitions GPT prend désormais en compte deux indicateurs (flags) sur une partition GPT : l’un provoque son montage en lecture seule et l’autre indique que la partition doit être ignorée pendant la phase de découverte automatique.

Deux nouveaux types d’identifiant universel unique (UUID) pour GPT ont été ajoutés à la découverte automatique de partitions, pour les architectures ARM 32 et 64 bits. Ça n’est pas particulièrement utile pour découvrir le répertoire racine pendant un démarrage bare‐metal (on n’y voit pas souvent d’UEFI), mais c’est quand même très utile pour autoriser le démarrage de disques dans nspawn avec l’option -i.

Sécurité

Le répertoire /sys/fs/cgroup/ est maintenant monté en lecture seule après que tous les arbres de contrôleurs y sont montés. Notez que les répertoires montés dans une sous‐arborescence ne sont pas en lecture seule. Cette mesure de sécurité est particulièrement utile car la glibc effectue une recherche pour prendre tous les pseudo‐systèmes de fichiers tmpfs qu’elle peut trouver pour implémenter shm_open() si /dev/shm n’est pas disponible (ce qui peut très bien être le cas dans un espace de noms donné).

Les options PrivateDevices=, PrivateNetwork= et PrivateTmp= sont maintenant utilisées sur tous les services tournant pendant une longue période (quand c’est approprié). En outre, l’option PrivateDevices= est plus sécurisée (elle ne nécessite plus la capacité CAP_MKNOD et l’ensemble des capacités liées, et implique DevicePolicy=closed).

Désormais, la gestion de kdbus prend en charge la politique de téléchargement dans le noyau. sd-bus peut désormais créer des connexions de surveillance (monitoring) qui peuvent espionner toutes les communications de bus pour déboguer.

udev dans un espace de noms de montage séparé

systemd-udevd va maintenant fonctionner dans un espace de noms de montage séparé. Pour bien comprendre, quelques explications s’imposent.

udev est un programme qui permet à l’ordinateur d’effectuer automatiquement certaines actions en fonction d’évènements liés au matériel (par exemple, monter automatiquement une clef USB lorsqu’elle est branchée à l’ordinateur). Les actions à effectuer sont déterminées grâce à des règles udev (des fichiers .rules habituellement fournis par la distribution, bien qu’il soit possible de les créer soi‐même). Or, ces règles permettent d’activer un programme ou un script arbitraire, via une ligne du type RUN+="mon_executable". Pour monter une clef USB, on fera appel au programme mount, par exemple.

Les espaces de noms de montage permettent de montrer une organisation du système différente (points de montage différents, ou passage de certains montages en lecture seule) pour certains processus. C’est notamment utile pour sécuriser les conteneurs.

Depuis quelques versions, il est recommandé de passer par l’activation d’un service systemd au lieu de l’utilisation de mount ; ça sera désormais obligatoire pour monter un périphérique. On utilisera donc : ENV{SYSTEMD_WANTS}="systemd_unit.service".

Amélioration du code

La prise en charge native de tcpwrap dans systemd a été supprimée. C’était du vieux code plus vraiment maintenu et qui avait de sérieux défauts. De meilleures alternatives existent, telles que les pare‐feux.

Pour les configurations qui nécessitent l’utilisation de tcpwrap, veuillez envisager d’invoquer votre service activé par socket via tcpd, comme avec le traditionnel inetd.

Version 213

Outils en ligne de commande

Concernant systemctl, les commandes systemctl list-timers et systemctl list-sockets disposent maintenant de l’option --recursive qui permet de lister les unités du type donné dans tous les conteneurs locaux, à l’instar de systemctl list-units.

Désormais, le générateur de graphe du démarrage (pour rappel : systemd-analyze plot) peut inclure les informations cgroups.

Le (petit) démon systemd-hostnamed a été mis à jour pour exposer le nom du noyau, sa variante et sa version sur le bus. C’est utile lorsque l’on exécute des commandes telles que hostnamectl avec l’option -H. systemd-analyze se sert de cette option pour afficher correctement les détails du système, lorsque l’exécution est distante.

Enfin, machined dispose d’une nouvelle interface de programmation (API) pour interroger les adresses IP des conteneurs enregistrés. machinectl status a été mis à jour pour afficher ces adresses dans sa sortie.

Unités

Cette fois, les unités de type service ont gagné beaucoup d’options pour permettre un contrôle beaucoup plus fin du comportement et des limitations de celles‐ci :

RebootArgument= peut être utilisé pour définir un argument de redémarrage pour le noyau, à utiliser si l’on déclenche un redémarrage avec StartLimitAction= ;
FailureAction= peut être utilisé pour définir une opération à déclencher quand un service échoue : ce paramètre fonctionne de façon similaire à StartLimitAction=, mais, contrairement à celui‐ci, il vérifie ce qui est effectué immédiatement, plutôt qu’après plusieurs essais de redémarrage du service ;
si CPUQuota= est activé, le service ne pourra jamais obtenir plus de temps processeur que le pourcentage indiqué, même si la machine est inoccupée ;
StartupCPUShares= et StartupBlockIOWeight= fonctionnent de façon similaire à CPUShares= et BlockIOWeight=, mais s’appliquent uniquement au démarrage du système ; ces deux options sont utiles pour assigner des priorités différentes à certains services pendant le démarrage et pendant l’exécution normale.

Dorénavant, l’analyseur de fichiers de configuration (.ini) ignorera les sections qui commencent par X-. Elles peuvent être utilisées pour maintenir des sections spécifiques à certaines applications dans les fichiers unités.

Réseau

Cette nouvelle version accueille un nouveau démon : systemd-timesyncd. C’est un client SNTP. Contrairement à un client NTP, il s’occupe simplement d’interroger un serveur distant et de mettre à jour l’heure de la machine (il est uniquement client, et non serveur).

systemd-timesyncd tourne avec des privilèges minimaux et n’agit que lorsqu’une connexion Internet est disponible. Il peut corriger l’heure tôt dans le processus de démarrage, ce qui est utile pour les systèmes comme le Raspberry Pi et d’autres appareils embarqués qui n’ont pas d’horloge temps réel.

systemd-networkd gère maintenant les tunnels IPIP et SIT, et se dote d’un nouveau compagnon, le démon minimal systemd-resolved. Il agit pour le moment comme simple compagnon à systemd-networkd et gère le resolv.conf en se basant sur la configuration DNS par interface, potentiellement obtenue via DHCP. À long terme, nous espérons l’étendre à la gestion d’un cache DNS gérant DNSSEC et mDNS.

Petite subtilité, systemd-networkd-wait-online est dorénavant activé par défaut. Il retarde network-online.target jusqu’à ce qu’une interface réseau ait été configurée. Cet outil est conçu pour fonctionner avant tout avec networkd, mais fera son possible pour donner du sens à une configuration réseau effectuée par d’autres moyens.

Autre subtilité, hostnamed a été modifié pour préférer le nom d’hôte configuré statiquement dans /etc/hostname à celui éventuellement fourni par DHCP. Cela correspond mieux au fonctionnement global de /etc, où la configuration de l’administrateur prévaut sur n’importe quelle autre.

Autre

La nouvelle option du noyau fsck.repair= contrôle comment fsck doit se comporter avec un système de fichiers incohérent au démarrage.

Version 214

Voilà la version 214 ! Truffée de nouvelles fonctionnalités et d’améliorations dans tous les domaines, en particulier en sécurité (service de bac à sable — sandboxing — de systèmes de fichiers, diminution des privilèges de nos démons), en réseau (trois nouveaux types d’interfaces sont dorénavant pris en charge par networkd) et dans les unités socket (quatre nouveaux réglages).

Le changement que je trouve le plus excitant : un premier pas dans la direction d’un système sans état. Dorénavant, /var est reconstruit s’il est vide au démarrage. Ma nouvelle commande favorite faisant appel à ça est la suivante :
systemd-nspawn -D /srv/mycontainer --read-only --tmpfs=/var -b.

Elle engendre un conteneur nspawn avec une arborescence montée en lecture seule et un dossier /var volatile et vide, monté par dessus et vidé lorsque l’on arrête le conteneur. Avec ces éléments en place, on peut facilement lancer des centaines d’instances de conteneurs ad hoc jetables depuis la même arborescence, en étant sûr qu’elles se terminent sans interférer les unes avec les autres. Prochaine étape (planifiée pour la prochaine version) : ajouter l’infrastructure pour gérer également le démarrage avec /etc vide (c’est‐à‐dire, avec une racine en tmpfs et seulement un /usr monté depuis l’arborescence d’une distribution en lecture seule).

Outils en ligne de commande

Unités

Les unités sockets ont gagné beaucoup d’options :

SocketUser= et SocketGroup= : indiquent le propriétaire et le groupe à utiliser pour les sockets AF_UNIX et les files d’attente FIFO sur le système de fichiers ;
RemoveOnStop= : si activé, tous les FIFO et les sockets sur le système de fichiers seront retirés quand l’unité correspondante est arrêtée ;
Symlinks= : prend une liste de liens symboliques à créer (sur le système de fichiers) des sockets système ou des FIFO créés par les sockets UNIX correspondants. Cette option est utile pour gérer les liens symboliques vers des fichiers sockets ayant le même cycle de vie que le socket lui‐même.

Concernant les unités de services, on gagne deux nouvelles options : ProtectedHome= et ProtectedSystem=. Elles rendent les données utilisateur (comme /home) inaccessibles ou en lecture seule, et le système (comme /usr) en lecture seule pour des services particuliers. Cela nous permet d’avoir un système de bac à sable très léger. Ces options ont été activées pour tous les services tournant pendant une longue période, quand c’est approprié.

De plus, l’effet de plusieurs paramètres pour les services a changé :

L’option on-abnormal a été ajoutée à Restart=. Si elle est définie, elle aura pour effet de déclencher des redémarrages automatiques pour toute raison « anormale » de fin d’un processus, ce qui inclut signaux d’erreur, vidanges mémoires, expirations de délai et expirations de délai de chien de garde (watchdog), mais exclut les codes de sortie propres ou non, ainsi que les signaux propres. Restart=on-abnormal est une alternative à Restart=on-failure pour les services qui doivent pouvoir s’arrêter et ne pas redémarrer lors de certaines erreurs en le signalant par un code de sortie d’erreur adéquat. Restart=on-failure ou Restart=on-abnormal est maintenant le réglage par défaut recommandé pour tous les services tournant pendant une longue période.
Si le réglage de l’option InaccessibleDirectories= pointe vers un point de montage (ou si le répertoire pointé contient lui‐même un point de montage), systemd essaiera de démonter totalement l’arborescence pour rendre les systèmes de fichiers vraiment indisponibles pour le service concerné.
Le réglage ReadOnlyDirectories= et le paramètre --read-only de systemd-nspawn sont dorénavant aussi appliqués de façon récursive à tous les sous‐points de montage.

Enfin, deux autres changements concernant les unités :

le socket /dev/log et la FIFO /dev/initctl ont été déplacés vers /run et ont été remplacés par des liens symboliques. Cette modification permet de se connecter à elles même si PrivateDevices=yes est utilisé pour un service — ce qui rend /dev/log inatteignable mais laisse /run accessible. Cette option a l’avantage de s’assurer que /dev contient uniquement des périphériques, des répertoires, des liens symboliques et rien d’autre ;
une nouvelle unité cible (target) a été ajoutée : network-pre.target. Elle est utile pour les services qui doivent être exécutés avant que le réseau ne soit configuré, par exemple les scripts de pare‐feu.

Réseau

systemd-networkd, systemd-resolved et systemd-bus-proxyd tournent maintenant sous leurs propres utilisateurs homonymes. Ils ne conservent que quelques capacités, mais ne peuvent cependant plus écrire dans des fichiers appartenant au super utilisateur root.

systemd-networkd gère maintenant la mise en place de périphériques Ethernet virtuels veth pour la connectivité des conteneurs, ainsi que les tunnels GRE et VTI.

Le fichier resolv.conf généré par systemd-resolved a été déplacé dans /run/systemd/resolve/. Si avez un lien symbolique depuis /etc/resolv.conf, il faudra peut‐être le corriger.

Amélioration du code

La dépendance à libattr a été éliminée. Les appels pour les attributs étendus ont depuis longtemps été déplacés dans la glibc, rendant libattr inutile.

La prise en charge des scripts init SysV et LSB a été supprimée du démon systemd lui‐même. À la place, un générateur crée des unités systemd natives lorsque nécessaire. Cela a permis de supprimer une portion non négligeable de code de compatibilité de « PID 1 », suivant ainsi les distributions, qui aujourd’hui ne livrent qu’un tout petit nombre de scripts init LSB ou SysV.

Virtualisation

Deux changements concernant la virtualisation :

la détection de la virtualisation fonctionne maintenant sans privilèges. systemd-detect-virt ne nécessite donc plus la capacité CAP_SYS_PTRACE et nos démons peuvent ainsi fonctionner avec moins de privilèges ;
les domaines privilégiés Xen (dom0) ne sont plus considérés comme de la virtualisation par la logique de détection de virtualisation. Après tout, ils ont en général un accès total au matériel et sont d’ordinaire utilisés pour gérer des domaines non privilégiés (domU).

Autres

À titre de fonctionnalité expérimentale, udev essaie désormais de verrouiller un périphérique disque lorsqu’il exécute des évènements pour ce disque ou l’une de ses partitions. Des applications telles que les programmes de partitionnement de disque peuvent verrouiller le disque et réclamer temporairement la propriété du périphérique de cette façon et udev ignorera complètement tous les évènements pour ce disque ou cette partition. Si le disque a été ouvert en écriture, la fermeture déclenchera une analyse de la table de partition. Ce comportement est dorénavant activé par défaut ; s’il s’avère qu’il cause d’importants problèmes, nous pourrions l’activer uniquement pour quelques périphériques particuliers ou le désactiver complètement. Ce comportement ne prend pas en compte les périphériques virtuels (device-mapper).

Des unités mount temporaires peuvent maintenant être créées par les interfaces de programmation (API) du bus.

Un bout de code tmpfiles pour recréer la structure la plus élémentaire de /var est maintenant disponible. Il est suffisant pour créer le lien symbolique /var/run → /run et créer une série de répertoires structurels. Ça permet au système de démarrer avec un /var vide ou volatile. Évidemment, si grâce à ce changement le système d’exploitation de base est dorénavant capable de faire face à un /var volatile, tous les services utilisateurs n’y sont pas encore prêts. Cependant, nous espérons que tôt ou tard, de nombreux démons de services seront modifiés en amont, de façon à créer automatiquement au démarrage les répertoires nécessaires dans /var, s’ils devaient manquer. Il s’agit d’un premier pas vers un système sans état qui nécessite uniquement une image de la distribution sur /usr pour démarrer.

systemd-nspawn dispose désormais d’une nouvelle option --tmpfs= pour monter une instance tmpfs vide sur un répertoire particulier. C’est particulièrement utile pour la reconstruction automatique de /var (voir ci‐dessus), en passant --tmpfs=/var.

Le groupe floppy [N. D. T. : disquette] qui possédait les périphériques /dev/fd* n’est plus utilisé. Le groupe disk est utilisé à la place. Les distributions devraient probablement déconseiller l’utilisation de ce groupe.

Version 215

Beaucoup de travail pour rendre fonctionnels la remise aux paramètres d’usine, les systèmes sans état et les mises à jour hors‐ligne. Beaucoup de travail autour de networkd (serveur DHCP 4 !), enfin coredumpctl est maintenant vraiment utile.

Outils en ligne de commande

Cette fois‐ci, deux nouvelles commandes :

systemctl is-system-running : permet de vérifier l’état général du système, par exemple s’il a fini de démarrer et est pleinement opérationnel ;
la nouvelle page man file-hierarchy(7) contient une version raccourcie et modernisée de l’organisation du système de fichiers attendue par systemd, semblable à la spécification FHS ou la page de man hier(5). Le nouvel outil systemd-path(1) a été ajouté pour afficher plusieurs de ces chemins concernant la machine locale et l’utilisateur local.

Par exemple, systemd-path retourne chez moi :

temporary: /tmp
temporary-large: /var/tmp
system-binaries: /usr/bin
system-include: /usr/include
system-library-private: /usr/lib
system-library-arch: /usr/lib
system-shared: /usr/share
system-configuration-factory: /usr/share/factory/etc
system-state-factory: /usr/share/factory/var
system-configuration: /etc
system-runtime: /run
system-runtime-logs: /run/log
system-state-private: /var/lib
system-state-logs: /var/log
system-state-cache: /var/cache
system-state-spool: /var/spool
user-binaries: /home/sinma/.local/bin
user-library-private: /home/sinma/.local/lib
user-library-arch: /home/sinma/.local/lib/x86_64-linux-gnu
user-shared: /home/sinma/.local/share
user-configuration: /home/sinma/.config
user-runtime: /run/user/1000
user-state-cache: /home/sinma/.cache
user: /home/sinma
user-documents: /home/sinma/documents/
user-music: /home/sinma/musique/
user-pictures: /home/sinma/images/
user-videos: /home/sinma/vidéos/
user-download: /home/sinma/téléchargements/
user-public: /home/sinma/
user-templates: /home/sinma/modèles
user-desktop: /home/sinma/
search-binaries: /usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/sinma/.cabal/bin
search-library-private: /home/sinma/.local/lib:/usr/local/lib:/usr/lib
search-library-arch: /home/sinma/.local/lib/x86_64-linux-gnu:/usr/lib
search-shared: /home/sinma/.local/share:/usr/share:/usr/share:/usr/local/share
search-configuration-factory: /usr/local/share/factory/etc:/usr/share/factory/etc
search-state-factory: /usr/local/share/factory/var:/usr/share/factory/var
search-configuration: /home/sinma/.config:/etc

Et deux mises à jour :

machined a été mis à jour pour exporter la version du système d’exploitation d’un conteneur (lue depuis /etc/os-release/ et /usr/lib/os-release) ; cette information est disponible via machinectl status ;
l’option -H de systemctl (permettant de se connecter à une machine distante exécutant systemd) a été étendue pour pouvoir se connecter à un conteneur spécifique de l’hôte. Par exemple, systemctl -H root at foobar:waldi permet de se connecter en tant que super utilisateur root de la machine foobar directement au conteneur_waldi_. Notez que, pour l’instant, il faut s’authentifier en tant que super utilisateur root pour que ça marche, puisqu’entrer dans un conteneur est une opération privilégiée.

systemd-coredump

systemd-coredump est l’outil qui gère les vidanges mémoires (core dumps), c’est‐à‐dire le contenu de la mémoire du programme avant son plantage.

Le comportement de systemd-coredump a pas mal changé : il génère dorénavant automatiquement une trace d’appel enregistrée dans le journal pour toutes les vidanges système (grâce à la bibliothèque libdw des elfutils). De plus, il enregistre maintenant les vidanges système directement sur le disque (sous /var/lib/systemd/coredump, si possible dans un format compressé), au lieu de les enregistrer dans le journal. Un nouveau fichier de configuration /etc/systemd/coredump.conf a été ajouté pour configurer les autres paramètres de systemd-coredump.

On utilise la commande coredumpctl pour consulter les informations collectées par systemd-coredump. Elle a été enrichie de deux nouvelles options : info, pour afficher les détails de la vidange système choisie, et -1, pour afficher uniquement les informations de la plus récente vidange au lieu de l’ensemble des entrées. En outre, vu que l’outil est utile de façon générale, le préfixe systemd- lui a été retiré. Les distributions qui veulent maintenir la compatibilité avec l’ancien nom devraient ajouter un lien symbolique de l’ancien nom vers le nouveau.

Pour finir, l’option SplitMode= de journald est maintenant uid par défaut. Cela signifie que les utilisateurs non privilégiés peuvent accéder à leurs propres coredumps avec coredumpctl, sans restrictions.

Unités

Trois nouveaux paramètres pour les unités services :

RestartForceExitStatus= : si configuré avec une série de signaux de sortie ou de valeurs de retour de processus, le service sera relancé si le processus du démon principal se termine avec l’un d’entre eux (quelle que soit l’option Restart=) ;
dans la section [Install], DefaultInstance= : pour définir l’instance par défaut à démarrer, si une unité modèle est activée sans instance spécifiée (normalement on a service@instance — par exemple, dhcpcd@[interface] ou openvpn@[nom_configuration_VPN] —, mais on peut avoir service sans @instance) ;
ConditionNeedsUpdate= : démarre seulement les unités lorsque /etc ou /var sont plus « anciens » que les ressources de la distribution installée dans /usr. Elle est utile pour reconstruire ou mettre à jour /etc au redémarrage après une mise à jour hors‐ligne du répertoire /usr ou une remise aux paramètres d’usine. Les services qui veulent démarrer une seule fois après une mise à jour ou une remise à zéro devraient utiliser cette condition et se lancer eux‐même avant le nouveau systemd-update-done.service, qui marquera les deux répertoires comme totalement à jour. Un certain nombre de fichiers de services utilisant cette modification ont été ajoutés pour reconstruire la base de données matérielle de udev, le catalogue de messages de journald et le cache du chargeur de bibliothèques dynamiques (ldconfig). L’outil systemd-sysusers décrit plus haut fait déjà usage de cette nouveauté. Avec ces éléments en place, il est possible de démarrer proprement un système d’exploitation minimal avec un répertoire /etc vide. Pour plus d’informations sur le sujet, voir ce récent journal de Lennart.

Il y a aussi une nouvelle option pour les unités .mount, SloppyOptions=. Si elle est activée, cette dernière utilise l’option -s de mount(8) (traitement permissif des options de montage inconnues).

De plus, la nouvelle cible cryptsetup-pre.target peut être utilisée par les services qui doivent s’exécuter et se terminer avant que le premier conteneur chiffré LUKS ne soit configuré.

Réseau

Trois changements concernant systemd-network :

prise en charge d’un serveur DHCPv4 minimal (en plus de l’actuel client DHCPv4), des clients DHCPv6 et des sollicitations client de routeur IPv6. Le client DHCPv4 gère désormais les routes statiques données par le serveur. Notez que la section [DHCPv4] des anciennes versions de systemd-networkd a été renommée en [DHCP] et qu’elle est également utilisée par le client DHCPv6. Les fichiers .network utilisant les paramètres de cette section devraient être mis à jour, bien que la compatibilité soit maintenue. En option, le nom d’hôte du client peut maintenant être envoyé au serveur DHCP ;
gestion des réseaux virtuels VXLAN, ainsi que TUN/TAP et les périphériques factices ;
allocation automatique de plages d’adresses pour les interfaces en utilisant groupe de d’adresses (pool) pour tout le système. C’est utile pour la gestion dynamique de nombreuses interfaces depuis un fichier de configuration pour un seul réseau, en particulier pour assigner des adresses IP correctes aux liens veth de nombreuses instances de nspawn.

Enfin, les noms d’interfaces réseau prédictibles de udev font désormais usage de l’attribut dev_port de sysfs, introduit dans Linux 3.15, à la place de dev_id : cela permet de distinguer les ports des mêmes fonctions PCI. dev_id devrait être utilisé uniquement pour les ports utilisant la même adresse matérielle, d’où la nécessité de dev_port.

Remise du système aux paramètres d’usine

Le nouvel outil systemd-sysusers est capable de créer les utilisateurs et groupes du système dans /etc/passwd et /etc/group en se basant sur les définitions des utilisateurs et groupes déclarés statiquement dans /usr/lib/sysusers.d/. C’est utile pour réinitialiser un système aux paramètres d’usine et pour les systèmes volatiles qui démarrent avec un répertoire /etc vide, et qui nécessitent les utilisateurs et groupes du système tôt dans le processus de démarrage. systemd fournit deux fichiers dans sysusers.d/ par défaut pour les utilisateurs et groupes indispensables à systemd et au cœur du système d’exploitation.

Un nouveau bout de code tmpfiles a été ajouté pour reconstruire les fichiers essentiels dans /etc au démarrage, s’ils sont manquants.

Une directive pour s’assurer du nettoyage automatique de /var/cache/man/ a été supprimée de la configuration par défaut. Cette instruction devrait dorénavant être fournie par l’implémentation de man. Les modifications nécessaires ont été apportées à l’implémentation de man‐db. Notez que vous devez mettre à jour votre implémentation de man vers une version qui fournit cette instruction, sans quoi le nettoyage automatique de /var/cache/man n’aura pas lieu.

Le fichier /etc/os-release doit maintenant être déplacé vers /usr/lib/os-release (un lien symbolique de l’ancien chemin au nouveau est automatiquement créé). /usr/lib est plus approprié pour accueillir ce fichier car il décrit le système fourni dans /usr, et pas la configuration stockée dans /etc.

tmpfiles gère désormais une nouvelle directive L+ qui crée un lien symbolique, mais, contrairement à L, elle efface d’abord le fichier pré‐existant, le cas échéant, ou si le lien symbolique ne pointait pas au bon endroit. De façon similaire, des directives b+, c+ et p+ ont été ajoutées, pour créer des périphériques blocs, caractères, ainsi que des files d’attente FIFO dans le système de fichiers, supprimant éventuellement n’importe quel fichier de type différent.

Pour les directives L, L+, C et C+ des tmpfiles, le dernier champ argument, utilisé jusque‐là pour spécifier la source du lien symbolique ou de la copie, est maintenant optionnel. S’il est omis, le même fichier est copié depuis /usr/share/factory/ et suffixé du chemin de destination. C’est utile pour peupler le répertoire /etc de fichiers essentiels, en les copiant depuis les réglages de la distribution fournis dans /usr/share/factory/etc.

Une nouvelle commande systemctl preset-all permet de remettre les paramètres de toutes les unités de service à leurs valeurs par défaut. Une nouvelle option --preset-mode= a de même été ajoutée pour contrôler si seules les opérations activées ou désactivées doivent être exécutées.

Lorsque le système démarre avec un répertoire /etc vide, l’équivalent de systemctl preset-all est exécuté tôt au démarrage pour s’assurer que tous les services par défaut sont activés après une réinitialisation aux paramètres d’usine.

Sécurité

systemd-nspawn filtrera dorénavant par défaut une série d’appels système pour les conteneurs, parmi lesquels, ceux requis pour charger les modules noyau, les accès directs aux ports d’entrée‐sortie x86, le contrôle du fichier d’échange (swap) et kexec. Mais surtout, open_by_handle_at() est dorénavant interdit aux conteneurs, fermant ainsi une faille similaire à celle de Docker récemment débattue, à propos de l’accès aux fichiers sur les arborescences auxquelles les conteneurs ne devraient pas avoir accès. Notez que nous ne garantissons par la sécurité de nspawn (ceci est explicitement documenté dans le manuel). Il s’agit donc juste de la solution à l’un des problèmes les plus évidents.

Autres

Le groupe input a été ajouté et tous les nœuds de périphériques d’entrée sont assignés à ce groupe. C’est utile pour les logiciels système qui veulent avoir accès aux périphériques d’entrée. Cela complète ce qui a déjà été fait pour les groupes audio et video.

Les nœuds de périphériques /dev/loop-control et /dev/btrfs-control appartiennent désormais au groupe disk par défaut.

De nouvelles options pour la ligne de commande du noyau ont été ajoutées : systemd.wants= (pour ajouter des unités additionnelles pendant le démarrage), systemd.mask= (pour masquer des unités particulières au démarrage) et systemd.debug-shell (pour activer le shell de débogage sur tty9).

Le nettoyage périodique automatique de $XDG_RUNTIME_DIR n’est plus fait, car c’est devenu inutile. En effet, le dossier a maintenant une limite de taille par utilisateur et est nettoyé à la déconnexion.

Aller plus loin

systemd version 212 (163 clics)
systemd version 213 (43 clics)
systemd version 214 (42 clics)
systemd version 215 (255 clics)

# list-machines ?

Posté par madhatter (site web personnel) le 06 octobre 2014 à 11:14. Évalué à 6.

Salut,

Une nouvelle commande list-machines a été ajoutée à systemctl. Elle liste tous les systèmes d’exploitation dans un conteneur ainsi que leurs états (voir le point ci-dessus), si systemd est utilisé dans ces conteneurs.

Je ne connais pas encore suffisamment systemd pour avoir un avis tranché, je le découvre en ce moment sur ma Debian et à travers les récentes dépêches sur systemd pour les administrateurs (merci à leurs auteurs), mais, même si après tout pourquoi pas, je me demande quand même pourquoi systemd prend en charge cette fonctionnalité ?

Quel est l'intérêt ? Pourquoi ré-inventer une partie de quelque chose qui existe déjà (les outils fournis par lxc, l'api libvirt…) et l'intégrer à un projet qui de mon point de vue n'a pas grand chose à voir ? Je ne trouve pas logique de faire appel à un utilitaire de systemd pour gérer mes conteneurs (même si systemd gère les cgroup en arrière-plan et donc par extension, les-dits conteneurs).

Je lis beaucoup les commentaires sur les nombreuses discussions à propos de systemd et même si - je le répète - mon avis n'est pas fait, force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire (un futur remplaçant d'emacs peut-être ? :D) semble justifié.

Je ne dis pas que c'est une mauvaise chose pour autant, mais j'imagine que ça doit au moins faire plus de code à maintenir, plus de bug potentiels et donc plus de boulot.

Au final, même si du peu que j'en ai vu, j'aime bien ce qu'apporte systemd - la rapidité du boot notamment - j'ai l'impression de perdre aussi un peu de cette philosophie d'Unix qui disait que les programmes faisaient peu de choses mais le faisaient bien et que leurs combinaisons permettaient de faire des choses plus complexes.

There is no spoon...
- [^] # Re: list-machines ?
  
  Posté par freeze le 06 octobre 2014 à 11:27. Évalué à 8.
  
  Je pense que ça vient de deux aspects:
  - Comme tu le dis, systemd est le royaume des cgroups, donc autant y aller jusqu'au bout et donc incorporer LXC (les fonctionnalités, pas le binaire)
  - Ensuite, avec la mode du cloud, on aime avoir des services qui démarrent dans tous les sens, dans des sandbox etc, donc on aimerait pouvoir démarrer des conteneurs aussi facilement que des services classiques.
  
  Avec ce point de départ, il y a la solution classique: on démarre lxc/docker depuis systemd, et puis il a la solution systemd, on fusionne (j'imagine en espérant profiter des synergies).
  
  Effectivement, la question au bout du compte c'est dans cette situation LXC sert-il encore à quelque chose ? Docker a au moins quelques autres cordes à son arc avec les dépots et les layers, mais je suppose que ça sera aussi intégré à systemd 220 ;)
- [^] # Re: list-machines ?
  
  Posté par esdeem le 06 octobre 2014 à 11:29. Évalué à 10. Dernière modification le 06 octobre 2014 à 11:32.
  
  force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire […]
  
  On va te rétorquer que ce n'est pas systemd qui le fait, en omettant soigneusement de distinguer l'exécutable de « l'écosystème systemd », si j'ose l'appeler ainsi.
  Toutes les discussions sur le sujet confondent joyeusement les deux et partent (c|quen)ouille à cause de cette indistinction.
  
  0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
  - [^] # Re: list-machines ?
    
    Posté par barmic le 06 octobre 2014 à 11:59. Évalué à 9.
    
    Peut être que Lennart n'a pas était très malin (ou est un gros trolleur) et aurait du appeler l'init "startd" et le projet systemd. Pour éviter les confusions et voir que systemd est comme sysctl pas portable mais donnant accès aux fonctionnalités du noyau.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: list-machines ?
      
      Posté par gnx le 06 octobre 2014 à 12:06. Évalué à 0.
      
      Pour cela, il aurait fallu qu'il ait une idée d'où il voulait aller, et je ne crois pas que ç'ait été le cas.
      - [^] # Re: list-machines ?
        
        Posté par kursus_hc le 06 octobre 2014 à 18:49. Évalué à 8.
        
        Je crois au contraire qu'il sait exactement où il va.
        
        [^] # Re: list-machines ?
        
        Posté par gnx le 06 octobre 2014 à 19:35. Évalué à 2.
        
        Maintenant, très probablement. Au départ, j'en suis beaucoup moins convaincu.
        
        [^] # Re: list-machines ?
        
        Posté par ariasuni le 06 octobre 2014 à 21:32. Évalué à 8.
        
        À mon avis, s’il n’avait pas su où il allait, vu toutes les oppositions à systemd, il serait allé droit dans le mur. Au contraire, je pense qu’il sait pertinent où il va depuis le début (sauf qu’il ne se doutait probablement pas que le projet systemd allait compter autant de composants différents).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: list-machines ?
        
        Posté par gaaaaaAab le 07 octobre 2014 à 10:22. Évalué à 5.
        
        Pour vous départager, autant aller voir la source
        
        [^] # Re: list-machines ?
        
        Posté par kursus_hc le 08 octobre 2014 à 03:43. Évalué à 8.
        
        C'est quoi cette façon d'apporter la preuve par les faits ? T'es nouveau ici ?!
        
        [^] # Re: list-machines ?
        
        Posté par gaaaaaAab le 08 octobre 2014 à 04:07. Évalué à 2.
        
        C'est quoi cette façon d'apporter la preuve par les faits ?
        
        Tu noteras que je n'ai pas donné mon avis, mais simplement un lien. Je ne connais pas suffisamment systemd pour déterminer s'il y a une grande distance entre ce post et ce que systemd est aujourd'hui (et puis c'était un peu long, j'ai plutôt survolé. Possible que je relise plus en profondeur à l'occasion).
        
        Du coup, tout va bien, je suis sûr qu'il reste largement de quoi s'écharper sur son interprétation !
        
        [^] # Re: list-machines ?
        
        Posté par Anonyme le 10 octobre 2014 à 12:53. Évalué à 4.
        
        Il savait où il allait sur le systeme d'init, mais il n'imaginait pas forcement au départ que le projet systemd allait évoluer pour etre beaucoup plus qu'un simple systeme d'init.
- [^] # Re: list-machines ?
  
  Posté par ʭ ☯ le 06 octobre 2014 à 15:57. Évalué à 8.
  
  Comme toujours : soit c'est une bonne idée, et tout le monde va s'en servir, soit ça va être oublié, puis enlevé. De quel droit moquons-nous les choix de l'équipe de systemd? Pour ma part, je les paye pas sur leur projet…
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: list-machines ?
  
  Posté par Misc (site web personnel) le 06 octobre 2014 à 19:13. Évalué à 8.
  
  La différence est que libvirt ne va lister que les choses qui sont managés par libvirt, la ou systemd va lister les choses ou systemd tourne. Cad que si tu lances un container à la main avec lxc, docker ou autre, ça va apparaitre. Il faut voir ça comme un espace de ps pour les containers, la ou libvirt va gérer bien plus de choses et requiert que tout soit fait par le daemon de libvirt.
  
  En ce sens, systemd va être plus léger et offre juste une information qui découle du tracking des processus, information qui est la par design, et parce que ç'est pas trop compliqué de la récolter.
# un message de lennart

Posté par jcnewb le 06 octobre 2014 à 12:25. Évalué à 10.

https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/J2TZrTvu7vd
- [^] # Re: un message de lennart
  
  Posté par gnx le 06 octobre 2014 à 12:38. Évalué à -10.
  
  C'est vraiment lui qui écrit ça ??? Donc, il est entouré de trous du cul et de malades mentaux, et le pire d'entre eux est Linus Torvalds. Bien, bien, bien…
  - [^] # Re: un message de lennart
    
    Posté par jcnewb le 06 octobre 2014 à 12:42. Évalué à 9.
    
    Recently, people started collecting Bitcoins to hire a hitman for me (this really happened!). Just the other day, some idiot posted a "song" on youtube, a creepy work, filled with expletives about me and suggestions of violence. People post websites about boycotting my projects, containing pretty personal attacks. On IRC, people /msg me sometimes, with nasty messages, and references to artwork in 4chan style. And there's more. A lot more.
    
    wow
    - [^] # Re: un message de lennart
      
      Posté par Adrien le 06 octobre 2014 à 13:11. Évalué à 10.
      
      En fait, la bashing anti-systemd/lennart devient la minute de la haine de beaucoup de gens dans le libre…
      - [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 06 octobre 2014 à 19:21. Évalué à 9.
        
        Beaucoup de gens, je sais pas. J'ose croire qu'il y a beaucoup plus de gens qui s'en foutent, et qu'on ne prends pas les proportions de la taille du groupe. IE, 100 personnes apparaissent comme beaucoup pour un individu, mais si c'est sur un groupe de 100 000, c’est rien. Peut être qu'il y a beaucoup, peut être qu'il y a pas une majorité, mais je me garderais bien de caractériser un groupe entier alors qu'autour de moi, les actions correspondent pas à ce que je vois ailleurs. Et je pense pas que les gens autour de moi soient différents.
        
        Bien sur, une poignée de gens suffit à rendre la vie très dur, voir à pousser des gens au suicide ( exemple, FT, Peugeot, etc ). Il suffit d'une personne motivé pour que ça devienne du harcèlement ( parfois sans se rendre compte de la gravité, par manque d'empathie ou d'autre raisons ), alors en effet un petit groupe peut vite submergé quelqu'un.
        
        [^] # Re: un message de lennart
        
        Posté par anaseto le 07 octobre 2014 à 10:14. Évalué à 3. Dernière modification le 07 octobre 2014 à 10:15.
        
        Je suis d'accord avec toi. Je comprends que Lennart, vu sa position de victime en l'occurrence, en vienne à généraliser (je pense n'importe qui de normalement constitué serait énérvé à sa place), mais je n'ai pas du tout l'impression de rencontrer statistiquement cette "haine" dans la communauté, et je ne pense pas que ce soit quelque chose de généralisé.
        
        D'ailleurs, pour ce qui est de Gentoo qu'il critique, systemd est utilisable avec depuis longtemps, ce qui prouve qu'il n'y a pas de rejet généralisé ; certains sont peut-être énérvés parce que systemd leur complique la tâche : normal, Gentoo se veut d'offrir le plus de choix possible, donc un système d'init en plus, ça fait un choix de plus, donc du travail en plus, mais c'est à Gentoo de s'en sortir avec sa philosophie. Ceci dit, je n'ai pas l'impression que ceux qui bossent pour d'autres solutions soient "haineux". D'ailleurs, suivant les besoins et ce qu'on demande d'un système d'init, toute cette histoire n'a pas forcément de sens, parce que si ce qu'on veut c'est un système d'init complètement basique qui ne fait que démarrer et arrêter des processus, il faut arrêter de troller parce qu'il ne faut pas grand monde pour le maintenir, faut juste voir le système d'init d'OpenBSD par exemple, le nombre d'éditions par an n'est pas énorme. Après, si on veut du Gnome et d'autres trucs, il faut assumer et développer les APIs qu'il faut, ce n'est pas la faute à systemd (tout au plus de Gnome, mais c'est à eux de voir le public qu'ils visent) ; certains ont commencé à coder. Et si ce qu'on veut c'est un système d'init complet, soit on choisit parmi l'existant, soit on fait le sien.
        
        Bref, je crois que la plupart des libristes ont compris, et que Lennart a juste eu la mauvaise chance de devenir connu à l'aide d'une solution technique qui ne faisait pas l'unanimité et a réussit, du coup, à devenir la cible de quelques aigris qu'on trouve dans toutes les communautés.
        
        [^] # Re: un message de lennart
        
        Posté par FantastIX le 07 octobre 2014 à 12:44. Évalué à 2.
        
        Bref, je crois que la plupart des libristes ont compris, et que Lennart a juste eu la mauvaise chance de devenir connu à l'aide d'une solution technique qui ne faisait pas l'unanimité et a réussit, du coup, à devenir la cible de quelques aigris qu'on trouve dans toutes les communautés.
        
        J'aurais été entièrement d'accord avec le reste de ta réponse (qui pour moi aborde le sujet d'un ton relativement neutre que j'apprécie beaucoup) si la dernière phrase ne me choquait pas à ce point. Je ne sais pas s'il faut interpréter cette dernière comme « ce sont les aigris qui tirent à bout portant sur [Lennart Poettering] » ou autre chose que j'ai du mal à définir.
        
        Le moins qu'on puisse dire c'est que son produit divise. Et quand la division est à ce point prononcée, il y a de quoi s'interroger, encore faut-il se poser les bonnes questions. Et classer les détracteurs de systemd dans la catégorie "râleurs" ou "aigris" est beaucoup trop facile, comme si, parce que "la critique est aisée", celle-ci devait nécessairement être non fondée.
        
        J'utilise Gentoo depuis 2004, année où je suis passé à GNU/Linux. J'applaudis et admire profondément le choix des mainteneurs à fournir autant d'efforts pour le support des deux systèmes; ils font tout leur possible et y arrivent, tant bien que mal. Et que M. Poettering en vienne à critiquer les responsables de cette distribution me heurte profondément, pas parce que c'est ma distribution préférée mais parce que eux qui sont derrière méritent le respect de ceux qui l'utilisent au moins autant que ce… morveux semble prétendre imposer le sien… qu'il ne gagnera sûrement pas en se comportant ainsi.
        
        Pour info, j'ai arrêté de lire son… message dès que je suis tombé sur les trucs du genre « [A] is full of [B] " avec B étant un qualificatif peu élogieux.
        
        [^] # Re: un message de lennart
        
        Posté par Jean-Philippe Garcia Ballester (site web personnel) le 07 octobre 2014 à 14:29. Évalué à 6.
        
        M. Poettering en vienne à critiquer les responsables de cette distribution me heurte profondément
        
        Ce ne sont pas les responsables de la distribution qu'il critique, mais la communauté en général.
        
        [^] # Re: un message de lennart
        
        Posté par FantastIX le 09 octobre 2014 à 11:26. Évalué à 2.
        
        Ce ne sont pas les responsables de la distribution qu'il critique, mais la communauté en général.
        
        En quoi cela fait-il une différence? Ceux qui sont derrière et ceux qui s'en servent ont une responsabilité, pas la même mais une responsabilité quoi qu'il en soit. Le ton de sa généralisation est à tout le moins critiquable.
        
        [^] # Re: un message de lennart
        
        Posté par Albert_ le 09 octobre 2014 à 14:51. Évalué à 2.
        
        Peut etre que il est aussi un "tout" petit peu responsable? Lorsqu'il y a une critique et qu'il repond: "Je vous emmerde je fais ce que je veux" ou lorsque qu'il met dbus dans le projet systemd en promettant de ne pas le lier et que c'est la premiere chose de faite, la encore on peut se dire que cela peut enerver quelques personnes.
        
        Apres les attaques personnelles ou les menaces de mort (si c'est vrai) c'est naturellement inacceptable mais que je sache on a encore le droit de critiquer, non?
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 14:37. Évalué à 6.
        
        Le moins qu'on puisse dire c'est que son produit divise. Et quand la division est à ce point prononcée, il y a de quoi s'interroger, encore faut-il se poser les bonnes questions.
        
        Argumente : en quoi il divise?
        Moi, je vois qu'il rassemble, et les rares "divisés" ne sont pas les personnes concernées par la maintenance de distro, elles ont juste trouvé un bouc missaire facile à leur incapacité à apprendre de nouvelles technologies, plutôt que d'accepter l'évolution.
        
        Perso, j'ai plutôt rarement vu un projet qui rassemble autant, et c'est d'ailleurs la seule raison pour laquelle les "anti" assez extrémistes sont visibles : à part les extrémistes, il n'y a personne de "divisé".
        
        Et classer les détracteurs de systemd dans la catégorie "râleurs" ou "aigris" est beaucoup trop facile, comme si, parce que "la critique est aisée", celle-ci devait nécessairement être non fondée.
        
        Argumente : d'après, c'est quoi alors qui fait que 1% (à la louche, mais ça doit être moins) des gens sont aussi violents dans leurs mots, et pas foule autre ne trouve à redire de son projet?
        
        Après, si pour toi "ne pas diviser" signifie ne jamais rien changer, forcément on va avoir du mal à discutter, faire du surplace voulant surtout dire mourir à terme.
        
        Sinon, tu ublies une chose aussi dans ton discours : personne ne force à utiliser systemd, tout le monde est libre de propsoer autre. Donc à part des râleurs et des aigris, j'ai du mal à voir qui est contre systemd. Je t'en prie, donne des raisons, et dit surtout pourquoi personne ne fait sérieusement une offre alernative, si ça divise autant que tu le dis.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 14:56. Évalué à 1.
        
        Argumente : en quoi il divise?
        
        Il semble qu'il y a des gens qui gueule contre son logiciel, il semble que ce soit pour ça qu'il a fait ce message. Mais non pour toi ces gens là n'existent pas. Lennart les vois mais pas toi.
        
        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 message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 15:01. Évalué à -1. Dernière modification le 07 octobre 2014 à 15:01.
        
        Tu montres que tu ne lis pas ce que j'écris.
        J'en parle pourtant clairement de ces gens.
        Si il faut être plus court : Diviser != se prendre quelques extrémistes dans la gueule, incapables de proposer une alternative (tu plaisantes, faudrait se mettre d'accord sur l'alternative) alors qu'on a 99.99% des gens contents.
        
        J'ai dit "argumente", pas de sortir n'importe quoi.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 15:08. Évalué à 1.
        
        L'important n'est pas le nombre, c'est la capacité à produire/nuire. Ils sont peut être pas nombreux, ils n'ont peut être pas de capacité à produire, mais ils ont de toute évidence une grosse capacité à nuire et ça leur donne une certaine importance (suffisante pour entailler assez correctement le moral d'un mec qui a le cuire assez épais - pour rappel le monsieur rigolait quand il y avait des pétitions contre son travail -).
        
        Tu peux les rabaisser ou les ignorer, mais ça ne les ferra pas disparaître pour autant.
        
        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 message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 15:14. Évalué à 2. Dernière modification le 07 octobre 2014 à 15:14.
        
        Je n'ai jamais dit le contraire.
        Mais ça n'a rien à voir avec le sujet (diviser) : comme tu dis, c'est une capacité de nuisance supérieure au nombre qu'ils sont, rien à voir avec la division de la communauté.
        
        Parler de division pour un des projets qui rassemble le plus, c'est simplement ne pas comprendre que les gens ont plus de pouvoir de nuisance qu'un apport au libre.
        
        Je redemande encore : en quoi ce projet divise? Tu n'as pas répondu.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 15:18. Évalué à 1.
        
        Je redemande encore : en quoi ce projet divise? Tu n'as pas répondu.
        
        Il y a ceux qui sont pour et ceux qui sont contre.
        
        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 message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 15:24. Évalué à 1. Dernière modification le 07 octobre 2014 à 15:26.
        
        Donc si une personne sur un million se dit contre, ça divise.
        Avec ta définition, tout projet divise.
        Super, on avance.
        
        Désolé, je ne prend pas ce genre d' "argument" qui signifie simplement qu'il est impossible de te faire dire qu'un projet rassemble. On ne change plus jamais rien alors, pour ne pas "diviser".
        Rassembler != avoir 100.00000000000000000% des gens avec toi.
        
        Donne-moi un projet qui ne divise pas suivant ta définiton.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 15:28. Évalué à 1.
        
        Aller on remonte le fil de commentaire…
        
        L'important n'est pas le nombre, c'est la capacité à produire/nuire.
        
        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 message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 15:32. Évalué à 1. Dernière modification le 07 octobre 2014 à 15:33.
        
        L'importance de x ne justifie pas de FUDer "Le moins qu'on puisse dire c'est que son produit divise."
        J'ai demandé des arguments pour cette phrase, pas pour autre chose, car c'est ça qui a été écrit.
        Tu évites de répondre à la question en deviant la conversation, et ça boucle…
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 16:16. Évalué à 3.
        
        systemd divise suffisamment pour que les développeurs mainstream et les packageurs se fassent copieusement insulté. De plus le consensus dont tu parle oublie joyeusement la guerre qu'il y a eu au sein du projet Debian par exemple.
        
        Bien tu va donner ton argument béton "ça ne représente que 1%" ouai peut être, ou pas. Le comité chez Debian n'a pas voté à l'unanimité par exemple. Ce n'est pas l'histoire de glands derrière leurs écrans, mais des gens qui font du logiciel, qui contribuent plus que toi et moi réunis. Il y a slackware. Il y a une partie des mainteneurs de Gentoo. Mais je présume que eux aussi ils ne représentent rien.
        
        Bref comme je l'ai dis dans le fait de diviser ce qui est intéressant c'est de voir pour chaque groupe si :
        
        ils sont nombreux : on va dire qu'ils sont 1% pour te faire plaisir
        
        ils ont une capacité à produire (le libre c'est une méritocratie ou pas ?) : c'est le cas d'une partie des mainteneurs de Debian qui étaient contre, d'une partie des mainteneurs de Gentoo et des contributeurs de Slackware)
        
        ils ont une capacité de nuisance : le journal montre que c'est le cas
        
        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 message de lennart
        
        Posté par LupusMic (site web personnel, Mastodon) le 07 octobre 2014 à 17:32. Évalué à -4.
        
        De plus, je tiens à préciser que je ne connais aucun ops (sysadmin) qui voit SystemD comme une bonne chose.
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 17:39. Évalué à 5. Dernière modification le 07 octobre 2014 à 17:41.
        
        C'est un coup monté de (je ne sais pas qui, à vous de mettre) pour conquérir le monde, c'est inutile mais les gens le développent et l'intégrent.
        tous ces admins sys dont tu parles, si ils sont si nombreux, pourquoi ils ne se cotisent pas pour avoir une distro sans systemd?
        Moi, je dirai que c'est parce que finalement c'est la pire des choses, à l'exception de toutes les autres choses (oui, je copie).
        
        On parlait de quoi déjà? Ah oui : des râleurs sur systemd, rien d'autre.
        
        J'attend toujours des arguments plutôt qu "bouh, on me change mes habitudes de vieux sysadmin, donc ce n'est pas une bonne chose". Toujours rien.
        
        [^] # Re: un message de lennart
        
        Posté par LupusMic (site web personnel, Mastodon) le 07 octobre 2014 à 18:18. Évalué à 1.
        
        Il existe encore des distributions sans SystemD, donc pas besoin de se cotiser. Mais ce que je vois surtout, c'est l'étude de migration vers des BSD pour éviter systemd.
        
        Tu sais très bien que les admin sys n'aiment globalement pas le changement, car ce qui était garanti ne l'est plus, et qu'il faut revalider tout les processus.
        C'est très important de permettre la conservation d'un système existant qui fonctionne. Quand je vois le mal qu'ont mes employeurs consécutifs, rien qu'à migrer des applications PHP, je me dis que le passage à SystemD va être très difficile. Et oui, migrer d'un CentOS à FreeBSD sera certainement moins douloureux pour un sysadmin que de basculer sous SystemD, qui brise les fondements d'Unix tels qu'ils sont globalement acceptés par ces professionnels.
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 07 octobre 2014 à 18:01. Évalué à 4.
        
        De plus, je tiens à préciser que je ne connais aucun ops (sysadmin) qui voit SystemD comme une bonne chose.
        
        J'en connais plein dans le cas contraire. Donc bon, le petit bout de la lorgnette c'est vite limité…
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par LupusMic (site web personnel, Mastodon) le 07 octobre 2014 à 18:21. Évalué à -5.
        
        Certes, ce ne sont que mes contacts, mais en même temps, qu'aucun n'entrevoit la possibilité de le mettre me rend prudent.
        
        Quels sont les arguments favorables à SystemD de tes collègues ?
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 18:30. Évalué à 4. Dernière modification le 07 octobre 2014 à 18:31.
        
        Quels sont les arguments favorables à SystemD de tes collègues ?
        
        Sérieusement, il n'y a pas eu assez de journaux/dépèches qui résume la situation?
        si tu souhaites savoir, c'est facile… LinuxFr est ton ami, entre autres.
        
        [^] # Re: un message de lennart
        
        Posté par LupusMic (site web personnel, Mastodon) le 07 octobre 2014 à 18:44. Évalué à -1.
        
        Tout ce que je lis ne met en exergue que des défauts. En effet, SystemD transpose à l'OS ce qui fait la complexité des frameworks de programmation, à savoir le découplage, l'injection de dépendances et un workflow event-driven. J'arrive plus ou moins à accepter le concept au niveau de la programmation d'applications complexes, bardées de tests, mais j'ai du mal à voir un avantage au niveau d'un OS, qui doit pour être manipulé sans risquer un comportement étrange rien que parce qu'un service lointain est désactivé pour une raison ou une autre.
        
        C'est pour ça que je pose la question, ça m'intéresse vraiment de comprendre comment des sysadmins peuvent voir cette explosion de la complexité de l'OS.
        
        [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 07 octobre 2014 à 20:13. Évalué à 6.
        
        La complexité existe déja. une infra moderne, redondante avec des firewalls, des loadbalancers, du puppet/chef, des containeurs, de la virtualisation, du cloud, du monitoring, c'est complexe.
        
        Donc au moins, systemd rajoute sur ça la standardisation dans les scripts et les features, ce qui est appréciable.
        
        [^] # Re: un message de lennart
        
        Posté par ariasuni le 08 octobre 2014 à 01:28. Évalué à 6. Dernière modification le 08 octobre 2014 à 01:29.
        
        Tout ce que je lis ne met en exergue que des défauts.
        
        Faudrait peut-être pas exagérer non plus (cf. les dépêches étiquettées [systemd_pour_les_admins](https://linuxfr.org/tags/systemd_pour_les_admins/public)).
        
        […] j'ai du mal à voir un avantage au niveau d'un OS, qui doit pour être manipulé sans risquer un comportement étrange rien que parce qu'un service lointain est désactivé pour une raison ou une autre.
        
        Je ne crois pas avoir lu ça dans les spécifications de systemd. Je ne pense pas que «systemd va forcément boguer» soit un bon argument (du moins, sans preuve).
        
        Note: j’en profite pour glisser que c’est systemd, et pas Systemd, SystemD, systemD, system D ou systemd d.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 08 octobre 2014 à 07:33. Évalué à 7.
        
        Tout ce que je lis ne met en exergue que des défauts.
        
        Ce que tu as un filtre très puissant!
        Il faut voir le nombre de textes qu'il y a dessus, il aut voir le débat chez Debian lors du choix de systemd… Bref, tu lis que ce que tu veux lire.
        
        J'arrive plus ou moins à accepter (…)
        
        Voila, tout est dit avec cette phrase : tu y es à reculons, en résistant, et non pas en regardant ce qqu'il peut t'apporter. CQFD.
        
        comment des sysadmins peuvent voir cette explosion de la complexité de l'OS.
        
        Les besoin de 2014 ne sont pas les besoins de 1980 Si tu as toujours des besoins de 1980, tu peux utiliser un OS de 1980 avec. De nos jours, on a des besoins plus complexes qu'en 1980 et tu ne l'acceptes pas, c'est tout.
        
        Rapportons ça aux voitures : une voiture, c'est un moteur et 4 roues, pourquoi tant de complexité? Ben pour y répondre, essaye une voiture de 1980 (confort, puissance, conso…). Pareil pour un OS (confort, puissance, conso…)
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 07 octobre 2014 à 18:44. Évalué à 8.
        
        Rétro-compatibilité avec les scripts
        
        Pouvoir arrêter un service de manière fiable grâce à l'utilisation par systemd des control groups
        
        La doc qui est clair et fournie (bien plus que pour SysV ou Upstart)
        
        La série "systemd for administrators" qui permet de se former à systemd et qui est très bien écrite
        
        Les capacités de gestion des ressources, de gestion des containers, et les fonctionnalités de sécurité, de pouvoir détecter la virtualisation simplement… (tout ça avant c'était du boilerplate code dans chaque script…)
        
        Et encore, ce ne sont que les plus cités…
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par gouttegd le 07 octobre 2014 à 22:11. Évalué à 4. Dernière modification le 07 octobre 2014 à 22:15.
        
        Il y a slackware. […] des contributeurs de Slackware
        
        Tu as un lien rapportant une prise de position des contributeurs de Slackware à propos de systemd ?
        
        Aux dernières nouvelles et à ma connaissance, Patrick Volkerding n’a simplement pris encore aucune décision.
        
        [^] # Re: un message de lennart
        
        Posté par Doug Le Tough (site web personnel) le 08 octobre 2014 à 04:20. Évalué à 1.
        
        À ma connaissance également il a explicitement indiqué qu'il n'intègrerait pas systemd tant qu'il n'aura pas été prouvé que c'est un système plus fiable que l'existant ou quand il n'aura pas le choix compte tenu de l'évolution globale (lu je ne sais plus où, probablement sur LQ).
        
        À l'heure actuelle aucune de ces deux conditions ne semble remplie.
        
        Et comme Pat n'est pas sans humour, le changelog de slackware-current du 1er avril 2014 contenait une mention stipulant l'intégration de systemd. Ça laisse entrevoir la position de Patrick Volkerding.
        
        En ce qui concerne la communauté Slackware, dont je fais modestement partie, elle ne regarde pas systemd du meilleur oeil pour la simple raison que, contrairement à ce qui a pu être écrit à droite ou à gauche, systemd ne respecte ni la philosphie Unix ni l'esprit KISS qui sont deux valeurs fondamentales pour la dite communauté.
        Il ne s'agit pas pour autant de refuser l'évolution mais au contraire de n'accepter l'évolution que si elle est positive sous tous ces aspects.
        
        Citation de Patrick Volkerding (2012, extraite de la page Wikipedia de systemd) :
        "Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well."
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 08 octobre 2014 à 06:50. Évalué à 2.
        
        contrairement à ce qui a pu être écrit à droite ou à gauche, systemd ne respecte ni la philosphie Unix ni l'esprit KISS qui sont deux valeurs fondamentales pour la dite communauté.
        
        Bullshit.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par Doug Le Tough (site web personnel) le 08 octobre 2014 à 07:09. Évalué à 1. Dernière modification le 08 octobre 2014 à 07:13.
        
        Bullshit
        
        Bel argumentaire.
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 08 octobre 2014 à 07:27. Évalué à 2.
        
        Oui, car cette "critique" infondée a déjà été rebutée mille fois sur LinuxFR - il suffit de s'informer.
        
        A ce stade, y'en a juste marre des personnes qui répètent des critiques qu'ils ont entendu sans même essayer systemd.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par Doug Le Tough (site web personnel) le 08 octobre 2014 à 12:16. Évalué à 2. Dernière modification le 08 octobre 2014 à 12:18.
        
        Et répéter un argumentaire n'en fait pas une vérité.
        J'ai beau relire cet argumentaire en faveur de systemd, je n'arrive pas à voir en quoi systemd est KISS.
        
        Je ne nie pas l'intérêt qu'il pourrait y avoir à revoir de fond en comble le processus d'initialisation de Linux, je dis simplement et d'autres avec moi que la manière dont essaye de le faire systemd n'est pas la bo^Wmeilleure.
        
        Je ne vais pas argumenter plus en profondeur dans un sous-fil trollogène mais je vais rebondire sur l'idée de consensus qui a été évoquée plus haut.
        
        On notera que Wayland qui est également une remise à plat d'un gros composant d'une distribution Linux ne suscite pas autant de crainte voire de répulsion qu'en suscite systemd. Pourtant alors qu'il va également bouleverser pas mal de choses, obliger à changer des habitudes, probablement obliger à recoder certaines applications, j'ai plutôt l'impression que tout le monde attend avec impatience sa première release.
        
        Comment expliquer cela ? Comment ce fait il qu'il n'y ait pas de cohortes de barbus à bretelles prêts à mourir pour la défense d'X11 ? L'argument qui veut que les réfractaires à systemd ne sont que des gens qui refusent l'évolution est totalement fallacieux. Les opposants à systemd ont aussi des arguments et ce sont également des arguments qu'on ne peut pas se contenter de balayer d'un revers de mains. À défaut d'être entendus ces arguments ont également été rabachés, ça n'en fait pas plus une vérité que ceux en faveur de systemd.
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 08 octobre 2014 à 12:55. Évalué à 8. Dernière modification le 08 octobre 2014 à 13:00.
        
        Je ne nie pas l'intérêt qu'il pourrait y avoir à revoir de fond en comble le processus d'initialisation de Linux, je dis simplement et d'autres avec moi que la manière dont essaye de le faire systemd n'est pas la bo^Wmeilleure.
        
        Rien que parce que l'existant ne sait pas arrêter un service proprement. Quand on en est là, il vaut mieux repartir de la base : avoir un coeur fiable (grâce aux control groups). Tout le reste de systemd en découle.
        
        Enfin, ça, et arrêter de copier/coller du boilerplate code dans tous les scripts, et arrêter d'avoir un script par logiciel par distribution (c'est intéressant pour vous de refaire toujours le même travail ?).
        
        On notera que Wayland qui est également une remise à plat d'un gros composant d'une distribution Linux ne suscite pas autant de crainte voire de répulsion qu'en suscite systemd.
        
        Tu rigoles ?
        
        Rien que dans la dernière dépêche sur Wayland on peut lire :
        "Wayland est installé d'office sur mon smartphone (Sailfish-OS) … Et perdre l'export-display comme le proposait Maemo5 de mon précédent terminal m'emmerde toujours autant. Mais bon perdre des fonctionnalités, qu'on utilisait couramment, est semble-t-il une nouvelle forme de progrès."
        
        Et avant on a pu lire :
        
        "Ma transparence réseau me sera enlevé lorsque je serais mort et enterré" (alors qu'elle n'existe plus depuis longtemps mais passons et qu'elle ne sert en rien les applications modernes…)
        
        "Je vais devoir recoder mon appli grâce à Wayland, merci Wayland" (alors que ça ne touche que les toolkits et qu'il y a une couche de compatibilité X<->Wayland)
        
        "Et BSD alors ? Xorg était un standard ! Rendez moi mon standard !" (très bien alors ne touchons surtout à rien. La stagnation, c'est tendance !)
        
        Ça peut aussi s'expliquer que l'usage de Wayland reste confidentiel et expérimental, alors que systemd est déjà dans Archlinux depuis 2 ans, dans Fedora depuis 3 ans, et s'étend aux reste des distributions très vite (Debian, Mageia, Ubuntu, …) . Bref, on compare des pommes et des oranges, là.
        
        Par ailleurs, comment peut on dire que systemd révulse alors qu'il est adopté par les distributions majeures ?
        
        Je dirais que plus il est adopté à cause de ses arguments techniques, plus ceux qui se fichent des arguments techniques se font entendre. Mais ce n'est pas pour autant eux qui décident.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par ariasuni le 08 octobre 2014 à 16:40. Évalué à 5.
        
        […] je dis simplement et d'autres avec moi que la manière dont essaye de le faire systemd n'est pas la bo^Wmeilleure.
        
        Le mieux est l’ennemi du bien. Il semblerait que la plupart des gens trouvent que c’est une nette amélioration par rapport aux systèmes précédents, donc il a été adopté un peu partout.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 08 octobre 2014 à 07:36. Évalué à 5. Dernière modification le 08 octobre 2014 à 07:37.
        
        Bel argumentaire?
        Le ciel est jaune. La terre est plate.
        A toi de me démontrer qu'il n'est pas jaune et que la terre n'est pas plate.
        Ou alors, il suffit de regarder, de se renseigner un minimum…
        
        Le manque d'argumentaire est chez celui qui attaque gratuitement.
        
        Bref, on te retourne le compliment (sérieux, il sufft de regarder un tout petit peu pour voir que tout est découpé proprement, et que c'est bien plus simple que les merdes de scripts SysV, tu ne fais que FUDer en montrant ta non connaissance de ce que tu n'aimes pas, certes c'est classique mais quand même…)
        
        [^] # Re: un message de lennart
        
        Posté par Doug Le Tough (site web personnel) le 09 octobre 2014 à 10:41. Évalué à -1.
        
        Bel argumentaire?
        Le ciel est jaune. La terre est plate.
        A toi de me démontrer qu'il n'est pas jaune et que la terre n'est pas plate.
        
        Le jaune est la couleur de la fleur de pissenlit. Le ciel n'est pas de la couleur de la fleur de pissenlit, il n'est donc pas jaune.
        
        Si la terre était plate :
        
        Ce serait un plan infini sur la surface duquel nous vivrions et nous serions incapable d'en faire le tour. Or nous en faisons le tour sans difficulté.
        
        Ce serait un plan fini présentant une arête à chacun de ses bords. Or il se trouve qu'après avoir fait le tout de la planète, l'Homme n'a pas trouvé trace d'arête ni précipice marquant une "fin du monde".
        
        À toi de me démontrer même sommairement que systemd est KISS.
        Si tu n'arrives pas à démontrer en quelques lignes qu'une application est KISS, alors elle n'est pas KISS. Point.
        Un espèce de machin qui fait tout et n'importe quoi, aussi modulaire soit-il n'est pas KISS.
        Un journal binaire même optionnel n'est pas KISS.
        etc.
        
        [^] # Re: un message de lennart
        
        Posté par Jean-Philippe Garcia Ballester (site web personnel) le 09 octobre 2014 à 11:20. Évalué à 2.
        
        En même temps, la définition de KISS, c'est un peu flou, non ? En quoi c'est KISS de lancer un interpréteur d'un langage turing-complet à chaque fois que tu veux démarrer un nouveau service ?
        
        [^] # Re: un message de lennart
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 12:58. Évalué à 3.
        
        En quoi c'est KISS de lancer un interpréteur d'un langage turing-complet à chaque fois que tu veux démarrer un nouveau service ?
        
        Parce que c'est complet, voilà.
        
        [^] # Re: un message de lennart
        
        Posté par ariasuni le 09 octobre 2014 à 12:07. Évalué à 4.
        
        Un journal binaire même optionnel n'est pas KISS.
        
        Et pour quelles raisons?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 12:38. Évalué à 4.
        
        l'Homme n'a pas trouvé trace d'arête ni précipice marquant une "fin du monde".
        
        Toi, tu ne connais pas encore Mix'Art-Myrys…
        
        [^] # Re: un message de lennart
        
        Posté par gouttegd le 08 octobre 2014 à 09:30. Évalué à 4.
        
        À ma connaissance également il a explicitement indiqué qu'il n'intègrerait pas systemd tant qu'il n'aura pas été prouvé que c'est un système plus fiable que l'existant ou quand il n'aura pas le choix compte tenu de l'évolution globale (lu je ne sais plus où, probablement sur LQ).
        
        Je demandais un lien. Parce que la seule intervention de Pat que je connaisse où il mentionne systemd, c’est celle à laquelle tu fais référence, et que je me permets de citer plus largement :
        
        Yeah, I see a few things coming down the line that may cause a shakeup to our usual way of doing things, and could force Slackware to become, well, perhaps less UNIX-like. I guess the two big ones that are on the horizon are Wayland and systemd. Whether we end up using them or not remains to be seen. It's quite possible that we won't end up having a choice in the matter depending on how development that's out of our hands goes. It's hard to say whether moving to these technologies would be a good thing for Slackware overall. Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle.
        
        Ça ne traduit certainement pas un enthousiasme débordant pour systemd comme on peut le voir par ici (où certains semblent croire que systemd va résoudre tous leurs problèmes), mais ça ne ressemble pas non plus à un refus catégorique. M’est avis qu’il attend de voir, tout simplement.
        
        Et j’ai déjà eu l’occasion de le dire, mais ceux qui comptent sur Slackware pour les « sauver » de systemd se mettent le doigt dans l’œil à mon avis s’ils s’imaginent que Pat va se coltiner à lui tout seul la maintenance d’une alternative à systemd.
        
        [^] # Re: un message de lennart
        
        Posté par Doug Le Tough (site web personnel) le 08 octobre 2014 à 12:32. Évalué à 3.
        
        Ça ne traduit certainement pas un enthousiasme débordant pour systemd comme on peut le voir par ici (où certains >semblent croire que systemd va résoudre tous leurs problèmes), mais ça ne ressemble pas non plus à un refus >catégorique. M’est avis qu’il attend de voir, tout simplement.
        
        Tout à fait, il attend de vérifier que systemd apporte une vraie solution à un vrai problème.
        Si c'est le cas il n'y a aucune raison à ne pas l'utiliser mais dans le doute il n'y a aucune raison de le faire.
        Comme beaucoup de slackeux, je partage ce point de vue pragmatique.
        
        Et j’ai déjà eu l’occasion de le dire, mais ceux qui comptent sur Slackware pour les « sauver » de systemd se mettent >le doigt dans l’œil à mon avis s’ils s’imaginent que Pat va se coltiner à lui tout seul la maintenance d’une >alternative à systemd.
        
        Là dessus on est d'accord et il sous-entend qu'en l'absence d'option alternative il s'y conformera. C'est comme ça que je le comprend.
        
        De mon point de vue, ce moment sera symbolique et marquera un tournant dans l'histoire de Linux et probablement, par effet de bord, dans celle de BSD.
        
        [^] # Re: un message de lennart
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 13:08. Évalué à 3.
        
        la maintenance d’une alternative à systemd.
        
        D'un autre coté, la maintenance d'un système d'init rudimentaire, efficace, compréhensible et éprouvé depuis plus de trente ans, ça doit pas être une grosse charge de travail. Surtout comparé au gazillion de fonctionnalités qui semblent devoir tomber dans le giron de systemd.
        
        Juste parce que LP fait du buzz et surfe sur la wave de la hype de l'informatique : « ouaou, c'est nouveau, donc ça doit être mieux. », genre iModerne, il faudrait complexifier à outrance le bouzin ?…
        
        [^] # Re: un message de lennart
        
        Posté par ariasuni le 09 octobre 2014 à 13:42. Évalué à 4. Dernière modification le 09 octobre 2014 à 13:45.
        
        D'un autre coté, la maintenance d'un système d'init rudimentaire, efficace, compréhensible et éprouvé depuis plus de trente ans, ça doit pas être une grosse charge de travail. Surtout comparé au gazillion de fonctionnalités qui semblent devoir tomber dans le giron de systemd.
        
        Il faudra demander aux mainteneurs de Arch Linux par exemple, qui ne ce sont pas précipités dessus, mais qui ont trouvé que c’était plus simple à maintenir avant que GNOME le nécessite (par exemple).
        
        Après c’est peut-être aussi lié à l’intégration d’udev dans le dépôt systemd, mais les développeurs udev ne ce sont pas fait absorbés contre leur gré par systemd hein, donc c’est aussi un peu de leur faute.
        
        Juste parce que LP fait du buzz et surfe sur la wave de la hype de l'informatique : « ouaou, c'est nouveau, donc ça doit être mieux. », genre iModerne, il faudrait complexifier à outrance le bouzin ?…
        
        Oh tiens, une attaque personnelle envers Lennart. Précisément ce qu’il dénonce.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 09 octobre 2014 à 13:59. Évalué à 2.
        
        Après c’est peut-être aussi lié à l’intégration d’udev dans le dépôt systemd, mais les développeurs udev ne ce sont pas fait absorbés contre leur gré par systemd hein, donc c’est aussi un peu de leur faute.
        
        IIRC, Arch est passé à systemd bien avant que udev soit dans le même dépôt que systemd.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par ariasuni le 09 octobre 2014 à 19:13. Évalué à 2.
        
        En vérité il était déjà dans Arch Linux mais pas par défaut, par ordre chronologique:
        
        1 juin 2012 udev fusionné à systemd arrive dans Arch
        
        13 octobre 2012: systemd par défaut sur les nouvelles installations
        
        4 novembre 2012: fin du support des scripts d’init
        
        4 février 2013: Suppression des scripts d’init
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 09 octobre 2014 à 19:04. Évalué à 7.
        
        D'un autre coté, la maintenance d'un système d'init
        rudimentaire, efficace, compréhensible et éprouvé depuis plus de
        trente ans, ça doit pas être une grosse charge de travail.
        Surtout comparé au gazillion de fonctionnalités qui semblent
        devoir tomber dans le giron de systemd.
        
        C'est parce que tu vois sysv comme étant juste le binaire d'init. C'est une vision tronqué, car ce qui est visé, c'est pas /bin/init, c'est surtout tout les initscripts, cad /etc/rc.d/rc.sysinit sur les RH-likes, et les /etc/rcS.d/ sur les debian likes.
        
        Et la, on rentre dans le truc velu qui va devoir se charger du lvm, du multipath, du raid, de fsck, de la crypto, des montages stateless, des quotas, de lancer la configuration initial, de divers nettoyages, etc. C'est juste en lisant les scripts de 600 lignes sur rhel6. ( sans les fonctions ou tu ramées 800 lignes de plus ). Et qui doit s'interfacer avec udev, avec le kernel. Et tout ces trucs bas niveau sont en general pas asynchrones pour un sou, donc tu attends, ou on contraire, sont asynchrones, et le shell avec ses primitives de threads fait des merveilles. Ah non, on me signale qu'il y a pas ça.
        
        C'est sur, maintenir un truc comme le DOS, c'est plus simple que Linux. Mais voila, ce que les gens veulent, c'est quelque chose comme Linux plus qu'un truc comme DOS.
        
        Si tu retires tout ce que tu ne veux pas, ça va aller plus vite et être plus simple, bien sur. Sauf que pour une distribution, tu va remplir les besoins que d'une minorité si tu fait ça, genre que des gens qui ont ton setup.
        
        [^] # Re: un message de lennart
        
        Posté par Moonz le 07 octobre 2014 à 19:43. Évalué à 3.
        
        systemd divise suffisamment pour que Gentoo se fasse chier à continuer de maintenir des solutions alternatives (alors qu’à priori maintenir l’upstream c’est pas leur boulot à la base).
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 07 octobre 2014 à 19:58. Évalué à 0. Dernière modification le 07 octobre 2014 à 19:59.
        
        systemd "divise" tellement qu'Archlinux, Debian, Ubuntu, Fedora, Mageia, RHEL, et d'autres y passent, ou y sont passé depuis longtemps.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 20:47. Évalué à 7.
        
        systemd "divise" tellement qu'Archlinux, Debian, Ubuntu, Fedora, Mageia, RHEL, et d'autres y passent, ou y sont passé depuis longtemps.
        
        Par longtemps tu entends pas avoir encore sorti de version stable avec c'est ça ? C'est pas parce que systemd est bien qu'il faut sortir des âneries pour le défendre. Systemd dans Debian ça a était 8 mois de guerre civile pour finir sur un vote qui était loin d'être un consensus.
        
        Pareil pour ubuntu, ils y sont passé contrains et forcé il y a moins d'un an (à la suite de la décision de Debian).
        
        Sincèrement, je suis pour systemd qui résoud un paquet de problème qu'aucune de ses alternatives ne sait même qu'imaginer. Mais c'est pas pour autant qu'il faut prétendre des choses fausses pour essayer de le défendre (la vérité 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: un message de lennart
        
        Posté par Zenitram (site web personnel) le 07 octobre 2014 à 21:16. Évalué à 0.
        
        Le choix de Debian et Ubuntu se sont basé sur des données technique, avec un concurrent sérieux. Rien à voir avec les anti-systemd.
        
        Et ce que tu appelle "guerre de tranchée", c'est simplement la démocratie : oui, on voit des discussion, et force est de constater que systemd a montré son consensus, sa supériorité technique qui a fait qu'il a été choise contre son concurrent (hint : qui n'est pas le système que souhaitent les anti-systemd, rigolo quand même non que les anti-systemd veuillent u ntruc que vraiment personne ne voulait, même lors du vote de Debian?) quoique tu veuilles penser.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 22:59. Évalué à 3.
        
        systemd a montré son consensus
        
        Ou pas. Un consensus c'est quand tout le monde se met d'accord. Le vote a était serré, donc même après 8 mois à dire qu'il était génial dans toutes les langues, il y a des gens (qui sont compétant et qui font partie de ceux qui travail) qui étaient contre. Ça n'est un consensus que dans ton monde.
        
        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 message de lennart
        
        Posté par ariasuni le 08 octobre 2014 à 01:32. Évalué à 5.
        
        Ou pas. Un consensus c'est quand tout le monde se met d'accord. Le vote a ~~était~~ été serré, donc même après 8 mois à dire qu'il était génial dans toutes les langues, il y a des gens (qui sont ~~compétant~~ compétents et qui font partie de ceux qui ~~travail~~ travaillent) qui étaient contre. Ça n'est un consensus que dans ton monde.
        
        Oui je me soigne, tout ça.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: un message de lennart
        
        Posté par xcomcmdr le 07 octobre 2014 à 21:48. Évalué à 8. Dernière modification le 07 octobre 2014 à 21:51.
        
        1.J'ai dit "y passent OU y sont passés depuis longtemps."
        
        2.Archlinux y est passé en septembre 2012. Plus de deux ans, je dirais que ça rentre dans la définition de "longtemps".
        
        3.Fedora y est passé en Mai 2011. C'est assez long pour toi, plus de 3 ans ?
        
        4.Il n'y a pas que Debian dans la vie !
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 07 octobre 2014 à 23:01. Évalué à 2.
        
        1.J'ai dit "y passent OU y sont passés depuis longtemps."
        
        Désolé j'ai vu trop vite (j'ai tendance à trouver surprenant les virgules avant un "ou" comme dans « c'est ça, ou c'est ça »).
        
        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 message de lennart
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 13:39. Évalué à 2.
        
        un paquet de problème
        
        Chic, une liste (cTMr) !
        
        [^] # Re: un message de lennart
        
        Posté par Anthony Jaguenaud le 08 octobre 2014 à 10:17. Évalué à 3.
        
        à part les extrémistes, il n'y a personne de "divisé".
        
        Ouai, alors là, tu m’insultes… je suis dubitatif sur le projet en lui même pour différentes raisons, mais me traiter d’extrémiste, je trouve que tu y vas un peu fort.
        
        Il semble confortable pour les « fan » de traité ceux qui ne suivent la sainte parole aveuglément de les traiter d’intégriste…
        
        J’aurais tendance à dire qu’il faut regarder le pour et le contre. Mais c’est parce que je suis intégriste !
        
        [^] # Re: un message de lennart
        
        Posté par Zenitram (site web personnel) le 08 octobre 2014 à 10:31. Évalué à -1.
        
        J’aurais tendance à dire qu’il faut regarder le pour et le contre.
        
        Justement : toutes les personnes vraiment concernées ont regardé, et choisi (de manière démocratique des projets, Debian ayant montré le plus de doutes mais ayant finalement choisi). Bizarrement, ce n'est pas accepté par certains qui pensent mieux savoir que les gens qui font les distros, personnes ayant pris la peine de se renseigner entre leurs besoins et les besoins de tous (et pas seulement une partie qui ne souhaite pas changer) leur utilisateurs…
        
        mais me traiter d’extrémiste
        
        Je ne sais pas exactement pour toi, je pensais globalement à tous ceux qui racontent 100x les mêmes conneries mêmes quand on leur a démontré le contraire.
        
        Il semble confortable pour les « fan » de traité ceux qui ne suivent la sainte parole aveuglément de les traiter d’intégriste…
        
        J'en ai pas grand chose à foutre de systemd, il est sous le capot. Dur d'être "fan".
        Répondre à ceux qui FUDent ne veut pas dire être fan, ne t'en déplaise.
        Et ce n'est pas "aveugle", c'est jsute se renseigner un minimum et se rendre compte en 5 minute que les "anti" disent des conneries dans leurs "arguments".
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 08 octobre 2014 à 10:43. Évalué à 4.
        
        toutes les personnes vraiment concernées ont regardé
        
        Note tout de même qu'ils n'y a pas que les packageurs qui sont concernés.
        
        Je ne sais pas exactement pour toi, je pensais globalement à tous ceux qui racontent 100x les mêmes conneries mêmes quand on leur a démontré le contraire.
        
        Toi faire de la généralisation à outrance ?! C'est bien la première fois.
        
        J'en ai pas grand chose à foutre de systemd, il est sous le capot.
        
        Ce n'est pas le cas pour tout le monde. Ton usage de la machine n'est pas celui de tout le monde (même s'il est peut être celui de la majorité).
        
        Dur d'être "fan".
        
        Dire que ceux qui sont contre sont des extrémistes c'est pas un peu, mais vraiment un tout petit peu de la stigmatisation abusive ?
        
        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 message de lennart
        
        Posté par Zenitram (site web personnel) le 08 octobre 2014 à 10:54. Évalué à -1. Dernière modification le 08 octobre 2014 à 10:55.
        
        Ce n'est pas le cas pour tout le monde.
        
        Et?
        Je parlais du fait que moi on me disais que j'étais fan.
        Evidement que ce n'est pas le cas pour tout le monde, et ce n'est pas le sujet de ce à quoi je répondais.
        Note que ceux qui font des trucs complexes (complexe != mes scripts à l'anciennes à ralonge pour faire un truc qui est simple avec systemd à partir du moment où on se renseigne) sont les plus fans de systemd…
        
        Dire que ceux qui sont contre sont des extrémistes c'est pas un peu, mais vraiment un tout petit peu de la stigmatisation abusive ?
        
        J'attend un vrai argument d'abord.
        Et pas un "c'était mieux avant", hein, le débat chez Debian était pas pour garder ce qu'il y avait avant, mais entre deux nouveautés, l'autre aurait autant fait râler les gens qui ne veulent pas que ça change.
        
        Bref, toujours pas d'arguments (des vrais), juste des plaintes sans fondement puis des plaintes qu'on ne prend pas aux sérieux les gens qui se plaignent sans fondements.
        
        [^] # Re: un message de lennart
        
        Posté par barmic le 08 octobre 2014 à 11:09. Évalué à 6.
        
        Bref, toujours pas d'arguments (des vrais), juste des plaintes sans fondement puis des plaintes qu'on ne prend pas aux sérieux les gens qui se plaignent sans fondements.
        
        D'arguments pour quoi ? Je suis comme toi j'en ai rien à faire de systemd. Je n'aime pas ta façon d'en parler et de rabaisser ceux qui ne l'apprécient pas, mais c'est tout.
        
        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 message de lennart
        
        Posté par FantastIX le 09 octobre 2014 à 11:13. Évalué à 3.
        
        Argumente : en quoi il divise?
        
        Déjà le fait que toutes les distributions ne l'ont pas intégré par défaut. Il ne fait donc pas l'unanimité. Dont Gentoo, par exemple.
        
        Perso, j'ai plutôt rarement vu un projet qui rassemble autant […]
        
        Si nous ne voyons pas les mêmes choses, tu en déduis quoi? Perso, je pourrais en déduire que tu te mets la tête dans le sable, ce qui arrive fréquemment à pas mal de monde, d'après ce que j'observe autour de moi. C'est une forme élémentaire d'auto-protection, il suffit d'observer la nature humaine. Mais comme je ne te connais pas en personne, je me garderais bien de conclure quoi que ce soit.
        
        J'ai dit: « Et classer les détracteurs de systemd dans la catégorie "râleurs" ou "aigris" est beaucoup trop facile […] »
        
        Argumente: […]
        
        Encore? Ça me paraît pourtant évident. N'est-il pas vrai que classer les détracteur d'un sujet X sans analyse supplémentaire est trop facile? Alors, si tu considères que tous les détracteurs de systemd sont des aigris et des réfractaires, vas-y, argumente à ton tour. Statistiquement, il est impossible que 100% de ces gens soient comme tu les décris.
        
        Tu sais, il est un dicton qui dit « on a ce qu'on mérite ». Je ne parle pas de M. Poettering, dans le paragraphe qui suit.
        
        Lorsque quelqu'un s'en-tête à marcher à contre-courant, il court le risque de s'attirer les foudres de ses comparses. Idem s'il s'évertue à vouloir changer les habitudes. Il subira probablement de vives critiques au départ mais celles-ci s'estomperont avec le temps, surtout si sa quête est noble. Si ce n'est pas le cas, alors il y a quelque chose qui ne va pas. Pointer du doigt les auteurs des critiques est un réflexe. Ce n'est pas le bon.
        
        Ceci n'est que sociologie et psychologie élémentaire. Ça te paraîtra limpide si tu observes les gens autour de toi.
        
        Que peut-on dire des libristes, sinon qu'ils marchent à contre-courant [de l'«ordre» établi]? Ne peut-on pas dire qu'ils remettent en cause les fondements de cet «ordre» (au sens général)?
        
        Nous sommes des personnes qui avons choisi la direction que nous suivons. Nous avons décidé la direction qui nous offrait le choix, en nous permettant de retrouver le contrôle de la machine. Pour ma part, j'ai fait ce choix parce que c'est ma personnalité; les principes derrière le logiciel libre étaient les miens bien avant que j'abandonne Windows. Que je sois seul dans ce cas est impossible.
        
        Pour revenir à systemd, il est logique d'affirmer que, dans ses détracteurs, il en existe qui correspondent à ce type de personnes (je ne parle pas de moi): mûrs, réfléchis et respectables. Même s'il n'en existe qu'un seul qui s'y oppose, il mérite d'être entendu et ses arguments pris en compte, non? Je n'ai peut-être aucune preuve et c'est juste de la théorie — auquel cas, à toi de me prouver qu'elle est fausse — mais elle me sert à ce qui va suivre.
        
        Exemple?
        
        Ok, technique, maintenant.
        
        J'ai du mal à comprendre la pertinence des modules comme le démon journald, le serveur DHCP, le module NTP (il y en a sans doute d'autres, je ne les connais pas). Pourquoi?
        
        Si systemd (le paquet complet) se veut une suite d'outils, pourquoi pas. Mais encore une fois, l'argument classique qu'on observe c'est que le logiciel libre permet d'améliorer les logiciels existant, que ce soit par un fork ou des contributions; n'est-ce pas ce qui est vivement recommandé? La présence de ces modules dans systemd ne constitue ni une amélioration ni une contribution; il s'agit d'une ré-écriture. Et en regard du nombre de modules, croissant (au beurre, pour moi), on peut se demander pourquoi n'avoir pas contribué avec les développeurs des paquets existants pour les améliorer. Et, si refus il y eut, d'où qu'il vienne, doit-on nécessairement en déduire que c'est à cause d'un problème d'ego?
        
        En voyant la description de systemd, on comprend que ce que l'auteur a voulu est une ré-écriture complète du système de démarrage. Pas une amélioration ni une contribution. Les modules qu'il intègre et que je viens de citer sont aussi une ré-écriture complète. Alors doit-on vraiment s'étonner de ceux qui parlent du syndrôme NIH? Doit-on aussi les considérer d'emblée comme des contestataires amers? Et les programmes existants, sont-ils aussi mauvais qu'ils durent être ré-écrits?
        
        Dans le détail, à présent.
        
        Lorsque tu écris un programme pour une fonctionnalité, tu le fais à fond ou tu ne le fais pas. Un mini-serveur DHCP est un oxymore dans le monde UNIX. S'il fait une tâche, qu'il la fasse à fond. Or un serveur DHCP qui n'inclut pas toutes les specs n'est pas un serveur DHCP — personnellement, quand j'ai besoin d'un tel serveur, en particulier pour mes environnements virtuels, je me fie à dnsmasq, développé par une équipe de personnes extrêmement compétentes. (Et ne me demande surtout pas d'argumenter là-dessus, s'il te plaît. Sauf pour rire, bien sûr.) Donc, si on se réfère à ce principe, qui, rappelons-le, fait aussi partie, si j'ai bien compris, des nombreux autres arguments énoncés par la-bande-à-UNIX, un serveur DHCP minimal est absurde au pire et totalement inutile au mieux.
        
        Je pars aussi du principe que ce module DHCP n'est pas le seul dans systemd à répondre à cette description. Personne ne m'impose de m'en servir, me diras-tu sans doute. Et je te répondrai que la question n'est pas là: le module, inutile, est quand-même présent dans systemd, même si je ne m'en sers pas. Il a demandé des ressources humaines, qui auraient très bien pu collaborer avec les développeurs des autres paquets — question ouverte: se trouve-t-il des développeurs de dnsmasq dans ceux de systemd-network et qui approuvent les deux projets, par exemple?
        
        La pertinence de la gestion du réseau par systemd lui-même est à questionner. Pour moi? Oui. Et pour d'autres aussi, je l'ai lu, ici même et ailleurs dans des articles dont je n'ai plus les références. En ce qui me concerne, systemd devrait moins s'occuper du réseau que de contrôler les modules qui, eux, s'occupent du réseau.
        
        Les critiques de cette tendance de systemd à "vouloir s'occuper de tout" sont donc tout-à-fait justifiées. On devrait donc voir, en toute logique si ces critiques étaient prises en compte, (doit-on encore remettre en cause leur légitimité?) une réduction dans le développement des modules répondant à des fonctionnalités existantes, non?
        
        La violence des réactions témoigne justement donc d'une ferme opposition donc d'une division. Je ne cautionne pas la violence et ceux qui s'abaissent à ce genre d'attitude nauséabonde mais à toute forme de violence correspond un problème profond. Et classer ce problème aussi sec, sans analyse supplémentaire, dans la catégorie "opposition par des réfractaires" est, en effet, trop facile.
        
        Que M. Poettering s'en étonne me paraît symptomatique. Qu'il définisse ensuite la communauté du libre comme étant "remplie de [choisis tes termes parmis les moins élogieux]" ajoute suffisamment à son discrédit. En tout cas, ça prouve au moins qu'il n'a pas fait l'effort de comprendre ce qui lui arrive et pourquoi.
        
        Je répète, le libre est un monde de personnes qui ont choisi de restaurer le choix, il s'agit d'un monde de convaincus et de principes. Marcher à contre-sens de ces gens-là ne peut que porter atteinte à l'ensemble de la communauté, surtout lorsque la figure de proue fait partie du même mouvement. Alors, dire que les contestataires sont juste des "aigris" ou des "réfractaires", décidément, non, j'adhère pas.
        
        Je m'arrête là, j'ai soif.
        
        pourquoi personne ne fait sérieusement une offre alternative
        
        Je ne commenterai pas, tellement je trouve cet argument grotesque d'aveuglement. Mais ce n'est que mon opinion.
        
        [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 09 octobre 2014 à 20:15. Évalué à 10.
        
        Si ce n'est pas le cas, alors il y a quelque chose qui ne va pas.
        
        Je pense que ce raisonnement est incomplet. Par exemple, des gens chez openbsd continue de penser que la virtualisation et pam sont trop dangereuses. Ou, sans vouloir faire une comparaison avec un camp ou avec l'autre, les anti mariages pour tous.
        
        Pour moi, le fait de protester tiens plus à la capacité de certains à mobiliser ( sur la base de faire du bruit, sur la base d'echange passé ) que sur le changement lui même, qui n'est qu'un facteur.
        
        Que peut-on dire des libristes, sinon qu'ils marchent à contre-
        courant [de l'«ordre» établi]? Ne peut-on pas dire qu'ils
        remettent en cause les fondements de cet «ordre» (au sens
        général)?
        
        On pourrait le dire de n'importe qui ou quoi. Si tu défini pas l'ordre établi, la généralisation n'a aucun sens. Un libriste va aller contre l'idée de proprietarisation ce qui est vu comme l'ordre établi, mais pas en faveur d'un retour à la terre ou un monde sans technologie tel que certains mouvements neoluddites le préconisent.
        
        il mérite d'être entendu et ses arguments pris en compte, non?
        
        tu peux prendre en compte l'argument et quand même faire un choix qui va contre. Tu peux écouter et dire "j'ai compris, je vois bien qu'il y a comme toujours des avantages et des inconvénients, et je pense que la balance est plus bénéfiques de ce coté". On a pas toujours une solution qui va satisfaire tout le monde à 100%. Et sauf à se dire "je suis donc j'ai le droit qu'on fasse ce que je dit" ( aka, l'entitlement anglais, que j'ai du mal à traduire ), les gens vont comprendre ça. Mais la, il semble plus que les gens postent sur les forums, n'ont pas de réponse et se dise "personne n'a lu ce que j'ai dit, et on ne fait rien pour moi".
        
        J'ai du mal à comprendre la pertinence des modules comme le
        démon journald, le serveur DHCP, le module NTP (il y en a sans
        doute d'autres, je ne les connais pas). Pourquoi?
        
        Alors, pourquoi journald. Parce que ça apporte des fonctions qui n’était pas présente. Le fait de proposer de façon unifié les messages de logs, de recolter stdout/stderr en rajoutant des metadonnées, etc. Tu penses peut être que ça sert à rien, c'est ton droit, mais moi, je suis pas d'accord. D'un point de vue technique, si tu veux rajouter les infos, tu peux pas par définition passer ça directement à syslog, surtout si syslog est pas lancé encore. Donc tu as besoin d'un process qui gère ça. C'est juste évident, et j'attends franchement que quelqu'un propose un autre design histoire qu'on en discute.
        
        Pourquoi dhcp. Alors du coté du client, c'est pour se débarrasser de /etc/init.d/network, car c'est un gros shell script bien relou. Mais dans ce cas, pourquoi ne pas garder dhclient ? Visiblement, les gens de intel et tom, qui ont bossés dessus, ont réussi à obtenir des résultats assez impressionnant en terme de vitesse à obtenir le lien, chose qu'ils n'auraient sans doute pas pu faire via le client de l'isc. Donc je pense qu'aprés avoir bosser sur connman, sur les autres clients, etc, ils se sont dit "on va refaire de 0". Ensuite se pose la question de "pourquoi dans le git de systemd plutot qu'ailleurs", et je pense que c'est surtout pour s'intégrer via les autres distributions, vu que ça donne plus de retours, plus de tests et plus de contributeurs que de faire les trucs dans leur coin. C'est une bête question de collaboration.
        
        Du coté du serveur, c'est vis à vis de la volonté d'avoir systemd capable de lancer des containers. Systemd-nspawn, etc. Tu peux te dire que ça n'a rien à faire la, mais les devs se disent que lancer un logiciel, ou lancer un container, c'est pareil. C'est vrai que c'est pareil, tu as juste 2/3 namespaces différents et c'est tout. Et à partir du moment ou tu te dit que tu veux contrôler l’environnent du programme, y compris le réseau, alors le serveur dhcp sous ton contrôle s'impose comme une solution qui requiert 0 modifs coté système dans le containers. Et qui donne en plus accès à la requête exacte, ce qui permet de faire du reporting, d’orchestrer les choses, etc.
        Mais comme le but est juste de faire un outil pour ça, tu va pas faire un serveur dhcp complet comme l'ISC, qui supporte le pxe, la redondance, l'intégration avec bind, etc.
        
        Je trouve en fait quand même ironique de se plaindre que systemd fait trop de choses, et de dire ensuite que ça ne fait pas assez. Et de citer dnsmasq qui justement n’implémente pas toutes les RFC du dns et du dhcp ( genre rfc 1034 et 1035 ), ça rajoute à l'ironie. C'est ce genre de choses qui fait qu'au final, les détracteurs de systemd sont pas pris au sérieux. C'est le fait d'agiter des concepts sans réfléchir, une forme de dogmatisme qui nuit au propos.
        
        question ouverte: se trouve-t-il des développeurs de dnsmasq
        dans ceux de systemd-network et qui approuvent les deux
        projets, par exemple?
        
        Pourquoi ils devraient ? Y a eu des devs de l'isc pour approuver dnsmasq, ou n'importe quel serveur dhcp et dns ?
        C'est un peu un appel à l'autorité qui pue un peu, le coté "il faut que le code de systemd soit tenu à un standard plus elevé" est du bullshit complet. Et ça, ç'est aussi une des raisons qui font que les détracteurs sont pas pris au sérieux. D'un coté, les gens réclament des alternatives à systemd, mais ensuite, ils veulent aussi pas que les codeurs codent des alternatives sans l'approbation d'autres gens.
        
        Mais sinon, oui, il y a les gens qui bossent sur connman chez Intel qui ont décider de faire une lib de parsing des messages dhcp avec l'équipe systemd, chose que les autres implementations n'ont pas cru bon de faire, ce qui fait qu'on repart de 0 à chaque fois.
        
        La pertinence de la gestion du réseau par systemd lui-même est
        à questionner. Pour moi? Oui. Et pour d'autres aussi, je l'ai
        lu, ici même et ailleurs dans des articles dont je n'ai plus
        les références. En ce qui me concerne, systemd devrait moins
        s'occuper du réseau que de contrôler les modules qui, eux,
        s'occupent du réseau.
        
        Quel modules ? Tu crois que le réseau, ça arrive par magie ?
        En fait le souci, c'est quoi, c'est que des gens passent de leur temps à recoder des choses et tu penses qu'ils ne devraient pas ?
        
        Encore une fois, le but est de remplacer le paquet initscripts des RHlikes. Dont /etc/init.d:network. Si la conclusion est "on refait des trucs plus que de s'intéger avec ce qui existe parce qu'on pense que l'intégration plus poussé donne accès à des choses qu'on ne peut pas faire avec l'existant", alors ça a du sens, cf ma réponse plus haut. Tu peux mettre un poids plus haut sur une séparation plus formel, sans souci, mais ça reste une opinion, qui a été envisagé et qui n'a pas été implémenté. Tu voudrais quoi de plus ?
        
        Et classer ce problème aussi sec, sans analyse supplémentaire,
        dans la catégorie "opposition par des réfractaires" est, en
        effet, trop facile.
        
        Et pourtant, c'est le plus rapide. Tu apportes rien de neuf qui n'a pas déjà été dit, tu le reconnais toi même vu que tu cites d'autres personnes qui se font la reflexion. Faire une réponse construite m'a pris facile 1h et j'ai pas adressé tout, et je part du principe que tu va pas répondre, sinon ça va me prendre encore plus de temps. 1h que j'ai pas consacré à coder ou autre choses. Si pour chaque posts sur linuxfr, sur phoronix, sur lwn, je passe 1h à répondre, je peux passer la journée dessus. Et pendant ce temps, les projets n'avancent pas. Donc oui, quand ça n'apporte rien de nouveau, ne rien répondre devrait suffire.
        
        Je répète, le libre est un monde de personnes qui ont choisi
        de restaurer le choix,
        
        Non. le libre n'est pas le choix par construction, mais le choix par hasard. Ça découle de la liberté, mais le choix n'est pas gratuit en terme de ressources, et c'est encore une point de plus en défaveur de ton argumentaire, vu que tu dis "faut mutualiser les ressources, mais en même temps, faut aussi disperser pour le choix".
        
        il s'agit d'un monde de convaincus et de principes.
        Marcher à contre-sens de ces gens-là ne peut que porter
        atteinte à l'ensemble de la communauté, surtout lorsque la
        figure de proue fait partie du même mouvement. Alors, dire que
        les contestataires sont juste des "aigris" ou des
        "réfractaires", décidément, non, j'adhère pas.
        
        Et pourtant, en voyant ton pâté, avec le grand final qui tout juste ne dit pas "systemd va détruire le libre", on devrait en penser quoi ? Encore une fois, je sais que c'est injuste, mais ça me rappelle les revendications de certaines mouvements politiques qui disent que le mariage pour tous va détruire la societé francaise.
        
        Donc ouais, si tu veux pas passer pour réfractaire, je pense que tu devrait arrêter de reprendre leurs codes de communications, même si je ne doute pas que ça soit involontaire. Parce que bon :
        - l'appel au dogme ( unix, religieux )
        - le fait de continuer après la bataille
        - l'appel au risque de destruction de l'existant
        - le fait de se sentir ignorer par les gens qui décident
        - le fait d'avoir des casseurs et des gens violent en marge du mouvement ( insulte de taubira, insulte de lennart )
        
        Je trouve que ça fait beaucoup de ressemblances. Ensuite, encore une fois, je pense que les idées sont totalement différentes dans les 2 cas donc c'est pas le fond qu'il faut comparer mais la forme et comment les mouvements se structurent de la même façon.
        
        [^] # Re: un message de lennart
        
        Posté par FantastIX le 13 octobre 2014 à 09:35. Évalué à 2.
        
        Faire une réponse construite m'a pris facile 1h et j'ai pas adressé tout, et je part du principe que tu va pas répondre, sinon ça va me prendre encore plus de temps. 1h que j'ai pas consacré à coder ou autre choses. Si pour chaque posts sur linuxfr, sur phoronix, sur lwn, je passe 1h à répondre, je peux passer la journée dessus. Et pendant ce temps, les projets n'avancent pas. Donc oui, quand ça n'apporte rien de nouveau, ne rien répondre devrait suffire.
        
        Ma réponse m'a demandé plus de 2 heures, alors disons qu'au final, ta dernière phrase me suffira; je n'ai en effet plus envie d'argumenter. Mais ça ne m'empêchera pas de rester sur l'opinion que la complainte de Lennart Poettering sur "la communauté" est inappropriée (ce qui était au départ, mon seul et unique reproche… que j'ai eu le tort de penser étoffer avec des arguments techniques scabreux, ça, je te le concède volontiers). Ce type a tort sur l'opinion qu'il en a.
        
        Mais comme nous l'avons lu plus haut: «l'avenir nous le dira».
        
        [^] # Re: un message de lennart
        
        Posté par anaseto le 07 octobre 2014 à 19:59. Évalué à 8.
        
        Je ne sais pas s'il faut interpréter cette dernière comme « ce sont les aigris qui tirent à bout portant sur [Lennart Poettering] » ou autre chose que j'ai du mal à définir.
        
        Je ne sais pas si le mot "aigri" était bien choisi de ma part. Ce que je veux dire, c'est que, même si on a le droit de ne pas aimer systemd, c'est injuste et peu responsable de s'en prendre à son développeur principal, quand c'est une décision partagée par beaucoup de monde ; sans l'appui des distributions et d'une bonne partie de la communauté, systemd n'irais nulle part. Que Lennart pense que tout le monde devrait utiliser son logiciel ou non, ça n'a que peu d'importance, c'est chaque distribution qui décide ce qui est bon pour elle. Je ne dis pas que je trouve sa façon de généraliser une bonne chose, loin de là, juste que je comprends, et qu'il n'y a pas de quoi en faire un pâté.
        
        Après, je pense que tout le monde peut râler. Personnellement, systemd ne m'intéresse pas particulièrement, répond à des problèmes qui ne me disent rien et ne font pas partie de mes centres d'intérêt, et le fait d'apprendre à l'utiliser me semble plus une corvée qu'autre chose, et j'espère juste que, si un jour je dois l'utiliser, je ne perdrai pas trop de temps avec, mais j'assumerai et je n'en voudrai à personne (l'idée même me semble ridicule).
        
        [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 07 octobre 2014 à 19:24. Évalué à 5.
        
        Je suis d'accord avec toi. Je comprends que Lennart, vu sa
        position de victime en l'occurrence, en vienne à généraliser
        (je pense n'importe qui de normalement constitué serait énérvé
        à sa place), mais je n'ai pas du tout l'impression de
        rencontrer statistiquement cette "haine" dans la communauté,
        et je ne pense pas que ce soit quelque chose de généralisé.
        
        Moi, je me suis déjà fait prendre à partie sur le bugzilla de mandriva.
        https://qa.mandriva.com/show_bug.cgi?id=52856#c10
        
        Sur le forum de mdv aussi, par le même groupe. ( mais le forum de mandriva a disparu, donc j'ai pas de lien à donner )
        
        J'ai plein de gens de mageia qui se sont aussi fait insulter par un codeur du projet rpm5 pour ne pas l'avoir invité à mageia ( en parti parce qu'il avait insulté les gens avant ). Et le projet open mandrake a aussi eu des soucis à cause du même genre de personne, au point de devoir le virer du projet qu'il a aidé à fonder. Il est pourtant techniquement bon, mais voila.
        
        Donc tu as soit eu de la chance, soit tu as pas fait assez de contributions au libre pendant assez longtemps. Ou soit, comme moi, c'est arrivé, et tu t'es dit "bof", avant de t'en souvenir et de te dire "ah oui, si quand même". Bien sur, la grande majorité des gens sont sympathiques autour de moi, mais je sais aussi que c'est pas le cas de tout le monde.
        
        Et comme je le cite sans arrêt, y a d'autres personnes qui trouvent que faire du libre est parfois une pression énorme, à cause du sentiment de certains que tout leur est du :
        
        http://shk.io/2014/08/27/open-source/
  - [^] # Re: un message de lennart
    
    Posté par ʭ ☯ le 06 octobre 2014 à 15:54. Évalué à 8.
    
    … ou comment lire de travers : il dit juste qu'une communauté où l'on trouve ça sympa de s'envoyer des insultes fonctionne de travers. Quand tu as des gens qui s'amusent à publier des chansons pour t'insulter, qui créent une cagnotte publique pour te faire assassiner, tu trouves ça moyennement drôle l'agressivité des messages de Linus pour du code qui lui plaît pas : "on devrait avorter rétroactivement les gens qui ont écrit ça".
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: un message de lennart
      
      Posté par gnx le 06 octobre 2014 à 16:33. Évalué à 0.
      
      Non, il ne dit pas juste ça.
      
      the Open Source community is full of assholes
      
      The Internet is full of deranged people,
      
      there are certain communities where it appears to be a lot more accepted to vent hate, communities that attract a certain kind of people (Hey, Gentoo!)
      
      I'd actually put some blame on a certain circle of folks that play a major role in kernel development, and first and foremost Linus Torvalds himself.
      - [^] # Re: un message de lennart
        
        Posté par rogo le 06 octobre 2014 à 19:55. Évalué à 7.
        
        À mon avis, les propos de L. Poettering correspondent sur le fond au ça que tu nies. La principale différence que j'y vois est que ʭ ☯ adoptait un ton détaché alors que la victime est plus naturellement portée à l'acrimonie.
        
        Reprenons point par point. D'abord, il commence par deux banalités : il y a des gens perturbés et des connards dans toute communauté d'une certaine taille. Par moments, je me dis que presque toute l'humanité rentre dans ces deux catégories. Ensuite il se plaint que certaines communautés et certains individus encouragent l'agressivité et les brimades, ce qui me semble là aussi une banalité.
        
        Enfin, il accuse Gentoo et L. Torvalds de contribuer à cette agressivité. Qu'on soit d'accord ou pas (je n'en sais pas assez pour me faire une opinion solide), il y a déjà eu suffisamment de faits avérés, et par le passé des éclats, des insultes, et des personnes se disant blessées, pour que sa plainte semble sincère, et représentative au moins d'une minorité.
        
        [^] # Re: un message de lennart
        
        Posté par Misc (site web personnel) le 06 octobre 2014 à 21:46. Évalué à 7.
        
        D'un point de vue pratique, tu pourrais rajouter plein d'autre à Linus. Par exemple, la réaction de Borislav Petkov sur les histoires de debug était relativement disproportionné à mon sens ( et c'est pas le premier dev kernel à avoir ce que j'estime des réactions excessives ). Je suis sur que la façon de gérer les choses de Theo De Raadt a aussi entrainé tout une suite de copycat qui font pareils, ce qui aboutit quand même à des sacrés tensions, voir pire ( j'ai des collègues qui refuse de traiter avec lui pour les soucis de sécuritéé de part la violence de certains mails privés qu'il a envoyé ).
        
        À coté, y a des communautés ou tu entends pas parler de ce genre de problèmes ( freebsd par exemple ), et ça donne un système de qualité équivalente.
# Typo ?

Posté par rdg le 06 octobre 2014 à 13:42. Évalué à 3.

"Gestion des réseaux virtuels xvlan ainsi que tun/tap et les périphériques factices."

==> vxlan plutôt non ?
- [^] # Re: Typo ?
  
  Posté par Benoît Sibaud (site web personnel) le 06 octobre 2014 à 13:47. Évalué à 3.
  
  Corrigé, merci.
# Nettoyage des sémaphores

Posté par LupusMic (site web personnel, Mastodon) le 06 octobre 2014 à 17:39. Évalué à 5.

Côté fonctionnement interne, logind détruit maintenant automatiquement les objets d’IPC (InterProcess Communication, communication interprocessus) appartenant à un utilisateur quand il se déconnecte complètement, pour libérer des ressources. Cela inclut sémaphores, files de messages et mémoires SysV, ainsi que les files de messages et mémoires partagées POSIX. Les objets SysV et POSIX n’ont traditionnellement pas de cycle de vie, cette fonctionnalité corrige cela.

C'est complètement surréaliste. Déjà il faudra me définir le concept de déconnexion complète. À mon sens, on a une session ouverte ou aucune, mais il n'y a pas d'état intermédiaire.

Ensuite, comment seraient gérées les IPC inter-utilisateurs, ou qui doivent survivre à leur créateur ? Je pense entre autres aux queues de messages qui permettent de créer des systèmes asynchrones ? En effet, si j'ai un service tournant sous l'utilisateur A qui écrit dans une queue, créée par un utilisateur B, pour qu'un cron job lancé sous l'utilisateur C traite les messages de la queue, que se passe-t-il quand aucun processus de l'utilisateur B n'existe ?
- [^] # Re: Nettoyage des sémaphores
  
  Posté par rogo le 06 octobre 2014 à 18:56. Évalué à 8.
  J'ai moi-même été dubitatif à la lecture, mais après avoir glané quelques infos, ça me semble assez mineur.
  
  C'est complètement surréaliste. Déjà il faudra me définir le concept de déconnexion complète. À mon sens, on a une session ouverte ou aucune, mais il n'y a pas d'état intermédiaire.
  
  Rien de bien méchant derrière ce "fully log out". Si j'ai 2 connexions SSH sur une machine et que j'en ferme une, je ne suis que partiellement déconnecté.
  
  Ensuite, comment seraient gérées les IPC inter-utilisateurs, ou qui doivent survivre à leur créateur ? […] que se passe-t-il quand aucun processus de l'utilisateur B n'existe ?
  
  Dans quelle situation a-t-on une file de message rattachée à l'utilisateur B mais sans aucun processus ? Parce que dans ce cas je ne vois pas où iraient les messages…
  1. Ce nouveau comportement ne concerne que les comptes humains, pas les comptes systèmes, de faible ID.
  2. Ce comportement est désactivable dans logind.conf.
  3. Il s'agit de supprimer les objets IPC, pas les processus. Donc on peut continuer à laisser un GNU Screen tourner en quittant sa session graphique. Cf le réglage booléen KillUserProcesses, désactivé par défaut dans ce même logind.conf.
  - [^] # Re: Nettoyage des sémaphores
    
    Posté par LupusMic (site web personnel, Mastodon) le 07 octobre 2014 à 14:05. Évalué à 2.
    
    Dans quelle situation a-t-on une file de message rattachée à l'utilisateur B mais sans aucun processus ? Parce que dans ce cas je ne vois pas où iraient les messages…
    
    Ben ils restent dans la queue jusqu'à ce qu'ils soient lus.
    http://linux.die.net/man/2/msgctl
    
    Et merci d'avoir apporté les précisions qui répondent à mon questionnement.
  - [^] # Re: Nettoyage des sémaphores
    
    Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 13:52. Évalué à 1.
    
    pas les comptes systèmes, de faible ID.
    
    Classification arbitraire.
    - [^] # Re: Nettoyage des sémaphores
      
      Posté par ariasuni le 09 octobre 2014 à 19:16. Évalué à 2.
      
      Bah ça a un peu toujours été comme ça sous GNU/Linux, non? Et s’il n’y a pas de raison de changer…
      
      Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Nettoyage des sémaphores
  
  Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 13:50. Évalué à 3.
  
  mais il n'y a pas d'état intermédiaire.
  
  $ nohup mega_gros_batch.sh &
  $ exit
  
  Dans quel état j'erre ?
# Description de systemd ?

Posté par jon le 06 octobre 2014 à 21:18. Évalué à 5.

Je suis d'assez loin et de manière passive le développement de systemd et je suis globalement plutôt positif quand aux changements proposés.

Mais la dépêche commence avec :

systemd est un système de démarrage alternatif au démon init de System V spécifiquement conçu pour le noyau Linux, avec une meilleure gestion des dépendances entre services et le chargement en parallèle des services au démarrage.

… et en lisant le reste, je me demande à quel point cette description est encore vraie. Rien que dans cette dépêche, l'apparition d'un daemon SNTP et DHCP me paraît un peu bizarre. Je peux comprendre, à la limite, qu'on veuille mettre en place ces informations le plus tôt possible, mais de là à les intégrer à systemd directement ?

J'ai l'impression que ce logiciel grossi de plus en plus en phagocytant de plus en plus de services qui étaient avant externes à systemd, dans des projets bien séparés, et ça me fait un peu penser au syndrome NIH (Not Invented Here)
- [^] # Re: Description de systemd ?
  
  Posté par ariasuni le 06 octobre 2014 à 21:30. Évalué à 7.
  
  Rien que dans cette dépêche, l'apparition d'un daemon SNTP et DHCP me paraît un peu bizarre. Je peux comprendre, à la limite, qu'on veuille mettre en place ces informations le plus tôt possible, mais de là à les intégrer à systemd directement ?
  
  Hé bien tous ces trucs viennent avec systemd mais ne font pas partie du binaire systemd, tout comme Linux est livré avec tout en tas de pilotes qui ne sont que des modules.
  
  J'ai l'impression que ce logiciel grossi de plus en plus en phagocytant de plus en plus de services qui étaient avant externes à systemd, dans des projets bien séparés, et ça me fait un peu penser au syndrome NIH (Not Invented Here)
  
  En fait, dans la plupart des cas, soit le logiciel ne correspondait pas à ce qui était attendu par les développeurs systemd (ex: unités minuteurs face à cron), soit ça n’avait complètement rien à voir (ex: virtualisation, conteneurs), soit c’est un truc léger (ex: client SNTP), mais globalement rien d’inutile.
  
  Après, libre à toi de penser que ça n’était pas ce qu’il fallait faire (chacun à son avis dessus, ~~trop~~ très souvent passionné — qui relève souvent de la loi de futilité de Parkinson malheureusement). Par contre, c’est loin d’être inutile.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Description de systemd ?
    
    Posté par Christophe le 06 octobre 2014 à 22:21. Évalué à 5.
    
    Hé bien tous ces trucs viennent avec systemd mais ne font pas partie du binaire systemd, tout comme Linux est livré avec tout en tas de pilotes qui ne sont que des modules.
    
    Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
    On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
    
    Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
    
    Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
    Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
    
    (et merde, on est seulement lundi…)
    - [^] # Re: Description de systemd ?
      
      Posté par ariasuni le 06 octobre 2014 à 22:46. Évalué à 8.
      Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
      
      On est quand même loin là, le noyau n’est pas censé fournir d’application. systemd fournit des démons indépendants, qui peuvent être désactivés et remplacés.
      
      On parle bien ici d'un projet systemd, qui faute de limite claire dans son rôle (démarrer un système et le gérer, c'est quand même très flou), est en train de tout refaire à sa sauce. Ce projet est-il donc incapable d'interagir avec une brique de l'espace utilisateur sans créer un module dédié ? Le daemon DHCP, au départ tout simple, ambitionne déjà de gérer un cache DNS et DNSSEC…
      
      S’ils font un truc bien, pourquoi pas. Bizarrement quand le projet systemd fait des trucs on parle de NIH, mais sinon les trouze milles distributions c’est de la diversité, hein? J’ai envie de dire: nous verrons bien ce que ça va donner.
      
      Alors, bien sûr, on peut ne pas activer ces modules. Mais il n'empêche que ces modules seront intégrés de plus en plus fortement au démarrage du système, et la possibilité qu'ils deviennent irremplaçables est bien là.
      
      Je ne vois pas en quoi les modules précédents pourraient devenir obligatoires.
      
      Le problème, tel que je le vois, est double: 1. on a un projet qui se disperse, ne trouve pas son rôle, et 2. on a un risque de rigidifier fortement le système GNU/Linux en faisant tout passer par un composant central.
      Récemment il m'est arrivé d'avoir cassé mon DBus à la suite d'une bidouille malheureuse: j'ai dû corriger le problème à l'intuition, car journalctl et systemctl ne fonctionnaient plus… Très pratique.
      
      Je me trompe peut-être, mais:
      
      si le shell est H.S., point de SystemV. dbus serait-il plus susceptible de ne pas fonctionner qu’un shell?
      
      avec dbus dans le noyau, ça risque d’être plus dur de foutre en l’air dbus, non?
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Description de systemd ?
        
        Posté par Christophe le 07 octobre 2014 à 09:27. Évalué à 4.
        
        Ce sont juste des doutes et des interrogations. Je ne suis pas devin, donc effectivement nous verrons bien. Mais il est essentiel de garder un œil critique sur ce composant qui est aujourd'hui au cœur de notre OS.
        
        [^] # Re: Description de systemd ?
        
        Posté par ledufakademy le 08 octobre 2014 à 00:01. Évalué à -1.
        
        je partage ton avis.
        
        Oui c'est clair et indéniable que cette conception du démarrage est assez bien ficelé. Et extrèment efficace (temps de boot avec un ssd de dingue, plus vite que le bios !!)
        
        PAR CONTRE :
        
        ce truc est vraiment tentaculaire, Lennart le compare souvent à launchd (os x) que j'ai "hacké" fût une époque, et je puis vous dire que si c'est cela la cible du type : on est un peu dans la merde.
        C'est du fermé et tout devient interdépendant (y'a qu'avoir le schema systemd avec ses hooks : udev, d-bus etc etc ….)
        D'ailleur tt comme mac os x : log binaire … ( lennart stp, achètes toi un mac ! … yosemite va bientôt sortir ;-))
        
        Ce systemd va devenir une grosse boite noire, car oui sa demo sur les pid à 1883, les x awk etc est totalement pertinente, par contre lui il met tout en binaire il fige avec une compilation !
        un binaire cela ne se tune que par le biais d'une recompilation et oui !
        Alors qu'un script (bash pour les rc etc) l'admin sys peut le retravailler : on va perdre en facilité de maintenance et de personnalisation , j'en suis certain.(un fichier de conf est limité à ses options, un script n'a de limite que notre imagination)
        
        Mais bon, j'espère me planter (et pis y'a pas temps de doc sur lui … en faite !)
        
        [^] # Re: Description de systemd ?
        
        Posté par ariasuni le 08 octobre 2014 à 01:48. Évalué à 5.
        
        ce truc est vraiment tentaculaire, Lennart le compare souvent à launchd (os x) que j'ai "hacké" fût une époque, et je puis vous dire que si c'est cela la cible du type : on est un peu dans la merde.
        
        Pas plus que le projet GNU qui comporte un interpréteur de commande, un noyau de système d’exploitation, une boite à outils graphique, un logiciel de dessin matriciel, un navigateur web, un ~~système d’exploitation~~ éditeur de texte, un langage de programmation, un compilateur, etc.
        
        C'est du fermé
        
        systemd c’est du logiciel libre, les décisions se passent sur la liste de discussion, etc.
        
        et tout devient interdépendant (y'a qu'avoir le schema systemd avec ses hooks : udev, d-bus etc etc ….)
        
        Quel rapport entre l’utilisation de udev et de dbus, et le fait que les composants de systemd soit soit-disant interdépendants?
        
        Et ça n’est pas parce que tout est dans le même dépôt et géré par la même équipe que ça veut dire que tout sera interdépendant et impossible à gérer. En tout cas j’attends toujours la preuve de cette affirmation.
        
        D'ailleur tt comme mac os x : log binaire … ( lennart stp, achètes toi un mac ! … yosemite va bientôt sortir ;-))
        
        Un exemple, ça fait un peu faible pour dire que c’est pareil. D’autre part, reprendre des idées de Mac c’est pas forcément mauvais (d’ailleurs j’attends l’équivalent des touches mortes affichées en jaune lorsqu’elles sont pressées une fois sous GNU/Linux).
        
        Bref, j’ai pas vraiment vu d’argument convaincant pour dire que les logs binaires sont pourris. D’après ce que j’en ai compris, c’est juste pratique dans certains cas et pas dans d’autres, et franchement dans la plupart des cas ça ne fait pas de différences.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 08 octobre 2014 à 09:25. Évalué à 6.
        
        Pas plus que le projet GNU qui comporte un interpréteur de commande, un noyau de système d’exploitation, une boite à outils graphique, un logiciel de dessin matriciel, un navigateur web, un système d’exploitation éditeur de texte, un langage de programmation, un compilateur, etc.
        
        Je peux utiliser n’importe lequel de ces composants sans les autres, ils sont tous (ou presque) indépendants.
        
        Moi j’aime bien systemd le système d’init, mais les trucs à la consolekit/policykit je les ai toujours fuis comme la peste. Lennart ne veut pas seulement faire plein de briques (j’ai rien contre ça, au contraire), mais il veut les « unifier », c’est à dire de faire de tout ça un gros paquet de nouilles interdépendant.
        
        Tu ne peux pas comprendre l’opposition à systemd si tu persistes à dire « systemd c’est un projet, un peu comme GNU », c’est plus un projet comme Windows ou MacOS X, et c’est pour ça que ceux qui aiment le modèle Linux s’y opposent.
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 08 octobre 2014 à 09:28. Évalué à -1.
        
        Moi j’aime bien systemd le système d’init, mais les trucs à la consolekit/policykit je les ai toujours fuis comme la peste. Lennart ne veut pas seulement faire plein de briques (j’ai rien contre ça, au contraire), mais il veut les « unifier », c’est à dire de faire de tout ça un gros paquet de nouilles interdépendant.
        
        Sauf que ça ne l'est pas.
        
        Myth: systemd is monolithic.
        
        If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.
        
        A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 08 octobre 2014 à 09:40. Évalué à 4. Dernière modification le 08 octobre 2014 à 09:41.
        
        Gros paquet de nouilles interdépendant ≠ Monolithique
        
        MacOS X n’est pas monolithique, bonne chance pour faire fonctionner son serveur graphique sans avoir tout ce qu’il y a autour. Postfix c’est plein de binaires différents et donc n’est pas « monolithique », ça n’empêche qu’ils fonctionnent de manière interdépendante.
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 08 octobre 2014 à 10:24. Évalué à 2.
        
        Tu auras forcément des dépendances. Mais elles ne sont pas fortes dans le cas de systemd : les outils qui le compose peuvent être remplacés.
        
        Un système / programme sans dépendances : c'est un système / programme qui ne fait RIEN DU TOUT.
        
        Tu auras forcément des dépendances si tu veux quelque chose qui ait un minimum d'intérêt !
        
        Ce qui est à éviter, c'est les dépendances fortes, pas les dépendances tout court.
        
        Et ça n'en fait pas un gros plat de nouilles. Ça n'a rien à voir.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 08 octobre 2014 à 11:00. Évalué à 4. Dernière modification le 08 octobre 2014 à 11:03.
        
        Mais elles ne sont pas fortes dans le cas de systemd : les outils qui le compose peuvent être remplacés.
        
        Tu veux dire, un peu comme udev ?
        
        Un système / programme sans dépendances : c'est un système / programme qui ne fait RIEN DU TOUT.
        
        Ben non, si je reprend mon exemple de Pardus plus bas, leur système d’init (mudur) et leur gestionnaire de service (dont j’ai oublié le nom) étaient totalement indépendants (puisque j’ai pu utiliser l’un sans l’autre), et ils sont loin d’être inutiles.
        
        Et pour reprendre l’exemple de sinma (projet GNU), emacs est indépendant de hurd.
        
        De même, getty est indépendant de init, ça rend pas getty et init inutiles.
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 08 octobre 2014 à 11:29. Évalué à 3.
        
        Ben non, si je reprend mon exemple de Pardus plus bas, leur système d’init (mudur) et leur gestionnaire de service (dont j’ai oublié le nom) étaient totalement indépendants (puisque j’ai pu utiliser l’un sans l’autre), et ils sont loin d’être inutiles.
        
        Ben si.
        
        Tu confonds dépendance faible et dépendance forte, c'est tout.
        
        Et dans le cas de systemd, systemd (l'init) est indépendant de systemctl (le gestionnaire de services) : l'init n'a pas besoin de faire appel à systemctl pour booter.
        
        Par contre systemctl a besoin de systemd (l'init) pour (par exemple) lancer un service. C'est une dépendance faible et c'est normal.
        
        Dans le cas de SysV/Upstart/Pardus ça m'étonnerait que ce soit différent.
        
        Aucun n'est pourtant un gros plat de nouilles. Un gros plat de nouilles ce serait si systemd a besoin de systemctl et inversement.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 08 octobre 2014 à 14:32. Évalué à 1.
        
        Et dans le cas de systemd, systemd (l'init) est indépendant de systemctl (le gestionnaire de services) : l'init n'a pas besoin de faire appel à systemctl pour booter.
        
        Heu… source ? Parce que ce que tu es en train de dire, c’est que je peux par exemple prendre systemd en tant que /bin/init puis lancer initng (qui a besoin d’être PID 1) pour gérer mes services ?
        
        Je peux me tromper, mais j’en doute énormément.
        
        Et si je fais ça, les autres composants de systemd (journald, udev…) marchent toujours ? (sachant que le PID 1 n’est plus celui de systemd)
        
        Dans le cas de SysV/Upstart/Pardus ça m'étonnerait que ce soit différent.
        
        Ça l’est : leur gestionnaire de service était utilisable sur des systèmes sans leur init (j’ai essayé mais abandonné rapidement, préférant initng à l’époque). Tout ce dont il a besoin, c’est d’être PID 1 (c’est à dire que la seule chose nécessaire c’est que l’init puisse passer la main au gestionnaire de service une fois le système initialisé, c’était assez facile à faire sous Arch)
        
        [^] # Re: Description de systemd ?
        
        Posté par ariasuni le 08 octobre 2014 à 17:05. Évalué à 4.
        
        En fait t’as pas compris, mais mon analogie était mauvais donc prenons-en une plus pertinente: un environnement de bureau. Tu peux démarrer l’environnement sans les applications, mais les applications nécessitent des bouts de l’environnement de bureau. Tu peux aussi utiliser d’autres applications que celles de l’environnement de bureau.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 09 octobre 2014 à 07:33. Évalué à 5. Dernière modification le 09 octobre 2014 à 07:33.
        
        Pourquoi essayer des analogies quand on peut parler de la vraie chose ?
        
        Dans « l’ancien modèle », udev, init, le gestionnaire de service et getty sont totalement découplés.
        
        Dans le nouveau modèle systemd, udev, systemd (init), systemd (gestionnaire de service) et (le successeur de getty dont j’ai oublié le nom) sont fortement couplés (ou plus objectivement, de plus en plus fortement couplés de version en version).
        
        Tout ce que je dis, c’est que cette évolution :
        
        existe
        
        ne plait pas à certaines personnes
        
        cette résistance est distincte de « les méchants réactionnaires qui aiment pas le changement »
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 09 octobre 2014 à 07:54. Évalué à 4.
        
        Dans « l’ancien modèle », udev, init, le gestionnaire de service et getty sont totalement découplés.
        
        Euh non. L'init a besoin que quelque chose découvre le matos avant de booter, et c'est le rôle de udev. getty a besoin d'un kernel compatible et c'est linux qui remplit ce rôle.
        
        Et est-ce que udev tourne sous BSD ? J'en doute. J'ai jamais vu udev avec autre chose que du Linux.
        
        Bref, c'est couplé. Faiblement couplé, mais couplé quand même (et c'est inévitable).
        
        Dans le nouveau modèle systemd, udev, systemd (init), systemd (gestionnaire de service) et (le successeur de getty dont j’ai oublié le nom) sont fortement couplés (ou plus objectivement, de plus en plus fortement couplés de version en version).
        
        Ben bah plus que dans l'ancien modèle, si ce n'est que systemd (le projet) a besoin de linux et pas un autre kernel. Encore une fois, je doute que ça change grand chose par rapport à l'ancien modèle (udev et les scripts SysV Debian tournent-ils sous BSD ? J'ai un gros doute là !)
        
        Tout ce que je dis, c’est que cette évolution :
        
        Le problème c'est que ton "couplage fort" n'existe pas. On remplace des couplages faibles par… d'autres couplages faibles. Le CHOC ! L'HORREUR !1!1one
        
        Un couplage fort c'est une interdépendance de deux modules : et c'est là d'où vient l'aspect "gros plat de nouilles".
        
        Mais linux a-t-il besoin de systemd ? Non, c'est juste systemd qui a besoin de linux.
        udev a-t-il besoin de systemd ? Non. C'est juste systemd qui a besoin de udev.
        etc…
        
        Bref, on remplace du couplage faible et compatible BSD en théorie mais pas dans les faits (donc spécifique aux distribs Linux) à du… couplage faible et spécifique à Linux.
        
        Renversant !
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 09 octobre 2014 à 09:26. Évalué à 6.
        
        Euh non. L'init a besoin que quelque chose découvre le matos avant de booter, et c'est le rôle de udev
        
        Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).
        
        Et dans l’autre sens udev ne dépendait pas d’un init particulier, tu pouvais l’utiliser avec initng, sysvinit, mudur, celui de slackware…
        
        Quant à Linux c’est pas vraiment la question, udev était lié à Linux avant, il l’est tout autant avec systemd, pas de changement, je vois même pas ce qu’il y a à discuter là dessus…
        
        Ben bah plus que dans l'ancien modèle, si ce n'est que systemd (le projet) a besoin de linux et pas un autre kernel. Encore une fois, je doute que ça change grand chose par rapport à l'ancien modèle (udev et les scripts SysV Debian tournent-ils sous BSD ? J'ai un gros doute là !)
        
        udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.
        
        udev a-t-il besoin de systemd ? Non. C'est juste systemd qui a besoin de udev.
        
        Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.
        
        Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.
        
        Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 09 octobre 2014 à 09:34. Évalué à 0.
        
        Du tout : même si c’était déprecié, tu pouvais utiliser devfs. Voire créer les fichiers à la main (j’ai ouïe dire que ça se faisait dans certains systèmes embarqué, mais j’avoue que c’est pas mon domaine).
        
        peu importe. Le fait est que l'init dépend d'un outil pour peupler /dev.
        
        Tu as pas suivi ? udev sans systemd n’est maintenant plus supporté, autrement dit couplage fort entre les deux.
        
        C'est une config qui n'est plus sountenue, mais ça ne veut pas dire qu'il y a un couplage fort. Ou alors, montre le code !
        
        udev non, les scripts init oui, c’est du bête shell, mais ce n’est pas la question, je ne parle pas du couplage entre l’OS et les différents composants mais des différents composants entre eux.
        
        C'est du pareil au même !
        
        Je peux avoir le système d’init systemd sans le système de gestion de service de systemd ? Et dans l’autre sens ? Il me semble pas.
        
        Tout comme systemd-logind tournait sous ubuntu sans systemd, systemd (l'init) n'a pas besoin de systemctl pour booter.
        
        Et tu vois les choses de manière trop binaire, il y a tout un continuum entre totalement couplé/totalement découplé, et ce que je dis c’est que systemd pousse dans la première direction, ce qu’on peut difficilement nier, puisque c’est après tout un avantage que mettent en avant les défenseurs de systemd (« l’ancien système c’est un patchwork de trucs complètement indépendants qui arrivent tant bien que mal à donner un système fonctionnel, mais fonctionnel n’est ni optimal ni intégré, ce qui ne nous permet pas de lutter face à la concurrence Windows/OSX », pour caricaturer (un peu) le discours) et un objectif affiché du projet (faire un système homogène, unifié et intégré, et ça ça passe par plus de couplage, c’est les deux faces d’une même pièce).
        
        Ca reste du couplage faible. C'est soit du couplage faible (dépendance dans un sens), soit fort (interdépendance). Un point c'est tout.
        
        Et ça n'a rien à voir avec Windows.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Yves (site web personnel) le 09 octobre 2014 à 11:18. Évalué à 7.
        
        xcomcmdr, j'appréciais l'information apportée par tes commentaires. Mais là, je vois pointer la mauvaise foi. Ta première réponse à elle seule a tellement d'œillères qu'on se demande comment tu peux encore voir…
        
        Personnellement, j'apprécie le travail fait autours de systemd, et je suis plutôt enthousiasmé par les plans de l'auteur (autours de btrfs et du packaging par exemple). Et je suis pleinement conscient de la souplesse de systemd (voir ici par exemple : http://linuxfr.org/users/roc_pierre/journaux/sur-systemd-btrfs-co).
        
        Cela ne m'empêche pas d'être inquiété, comme d'autres, par le fait que systemd remplace des dépendances vers un composant sous-jacent au choix par des dépendances (certes unilatérales) vers un composant sous-jacent imposé, à plusieurs niveaux. Le nier, ou esquiver plutôt que d'expliquer en quoi c'est faux, ne fera pas avancer le débat.
        
        Je suis intéressé par tout information objective que tu aurais pour répondre à cette inquiétude :-)
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 09 octobre 2014 à 13:04. Évalué à 6. Dernière modification le 09 octobre 2014 à 13:05.
        
        Cela ne m'empêche pas d'être inquiété, comme d'autres, par le fait que systemd remplace des dépendances vers un composant sous-jacent au choix par des dépendances (certes unilatérales) vers un composant sous-jacent imposé, à plusieurs niveaux. Le nier, ou esquiver plutôt que d'expliquer en quoi c'est faux, ne fera pas avancer le débat.
        
        Bah ça c'est autre chose : c'est depuis le début le parti pris de systemd de gérer une base de code dans un tout cohérent, dans le même dépôt.
        
        C'est du "à la BSD" si je ne m'abuse :
        
        On the other hand, there is a central repository, a single place where you can find the entire operating system sources, including all older versions.
        
        BSD projects maintain the entire “Operating System”, not only the kernel. This distinction is only marginally useful: neither BSD nor Linux is useful without applications. The applications used under BSD are frequently the same as the applications used under Linux.
        
        As a result of the formalized maintenance of a single CVS source tree, BSD development is clear, and it is possible to access any version of the system by release number or by date. CVS also allows incremental updates to the system: for example, the FreeBSD repository is updated about 100 times a day. Most of these changes are small.
        
        Alors certes on a pas encore le kernel Linux dans le même dépôt/projet, mais avoir systemd + udev + les outils systemd (systemctl, journalctl, …) ensemble c'est voulu.
        
        Myth: systemd is not UNIX.
        
        In fact the design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy. Then, the way our project is handled (i.e. maintaining much of the core OS in a single git repository) is much closer to the BSD model (which is a true UNIX, unlike Linux) of doing things (where most of the core OS is kept in a single CVS/SVN repository) than things on Linux ever were.
        
        Dans ce sens, dire "on ne soutient plus les config udev sans systemd" pour moi ça veut dire que les configs udev sans systemd ne sont tous simplement pas testées. C'est responsable et logique de dire que ceux qui sortent des configs testés le font à leurs risques et périls.
        
        De là à dire que udev dépend de systemd faudrait savoir si c'est vraiment le cas (suffit d'essayer de booter la dernière version de udev sans systemd). Je suis pas non plus pour dire si c'est un gros plat de spaghetti sans voir le code.
        
        Et de là à dire qu'on ne peut pas remplacer les outils/implémentations d'APIs de systemd par d'autres :
        - Ubuntu a utilisé systemd-logind avec Upstart
        - OpenBSD réimplémente les parties de Gnome 3 dont systemd dépend (timedated, localed, hostnamed and logind).
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Albert_ le 09 octobre 2014 à 15:12. Évalué à 0.
        
        Ce qui me gene moi c'est plus systemd devient gros et interdependant moins il sera facile de remplacer une brique. Tu seras completement oblige de passer par ce system meme si cela est un frein a un projet.
        Exemple: on a eu devfs et maintenant udev. Si devfs avait ete fortement lie a un truc comme systemd il y a probablement peu de chance que l'on ait vu apparaitre udev.
        
        Et surtout ce qui me fait peur avec systemd c'est que va t'il se passer quand cela aura fini d'amuser LP? Il se passera un truc comme pour PA (la communaute a recupere le projet et a fait en sorte de patcher le bousin pour que cela fonctionne enfin comme il faut en dehors de RH) ou avahi (un projet orphelin)?
        
        Je n'ai pas systemd sur ma distrib (pour l'instant) et donc je m'en passe tres bien mais quand je vois ce genre de chose je suis inquiet.
        
        [^] # Re: Description de systemd ?
        
        Posté par LeMagicien Garcimore le 09 octobre 2014 à 16:13. Évalué à 5.
        
        Et surtout ce qui me fait peur avec systemd c'est que va t'il se passer quand cela aura fini d'amuser LP?
        
        C'est curieux cette tendance a vouloir croire que systemd c'est le «pet project» de Lennart Poettering et qu'il est tout seul a travailler dessus: http://cgit.freedesktop.org/systemd/systemd/log/
        
        [^] # Re: Description de systemd ?
        
        Posté par ariasuni le 09 octobre 2014 à 19:20. Évalué à 2.
        
        Laisse tomber, une attaque personnelle comme il dénonce.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Description de systemd ?
        
        Posté par whity le 09 octobre 2014 à 18:33. Évalué à 3.
        
        Je n'ai pas systemd sur ma distrib (pour l'instant) et donc je m'en passe tres bien mais quand je vois ce genre de chose je suis inquiet.
        
        Ah bon ? Tu trouves ça inquiétant de savoir que le soft chargé de lire les logs est robuste et supporte bien de lire des fichiers de logs corrompus ? Moi pas, au contraire, je trouve ça rassurant.
        
        Et surtout ce qui me fait peur avec systemd c'est que va t'il se passer quand cela aura fini d'amuser LP? Il se passera un truc comme pour PA (la communaute a recupere le projet et a fait en sorte de patcher le bousin pour que cela fonctionne enfin comme il faut en dehors de RH) ou avahi (un projet orphelin)?
        
        PA est le truc qui fait que l’audio marche sous linux, y compris avec plusieurs cartes son. Mais j’ai remarqué que ceux qui critiquent systemd sont aussi souvent ceux qui critiquent pulseaudio…
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Description de systemd ?
        
        Posté par gouttegd le 09 octobre 2014 à 19:34. Évalué à 1.
        
        PA est le truc qui fait que l’audio marche sous linux, y compris avec plusieurs cartes son. Mais j’ai remarqué que ceux qui critiquent systemd sont aussi souvent ceux qui critiquent pulseaudio…
        
        Faudrait voir à ne pas exagérer non plus. Que PulseAudio rende service, je veux bien, mais on ne l’a pas attendu pour profiter pleinement du son sous GNU/Linux…
        
        [^] # Re: Description de systemd ?
        
        Posté par ariasuni le 09 octobre 2014 à 20:10. Évalué à 2.
        
        Le réglage du son par application, ça ne t’es peut-être d’aucune utilité mais ne pas avoir ça en 2014 c’est quand même un peu dommage (par exemple).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Description de systemd ?
        
        Posté par gouttegd le 09 octobre 2014 à 21:14. Évalué à 4.
        
        Donc ça rend service, merci je n’ai pas dit le contraire. Mais de là à dire que c’est ce qui fait que « le son marche sous GNU/Linux », désolé je ne suis pas d’accord.
        
        M’enfin, on en arrive à un point où ceux qui encensent les projets de Poettering comme s’ils étaient miraculeux me saoûlent autant que ceux qui les critiquent sans chercher à les connaître, donc je vais profiter une dernière fois du strip « Discussion » et m’arrêter là. Désolé pour le bruit.
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 09 octobre 2014 à 21:15. Évalué à 1.
        
        Oui avec ALSA tu as une carte son qui fonctionne.
        
        Avec PulseAudio, tu as une gestion de ton son facile et moderne.
        
        Encore que j'ai pas trouvé comment normaliser tous les sons comme je peux le faire sous Windows depuis Windows 7 en un clic. C'est bien utile pour les oreilles.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par ariasuni le 10 octobre 2014 à 01:17. Évalué à 1.
        
        Tu as dit «profiter pleinement»… Tu n’as pas donné de définition, j’ai interprété.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Description de systemd ?
        
        Posté par Albert_ le 09 octobre 2014 à 21:27. Évalué à 3.
        
        Probablement parceque nous avons essuye les platres de PA sur un autre systeme que RH/Fedora et que c'etait bien la catastrophe. Il a fallu plusieurs annees pour regler la situation. Desole d' etre un viel utilisateur de linux et comme on dit "chat echaude craint l' eau froide".
        
        [^] # Re: Description de systemd ?
        
        Posté par microlinux (site web personnel) le 10 octobre 2014 à 00:41. Évalué à 4.
        
        On doit être les seuls dans le forum à avoir débuté sous Slackware en jonglant avec les disquettes floppy, Albert. Du coup nous voilà comme les deux vieux grincheux dans la loge du Muppet Show. Perso (et au boulot) j'ai toutes mes machines sous Slackware, et si systemd est vraiment le système d'initialisation du futur, ma foi, je l'utiliserai dans le futur. :o)
        
        Dyslexics have more fnu.
        
        [^] # Re: Description de systemd ?
        
        Posté par Albert_ le 10 octobre 2014 à 10:38. Évalué à 3.
        
        Avec la 28 eme disquettes corrompus et uniquement un acces au terminal car X11 ne supportait pas la carte graphique mais bon au moins on avait acces a des compilos de facon legale…
        
        C'est vraiment pas gentil de pointer a quel point je suis vieux :)
        
        [^] # Re: Description de systemd ?
        
        Posté par whity le 10 octobre 2014 à 15:15. Évalué à 1.
        
        On n’a pas la même notion de profiter pleinement.
        
        Donc, l’audio qui marche, c’est :
        * plusieurs applications qui font du son en même temps
        * le son qui passe sur le casque quand je le branche, avec un niveau acceptable (càd, différent de quand il était sur le hp intégré)
        * le support de plusieurs cartes sons (par exemple, la carte-son plus le micro intégré de la webcam)
        * le support multi-utilisateur (càd, quand je fais « changer d’utilisateur », j’ai du son sur la session en cours).
        
        Avec pulseaudio, désormais j’ai tout ça sans avoir à modifier un seul fichier de conf, avec une jolie interface intuitive pour la feignasse que je suis.
        
        Avec alsa, ben en fait, j’ai jamais rencontré une config où tout ça [b]à la fois[/b] marchait correctement. Et bien évidemment, il fallait triturer les fichiers de conf jusqu’à avoir une config acceptable (ah, dmix, que du bonheur…).
        
        Alors certes, il y a eu des plâtres avec PA (notamment à cause de driver pourris, mais c’est un autre débat). Mais maintenant, ça marche, et c’est infiniment mieux que ce qu’il y avait avant.
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Description de systemd ?
        
        Posté par Padishah le 10 octobre 2014 à 16:32. Évalué à 3.
        
        Je n'utilise pas PA, et sans avoir à créer de fichier asoundrc j'ai :
        
        Plusieurs applications qui font du son en même temps;
        Le volume du casque qui est géré indépendamment du volume master;
        Support multi-utilisateur;
        
        Et ceci depuis au moins 7 ans…
        
        [^] # Re: Description de systemd ?
        
        Posté par ledufakademy le 10 octobre 2014 à 15:37. Évalué à 0.
        
        Arrêtes tu est hyper obtus là !
        On ne dit pas qu'on n'aime pas systemd au niveau des perf , des features killer.
        On te parles KISS (Keep It Simple …), modularité etc.
        Et avenir aussi …
        
        system va laisser gnome aussi indépendants qu'il l'est aujourd'hui : non.
        Tu le sais très bien , systemd et sa portée qui s’étend jusqu'au login de gnome va rendre gnome (api ) orienté linux et bcp moins multiplateforme (exit : bsd, freebsd , opensolaris .. ou au prix de très gros portage)
        
        A+
        
        [^] # Re: Description de systemd ?
        
        Posté par whity le 10 octobre 2014 à 16:15. Évalué à 2.
        
        En fait, c’est faux (mais ça a été dit et redit je ne sais combien de fois).
        
        Gnome utilise des fonctionnalités fournies, à l’heure actuelle, uniquement par systemd. C’est un choix de l’équipe de gnome, pour profiter de ces fonctionnalités. systemd n’y est pour rien, la seule chose qu’on peut lui reprocher, c’est de fournir des fonctionnalités que les autres ne fournissent pas.
        
        Après, il y a deux approches pour faire marcher gnome en dehors de linux :
        
        fournir des patchs dans gnome pour que gnome utilise des solutions de contournement quand les services fournis par systemd ne sont pas disponibles. Mais globalement, la position des mainteneurs de gnome est qu’il n’en veulent pas, pour garder le code simple
        
        fournir les fonctionnalités de systemd (pour rappel : on parle d’interfaces dbus principalement, donc rien d’insurmontable) via d’autres systèmes que systemd. Le reproche principal qu’on pourrait faire, c’est que l’api des services systemd n’est pas standardisée, mais qu’elle risque de devenir un standard de fait qui s’imposera à tous, parce que de plus en plus de produits auront fait le choix d’en dépendre.
        
        Alors oui, globalement, systemd fournit beaucoup plus que juste un système d’init : il fournit une api permettant d’interagir avec le système. Un truc qui n’existait pas sous linux, et que certains trouvent particulièrement bienvenu.
        
        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
        
        [^] # Re: Description de systemd ?
        
        Posté par Zenitram (site web personnel) le 08 octobre 2014 à 07:42. Évalué à 1. Dernière modification le 08 octobre 2014 à 07:43.
        
        Ce systemd va devenir une grosse boite noire,
        
        J'attends la démonstration de comment on peut faire une boite noire libre.
        
        un binaire cela ne se tune que par le biais d'une recompilation et oui !
        
        Et?
        
        Alors qu'un script (bash pour les rc etc) l'admin sys peut le retravailler :
        
        Ben les fichiers de config aussi, et ça correspond aux scripts.
        
        Pour les cas hyper tordus pour des besoins précis, un admin sys ne sait pas lancer une compilation?
        
        on va perdre en facilité de maintenance et de personnalisation , j'en suis certain.
        
        Continue dans tes croyances que la terre est plate (les gens en étaient certains aussi, autant que toi)
        
        (un fichier de conf est limité à ses options, un script n'a de limite que notre imagination)
        
        Ca tombe bien, avec ton ficheir de config tu peux lancer un… script (comme il peut faire les logs en texte, zut alors!). systemd n'a de limite que ton imagination.
        Toujours aussi ridicules les arguments des anti-systemd, toujours les mêmes mensonges (une fois , c'est une erreur et on corrige, plus, ben c'est du mensonge) qui reviennent.
        
        L'anti-systemd est une religion : même si l'inverse est démontré, les gens continuent de dire que c'est mal.
        
        [^] # Re: Description de systemd ?
        
        Posté par barmic le 08 octobre 2014 à 09:07. Évalué à 8.
        
        J'attends la démonstration de comment on peut faire une boite noire libre.
        
        C'était le cas du pilote nVIDIA nv.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Description de systemd ?
        
        Posté par Moonz le 08 octobre 2014 à 09:37. Évalué à 4.
        
        Ben les fichiers de config aussi, et ça correspond aux scripts.
        
        Non, du tout, si je compare à l’ancien init de Arch (connais bien moi le sysvinit classique), les scripts c’est pas seulement le démarrage des services, c’est aussi toute l’initialisation du système (/etc/rc.sysinit de mémoire), c’est à dire le montage des partitions, l’hostname, luks, lvm… et c’était typiquement pratique quand tu voulais jouer avec des trucs un peu bleeding-edge qui doivent se faire à l’initialisation du système : c’était juste un coup de vim /etc/rc.sysinit (à tes risques et périls bien sûr).
        
        Pardus avait un système encore plus sympa avec l’équivalent de /etc/rc.sysinit écrit en Python (mudur je crois) qui passait ensuite la main à un gestionnaire de service à la systemd/initng. Je me souviens à l’époque de m’être fait un mélange des deux sous Gentoo, où l’init se faisait avec mudur et passait la main à initng — et ça marchait vraiment pas trop mal (et pour revenir dans le troll systemd, c’est justement ce genre d’expérimentations que le projet systemd va rendre de plus en plus difficile voire impossible).
        
        [^] # Re: Description de systemd ?
        
        Posté par freeze le 08 octobre 2014 à 10:05. Évalué à 5.
        
        Mais qu'est-ce qui t'empêche de faire une unité systemd qui fait le même job ?
        Elle n'est pas fournie (a priori) en standard, mais je ne vois pas ce qui t'empêche d'avoir une unité personnelle très tôt dans la séquence.
        
        [^] # Re: Description de systemd ?
        
        Posté par gaaaaaAab le 08 octobre 2014 à 12:06. Évalué à 1.
        
        J'attends la démonstration de comment on peut faire une boite noire libre.
        
        D'un point de vue théorique, en obscurcissant (obfuscate en anglais, c'est pas un jeu de mot débile obscure -> noir) du code libre ?
        Dans le même genre, je me souviens d'un article dans M.I.S.C. qui traitait de recherches visant à implémenter des dispositifs de DRM en boite blanche.
        
        On sort un peu du cadre du débat sur systemd, mais c'était juste pour répondre sur ce point en passant.
        
        [^] # Re: Description de systemd ?
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 14:23. Évalué à 3.
        
        J'attends la démonstration de comment on peut faire une boite noire libre.
        
        http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
        
        [^] # Re: Description de systemd ?
        
        Posté par xcomcmdr le 08 octobre 2014 à 08:00. Évalué à 4.
        
        un binaire cela ne se tune que par le biais d'une recompilation et oui !
        
        Euh, les options dans les multiples fichiers de config, au lancement, et dans les unit files, et la rétro-compatibilité avec les scripts, c'est pour les chiens ?
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Description de systemd ?
        
        Posté par Tonton Th (Mastodon) le 09 octobre 2014 à 13:59. Évalué à 1.
        
        Et extrèment efficace (temps de boot avec un ssd de dingue, plus vite que le bios !!)
        
        Booter, certes, mais pourquoi rebooter ?
    - [^] # Re: Description de systemd ?
      
      Posté par ZeroHeure le 07 octobre 2014 à 09:25. Évalué à 4.
      
      Et si Linux incluait un module remplaçant mail ? un client ftp ? (minimaliste, bien sûr, enfin, au début…)
      
      Mais il l'a fait par le passé !
      Pas ces outils là, mais par exemple un serveur web minimaliste avec cgi. C'est resté en place quelques années.
      
      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Merci Systemd.

Posté par Kwiknclean le 06 octobre 2014 à 22:56. Évalué à -10.

Grâce à toi, j'ai découvert le monde BSD, merci 1000 fois.
- [^] # Re: Merci Systemd.
  
  Posté par xcomcmdr le 07 octobre 2014 à 07:54. Évalué à 2. Dernière modification le 07 octobre 2014 à 07:54.
  
  Le monde qui a dix ans de retard ? ;-)
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: Merci Systemd.
    
    Posté par wolowizard le 07 octobre 2014 à 08:07. Évalué à -2. Dernière modification le 07 octobre 2014 à 08:11.
    
    non, non le monde sans système d ;-)
    - [^] # Re: Merci Systemd.
      
      Posté par claudex le 07 octobre 2014 à 19:09. Évalué à 6.
      
      C'est bien ce qu'il dit.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Merci Systemd.
    
    Posté par Kwiknclean le 20 octobre 2014 à 23:18. Évalué à 1.
    
    Je viens de finir un peu de tuner ma conf packet filter pour mes jails et clairement pour le coup j'ai l'impression que
    c'est la c'est bien Iptable qui a quelques années de retards.
    
    Plus j'utilise FreeBSD plus j'apprécie, c'est clair, cohérent, carré, méthodique, un véritable outil de production.
    
    (En usage serveur j'entends, j'suis pas assez maso/barbu pour l'utiliser en desktop non plus hein).
# Problème de traduction

Posté par Cilyan Olowen (site web personnel) le 07 octobre 2014 à 20:48. Évalué à 3.

J'ai l'impression que peu de gens ont lu l'article avant d'aller cogner sur leur cible préférée…

FailureAction= peut être utilisé pour définir une opération à déclencher quand un service échoue : ce paramètre fonctionne de façon similaire à StartLimitAction= mais, contrairement à celui-ci, il vérifie ce qui est effectué immédiatement, plutôt qu’après plusieurs essais de redémarrage du service ;

Je propose plutôt "il spécifie une action effectuée immédiatement après un échec, …"

La socket /dev/log et la FIFO /dev/initctl ont été déplacées vers /run et ont été remplacées par des liens symboliques. Cette modification permet de se connecter à elles même si PrivateDevices=yes est utilisé pour un service.

Là j'avais pas compris. En fait il manque probablement une virgule entre "elles" et "même", mais vu que dans l'article ils parlent de "these facilities", je suggère de plutôt remplacer "elles" par "ces services" ou quelque chose de similaire.

Après, j'ai relevé quelques coquilles secondaires:

la détection de la virtualisation fonctionne maintenant sans privilège s.

et

afficher plusieurs de ces chemins concernant la machine et l’utilisateur locaux.

En tous cas, chapeau pour la traduction et la réorganisation.
- [^] # Re: Problème de traduction
  
  Posté par ariasuni le 08 octobre 2014 à 01:51. Évalué à 3.
  
  Merci pour cette relecture. Ça m’a pris des heures et des heures et je ne suis pas le seul à avoir contribué (on dirait pas comme ça, mais c’est un gros boulot), donc ça ne m’étonne pas qu’on ait loupé certains trucs.
  
  Écrit en Bépo selon l’orthographe de 1990
# Assimilation forcée

Posté par almire le 09 octobre 2014 à 12:47. Évalué à -9.

Vraiment triste que son usage s'impose comme la norme, par suivisme de DeadRat, dans les distributions principales, avec les problèmes fondamentaux qu'il entraîne.

Beaucoup de propagande pour présenter systemd comme une rupture et un progrès inéluctables, et une mise à l'écart malsaine et malhonnête des nombreuses alternatives sensées.

http://boycottsystemd.org
- [^] # Re: Assimilation forcée
  
  Posté par xcomcmdr le 09 octobre 2014 à 13:42. Évalué à 3.
  
  On a mis un flingue sur la tempe des mainteneurs de Fedora, Archlinux (une des premières à y passer), Debian, Ubuntu (qui aurait pu très bien continuer à maintenir Upstart) ?
  
  Ça dénonce grave !
  
  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
- [^] # Re: Assimilation forcée
  
  Posté par ariasuni le 09 octobre 2014 à 19:06. Évalué à 6.
  Vraiment triste que son usage s'impose comme la norme par suivisme de DeadRat, dans les distributions principales,
  
  Là tu insultes l’intelligence de l’ensemble des mainteneurs des distributions concernés ayant effectué ce choix.
  
  avec les problèmes fondamentaux qu'il entraîne.
  
  Bah à part la façon dont le projet est géré, je ne vois en quoi les distributions fonctionnent moins bien.
  
  Beaucoup de propagande pour présenter systemd comme une rupture et un progrès inéluctables,
  
  Bah, de la publicité pour le logiciel ça n’est pas interdit? Jusqu’à présent, je ne crois pas qu’il y ait beaucoup de mensonges à propos de systemd (s’il y en a eu).
  
  et une mise à l'écart malsaine et malhonnête des nombreuses alternatives sensées.
  
  Ouais, non.
  
  http://boycottsystemd.org
  
  Ça fait du bien de rigoler de temps en temps.
  1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries^1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.
  Sur la page du lien de la note ¹, on y trouve une «justification» de l’argument 1. Or sur cette même page, il lien vers une page du même auteur qui démonte complètement cet argument.
  
  In a way, you are right. systemd centralizes complexity from tons of init scripts into a single place. However, it therefore makes it very easy for maintainers to write service files (equivalent of an init script) and provides a consistent and reliable interface for service management. Furthermore, it is different than sysvinit, and different solutions often seem complex at first. While systemd consumes more resources than sysvinit, it uses them to make more information available about services; its finer-grained service management requires more state-keeping, but in turn offers you more control over your services.
  
  Ah, et peut-être que la philosophie Unix ne s’applique pas à tous les cas, de façon littérale, telle une religion. De plus systemd n’est pas un énorme composant unique mais plutôt bien découpé.
  1. systemd's journal files (handled by journald) are stored in a complicated binary format^2, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID-compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. No, seriously. Oh, and there's embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.
  Ça tombe bien, on est pas censé gérer le journal, c’est journald qui s’occupe de nous sortir quelque chose d’intelligible (un peu comme une base de données et son frontal). Autrement, je dirais que le format est complet, extensible et bien documenté. Pas vraiment une catastrophe.
  
  Pour la corruption, ça arrive rarement et il est possible (si ça n’est pas le cas par défaut) de faire de la rotation de journaux. Je ne saurais dire autrement si le format en lui-même peut permettre de retrouver facilement les bonnes informations après corruption partielle cependant.
  
  Quand à la mention des deux bibliothèques, Lennart y a répondu. Je ne me prononcerais pas sur la pertinence, mais franchement quand on sait que ça peut être utile et très léger, il n’y a pas de quoi en faire tout en fromage.
  1. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.
  Au cas où cette argument n’a pas été suffisamment démonté: c’est un procès d’intention (ils ne font pas un site s’appelant boycottunix.org non plus hein), les deux précédentes solutions ne fonctionnent pas sur BSD[^1] (scripts d’initialisation propres à chaque distribution ou Upstart). De plus ça ne change rien à la portabilité des logiciels ou à un quelconque enfermement (comme dit avant, les autres solutions ne marchaient pas mieux sur BSD).
  1. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago^3. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency.
  J’ai l’impression que c’est la faute de systemd alors que la fusion a eu lieu parce que son mainteneur a bien voulu. Et malgré tout ce qu’on pourra dire, c’est bien le droit du mainteneur du logiciel d’en faire ce qu’il veut, même si ça ne nous plait pas…
  
  Ceci étant dit, on peut regretter que la compatibilité avec les systèmes non-systemd ne soit pas assurée. D’un autre côté le projet s’appelle systemd. L’équipe de systemd a déjà fait un gros boulot pour prendre en charge les anciens scripts d’initialisation.
  
  Au lieu que chaque distribution ait sont truc à maintenir, il n’y aura du boulot que pour ceux n’utilisant pas systemd, ce qui est dommage mais logique (et les distributions non-systemd peuvent mutualiser leurs efforts également).
  
  Mais allons directement à l’avant-dernier argument:
  1. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.
  On dirait le discours des anti-mariage pour tous, pathétique. La moitié des choses est choses.
  
  postmodern
  
  Anticiper un peu le futur c’est mal? On préfère rester des vieux cons et avoir un métro de retard comme d’habitude?
  
  monolithic
  
  Ai-je besoin de dire pourquoi c’est faux?
  
  heavily desktop-oriented
  
  Ça n’empêche pas de fonctionner sur serveur (et systemd existe en embarqué aussi — quand ça n’est pas possible de l’utiliser c’est pareil qu’avant, on fait un truc personnalisé).
  
  choice-limiting
  
  Certes, ça demande un peu de travail pour ceux qui n’utilisent pas la solution standard. Mais encore une fois je trouve qu’on exagère en disant vehemantly.
  
  isolationist
  
  En quoi ça isole Linux de quoi? Avant c’était en théorie portable sur BSD mais tout le monde s’en foutait. Maintenant c’est plus possible et BSD s’en fout.
  
  reinvents the flat tire
  
  Ils ont refait Upstart en mieux, et à priori les démons que l’on appelle NIH sont simplement des versions légères pour les cas les plus simples et donc les plus courants (genre presque tout le monde, les autres sauront modifier, avec systemd c’est pas compliqué).
  
  just a huge anti-pattern
  
  Sérieusement? Je pourrais dire la même chose de ce qu’il y avait avant…
  
  Est-ce que je dois continuer ou c’est bon? Ce site web contient beaucoup d’arguments mille fois démontés, dommage ça noie les arguments pertinents dans la masse de connerie.
  
  [1]: On peut remplacer BSD par autre choses hein, c’est juste que c’est le plus souvent cité.
  
  Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.