Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio

Posté par ariasuni le 21 mars 2014 à 14:16. Édité par Davy Defaud, BAud, antistress, palm123, Benoît Sibaud, Melkor73, stiffux, ZeroHeure, Jarvis, patrick_g, Sébastien Koechlin, Jiehong, liberforce et Kfadelk. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

mar.

2014

La sortie de la dernière version de PulseAudio coïncide avec celle de trois nouvelles versions de systemd, c’est donc l’occasion de faire une dépêche spéciale Lennart Poettering !

Lennart Poettering <3

photo de Harald Hoyer sous CC-BY-SA-3.0

PulseAudio

Lien de l’annonce

En résumé

prise en charge de BlueZ 5 (A2DP seulement) ;
ré‐implémentation des modules tunnel ;
prise en charge de systemd-journal comme système de journalisation ;
petits changements çà et là ;
beaucoup de corrections de bogues.

Prise en charge de BlueZ 5 (A2DP seulement)

Posons d’abord le décor : les développeurs du projet BlueZ ont décidé de refaire leur interface (de programmation) client. Ils ont aussi décidé d’abandonner la prise en charge de l’ancienne interface. BlueZ 4 a l’ancienne interface et BlueZ 5 a la nouvelle. La décision d’abandonner la prise en charge de l’ancienne interface dans BlueZ 5 signifie que toutes les applications, incluant PulseAudio, qui fonctionnaient avec BlueZ 4 ne fonctionneront pas avec BlueZ 5.

La gestion de BlueZ 5 a progressivement été ajoutée dans diverses applications, et c’est la première version de PulseAudio qui prend en charge BlueZ 5. Cela signifie que tout est bien, n’est‐ce pas ? Pas vraiment. Le projet BlueZ a aussi décidé d’abandonner la prise en charge des profils HSP et HFP, qui étaient les profils qui avaient la responsabilité de gérer la téléphonie audio. Si vous avez un casque, son microphone ne va pas fonctionner avec BlueZ 5, parce que le microphone est seulement géré par les profils HSP et HFP.

Des distributions ont migré vers BlueZ 5 sans fournir aux utilisateurs la possibilité de rester avec BlueZ 4. Certaines de ces distributions ont probablement fait la transition sans en comprendre les conséquences — elles ont maintenant une sérieuse régression en termes de fonctionnalités, car les casques de leurs utilisateurs ont cessé de fonctionner (d’accord, les casques peuvent toujours être utilisés pour écouter de la musique, mais ils sont inutiles pour les applications de VoIP).

Les développeurs de GNOME ont aussi pris la décision, peut‐être en étant mal informés, d’abandonner la prise en charge de BlueZ 4 dans la dernière version de leur environnement, ce qui signifie que passer à la version courante de GNOME (3.10) pose un problème différent en fonction de la version de BlueZ du système : avec BlueZ 4, l’interface utilisateur de GNOME pour gérer le Bluetooth ne va pas fonctionner et, avec BlueZ 5, la gestion des casques audio sera castrée.

Comment refaire fonctionner les profils HSP et HFP avec BlueZ 5 ? Il sont partiellement gérés dans oFono (un démon de téléphonie), qui va heureusement être terminé prochainement, et la prochaine version de PulseAudio gèrera donc HSP/HFP via oFono. Cela rajoute une pile de téléphonie comme dépendance à PulseAudio pour utiliser vos casques Bluetooth, ce qui peut être considéré comme excessif. Ce problème reste à résoudre avec les développeurs de BlueZ.

Maintenant, les détails techniques à propos de la gestion de BlueZ 5 dans PulseAudio ; il y a désormais des modules séparés pour BlueZ 4 et BlueZ 5 : module-bluez4-discover et module-bluez5-discover. L’ancien module-bluetooth-discover existe toujours et est utilisé dans la configuration par défaut. module-bluetooth-discover est maintenant une couche d’abstraction : il va charger module-bluez4-discover et/ou module-bluez5-discover en fonction de ce qui est présent sur le système. Cela signifie que la migration vers Bluez 5 peut être effectuée sans changer la configuration de PulseAudio.

Ré-implémentation des modules tunnel

Les anciens module-tunnel-sink et module-tunnel-source ont une implémentation indépendante du protocole client de PulseAudio. Il y a une autre implémentation dans libpulse, qui est utilisée par les applications pour discuter avec le serveur PulseAudio. C’est clairement une duplication d’efforts et cela rend la maintenance des modules tunnel beaucoup plus dure qu’elle ne devrait l’être.

Dans le cadre d’un projet GSoC, Alexander Couzens a ré‐implémenté les modules tunnel pour qu’ils utilisent libpulse au lieu d’implémenter les détails du protocole eux‐mêmes. Ils sont maintenant disponibles sous les noms module-tunnel-sink-new et module-tunnel-source-new. L’implémentation n’est pas tout à fait complète, ce qui explique que les anciens modules existent toujours, mais les nouvelles versions peuvent déjà être testées (si vous avez des problèmes avec la qualité de la diffusion audio des anciens modules tunnel, ça vaut la peine de voir si les nouveaux modules fonctionnent mieux). Notez que si vous utilisez module-tunnel-sink-new ou module-tunnel-source-new dans un fichier de configuration, ce fichier de configuration ne fonctionnera plus quand ces modules seront terminés car le suffix -new sera supprimé du nom du module.

Prise en charge de systemd-journal

Une nouvelle cible pour le système de journalisation a été ajoutée : « journal ». Il est utilisé par défaut si PulseAudio est compilé avec prise en charge de systemd-journal. La nouvelle cible pour le système de journalisation est aussi gérée dans daemon.conf (option log-target), par la ligne de commande (option --log-target) et dans pacmd (commande set-log-target).

systemd

Voici une traduction des journaux des modifications concernant systemd. Les changements les moins importants et / ou trop techniques n’ont pas été traduits, et nous vous invitons alors à consulter les notes de version originales.

Un petit résumé pour les pressés : beaucoup d’améliorations et d’ajouts concernant la sécurité, quelques nettoyages et surtout beaucoup de nouvelles fonctionnalités dont certaines raviront l’utilisateur final, comme une meilleure prise en charge de la fermeture d’un écran d’ordinateur portable et la sauvegarde et restauration de la luminosité de l’écran.

Sur une note un peu plus technique, on pourra aussi noter l’implémentation de kdbus de plus en plus complète, une meilleure prise en charge de SELinux et d’options de sécurité, une syntaxe pour écrire des unités qui s’enrichit encore pour permettre plus de flexibilité, de sécurité et de contrôle sur les processus, et la fonctionnalité qui permet de démarrer sans /etc/fstab s’améliore pour gérer encore plus de cas.

Note : côté sécurité mais un peu en marge, la version 3.0 des pilotes Intel pour X.Org permettra à ce dernier de tourner sans les droits root en s’appuyant sur systemd/logind (le défunt OS Moblin 2.0 avait étrenné dès 2009 cette fonctionnalité rendue théoriquement possible par KMS).

systemd 209

Lien de l’annonce

Un nouveau composant nommé systemd-networkd a été ajouté. Il peut être utilisé pour configurer les interfaces du réseau local, statiquement ou via DHCP. Il est capable de construire des ponts (bridges), des réseaux locaux virtuels (VLAN), et d’agréger des liens. À l’heure actuelle, aucun script pour la configuration interactive de réseaux n’est fourni. Utilisez‐le pour votre initrd, conteneur, configuration embarquée ou serveur si vous avez besoin d’une solution de configuration réseau simple mais puissante. Sa conception est plutôt ingénieuse, car il permet le filtrage par métacaractère parmi les interfaces branchées à chaud. Par exemple, avec un seul bout de configuration, vous pouvez faire en sorte que toutes les interfaces Ethernet qui apparaissent soient automatiquement ajoutées à un pont, ou des choses similaires. Il gère le link-sensing et bien plus.
Un nouvel outil appelé systemd-socket-proxyd a été ajouté. Il agit comme un serveur mandataire (proxy) bidirectionnel pour les sockets TCP. C’est utile pour ajouter la prise en charge de l’activation par socket aux services qui ne la prennent actuellement pas en charge, incluant les machines virtuelles et compagnie.
Ajout d’un nouvel outil pour sauvegarder et restaurer l’état des interrupteurs physiques (rfkill) à l’arrêt et au redémarrage.
Sauvegarde et restauration de l’état du rétro‐éclairage du clavier et de la luminosité de l’écran.
Une nouvelle option de ligne de commande du noyau — systemd.restore_state=1|0 — permet d’activer et désactiver les restaurations des états sauvegardés des périphériques matériels. Plus précisément, les états des interrupteurs matériels et du rétroéclairage ne sont pas restaurés.
udev possède maintenant une nouvelle construction SECLABEL{} pour étiqueter les nœuds de périphériques avec une étiquette de sécurité spécifique quand ils apparaissent. Pour le moment, seulement SECLABEL{selinux} est pris en charge, mais la syntaxe est prête pour des environnements de sécurité additionnels.
systemd ne dépend plus de libdbus. Toute la communication est désormais effectuée avec sd-bus, l’implémentation de la bibliothèque de bus bas niveau de systemd.
la prise en charge de kdbus a été ajoutée au processus n^o 1 (PID 1) lui‐même. Quand kdbus est activé, le PID 1 met en place le bus système et active la prise en charge d’un nouveau type d’unité .busname qui encapsule l’activation des noms de bus dans kdbus. Ça fonctionne un petit peu comme les unités .socket, excepté pour les noms de bus. Un nouveau générateur a été ajouté qui convertit automatiquement les fichiers d’activation de service dbus1 classiques aux formats .busname et .service natifs de systemd.
Un démon mandataire (proxy) est maintenant fourni aux clients proxy se connectant via les sockets D-Bus AF_UNIX classiques vers kdbus, pour fournir une compatibilité totale avec le D-Bus classique.
Un pilote de bus qui gère la compatibilité avec les appels D-Bus classiques a été implémenté.
L’option de compatibilité FsckPassNo= dans les unités de montage et de service a été supprimée. Le générateur de table de montage de systèmes de fichiers (fstab) ajoutera désormais automatiquement les dépendances nécessaires, et ne nécessite plus de gestion par le PID 1.
journalctl a gagné une nouvelle option, --list-boots, qui liste les démarrages récents avec leur date et identifiant de démarrage.
Les divers outils tels que systemctl, logintctl, timedatectl, busctl, systemd-run, etc., ont obtenu une nouvelle option -M pour se connecter à un conteneur de système d’exploitation local (connexion directe sans utiliser SSH). Cela fonctionne sur n’importe quel conteneur qui est enregistré avec machined, comme ceux créés par libvirt-lxc ou nspawn.
systemd-run et systemd-analyze ont aussi obtenu l’ajout de l’option -H pour se connecter à un hôte distant via SSH. C’est particulièrement utile pour systemd-run, car cela permet de mettre en file d’attente des tâches sur des systèmes distants.
machinectl a obtenu une nouvelle commande login pour ouvrir une connexion getty dans n’importe quel conteneur local. Cela fonctionne avec n’importe quel conteneur enregistré avec machined (comme ceux créés avec libvirt-lxc ou nspawn), et qui font tourner systemd à l’intérieur.
machinectl a gagné une nouvelle commande reboot qui peut être utilisée pour lancer un redémarrage sur un conteneur spécifique enregistré avec machined. Cela fonctionne sur n’importe quel conteneur qui possède un système d’initialisation quelconque.
systemctl a obtenu une nouvelle commande, list-timers, qui affiche une liste sympathique des unités timer avec le temps qu’il reste avant leur prochaine échéance.
Des paramètres alternatifs de reboot() peuvent maintenant être spécifiés sur la ligne de commande systemctl reboot, et seront passés à l’appel système reboot().
Il existe désormais dans /etc/systemd/systemd.conf de nouveaux paramètres pour configurer les temps d’expiration des unités, ainsi que l’intervalle limite de départ et de burst. Ils peuvent toujours être redéfinis dans chaque unité.
Lors de la redirection du journal vers la console avec journald, l’horodotage est maintenant inclus (en fonction du paramètre dans /sys/module/printk/parameters/time).
OnCalendar= dans les unités timer comprend maintenant les chaînes de caractères spéciales yearly et annually (les deux sont équivalentes).
La précision des unités timer est maintenant configurable avec le nouveau paramètre AccuracySec=. Sa valeur par défaut est de 1 minute.
Un nouveau type de dépendance JoinsNamespaceOf= a été ajouté, il permet de lancer deux services dans les mêmes répertoire /tmp et espace de noms de réseau, si PrivateNetwork= ou PrivateTmp= sont utilisés.
Une nouvelle commande cat a été ajoutée à systemctl. Elle affiche le fichier d’unité original d’une unité, et le concatène avec le contenu des fichiers de configuration supplémentaires, affichant ainsi la configuration complète.
systemctl gère désormais les métacaractères pour les diverses commandes list-xyz, comme list-units et list-sockets, ainsi que pour les commandes qui prennent plusieurs noms d’unités en paramètres.
L’option --unit= de journalctl a obtenu la prise en charge des métacaractères.
Tous les démons systemd utilisent maintenant la logique de chien de garde (watchdog), systemd remarque donc automatiquement quand ils restent bloqués.
La base de données de matériel d’_udev_ contient désormais des informations sur les vendeurs et produits des appareils SDIO.
Les services par connexion activés par socket incluent maintenant une courte description des paramètres de connexion dans la description.
Une nouvelle option PrivateDevices= a été ajoutée aux unités de service, ce qui permet de faire tourner un service dans un répertoire /dev situé dans un espace de noms qui ne contient aucun nœud pour les périphériques physiques. Plus précisément, il contient seulement les périphériques tels que /dev/null, /dev/urandom et /dev/zero qui sont les points d’entrée de l’API.
logind a été étendu pour gérer des comportements tels que le changement de terminal virtuel sur les sièges qui ne prennent pas en charge un terminal virtuel. Cela rend le multi‐session disponible sur les sièges qui ne sont pas le premier (seat0), et sur les systèmes où la gestion par le noyau pour les terminaux virtuels a été désactivée à la compilation.
Si un processus maintient un verrou de délai pour la mise en veille ou l’arrêt du système et n’arrive à le libérer à temps, son identité sera désormais enregistrée dans le journal. Cela rend plus facile l’identification des processus qui provoquent des lenteurs lors de ces deux opérations.
Lors de l’analyse du fichier /etc/crypttab, la gestion d’une nouvelle option key-slot=, identique à celle de Debian, a été ajoutée. Cela permet d’indiquer quel emplacement LUKS utiliser sur le disque, accélérant le chargement de la clé.
La sortie du statut de démarrage est maintenant activée automatiquement après un court délai si le démarrage ne progresse pas, dans le but de donner à l’utilisateur une indication de ce qu’il attend.
La sortie au démarrage a été améliorée pour montrer combien de temps il reste avant que la tâche soit périmée.
L’option KillMode dans les unités de service a obtenu une nouvelle valeur possible, mixed. Si utilisée, et que l’unité est arrêtée, alors le SIGTERM initial est seulement envoyé au processus principal du démon, tandis que le signal SIGKILL suivant est envoyé à tous les processus restants du service.
Lors de la lecture des fichiers d’unité, systemd vérifie désormais les droits d’accès à ses fichiers, et affiche un avertissement pour certaines combinaisons suspectes. Cela a été ajouté pour rendre plus facile la vérification d’erreurs d’empaquetage où les fichiers d’unité sont marqués exécutables ou en écriture pour tout le monde.
systemd-nspawn a été mis à jour pour créer un nouveau domaine kdbus pour chaque conteneur qui est invoqué, permettant alors à chaque conteneur d’avoir son propre ensemble de bus système et utilisateur, indépendant de l’hôte.
systemd-nspawn a obtenu une nouvelle option, --drop-capability=, qui permet de lancer le conteneur avec moins de capacités que par défaut. --drop-capabilité= et --capability= acceptent maintenant tous les deux la chaîne spéciale all pour abandonner ou garder toutes les capacités.
systemd-nspawn a gagné une nouvelle option pour exécuter les conteneurs avec des étiquettes SELinux spécifiques mises en place.
logind va maintenant suivre un identifiant « Desktop » pour chaque session qui code l’environnement de bureau de cette dernière. C’est utile pour les environnements de bureau qui veulent identifier facilement plusieurs sessions en cours d’eux‐mêmes.
Un nouveau paramètre SELinuxContext= pour les unités des services a été ajouté et permet de spécifier un contexte d’exécution SELinux spécifique pour un service.
La plupart des outils client de systemd respecteront désormais la variable d’environnement $SYSTEMD_LESS pour le visualiseur de texte. Par défaut, ces outils outrepasseront $LESS pour permettre à certaines opérations de fonctionner, telles que le « saut à la fin ». Avec $SYSTEMD_LESS, il est possible d’influencer cette logique. (NdR : cette dépêche a permis de découvrir un bogue avec Mathjax.)
Le script seccomp de systemd a été modifié pour utiliser la libseccomp au lieu d’utiliser sa propre implémentation. Cela a pour avantage une meilleure portabilité parmi d’autres choses.

systemd 210

Lien de l’annonce

systemd va maintenant ré‐étiqueter /dev après le chargement de la politique SMACK en fonction des règles SMACK.
Une nouvelle option pour les unités AppArmoreProfile= a été ajoutée pour définir le profil AppArmor du processus d’une unité.
Une nouvelle vérification de condition ConditionArchitecture= a été ajoutée pour rendre l’unité conditionnelle en fonction de l’architecture du système, comme rapporté par le champ « machine » de la commande uname.
systemd-networkd peut maintenant filtrer par système de virtualisation, architecture, ligne de commande du noyau, nom d’hôte, et identifiant de la machine.
Le comportement de logind est maintenant beaucoup plus vigilant lors de la suspension de la machine à cause d’un écran rabattu. Au lieu d’agir seulement lors du rabat de l’écran, il va surveiller en permanence son statut et agir en conséquence. C’est utile pour les ordinateurs portables sur lesquels le bouton d’allumage est à l’extérieur du châssis et peut être actionné sans ouvrir l’écran (comme le Lenovo Yago). Sur ces machines, logind va immédiatement remettre en veille la machine si le bouton a été pressé par accident pendant que l’ordinateur était en veille et dans un sac à dos ou autre.
nspawn va désormais utiliser le gestionnaire cgroup des périphériques par défaut, et seulement permettre la création et l’accès aux nœuds de périphériques de l’API comme /dev/null ou /dev/random, ainsi que l’accès aux (mais pas la création de) périphériques tpy.
systemd comprend désormais les suffixes usuels M, K, G, T selon les normes du système international d’unités (c’est‐à‐dire en base 1000) lorsque qu’utilisé pour décrire des flux et des métriques matérielles. Il conservera les conventions de la commission électrotechnique internationale (c’est‐à‐dire en base 1024) pour les métriques logicielles, selon ce qui est habituel d’après Wikipédia. Chaque option de configuration documente explicitement quelle base est utilisée.
Le paramètre DeviceAllow= dans les fichiers d’unités prend désormais en charge une syntaxe pour mettre sur liste blanche un groupe entier de nœuds de périphériques d’un seul coup, en se basant sur la liste de /proc/devices. Par exemple, avec la chaine char-pts, il est maintenant possible de mettre sur liste blanche tous les pseudo‐terminaux virtuels courants et futurs en une seule fois.
systemd-networkd n’est plus activé statiquement, il utilise la section habituelle [Install] afin d’être activable et désactivable avec systemctl. Il est tout de même encore activé par défaut.

systemd 211

Lien de l’annonce

Une nouvelle option pour les fichiers d’unités RestrictAddressFamilies= a été ajoutée pour restreindre à quelles familles d’adresses de sockets les processus d’unités ont accès. Cela prend les noms de famille d’adresses tels que AF_INET et AF_UNIX, et est pratique pour minimiser la surface d’attaque de services via des piles de protocoles exotiques. Cela fait partie du système de filtrage d’appels systèmes de seccomp.
Deux nouveaux paramètres pour les unités ont été ajoutés pour gérer des dossiers de runtime par démon sous /run: RuntimeDirectory= et RuntimeDirectoryMode=. Cela permet de remplacer la mise en place de permissions appropriées avec des bouts de code de tmpfiles, et possède l’avantage que la durée de vie du dossier est limitée à celle du démon et que le démon commence avec un dossier vide à chaque fois. C’est particulièrement pratique lors de l’écriture de services qui se débarrassent de privilèges avec les paramètres User= et Group=.
Le paramètre d’unité DeviceAllow= supporte maintenant les métacaractères pour sélectionner les noms d’un groupe de périphériques.
Le fichier de configuration systemd.conf possède désormais les paramètres DefaultCPUAccounting=, DefaultBlockIOAccounting= et DefaultMemoryAccounting= pour activer ou désactiver globalement la compatibilité de ses ressources (cgroups) pour toutes les unités. Ces paramètres peuvent cependant toujours être écrasés par chaque unité individuellement.
systemd-gpt-auto-generator est maintenant capable de découvrir les partitions /srv et racine en plus de /home et des partitions d’échange (swap). Il prend maintenant aussi en charge les partitions chiffrées avec LUKS. Avec tout cela en place, la découverte automatique des partitions à monter suivant la spécification des partitions découvrables est maintenant beaucoup plus complète. Cela permet de démarrer sans fichier /etc/fstab et sans paramètre root= dans la ligne de commande du noyau sur les systèmes préparés correctement.
systemd-nspawn gagne une nouvelle option --image= qui permet de démarrer des images disques et des installations GNU/Linux sur n’importe quel périphérique bloc qui suit la spécification des partitions découvrables (voir au‐dessus). Cela signifie que les installations faites avec des installeurs mis à jour de façon appropriée peuvent maintenant être démarrées et déployées en utilisant le gestionnaire de conteneurs, sans aucune modification (nous espérons que libvirt-lxc ajoutera bientôt la prise en charge de cette fonctionnalité également).
system-networkd peut désormais configurer les adresses locales en utilisant IPv4LL.
Le nouvel outil systemd-network-wait-online a été ajouté pour attendre de façon synchrone la disponibilité du réseau en utilisant systemd-networkd.
Les dossiers de runtime définis pour chaque utilisateur par la variable $XDG_RUNTIME_DIR sont maintenant des instances individuelles de tmpfs, ce qui a pour avantage d’introduire des groupes séparés pour chaque utilisateur, avec des limites de tailles individuelles. Cela permet de s’assurer qu’un client non privilégié ne puisse plus affecter négativement le système ou d’autres utilisateurs en remplissant leurs répertoires $XDG_RUNTIME_DIR. La nouvelle option RuntimeDirectorySize= dans logind.conf permet de contrôler la taille limite par défaut pour tous les utilisateurs. Cela utilise par défaut 10 % de la mémoire physique disponible. Ce n’est cependant pas un remplacement pour les quotas sur tmpfs (ce que le noyau ne gère toujours pas), car /dev/shm et /tmp sont toujours des ressources partagées entre le système et les utilisateurs non privilégiés.
logind va maintenant désactiver automatiquement la mise en veille lors du rabat de l’écran d’un ordinateur portable si plus d’un écran est connecté. Il était auparavant prévu que ça soit implémenté individuellement par les environnements de bureau (comme GNOME). Cependant, cela a été ajouté à logind pour éviter au démarrage le scénario dans lequel un environnement n’aurait pas été démarré et donc n’aurait pas pu placer de verrou inhibiteur à temps.
logind va désormais attendre au moins 30 s après chaque cycle de mise en veille et reprise du système, et 3 min après le démarrage du système pour mettre en veille le système dû au rabat d’un écran d’ordinateur portable. Cela devrait donner assez de temps aux stations d’accueil USB et appareils similaires pour être reconnus et configurés après la reprise du système et le démarrage pour agir comme bloqueur de mise en veille.
systemd-run a obtenu un nouveau paramètre --property qui permet d’initialiser les propriétés de contrôle de ressource (et d’autres choses) pour les cadres (scope) créés ou les unités de service. Exemple : systemd-run --property=BlackIOWeight=10 updatedb peut être utilisé pour lancer updatedb avec une priorité d’ordonnancement des entrées‐sorties faible.
Quand systemd est compilé avec la prise en charge de kdbus, la gestion basique des politiques imposées est maintenant en place. (Notez qu’activer kdbus annule toujours votre garantie, et qu’aucune promesse de compatibilité d’API n’est faite).

DLFP

[source]

# De plus en plus complexe, le système d'init...

Posté par Xavier Teyssier (site web personnel) le 21 mars 2014 à 14:29. Évalué à 8.

Wahouh ! C'est terrifiant, je n'ai rien compris ! Peut-être suis-je mal réveillé, mais ça parle d'unités, de timers, de conteneurs, ça évoque je ne sais combien d'applications différentes qui commencent par systemd-*… Wahouh !
Ce truc devient particulièrement complexe ! Ce qui est un peu effrayant quand on voit qu'une part non négligeable de la stabilité du système en dépend…

Question aux utilisateurs avancés du truc : est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd, sur ses différents modules et comment les utiliser ?
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par ʭ ☯ le 21 mars 2014 à 14:50. Évalué à 10. Dernière modification le 21 mars 2014 à 14:51.
  
  est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd ?
  
  Oui. Il fait/sait faire/peut faire le café.
  
  Blague à part, tu as cherché un peu je suppose avant de dire ça? C'est sûr qu'un système d'init sait gérer la mise en veille par exemple est forcément plus complexe qu'un lanceur de services. Alors oui la compréhension du démarrage de linux devient plus complexe, mais quand le boulot est bien fait par ta distribution, l'administration devient plus simple.
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par claudex le 21 mars 2014 à 14:50. Évalué à 10.
  
  systemd, ce n'est pas que un système d'init. La stabilité du système de dépend pas de tous les processus relatif à systemd.
  
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par Sylvain Blandel le 21 mars 2014 à 14:57. Évalué à 10.
  
  est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd, sur ses différents modules et comment les utiliser ?
  
  En général, les pages du manuel sont bien écrites. La page d'accueil de systemd recèle également de nombreux liens pertinents.
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par ariasuni le 21 mars 2014 à 16:02. Évalué à 9.
  
  Dans les notes de version il y a avait aussi des trucs concernant la simplification des bibliothèques (suppression des dépendances circulaires, ce qui simplifie beaucoup la compilation).
  
  Après il y a aussi beaucoup de changements listés correspondant aux outils qui sont l'interface utilisateur, donc si tu fais pas d'admin tu t'en fous la plupart du temps, et la complexité de ces outils n'a aucun impact sur le PID1.
  
  Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par ParaDoxe le 21 mars 2014 à 16:19. Évalué à 3.
  
  systemd is a system and service manager for Linux.
  
  Source: http://www.freedesktop.org/wiki/Software/systemd/
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par Tonton Benoit le 21 mars 2014 à 22:23. Évalué à 10.
  
  Ce truc devient particulièrement complexe ! Ce qui est un peu effrayant quand on voit qu'une part non négligeable de la stabilité du système en dépend…
  
  Dit toi qu'avant on faisait déjà tout ça à la gruik et en bash, ce qui est bien pire.
  
  Je vient justement d'avoir un bug à cause d'un initscript qui change les permissions d'un socket avant que l’application ne le crée.
  
  Question aux utilisateurs avancés du truc : est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd, sur ses différents modules et comment les utiliser ?
  
  Les pages man ? Gmane ? Si y'a bien un truc qu'on peut pas reprocher à Lennart c'est la documentation, systemd est probablement le système d'init le mieux documenté à ce jour, en tout cas bien mieux que Upstart ou OpenRC !
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par Jean Parpaillon (site web personnel) le 22 mars 2014 à 14:49. Évalué à 9.
  
  Mais vous en avez pas marre de cracher sur systemd, avec l'argument le plus pourri qui soit: "je n'y comprend rien !". Si tu n'y comprend rien, passe ton chemin ou documente-toi, mais ne vas pas dire que c'est nul parce que tu ne comprend pas.
  
  Pour faire de Linux un système enfin utilisable par tout le monde, il s'est complexifié. En tant que développeur, j'accepte de ne comprendre qu'une partie du système. En tant qu'utilisateur, je suis ravi d'avoir des système comme PulseAudio, systemd, udev ou d-bus.
  
  Et si vous n'êtes pas content, faites du réseau en RS232 et utilisez des calculatrices !
  
  "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Batchyx le 22 mars 2014 à 17:46. Évalué à 4.
    
    Mais vous en avez pas marre de cracher sur systemd, avec l'argument le plus pourri qui soit: "je n'y comprend rien !". Si tu n'y comprend rien, passe ton chemin ou documente-toi, mais ne vas pas dire que c'est nul parce que tu ne comprend pas.
    
    En terme logiciel on appelle ça du bloat et du code non-maintenable. Et oui, c'est une critique parfaitement valide: si un logiciel qui est censé fournir une fonctionnalité simple se retrouve à être un monstre de complexité incompréhensible par un non-spécialiste parce qu'il fourni une masse de fonctionnalité en un bloc qui ne sont pas utiles pour tout le monde, alors oui il y a un problème.
    
    Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote. Il pouvait aussi lire le code du processus PID 1 qui n'est pas très gros. Certes ça ne lui servait pas à grand chose parce que ça faisait exactement ce qui était écrit dans la doc et ce qui pourrai être dans l'imagination du développeur si c'était lui qui devait le programmer.
    
    Là on se retrouve à lire une quantité incroyable de documentation, et même en l'ayant lue, on peut encore en apprendre en lisant son code source gigantesque. C'est clairement pas idéal.
    
    Pour faire de Linux un système enfin utilisable par tout le monde, il s'est complexifié.
    
    C'est l'une des plus grosse foutaise que j'en ai marre d'entendre: l'utilisabilité d'un système n'a rien à voir avec sa complexité. Suffit de voir Windows et Mac OSX: il y en a un qui est plutôt complexe et l'autre qui est plutôt utilisable. Ou alors l'iphone qui était quasiment mono-tache. On peut remonter loin dans l'histoire de l'informatique, et ça restera le cas. Ceux qui disent le contraire ne savent juste pas modulariser du code ou n'ont juste pas envie.
    
    Et si vous n'êtes pas content, faites du réseau en RS232 […]
    
    T'est gentil mais j'utilise une configuration réseau bien plus avancée que ce que networkd peut actuellement fournir, et le tout uniquement avec ifupdown et /etc/network/interfaces sous Debian. Et ça c'est pour une machine filaire. Sur un portable, il me faut aussi un équivalent à guessnet, ce que le sois disant utilisable systemd-networkd ne fourni pas.
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par Maclag le 22 mars 2014 à 17:52. Évalué à 10.
      
      J'utilise très régulièrement, comme toi ou beaucoup de monde ici je suppose, un nombre assez conséquent d'outils sous Linux. Je veux dire hors commandes Unix/Bash/etc.
      
      Et là je me demande si en changeant leur nom pour les appeler systeme-simple, je ne créé pas un monstre de complexité qui fait absolument tout et n'importe quoi parce que "hé mais putain, y'a systeme-simple-ifupdown et systeme-simple-cups, clairement systeme-simple est un bloatware!"
      Et je suis à peu près sûr qu'on trouvera des piles logicielles communes entre les deux outils pour achever la comparaison.
      
      Voilà, un mec a fait une pile "de base" supplémentaire et il en profite pour faire des outils qui s'en servent. Peut-être que le plus gros reproche à lui faire est de tout appeler systemd-truc et systemd-machin.
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 22 mars 2014 à 17:59. Évalué à 9.
        
        Le problème, c'est surtout systemctl, je trouve ça très difficile à taper.
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 22 mars 2014 à 22:36. Évalué à 3.
        
        Tu peux utiliser un alias.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 23 mars 2014 à 00:09. Évalué à 6.
        
        Il faut aussi réécrire le bash_completion.
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par robin le 23 mars 2014 à 01:22. Évalué à 4.
        
        zshcompletion marche très bien :)
        
        bépo powered
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 22 mars 2014 à 18:39. Évalué à 9.
        
        Est ce que je peux utiliser system-networkd sans utiliser systemd en PID 1 ?
        
        Si oui, alors il s'agit d'un processus autonome qui peut être étudié séparément comme n'importe quel autre processus, et donc il n'y a pas besoin de chercher à comprendre comment systemd marche. Il suffit juste de regarder les interactions que ce démon à avec le monde extérieur, qui doivent se résumer à une socket rtnetlink, à forker un client dhcp et ptet à servir une API et/ou lancer des (séries de) scripts lancés lors d'événements. Un peu comme Network Manager dans le cas filaire, quoi (sans la socket vers udev, qui sert pas à grand chose dans le cas filaire). Et dans ce cas la, je vois pas pourquoi il y a systemd dans le nom.
        
        Si non, alors il y a potentiellement des interactions cachées dont l'utilité ne saute pas au yeux pour un outil de configuration réseau et qui n'aident pas à la compréhension. Ça veut dire que si un jour ça marche pas, il va falloir que je comprenne comment systemd est censé marcher pour savoir comment system-netlinkd est censé marcher. Le fait que ça soit un processus séparé n'est qu'un détail d'implémentation, ça aurai pu être dans le PID 1 que ça aurai pas changé grand chose.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 11:12. Évalué à 7.
        
        Donc pour résumer, systemd c'est nul, ca fait trop de choses donc c'est du bloatware. Mais par contre system-networkd c'est nul, c'est pas assez du bloatware, ca ne fonctionne qu'avec un systeme de boot particulier sous pretexte de simplifier les choses.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 23 mars 2014 à 21:36. Évalué à 4.
        
        Non, t'a pas suivi: Systemd est bloat, system-networkd est non-maintenable.
        
        Ah et j'ai regardé system-networkd, et je suis tombé sur le code qui gère la reception d'un lease DHCP: C'est un véritable retour en arrière par rapport à ce qui existe déjà: les seules options que ça supporte c'est d'avoir une adresse, un netmask, une gateway (alors qu'il peut y en avoir plusieurs), un hostname et des serveurs DNS (ouf ça en gère plusieurs).
        
        Fin bref, au revoir les domaines, les suffixes par défaut, les routes statiques, et toutes les fonctionnalités de DHCP sorties après les années 2000. Même dhclient-script gère plus d'options que ça.
        
        Et on veut mettre ça sur un serveur ?!?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 23 mars 2014 à 21:56. Évalué à 5.
        
        C’est clairement indiqué que c’est pour les configurations simples.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Albert_ le 24 mars 2014 à 10:17. Évalué à 1.
        
        Donc cela fait doublon avec des outils deja present. Et cela a donc "tres" legerement la possibilite de mettre un joyeux merdier.
        Je sens que l'on a pas fini de se ~~marrer~~debugguer ce truc et tous les "services" inclus dedans. Cela devient pire que emacs.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 12:19. Évalué à 3.
        
        C’est clairement indiqué que c’est pour les configurations simples.
        
        ifupdown aussi c'est prévu pour les configurations simples, tout en étant extensible à l'infini avec des scripts. Et vu que ça laisse dhclient-script gérer DHCP, et bien ça juste marche. Et qu'on vienne pas me dire qu'ifupdown n'est pas documenté.
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par Zenitram (site web personnel) le 22 mars 2014 à 21:21. Évalué à 10.
      
      En terme logiciel on appelle ça du bloat et du code non-maintenable.
      
      Clair que les scripts bash qui se baladent et non facilement maitrisable sur qui fait quoi, c'est très maintenable.
      
      Et oui, c'est une critique parfaitement valide: si un logiciel qui est censé fournir une fonctionnalité simple se retrouve à être un monstre de complexité incompréhensible par un non-spécialiste parce qu'il fourni une masse de fonctionnalité en un bloc qui ne sont pas utiles pour tout le monde, alors oui il y a un problème.
      
      tu parles bien des systèmes d'init avant systemd, on est d'accord?
      
      Là on se retrouve à lire une quantité incroyable de documentation, et même en l'ayant lue, on peut encore en apprendre en lisant son code source gigantesque. C'est clairement pas idéal.
      
      Sauf que la, c'est plus que l'init.
      Si seul l'init t'interresse, la doc est moins bordélique (c'est pas du bash qui plante car tu n'es pas sur la bonne distro et que tu as pas pensé à la petite subtilité de la distro) et petite.
      Comparons des choses comparables.
      
      Pour faire de Linux un système enfin utilisable par tout le monde, il s'est complexifié.
      
      C'est l'une des plus grosse foutaise que j'en ai marre d'entendre
      
      Tes exemples ensuite n'ont rien à voir : Mac OS X est simple pour l'utilisateur, ça ne dit pas que ce qu'il y a dessous est simple.
      Et tu donnes d'ailleurs un très bon exemple : pour le moment, la charge de travail est pour le mainteneur de distro et les utilisateurs, et avec systemd la complexité est dans l'OS lui-même pour une simplicité pour l'utilisateur (ne me dit pas que tu préfères les scripts bash à l'arrache aux init de systemd…), comme… ton exemple Mac OS X en fait.
      
      Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne, non ça ne n'était pas simple, au contraire, et non ça ne faisait pas ce qu'on attend d'un OS moderne.
      Et surtout, ne pas se demander pourquoi les mainteneurs, ceux qui bossent et subissent le plus, des distros les plus diffusées sont assez stupides et incompétants pour prendre "du bloat et du code non-maintenable" plutôt que de garder ce qu'il y avait avant : peut-être parce que cette description de systemd n'est pas crédible? Mais tu peux donner ton explication pour les convaincre qu'ils ont tous (maintenant, "tous" inclut même les mainteneurs Debian et Ubuntu, même plus de gueguerre distros basées sur RPM contre distros basées sur DEB, tous les plus gros ont décidé la même chose) faux sur toute la ligne et qu'il prennent un bloat plutôt qu'un truc simple juste pour le plaisir de souffrir…
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 22 mars 2014 à 22:17. Évalué à 7. Dernière modification le 22 mars 2014 à 22:18.
        
        Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne, non ça ne n'était pas simple, au contraire, et non ça ne faisait pas ce qu'on attend d'un OS moderne.
        
        Il faut arrêter avec la mauvaise foi un peu.
        
        Les initscripts ont été maintenus pendant des dizaines d’années sans aucun souci. Les BSD d’ailleurs n’ont pas l’air d’avoir envie de s’en départir, on devrait en déduire que ce sont des gros masochistes qui aiment le code inmaintenable ? (dans ce cas il faudra m’expliquer la décision de OpenBSD de sortir apache pour des raisons de trop grossos difficultés niveau maintenabilité tout en ne disant rien pour les initscripts…) Sans compter Slackware, distribution d’une seule personne qui a maintenu sans aucun souci tous les initscript de la distrib sans gros souci…
        
        C’est pas parce que t’aime pas le shell que c’est pas maintenable, désolé. Sinon moi aussi je peux le faire : SAP essaie de s’éloigner de Windows donc j’en déduis qu Windows c’est pas maintenable.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 22 mars 2014 à 23:24. Évalué à 9. Dernière modification le 22 mars 2014 à 23:25.
        
        Les initscripts ont été maintenus pendant des dizaines d’années sans aucun souci.
        
        Oui c'est vrai.
        Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.
        
        Aucun souci, sauf quand tu te tapes des failles de sécurité
        
        Aucun souci, sauf quand t'as oublié de gérer les fichues runlevels (heureusement qu'on n'utilise plus ça avec systemd)
        
        Aucun souci, sauf quand tu veux que tes services soient démarrés selon un évènement externe (une imprimante a été découverte, le wifi a été réactivé, …). Bon, on peut faire du busy waiting, mais c'est un peu la merde quand même pour l'usage de la batterie.
        
        Aucun souci, sauf quand tu veux que ton script d'init fonctionne sur plusieurs distributions.
        
        Aucun souci, sauf quand le script fourni par ta distribution ne fonctionne pas.
        
        Aucun souci, sauf que c'est difficile d'écrire un bon init script, et que la plupart des init scripts existants étaient merdiques
        
        Aucun souci, sauf que certaines distributions (dont Arch en premier) sont passés à systemd très vite pour éviter de continuer à se taper la maintenance de scripts d'init.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 22 mars 2014 à 23:34. Évalué à 5.
        
        Oh mon Dieu, des bugs et des failles dans un logiciel, quelle horreur qui n’arrive que dans les projets inmaintenables !
        
        Heureusement que systemd, étant bien codé lui, n’a aucun bug ni aucune faille de sécurité.
        
        Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.
        
        Heu, par définition (ou à moins d’un très grave bug dans le pid 1), si tu as un zombie c’est que ton processus est pas géré par le système d’init…
        
        Aucun souci, sauf quand t'as oublié de gérer les fichues runlevels (heureusement qu'on n'utilise plus ça avec systemd)
        
        Tu as les target qui ont exactement le même « problème » (qui n’en est pas un : si tu spécifies pas quand tu veux que ton script démarre ça me paraît normal que le système d’init le démarre pas, que ce soit systemd ou sysvinit)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 10:58. Évalué à 3.
        
        Oups, un zombie
        
        Sous UNIX, et c'est vrai sous Linux, tout processus qui se termine devient Zombie. Ensuite, c'est à son père de récupérer la valeur de retour. Une fois fait, le processus est réellement déchargé de la mémoire. Si le père en question meurt, c'est au /grand-père/ de lire les valeurs de retour. Et ainsi de suite jusqu'au PID 1 Dieu et maître, père de tous qui doit acquiter tout les zombies qui lui arrive.
        
        Tout ça pour dire que dire que les processus Zombies sont une marque de mauvais système d'init me semble capilotracté.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 12:30. Évalué à 1.
        
        Techniquement, le grand père n'est pas impliqué: Si le père d'un zombie meurt , il sera rattaché directement au machin centralisé qu'est le PID 1, qui l'achèvera.
        
        Mais ta conclusion reste parfaitement correcte.
        
        [^] # Arrêter un service avec systemd
        
        Posté par Sylvain Blandel le 24 mars 2014 à 15:54. Évalué à 6.
        
        Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.
        
        […] dire que les processus Zombies sont une marque de mauvais système d'init me semble capilotracté.
        
        Il n'est pas question ici de « systemd, le système d'initialisation », mais de « systemd, le gestionnaire de services ».
        
        Lorsqu'on demande à systemd de lancer un service, le comportement par défaut est d'isoler le programme lancé ainsi que tous ses descendants dans un nouveau groupe de contrôle. De cette façon, le processus lancé et tous ses descendants sont clairement identifiables : ils sont tous dans le même groupe de contrôle.
        
        Plus tard, lorsqu'on demande à systemd d'arrêter ce service, il zigouille tous les processus contenus dans le groupe de contrôle en question. C'est une différence importante avec le traditionnel SysVinit : lorsque systemd arrête un service, il ne se contente pas d'exécuter une commande (qui doit stopper des processus), il met à mort l'ensemble des processus contenus dans le groupe de contrôle. Autrement dit, systemd termine tous les processus que le service à engendré.
        
        De cette façon, je ne vois pas comment il peut y avoir des processus zombie.
        
        Remarque : la façon dont systemd arrête un service est évidemment paramétrable, voir les options ExecStop et KillMode.
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 16:43. Évalué à 2.
        
        Je pense que nous ne parlons pas exactement de la même chose… Je parle de : Processus Zombie.
        
        Toi tu me parles d'un démon type apache qui démarre 20 processus fils. Et dans certains cas, si on tue le père, certains fils peuvent migré vers le nouveau père supérieur (PID1) sans être tué. Si c'est ça, systemD fait office de garde pour les bugs des démons du système. Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.
        
        Ai-je bien compris ?
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 16:59. Évalué à 2.
        
        Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.
        
        on est d'accord que c'est positif?
        Ta tournure de phrase laisse penser que c'est négatif pour une fonctionnalité qui participe à la stabilité d'un OS en production (un logiciel sous-jacent sans bugs étant un rève) ce qui est le but du sponsor principal (Red Hat souhaite un truc stable) et de plein d'autres personnes (les bugs, ok il faut les debugguer, mais pas au prix de l'instabilité en prod')
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 17:15. Évalué à 3.
        
        on est d'accord que c'est positif?
        Ta tournure de phrase laisse penser que c'est négatif pour une fonctionnalité qui participe à la stabilité d'un OS en production
        
        Bah, oui je suis un peu dubitatif.
        Ok, ça apporte de la stabilité au système, mais il y a le risque de masquer un bug, qui pourra avoir d'autres effets de bord moins visibles mais plus grave à long terme…
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 17:32. Évalué à 1.
        
        mais il y a le risque de masquer un bug
        
        Je parie qu'il est possible de logguer les process tués (et avec les cgroups, tout un tas d'information utiles)
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par Anonyme le 24 mars 2014 à 18:12. Évalué à 2.
        
        Masquer un bug sur une fonctionnalité qui n'a plus aucun interet.
        
        Mais c'est systemd, il faut forcement trouver un truc negatif.
        
        [^] # Re: Arrêter un service avec systemd
        
        Posté par claudex le 24 mars 2014 à 17:05. Évalué à 8.
        
        Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.
        
        Ils sont justement plus facile à trouver puisqu'il suffit de demander à systemd de ne pas les tuer et on peut retrouver facilement ces processus puisqu'ils sont tous dans le même cgroup.
        
        « 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: Arrêter un service avec systemd
        
        Posté par Sylvain Blandel le 24 mars 2014 à 18:35. Évalué à 2. Dernière modification le 24 mars 2014 à 18:37.
        
        Je pense que nous ne parlons pas exactement de la même chose… Je parle de : Processus Zombie.
        […]
        Toi tu me parles d'un démon type apache qui démarre 20 processus fils. Et dans certains cas, si on tue le père, certains fils peuvent migré vers le nouveau père supérieur (PID1) sans être tué.
        […]
        Ai-je bien compris ?
        
        Hum … oui. Finalement, mon commentaire concernait plus les processus orphelins que les processus zombies.
        
        Si c'est ça, systemD fait office de garde pour les bugs des démons du système. Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.
        
        La façon dont systemd termine un service est paramétrable. D'après la documentation, le comportement que tu souhaites est possible en mettant les paramètres suivants dans le fichier .service :
        
        KillMode=none
        ExecStop=/usr/bin/CommandeChargéeDeTerminerLeService arguments
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 22 mars 2014 à 23:33. Évalué à 1. Dernière modification le 22 mars 2014 à 23:34.
        
        Il faut arrêter avec la mauvaise foi un peu.
        
        Je suis d'accord avec toi
        
        Les initscripts ont été maintenus pendant des dizaines d’années sans aucun souci.
        
        S'il te plait, essaye d'appliquer la phrase juste avant…
        
        Tellement aucun soucis que les mainteneurs se sont dépéchés (avant que systemd soit très stable) de se débarraser des initscripts, mais il y a toujours les personnes qui ne sont pas à faire le taf qui disent "aucun soucis".
        Vous prenez les mainteneurs pour des masochistes qui adorent casser "aucun soucis" pour le plaisir d'avoir du taf en plus et se prendre les râleurs sans jamais vous poser la question de pourquoi ils se dépèchent.
        
        Je vois que vous avez une haute estime des mainteneurs. Et pour la mauvaise foi, chapeau pour le "aucun soucis", impressionnant, on peu faire difficilement plus gros.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 22 mars 2014 à 23:48. Évalué à 6. Dernière modification le 22 mars 2014 à 23:48.
        
        Il y avait des tas de projets d’init bien avant systemd qui avaient pour simple but de remplacer les scripts init par des fichiers de conf et qui n’ont pas été adoptés par les mainteneurs (smf, launchd, upstart, pour n’en citer que les plus connus). Si la raison pour laquelle les mainteneurs ont choisi systemd c’est la simplicité de la maintenance des scripts, explique moi donc :
        
        pourquoi ils n’ont pas choisi un de ces projets il y a des années ? parce que le bash de 2009 était maintenable mais le bash de 2014 ne l’est plus ?
        
        pourquoi slackware, maintenu par une seule personne donc en première ligne pour les questions de difficulté de maintenance, veut retarder le plus possible son adoption ? masochisme ?
        
        pourquoi les BSD n’abandonnent pas les initscripts si c’est une telle charge de travail à maintenir ?
        
        Vraiment, j’aimerais que tu m’expliques comment tu arrives à réconcilier ta théorie « les distribs migrent vers systemd parce que les .unit c’est plus maintenable que des scripts bash » avec ces faits.
        
        Je vois que vous avez une haute estime des mainteneurs
        
        Il ne t’est pas venu à l’esprit que ceux qui ont décidé de passer à systemd l’ont fait pour d’autres raisons que « c’est trop dur de maintenir des scripts shell » ?
        
        (semi-troll: de toute façon c’est pas un pauvre script shell qui va faire peur à quelqu’un qui maintient des paquets deb/rpm quand on voit la simplicité de ces derniers…)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 11:28. Évalué à 7.
        
        pourquoi ils n’ont pas choisi un de ces projets il y a des années ? parce que le bash de 2009 était maintenable mais le bash de 2014 ne l’est plus ?
        
        Peu etre par ce que ces projets avaient d'autres problemes ?
        
        pourquoi slackware, maintenu par une seule personne donc en première ligne pour les questions de difficulté de maintenance, veut retarder le plus possible son adoption ? masochisme ?
        
        Par ce qu'un systeme de boot ca ne se change pas en 5mn, et donc on ne peut pas s'attendre à ce que 100% des distributions migrent tout de suite. Je trouve ca deja impressionnant le nombre de distributions ayant migré en si peu de temps.
        
        pourquoi les BSD n’abandonnent pas les initscripts si c’est une telle charge de travail à maintenir ?
        
        Peu etre par ce que systemd ne fonctionne pas sur BSD, et par ce que personne n'a encore pris le temps d'implementer un equivalent ?
        
        Vraiment, j’aimerais que tu m’expliques comment tu arrives à réconcilier ta théorie « les distribs migrent vers systemd parce que les .unit c’est plus maintenable que des scripts bash » avec ces faits.
        
        Il te faudrait quoi ? Que 100% des distributions l'aient fait ?
        
        Il ne t’est pas venu à l’esprit que ceux qui ont décidé de passer à systemd l’ont fait pour d’autres raisons que « c’est trop dur de maintenir des scripts shell » ?
        
        Tu veux dire qu'ils mentent quand ils donnent ca parmis leurs raisons pour le faire ? Et qu'ils ont d'autres raisons cachées ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 23 mars 2014 à 12:07. Évalué à 4. Dernière modification le 23 mars 2014 à 12:10.
        
        Peu etre par ce que ces projets avaient d'autres problemes ?
        
        launchd et smf étaient utilisés par Apple et Sun (oui, quand ils s’appelaient encore Sun). initng était parfaitement utilisable et très bien supporté par certaines distribs comme Gentoo.
        
        Peu etre par ce que systemd ne fonctionne pas sur BSD, et par ce que personne n'a encore pris le temps d'implementer un equivalent ?
        
        initng et launchd fonctionnaient sous BSD avant même que la première ligne de code de systemd soit écrite…
        
        Et qu'ils ont d'autres raisons cachées ?
        
        Pourquoi cachées ?
        
        systemd gère mieux les cgroups et le multi-seat que n’importe quel autre de ses concurrents. Il a un système de templating extrêmement pratique. Il est aussi le projet qui exporte le plus de choses aux autres applications, d’où l’utilisation de cette API par Gnome, d’où une meilleure expérience utilisateur sur le desktop avec systemd.
        
        Ça en fait des raisons largement suffisantes pour expliquer sont adoption massive, sans avoir à aller chercher des raisons comme « maintenir des scripts shell c’était trop dur », tu ne penses pas ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 12:19. Évalué à 3.
        
        Ça en fait des raisons largement suffisantes pour expliquer sont adoption massive, sans avoir à aller chercher des raisons comme « maintenir des scripts shell c’était trop dur », tu ne penses pas ?
        
        Ca n'est pas la seule raison, mais ca fait partie des raisons frequement citées.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par modr123 le 24 mars 2014 à 13:39. Évalué à -1.
        
        tu veux dire que systemd est tellement intrusif qu'ils ont le choix maintenir les scripts et patchée les programmes pour qu'il ne soit plus dependant de systemd et utiliser systemd ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 24 mars 2014 à 19:03. Évalué à 3.
        
        systemd est 99% rétro-compatible avec les scripts, hein.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Sylvain Blandel le 24 mars 2014 à 19:52. Évalué à 3.
        
        systemd est 99% rétro-compatible avec les scripts, hein.
        
        C'est exact, on peut parfaitement utiliser ses scripts SysVinit avec systemd.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par modr123 le 24 mars 2014 à 21:05. Évalué à -3.
        
        je vois pas le rapport….
        ne pas utiliser systemd rajoute le fait de devoir patcher les programmes qui ont pour dependance systemd et l'a virer
        ne pas utiliser systemd rajoute donc du boulot a cause du cote intrusif de systemd
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 21:34. Évalué à 3.
        
        ne pas utiliser systemd rajoute le fait de devoir patcher les programmes qui ont pour dependance systemd et l'a virer
        
        Est-ce la faute de systemd si d'autres décident ça?
        Ah oui, tout mettre sur systemd, ce salaud coupable de tout, pardon…
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 12:26. Évalué à 10.
        
        pourquoi ils n’ont pas choisi un de ces projets il y a des
        années ? parce que le bash de 2009 était maintenable mais le
        bash de 2014 ne l’est plus ?
        
        Ubuntu est passé sur upstart, Fedora aussi, et Opensuse/Mandrake allait le faire. Gentoo utilise autre chose que sysv init.
        
        Solaris et Os X ont refait un init. Le hurd a revu les concepts de runlevels depuis le début car non adaptés.
        
        Donc je pense que les distributeurs ou assimilés ont tentés de faire des choses, oui.
        
        Ensuite, la question est en fonction de chaque OS. Launchd n'était pas portable, je suppose SMF non plus. Il reste donc upstart, qui a un certain nombre de souci de design ( utilisation de ptrace pour suivre les processus, syntaxe de la conf pas super intuitive ) en plus d'avoir un CLA qui a limité les contributions externes (selon moi).
        
        pourquoi slackware, maintenu par une seule personne donc en
        première ligne pour les questions de difficulté de
        maintenance, veut retarder le plus possible son adoption ?
        
        Faut lui demander. Mais il me semble plus évident que ne pas migrer coute moins cher que migrer, sauf que du coup, tu restes sur les vieux soucis, sans avoir les nouvelles fonctions. On peut retourner la question de slackware sur le fait d'avoir son propre format de paquet.
        
        pourquoi les BSD n’abandonnent pas les initscripts si c’est
        une telle charge de travail à maintenir ?
        
        http://wiki.netbsd.org/projects/project/launchd-port/
        http://www.phoronix.com/forums/showthread.php?91776-Apple-s-OS-X-Launchd-Being-Ported-To-FreeBSD
        
        Et les devs BSD ont déjà des choses plus urgentes à faire. Comme essayer de suivre linux pour les pilotes graphiques ( ex kms ). Le souci, c'est pas que le code en bash soit si difficile à maintenir si tu connais le bash. C'est comme écrire ton site web en C, ça se fait. Le souci, c'est d'écrire ça comme il faut la première fois. C'est une barrière à la contribution inutile pour les packageurs.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 10:08. Évalué à 6.
        
        On peut retourner la question de slackware sur le fait d'avoir son propre format de paquet.
        
        vu l'age de l’ancêtre c'est plutôt les autres qui ont choisi d'utiliser leur propre format de paquet :)
        Sans compter que la réponse est connue : si les paquets sont bien faits c'est beaucoup plus simple à maintenir qu'un truc a gestion de dépendances.
        Pour systemd, la réponse est connue aussi : interview de Volkerding
        
        Le souci, c'est d'écrire ça comme il faut la première fois.
        
        Bah comme tout : si tu fait des trucs comme il faut dès la première fois, tu es très fort.
        
        M'enfin, pour ma part, je préfère faire à la main (même mal) en shell une fois pour toutes ce que ces machins automatisés font plus ou moins bien a chacun de mes boots (détection de matos, séquençage des scripts de démarrage etc), ajoutant encore un peu plus à la balkanisation des linux. C'est sans doute mieux pour les mainteneurs mais perso, je vis mieux sans.
        L'ennui c'est que plus ça va, moins c'est faisable à cause de dépendances plus ou moins fumasse à ces usines a gaz.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 10:36. Évalué à 6.
        
        Sans compter que la réponse est connue : si les paquets sont bien faits c'est beaucoup plus simple à maintenir qu'un truc a gestion de dépendances.
        
        C'est certain qu'un programme qui fait moins de chose est plus simple à maintenir car la partie complexe est laissée à l'opérateur humain. est-ce vraiment souhaitable ? La gestion des dépendances fait gagner beaucoup de temps et d'énergie à l'opérateur humain qui n'a à ce soucier que du nom du programme qu'il souhaite pour l'avoir fonctionnel.
        
        Alors oui au moins tu sais exactement ce que tu fais, mais tu payes le prix par moins de confort et plus de temps à gérer cela à la place de l'ordinateur (qui est pourtant un outil fait pour automatiser les tâches et libérer l'humain de la répétition). C'est un choix de vie, tu comprendras que certains ont d'autres priorité que toi.
        
        M'enfin, pour ma part, je préfère faire à la main (même mal)
        
        Tu pars mal, préférer mal faire quelque chose quelque en soit la raison derrière me paraît bien futile. Pourquoi vouloir faire mal ? Tu n'as rien à y gagner…
        
        en shell une fois pour toutes
        
        À chaque mise à jour majeur des programmes que tu lances tu devras certainement retoucher aux scripts de lancement. Si tu changes de distributions aussi. Bref, ce n'est pas gravé dans le marbre.
        
        machins automatisés font plus ou moins bien a chacun de mes boots (détection de matos, séquençage des scripts de démarrage etc), ajoutant encore un peu plus à la balkanisation des linux.
        
        D'un autre côté, l'informatique a changé, le matériel est modulaire (clés USB qu'on branche et débranche, carte Wifi qu'on active selon le besoin, pareil pour le Bluetooth, etc.), les interfaces réseaux peuvent changer, le fait d'avoir le réseau en permanence n'est pas une garantie, etc. Bref, il faut gérer ces cas pour que les programmes derrières fonctionnent correctement mais aussi pour que l'utilisateur puisse exploiter le matériel qu'il a sous la main.
        Tu regrettes l'époque du montage de la clé USB à la main ? Tu regrettes la douce époque où la batterie ne durait que 15 minutes car tout le matériel était activé sans possibilité de couper ce qui ne sert pas ? Bref, oui l'informatique a évolué et pour profiter du matériel et des logiciels à disposition ils faut faire des tâches automatisés qui va s'adapter au contexte pour faire ce qu'il y a à faire. C'est de l'optimisation et tout le monde y gagne. Oui les programmes sont du coup plus complexes, mais je pense que tu utilises ssh et non telnet, que tu prends Firefox et non Mosaic pour aller sur le Web, que tu utilises Torrent et les courriels plutôt que USENET, que tu n'utilises pas une interface tty uniquement, etc.
        
        L'ennui c'est que plus ça va, moins c'est faisable à cause de dépendances plus ou moins fumasse à ces usines a gaz.
        
        Reste à démontrer qui est l'usine à gaz. Je pense qu'on ne doit pas avoir la même définition d'une usine à gaz. Déjà ce terme implique que le programme surconsomme par rapport à son efficacité et au vu de ce qu'il est capable de faire, il est bien performant.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 16:42. Évalué à 2. Dernière modification le 24 mars 2014 à 16:44.
        
        C'est un choix de vie, tu comprendras que certains ont d'autres priorité que toi.
        
        Oui bien sur. L'ennui c'est que ce choix disparaît avec le temps et les dépendances et que bientôt je ne l'aurais plus. Pourtant, mon approche a toujours une raison d'être.
        Ça me semble une régression car une perte globale de souplesse et de modularité.
        
        préférer mal faire quelque chose quelque en soit la raison derrière me paraît bien futile.
        
        J'ai dû mal m'exprimer : je préfère un truc que je fais mal à un truc que quelque chose d'autre fait mal (non adéquat si tu préfères). Dans le premier cas, je peux arranger la chose, dans l'autre c'est beaucoup plus compliqué à arranger.
        
        l'informatique a changé, le matériel est modulaire (clés USB qu'on branche et débranche, carte Wifi qu'on active selon le besoin, pareil pour le Bluetooth, etc.), les interfaces réseaux peuvent changer, le fait d'avoir le réseau en permanence n'est pas une garantie, etc.
        
        Ok pour le desktop (et encore) mais là, les automatismes on se les tape sur toutes les machines, juste parce que le desktop a changé. Or, le desktop c'est marginal pour linux. C'est la logique qui fait qu'on développe des GUI tactiles inadaptées sur les PC sous prétexte qu'il faut que ça tourne sur tablette.
        Si c'est ça le progrès alors je veux bien passer pour un dino réfractaire.
        
        Bref, il faut gérer ces cas pour que les programmes derrières fonctionnent correctement mais aussi pour que l'utilisateur puisse exploiter le matériel qu'il a sous la main.
        
        L'utilisateur a toujours pu exploiter le matériel qu'il avait sous la main, mais il devait le faire de manière explicite. Maintenant c'est implicite : tu branches un truc et ça fait quelque chose pour que ça marche "au mieux". Sauf que "au mieux" pour le mainteneur, ce n'est pas forcément au mieux pour moi. Alors oui ça fait le café tout seul mais une fois sur deux je me retrouve avec un cappuccino sucré quand je voulais un café noir.
        
        C'est de l'optimisation et tout le monde y gagne.
        
        C'est de la généralisation et tout le monde n'y gagne pas. Les gens hors du "cadre général" vont galérer beaucoup plus à désactiver une techno non désirée qu'à mettre en œuvre un service sans avoir a désactiver cette techno. Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur et le serveur c'est que du cas particulier, c'est pour ça qu'on paye des gens pour faire la config.
        Résultat : l'admin devra se palucher une techno supplémentaire pour un gain qui est loin d'être acquis.
        
        tu utilises ssh et non telnet, que tu prends Firefox et non Mosaic pour aller sur le Web, que tu utilises Torrent et les courriels plutôt que USENET, que tu n'utilises pas une interface tty uniquement, etc.
        
        J'utilise telnet ou ssh en fonction de la situation et non systématiquement l'un ou l'autre. C'est aussi valable pour le reste. Jeter ftp parce qu'il existe dropbox, http ou torrent est d'une stupidité sans nom : tu choisis un soft principalement pour l'usage que tu en fais, pas parce que ça fait "plein de choses qu'on pouvait pas avant".
        Or, globalement, en info, on va vers l'intégration de fonctionnalités qui n'ont rien a faire dans le soft (par ex : inetd fusionné avec le gestionnaire de boot dans le cas systemd) et on a tendance a présenter ça comme un progrès : désolé de ne pas être d'accord.
        
        l'informatique a évolué et pour profiter du matériel et des logiciels à disposition ils faut faire des tâches automatisés qui va s'adapter au contexte pour faire ce qu'il y a à faire
        
        Ce n'est pas l'informatique qui évolue mais ce que les gens en font. Les technos actuelles existaient pour la plupart il y a 20 ans. Or, l'utilisation principale de Linux (l'OS) c'est le serveur et c'est une niche peu confrontée aux problématiques de matériel modulaire et de contexte de config qui change tous les jours.
        
        on ne doit pas avoir la même définition d'une usine à gaz
        
        Une usine a gaz c'est un truc qui nécessite trop de ressources pour le mettre en œuvre par rapport à l'usage qui en est fait. S'il faut se palucher en plus la doc de systemd pour démarrer 3 pauvres services sur un LAMP alors que 3 lignes de shell suffisent, alors c'est une usine a gaz.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 17:19. Évalué à 1.
        
        L'ennui c'est que ce choix disparaît avec le temps
        
        aucun choix ne disparait avec le temps.
        a seule chose qui disparaisse, c'est des gens qui font du travail pour toi (car eux aussi sont libres) si tu décides de ne pas participer à u ntruc commun.
        
        dire qu'un choix disparait avec du libre, c'est juste des foutaises pour ne pas juste dire qu'on ne veut ni faire le boulot ni faire du commun.
        
        Pourtant, mon approche a toujours une raison d'être.
        
        A démontrer.
        
        Ça me semble une régression car une perte globale de souplesse et de modularité.
        
        Ha ha ha. Au contraire.
        
        J'utilise telnet ou ssh en fonction de la situation et non systématiquement l'un ou l'autre.
        
        (je met de côté l'idée que tu ne parles pas de machine où seul telnet est disponible, ça serait non prendre pour des idiots)
        Ha oui, vu comme ça, forcément… Le plaisir de prendre 2 technos quand une seule suffit, juste par principe, c'est un plaisir qui te regarde mais ne demande pas aux autres de se faire chier pour ton plaisir.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 17:46. Évalué à 1.
        
        dire qu'un choix disparait avec du libre, c'est juste des foutaises pour ne pas juste dire qu'on ne veut ni faire le boulot ni faire du commun
        
        Vu comme ça, pourquoi pas. Mais c'est un peu l'hôpital qui se fout de la charité car ton respect du travail des autres est très sélectif aussi : tu viens bien râler sur le boulot pourri des autres (les shell scripts éparpillés qui puent).
        
        A démontrer.
        
        Le fait qu'il existe des distributions dédiées à des cas d'utilisations de niche et sans tous ces trucs me semble démontrer qu'il y a un besoin.
        
        Ha ha ha. Au contraire.
        
        Ho ho ho : je t'assure que si !
        
        Le plaisir de prendre 2 technos quand une seule suffit
        
        Ce n'est pas les mêmes cas d'usage ? La config de sshd est sensiblement plus compliquée que celle de telnetd ? J'utilise en effet des machines sans sshd ? Désolé de te prendre pour un idiot, mais c'est une réalité.
        
        ne demande pas aux autres de se faire chier pour ton plaisir.
        
        je ne demande rien aux autres, je donne mon avis sur une techno que je ne trouve pas intéressante et je constate une tendance qui ne m'arrange pas.
        
        PS pour les admins du site : excellent le dessin quand on prévisualise le commentaire :)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 17:58. Évalué à 1.
        
        Mais c'est un peu l'hôpital qui se fout de la charité car ton respect du travail des autres est très sélectif aussi : tu viens bien râler sur le boulot pourri des autres (les shell scripts éparpillés qui puent).
        
        Tu fantasmes : les autres en question ont fait ce qu'ils ont pu avec les moyens du bord à une époque données, et je les remercie.
        Mais maintenant qu'on a mieux, pourquoi continuer avec "les moyens du bord" d'avant?
        
        Ce n'est pas les mêmes cas d'usage ?
        
        Ah… sérieux, quel usage SSH ne fait pas et que telnet fait? Je suis curieux…
        
        La config de sshd est sensiblement plus compliquée que celle de telnetd ?
        
        compliquée??? chacun sa vision de compliqué, je n'ai jamais croisé une distro moderne avec SSH désactivé quand installé sur des serveurs, donc la complexité est haute en effet : null.
        Et sans doute que tu as loupé tous les aspects sécurité du monde moderne et aime encore les mots de passe en clair, mais bon, passons…
        
        OK, tu viens de démontrer que c'est surtout le plaisir de garder deux trucs redondants quand les gens en veulent un seul qui te motive.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 10:20. Évalué à 3.
        
        quel usage SSH ne fait pas et que telnet fait
        
        Je me vois mal faire du ssh client sur un serveur mail ou web. Côté serveur, ssh n'est pas disponible de base sur tous les (vieux) systèmes.
        
        le plaisir de garder deux trucs redondants
        
        Désolé de travailler aussi avec des vieux Unix.
        
        quand les gens en veulent un seul
        
        Les gens c'est toi ?
        
        tu as loupé tous les aspects sécurité du monde moderne
        
        Disons que les technos dans le monde de l'entreprise évoluent moins vite que ce que tu aimerais. La sécu c'est bien hein, mais derrière les FW il y a souvent des babasses bien loin de l'idéal sécuritaire de l'admin parano.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 10:26. Évalué à -2. Dernière modification le 25 mars 2014 à 10:29.
        
        Je me vois mal faire du ssh client sur un serveur mail ou web.
        
        Mais telnet oui. euh… OK, tu évites bien soigneusement de répondre à la question, c'est un signe.
        
        Côté serveur, ssh n'est pas disponible de base sur tous les (vieux) systèmes.
        
        Je me cite :
        "(je met de côté l'idée que tu ne parles pas de machine où seul telnet est disponible, ça serait non prendre pour des idiots)"
        
        OK, l'argument est que tant que tout n'est pas x, on ne va pas vers x, donc jamais on évolue. La volontée claire nette de la volonté de rester dans le passé.
        Désolé, le monde change.
        
        (Plus je lis certaines réactions, plus je comprend pourquoi des entreprises meurent faute d'accepter que les technologies évoluent et se retrouvent avec un travail inutile qui plombe la rentabilité long terme faute d'avoir accepté de prendre le train en marche pendant que les autres migrent en augmentant leurs savoir faire…)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 25 mars 2014 à 10:29. Évalué à 4.
        
        Je me vois mal faire du ssh client sur un serveur mail ou web.
        
        Mais telnet oui. euh… OK, tu évites bien soigneusement de répondre à la question, c'est un signe.
        
        Non, tu n'as pas compris la réponse. Je t'invite a essayer : telnet www.google.fr 80 puis GET index.html (ou quelque chose de proche).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 10:41. Évalué à -1.
        
        Ce qui est évidement l'utilisation la plus classique de telnet… surtout que une fois la demande de TLS faite (classique de nos jours), tu vas aller loin, et puis bon tout le monde fait ça manuellement, c'est connu!
        
        Effectivement, je n'avais pas suivi tellement c'est énorme.
        C'est vraiment l'exemple cherché très très loin pour justifier. Il faudrait qu'on reste tous en port série, car c'est utile pour certains debug et pas question de prendre plus évolué pour cette raison.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 17:24. Évalué à 3.
        
        Oui bien sur. L'ennui c'est que ce choix disparaît avec le temps et les dépendances et que bientôt je ne l'aurais plus. Pourtant, mon approche a toujours une raison d'être.
        
        Si le choix disparaît, c'est que les autres choix ne sont plus pertinents aux yeux des mainteneurs et que le point de vue qui justifie leur existence est marginale.
        
        Tu te doutes bien que si tout le monde pensait comme toi, systemd ne s'imposerait pas… Et que si beaucoup de gens pensent comme toi ils peuvent maintenir le truc en parallèle. D'autant plus, qu'à écouter certains, systemd c'est la difficulté et SysV la facilité, alors qui est chaud pour donner du temps à le maintenir ? Bizarrement, plus grand monde…
        
        Dans le premier cas, je peux arranger la chose, dans l'autre c'est beaucoup plus compliqué à arranger.
        
        En partant de ce principe, tu codes en assembleur et tu n'utilises aucun programmes que tu n'as pas écrit ? J'en doute. Pourtant tous ce que tu utilises fait de l'abstraction pour toi, prennent des choix de conceptions que tu apprécies ou pas, etc. Pourquoi est-ce que là ce serait plus important qu'ailleurs ? Si tu as le besoin de manipuler profondément ce qu'il se passe, tu peux toujours te passer de systemd notamment en créant ta propre distribution à la main. Certains le fond, comme dans l'embarqué.
        
        Or, le desktop c'est marginal pour linux.
        
        Toutes les distributions qui utilisent systemd pour le moment sont plus orientées bureaux que serveurs. Et systemd est loin d'être inapte en utilisation serveur, au contraire, il simplifie la vie des administrateurs systèmes (qui ne pensent pas comme des programmeurs).
        
        L'utilisateur a toujours pu exploiter le matériel qu'il avait sous la main, mais il devait le faire de manière explicite.
        
        Oui mais le faire de manière explicite n'est pas toujours simple ou à la portée de tous.
        Le faire à la main demande le temps d'apprendre à le faire, alors qu'en mode automatique tu n'as pas à t'en soucier. Personnellement quand j'utilise ma machine, je n'ai pas envie d'apprendre à monter une clé USB avant à la main. Pourtant à une époque j'ai du le faire, mais je l'ai fait car j'étais curieux et que j'avais le temps disponible pour ça.
        
        Sauf que "au mieux" pour le mainteneur, ce n'est pas forcément au mieux pour moi. Alors oui ça fait le café tout seul mais une fois sur deux je me retrouve avec un cappuccino sucré quand je voulais un café noir.
        
        Une distribution Linux est par définition un assemblage de composants logiciels afin d'avoir un système cohérent et utilisable. Par conséquent, ils font des choix de technologies, de logiciels et d'imbrications en vue d'une utilisation par une cible particulière. La distribution universelle (désolé pour Debian) n'existe pas et n'a pas de sens. Forcément certains choix plairont à certains et pas à d'autres. Et si tu n'aimes pas ces choix, bah go LFS.
        
        En informatique, et tout domaine un petit peu complexe, tu fais confiance au travail d'autrui et par conséquent à des choix qu'ils ont fait (en général pour se faire plaisir avant tout). Tu es qui pour exiger que ton choix soit pris en compte ? Tu es libre de proposer une solution pour représenter ton choix et tes besoins.
        
        Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur et le serveur c'est que du cas particulier, c'est pour ça qu'on paye des gens pour faire la config.
        
        Bizarrement je constate que les administrateurs systèmes purs qui ont fait l'effort d'apprendre systemd sont contents du résultat. La critique est souvent porté par ceux qui n'ont pas essayé…
        Sans compter que c'est Red-Hat qui paye le développeur principal de systemd. Red-Hat qui a je pense un coeur de métiers qui fait que s'ils se loupent sur le marché des serveurs ils vont le regretter. Alors on verra avec le temps mais je fais confiance au fait que Red-Hat ne souhaite pas torpiller son propre marché et qu'ils savent ce qu'ils font.
        
        Résultat : l'admin devra se palucher une techno supplémentaire pour un gain qui est loin d'être acquis.
        
        Je n'ai vu personne qui a appris à utiliser correctement systemd s'en plaindre. Bien au contraire, c'est plutôt bien accueillis.
        Et oui l'administrateur système devra apprendre une nouvelle technologie, mais en informatique l'apprentissage est constant dans le temps. Apprendre une nouvelle technologie ne devrait pas faire peur, tout informaticien est payé pour être à jour de ce point de vue. Tu crois que Ken Thompson programme de la même façon en 1960 et aujourd'hui ? Tout change, tout évolue et il faut s'adapter et dans le milieu ce n'est pas quelque chose de nouveau.
        
        tu choisis un soft principalement pour l'usage que tu en fais, pas parce que ça fait "plein de choses qu'on pouvait pas avant".
        
        Ce que je voulais te mettre en évidence, c'est que tu utilises aujourd'hui des programmes dont le fonctionnement interne t'es largement inaccessible. Pourtant ces programmes remplacent avantageusement des programmes plus simples du passé. Donc si tu es prêt à t'accommoder de ça, tu peux le faire pour systemd.
        
        Les technos actuelles existaient pour la plupart il y a 20 ans.
        
        Pas trop non. Il suffit de voir la quantité de norme qui tentent de combler les lacunes de POSIX pour montrer que ça évolue nettement. La LSB, Freedesktop.org, les nouveautés du noyau Linux ou X.org ça ne te dit rien ? HAL, udev et autres non plus ?
        
        D'ailleurs, dans le domaine du serveur tu as la virtualisation et les serveurs d'applications qui sont de plus en plus utilisés et que systemd prend en charge bien mieux que SysV. ces applications étaient marginales voire inexistantes il y a 20 ans…
        
        Or, l'utilisation principale de Linux (l'OS) c'est le serveur
        
        Référence nécessaire, je dirais que le téléphone mobile est équivalent maintenant.
        
        'est une niche peu confrontée aux problématiques de matériel modulaire et de contexte de config qui change tous les jours.
        
        Domaine qui est confronté aux migrations de systèmes, mises à jour et gestion des distributions où les scripts SysV n'étaient pas compatibles entre eux.
        
        S'il faut se palucher en plus la doc de systemd pour démarrer 3 pauvres services sur un LAMP alors que 3 lignes de shell suffisent, alors c'est une usine a gaz.
        
        Il faut se farcir la doc pour écrire un lanceur de LAMP en tant que démon. Doc bien plus obscur et moins généraliste entre distribution que ne peut le faire systemd.
        Pour écrire un service sur systemd, c'est très simple et rapide. Le temps d'apprentissage est bien plus court.
        Quand systemd sera bien ancré partout, ça posera moins de soucis dans ces situations…
        
        Sans compter la maintenance qui est simplifié avec de nouveaux usages possibles.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 18:01. Évalué à 1.
        
        Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur et le serveur c'est que du cas particulier, c'est pour ça qu'on paye des gens pour faire la config.
        
        Red-Hat qui a je pense un coeur de métiers qui fait que s'ils se loupent sur le marché des serveurs ils vont le regretter.
        
        Rajoute SUSE.
        Ca fait que les 2 plus gros acteurs de Linux sur les système sensibles sont avec systemd, en plus des mainteneurs de Debian (aussi pas du tout sur les seurveurs…), mais ils ont tous tort, ces idiots vraiment… En attendant, ceux qui ont tort comme ça sont la, font du business (mais on va me dire que c'est un gros mot :) ).
        
        Perso, je me marre bien avec ces exemples!
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 15:21. Évalué à 0.
        
        ne sont plus pertinents aux yeux des mainteneurs
        
        C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.
        
        systemd c'est la difficulté et SysV la facilité,
        
        De mon point de vue, systemd n'est qu'une évolution de system V : un pas de plus vers de la complexité non nécessaire dans le cas général. System V n'est ni plus ni moins que l'éclatement d'un script d'init dans 36 répertoires, liens symboliques et fichiers. En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.
        Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final…
        
        Tout change, tout évolue et il faut s'adapter et dans le milieu ce n'est pas quelque chose de nouveau.
        
        Le changement c'est bien quand c'est nécessaire. Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs). Mon besoin n'a pas changé et pourtant je vais être amené a changer : est-ce une bonne chose ?
        Un peu comme quand on décide de changer l'orga des menus de Gnome parce que "c'est mieux". Sauf que 2 ans plus tard, on fait machine arrière parce que ça pue. Le problème n'est pas d'avoir essayé (bien au contraire), le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.
        
        La LSB, Freedesktop.org, les nouveautés du noyau Linux ou X.org ça ne te dit rien ? HAL, udev et autres non plus ?
        
        En termes de technos oui c'est plus ou moins récent, mais les concepts sous jascents sont loin de l'être.
        La LSB, c'est bien le machin qui impose de supporter RPM, qui crée des répertoires doublons au FHS et qui t'impose de supporter un init system V et qui définit les runlevel ? Tellement une avancée que toutes les distro majeures la supporte, comme debian met qui les sites web et les instances SGBD dans /srv/ ?
        X.org n'est qu'une implémentation de X, un protocole qui a … 30 ans.
        Freedesktop, c'est sympa et le fait que ça ait fédéré les dev d'outils desktop est une bonne chose. Après, je ne connais pas tous les projets dans le détail, mais je n'ai pas l'impression qu'il aient innové techniquement, ils se sont surtout concentrés sur des définitions d'apis et d'outils.
        
        Mais que fait udev ? Gérer des fichiers de devices dans /dev ? Ah, le vrai changement c'est qu'il annonce les changements matériels via dbus : wow quelle révolution ! A la limite, ils auraient cassé le systeme de /dev, je dis pas, mais ils ne l'ont pas fait pour répondre a la LSB.
        HAL c'est l'implémentation d'une approche qui était déjà exploitée notoirement dans … Windows NT et probablement dans d'autres systèmes avant lui. Oui c'était une nouveauté linux mais les concepts sont plutôt anciens.
        Excuse moi mais ce sont des changements de techno mais les changement techniques relèvent de l'implémentation, pas du concept.
        
        Dans la série des nouveautés, tu peux rajouter le NoSQL (technos des années 80 resservies à la sauce webservice), REST ou comment faire du RPC sur http, HTML 5 ou comment développer des fonctionnalités qui existent depuis au moins 15 ans (super, on peut faire du drag n drop et lire des videos dans une IHM \o/).
        
        Référence nécessaire, je dirais que le téléphone mobile est équivalent maintenant.
        
        A mon avis le noyau linux est majoritairement installé sur des téléphones mobiles (faudrait trouver des chiffres). Sauf que je précise bien que ne parle pas du noyau mais de linux en tant qu'OS (GNU/Linux, si tu préfères). Et Android n'est pas un OS de type GNU/Linux. D'ailleurs, utilise-t'il systemd ?
        
        Domaine qui est confronté aux migrations de systèmes, mises à jour et gestion des distributions où les scripts SysV n'étaient pas compatibles entre eux.
        
        Et avec systemd, pof, ça marche en un clic ?
        
        Il faut se farcir la doc pour écrire un lanceur de LAMP en tant que démon.
        
        Etape obligatoire quelque soit ton gestionnaire de service non ?
        A moins que ça soit tellement bien qu'il n'y a plus de shellscript dans toute la chaîne et que ça fasse le httpd.conf tout seul ?
        
        Doc bien plus obscur et moins généraliste entre distribution que ne peut le faire systemd.
        
        Actuellement, vu le nombre de distro qui utilisent systemd, je ne comprend pas comment du peux parler de généralités dans les config. Sans compter que systemd ou pas, je ne connais auncune distro qui n'a pas de spécificité dans sa config. Et puis, le problème se posera toujours si tu dois naviguer entre linux et un autre Unix.
        
        Le temps d'apprentissage est bien plus court.
        
        Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD
        A moins que systemd soit tellement bien foutu qu'il te gère tout seul tes vhosts apache et tes instances PostgreSQL ?
        
        Sans compter la maintenance qui est simplifié avec de nouveaux usages possibles.
        
        A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.
        Comprend que ce type d'arguments relève plus du décideur pressé que de la réalité quotidienne.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 15:52. Évalué à 1.
        
        C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.
        
        Le mainteneur est confronté aux problèmes des sys admin. L'utilisateur final de systemd ce sont les mainteneurs et les sys admin, pas les autres qui effectivement ne verront pas une différence directe (mais indirectement, s'il y a moins de temps à passer pour gérer les services, la qualité globale du système augmente et cela permettrait de se concentrer sur d'autres tâches).
        
        un pas de plus vers de la complexité non nécessaire dans le cas général.
        
        Pourtant, les gens n'arrêtent pas de lister des cas où SysV a montré ses limites. Pour moi c'est la preuve que c'est nécessaire, pas pour tout le monde certes, et alors ? Gnome est une complexité non nécessaire pour certaines actions faisable plus efficacement en console, cela n'enlève pas son intérêt global d'exister.
        
        En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.
        
        À lire les anti-systemd qui veulent un retour à SysV et non vers une autre solution, on voit qu'il y a un soucis de discours.
        C'est de la résistance au changement.
        
        Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final…
        
        Qui est l'utilisateur final ? L'admin système et le créateur de la distribution ont un gain évident dans l'affaire. L'utilisateur moyen non, mais est-ce qu'on râle sur des nouveautés de gcc que l'utilisateur moyen ne verra pas non plus ?
        
        Le changement c'est bien quand c'est nécessaire.
        
        Il faudra combien de messages avec la liste des gains apportés pour que tu voies que c'est nécessaire ?
        Et combien de distributions vont devoir migrer pour te montrer qu'ils le font car ils savent qu'ils ont à y gagner ?
        
        Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs).
        
        Tout le monde s'en fout de ton besoin ou du mien. Dans le LL, le besoin qui est représenté est celui qui code. C'est comme ça. Ils dictent les changements car ils travaillent avant tout pour eux (ils veulent forcément que l'outil qu'ils développent répondent à leur besoin, à moins d'être maso et de programmer un utilitaire dont on ne souhaite pas l'utiliser).
        
        Et si ton besoin n'a pas évolué, celui des autres oui, et systemd s'adapte à ce changement. D'autant qu'en étant compatible avec SysV, il peut satisfaire les "besoins" des "anciens".
        Encore faut-il démontrer le besoin réel auquel répond SysV et pas systemd.
        
        le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.
        
        Ce n'est pas expérimental. Systemd est en développement très actif mais j'ai connu très peu de problèmes avec. J'en ai connu avec SysV aussi…
        Ce n'est pas comme avec PA où en effet au début les problèmes étaient plus la norme que le bon fonctionnement. Systemd fonctionne très bien. Puis après on ne peut pas accuser le développeur d'un programme d'avoir son outil dans des distributions par défaut. Ce sont elles qui font le choix et en sont responsables.
        
        En termes de technos oui c'est plus ou moins récent, mais les concepts sous jascents sont loin de l'être.
        
        Oui, enfin osef. Une technologie qui n'existait que dans un garage ou de manière inaboutie ce n'est pas très intéressant. Cela reste des nouveautés qui impliquent de nouveaux usages et de nouveaux besoins.
        
        Typiquement udev (et HAL) permettent de gérer l'histoire des périphériques à chaud qui existaient depuis un bail mais qui sont populaires depuis seulement une décennie pour l'ordinateur moyen. Et étant donné la fréquence d'utilisation de ces périphériques aujourd'hui, heureusement qu'il y a des mécanismes similaires.
        
        Le concept est certes vieux, mais comme il était discret, le cas d'utilisation n'était pas gérée ou de manière trop légère.
        
        Et avec systemd, pof, ça marche en un clic ?
        
        Non, mais certains problèmes qu'il y avait avec SysV n'existe plus, ou sont plus simples à gérer.
        C'est là l'intérêt…
        
        Etape obligatoire quelque soit ton gestionnaire de service non ?
        
        Je ne dis pas le contraire. Mais certains semblent oublier que SysV nécessite un apprentissage.
        Et la courbe d'apprentissage de systemd semble intéressante vis à vis de SysV.
        
        Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD
        
        Où j'ai dis ça ? J'ai l'impression que tu négliges le temps de rédiger un démon sous SysV de manière propre. Car oui, gérer cela de manière propre est assez long et périlleux par rapport à une unité de systemd qui t'abstrait de l'implémentation de concepts délicats à gérer comme les dépendances de processus ou du chemin d'accès à certains fichiers.
        
        A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.
        
        C'est à se demander si tu as lu la doc de systemd et si tu t'en es réellement servi un jour.
        Les unités de systemd peuvent différer entre distributions pour un service donné. Systemd ne change rien à ce fait et chaque distribution peut avoir sa petite touche personnelle.
        
        Ce qui change c'est que si Debian fait une unité adaptée pour httpd, un utilisateur de Fedora intéressé pourra copier/coller ce fichier et l'utiliser et ça fonctionnera. C'est ça qui est intéressant.
        Essaye de le faire avec SysV, tu vas prendre un certains temps à adapter le script…
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 17:14. Évalué à -1.
        
        C'est à se demander si tu as lu la doc de systemd et si tu t'en es réellement servi un jour.
        
        Servi oui, en tant que lambda sur une fedora et même si j'ai crouté le boot avec un simple CTRL + ALT + SUP, je ne le met pas sur le dos de systemd.
        Lu la doc non, parce que, comme dit au dessus, je fais de la paleo informatique et dans ma boite, les serveurs et les technos évoluent au fil du besoin et des contraintes, pas des sorties des softs et même si je fais encore un peu d'admin, je m'oriente de plus en plus vers le dev (ma spé principale), justement parce que plus ça va, plus c'est compliqué de faire ce qui se faisait simplement il y a 10 ans.
        D'un pauvre script rc.M ou tu rajoutais ton /usr/local/bin/pg_ctl start -D /pathmabase, maintenant il te faut pondre un script complet start/stop/restart/magrandmereenstring avec des contraintes moisies pour gérer des cas que tu pouvais déjà gérer avant.
        Ce n'est pas de la nostalgie, c'est une constatation.
        
        Et systemd n'y change rien, amène une couche expérimentale (j'insiste : pas de roadmap claire, pas de norme) monolithique et intégrée qui fait le café et les patisseries qui l'accompagnent. Et moi je me dis merde, va me falloir manger une couche supplémentaire.
        
        Ce qui change c'est que si Debian fait une unité adaptée pour httpd, un utilisateur de Fedora intéressé pourra copier/coller ce fichier et l'utiliser et ça fonctionnera. C'est ça qui est intéressant.
        
        C'est bien le seul argument qui me semble intéressant au sens large dans tout ce qui a été dit pour nous vendre systemd dans ce thread. Ça reste léger et ne me concerne pas.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 25 mars 2014 à 17:46. Évalué à 7.
        
        D'un pauvre script rc.M ou tu rajoutais ton /usr/local/bin/pg_ctl start -D /pathmabase, maintenant il te faut pondre un script complet start/stop/restart/magrandmereenstring avec des contraintes moisies pour gérer des cas que tu pouvais déjà gérer avant.
        
        T’as pas dû en écrire beaucoup des unités systemd… Je vais prendre l’exemple d’Arch qui proposait un «init à la BSD» que l’on cite souvent ici comme un exemple de bon systèmes d’initialisation.
        
        kdm.service:
        
        [Unit] Description=K Display Manager After=systemd-user-sessions.service [Service] ExecStart=/usr/bin/kdm -nodaemon [Install] Alias=display-manager.service
        
        ancien script kdm:
        
        #!/bin/bash . /etc/rc.conf . /etc/rc.d/functions PID=$(pidof -o %PPID /usr/bin/kdm) case "$1" in start) stat_busy "Starting KDE Desktop Manager" [ -z "$PID" ] && /usr/bin/kdm &>/dev/null if [ $? -gt 0 ]; then stat_fail else add_daemon kdm stat_done fi ;; stop) stat_busy "Stopping KDE Desktop Manager" [ ! -z "$PID" ] && kill $PID &> /dev/null if [ $? -gt 0 ]; then stat_fail else rm_daemon kdm stat_done fi ;; restart) $0 stop sleep 3 $0 start ;; *) echo "usage: $0 {start|stop|restart}" esac exit 0
        
        Un autre au hasard, iptables.service:
        
        [Unit] Description=Packet Filtering Framework [Service] Type=oneshot ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules ExecReload=/usr/bin/iptables-restore /etc/iptables/iptables.rules ExecStop=/usr/lib/systemd/scripts/iptables-flush RemainAfterExit=yes [Install] WantedBy=multi-user.target
        
        avec /usr/lib/systemd/scripts/iptables-flush:
        
        #!/bin/bash # # Usage: iptables-flush [6] # iptables=ip$1tables if ! type -p "$iptables"; then echo "error: invalid argument" exit 1 fi while read -r table; do tables+=("/var/lib/$iptables/empty-$table.rules") done <"/proc/net/ip$1_tables_names" if (( ${#tables[*]} )); then cat "${tables[@]}" | "$iptables-restore" fi
        
        ancien script iptables.rc:
        
        #!/bin/bash # source application-specific settings [ -f /etc/conf.d/iptables ] && . /etc/conf.d/iptables # Set defaults if settings are missing [ -z "$IPTABLES_CONF" ] && IPTABLES_CONF=/etc/iptables/iptables.rules . /etc/rc.conf . /etc/rc.d/functions case "$1" in start) if [ ! -f "$IPTABLES_CONF" ]; then echo "Cannot load iptables rules: $IPTABLES_CONF is missing!" >&2 exit 1 fi stat_busy "Starting IP Tables" if [ "$IPTABLES_FORWARD" = "1" ]; then echo 1 >/proc/sys/net/ipv4/ip_forward fi if ck_daemon iptables; then /usr/sbin/iptables-restore < $IPTABLES_CONF if [ $? -gt 0 ]; then stat_fail else add_daemon iptables stat_done fi else stat_fail fi ;; stop) stat_busy "Stopping IP Tables" if ! ck_daemon iptables; then fail=0 for table in $(cat /proc/net/ip_tables_names); do iptables-restore < /var/lib/iptables/empty-$table.rules [ $? -gt 0 ] && fail=1 done if [ $fail -gt 0 ]; then stat_fail else rm_daemon iptables stat_done fi else stat_fail fi ;; restart) $0 stop $0 start ;; save) stat_busy "Saving IP Tables" /usr/sbin/iptables-save >$IPTABLES_CONF if [ $? -gt 0 ]; then stat_fail else stat_done fi ;; *) echo "usage: $0 {start|stop|restart|save}" esac exit 0
        
        Note au passage la duplication de code pour gérer les commandes start, stop etc et l’affichage de l’usage de la commande. Et des exemples comme ça j’en ai à la pelle. Alors bien sûr tu peux faire ton script shell de deux lignes complètement moisi… Ou utiliser systemd qui gère tout ce merdier à ta place tout en te permettant .
        
        C'est bien le seul argument qui me semble intéressant au sens large dans tout ce qui a été dit pour nous vendre systemd dans ce thread. Ça reste léger et ne me concerne pas.
        
        L’interopérabilité des distributions, point ô combine critiqué, et sûrement le plus gros défaut de l’écosystème de GNU/Linux, ça vaut le pas.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 25 mars 2014 à 20:03. Évalué à 3.
        
        Je complète le trou (j’ai oublié de compléter avant d’envoyer):
        
        Ou utiliser systemd qui gère tout ce merdier à ta place tout en te permettant [d’avoir un script lisible et portable].
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 16:31. Évalué à 1.
        
        C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.
        
        Tu ne serais pas en train te t'auto-descendre?
        L'utilisateur final ne verra jamais systemd, n'entendra jamais son nom, c'est normal. Donc que ce ne soit pas orienté utilisateur final est… Heu, hum.
        
        un pas de plus vers de la complexité non nécessaire dans le cas général
        
        C'est fou comme les gens sont stupides au point de vouloir une "complexité non nessaire".
        Tu es de plus en plus ridicule devant ton négtionisme.
        
        Le changement c'est bien quand c'est nécessaire.
        
        Faut croire que les gens qui bossent pensent que c'est nécessaire.
        
        Encore une fois, si tu penses qu'ils font fausse route, toi et tes amis faitent une distro qui va prouver à tous les autres idiots qu'ils sont nul en choix.
        Je parie qu'on n'aura même pas la peine de regarder, vu que vous ne ferez jamais rien, car vous ne savez faire qu'une chose : résister au changement en disant plein de bêtises, sans être prêt à faire la moindre chose. Vous ne faites que ralentir l'évolution, qui se fera quand même faute d'alternative que vous proposez (maintenir le vieux truc qui prend du temps étant une alternative que vous seuls proposez, assumez et faites le).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Maclag le 26 mars 2014 à 04:41. Évalué à 10.
        
        C'est ce que je dis : ça répond a des problématiques plus orienté mainteneurs qu'utilisateur final.
        
        Personnellement, je suis bien content que les mainteneurs travaillent avec un outil qui leur permet de consolider beaucoup de code et d'être globalement plus efficaces. Je préfère ça plutôt que ramasser un bug dans un script shell dont le code est "presque pareil mais en fait non" que d'autres services/sur d'autres distros.
        
        Sinon moi je ne fais pas de développement, alors ce serait bien qu'on arrête de passer du temps sur ces absurdités de IDE et autre RAD et qu'on revienne à des choses simples et prouvées telles que Emacs/Vim, un Makefile fait à la main, et la compilation en ligne de commande dans un autre terminal. Ça a marché pendant des années, c'est le summum de la souplesse parce qu'il n'y a aucun cas de figure qui ne soit pas faisable, alors qu'un outil d'aide au développement peut mettre des restrictions à cause de conventions ou de la logique interne.
        Faut pas oublier que le résultat tourne sur ma bécane à la fin, et si je sais ouvrir et lire un Makefile, je ne comprends pas l'arborescence des trucs générés par des outils inutilement complexes.
        
        En remplacement de System V, alors il y a peut-être un progrès, mais par rapport a un init sauce BSD, c'est juste de la complexité ajoutée pour couvrir des cas peu probables, particulièrement sur des serveurs basiques.
        
        Ce qu'il y a de bien avec les cas "peu probables", c'est que ce sont forcément les cas des autres. Faudrait aussi faire le ménage dans le noyau Linux qui devient de plus en plus gros à force de supporter du matériel "peu probable", enfin tant que c'est pas le mien hein!
        
        Après c'est sur que pour un éditeur de distro, il y a clairement un gain, mais pour l'utilisateur final…
        
        Ben ça dépend s'il est concerné par le cas "peu probable", ou s'il se soucie d'avoir une montagne de scripts shell tous plus "presque pareils" les-uns que les-autres mais maintenus complètement indépendamment les-uns des-autres.
        En ce qui me concerne, ça me ferait un peu chier qu'on me dise que "non, avec Linux, tu ne pourras jamais couvrir ton cas, tu comprends beaucoup d'admin pense que ton cas est «peu probable» alors tant pis, tu dois en chier". Mais c'est assurément une opinion très personnelle.
        
        Un peu comme quand on décide de changer l'orga des menus de Gnome parce que "c'est mieux". Sauf que 2 ans plus tard, on fait machine arrière parce que ça pue. Le problème n'est pas d'avoir essayé (bien au contraire), le problème est dans le fait qu'on bascule un truc expérimental dans un outil de production.
        
        Comment on passe de "expérimental" à "prêt production"? Si aucune distro n'intègre le truc "trop expérimental", il va rester expérimental un paquet d'années. Si tu as besoin d'un truc testé pendant plusieurs années (par "les autres") avant de le voir sur ta distro, vois avec les mainteneurs de ta distro!
        
        Le changement c'est bien quand c'est nécessaire. Là, le changement va être induit par une nouvelle techno qui n'est pas développée pour répondre à mon besoin mais a celui de tiers (les mainteneurs). Mon besoin n'a pas changé et pourtant je vais être amené a changer : est-ce une bonne chose ?
        
        Pas plus que les outils de dévs qui ne me servent personnellement à rien mais qu'on a mis dans la chaîne de développement alors qu'ils automatisent tout un tas de trucs dans mon dos. Un Makefile écrit avec amour complètement à la main, c'était tellement plus simple à appréhender que tout ce fatras d'outils qui génèrent des trucs et des machins et à la fin on ne sait pas comment ton Makefile a été pondu sans lire de la doc supplémentaire.
        
        X.org n'est qu'une implémentation de X, un protocole qui a … 30 ans.
        
        Ouai, il fait un peu plus que juste supporter le protocole X. Ah, et j'ai une mauvaise nouvelle pour toi au sujet du futur de l'affichage graphique, mais je ne sais pas si tu es prêt à l'entendre…
        
        Actuellement, vu le nombre de distro qui utilisent systemd, je ne comprend pas comment du peux parler de généralités dans les config. Sans compter que systemd ou pas, je ne connais auncune distro qui n'a pas de spécificité dans sa config. Et puis, le problème se posera toujours si tu dois naviguer entre linux et un autre Unix.
        
        Un des intérêts de systemd, c'est que justement tu vas adoucir les changements d'une distro à l'autre. Après si tu râles parce que tu as trouvé une ch'toute petite différence entre 2 distros, je me demande comment tu peux supporter le méga-bordel qu'on a aujourd'hui.
        
        Et si tu dois naviguer entre Linux et d'autres Unix… ben ça ne changera rien, effectivement, ce sera autant le bordel qu'aujourd'hui. D'un autre côté, si tu veux que tout soit pareil, c'est simple: il faut installer un seul et unique OS partout!
        
        Donc lire la doc du service est plus long que lire la doc du service + la doc de systemd. CQFD
        A moins que systemd soit tellement bien foutu qu'il te gère tout seul tes vhosts apache et tes instances PostgreSQL ?
        
        Je ne pense pas que lire juste la doc du service permette de comprendre quand et dans quelles conditions/environnement son script init va être appelé. Pour ton cas, tu connais déjà l'existant, donc encore une fois: ça ne te concerne pas et par conséquent, tu t'en fous. Pour ceux qui découvrent leur premier système d'init, je ne crois pas qu'ils auront plus de mal à décortiquer systemd que sysV.
        
        A vous croire ça lave tellement plus blanc que toutes les distros seront identiques en termes de conf et que les migrations se feront en un clic. Rien que quand tu vois le support de la LSB par les distro, tu sais que ça relève du vœu pieux mais que c'est irréalisable justement parce que s'il existe différentes distros, c'est parce qu'il existes différents contextes.
        Comprend que ce type d'arguments relève plus du décideur pressé que de la réalité quotidienne.
        
        À te lire, il faut croire que si c'est pas "parfait", il vaut mieux laisser le super-méga-bordel qu'on traîne depuis des années tel quel parce que toi tu le connais bien et tu en as l'habitude.
        Franchement j'aimerais que les admins et autres qui râlent contre systemd se lancent ensembles dans un fork d'une distrib juste pour enlever systemd. Quand ils reviendront en disant qu'ils n'ont pas que ça à foutre de maintenir la chiadée de scripts init, on pourra leur expliquer que les mainteneurs des autres distros ont aussi d'autres choses qu'ils aimeraient bien faire avec leur temps.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 26 mars 2014 à 13:00. Évalué à 3.
        
        Sinon moi je ne fais pas de développement, alors ce serait bien qu'on arrête de passer du temps sur ces absurdités de IDE et autre RAD et qu'on revienne à des choses simples et prouvées telles que Emacs/Vim, un Makefile fait à la main, et la compilation en ligne de commande dans un autre terminal. Ça a marché pendant des années, c'est le summum de la souplesse parce qu'il n'y a aucun cas de figure qui ne soit pas faisable, alors qu'un outil d'aide au développement peut mettre des restrictions à cause de conventions ou de la logique interne.
        
        Je trouve ton analogie excellente. Dans un cas, tu as un produit globalement fini, mais limité par design. De l'autre tu as un outil tellement ouvert qu'il a l'air inaccessible.
        
        Que certains préfère une solution plutôt que l'autre justifie-t-il de traiter les minoritaires de relou, réfractaire, etc. ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Maclag le 26 mars 2014 à 20:53. Évalué à 9.
        
        Le point que tu rates dans l'analogie, c'est que moi, utilisateur et pas développeur, je veux avoir mon mot à dire sur les outils des développeurs (que je ne rémunère pas qui plus est), et je leur demande d'en chier parce que je ne veux pas avoir à faire à leurs nouveaux outils.
        
        Et là c'est la même chose: les mainteneurs applaudissent à deux mains, et la minorité dont tu parles vient dire "nan mais les gars, arrêtez tout: c'était mieux quand vous écriviez les scripts shell à rallonge" et pourquoi c'était mieux? ben parce que "les scripts shell, je sais les lire depuis le temps, alors que systemd, j'ai pas super envie d'apprendre, ça a l'air compliqué". Tu t'attends à quoi comme réaction?
        
        Je peux en faire d'autres, des analogies du genre:
        "Je ne sais pas me servir d'un ordinateur alors encore moins lire des emails. Ça me fait chier d'apprendre, un ordinateur ça peut buguer et planter, tomber en panne, sans parler du réseau, et puis j'ai mes habitudes et mes méthodes. Merci de m'envoyer votre rapport quotidien par fax. Tout le monde sait utiliser un fax, inutile d'apporter la complexité d'un ordinateur pour un rapport!"
        Si ça ne vient pas du chef, tu n'aurais pas une méchante envie d'envoyer chier l'interlocuteur?
        
        Moi si. Est-ce que c'est tellement différent ici? Ah ben c'est sûr qu'un ordinateur est monstrueusement plus compliqué qu'une feuille qui sort toute seule de la machine. Alors quand on a l'habitude d'être la partie qui reçoit, on voit tout de suite l'intérêt de rester sur le fax: plus éprouvé, pas de formation nouvelle, simple donc fiable.
        
        De l'autre côté, il y a un mec qui en a ras-le-bol d'aller mettre du papier dans l'imprimante pour sortir son put*** de rapport, et aller le passer dans le fax, tous les jours. Et il ne comprend pas bien pourquoi il devrait continuer à se faire chier alors que la seule chose qui bloque, c'est une minorité qui n'aime pas les ordinateurs.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 26 mars 2014 à 22:26. Évalué à -3.
        
        Le point que tu rates dans l'analogie, c'est que moi, utilisateur et pas développeur, je veux avoir mon mot à dire sur les outils des développeurs (que je ne rémunère pas qui plus est), et je leur demande d'en chier parce que je ne veux pas avoir à faire à leurs nouveaux outils.
        
        Le point que tu rates dans ton analogie, c’est qu’on parle bien d’IDE, je t’aide : Integrated Development Environment. Donc oui, pour un développeur je ne trouve pas ça déconnant.
        Pour un admin système, il y a plusieurs niveau. Mme Michu, elle s’en fout, elle ouvrira pas de fichier systemd. L’admin de base fera confiance à sa distrib, avec peut-être une modif ici ou là, mais ce sera un copier/coller d’un forum.
        L’admin expert, lui, avoir une machine de turing pourrait l’aider, mais pas forcément tout le temps.
        
        Au départ, je ne voulais pas réagir, car les pro-systèmed sont largement majoritaire, et que ceux si ont tendance à insulter directement les autres. Mes réactions n’ont eu pour but que de relever des arguments que je trouve non pertinent, (le beau code parce qu’il utilise des extensions d’un compilateur…) en aucun de mettre en doute la sacro-sainte parole.
        
        Ça me rappelle une étude sur les utilisateurs d’apple dont la marque éveillait dans le cerveau les mêmes zones que la foi. Et j’ai parfois l’impression que c’est pareil pour les pro-systemd. On ne peut argumenter ne serait-ce qu’un cas sans en prendre plein la tronche gratos. C’est quoi la prochaine étape, venir nous démolir la tronche ?
        
        J’aimerai vraiment pouvoir discuter dans ce débat sereinement. Systemd apporte des évolutions sympas, tout le monde n’en ressent pas le besoin, et certains critique sa vampirisation de truc comme udev. Est-ce un délit ? Devrait-ce être un délit ? Faut-il prévenir l’exécutif ?
        
        Dans le débat, si on prend les mots violent, de dénigrement et qu’on classe cela entre les pro et les anti, car apparemment on a pas le droit d’être juste perplexe, je suis certain de savoir de quel côté est la violence des mots.
        
        sur ce à la prochaine.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 27 mars 2014 à 00:07. Évalué à 10.
        
        Au départ, je ne voulais pas réagir, car les pro-systèmed sont
        largement majoritaire
        et que ceux si ont tendance à insulter directement les autres
        
        Cf commentaire qui suit le tien sur ce qui a commencé le thread.
        Sinon, je veux bien voir ou est ce que j'ai commencé à insulter les autres. En fait, j'aimerais voir des données un peu plus précises qu'un ressenti. Même si il y a des mecs qui sont insultants ou borderline ( Zertinam me viens à l'esprit ), je n'ai pas le sentiment que ça soit la majorité.
        
        On ne peut argumenter ne serait-ce qu’un cas sans en prendre
        plein la tronche gratos. C’est quoi la prochaine étape, venir
        nous démolir la tronche ?
        
        Dans le style de ce message sur debian-devel :
        https://lists.debian.org/debian-devel/2014/02/msg00462.html
        
        Mes réactions n’ont eu pour but que de relever des arguments
        que je trouve non pertinent, (le beau code parce qu’il utilise
        des extensions d’un compilateur…)
        
        J'ai pas dit "beau", j'ai dit "Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs.", suivi des raisons qui font que je le trouve plus moderne et agréable.
        
        Tu peux relire le commentaire :
        https://linuxfr.org/news/speciale-lennart-poettering-nouvelles-versions-de-systemd-et-pulseaudio#comment-1527799
        
        Moderne, car oui, je pense qu'utiliser une extension des compilos pour gérer automatiquement une partie de la mémoire, c'est plus moderne que faire tout à la main. Moderne car il y a une suite de tests, c'est loin d'être un acquis ( exemple, la suite de tests de sysvinit ). Moderne car ça utilise par exemple git et pas bzr ou cvs.
        
        Agréable, parce que j'ai eu moins de souci à trouver ce que je voulais faire que par exemple, sur upstart. Agréable parce que je trouve que le style consistant me fait moins saigner des yeux que le code de certains plugins de sane.
        
        Ensuite,j'ai bien conscience que la beauté est un truc différent et dépendant, et c'est bien pour ça que j'ai pas utilisé ce mot. Et en effet, ça serait non pertinent de dire "le code est beau".
        Tout comme il serait non pertinent de dire "le code est moche", bien sur. Mais personne n'arrive à décrire exactement ce qui est beau et moche, donc ç'est forcement plus dur de trancher..
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 27 mars 2014 à 08:38. Évalué à 1. Dernière modification le 27 mars 2014 à 08:42.
        
        que ceux si ont tendance à insulter directement les autres.
        
        Un lien s'il te plait.
        Si dire que ta réaction est stupide ou dire que tu n'a acun argument et que c'est juste de la résistance au changement est t'insulter, il faut donc résumer ainsi : dès qu'on dit que le problème vient de toi, c'est t'insulter.
        alors, admettons, dire que tu me fais rire est limite, mais bon, tu me traite comme un idiot incapable de réfléchir 10 secondes, alors pour le niveau d'insulte…
        
        Non, la ce sont juste des faits, maclag t'a donné un super exemple, et tu continues de refuser d'ouvrir les yeux…
        
        On ne peut argumenter ne serait-ce qu’un cas sans en prendre plein la tronche gratos.
        
        Tu en prends plein la trouche car ce que tu dis est 100% mauvaise foi, sans aucun argument qui ne se fait pas démonter en 10 secondes de réflexion, utilisables partout mais que tu utlises que pour systemd.
        
        Ça me rappelle une étude sur les utilisateurs d’apple dont la marque éveillait dans le cerveau les mêmes zones que la foi. Et j’ai parfois l’impression que c’est pareil pour les pro-systemd.
        
        Le monde à l'envers : la foi est dans les anti-systemd, les "pro-systemd" ne sont pas pro du tout, ils cherchent juste un otutil ui les aide à en chier moins. Tu n'arrives à convaincre que toimême avec tes pseudo-arguments.
        Rappel : les premiers à troller son les anti-systemd qui viennent pourir une dépèche sur une présentation de systemd, comme si des anti-Linux venir dire "Linux ça pue" à chaque dépèche noyau. PERSONNNE ne vous oblige à l'utiliser (comme personne n'oblige à utiliser le noyau Linux), donc pourquoi venir le critiquer gratos? Pourquoi donc venir à chaque fois dire les pires stupidités qui montre ton incompétance (tu le prends comme insulte si tu veux, mais c'est juste un fait et non écrit comme insutant dans les dicos) et ton refus de l'accepter (ce qui est pire, mais toujours pas une insulte. Si il faut le démontrer devant un juge, pas de soucis, c'est faisable avec tout ce que tu as écrit)
        
        La, tu fais surtout de l'insulte à l'intéligence. Réfléchit un peu. (c'est un isnulte?)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 27 mars 2014 à 11:01. Évalué à 3. Dernière modification le 27 mars 2014 à 11:05.
        
        Ben tiens, « réactionnaire réfractaire au changement qui veut pas changer ses habitudes » c’est pas une insulte ?
        
        PERSONNNE ne vous oblige à l'utiliser
        
        De fait la principale inquiétude des « anti-systemd primaires réactionnaires » comme moi n’est pas tant systemd en lui même (qui est un soft que j’aime bien) que le processus de vampirisation de tout l’écosystème linux derrière (udev, dbus, logind, bientôt wayland) qui va rendre la possibilité de concurrence bien plus complexe.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 27 mars 2014 à 11:29. Évalué à 1.
        
        Ben tiens, « réactionnaire réfractaire au changement qui veut pas changer ses habitudes » c’est pas une insulte ?
        
        Merci de lire dans un dictionnaire la définition d'insulte.
        Après, si émettre une opinion basée sur des faits est une isnulte, on ne peut plus rien dire qui ne va pas dans le sens du poil de la personne concernée…
        
        vampirisation
        
        Rien que ça.
        bon, voila, dure le réactionnaire réfractaire au changement qui veut pas changer ses habitudes face à l'évolution de la technologie.
        C'était mieux avant, quand on pouvait faire son CPU à la maison avec des cartes pérforées (vu que ce genre d'argument existait déjà lors que les cartes perforées on disparues)
        Le monde évolue. rien ne t'interdit de rester dans le passé, mais rien n'interdit aux autre de t'y laisser seul et faire autre chose genre vivre dans le présent.
        
        C'ests insultant (avec ta définition) de parler de vampirisation pour décrire juste une évolution technologique qui répond mieux au besoin, juste parce qu'elle ne te plait pas, sans aucun argument (non, avant ce n'était pas mieux, des logiciels faisaient aussi x choses alors qu'on peut encore plus découper)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 26 mars 2014 à 20:57. Évalué à 10. Dernière modification le 26 mars 2014 à 21:02.
        
        Que certains préfère une solution plutôt que l'autre justifie-t-il de traiter les minoritaires de relou, réfractaire, etc. ?
        
        Faudrait peut-être pas inverser la lecture du fil de discussion, là.
        
        Le tout premier message dit en essence que systemd say-trop-complexe et oh-mon-dieu-où-est-la-doc
        
        Et les fils de discussion de ce genre où les réfractaires :
        
        disent que systemd est bloated sans même aller voir le code et sans même se documenter un minimum (ils sauraient alors que systemd c'est un coeur + une soixantaines de binaires indépendants qui font une seule chose et la font bien),
        
        disent que systemd ne te donne aucune abstraction et que c'est pas bien (les targets, les fichiers d'unit, les utilitaires autour… ce ne sont QUE des abstractions !),
        
        disent que systemd te donne des abstractions, et que c'est pas bien,
        
        disent que systemd te donne une rétro-compatibilité avec les scripts et qu'alors systemd n'a aucun intérêt,
        
        que les failles de sécurité dans 3000 scripts, c'est moins grave que dans un seul systemd
        -_-' (le concept de surface d'attaque est inconnu au bataillon. Et c'est quoi le plus simple ? Corriger systemd une fois ou corriger chaque script ? Je vous laisse deviner),
        
        disent que systemd c'est une usine à gaz faite pour le desktop - mythe N#7, sauf que systemd fonctionne très bien sur un système embarqué(mythe #7 encore), et que le premier client de systemd c'est RedHat qui n'est pas vraiment connu pour ses parts de marché dans le domaine du PC grand public,
        
        inventent des cas d'utilisation irréalistes de SysV pour rejeter systemd s'il ne sait pas les gérer,
        
        disent que les targets et le runlevels c'est du pareil au même (alors que justement les runlevels c'était de la merde parce que c'était différent selon la distro),
        
        disent qu'il n'y a pas de doc (alors qu'il y a bel et bien une doc', et bien longue en plus), et que SysV est documenté (QUOI ?),
        
        en veulent personnellement à Lennart Poettering,
        
        disent que les scripts éparpillés partout qui répètent de la logique entre eux on s'en fout (et le principe DRY, alors ? C'est pour les singes ?),
        
        disent que systemd est une boîte noire (un logiciel libre, bien écrit, et bien documenté, c'est une boîte noire !),
        
        disent que les mainteneurs de distro qui ont choisi systemd ne font que suivre la mode
        
        …
        
        Y'en a plein ~~linuxfr~~ Internet.
        
        On a aussi souvent droit sur linuxfr aux "arguments" suivants (liste non-exhaustive) :
        
        systemd c'est une tentative de contrôle des distributions tierces de la part de RedHat
        
        systemd c'est un enfant du syndrome NIH (bah voyons)
        
        Un des principaux objectifs de systemd est un boot rapide et qu'on s'en fout d'un boot rapide (alors que ce n'est qu'un effet de bord de la manière dont systemd fonctionne)
        
        Je sais pas, un moment, il faudrait se renseigner un MINIMUM sur systemd pour pas passer totalement pour une bande de personnes qui ne savent pas du tout de quoi elles parlent ! Ou alors, dire clairement qu'on est là pour le troll.
        
        Et l'analogie ci-dessus fonctionne mieux que tu ne le penses: il y a beaucoup de cas d'utilisation d'un IDE qui sont juste impossibles avec un éditeur de texte (refactoring qui touche plusieurs projets, par exemple).
        
        Il y a aussi beaucoup de cas (comme lancer/arrêter les services en réponse à un évènement - connexion Internet trouvée/perdue par exemple -) qui sont juste impossibles ou trop complexes avec SysV.
        
        Ce n'est pas qu'une histoire de style (cf. fichiers "à la ini" VS "scripts sh").
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 26 mars 2014 à 11:02. Évalué à 5.
        
        C'est ce que je dis : ça répond a des problématiques plus
        orienté mainteneurs qu'utilisateur final.
        
        Je ne suis pas d'accord. Quand tu es admin d'un service, la frontière entre "mainteneur" et "utilisateur final" est pas aussi marqué.
        
        Et je pense qu'il y a des fonctions de systemd ( le fait de régler les cgroups directement dans l'unité, les templates d'unités, le capacité à surcharger la config via des mechanismes qui embrouillent pas le système de paquets ) sont bien plus pour les admins que les mainteneurs.
        
        Donc tout dépend ce que tu appelles "utilisateur final".
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 24 mars 2014 à 17:42. Évalué à 4.
        
        Or, le desktop c'est marginal pour linux. […] Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur […]
        
        Donc selon toi, Linux est d'un usage marginal en dehors du serveur (Ubuntu? SteamOS? Android?), et il faudrait empêcher d'agir ceux qui veulent le rendre plus accessible?
        
        Or, globalement, en info, on va vers l'intégration de fonctionnalités qui n'ont rien a faire dans le soft (par ex : inetd fusionné avec le gestionnaire de boot dans le cas systemd) et on a tendance a présenter ça comme un progrès : désolé de ne pas être d'accord.
        
        Un gestionnaire de service et un système pour démarrer les services à la demande ça n'a rien à voir? Pourquoi le séparer du reste si c'est utilisé partout danr systemd et que ça permet d'avoir une syntaxe simple? Pourquoi vouloir d'un bidouillage lorsqu'on peut intégrer proprement avec une prise en charge officielle toutes les fonctionnalités d'un gestionnaire de service moderne dans le gestionnaire de service?
        
        Une usine a gaz c'est un truc qui nécessite trop de ressources pour le mettre en œuvre par rapport à l'usage qui en est fait. S'il faut se palucher en plus la doc de systemd pour démarrer 3 pauvres services sur un LAMP alors que 3 lignes de shell suffisent, alors c'est une usine a gaz.
        
        Source?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 12:24. Évalué à -3.
        
        Donc selon toi, Linux est d'un usage marginal en dehors du serveur
        
        Pas selon moi, selon les stats de user agent de tous les serveurs Web de la planete.
        Android n'est pas Linux en tant qu'OS : c'est linux en tant que noyau. D'ailleurs, je n'ai pas l'impression que systemd soit à l'ordre du jour.
        
        il faudrait empêcher d'agir ceux qui veulent le rendre plus accessible
        
        Excuse moi, mais j'ai du mal a voir ce que viens faire dans l'accessibilité un gestionnaire de boot, lanceur de services réseau et autre joyeusetés bien loin des préoccupations de l'utilisateur lambda qui ne veut pas aligner 2 lignes de code.
        
        Pourquoi le séparer du reste
        
        Parce que partout en informatique on considère comme bonne pratique de séparer les choses qui n'ont pas le même rôle ?
        Il me semble qu'il y a des différences entre démarrer des services réseau à la demande, effectuer des taches à temps défini, monter des périphériques ou configurer des interfaces réseau. Apparemment la modernité considère que non :D
        
        Pourquoi vouloir d'un bidouillage
        
        L'init d'un Unix un bidouillage ? Une sacrée bidouille alors… Que dire alors de tout le reste !
        
        lorsqu'on peut intégrer proprement
        
        Proprement ? Dans un SPOF nécessitant une maitrise poussée du bousin pour savoir ce qu'il va faire implicitement ? Moi qui croyait que l'implicite n'était pas vraiment une bonne chose dans un système un tantinet complexe…
        
        une prise en charge officielle
        
        Officielle de quoi ?
        
        Source?
        
        Pour la définition, je te donne la mienne afin d'avoir une base de discussion, si tu en as une : envoie.
        Quand à démarrer apache/php et mysql, ça tient avec une ligne par commande, donc pas 3 comme j'ai dit mais 2 (si tu utilises mod_php).
        Mais il est vrai que c'est beaucoup plus compliqué à force de vouloir faire des trucs qui prennent en compte les cas particuliers de chaque installation / distribution.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 25 mars 2014 à 17:26. Évalué à 5.
        
        Donc selon toi, Linux est d'un usage marginal en dehors du serveur
        
        Pas selon moi, selon les stats de user agent de tous les serveurs Web de la planete.
        Android n'est pas Linux en tant qu'OS : c'est linux en tant que noyau. D'ailleurs, je n'ai pas l'impression que systemd soit à l'ordre du jour.
        
        Pourquoi limiter à GNU/Linux? systemd ne dépend que de Linux à ce que je sache. Et on pourrait très bien imaginer que Android passe à systemd, et il y aura sûrement des systèmes d’exploitation mobile avec systemd à l’intérieur qui vont débarquer (Ubuntu Touch, Jolla…).
        
        il faudrait empêcher d'agir ceux qui veulent le rendre plus accessible
        
        Excuse moi, mais j'ai du mal a voir ce que viens faire dans l'accessibilité un gestionnaire de boot, lanceur de services réseau et autre joyeusetés bien loin des préoccupations de l'utilisateur lambda qui ne veut pas aligner 2 lignes de code
        
        Rendre un système plus accessible, ça veut dire:
        
        plus rapide
        
        plus sécurisé
        
        plus automatisé
        
        Oh magie, c’est ce que fait systemd en démarrant les services en parallèles (et le reste il y a des exemples dans la dépêches).
        
        Pourquoi le séparer du reste
        
        Parce que partout en informatique on considère comme bonne pratique de séparer les choses qui n'ont pas le même rôle ?
        Il me semble qu'il y a des différences entre démarrer des services réseau à la demande, effectuer des taches à temps défini, monter des périphériques ou configurer des interfaces réseau. Apparemment la modernité considère que non :D
        
        Source de systemd. Oh c’est magnifique, plein d’utilitaires qui font une chose et qui le font bien, qui combiné entre eux font un logiciel complet appelé systemd.
        
        Pourquoi vouloir d'un bidouillage
        
        L'init d'un Unix un bidouillage ? Une sacrée bidouille alors… Que dire alors de tout le reste !
        
        Peut-être pas quand il a été créé. Mais comme expliqué plusieurs fois dans les commentaires par moi-même et d’autres, il a beaucoup de défauts qui était réglé par systemd, ou alors il faisait les mêmes choses de manière beaucoup plus propre puisque les mainteneurs l’on choisi en remplacement.
        
        lorsqu'on peut intégrer proprement
        
        Proprement ? Dans un SPOF
        
        Source?
        
        nécessitant une maitrise poussée du bousin pour savoir ce qu'il va faire implicitement ? Moi qui croyait que l'implicite n'était pas vraiment une bonne chose dans un système un tantinet complexe…
        
        En quoi c’est implicite? Pour le lancement par socket il y a des unités .socket, pour un lancement au démarrage il y a des .service.
        
        une prise en charge officielle
        
        Officielle de quoi ?
        
        Du démarrage par socket.
        
        Source?
        
        Pour la définition, je te donne la mienne afin d'avoir une base de discussion, si tu en as une : envoie.
        
        Non, la définition je l’ai recopié parce que j’ai répondu paragraphe par paragraphe.
        
        Quand à démarrer apache/php et mysql, ça tient avec une ligne par commande, donc pas 3 comme j'ai dit mais 2 (si tu utilises mod_php).
        Mais il est vrai que c'est beaucoup plus compliqué à force de vouloir faire des trucs qui prennent en compte les cas particuliers de chaque installation / distribution.
        
        En quoi c’est plus compliqué avec systemd?
        
        Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 22 mars 2014 à 23:05. Évalué à 3.
        
        Clair que les scripts bash qui se baladent et non facilement maitrisable sur qui fait quoi, c'est très maintenable.
        
        Je sais pas de quel système tu parle (Android ?), mais chez moi les scripts d'init sont tous dans /etc/init.d, avec de la conf dans /etc/default. Chaque script d'init s'occupe d'une seule chose et s'exécute dans un ordre bien précis.
        
        À te lire on dirait que bash est un objet quantique et que c'est le script d'init de cron qui configure le réseau.
        
        Et si tu trouve que le code de systemd est plus maintenable que des scripts shells, et bien je veux bien te regarder.
        
        tu parles bien des systèmes d'init avant systemd, on est d'accord?
        
        Non, je te parle des 30000 lignes de code de systemd, là ou tout mon init.d (avec une bonne tétrachiée de démons et de conf, plus que sur un desktop normal) n'en fait que 10000, /etc/init.d/rc compris. Et bash reste bien plus lisible et plus compact que du C.
        
        Sauf que la, c'est plus que l'init.
        
        Pourquoi le code de systemd est plus gros que ce qui sert à démarrer absolument tout les démons et les fonctionnalités noyaux qui me servent sur mon système, qui tiens plus d'un hybride serveur-desktop que d'un serveur ou un desktop habituel ?
        
        Si seul l'init t'interresse, la doc est moins bordélique (c'est pas du bash qui plante car tu n'es pas sur la bonne distro et que tu as pas pensé à la petite subtilité de la distro) et petite.
        
        Genre il y a des distros sur lequel le language bash n'est pas le même ? Tu crois vraiment à ce que tu dit ?
        
        Et moi je préfère lire un script de 3 pages que de lire 30 pages de doc.
        
        Tes exemples ensuite n'ont rien à voir : Mac OS X est simple pour l'utilisateur, ça ne dit pas que ce qu'il y a dessous est simple.
        
        C'est toi qui n'a rien compris: on me dit que pour que Linux soit utilisable, il doit être complexe. La réponse est non. Merci.
        
        Et tu donnes d'ailleurs un très bon exemple : pour le moment, la charge de travail est pour le mainteneur de distro et les utilisateurs
        
        La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.
        
        Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne.
        
        Peut-être parce que c'était le cas ? Après si tu préfère les systèmes centralisés interdépendants qui gèrent 90% des services de la machine "parce que c'est plus simple" qu'un système ou on sépare les choses bien comme il faut dans des couches et/ou des processus séparés, je ne vois pas ce que tu fout sur Internet ou sur un système Unix (malgré ses origines téléphonistes chez AT&T).
        
        Et ce n'est pas parce que systemd est à la mode chez les mainteneurs que ça le sera pour l'éternité. Les mainteneurs ne font généralement que suivre les projets upstreams: si Gnome veux du policykit, du consolekit et du systemd, alors les mainteneurs vont avoir tendance à intégrer policykit, consolekit et systemd plutôt que réimplémenter Gnome.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 22 mars 2014 à 23:13. Évalué à -2. Dernière modification le 22 mars 2014 à 23:17.
        
        un système ou on sépare les choses bien comme il faut dans des couches et/ou des processus séparés
        
        J'espère pour toi, pour être cohérant avec ce que tu dis, que tu es sous GNU Hurd et pas cette saloperie de bloat et code non-maintenable avec des couches et de processus séparés (ben oui, noyau monolythique, tout en bordel dans un gros truc, c'est horrible d'après toi) qu'est Linux.
        
        Bizarre cette intuition, je parie qu'en fait tu en utilises déjà un de bloat et code non-maintenable (ben oui, tu parles de systemd).
        Ou comment avoir des arguments utilisés que quand on a envie et oubliés dans d'autres cas. Assume tes arguments, fuit Linux plutôt que de faire croire que Linux est trop bien écrit avec des couches séparées ou un processus fait un truc et seulement un, mais de façon trop bien, car systemd n'est que la méthode Linux appliquée à l'init.
        
        Les mainteneurs ne font généralement que suivre les projets upstreams
        
        quel projet upstream pour systemd? Linux? (vu que systemd est pid 1…)
        Tu as des argumetns très "percutants" : tu prends les mainteneurs pour des idiots incompétants qui font des trucs à la mode, et c'est tout. Sympa pour eux. Ca démontre encore une fois tout sur les "arguments" des gens qui critiquent systemd.
        hum…
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 23 mars 2014 à 00:25. Évalué à 2.
        
        J'espère pour toi, pour être cohérant avec ce que tu dis, que tu es sous GNU Hurd et pas cette saloperie de bloat
        
        Linux, bloat ? Va falloir me le démontrer ça. T'a un noyau avec moins de ligne de code compilées avec à peu près autant de fonctionnalités à proposer ?
        
        et code non-maintenable
        
        Quasiment toutes les fonctionnalités sont optionnelles, avec des API bien séparées entre les composants, et des modules chargeables délégués à l'espace utilisateur, comme beaucoup d'autres fonctionnalités d'ailleurs. Et la qualité du code est incomparable avec systemd ou la plupart des autres logiciels que tu utilise.
        
        Argument sans fondement.
        
        quel projet upstream pour systemd? Linux? (vu que systemd est pid 1…)
        
        Gnome, X et bien d'autres. Faut sortir de ta grotte un peu.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Albert_ le 23 mars 2014 à 08:34. Évalué à -2.
        
        Euh zenitram ne se sert pas de linux car il croit que c'est inutilisable. Donc il troll mais systemv ou systemd il s'en fout au mieux.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 23 mars 2014 à 09:09. Évalué à 1. Dernière modification le 23 mars 2014 à 09:10.
        
        Au mieux tu as une mémoire très limitée, au pire tu mens.
        Ce n'est pas la première fois que je te corrige pour te dire que j'utilise Linux.
        Ce n'estp as parce que je n'utilise pas Linux sur le desktop que je ne l'utilise pas sur des servuers.
        Ha oui, j'avais oublié : le monde est binaire, dans certaines têtes impossible de vivre sans mettre dans des cases "il utilise" ou "il n'utilise pas".
        Et impossible d'imaginer qu'une personne souhaiterai que Linux sur le desktop soit assez utilisable pour l'utiliser, genre avec systemd qui en ferait un OS desktop moderne.
        Triste monde de rejet de celui qui n'est pas à 100% dans la communauté.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Albert_ le 23 mars 2014 à 12:42. Évalué à 1.
        
        Donc tu utilises un serveur linux que tu as installe toi meme et qui est sous systemd?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 11:48. Évalué à 7.
        
        Linux, bloat ? Va falloir me le démontrer ça. T'a un noyau avec moins de ligne de code compilées avec à peu près autant de fonctionnalités à proposer ?
        
        Minix par exemple a beaucoup moins de lignes de code que Linux. Et la difference du nombre de fonctionnalités entre Minix et Linux doit etre à peu près comparable à SysVinit et systemd.
        
        Et la qualité du code est incomparable avec systemd ou la plupart des autres logiciels que tu utilise.
        
        Tu te bases sur quoi pour juger la qualité du code de systemd ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 11:41. Évalué à 7.
        
        La charge de travail de quoi ? De l'écriture du script d'init ? Désolé mais elle reviens à l'auteur upstream du démon qui doit fournir un script LSB (sous Linux). Libre aux distributions de patcher ce script si elles veulent améliorer les choses.
        
        Oui, en théorie, "il suffit de" prendre le script fait par upstream, et tout fonctionne parfaitement sans jamais aucun probleme.
        
        Tout comme il suffit de faire "./configue; make; make install" pour installer n'importe quel programme. Tout fonctionne, il n'y a jamais aucun probleme de compilation, d'incompatibilité avec une lib ou autre. En theorie.
        
        En fait c'est vraiment simple de créer une distribution. En theorie il n'y a rien à faire, tout est fait par upstream.
        
        Et après ca ils viennent nous parler de charge de travail, quelle bande de faineants !
        
        Au fait, tu as deja maintenu un paquet avec un script d'init dans une distribution ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 23 mars 2014 à 11:44. Évalué à 5.
        
        Au fait, tu as deja maintenu un paquet avec un script d'init dans une distribution ?
        
        Le mieux est dans plusieurs distributions.
        Car c'est bien connu que les gens aiment le travail identique démultiplié juste à cause de petites bizaretés, c'est tellement amusant de débugguer plutôt que de prendre le script du voisin tel quel.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 16:53. Évalué à -2.
        
        Maintenir un paquet dans une distro c'est le boulot des devs de la distro, pas du développeur du soft (enfin après il fait ce qu'il veut, s'il aime souffrir :) ).
        Et je ne vois pas pourquoi un mainteneur debian irait tenir a jour un paquet redhat.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 24 mars 2014 à 19:34. Évalué à 3. Dernière modification le 24 mars 2014 à 19:35.
        
        Ben non.
        
        Le principe avec les unit files de systemd, c'est qu'un seul fichier soit upstream, et que toutes les distributions utilisent le fichier fourni par upstream (cf. le(s) développeurs(s) du projet X qui en a besoin).
        
        Et si c'était un script, on pourrait parler de souffrance. Avec les unit files de systemd, c'est plutôt une joie. ;-)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 11:13. Évalué à 0.
        
        Le principe avec les unit files de systemd
        
        C'est bien beau les principes, mais il faudrai regarder les faits en face: Toutes les distributions ne sont pas identiques, certaines vont vouloir privilégier la sécurité, d'autres vont vouloir privilégier la simplicité, la légèretée, le fait d'avoir un / read only ou qui supporte un nombre limité d'écriture, ou d'avoir des invariants folkloriques à respecter …
        
        Tu va pas me faire croire que toutes les cas d'usages d'un démon se résolvent par un seul fichier d'unit unique. Si toutes les distributions passent à systemd, je te garanti qu'elles n'utiliseront pas les mêmes units. Si c'est le cas actuellement, c'est juste que toutes les distributions ne sont pas passées à systemd (heureusement).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 11:36. Évalué à 7.
        
        je te garanti qu'elles n'utiliseront pas les mêmes units.
        
        Possible, et en soit ça n'aura pas une grande importance.
        Un fichier init donne les paramètres pour lancer un service dans une syntaxe précise et en couvrant un maximum de configurations possibles. Si une distribution veut changer un fichier unit pour une raison X ou Y, ce n'est pas grave car comme la syntaxe et les possibilités sont uniformisées, un fichier unit d'une distribution fonctionnera forcément dans une autre.
        
        Avec SysV ce n'était pas le cas, car chaque service vérifie des trucs dans son coin de manière non harmonisée, les noms de fichiers ou les chemins d'accès diffèrent entre distributions, etc. Ce qui fait que le copier/coller n'est pas possible.
        
        Systemd corrige cela et c'est déjà un grand pas en avant.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 15:35. Évalué à 3.
        
        Même si chaque distrib devra maintenir une unité spécifique, ça sera toujours beaucoup plus simple et documenté qu'avec des scripts.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 19:39. Évalué à 2. Dernière modification le 24 mars 2014 à 19:41.
        
        Et je ne vois pas pourquoi un mainteneur debian irait tenir a jour un paquet redhat.
        
        Oui, donc tu aimes continuer "comme avant" en faisant 36x la même chose alors qu'on a une solution pour que les mainteneurs aient juste à se passer un fichier identique de config (et le mettre upstream).
        
        surtout, ne change rien, continue à vouloir faire 36x un taf qu'on sait aujourd'hui automatiser, mais les autres ne souhaitent pas te suivre. Pour une fois que des gens qui bossent* sont d'accord pour faire un choix cimmun, il faut quand même des râleurs externes pour leur dire que de vivre ensemble, ça pue.
        
        Ou comment faire du communautaire (dans le sens négatif : diviser), quitte à souffrir (enfin : que les autres souffrent).
        
        Le monde change, évolue, se simplifie, malgré les réticences de râleurs qui ne se tapent pas le travail. A croire que vivre ensemble, se mettre d'accord, c'est mal et qu'il y en a qui n'aiment pas que les gens se mettent ensemble pour se simplifier la vie. Après, c'est une simple démonstration de la vraie vie ailleurs certes…
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 15:27. Évalué à 10.
        
        Chaque script d'init s'occupe d'une seule chose et s'exécute
        dans un ordre bien précis.
        
        Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
        
        On va prendre par exemple bind9. Dans le script de bind9, le script fait :
        - l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
        - le chargement d'un module ( capabilities )
        - la creation de /var/run/named
        - vérifie que le réseau est configuré avant de lancer bind
        
        Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
        
        On peut voir dbus. Il fait :
        - création du repertoire pour le pid
        - vérification si /proc est monté
        - génere un fichier /etc/machine-id si absent
        
        On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
        
        Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
        
        [misc@venser init.d] $ wc -l saslauthd 403 saslauthd
        
        Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
        
        Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
        
        RUN_DIR=`echo "$OPTIONS" | xargs -n 1 echo | sed -n '/^-m$/{n;p}'`
        
        Code copier coller entre le start et le stop, au passage.
        
        Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
        
        Un autre exemple pour la route ?
        
        Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
        
        Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
        
        NEED_CHROOT=$(awk '/^[0-9a-z]/ && ($5 ~ "[-yY]") { print "y"; exit}' ${config_dir}/master.cf)
        
        Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 23 mars 2014 à 21:18. Évalué à -6.
        
        On va prendre par exemple bind9. Dans le script de bind9, le script fait :
        - l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
        
        Sans utiliser resolvconf ? Oh le bon vieux script que voila.
        
        le chargement d'un module ( capabilities )
        
        Qui n'existe pas. On sent le script maintenu.
        
        la creation de /var/run/named
        
        Ça par contre tu ne peux pas y couper. Si tu veux créer ce répertoire lors de l'installation du paquet, et bien ça marchera pas, point.
        
        vérifie que le réseau est configuré avant de lancer bind
        
        Avec ifconfig en plus, quelle plaie. Personne n'a du retoucher ce script depuis des lustres.
        
        On peut voir dbus. Il fait :
        - création du repertoire pour le pid
        
        Ça tu peux pas y couper.
        
        vérification si /proc est monté
        
        Qui sert à rien, vu que ce script dépend de remote_fs, qui lui dépend plus ou moins directement de mountall.
        
        génere un fichier /etc/machine-id si absent
        
        Fichier qui, si je me souviens bien, est également généré lors du postinst.
        
        Enfin bref, les scripts d'init sont écrits par des abrutis, pourtant tu les comprend rapidement.
        
        Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
        
        La logique de lancement d'un processus dans systemd: une fonction de 614 lignes, dont la longueur des lignes va jusqu'à 142 caractères. Et qui bien entendu appelle d'autres fonctions écrites dans le même style. J'ai besoin d'élaborer ?
        
        Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
        
        La seule formation qu'un admin à besoin pour comprendre ça, c'est savoir lire du shell. De toute façon il faudra forcement qu'il en écrive un jour.
        
        Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
        
        Comme systemd, quoi. Sauf que là c'est lisible.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par anaseto le 23 mars 2014 à 22:19. Évalué à 2.
        
        En tous cas, chez OpenBSD, le script d'init de named c'est ça :
        
        #!/bin/sh # # $OpenBSD: named,v 1.1 2011/07/06 18:55:36 robert Exp $ daemon="/usr/sbin/named" . /etc/rc.d/rc.subr pexp="named: \[priv\]" rc_cmd $1
        
        qui doit être plus court et lisible que l'unit de systemd, et que ce script d'init de Debian. Au passage, on remarque que ça fait plus de deux ans qu'ils n'ont pas senti le besoin de changer ça.
        
        Après, ceci est juste ce que j'en vois, en tant qu'utilisateur naïf de système d'init aux besoins limités, peut-être que pour des besoins avancés c'est insuffisant, et que c'est pour ça que cet OS n'est pas utilisé aussi massivement… aucune idée.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 23 mars 2014 à 22:55. Évalué à 10.
        
        Le bind9.service dans Debian unstable:
        
        [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target [Service] ExecStart=/usr/sbin/named -f -u bind ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 23:59. Évalué à 10.
        
        C'est en effet court, mais buggué. Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi ( cf http://www.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr?rev=1.70;content-type=text%2Fplain ).
        Mais bon, openbsd a juste chroot comme solution de container, et la virtualisation du réseau, donc c'est pas non plus l'os de choix pour ça.
        
        De plus, sous Linux, ce script aurait un souci assez évident. Je précise sous Linux parce qu'il est possible que ça ne marche pas sous OpenBSD, donc je vais pas m'avancer avant de dire "y a peut etre un souci". Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0]. Donc un utilisateur sans privilége peut faire un DoS en créant un processus, puis en le renommant en "named: [priv]" et en le faisant intercepter SIGTERM ( ou en forkant lorsqu'il reçoit le SIGTERM ) pour ne pas mourir.
        
        Sauf erreur de ma part, le script va envoyer SIGTERM sur tout les process qui matche la regexp, puis attendre 30 secondes pour conclure "ok, j'ai bien fait mon boulot" à grand coup de pgrep. Comme il n'arrive pas à tuer tout les processus, alors il va s'arreter la. Si c'est "/etc/init.d/named start", ça se lanceras pas. Si c'est /etc/init.d/named restart", ça se relanceras pas.
        
        Bien sur, un admin peut intervenir et corriger. Car c'est bien connu, ils ont en général que ça à faire.
        
        Mais sinon, à part ces soucis qui dérange personne à part moi ( vu que comme tu dit, personne n'a cru bon de corriger ça depuis 2 ans ), c'est pas mal, c'est en effet bien plus clair que la majorité des scripts d'init que j'ai pu lire.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par anaseto le 24 mars 2014 à 09:26. Évalué à 1.
        
        Merci pour les explications, c'était instructif.
        
        Donc sous Linux, on peut changer le nom d'un process en modifiant argv[0].
        
        J'ai testé sur ma machine virtuelle, et on peut changer le nom visiblement, mais ps m'affiche le nouveau nom suivi du nom originel entre parenthèses alors que sous Linux je vois juste le nouveau nom… bref, je sais pas ce que ça veut dire.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 16:59. Évalué à -1.
        
        Si jamais tu utilises un truc genre containers, ou chroot, et que les processus sont visibles depuis l'extérieur, le processus à l'intérieur va se faire tuer aussi
        
        Et si tu n'utilises pas tout ça ? Tu es obligé de te palucher un script de la mort quand même ?
        
        un utilisateur sans privilége peut faire un DoS(…) Car c'est bien connu, ils ont en général que ça à faire.
        
        C'est vrai qu'un bon admin n'intervient jamais après une intrusion, il préfère laisser faire parce qu'il n'a pas que ça a faire :)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 25 mars 2014 à 13:07. Évalué à 3. Dernière modification le 25 mars 2014 à 13:09.
        
        Et si tu n'utilises pas tout ça ? Tu es obligé de te palucher
        un script de la mort quand même ?
        
        Non, tu peux utiliser mutualiser ça dans une lib, et par exemple, utiliser autre chose que le nom pour suivre les processus.
        
        Tu peux faire ça par pid, mais ça, ça foire quand le process forke 2/3 fois. Et il y a des races conditions si tu écrit le fichier, etc.
        
        Tu peux faire comme upstart, et utiliser ptrace pour suivre les forks. C'est moche et ça a son lot de problème, mais c'est "portable".
        
        Tu peux utiliser les cgroups sous linux, comme systemd. Mais c'est trop bas niveau pour bash, y a pas d'helper pour l'utiliser.
        
        Et tu peux aussi t'en foutre et te dire "ça me concerne pas, donc ça concerne personne". Une attitude valable aprés tout.
        
        C'est vrai qu'un bon admin n'intervient jamais après une
        intrusion, il préfère laisser faire parce qu'il n'a pas que ça
        a faire :)
        
        Je parle pas d'une intrusion, mais par exemple d'un serveur partagé avec plusieurs utilisateurs. Ça se fait encore assez souvent en fait. Moi, si j'étais admin de FAC ( pour donner un exemple réaliste ), je pense que ça me ferait chier si ma gateway openbsd qui fait aussi dns ne relance pas bind parce qu'un étudiant a cru bon d'appliquer les conneries qu'il lit sur Linuxfr ( si ça marche bien sur, j'ai extrapolé sur la base du fonctionnement sur Linux, mais visiblement, c'est différent sur openbsd, donc à prendre avec des pincettes tant que quelqu'un n'a pas vérifié en détail ).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 15:37. Évalué à -2.
        
        Et tu peux aussi t'en foutre et te dire "ça me concerne pas, donc ça concerne personne"
        
        Que la possibilité existe c'est une bonne chose, vu qu'elle semble répondre a un besoin, mais qu'elle devienne incontournable, je trouve ça un peu con.
        
        Moi, si j'étais admin de FAC (…) ma gateway openbsd qui fait aussi dns ne relance pas bind parce qu'un étudiant a cru bon d'appliquer les conneries qu'il lit sur Linuxfr
        
        Si tu étais admin de fac, j'espère surtout que tu te débrouillerai pour que les postes des étudiants n'hébergent pas de service sensible.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 24 mars 2014 à 01:11. Évalué à 7.
        
        qui doit être plus court et lisible que l'unit de systemd
        
        Euh?
        
        . /etc/rc.d/rc.subr
        
        Uh?
        
        pexp="named: [priv]"
        
        Uh??
        
        rc_cmd $1
        
        Uh???
        
        Dans l’unité systemd, on comprend clairement à quoi sert chaque ligne. Là, visiblement non.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par anaseto le 24 mars 2014 à 09:32. Évalué à -1.
        
        Oui, enfin, dans les deux cas, si tu veux vraiment savoir, il faut lire la doc, histoire de savoir exactement ce que tu fais. Dans ce cas, ils ont une courte page man avec une liste des fonctions utilisables du script commun rc.subr et leur utilisation.
        
        Au passage par contre, je m'étonne qu'ils disent qu'ils utilisent SIGKILL pour rc_stop alors que, comme Misc, j'ai l'impression que c'est un SIGTERM.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 24 mars 2014 à 10:14. Évalué à 4. Dernière modification le 24 mars 2014 à 10:17.
        
        Oui, enfin, dans les deux cas, si tu veux vraiment savoir, il faut lire la doc, histoire de savoir exactement ce que tu fais.
        
        Je vois pas, vraiment. On peut difficilement faire plus limpide que l'exemple cité.
        
        [Unit] Description=BIND Domain Name Server Documentation=man:named(8) # démarrer après l'initialisation du réseau After=network.target # on sait tout de suite quand est exécutée chaque commande [Service] ExecStart=/usr/sbin/named -f -u bind ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop # Unité démarrée pour la cible «multi-user», donc lors d'un démarrage normal. [Install] WantedBy=multi-user.target
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 24 mars 2014 à 17:04. Évalué à 0.
        
        Perso, je ne comprend pas ce que font les 2eme, 3eme et dernière lignes.
        Ensuite, ce fichier je ne sais pas où le mettre.
        
        Donc non ce n'est pas limpide : il faut se taper une doc supplémentaire \o/
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 17:30. Évalué à 7.
        
        Pour l'autre aussi.
        En fait la question est :
        Prends deux apprentis admins systèmes qui ne connaissent rien en SysV et systemd.
        Demande leur de créer chacun de leur côté un service X tout seul avec la doc.
        
        Je ne suis pas sûr que celui qui fera du SysV finira le premier… Et en plus en traitant la chose correctement (dépendance entre services, etc.).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 19:04. Évalué à 0.
        
        L'apprenti systemv:
        - Cherche sur le net (c'est pas faute de tenter de lui convaincre de lire la doc …)
        - Tombe sur un mec qui lui apprend l'existence de rc.local. Ou de faire un script en partant d'un autre ou d'un skeleton, en remplacant NAME par le nom du programme.
        - Le stagiaire choisi d'éditer rc.local, ça à l'air plus simple. Suffit juste d'entrer les commandes qu'il fait en console pour lancer le programme.
        - Fini. C'est super moche, mais osef, si ça marche au premier boot, ça marche sur les suivants.
        
        L'apprenti Systemd:
        - Cherche sur le net plutôt que de lire la doc. De toute façon, la doc de systemd est en anglais, il y comprend rien. Malgré qu'on arrête pas de lui répéter que l'anglais dans l'informatique c'est obligatoire.
        - Tombe sur un tutoriel écrit par un neuneu comme lui, et va recopier l'unit sans trop réfléchir, sur un service qui n'a peut-être pas les mêmes dépendances et qui nécessite pas la même chose pour démarrer.
        - Si ça marche au premier boot, tant mieux. Pas dit que ça marche aux suivants. Si ça marche pas au premier boot, j'espère qu'il aura le réflexe de lire les logs, plutôt que d'utiliser la solution windowsienne qui consiste à essayer plein de trucs jusqu'à que ça marche.
        
        Dans tout les cas, il fera de la merde. Faire un unit ou un script shell, c'est à laisser à des professionnels.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 24 mars 2014 à 19:40. Évalué à 5.
        
        Déjà, l'aprenti systemd, il peut faire un rc.local, ça marche aussi (en fonction des distribs et de l'admin système, mais je doute que les distribs qu'on retrouve en production vont l'abandonner tout de suite), et il y a beaucoup de chance que ce soit la solution qu'il trouve vu l'historique.
        
        Ensuite, s'il écrit son unit, dans le cas où il y a des vrais dépendance (ce qui n'arrive pas tout le temps), j'ai un gros doute qu'il ne se rende pas compte qu'il doit y avoir d'autre service démarrés pour que ce truc fonctionne.
        
        On se retrouve donc dans le cas où un type écrit le démarrage d'un service (ce qui n'est pas très courant, c'est souvent fourni avec le logiciel, encore plus avec systemd), qui a des dépendances fortes (genre qui refuse de démarrer si ses dépendances ne sont pas là, souvent, il est juste inaccessible tant que service n'est pas démarré). Mais le type est complètement manche pour se rendre compte de cette dépendance et pas de bol, tombe sur la mauvaise doc. J'ai quand même l'impression qu'on ne va pas voir arriver ça si souvent.
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 24 mars 2014 à 21:29. Évalué à 7.
        
        Tu peux rajouter qu'avec une unité, on a un feedback si la syntaxe est invalide. Alors qu'il y a pas vraiment de vérificateur de base avec bash (que je sache).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 24 mars 2014 à 17:57. Évalué à 3.
        
        Perso, je ne comprend pas ce que font les 2eme, 3eme et dernière lignes.
        
        2e et 3e ligne c'est pour systemctl ça me parait évident.
        
        La dernière ligne, c'est pour indiquer l'équivalent du runlevel (mais bien plus puissant) côté systemd. Sauf qu'au lieu d'avoir des numéros imbitables, on a directement le nom. Léger avantage systemd.
        
        Ensuite, ce fichier je ne sais pas où le mettre.
        
        Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.
        
        Donc non ce n'est pas limpide : il faut se taper une doc supplémentaire \o/
        
        En connaissant simplement le principe des cibles (target) de systemd, on devine facilement ce que fait l'unité. Par contre le script est cryptique, même si on sait on peut oublier, c'est plus dur avec des champs bien nommés.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 23:06. Évalué à 1.
        
        2e et 3e ligne c'est pour systemctl ça me parait évident.
        
        Ce n’était pas évident pour moi non plus. Mais je suis un peu neuneu.
        
        a dernière ligne, c'est pour indiquer l'équivalent du runlevel (mais bien plus puissant) côté systemd. Sauf qu'au lieu d'avoir des numéros imbitables, on a directement le nom. Léger avantage systemd.
        
        Pour l’avantage, certaines distribution utilise aussi des « runlevels » nommé, oups, ce n’est pas une exclusivité.
        
        Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.
        
        Ben si, /etc/init.d/
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 24 mars 2014 à 23:50. Évalué à 5.
        
        Ce n’était pas évident pour moi non plus. Mais je suis un peu neuneu.
        
        Bah vu que systemd ne comprends ni les descriptions en anglais ni les pages de man, ces métadonnées ne pouvait être destinées qu’à un outil client…
        
        Pour l’avantage, certaines distribution utilise aussi des « runlevels » nommé, oups, ce n’est pas une exclusivité.
        
        Je ne savais pas. Source? Dans tous les cas, dépend des distributions (comme la définition des runlevels d’ailleurs), tandis que les cibles de systemd sont bien flexibles et bien définies.
        
        Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.
        
        Ben si, /etc/init.d/
        
        Bah sous Arch Linux c’était dans /etc/rc.d/ par exemple.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 25 mars 2014 à 09:55. Évalué à 2.
        
        Bah vu que systemd ne comprends ni les descriptions en anglais ni les pages de man, ces métadonnées ne pouvait être destinées qu’à un outil client…
        
        C'est amusant, il y a deux cas :
        * Les scripts c'est pourri par ce que quand on connaît pas ça semble compliqué.
        * Systemd c'est simple.
        
        Sauf que moi, je connais et comprends les scripts. Le fait que les métadonnées ne pouvait être destinées qu'à un outil client te semble évident parce que tu connais l'outil. Admettre que tout n'est pas limpide pour quelqu'un qui ne connais pas l'outil est trop dur pour votre égo ?
        
        gentoo utilise des « runlevel » nommé par exemple.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 10:04. Évalué à 6.
        
        Les scripts c'est pourri par ce que quand on connaît pas ça semble compliqué.
        
        Pour deux personnes qui ne connaissent ni systemd, ni les scripts, systemd sera bien plus simple.
        
        gentoo utilise des « runlevel » nommé par exemple.
        
        Et alors ? le soucis c'est qu’il n'y a aucune convention de nom, pas toutes les distributions le font et en plus les niveaux d'exécution sont loin d'être les seuls problèmes notamment de compatibilité. Faute de s'accorder sur une norme commune, systemd aura le mérite d'agir comme standard de facto de manière efficace.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Toufou (site web personnel) le 25 mars 2014 à 15:49. Évalué à -6.
        
        systemctl ça me parait évident.
        
        désolé mais systemctl ça ne me parle pas :
        
        Sauf qu'au lieu d'avoir des numéros imbitables
        
        Quels numéros imbittables ? .S .M ? ou rc.numrunlevel ?
        C'est vrai que le concept du runlevel est ardu a saisir : la page Wikipedia d'ailleurs est d'une longueur monstrueuse.
        
        arathorn:~# systemctl
        -su: systemctl: command not found
        arathorn:~# man systemctl
        No manual entry for systemctl
        
        Ton script non plus
        
        mmh au hasard et suivant les cas : dans /etc/rc.d ou dans /etc/init.d. Le truc bon c'est que c'est valable pour quasiment tous les unix, pas juste linux.
        
        En connaissant simplement le principe des cibles (target) de systemd, on devine facilement ce que fait l'unité.
        
        Donc en ayant mangé la doc.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 15:57. Évalué à 7.
        
        C'est vrai que le concept du runlevel est ardu a saisir : la page Wikipedia d'ailleurs est d'une longueur monstrueuse.
        
        Si tu avais lu la page, tu aurais vu qu'un numéro d'exécution chez l'un peut avoir une autre signification chez un autre. En gros, il faut adapter à chaque distribution le numéro selon que l'on souhaite. Il faut trouver cette information, la vérifier et tester. Ici comme c'est nommé, tu sais que quelque soit la distribution ça s'exécutera au niveau d'exécution que tu voulais. C'est plus simple non ?
        
        arathorn:~# man systemctl
        No manual entry for systemctl
        
        Si tu n'as pas systemd, c'est normal que tu n'as pas d'entrée de manuel pour cet utilitaire.
        Tu n'essayerais pas un peu de te foutre de notre gueule ?
        
        mmh au hasard et suivant les cas : dans /etc/rc.d ou dans /etc/init.d. Le truc bon c'est que c'est valable pour quasiment tous les unix, pas juste linux.
        
        Rien que pour le dossier de base, comme tu le montres, le nom du dossier peut changer.
        Quelle portabilité incroyable !
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 16:56. Évalué à 9. Dernière modification le 25 mars 2014 à 16:57.
        
        C'est vrai que le concept du runlevel est ardu a saisir : la page Wikipedia d'ailleurs est d'une longueur monstrueuse.
        
        Elle n'est pas longue, mais elle n'est pas claire pour autant :
        
        2 à 5 : dépend du système d'exploitation
        
        Ça m'aide vachement. Je trouve où la doc ?
        
        mmh au hasard et suivant les cas : dans /etc/rc.d ou dans /etc/init.d. Le truc bon c'est que c'est valable pour quasiment tous les unix, pas juste linux.
        
        Bah non. Sous HPUX c'est dans /sbin/rc.d par exemple.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 25 mars 2014 à 19:19. Évalué à 1. Dernière modification le 25 mars 2014 à 19:19.
        
        arathorn:~# man systemctl
        No manual entry for systemctl
        
        Euh…
        
        max@max-laptop% man systemctl
        
        SYSTEMCTL(1) systemctl SYSTEMCTL(1)
        
        NAME
        systemctl - Control the systemd system and service manager
        
        SYNOPSIS
        systemctl [OPTIONS…] COMMAND [NAME…]
        
        DESCRIPTION
        systemctl may be used to introspect and control the state of the
        systemd(1) system and service manager.
        
        OPTIONS
        The following options are understood:
        …
        
        Donc bon, avant d'argumenter, sachez installer des paquets proprement… -_-
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 15:42. Évalué à 8.
        
        Faut quand même être d'une sacré mauvaise foi pour dire qu'une unité systemd est incompréhensible, surtout comparée à un script…
        
        Dans la manpage systemd-unit tu as les explications pour chaque entrée.
        
        Pour sysv elle est où la doc ? Qu'on ne me parle pas de rechercher sur Google, c'est pas ce que j'appelle de la doc. Un tutorial non plus d'ailleurs.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par lasher le 25 mars 2014 à 17:02. Évalué à -1.
        
        Ben écoute, perso j'ai rien contre systemd, mais si j'ai compris l'intention derrière le truc (tout comme je comprends celle derrière la plupart des scripts d'init), effectivement, j'aurais ete bien incapable de correctement décrire les étapes de cette unité.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 17:42. Évalué à 6.
        
        Sincèrement, c'est de l'anlais simple, je ne vois pas ce qu'il y a à expliciter là-dedans sans paraît hautain, surtout si tu as déjà eu affaire à des scripts d'init.
        
        Description : la description
        Documentation : la documentation
        After : après quoi le service est démarré
        
        ExecStart : la commande pour démarrer le démon
        ExecReload : la commande pour que le démon relise sa config
        ExecStop : la commande pour arrêter le démon
        
        Y'a guère que la partie WantedBy qui est spécifique à Systemd. Mais quand tu sais ce qu'est un runlevel, tu comprends très vite qu'une target est la même chose, et que le WantedBy est juste la runlevel où le service est lancé.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par lasher le 25 mars 2014 à 18:05. Évalué à 1.
        
        C'est pas une histoire d'Anglais. Par exemple, le champ "Documentation" est juste la a titre informatif? Ou bien est-il possible d'effectuer une action en utilisant un truc du genre "systemd-doc " et ça va appeler la commande man kivabien ?
        
        C'est pour ça que je dis que je comprends l'intention (et oui c'est relativement clair), mais qu'expliquer en détails ce que ça fait, c'est une autre chose.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par anaseto le 25 mars 2014 à 18:43. Évalué à 1.
        
        Pour sysv elle est où la doc ?
        
        Je vois pas pourquoi ce ne serait pas possible d'avoir de la doc complète pour sysv. En tous cas, justement, plus haut j'ai donné un lien vers une page man qui documente le système d'openbsd. C'est tout ce qu'il y a de plus simple pour qui connaît le shell (mais pas forcément le système d'init).
        
        Faut quand même être d'une sacré mauvaise foi pour dire qu'une unité systemd est incompréhensible, surtout comparée à un script…
        
        C'est pas surprenant, la lisibilité et ce genre de choses font rarement l'unanimité, et pourtant deviennent le sujet central du débat, bien qu'il y ait des raisons techniques pour préférer systemd ou les scripts (dont le style varie d'ailleurs d'un système à un autre). Ce n'est pas forcément grave. Chacun met dans la balance ce qu'il veut suivant ses intérêts, besoins, goûts, etc…
        
        Peut-être que les différents systèmes continueront à exister longtemps pour répondre à cette diversité d'opinions, et que chacun trouvera son bonheur malgré tout ce qu'on en dit. Et ce ne serait pas une catastrophe, au contraire : après tout, c'est cette impression de diversité et liberté dans les choix qui m'a fait aimé le monde du libre, et je vois pas l'intérêt d'essayer de prouver que tel choix est indéniablement supérieur à un autre quand visiblement les avis sont partagés, et que des personnes évaluant indépendamment les différentes options arrivent à des conclusions différentes à propos de ce qui leur convient le mieux.
        
        Si au contraire, cette diversité disparaît, ce n'est pas grave non plus : ça signifierait qu'en effet pas suffisamment de monde ne considère que le choix vaille suffisamment la peine pour qu'un autre système continue à vivre : ça arrive bien avec d'autres choses que le système d'init, c'est juste la loi de la nature.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 20:51. Évalué à 1.
        
        quand visiblement les avis sont partagés
        
        Note qu'ils sont partagés que si on regarde l'ensemble personne concernées par les merdes et personnes non concernées qui veulent juste râler pour le plaisir.
        Si tu te "limites" aux personnes concernées, les avis sont la quasi-unanimité
        Et à mon avis, les personnes concernées (et plein d'autres) se foutent complet des personnes non concernées à part essayer de limiter leur capacité de nuisance inutile.
        
        Si au contraire, cette diversité disparaît, ce n'est pas grave non plus : ça signifierait qu'en effet pas suffisamment de monde ne considère que le choix vaille suffisamment la peine pour qu'un autre système continue à vivre : ça arrive bien avec d'autres choses que le système d'init, c'est juste la loi de la nature.
        
        Tout à fait. Et on y va à grand pas vu que les quasiment les seuls à râler ne sont pas ceux qui bossent.
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par xcomcmdr le 22 mars 2014 à 22:55. Évalué à 8. Dernière modification le 22 mars 2014 à 22:55.
      
      En terme logiciel on appelle ça du bloat et du code non-maintenable.
      
      Et t'es allé voir le code de systemd pour voir s'il était bloated ?
      Je parie que non.
      
      systemd, c'est un cœur simple, et une soixantaine d'utilitaires.
      Et si on regarde le code source, et qu'on regarde les fichiers sources les plus gros, aucune fonction ne dépasse les 40 lignes.
      Et les nouvelles versions de systemd sortent à un rythme d'enfer.
      
      Non, vraiment, le code a l'air bon et bien compartimenté.
      
      Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote.
      
      La documentation pour écrire un unit-file systemd est on ne peut plus simple. C'est même plus simple que d'écrire des scripts (ce qui était le but), et ça fonctionne sur des distributions différentes.
      
      Il pouvait aussi lire le code du processus PID 1 qui n'est pas très gros.
      
      Ouais, et dans la réalité je doute que c'était fait si souvent, ça ne sert à rien.
      
      Certes ça ne lui servait pas à grand chose parce que ça faisait exactement ce qui était écrit dans la doc et ce qui pourrai être dans l'imagination du développeur si c'était lui qui devait le programmer.
      
      systemd est bien mieux documenté que ne l'était SysV.
      Par contre, on a pas à se taper des scripts à la con qui répètent de la logique entre eux (bloat).
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 22 mars 2014 à 23:45. Évalué à -4.
        
        Et t'es allé voir le code de systemd pour voir s'il était bloated ?
        Je parie que non.
        
        Non, j'ai déjà lu en long en large et en travers celui d'Avahi, et ça me suffit pour ma santé mentale. De ce que tu m'en décris, celui de systemd est similaire. Comme c'est surprenant.
        
        Le jour ou je serait obligé d'utiliser systemd sur un système embarqué que je doit maîtriser entièrement, t'inquiète pas que je te le lirait le code source.
        
        systemd, c'est un cœur simple, et une soixantaine d'utilitaires.
        
        Comme Avahi ? Un bon gros cœur qui fait tout avec une API imbitable et des clients qui l'utilisent ?
        
        Et si on regarde le code source, et qu'on regarde les fichiers sources les plus gros, aucune fonction ne dépasse les 40 lignes.
        
        Facile de ne pas dépasser les 40 lignes quand on respecte pas les 80 caractères.
        
        Non, vraiment, le code a l'air bon et bien compartimenté.
        
        Avahi aussi est à peu près bien compartimenté aussi. Tellement bien compartimenté que chaque compartiment réimplémente sa liste chaînée et son tableau dynamique. Non mais sérieusement quel code de «¶ŋøß¢ !
        
        La documentation pour écrire un unit-file systemd est on ne peut plus simple. C'est même plus simple que d'écrire des scripts (ce qui était le but), et ça fonctionne sur des distributions différentes.
        
        Moi je ne te parle pas d'écrire, je te parle de lire et de savoir exactement ce qui se passe lorsque ton système boote et quel impact peut avoir chaque dysfonctionnement. Il se passe quoi avec systemd si /etc/fstab est foutu ?
        
        systemd est bien mieux documenté que ne l'était SysV.
        
        le démon sysvinit est assez bien documenté moi je trouve. Les scripts shells le sont moins, mais quand le code source est lisible et bien plus petit que la documentation, je trouve pas ça franchement utile de documenter.
        
        Par contre, on a pas à se taper des scripts à la con qui répètent de la logique entre eux (bloat).
        
        Ce bloat peut se résoudre sans l'aide de systemd. Certaines distributions l'on déjà fait. Mais si on regarde bien, la plupart des scripts d'init font plus que lancer et tuer des démons.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 23 mars 2014 à 02:50. Évalué à 9.
        
        Tu te rends compte que tu juges la qualité du code de systemd en regardant celui d'Avahi?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 23 mars 2014 à 10:48. Évalué à -3.
        
        Désolé, mais j'ai pas réussi à trouver de différences fondamentales entre le code d'Avahi et le peu de code de systemd que j'ai lu.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par modr123 le 23 mars 2014 à 21:48. Évalué à 0.
        
        http://fr.wikipedia.org/wiki/Avahi_%28logiciel%29
        
        La bibliothèque Avahi a été développée par Lennart Poettering et Trent Lloyd. Elle est le résultat d'une fusion réalisée en 2005 entre l'implémentation des protocoles mDNS/DNS-SD de L. Poettering appelée "FlexMDNS", et du code de T. Lloyd appelé "Avahi". Alors que la majorité du code actuel provient du premier
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 23 mars 2014 à 21:55. Évalué à 4.
        
        Tu sais que tu peux t’améliorer au fil du temps? Tu sais que tu peux avoir fait un peu de la merde une fois et faire un truc pas mal voire bien ensuite? Tu sais que Lennart Poettering n’est pas le seul à bosser sur systemd, mais qu’il y a des dizaines et des dizaines de développeurs qui bossent dessus?
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par liberforce (site web personnel) le 24 mars 2014 à 13:13. Évalué à 8. Dernière modification le 24 mars 2014 à 13:13.
        
        Il y a aussi le fait que Lennart a publiquement dit que le code d'Avahi avait été un enfer à écrire et maintenir à cause des problématiques de portabilités sur plusieurs OS. C'est aussi pour cela qu'il n'accepte pas de patchs pour d'autres systèmes sur systemd, pour éviter de retomber dans un enfer de #ifdef et de code difficilement testable. Je ne doute pas que le code d'Avahi soit complexe, la question est plutôt de savoir si celait pouvait l'être moins. Et systemd n'ayant pas ces contraintes, le code devrait être plus lisible.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 13:45. Évalué à 2.
        
        Je ne doute pas que le code d'Avahi soit complexe, la question est plutôt de savoir si celait pouvait l'être moins.
        
        Le fait de réimplementer 5 fois des listes chaînées, des tableau dynamiques, de faire du gros copier-coller, d'avoir des mégafonctions ou de faire des API D-Bus imbitables (wrappées dans des bibliothèques que ceux qui viennent de l'API de l'implémentation d'Apple ne comprennent pas pourquoi elles sont aussi compliquées à utiliser), n'a absolument rien à voir avec les problèmes de portabilités entre les OS.
        
        Sérieusement quoi, c'est un programme réseau qui envoie et reçoit des datagrammes multicast. l'API des sockets est définie par des RFC respectées sur quasiment tout les systèmes. Et, comme d'habitude dans un programme réseau, la partie qui les utilisent ne représente qu'une toute petite partie du code. Et il existe plusieurs bibliothèques portables qui permettent d'abstraire tout ça.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Maclag le 24 mars 2014 à 14:09. Évalué à 6.
        
        Du coup on devrait peut-être lui demander s'il veut le réécrire?
        systemd-mdns!
        
        ----------> [ ]
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 12:48. Évalué à 10.
        
        Non, vraiment, le code a l'air bon et bien compartimenté.
        
        Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs. Par exemple, ça utilise largement des fonctionnalités de gcc pour nettoyer les variables automatiquement ( via l'attribut cleanup ) pour éviter les fuites de mémoires. Il y a un coding style assez détaillé et qui est suivi. Il y a une suite de tests, assez de commentaires pour piger ce qui se passe dans les cas compliqués. Et y a pas des tonnes de #ifdef en fonction de la plateforme.
        
        Pour avoir lu en détail celui de upstart et de systemd ( mon but était de rajouter le support du protocole d'activation à upstart ), celui de systemd m'a paru bien plus facile à comprendre et à modifier.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 11:00. Évalué à 3.
        
        Par exemple, ça utilise largement des fonctionnalités de gcc
        
        Je ne suis pas certain que ça prouve que le code est génial…
        
        Si tu veux laisser le langage gérer ta RAM utilise java ;
        
        Utiliser des extension d'un compilateur empêche d'utiliser les autres… pas très libre dans l'esprit
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 12:34. Évalué à 1.
        
        Tu as déjà essayé de compiler Linux avec autre chose que GCC?
        Rappel : systemd est fortement lié à Linux pour le moment…
        (mais rien n'empèche dans le futur d'être moins lié à Linux ou GCC).
        
        c'est fou comme les arguments sont à fond recherchés contre systemd sans qu'on les voit sur d'autres projets (genre le noyau, mais on peut trouver une tonne de projets GNU, ces libristes dans l'esprit, qui ne compilent pas ailleurs qu'avec GCC), hop comme ça des trucs dont on était indifférent avant deviennent "pas très libre dans l'esprit"… deux poids, deux mesures.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 12:52. Évalué à 3.
        
        Tu as déjà essayé de compiler Linux avec autre chose que GCC?
        
        Des gens y travaillent, et ça va finir par compiler avec LLVM/Clang. Les extensions de GCC comme les VLAIS sont en train d'être remplacées par du C99 valide.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 12:57. Évalué à -1. Dernière modification le 24 mars 2014 à 13:01.
        
        Avec le même travail systemd compilera avec LLVM/CLang. Donc aucun problème avec systemd, tu aurais pu lui répondre à Anthony directement plutôt qu'à moi, avec un "suffit que des gens y travaillent (soit modif de systemd, soit support LLVM de la spécificité x)".
        après, LLVM n'est qu'un compilo en plus, l'idée dans le reproche c'est tous les compilos standards pour moi (sinon on remplace juste un "1" par un "2", bof)
        Avec des excuses pour Linux qui marchent pour systemd, on tourne en rond.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 13:27. Évalué à 3.
        
        Toi pas comprendre. Linux compilera avec LLVM/Clang parce que Linux s'approchera du standard C99, pas l'inverse. Ça fait depuis longtemps que Linux n'accepte plus aussi facilement du nouveau code qui dépend d'extensions de GCC autres que celles qui sont wrappées dans des macros spécifiques au noyau qui permettent leur désactivation en un seul endroit.
        
        Enfin bref, un projet de 1991 qui donne des leçons de portabilité à un projet qui date de 2010, ça fait toujours plaisir.
        
        Avec le même travail systemd compilera avec LLVM/CLang.
        
        Est ce que les mainteneurs de Systemd en ont simplement envie ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 13:40. Évalué à 2. Dernière modification le 24 mars 2014 à 13:42.
        
        Toi pas comprendre.
        
        Ou alors, je comprend trop, question de point de vue.
        
        Enfin bref, un projet de 1991 qui donne des leçons de portabilité à un projet qui date de 2010, ça fait toujours plaisir.
        
        Vu autrement, tu demandes à un projet qui a 4 ans et qui va vite entre autre grâce à l'utilisation de choses faites ailleurs d'être aussi mature qu'un projet qui a mis 20 ans avant de se dire que le code standard ça serait bien.
        Tu as 16 ans d'avance (ou pendant 16 ans tu as "oublié" de critiquer Linux à ce sujet). Encore une attaque qui sort du chapeau contre ce projet et seulement celui-ci. Faudra un jour se poser la question du pourquoi tant de haine pour ce projet.
        
        Est ce que les mainteneurs de Systemd en ont simplement envie ?
        
        On s'en fout pour le moment, mais qui sait, un jour peut-être, mais pour le moment ce n'est pas la priorité. Après, à toi de convaincre de l'utilité pour le besoin aujourd'hui de systemd, sans pourrir les time to market.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 14:01. Évalué à 3.
        
        Vu autrement, tu demandes à un projet qui a 4 ans et qui va vite entre autre grâce à l'utilisation de choses faites ailleurs d'être aussi mature qu'un projet qui a mis 20 ans avant de se dire que le code standard ça serait bien.
        
        Oui: un code moderne n'a pas à faire les mêmes erreurs qu'un code ancien.
        
        Tu as 16 ans d'avance (ou pendant 16 ans tu as "oublié" de critiquer Linux à ce sujet).
        
        Personnellement, je n'ai pas attaqué Linux il y a 16 ans, mais d'autres s'en sont chargés à ma place.
        
        Encore une attaque qui sort du chapeau contre ce projet et seulement celui-ci.
        
        Oui, parce qu'il y a bien que Lennart pour dire que la portabilité ça sert à rien, que la philosophie Unix est un échec, et d'autres types de conneries.
        
        Après, à toi de convaincre de l'utilité pour le besoin aujourd'hui de systemd, sans pourrir les time to market.
        
        Ah, ça y est, on en est là: Il faut absolument du time to market, y compris en pondant du code dégueulasse architécturé comme les téléphonistes le faisait même pas il y a 20 ans ?
        
        Dans ce cas la, c'est plus simple alors, il suffit de prendre toutes les critiques que l'on peut faire à du code écrit par des entreprises plongées dans ce genre de foutaises et l'appliquer à systemd, ça sera plus simple.
        
        Comme j'aurai pas besoin d'expliquer pourquoi un hippie comme Linus Torvalds viens dire que plus on porte vers d'autres architectures, plus on trouve de bugs qui affectaient les autres.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 24 mars 2014 à 14:09. Évalué à 0. Dernière modification le 24 mars 2014 à 14:13.
        
        Comme j'aurai pas besoin d'expliquer pourquoi un hippie comme Linus Torvalds viens dire que plus on porte vers d'autres architectures, plus on trouve de bugs qui affectaient les autres.
        
        On parle bien du même qui pendant 20 ans faisait du code compilable que sous GCC, alors qu'on sait bien que plus on compile sur des compilateurs différents, plus on trouve de bugs qui affectaient les autres?
        D'ailleurs, systemd va tourner sur toutes les archis de Linux, donc je te laisse faire la conclusion de Torvalds… A mourrir de rire.
        
        Passons donc…
        
        Ah, ça y est, on en est là: Il faut absolument du time to market,
        
        Désolé d'avoir utilisé un gros mot. OK, on comprend donc qu'en fait tu t'en fout que le code soit utilisé, tu préfère un code prope que personne n'utilise à un code moins joli mais utile. On ne va clairement pas se comprendre, où plutôt je vais plutôt encore avoir un argument contre les gens contre systemd : leur vie hors de la vraie vie. Plus on creuse, plus on se marre sur les anti-systemd.
        
        y compris en pondant du code dégueulasse architécturé
        
        Seul toi et quelques râleurs trouvent le code dégueulasse, les autres le prennent et l'utilisent. Si tu penses savoir faire mieux, n'hésite pas à le prouver à la place de parler. Je sais, c'est plus difficile de prouver que sa façon de voir est meilleure (même à long terme).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Maclag le 24 mars 2014 à 14:11. Évalué à 6.
        
        Comme j'aurai pas besoin d'expliquer pourquoi un hippie comme Linus Torvalds viens dire que plus on porte vers d'autres architectures, plus on trouve de bugs qui affectaient les autres.
        
        Il y a portage et portage.
        Linus ne propose pas de porter le noyau Linux sous les espaces utilisateurs des BSD.
        systemd sera bien porté sur toutes sortes d'archi matérielles, même si ce n'est pas forcément par Lennart lui-même!
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 14:13. Évalué à 10.
        
        Oui, parce qu'il y a bien que Lennart pour dire que la portabilité ça sert à rien, que la philosophie Unix est un échec, et d'autres types de conneries.
        
        Il a dit surtout que la portabilité ne sert à rien si cela implique que tout logiciel ne soit compatible qu'au dénominateur commun et dans le cadre d'un système de démarrage cela fait sens.
        
        En écoutant certains, il faudrait que tous les programmes soient compatibles avec toutes les plateformes. Mis tu veux atteindre ce but comment avec un code un minimum propre tout en gardant des spécificités à chaque plateforme ? Le noyau Linux propose une API avec des fonctionnalités innovantes, hors norme POSIX (car cette norme n'évolue plus), à quoi ça sert de faire de telles fonctionnalités si aucun programme n'en profite en raison de la sacro sainte portabilité ? À quoi ça sert pour un programme qui est par essence lié au noyau d'être portable ? Déjà que les scripts SysV ne sont pas portables d'une distribution à une autre, au moins systemd aura malgré son lien au noyau Linux amélioré la portabilité entre elles.
        
        La portabilité c'est bien, oui, il faut travailler en ce sens. Mais pas à n'importe quel prix, que ce soit en performance, en qualité du code ou en fonctionnalités proposées. La portabilité impose des contraintes que tu ne peux pas toujours accepter, c'est comme ça. Est-ce grave ? Non, même si c'est souhaitable de rendre le code le plus portable possible.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 24 mars 2014 à 15:15. Évalué à 9.
        
        La portabilité c'est bien, oui, il faut travailler en ce sens. Mais pas à n'importe quel prix, que ce soit en performance, en qualité du code ou en fonctionnalités proposées. La portabilité impose des contraintes que tu ne peux pas toujours accepter, c'est comme ça.
        
        C'est d'ailleurs pour ça que le noyau abandonne des architectures, comme les 386.
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 11:18. Évalué à -1.
        
        dans le cadre d'un système de démarrage cela fait sens.
        
        Si systemd n'était qu'un système de démarrage, ça aurai un sens. Sauf que c'est pas le cas.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 24 mars 2014 à 18:42. Évalué à 7.
        
        Ah, ça y est, on en est là: Il faut absolument du time to market, y compris en pondant du code dégueulasse architécturé comme les téléphonistes le faisait même pas il y a 20 ans ?
        
        Sauf que ce code dégueulasse et architécturé n'importe comment:
        - il fonctionne
        - il est plutot fiable. En tout cas suffisement pour qu'un grand nombre de distributions aient décidé de se baser dessus pour un composant critique.
        - il ne semble pas poser de problème particulier à ses mainteneurs qui se débrouillent visiblement bien pour le faire evoluer sans tout casser.
        
        Après, qu'il ne plaise pas à un expert autoproclamé en qualité de code, c'est pas très important.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anthony Jaguenaud le 24 mars 2014 à 13:18. Évalué à 4.
        
        Tu as déjà essayé de compiler Linux avec autre chose que GCC?
        
        Non. Mon propos était juste de relever un argument fallacieux, et pas de dire que c'était mal. Je t'aide :
        
        Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs. Par exemple, ça utilise largement des fonctionnalités de gcc…
        
        Pour justifier un code /moderne et agréable/, ça utilise des spécificité du compilateur. Je trouve la justification mauvaise je ne réagissais que la dessus.
        Je comprends la phrase comme : Pour avoir un code moderne et agréable il faut faire fi des standard et utiliser les extensions de gcc.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 24 mars 2014 à 21:53. Évalué à 5.
        
        Si tu veux laisser le langage gérer ta RAM utilise java ;
        
        En l'occurrence, non, ça gère que les cas les plus triviaux. Genre fermeture du fichier quand la variable sort du scope, etc, etc.
        Enfin je pense que c'est pas dur de voir qu'il y a une des tonnes de possibilités entre "tout faire gérer" et "rien gérer du tout", donc je suis pas sur que la dichotomie soit un argument valable.
        
        Utiliser des extension d'un compilateur empêche d'utiliser les
        autres… pas très libre dans l'esprit
        
        Sauf si l'extension est compatible.
        En l'occurrence, on parle de ça :
        http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/macro.h#n47
        
        Utilisé pour ça :
        http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/path-lookup.c#n93
        
        Et la doc pour GCC est la :
        http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html
        
        Et c'est compatible avec llvm, cf ce morceau du code de llvm :
        https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/Attr.td#L482
        
        Il y a des gens qui compilent systemd avec clang, des patchs qui remontent donc c'est pas par hasard non plus.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 24 mars 2014 à 12:43. Évalué à -1.
        
        Par exemple, ça utilise largement des fonctionnalités de gcc pour nettoyer les variables automatiquement ( via l'attribut cleanup ) pour éviter les fuites de mémoires.
        
        Ça présage bien de la qualité du machin. Moi j'ai pas besoin d'extensions à GCC pour faire la même chose: Ça s'appelle C++, c'est portable et ça existe depuis 1998, avec une mise à jour bien sympathique en 2011.
        
        Mais bon, comme dirait l'autre, on peut programmer en fortran dans n'importe quel langage.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par lasher le 25 mars 2014 à 16:16. Évalué à 3.
        
        Quelle norme de Fortran ? Parce que Fortan > 77 est moderne, propose de la programmation structurée… ;)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par gnx le 24 mars 2014 à 16:24. Évalué à -2.
        
        Par exemple, ça utilise largement des fonctionnalités de gcc
        
        Donc, ça ne tourne qu'avec un noyau Linux… ça ne compile qu'avec GCC… c'est quoi la suite ? bientôt ça marchera seulement avec une distribution RedHat installée sur un Western Digital tournant sur un Core i5 avec un BIOS AMI ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 16:36. Évalué à 10.
        
        Mince, les scripts SysV de Debian ne tournaient que sous Debian (avec de la chance sur plusieurs versions de suite et ses dérivées) et pendant une longue époque avec bash. Alors je n'ose même pas imaginer le résultat sur une Red-Hat ou un OpenBSD…
        
        Tu vois que finalement ce n'est pas un véritable problème, ce n'est pas pire qu'avant.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par gnx le 24 mars 2014 à 18:20. Évalué à -3.
        
        Mince, les scripts SysV de Debian ne tournaient que sous Debian
        
        Quel rapport ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 24 mars 2014 à 18:57. Évalué à 10.
        
        Si les scripts SysV ne sont pas portables entre distribution, on peut admettre alors que systemd est plus portable que l'ancienne proposition. Donc pourquoi critiquer systemd sur ce point et pas SysV ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par claudex le 24 mars 2014 à 19:00. Évalué à 10.
        
        La portabilité. Avant systemd, c'était spécifique à chaque distribution, après systemd, beaucoup de distribution partage les même fichiers.
        
        « 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: De plus en plus complexe, le système d'init...
        
        Posté par gnx le 24 mars 2014 à 20:52. Évalué à -1.
        
        Décidément… d'une part, je ne parle pas de ça, je parle du fait d'écrire du C non standard. Mais peut-être que Poettering a déclaré que c'est bon pour la portabilité, ça aussi, et génial pour dérouler des tests avec plusieurs compilos, tant qu'on y est. C'est pas comme si ça pouvait aider à trouver des bugs.
        
        Et sinon, pour le truc que vous (deux) ramenez ici, hors propos et qui a déjà été traité 50 fois par les pro et les anti, je recolle la réponse habituelle :
        oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par GaMa (site web personnel) le 24 mars 2014 à 21:02. Évalué à 7.
        
        oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.
        
        Non :
        Les scripts SysVinit Debian sont compatibles avec les distributions SysVinit Debian et systemd Debian. Les scripts SysVinit RedHat sont compatibles avec les distributions SysVinit RedHat et systemd RedHat. Et les unités systemd sont compatibles avec les distributions systemd Debian et systemd RedHat.
        
        (Tu vois pas comme une petite différence ?)
        
        Matthieu Gautier|irc:starmad
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 24 mars 2014 à 21:15. Évalué à 3.
        
        oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.
        
        Non, c'est plutôt :
        1.Les scripts d'une distribution X ne sont pas forcément compatibles avec la distribution Y, voire avec la distribution X.VersionZ. Les unit files systemd sont écrits une seule fois par le projet upstream, et utilisés à l'identique par toutes les distributions compatibles (celles qui utilisent systemd, ou qui implémentent un équivalent. Après tout, ce n'est pas comme si les unit files n'étaient pas documentés)
        
        2.Les scripts répètent de la logique entre eux, et n'offrent pas tous les mêmes compatibilités. l'un ne fonctionne pas avec SELinux, l'autre fonctionne avec AppArmor mais pas SELinux, etc… Tout ça est pris en charge par systemd.
        
        3.Ah oui, on a arrêté les runlevels idiots avec des définitions différentes selon la distro pour utiliser à la place quelque chose de plus puissant et pour lesquels il n'y a qu'une seule définition : les targets.
        
        4.Grâce aux control groups, quand on arrête un service, on est sûr et certain qu'il va s'arrêter. ;-)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Arthur Accroc le 26 mars 2014 à 01:37. Évalué à 2.
        
        4.Grâce aux control groups, quand on arrête un service, on est sûr et certain qu'il va s'arrêter. ;-)
        
        Je dirais plutôt assez sûr et pas depuis longtemps.
        J’ai lancé l’arrêt d’une Fedora 17 un soir, le lendemain elle était toujours bloquée en cours d’arrêt…
        
        Je ne dis pas que la conception de systemd est mauvaise ou que ce ne sera pas un très bon système de démarrage des services un jour (j’espère que ce sera le cas, vu qu’il est maintenant difficilement évitable), mais il manque encore de maturité.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 26 mars 2014 à 06:56. Évalué à 2.
        
        Je dirais plutôt assez sûr et pas depuis longtemps.
        J’ai lancé l’arrêt d’une Fedora 17 un soir, le lendemain elle était toujours bloquée en cours d’arrêt…
        
        Fedora 17, ça date de mai 2012. Bref, ce bug, c'était sur les vielles, vielles versions de systemd. Ça ne m'est pas arrivé depuis très longtemps sous Archlinux.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 26 mars 2014 à 10:56. Évalué à 2.
        
        Je tourne sous ArchLinux et j’avais ce bug jusqu’à la semaine dernière (bon, pas une journée, mais plusieurs minutes quand même pour l’arrêt)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par lasher le 25 mars 2014 à 16:26. Évalué à 3.
        
        Bon, je voulais éviter de tomber dedans, mais je vais le faire (un ch'tit peu). Perso j'ai absolument rien contre l’idée d'un système d'init plus moderne/modulaire/configurable/. Et oui, un système d'init qui se concentre sur l'OS pour lequel il est fait, ça me semble raisonnable.
        
        Ceci étant dit, le problème n'est pas tant que systemd existe, mais que d'autres softs de plus haut niveau se basent uniquement dessus, rompant donc avec la portabilité POSIX/UNIX. Donc par exemple si GNOME décide de se baser sur systemd, mais sans offrir une couche de compatibilité "dégradée", je trouve ça extrêmement gênant, et ce, même si personnellement je n'ai plus touché de BSD depuis quelques années.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 25 mars 2014 à 16:51. Évalué à 7.
        
        Ceci étant dit, le problème n'est pas tant que systemd existe, mais que d'autres softs de plus haut niveau se basent uniquement dessus, rompant donc avec la portabilité POSIX/UNIX. Donc par exemple si GNOME décide de se baser sur systemd, mais sans offrir une couche de compatibilité "dégradée", je trouve ça extrêmement gênant, et ce, même si personnellement je n'ai plus touché de BSD depuis quelques années.
        
        Faut se plaindre à GNOME pour qu’ils fournissent un mode dégradé et/ou à ta distribution pour qu’ils implémentent l’API comme le ~~fait~~ faisait Ubuntu. Ou tu n’as qu’à utiliser KDE. :p
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par Anonyme le 23 mars 2014 à 11:01. Évalué à 4.
      
      En terme logiciel on appelle ça du bloat et du code non-maintenable. Et oui, c'est une critique parfaitement valide: si un logiciel qui est censé fournir une fonctionnalité simple se retrouve à être un monstre de complexité incompréhensible par un non-spécialiste parce qu'il fourni une masse de fonctionnalité en un bloc qui ne sont pas utiles pour tout le monde, alors oui il y a un problème.
      
      Tu veux parler du noyau Linux par exemple, avec ses milliers de drivers et options qui ne sont pas utiles pour tout le monde ?
      
      Et sinon booter une machine ca n'est pas "une fonctionnalité simple".
      
      Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote. Il pouvait aussi lire le code du processus PID 1 qui n'est pas très gros. Certes ça ne lui servait pas à grand chose parce que ça faisait exactement ce qui était écrit dans la doc et ce qui pourrai être dans l'imagination du développeur si c'était lui qui devait le programmer.
      
      C'est une blague ? J'ai jamais vu de doc correcte pour l'ancien systeme d'init, et lire du vieux code shell plein de hacks n'a rien de simple. Maintenant avec systemd il y a plein de doc très bien faite et generalement pas besoin d'aller lire le code pour comprendre comment ca marche.
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par zebra3 le 24 mars 2014 à 10:31. Évalué à 8.
      
      Parce que avant, n'importe quel développeur pouvait se lire la doc d'inittab et les scripts d'init de son système (ou du système des autres) et comprendre immédiatement ce que est censé faire son système quand il boote
      
      Euh non, pas immédiatement. Pas du tout.
      
      Entre les histoires d'initrd, de /etc/rcS.d, /etc/rc2.d ou /etc/rc.local, ça n'est pas franchement très accessible ni très documenté. Et encore, je ne parle que de Debian, sous Red Hat/Fedora c'est encore autre chose. En plus les scripts ne sont pas toujours très lisibles, surtout quand ils font référence à d'autres trucs genre /lib/lsb/init-functions.
      
      Peut-être que si tu es développeur tu peux comprendre rapidement (et encore faut aimer le bash) sauf que configurer l'init, c'est pas le boulot d'un développeur mais d'un administrateur. Ça tombe bien, systemd est conçu pour eux.
      
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par lasher le 25 mars 2014 à 16:31. Évalué à 3.
        
        Je suis globalement d'accord avec toi. Cependant, autant je ne demande pas à un admin de savoir écrire du code C++ utilisant la méta-programmation, les lambda fonctions, le tout couplé à un runtime écrit en OCaml, autant qu'il sache ce qu'est la programmation structurée, et qu'il sache lire des scripts, ça me semble la moindre des choses.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 18:00. Évalué à 5.
        
        Mouais, sauf que la plupart des scripts d'init que j'ai pu lire sont très vite illisibles dès qu'ils dépassent les 200 lignes (et c'est loin d'être rare). En plus quand tu lis des trucs comme ça pour tester une variable vide, ça fait quand même un peu peur :
        if [ x$VAR = $VAR ]
        
        Après, tu as raison, ça fait partie du métier. Sauf que le sysadmin, s'il trouve qu'un produit lui rend son boulot plus facile tout en lui laissant autant de possibilités, je ne vois pas pourquoi il se compliquerait la vie.
        
        Dire que ça fait partie du métier pour justifier un logiciel inutilement lourd ou complexe, ça me paraît un raisonnement difficilement tenable.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 26 mars 2014 à 11:00. Évalué à 1.
        
        Plains toi aux autotools pour avoir lancé cette « mode » (probablement pour pouvoir tourner sur des systèmes antédiluviens). [ "$VAR" = "" ] ça marche très bien (et tu as un raccourci [ -z "$VAR" ] si tu as une âme de perleux).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 26 mars 2014 à 11:32. Évalué à 5.
        
        Je ne dis pas qu'on ne peut pas faire autrement, je ne fais que souligner que SysV se trimballe un historique pas glorieux, quelles qu'en soient les raisons, bonnes ou mauvaises.
        
        D'où l'intérêt de systemd de faire le ménage.
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 26 mars 2014 à 14:23. Évalué à 3.
        
        [ "$VAR" = "" ] ça marche très bien
        
        Tu peux garantir que ça marche très bien sur tous les OS (pas que Linux, mais AIX etc…), de la dernière en date à celle d'il y a 20 ans?
        Car le but des autotools est d'être un max compatible. Il y a du coup des vieux trucs pourris à cause du plus petit dénominateur commun.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Moonz le 26 mars 2014 à 14:38. Évalué à 2.
        
        Non. Et alors ? on parlait des scripts d’init dans le sysv des distribs Linux des années 2000 non ?
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par Domi le 22 mars 2014 à 21:34. Évalué à 8.
  
  Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.
  
  Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.
  
  De plus, systemd n'a pas fini d'évoluer à toute vitesse car il est intimement lié aux cgroups du kernel, lesquels sont en train d'être ré-écrits complètement. Ce qui va prendre facilement encore au moins une année. Donc systemd de meme que sa doc n'ont pas finis d'évoluer, l'avalanche de bugs n'est pas prête d'être résorbée, et il n'est pas prêt d'être stabilisé, ce qui me semble la moindre des choses pour un soi-disant système d'init qui ressemble de plus en plus à une usine à gaz.
  
  Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par xcomcmdr le 23 mars 2014 à 08:18. Évalué à 5.
    
    Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.
    
    N'importe quoi. Je ne vois pas l'intérêt de suivre constamment cette évolution, à part pour contribuer au code ou à la documentation. Oui, systemd évolue vite, mais ça n'oblige en rien à modifier sa configuration, la plupart du temps. Le dernier truc dont je me souviens, c'était /etc/systctl.conf qui était remplacé par /etc/sysctl.d/, et encore j'ai rien eu à faire.
    
    Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.
    
    Tu crois que le code s'améliore tout seul avec le temps ? N'importe quoi !
    systemd est depuis longtemps un logiciel très fiable, justement parce qu'il est beaucoup utilisé et que les bugs sont vite découverts et vite résolus.
    
    De plus, systemd n'a pas fini d'évoluer à toute vitesse car il est intimement lié aux cgroups du kernel, lesquels sont en train d'être ré-écrits complètement. Ce qui va prendre facilement encore au moins une année. Donc systemd de meme que sa doc n'ont pas finis d'évoluer, l'avalanche de bugs n'est pas prête d'être résorbée, et il n'est pas prêt d'être stabilisé, ce qui me semble la moindre des choses pour un soi-disant système d'init qui ressemble de plus en plus à une usine à gaz.
    
    N'importe quoi. Les cgroups sont en train d'évoluer parce que JUSTEMENT des logiciels comme systemd qui les utilisent vraiment ont montré que l'API des cgroups était sous-optimale à l'usage.
    
    Bref pour toi, un logiciel qui stagne est un bon logiciel. C'est juste à se pisser dessus de rire.
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Anonyme le 23 mars 2014 à 11:56. Évalué à 7.
    
    Oui il existe un doc complète. Le problème n'est pas là. Le problème pour comprendre systemd est que ce logiciel évolue à toute vitesse et que pour le comprendre et suivre cette évolution, il faut être un développeur payé à plein temps pour ça.
    
    Tout comme le noyau linux qui evolue tout le temps.
    
    Une autre conséquence de cette évolution rapide est que ce logiciel est tous sauf stable et bien testé. Il s'agit au mieux d'un soft de qualité béta.
    
    Tout comme le noyau linux.
    
    Et sinon tu es tombé sur des vrais problemes de stabilité ou tu dis juste ca au hasard ?
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par Domi le 23 mars 2014 à 14:03. Évalué à -9.
      
      Avant de me mettre à l'utiliser, j'ai commencé par faire une recherche avec google, et quand j'ai vu aussi bien le nombre de bugs que le nombre de problèmes rencontrés par les utilisateurs, je me suis dit que j'allais attendre. J'ai aussi fait une recherche sur les forums, est je n'ai jamais vu un logiciel causer autant de problèmes à ses utilisateurs que systemd, ceci en plus de 20 ans d'utilisation de GNU/Linux.
      
      Quand aux cgroups du kernel, ils avaient décidés de les ré-écrire bien avant que systemd ne contacte les programmeurs des cgroups, il ne faut pas tout confondre. Et cela ne change rien au fait que tant que la ré-écriture des cgroups ne sera pas terminée, il sera impossible de stabiliser systemd.
      
      Et prétendre que le kernel n'est pas stable n'engage que celui qui a écrit ça. Il ne faut pas confondre l'intégration d'un nouveau driver ou d'une nouvelle fonction et la maintenance des fonctions existantes avec l'écriture d'un programme depuis le scratch (systemd) ou la ré-écriture complète d'un ensemble de fonctions complexes (cgroups). Sans la stabilité du coeur du système, le kernel, il aurait été impossible d'écrire qu'une des forces principales de GNU/Linux est… sa stabilité. Celui qui écrit le contraire n'a rien compris à comment fonctionne son système.
      
      Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par xcomcmdr le 23 mars 2014 à 14:21. Évalué à 8.
        
        Avant de me mettre à l'utiliser, j'ai commencé par faire une recherche avec google, et quand j'ai vu aussi bien le nombre de bugs que le nombre de problèmes rencontrés par les utilisateurs, je me suis dit que j'allais attendre. J'ai aussi fait une recherche sur les forums, est je n'ai jamais vu un logiciel causer autant de problèmes à ses utilisateurs que systemd, ceci en plus de 20 ans d'utilisation de GNU/Linux.
        
        Avant de me mettre à utiliser Ubuntu, j'ai commencé par faire une recherche avec google, et quand j'ai vu aussi bien le nombre de bugs que le nombre de problèmes rencontrés par les utilisateurs, je me suis dit que j'allais attendre. J'ai aussi fait une recherche sur les forums, est je n'ai jamais vu un logiciel causer autant de problèmes à ses utilisateurs que Ubuntu, ceci en plus de 20 ans d'utilisation de GNU/Linux.
        
        Avant de me mettre à utiliser Firefox, j'ai commencé par faire une recherche avec google, et quand j'ai vu aussi bien le nombre de bugs que le nombre de problèmes rencontrés par les utilisateurs, je me suis dit que j'allais attendre. J'ai aussi fait une recherche sur les forums, est je n'ai jamais vu un logiciel causer autant de problèmes à ses utilisateurs que Firefox, ceci en plus de 20 ans d'utilisation de GNU/Linux.
        
        Ouais, sur des sites et des forums d'entraide informatique, tu vas trouver des gens qui ont des… problèmes.
        Surprenant.
        
        Quand aux cgroups du kernel, ils avaient décidés de les ré-écrire bien avant que systemd ne contacte les programmeurs des cgroups, il ne faut pas tout confondre. Et cela ne change rien au fait que tant que la ré-écriture des cgroups ne sera pas terminée, il sera impossible de stabiliser systemd.
        
        Sauf que non. Le kernel a depuis longtemps une politique simple : pas de régression. Et surtout pas avec l'user-space. Bref, la ré-écriture des cgroups sera intégrée au kernel quand elle sera solide, en attendant les cgroups ne changeront pas ou peu. Bref, systemd est et restera stable de toute façon.
        
        Et prétendre que le kernel n'est pas stable n'engage que celui qui a écrit ça.
        
        Du point de vue de la fiabilité, j'ai déjà vu le kernel planter assez souvent… Ou les performances devenir horribles à cause d'une simple copie d'un gros fichier. Il n'est pas si fiable que ça.
        
        Sans la stabilité du coeur du système, le kernel, il aurait été impossible d'écrire qu'une des forces principales de GNU/Linux est… sa stabilité.
        
        Sans stabilité, on a pas de stabilité. Waouh ! Je pensais pas lire ça aujourd'hui. C'est révolutionnaire. Il faut que je me repose, c'est trop pour aujourd'hui, là. :-o
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Domi le 23 mars 2014 à 15:20. Évalué à -2.
        
        Tout ce que je dit est que j'ai un système qui fonctionne très bien sans systemd, et que je ne vois par conséquent aucun avantage à changer de système d'init pour un autre qui a autant de bugs. Je ne parle pas que des forums, mais aussi des bugzillas. Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs. C'est un fait, alors qu'on arrête de nous vendre ce truc comme un programme stable et bien testé. Utilisez d'autres arguments que le fait que des distros qui vivent en vendant leurs services veulent nous vendre un truc avec lequel elles sont sur de vendre leurs services.
        
        Sur les plantées du kernel, celles que j'ai expérimentées étaient liées à des bugs hardware ou du bios. Ainsi qu'à des kernels de distributions qui chargent le mauvais driver. C'est pourquoi j'utilise toujours mes propres kernels, ceci même avec les distributions binaires. Ceci permet aussi de les optimiser pour ce que je veux faire avec l'ordi. C'est un des avantages de linux, c'est que nous pouvons faire nos propres kernels. Dans cette optique, je suis aussi réticent à me mettre à systemd car il me forcerait à rajouter des cgroups dont je n'ai pas besoin à celui que j'utilise. Et je n'ai pas envie de me retrouver avec une usine à gaz déjà dans le kernel.
        
        Quand aux performances qui se dégradent, la dernière fois que cela m'est arrivé, c'était du temps des mono-processeurs, avec du multi-coeur, je n'ai jamais rien remarqué de bien sérieux, alors que je fais pas mal de compilation et d'audio temps réel. C'est sur qu'il faut trimer les priorités du système, mais entre une pause du bureau d'une fraction de seconde, ou une pause de plusieurs dizaines de secondes comme j'ai pu en observer avec des kernels temps réel sur des mono-processeurs, il y a une sacrée différence. Le plus remarquable est que pendant ces pauses du bureau, le kernel et les logiciels jack continuaient à fonctionner, ce qui prouve la fiabilité du kernel. Ces pauses ont disparu dés que je suis passé à du multicoeur pour ne plus devenir que de minuscules glitchs visuels.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Domi le 23 mars 2014 à 15:31. Évalué à -3.
        
        Et je rajoute que pendant ces pauses du bureau de plusieurs dizaines de secondes observées avec des monoprocesseurs en faisant de l'audio temps réel, si j'ai pu remarquer la stabilité du kernel, d'ALSA et de JACK, je ne peux pas en dire de même de la plupart des bureaux que j'ai testé.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 23 mars 2014 à 16:52. Évalué à 3.
        
        Tout ce que je dit est que j'ai un système qui fonctionne très bien sans systemd, et que je ne vois par conséquent aucun avantage à changer de système d'init pour un autre qui a autant de bugs. Je ne parle pas que des forums, mais aussi des bugzillas. Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs. C'est un fait, alors qu'on arrête de nous vendre ce truc comme un programme stable et bien testé.
        
        C'est pas un fait, on ne sait meme pas de quels bugs tu parles. Si ca se trouve ce sont juste des problemes mineurs, des fonctionnalités avancées en cours de developement, ou des cas particuliers qui ne fonctionnent pas non plus avec l'ancien systeme d'init.
        
        https://bugzilla.kernel.org/ a 1746 bugs ouverts actuellement. C'est pas pour ca qu'on peut dire que le noyau Linux n'est pas un OS stable et bien testé.
        
        Si au lieu de te baser sur de vagues recherches google tu l'utilisais vraiment avant de parler de sa stabilité ?
        Moi j'ai pas besoin d'une recherche google pour voir qu'il fonctionne sans problème particulier sur toutes mes machines ou il est installé.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Domi le 24 mars 2014 à 18:13. Évalué à -4.
        
        Comme tu le dis très bien, le kernel a une politique de zéro régression, ce qui n'a jamais été le cas de systemd.
        
        Quand à sous entendre que je ne saurais pas utiliser google (de vagues recherches…), c'est oublier que google ne ment pas, il trouve ce qu'on lui demande de trouver, et je n'y peut rien si la liste est aussi longue. Et j'ai aussi fait une recherche sur les bugzillas, à commencer sur celui de ma distribution.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 24 mars 2014 à 23:40. Évalué à 4.
        
        Comme tu le dis très bien, le kernel a une politique de zéro
        régression, ce qui n'a jamais été le cas de systemd.
        
        Ah oui, c'est pour ça qu'on retire jamais des drivers du kernel ?
        
        Par exemple, le token ring n'a pas été retiré :
        http://lwn.net/Articles/497397/
        
        Ou ça :
        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=127781d1ba1ee5bbe1780afa35dd0e71583b143d
        
        Ou les API dépréciés :
        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=43720bd6014327ac454434496cb953edcdb9f8d6
        
        https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=35b2a113cb0298d4f9a1263338b456094a414057
        
        Et je suppose bien sur aussi que tu utilises pas la glibc, car elle n'a pas non plus une politique "0 régression", cf https://bugzilla.redhat.com/show_bug.cgi?id=638477
        
        Ou gcc, cf tout le code qui compile plus à chaque version car gcc est devenu plus strict. (exemple : http://gcc.gnu.org/gcc-4.7/porting_to.html)
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 07:58. Évalué à 2.
        
        le kernel a une politique de zéro régression
        
        Va dire ça aux utilisateurs de CPU i386… le nouveaux Kernel ont tous une regression par rapport à avant, ils ne marchent plus sur i386 et Linus en est content.
        Ben oui, quand ça n'arrange pas, on vire, même dans le kernel. systemd est juste plus rapide car jeune.
        Dommage. Tu t'enfonces à chaque commentaire, sans accepter de te rendre compte que systemd n'invente rien, juste que tu lui en veut et invente des problèmes spécialement pour lui.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Anonyme le 25 mars 2014 à 09:45. Évalué à 4.
        
        Comme tu le dis très bien, le kernel a une politique de zéro régression, ce qui n'a jamais été le cas de systemd.
        
        J'ai du mal à comprendre ce que ca vient faire la.
        
        Tu veux dire que systemd aurait une politique de "le plus de régressions possible" ? Et pour cette raison le nombre de bugs ouverts sur le kernel n'a aucune importance et ne montre rien concernant sa stabilité, contrairement à systemd ou le nombre de bugs ouverts est bien une preuve du manque de stabilité ?
        
        Il suffirait donc que Lennart déclare "on a une politique de zéro régression" pour du jour au lendemain etre considéré comme un logiciel stable ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 23 mars 2014 à 19:12. Évalué à 7. Dernière modification le 23 mars 2014 à 19:13.
        
        Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs.
        
        Le meilleur moyen de ne pas avoir de bugs, c'est de ne pas avoir d'utilisateurs.
        Un nombre de bugs ouverts ne dit rien sur la qualité du produit, car ça dépend du nombre d'utilisateurs.
        Tu dois être vachement réputé dans l'analyse scientifique, tu considère qu'un programme avec un bug (pour 2 utilisateurs) est mieux qu'un programme qui a 1000 bugs (pour 1 million d'utilisateurs "mais on s'en fout dans l'étude")
        
        en fait, la seule chose qu'on voit est que pour ne pas changer, les anti-systemd sont à la recherche du moindre petit truc qu'ils vont agrandir en espérant que plus c'est gros, plus ça passe. Tant pis pour l'objectivité, c'est un gros mot.
        question idiote : tu as regardé le nombre de bugs ouverts pour Linux (le noyau)? quel noyau de merde (vu le nombre de bugs), pourquoi l'utilises-tu donc?
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Misc (site web personnel) le 23 mars 2014 à 13:33. Évalué à 5.
    
    Une autre conséquence de cette évolution rapide est que ce
    logiciel est tous sauf stable et bien testé. Il s'agit au mieux
    d'un soft de qualité béta.
    
    La version 208 est listé comme LTS, et elle est intégré dans RHEL 7. Que je sache, il y a une équipe QA dédié pour justement s'assurer que les logiciels soit pas dans l'état "pas stable" pour la version finale. De ce que je vois sur ma machine de test, c'est une version 208 qui est fourni, version 208 aussi listé comme "LTS" par l'upstream de systemd, avec une branche git dédié.
    
    On peut rajouter que pour un truc que tu qualifies de béta, y a plein de distro qui l'utilise ( Mageia, Arch, Fedora, Opensuse ), qu'il y a des hébergeurs qui l'utilisent en prod ( Pantheon system, qui parle de 500 000 unités lancés https://www.getpantheon.com/blog/pantheon-running-over-500000-systemd-units , Flow Pilots ( http://savanne.be/articles/deploying-node-js-with-systemd/ ). Il y a des boites qui l'utilisent comme CoreOS qui fait un OS dédié à avoir systemd, docker et des outils de gestions, ou Axis ( vu les patchs qui passent sur la ml ).
    
    Le problème pour comprendre systemd est que ce logiciel évolue
    à toute vitesse et que pour le comprendre et suivre cette
    évolution, il faut être un développeur payé à plein temps pour
    ça.
    
    Ma foi, je vais devoir demander à mon employeur de me payer un deuxiéme salaire, car j'arrive à suivre sans bosser à plein temps dessus. En fait, sans être payé pour regarder systemd, juste par curiosité.
- [^] # Re: De plus en plus complexe, le système d'init...
  
  Posté par zaz le 23 mars 2014 à 12:34. Évalué à -5.
  
  Le syndrome de la boîte noire
  
  Je n'aime pas systemd. On met un bout de texte dans un fichier de configuration, et le truc fait de la magie et voilà. Il faut juste faire confiance. Ceci dit, systemd est loin d'être le seul à faire ça (penser à mount et fstab par exemple).
  Moi, j'aime bien contrôler. Avec des scripts shells, c'est exactement ça qu'on a : Le contrôle.
  Parce que systemd entretient des liens étroits avec le Kernel, il peut mieux maîtriser les processus qu'un script, avantage indéniable. On peut aussi arguer que de par ce fait, il peut aussi mieux 'merder'.
  Juste faire confiance…
  Le Linux que j'utilise est un distribution personnelle faite par moi et mes petits doigts (fatigués d'avoir trop tapé). Normal que je n'aime pas les boîtes noires.
  Ceci dit pour une distribution Linux, je comprends très bien l'intérêt d'utiliser systemd plutôt que des scripts.
  Pas de quoi s'énerver. Ou presque. Je me vois assez bien dire à Poettering 'enlève tes lunettes' afin de mieux le baffer. Mais bon, ce n'est pas une bonne raison pour rejeter systemd :D
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Zenitram (site web personnel) le 23 mars 2014 à 12:44. Évalué à 0. Dernière modification le 23 mars 2014 à 12:45.
    
    Le syndrome de la boîte noire
    
    systemd est autant boite noire que le noyau Linux.
    Mai bizarrement, tu aimes l'un et pas l'autre, va comprendre…
    
    Sinon, ça fait rire de traiter un logiciel Open Source et hyper document de boite noire, très démonstratif du n'importe quoi que doivent trouver les gens qui n'aiment pas pour s'auto-persuader qu'ils ont logique.
    
    Le Linux que j'utilise
    
    Le syndrome de la boîte noire tout autant (tu vas nous dire que tu connais tout?)
    
    faite par moi et mes petits doigts
    
    Et tu peux faire pareil avec systemd, qu'il est beau!
    
    Je me vois assez bien dire à Poettering 'enlève tes lunettes' afin de mieux le baffer
    
    Sans commentaires… ou plutôt si : violence tout de suite (même si c'est verbal, ça montre fort ta vision des gens en désaccord et qui se bougent leur cul)
    Pourquoi le baffer? Vu que tu penses savoir faire mieux, je te défie de démontrer que ta façon de faire est meilleure plutôt que de baffer une personne qui ne t'a forcé aucunement à prendre systemd (la seule personne qui décide étant… Toi, vu que toi seul est maitre du choix de ta distro).
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par zaz le 23 mars 2014 à 13:13. Évalué à -5.
      
      Peux-tu reformuler un peu le :
      << Sinon, ça fait rire de traiter un logiciel Open Source et hyper document de boite noire, très démonstratif du n'importe quoi que doivent trouver les gens qui n'aiment pas pour s'auto-persuader qu'ils ont logique.
      
      Je ne comprend pas bien.
      
      Pour Poettering, je reconnais que j'aurais pu m'abstenir. Mais, voilà, je pense que de par sa personnalité, il provoque, sans le vouloir, des exaspérations qui crispent les débats. J'ai voulu résumer ça en une petite phrase humoristique.
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Anonyme le 23 mars 2014 à 14:19. Évalué à 9.
    
    Je n'aime pas systemd. On met un bout de texte dans un fichier de configuration, et le truc fait de la magie et voilà. Il faut juste faire confiance. Ceci dit, systemd est loin d'être le seul à faire ça (penser à mount et fstab par exemple).
    Moi, j'aime bien contrôler. Avec des scripts shells, c'est exactement ça qu'on a : Le contrôle.
    
    Non, tu n'as pas non plus le controle. Avec ton script shell, tu mets des commandes dans un fichier, et le truc fait de la magie et voilà. Ton shell va executer des commandes, mais tu ne sais pas trop comment, quelles seront les instructions assembleur, les appels systeme, les fichiers ouverts, etc … Il faut juste faire confiance.
    
    Si tu veux vraiment le controle, le plus simple c'est d'ecrire ton programme sur des cartes perforées. Et non pas avec une boite noire tel qu'un editeur de texte ou tu n'as aucun controle sur ce qui est vraiment ecrit sur le disque ! Sans parler du systeme de fichier à qui l'editeur de texte doit juste faire confiance: un empilement de boites noires sur des boites noires ! Une fois que c'est fait, le mieux ensuite c'est d'executer les instructions dans ta tete. Ne surtout pas passer par une boite noire comme un microprocesseur qui execute des instructions sans que tu saches vraiment comment.
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par zaz le 23 mars 2014 à 18:40. Évalué à 0.
      
      Ce que tu dis est vrai.
      Le truc a pris un tour un peu monstrueux que je n'attendais pas (d'accord je n'aurais pas du troller sur Poettering).
      J'ai simplement voulu dire que si tu maintiens une distribution utilisée professionnellement, je comprend très bien l'intérêt de systemd. Si tu fais ton truc à toi, genre pour le fun, ou un système 'embedded' sur une toute petite machine, sans udev ni dbus… Quelques bons petits scripts…
      C'est tout. Bisous
    - [^] # Re: De plus en plus complexe, le système d'init...
      
      Posté par Domi le 24 mars 2014 à 18:16. Évalué à -5.
      
      Si je pousse ta logique jusqu'au bout, je construit mon propre PC avec des composants discrets parce qu'aucun constructeur de microprocesseurs et de chip ne libre le code source de ses circuit, et qu'il y a deux moyens pour implémenter un programme, sous forme logicielle ou en le gravant dans le silicium.
      
      Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
      - [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Maclag le 24 mars 2014 à 21:15. Évalué à 8.
        
        Si je pousse ta logique jusqu'au bout, il faut lire le code source d'absolument tout ce qui est lancé sur la machine. Parce que systemd, tu sais pas ce qu'il fait, mais moi, Apache2, une fois que je lance le serveur, je n'ai aucune idée de ce qu'il fait dans mon dos, et au vu de la taille de la doc, y'a de quoi faire.
        Tiens, faudra parler de la glibc aussi, tu sais exactement tout ce que font chacune de ses fonctions?
        
        Non, dans les deux cas, tu as une vue grossière de ce qui se passe et ça t'a suffi jusqu'ici. Par contre, pour systemd, curieusement, c'est inacceptable.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 11:26. Évalué à -6.
        
        Parce que systemd, tu sais pas ce qu'il fait, mais moi, Apache2, une fois que je lance le serveur, je n'ai aucune idée de ce qu'il fait dans mon dos, et au vu de la taille de la doc, y'a de quoi faire.
        
        Je ne te confierai jamais l'administration d'une machine. Encore moins la conception d'un Linux embarqué.
        
        Je demande pas non plus que tu puisse expliquer chaque instruction assembleur utilisée, mais dire que tu n'a aucune idée de ce que ton serveur HTTP fait (hors failles de sécurités), des requêtes qu'il accepte et des modifications qu'il peut faire à ton système, alors tu a juste construit un serveur qui est tombé en marche.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 11:32. Évalué à 5.
        
        Oui mais il faut lire la documentation, se former. Tout comme pour les scripts SysV.
        
        systemd te fait abstraction de beaucoup de concepts, mais tu peux comprendre son fonctionnement : il y a de la documentation, le code source est accessible, etc.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 11:53. Évalué à -5.
        
        systemd te fait abstraction de beaucoup de concepts
        
        Il ne fait d'abstraction sur rien du tout: Ce n'est pas lui qui configure et gère les services, il ne fait que les lancer et les arrêter. Satisfaire les besoins et les dépendances d'un service restera à ta charge. Toutes les dépendances ne peuvent pas s'exprimer dans un unit systemd, certaines peuvent être particulièrement poilues comme "ce point de montage doit être démontable à n'importe quel moment", ou "ce logiciel ne supporte pas les changements d'heures".
        
        Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.
        
        "Leaky abstractions" comme dirait l'autre.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par GaMa (site web personnel) le 25 mars 2014 à 11:58. Évalué à 5.
        
        comme "ce point de montage doit être démontable à n'importe quel moment", ou "ce logiciel ne supporte pas les changements d'heures".
        
        Comment tu gères ces dépendances avec des scripts bash ?
        
        Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.
        
        Ça c'est vrai tout le temps, pourquoi ça pose un problème avec systemd ?
        
        Matthieu Gautier|irc:starmad
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 12:04. Évalué à 6. Dernière modification le 25 mars 2014 à 12:04.
        
        Satisfaire les besoins et les dépendances d'un service restera à ta charge.
        
        Par chance, si tu connais les dépendances les gérer est bien plus simple avec systemd qu'avec ton script SysV. Et lui gérera ça pour toi partiellement, tu n'as qu'à lui fournir le nom et non le mécanisme entier.
        
        Toutes les dépendances ne peuvent pas s'exprimer dans un unit systemd,
        
        Référence nécessaire.
        Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.
        
        Note que l'inverse est sans doute plus vrai encore, de nombreux cas pourtant "simples" ne sont pas gérables proprement avec SysV.
        
        Et si tu ne lit pas la documentation sur tout ton système et que tu ne regarde pas ce que fait chaque programme, tu peux toujours t'accrocher.
        
        systemd ne change rien sur ce fait (et SysV non plus), mais permet de s'affranchir de l'apprentissage de certaines choses avec un minimum d'apprentissage car on peut gérer des services sans être sysadmin d'un serveur critique tu sais…
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 16:54. Évalué à -1.
        
        Référence nécessaire.
        
        J'ai un service que je veut démarrer lorsque j'ai une route vers une IP, et que je veux arrêter lorsque je n'ai plus cette route vers une IP. Bien entendu je suis sur un pseudo "routeur", la route est dynamique.
        
        Il gère ça le systemd ?
        
        Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.
        
        Quel est l'intérêt de systemd alors ?
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par zebra3 le 25 mars 2014 à 17:03. Évalué à 8.
        
        Quel est l'intérêt de systemd alors ?
        
        Rendre le démarrage plus rapide.
        
        Rendre le système plus réactif par rapport à son environnement (par exemple le passage sur batterie arrête certains services).
        
        Fournir des outils d'analyse (systemctl --failed ou systemd-analyze).
        
        Simplifier l'écriture de services et la gestion des dépendances.
        
        Simplifier l'administration avec un outil unique à la syntaxe simple.
        
        Avoir une documentation complète (non, SysV y'a pas de doc).
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Renault (site web personnel) le 25 mars 2014 à 17:04. Évalué à 7.
        
        Il gère ça le systemd ?
        
        Je ne sais pas, mais comme il peut lire les scripts SysV, si tu arrives à le faire avec alors il pourra.
        
        Quel est l'intérêt de systemd alors ?
        
        La compatibilité ascendante ça te dit quelque chose ? Ça aide à faire la transition que ce soit pour les distributions ou les admins systèmes.
        
        À quoi ça sert que LibreOffice sache lire des fichiers Words de 97 ? À quoi ça sert que Firefox sache ire des pages HTML 1 ? À quoi ça sert de lire les partitions NTFS quand on a ReiserFS ou BTRFS ? Etc.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 17:36. Évalué à 4. Dernière modification le 25 mars 2014 à 17:37.
        
        Et si jamais ça arrive, systemd n’enlève pas la possibilité d'utiliser des scripts SysV.
        
        Quel est l'intérêt de systemd alors ?
        
        Du gros fouage de gueule :
        - systemd ne fait pas de compatibilité ascendante : c'est horrible
        - systemd fait de la compatibilité ascendante : c'est horrible
        
        Tu devrais être honnête et dire : "c'est horrible quoi qu'il fasse".
        
        Ma machine sait lire les CD (le truc d'avant, si tu as pas ta clé USB sur toi), quel est l'intérêt du port USB dessus?
        C'est la question que tu poses… Oui, elle est ridicule cette question, tu t'enfonces à chaque commentaire que tu fais tellement c'est énorme.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 25 mars 2014 à 12:39. Évalué à 5.
        
        Il ne fait d'abstraction sur rien du tout
        
        Tu bullshites.
        
        par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau ). Quand l'admin dit "je veux que tel répertoire soit non lisible par ce démon", c'est une abstraction de niveau plus haut que "faire tel truc avec le namespace". la seule chose demandé, c'est le repertoire. Le reste est fait par systemd, sans que tu dise "je veux monter un namespace avec tel permission sur tel répertoire quand je lance tel truc".
        
        Quand tu dit "il faut assigner tant de ram pour ce groupe", systemd va faire un cgroups, et mettre la config qu'il faut.
        
        ce point de montage doit être démontable à n'importe quel
        moment", ou "ce logiciel ne supporte pas les changements
        d'heures".
        
        Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".
        
        Donc forcément, en demandant des trucs qui sont impossible ( à savoir une fiabilité à 100% ), tu déduis "systemd permet pas de filer un truc qui marche dans tout les cas sorti de mon imagination, alors c'est pourri".
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 25 mars 2014 à 16:23. Évalué à -1.
        
        par exemple, quand l'admin dit "je veux que ce logiciel tourne sans réseau", il fait abstraction de la méthode ( à savoir les namespaces réseau )
        
        Cette abstraction ne tiens pas la route, vu que ce n'est pas Systemd qui configure le service, c'est moi.
        
        Si je configure le service pour qu'il se connecte à localhost vers un autre service, le mettre dans un network namespace séparé ne marchera pas, sauf configuration particulière du namespace. Pourtant j'ai bien envie qu'il n'accède pas au réseau. Et j'ai pas envie qu'il accède à tout mes services locaux en plus.
        
        Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.
        
        Tu confonds "contraintes pour qu'un système démarre" et "contraintes pour qu'un systéme tourne sans jamais aucun souci".
        
        Je ne fais pas de différences entre les deux, moi je veux un système qui marche. Si il merde au démarrage ou après, c'est déjà un échec, parce que ce système devait marcher.
        
        Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.
        
        Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.
        
        Et le syndrome de systemd qui consiste à uniquement regarder ce qu'on besoin 80% des personnes et a envoyer chier les autres ne simplifie vraiment pas le problème. Pour systemd, ils ont du regarder les besoins de la plupart des services et ils vont se dire qu'ils ne vont gérer que ces contraintes là, les autres pouvant aller se faire foutre. Pareil pour system-networkd: ils ont du rencontrer un admin qui leur à demandé une certaine liste de fonctionnalité et ils n'ont pas du se dire que peut-être un jour d'autres personnes auront d'autres besoins. On se retrouve avec des logiciels qui sont utiles que pour une certaines majorité de personnes qui viennent ensuite expliquer aux autres comment ils n'ont pas besoin des fonctionnalités qu'ils avaient avant.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par ariasuni le 25 mars 2014 à 16:58. Évalué à 4.
        
        Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.
        
        systemd est flexible, il ne t’empêche pas faire ta configuration perso. Mais il offre des options sympathique pour les usages courants.
        
        Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.
        
        En quoi c’est pas possible avec systemd?
        
        Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.
        
        On peut modifier toutes les unités systemd et les surcharger avec d’autres fichiers, donc je vois absolument pas pourquoi tu aurais besoin de patcher le système d’init (à moins qu’il soit codé avec le cul). C’est bien ça l’avantage avec systemd: on est pas obligé de toucher au code pour le faire fonctionner comme on veut.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Misc (site web personnel) le 25 mars 2014 à 23:41. Évalué à 6.
        
        Si je configure le service pour qu'il se connecte à localhost
        vers un autre service, le mettre dans un network namespace
        séparé ne marchera pas, sauf configuration particulière du
        namespace. Pourtant j'ai bien envie qu'il n'accède pas au
        réseau. Et j'ai pas envie qu'il accède à tout mes services
        locaux en plus.
        
        En fait, le souci, c'est que tu fait pas vraiment d'effort pour être crédible. Car bon, tout ton argumentaire est foireux, mais jusqu'à maintenant, il était foireux mais crédible pour quelqu'un qui passe vite fait en ayant juste lu la dépêche. La, tu passes une étape, et tu commence à dire "systemd fait pas ça", avec ça étant décrit dans la dépêche.
        
        En l'occurrence, "JoinsNamespaceOf" qui permet d'avoir 2 service dans le même namespace. mais bon, je sais déjà ce que tu va répondre, tu va sortir des trucs à base de "oui, je veux que les 2 soit dans le même namespace mais l'un des softs aussi dans un autre namespace, etc, etc, etc". et sortir un hypothétique soft et/ou réglage que tu seras incapable de faire en bash ( car pour le moment, tu brilles pas vraiment pas ta capacité à donner des vrais explications techniques, tu restes vachement dans le flou et dans le vague ).
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Batchyx le 29 mars 2014 à 16:46. Évalué à -3.
        
        La, tu passes une étape, et tu commence à dire "systemd fait pas ça", avec ça étant décrit dans la dépêche.
        
        Prend moi pour un idiot qui sait pas lire, en plus. Déjà, Nulle part j'ai indiqué que l'autre service ne doit pas avoir accès à Internet. En fait, je veux que l'autre service ai accès à Internet.
        
        Même s'il ne doit pas avoir accès à Internet, si j'ai besoin de lui dire explicitement de rejoindre un certain namespace, ça pète l'abstraction. Moi je veux que "le service truc n'ai pas accès à Internet" (mais qu'il puisse accéder au service machin, qui, il se trouve, utilise des sockets TCP bindées sur localhost en sous-main, les abstractions, il n'y a pas que systemd qui en fait). Si je doit prendre en compte l'implémentation de systemd et du moyen de communication entre les deux services, j'ai pas fini. Dans ce cas, l'abstraction est nulle à chier, ce que je me tue à dire.
        
        Il y a plein de manière d'empêcher un service d'accéder à Internet. Il y en a aucune de parfaite, chacune ayant ses défaut. Systemd en à choisi une, mais ne fait absolument aucune abstraction de ces défauts.
        
        Enfin bref, je me répète, mais c'est une "Leaky abstraction" ( http://www.joelonsoftware.com/articles/LeakyAbstractions.html ). L'abstraction c'est joli, mais quand c'est mal fait ça fait plus de mal que de bien. Ou bien on vire l'abstraction, ou bien on l'améliore. Et merci pour les hommes de pailles ou on me fait dire que je réclame les deux à la fois.
        
        [^] # Re: De plus en plus complexe, le système d'init...
        
        Posté par Zenitram (site web personnel) le 25 mars 2014 à 12:09. Évalué à 2. Dernière modification le 25 mars 2014 à 12:11.
        
        Je ne te confierai jamais l'administration d'une machine.
        
        Perso, je ne confierai jamais (ou disons temporairement) l'administration d'une machine à une personne qui rejette par principe ce qui est nouveau, par flemme de se former, de l'inconnu, car c'est une personne non optimale.
        
        Comme quoi, les choix… Malheuresement pour la personne qui rejette systemd, il va y avoir de moins en moins de boulot pour elle (les gens avancent, les autres sont soit virés soit leur boite coulent faute de rentabilité vu qu'ils laissent ça un peu partout, donc revient au même).
        
        Je demande pas non plus que tu puisse expliquer chaque instruction assembleur utilisée,
        
        C'est ce que tu demandes à systemd.
  - [^] # Re: De plus en plus complexe, le système d'init...
    
    Posté par Emmanuel C le 25 mars 2014 à 10:24. Évalué à 10.
    
    Donnez moi du systemd, je n'en veux pas !
    Des cgroups et journald, je n'en veux pas !
    Donnez moi un boot rapide, j'en ferais quoi ? pa pa la pa pa pa la
    Offrez moi du kdbus, j'en ferais quoi ?
    Modernité, simplicité, ce n'est pas pour moi !
    Networkd et machind, j'en ferais quoi ? pa pa la pa pa pa la
    
    Je veux du script, du bash, c'est que du bonheur !
    Corriger des bugs dans la douleur !
    Sys-V init, la main sur le cœur… pa pa la pa pa pa la
    Restons ensemble coincé dans le passé !
    Retenez bien tous nos clichés !
    Bienvenue dans notre réalité !
# À corriger

Posté par Sylvain Blandel le 21 mars 2014 à 14:34. Évalué à 2. Dernière modification le 21 mars 2014 à 14:35.

Une faute à corriger dans la dépêche :

Posons d’abord le décor : les développeurs du projet BlueZ a décidé de refaire leur interface

a → ont
- [^] # Re: À corriger
  
  Posté par Benoît Sibaud (site web personnel) le 21 mars 2014 à 14:39. Évalué à 4.
  
  Corrigé, merci.
- [^] # Re: À corriger
  
  Posté par Dr BG le 21 mars 2014 à 16:05. Évalué à 5.
  
  et
  
  Petits changements ça et là
  
  Ah çà ! Ici, ça s'écrit çà (et là), qui veut dire ici.
  - [^] # Re: À corriger
    
    Posté par Benoît Sibaud (site web personnel) le 21 mars 2014 à 16:40. Évalué à 4.
    
    Corrigé, merci.
    - [^] # Re: À corriger
      
      Posté par BAud (site web personnel) le 21 mars 2014 à 16:46. Évalué à 2.
      
      c'est ainsi qu'il était écrit lors de l'envoi en modération :-) (vu que j'étais déjà passé dessus en rédaction).
- [^] # Re: À corriger
  
  Posté par Pipo Le Clown le 21 mars 2014 à 17:00. Évalué à 4.
  
  Je hijacke le thread.
  
  Serait il possible de créditer correctement les images (i.e. en respectant la/les licences) ?
  
  Pour la première, un petit "By Harald Hoyer (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons" avec un lien vers https://commons.wikimedia.org/wiki/File:Lennart_Poettering_2012.jpg sur l'image ou dans le crédit.
  
  Pour la deuxième… je ne sais pas.
  - [^] # Re: À corriger
    
    Posté par ariasuni le 21 mars 2014 à 17:05. Évalué à 3.
    
    Pour la première, c'est ma faute! Pour la deuxième en revanche je ne sais plus…
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: À corriger
      
      Posté par navaati le 21 mars 2014 à 17:14. Évalué à 1.
      
      La deuxième vient de Google+ non ? Postée par Kay Sievers je crois, pas sûr du tout.
    - [^] # Re: À corriger
      
      Posté par Pipo Le Clown le 21 mars 2014 à 17:40. Évalué à 1.
      
      Merci pour la correction :)
- [^] # Re: À corriger
  
  Posté par Misc (site web personnel) le 23 mars 2014 à 14:37. Évalué à 2.
  
  dans le même genre, le nom du portable, c'est "lenovo yoga", pas yago.
# Timers

Posté par claudex le 21 mars 2014 à 14:47. Évalué à 4.

À propos des timers, comment se comportent-ils lorsqu'un évènement se produit alors que le PC était éteint ?

« 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: Timers
  
  Posté par navaati le 21 mars 2014 à 16:38. Évalué à 0.
  
  Rien, ça remplace pas anacron. Sauf évolution récente que j'ai loupée, mais ça m'étonnerai.
  - [^] # Re: Timers
    
    Posté par MCMic (site web personnel) le 27 mars 2014 à 14:41. Évalué à 5.
    La version 212 vient de sortir, extrait du changelog:
    * Timer units gained a new WakeSystem= switch. If enabled timers configured this way will cause the system to resume from system suspend (if the system supports that, which most do these days).
    
    * Timer units gained a new Persistent= switch. If enabled timers configured this way will save to disk when they have been last triggered. This information is then used on next reboot to possible execute overdue timer events, that couldn't take place because the system was powered off. This enables simple anacron-like behaviour for timer units.
    - [^] # Re: Timers
      
      Posté par ariasuni le 27 mars 2014 à 15:13. Évalué à 2.
      
      Tu gâches tout le suspens!
      
      Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Timers
      
      Posté par claudex le 27 mars 2014 à 16:32. Évalué à 5.
      
      This enables simple anacron-like behaviour for timer units.
      
      Il y a moyen de faire quoi de plus compliqué avec anacron ?
      
      « 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: Timers
  
  Posté par Sylvain Blandel le 21 mars 2014 à 17:16. Évalué à 7.
  
  À propos des timers, comment se comportent-ils lorsqu'un évènement se produit alors que le PC était éteint ?
  
  Je viens d'essayer avec un PC en veille.
  
  L'évènement devait se produire à 17h, mais le PC était en veille à cette heure-là. Résultat : l'évènement s'est produit immédiatement au sortir de la veille.
  
  À ce sujet : Remplacer cron par systemd
  - [^] # Re: Timers
    
    Posté par anaseto le 22 mars 2014 à 18:33. Évalué à 7.
    
    À ce sujet : Remplacer cron par systemd
    
    Quand au compare au simple crontab -e puis ajouter une simple ligne, ça a l'air très alambiqué tout ça quand même. Il y a des raisons à tout ça, aucun doute, mais pour l'utilisateur final que je suis, je vois juste qu'avec cron en lisant une seule page man relativement courte je pouvais ajouter facilement une tâche périodique à l'aide d'une commande à une seule option et sans arguments, et en écrivant une seule ligne dans un fichier. Pourquoi je pourrais préférer alors lire plusieurs pages de manuels, m'occuper de plusieurs fichiers, taper des commandes plus complexes (j'en compte plusieurs dans ton tuto), auxquelles j'imagine il faut rajouter quelque trucs si on veut faire tout ça sans root, si c'est finalement pour arriver au même résultat ?
    - [^] # Re: Timers
      
      Posté par Zenitram (site web personnel) le 22 mars 2014 à 21:31. Évalué à 1.
      
      taper des commandes plus complexes (j'en compte plusieurs dans ton tuto),
      
      Les commandes de systemd, je les comprend en grandes lignes en les lisant.
      Alors que les commandes de cron, à chaque je dois relire le manuel tellement c'est cryptique.
      chacu son truc, mais perso je sais que les exemples de son tuto et d'autres, je pourrais les modifier vite fait sans devoir relire un manuel, alors que je sais par expérience qu'à chaque fois que je veux modifier un truc dans le cron je dois ouvrir le manuel.
      (sans compter que l'exemple est la pour réutiliser l'existant, pas forcément le plus direct sans réutilisation)
      
      On va dire que c'est chacun son plaisir et sa façon de travailler (et ses problèmes pour retenir toutes les syntaxes de plein d'applis dans sa mémoire humaine).
      - [^] # Re: Timers
        
        Posté par Moonz le 22 mars 2014 à 22:10. Évalué à 6.
        
        Alors que les commandes de cron, à chaque je dois relire le manuel tellement c'est cryptique.
        
        Je vois pas en quoi @hourly /usr/local/bin/myjob c’est cryptique.
        
        Et je vois encore moins en quoi séparer ça en deux fichiers de plusieurs lignes est une avancée pour la simplicité d’utilisation et la maintenabilité.
        
        [^] # Re: Timers
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 14:36. Évalué à 6.
        
        Ton exemple est le moins cryptique qu'on puisse trouver. Un truc comme :
        
        */5 10 * * 2 /usr/local/bin/yourjob
        
        Est cryptique.
        
        Bien sur, il est cryptique car il a pas beaucoup de sens ( le job est lancé tout les mardis, à 10h par intervalles de 5 minutes, c'est assez peu courant et compliqué à souhait ).
        
        A comparer avec :
        
        0 */2 */3 * * /usr/local/bin/yourjob
        
        Lancer tout les 3 jours, et avec un intervalle de 2 heures entre chaque job.
        
        Pour les trucs simples, c'est assez simple ( une fois que tu penses à mettre 0 et pas * pour lancer une fois par heure, et quand tu penses que c'est rangé par ordre de durée ( minute -> heure -> jour -> mois ), modulo une exception pour le jour de la semaine ). Pour les trucs compliqués, c'est vachement plus compliqués.
    - [^] # Re: Timers
      
      Posté par Misc (site web personnel) le 23 mars 2014 à 13:15. Évalué à 9.
      C'est clairement plus complexe. Et je pense que l'article "remplacer cron par systemd" est trompeur, les 2 ne font pas les mêmes choses ( exemple, systemd envoie pas de mail que je sache quand un tache est lancé ). L'idée est plus de complémenter que de remplacer.
      
      Systemd propose des choses que cron propose pas. La gestion fines des ressources intégré dans l'unité est AMHA important pour un usage dans un adre de serveur. Par exemple, la gestion des backups et des taches nocturnes ( genre la tache de backup qui prends pas tout les i/o sur le serveur ).
      
      La précision des timers de systemd est aussi plus fine.
      
      OnActiveSec fait la même chose que at, OnBootSec permet de delayer le lancement d'une tache aprés le boot ( cron ne supporte que @boot je crois ). OnUnitActiveSec permet de dire "toutes les 17 minutes et 5 secondes", chose qu'on peut pas vraiment faire proprement avec cron ( non pas que ça me manque en pratique, les gens sont content d'arrondir à "toutes les 10 minutes", ou à faire une magouille à base de script et d'estimation par pgcd ).
      
      Les timers ont aussi une résolution inférieur à la minute, ce qui est un plus dans certains cas ( je pense par exemple pour de l'embarqué ).
      
      Et la syntaxe est aussi AMHA plus simple à comprendre, car bon, sans la doc ajouté par un patch externe à cron ( come le fait Debian et Mageia ) quand on fait crontab -e ( qui rajoute "# m h dom mon dow command" en guise de doc ), la syntaxe de "* * 5 * * /bin/foo" est pas super intuitive par rapport à celle de systemd, dont acte :
      
      OnCalendar=08:05
      
      vs
      
      5 8 * * * /bin/foo
      
      Donc non, on remplace pas cron par systemd, mais systemd peut apporter des choses à certains.
    - [^] # Re: Timers
      
      Posté par Sylvain Blandel le 25 mars 2014 à 14:36. Évalué à 3.
      
      À ce sujet : Remplacer cron par systemd
      
      Quand au compare au simple crontab -e puis ajouter une simple ligne, ça a l'air très alambiqué tout ça quand même.
      
      Pas faux. :-)
      
      Ceci étant, pour utiliser cron, on ne peut pas se contenter du seul fichier crontab, on doit également avoir un script qui lance le service cron. Ce script est généralement placé dans le répertoire /etc/init/ (on se contente habituellement du script écrit par le mainteneur de la distribution).
      
      Bien entendu, on peut avoir systemd comme gestionnaire d'init et de services, et continuer à utiliser le classique cron.
  - [^] # Re: Timers
    
    Posté par Domi le 22 mars 2014 à 21:38. Évalué à -9.
    
    Autrement dit l'événement qui aurait du se produire à 17 heure ne s'est pas produit, ce qui explique pourquoi Tchernobil à pété ! Super systemd.
    
    Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
    - [^] # Re: Timers
      
      Posté par Sufflope (site web personnel) le 22 mars 2014 à 22:16. Évalué à 7.
      
      L'évènement devait se produire à 17h, mais le PC était en veille à cette heure-là.
      
      l'événement qui aurait du se produire à 17 heure ne s'est pas produit, ce qui explique pourquoi Tchernobil à pété ! Super systemd.
      
      C'est la faute de systemd si l'ordi était en vei…
      
      …
      
      … non je n'ai même pas envie de finir ma phrase.
      - [^] # Re: Timers
        
        Posté par anaseto le 23 mars 2014 à 10:11. Évalué à 4.
        
        Bah si systemd n'est même pas capable de sortir l'ordinateur de veille pour lancer une commande et se remettre en veille… d'ailleurs je pense qu'il devrait même être capable de démarrer l'ordinateur s'il est éteint. Je vais de ce pas faire une feature request, et au passage je leur demanderai d'implémenter systemd-remonte-moi-le-temps pour remonter le temps (comme son nom l'indique), ça peut toujours servir et ça permettra au passage de faire de systemd le premier système d'init de l'histoire, il le mérite bien. C'est clair que systemd, c'est très prometteur, mais il lui manque malheureusement encore tout un tas de trucs de base qui le rendent inutilisable pour les besoins du desktop ou d'une centrale nucléaire moderne.
        
        [^] # Re: Timers
        
        Posté par Zenitram (site web personnel) le 23 mars 2014 à 10:58. Évalué à 1. Dernière modification le 23 mars 2014 à 10:59.
        
        Bah si systemd n'est même pas capable de sortir l'ordinateur de veille pour lancer une commande et se remettre en veille…
        
        Bah si on ne veut pas que l'OS bouffe la batterie (ce pour quoi on l'a mis en veille)…
        
        Bref, avant d'implémenter un "callback" matériel qui va faire se se reveiller tout seul le matériel (ben oui, systemd étant… en veille, donc ne peut rien faire) pour passer des commandes à systemd qui va bouffer de la batterie alors qu'on voulait l'inverse, il faut bien étudier le besoin : le besoin de lancer une commande à une heure précise en priorisant l'heure sur la batterie n'enlève pas le besoin de ne pas la lancer si l'ordinateur est en veille pour prioriser la batterie.
        
        C'est marrant, d'un côté on critique la complexité de systemd, de l'autre on lui demande de communiquer encore plus avec le matériel, schizophrénie quand tu nous tiens… Certes pas les mêmes personnes mais il faut imaginer qu'en face, le développeur est le même : les gens (pas les mêmes, mais les gens) ne seront jamais contents.
        
        (au fait, comment ça se passe avec cron dans le même cas?)
        
        [^] # Re: Timers
        
        Posté par anaseto le 23 mars 2014 à 13:29. Évalué à 4. Dernière modification le 23 mars 2014 à 13:32.
        
        Je précise, au cas où c'était pas clair, que mon commentaire était à prendre au 42-ème degré, qu'il est impossible normalement d'en tirer quoique ce soit, et que toute ressemblance avec des informations qui pourraient se rapporter à la réalité est purement fortuite.
        
        [^] # Re: Timers
        
        Posté par Domi le 23 mars 2014 à 14:14. Évalué à -4.
        
        Nous avons donc deux besoins possibles: donner la priorité à l'heure ou donner la priorité à la charge de la batterie, et systemd dans ce cas choisis à la place de l'utilisateur ce qu'il convient de faire. Il fourni donc une politique système au lieu de fournir à l'administrateur ou à l'utilisateur les moyens de faire lui-même ses propres politiques système.
        
        Indépendamment de tout ce qui a été dit d'autre sur systemd, c'est bien le principal reproche que l'on peut lui faire, reproche qui a déjà été fait par des programmeurs bien plus qualifiés que moi. systemd, en étabilssant des politiques système au lieu de fournir les moyens de faire des politiques système est donc déjà un plus grand problème que celui qu'il était censé résoudre. Sur le long terme, son adoption finale dépendra donc de sa faculté à résorber ce problème. Il y a déjà eu d'autres systèmes "géniaux" dans GNU/Linux, par exemple Hal, qui aujourd'hui sont totalement abandonnés.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Timers
        
        Posté par claudex le 23 mars 2014 à 14:38. Évalué à 4.
        
        Nous avons donc deux besoins possibles: donner la priorité à l'heure ou donner la priorité à la charge de la batterie, et systemd dans ce cas choisis à la place de l'utilisateur ce qu'il convient de faire.
        
        Tout comme cron ou at.
        
        Indépendamment de tout ce qui a été dit d'autre sur systemd, c'est bien le principal reproche que l'on peut lui faire
        
        Donc tu fais le même reproche à cron et at ?
        
        « 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: Timers
        
        Posté par Domi le 23 mars 2014 à 15:51. Évalué à -7.
        
        Non, cron et at n'ont pas la prétention d'être universels.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Timers
        
        Posté par Juke (site web personnel) le 28 mars 2014 à 14:03. Évalué à 4.
        
        Non, cron et at n'ont pas la prétention d'être universels.
        
        Systemd non plus.
        
        [^] # Re: Timers
        
        Posté par Maclag le 23 mars 2014 à 13:59. Évalué à 3.
        
        Quoi?! Tu veux demandes aux dévs?? Et moi qui ai passé tous ces mois à chercher la syntaxe de systemctl pour que systemd se développe tout seul, tu veux dire que ça marche pas encore!?
        Y'a pas à chier, c'est clairement pas fini alors!!
        
        [^] # Re: Timers
        
        Posté par anaseto le 23 mars 2014 à 15:23. Évalué à 3.
        
        Et moi qui ai passé tous ces mois à chercher la syntaxe de systemctl pour que systemd se développe tout seul, tu veux dire que ça marche pas encore!?
        
        Peut-être qu'un bon début ce serait de s'orienter vers une approche du type Tomate, pour monitorer l'évolution des différents composants, puis implémenter ensuite un algo de simulation suffisamment réaliste, mais je sais pas si c'est facile à faire.
        
        PS: j'arrête là les histoires ridicules pour aujourd'hui, on est pas vendredi :)
        
        [^] # Re: Timers
        
        Posté par Reihar le 25 mars 2014 à 15:02. Évalué à 3.
        
        Voyons, c'est à systemd-networkd d'implémenter IPoT.
  - [^] # Re: Timers
    
    Posté par LupusMic (site web personnel, Mastodon) le 23 mars 2014 à 18:26. Évalué à 3.
    
    Tu peux tester avec ton PC en veille 30 jours pour voir ce que ça donne à son réveil ? :p
# Merci Lennart (and sinma)

Posté par Albert_ le 21 mars 2014 à 14:59. Évalué à 10.

Un vendredi ou nous n'avions pour ainsi dire aucun troll et voila que tombe du ciel un nouvelle sur Lennart, systemd et PA. Il ne manquait que avahi et cela aurait un combo total!
- [^] # Re: Merci Lennart (and sinma)
  
  Posté par devnewton 🍺 (site web personnel) le 21 mars 2014 à 17:04. Évalué à 4.
  
  Il y avait pourtant la sortie de java 8, mais personne n'a fait de nourjal.
  
  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
  - [^] # Re: Merci Lennart (and sinma)
    
    Posté par ariasuni le 21 mars 2014 à 17:07. Évalué à 5.
    
    En même temps les changements sont encore plus incompréhensibles que ceux de systemd! :p
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Merci Lennart (and sinma)
      
      Posté par reno le 21 mars 2014 à 17:35. Évalué à 4.
      
      Ton troll ne tient pas debout: Java plus simpliste comme langage, il n'y a pas..
      - [^] # Re: Merci Lennart (and sinma)
        
        Posté par Batchyx le 21 mars 2014 à 20:48. Évalué à 1.
        
        Est ce qu'on peut enfin créer un ArrayList avec des int à l'intérieur ?
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Sébastien Le Ray le 21 mars 2014 à 21:07. Évalué à 4.
        
        L'auto(un)boxing c'est java 5 hein
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par wismerhill le 22 mars 2014 à 10:18. Évalué à 1.
        
        Et c'est une belle saloperie!
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par reno le 24 mars 2014 à 10:40. Évalué à 7.
        
        Tu as oublié d'expliquer pourquoi..
- [^] # Re: Merci Lennart (and sinma)
  
  Posté par ariasuni le 21 mars 2014 à 17:22. Évalué à 8.
  
  Mouaif, pour l'instant personne n'a rebondit sur le fait que Lennart dit que GNOME a pris une mauvaise décision, sur le démarrage sans /etc/fstab, sur la dépendance à la pile de téléphonie IP, d-bus dans le noyau, etc.
  
  Et pas de commentaire sur les trucs intéressants pour l'utilisateur final (à savoir le rétablissement du bon niveau de luminosité ou de l'état des interrupteurs physiques par exemple), ou sur le nombre affolants de changements pour améliorer la sécurité, ou le nombre d'améliorations conséquents (voir hallucinant) pour faciliter l'écriture d'unités.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Merci Lennart (and sinma)
    
    Posté par freem le 21 mars 2014 à 22:26. Évalué à 2.
    
    Et pas de commentaire sur les trucs intéressants pour l'utilisateur final
    
    En même temps, systemd, c'est pas censé être une amélioration pour l'utisateur final… ( le vendredi, c'est permis, non? )
    
    Plus "sérieusement", j'ai réussi à me forcer à lire tout… jusqu'a la fin de la 1ère version ( par ordre d'apparition dans le nourjal). Après… TL;DR.
    Alors, c'est vrai qu'un bon troll de compèt n'a pas besoin de lire, mais tout le monde ne peux pas être expert.
  - [^] # Re: Merci Lennart (and sinma)
    
    Posté par Albert_ le 21 mars 2014 à 23:04. Évalué à 2.
    
    Pour ton premier paragraphe c'est trop gros a avaler meme un vendredi.
    
    Pour le debut du deuxieme, il utiliserait un vrai DE (commencant par K) et il n'aurait pas eu de probleme avec sa luminosite.
    - [^] # Re: Merci Lennart (and sinma)
      
      Posté par ariasuni le 21 mars 2014 à 23:16. Évalué à 1.
      
      J'utilise un vrai DE dont le nom commence par un K et j'ai des problèmes avec la luminosité (mais rassurez-vous, d'après les moteurs de recherche, le nombre de personnes qui ont également ce problème se comptent sur les doigts d'une main).
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Merci Lennart (and sinma)
        
        Posté par freem le 21 mars 2014 à 23:23. Évalué à 1.
        
        Si c'est un problème de visualisation, genre, luminosité trop faible/forte, xrandr pourrait vous aider.
        Ca n'est qu'une bidouille logicielle par contre donc pas sûr qu'une économie de batterie soit espérable. Enfin, faut voir la nature exacte du problème après j'imagine.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par ariasuni le 21 mars 2014 à 23:36. Évalué à 2.
        
        Quand j'augmente ou diminue la luminosité avec les touches de l'ordi, KDE crois que je suis toujours à l'ancienne luminosité.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par freem le 22 mars 2014 à 00:00. Évalué à 1.
        
        C'est à dire?
        L'écran conserve sa luminosité, alors que tu as appuyé sur les touches?
        Si c'est le cas, as-tu vérifié qu'il y a une action déclenchée par l'appui sur les touches en questions?
        A priori, sur mon netbook, c'est géré naturellement… c'est à dire que je ne sais pas du tout qui s'en charge. Probablement ACPI.
        
        En revanche, sur mes desktop, il m'arrive de le faire aussi. Là, bien entendu, il n'y a aucune touche clavier dédiée, donc j'ai du binder à une combo de touche l'option xrandr pour modifier la luminosité: brightness, si je ne m'abuse.
        
        Si tu sais comment marche l'ACPI sous linux, tu as le droit de m'indiquer ou trouver des docs faciles à comprendre pour les bases, sinon, tu peux peut-être jouer avec cette option de xrandr.
        Dans tous les cas, je suis surpris que systemd interfère avec ACPI…
        
        Ajouterais-tu de l'eau au moulin de ceux qui disent qu'a force de trop en faire, il ne fait rien correctement ? hinhinhin
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par ariasuni le 22 mars 2014 à 02:00. Évalué à 2.
        
        Quand je change la luminosité, dans le plasmoïde le niveau indiqué ne change.
        
        Je ne sais pas si ça a un rapport avec systemd.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Astaoth le 22 mars 2014 à 20:02. Évalué à 2.
        
        Si par "luminosité" vous parlez de la backlight des écrans d'ordis portables, de la doc peut être trouvée ici. Cela dit, contrairement à ce qui est dit sur le Wiki, on peut avoir à la fois un dossier intel_backlight et acpi_video0 avec une carte Intel. Les deux contiennent des fichiers gérant la backlight et peuvent faire effet. Cependant, les modification de la backlight dans le dossier acpi_video0 sont pris en compte dans le dossier intel_backlight, mais le contraire non.
        Si lors du réglage de la backlight le DE ne voit pas e différence de niveau, je dirais que c'est parce qu'il surveille le mauvais fichier.
        
        En revanche, la luminosité modifié par xrandr ne change pas la backlight, mais réellement la luminosité, en terme de couleurs.
        
        Emacs le fait depuis 30 ans.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par ariasuni le 22 mars 2014 à 21:17. Évalué à 2.
        
        Si par "luminosité" vous parlez de la backlight
        
        Bah si je le modifie avec les touches du clavier, il y a pas trente milles possibilités.
        
        de la doc peut être trouvée ici. Cela dit, contrairement à ce qui est dit sur le Wiki, on peut avoir à la fois un dossier intel_backlight et acpi_video0 avec une carte Intel. Les deux contiennent des fichiers gérant la backlight et peuvent faire effet. Cependant, les modification de la backlight dans le dossier acpi_video0 sont pris en compte dans le dossier intel_backlight, mais le contraire non.
        Si lors du réglage de la backlight le DE ne voit pas e différence de niveau, je dirais que c'est parce qu'il surveille le mauvais fichier.
        
        Merci pour ces infos, je jetteraient à nouveau un œil sur ce problème un peu plus tard.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par ariasuni le 23 mars 2014 à 18:48. Évalué à 2.
        
        Quand je modifie la luminosité avec xbacklight ça fonctionne correctement, je pense que KDE ne détecte pas le changement de luminosité parce qu’il vient du BIOS. Ou un truc comme ça.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par ariasuni le 24 mars 2014 à 01:35. Évalué à 3.
        
        Bon en fait c’est bien un problème de KDE parce que ça marche sous GNOME, et j’ai pu le régler en faisant (en root):
        
        sudo echo 'Y' > /sys/module/video/parameters/brightness_switch_enabled
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Albert_ le 22 mars 2014 à 08:39. Évalué à 2.
        
        "chez moi ca marche"
        
        Par contre cela marche 1000 food mieux sur un thinkpad que sur un dell ou le changement lague mais fonctionne, il faut juste être patient.
      - [^] # Re: Merci Lennart (and sinma)
        
        Posté par Domi le 23 mars 2014 à 14:23. Évalué à -4.
        
        C'est marrant, j'utilise un vrai DE dont le nom ne commence ni par K ni par G, je n'utilise pas non plus systemd, et je n'ai jamais eu de problème de luminosité, sauf une fois quand j'avais attendu que l'écran rende l'âme avant de le changer.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
  - [^] # Re: Merci Lennart (and sinma)
    
    Posté par Frédéric Massot (site web personnel) le 22 mars 2014 à 01:41. Évalué à 1.
    
    Tu as des liens sur Lennart et GNOME ?
    - [^] # Re: Merci Lennart (and sinma)
      
      Posté par Albert_ le 22 mars 2014 à 08:42. Évalué à -3.
      
      Chapeau rouge, les outils PA et avahi uniquement pour gnome, systemd en dependance de gnome…
      
      Clairement plus de relations avec gnome que xfce ou kde.
- [^] # Re: Merci Lennart (and sinma)
  
  Posté par Batchyx le 21 mars 2014 à 20:38. Évalué à 10.
  
  Le problème avec Avahi, c'est que Lennart l'a complètement abandonné, du jour au lendemain. Et toutes les assurances foireuses qu'on vendait aussi avec systemd du genre "mais oui si Lennart disparait il y aura d'autre mainteneur" n'ont pas tenu, parce qu'ils se sont tous barrés aussi.
  
  Alors du coup on peut pas faire de news dessus, c'est pas drôle.
  - [^] # Re: Merci Lennart (and sinma)
    
    Posté par Albert_ le 21 mars 2014 à 23:01. Évalué à 1.
    
    Ouhais mais le plus drole c'est que c'est, en tout cas sur ubuntu, une dependance de cups…
    - [^] # Re: Merci Lennart (and sinma)
      
      Posté par Batchyx le 21 mars 2014 à 23:23. Évalué à 2.
      
      Je vois pas en quoi c'est choquant, beaucoup d'imprimantes réseaux s'annoncent via mDNS, et c'est pratique comme fonctionnalité à utiliser. Si tu a une autre implémentation d'mDNS, tu peux la proposer à cups.
      
      Et puis bon, cups ne dépend pas du démon Avahi, mais uniquement de ses bibliothèques mal foutues et pas très utiles qui servent juste à masquer une API D-Bus absolument horrible.
      - [^] # Re: Merci Lennart (and sinma)
        
        Posté par freem le 21 mars 2014 à 23:25. Évalué à 1.
        
        Le problème, c'est que cups ne gère pas que les imprimantes réseau.
        Et que la majorité des utilisateurs n'ont pas d'imprimante réseau: la majorité des utilisateurs de PC ( pas de linux, ceci dit, j'imagine ) ne sont pas des entreprises, mais des particuliers. Donc, pas d'imprimantes réseau, si je ne m'abuse.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par claudex le 22 mars 2014 à 09:35. Évalué à 4.
        
        Dans ce cas, plains toi à ta distribution, chez Debian, par exemple, avahi est une recommandation, pas une dépendance https://packages.debian.org/wheezy/cups
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Donk le 22 mars 2014 à 11:27. Évalué à 1.
        
        Chez Ubuntu aussi
        
        http://packages.ubuntu.com/precise-updates/cups
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Albert_ le 22 mars 2014 à 14:36. Évalué à 3.
        
        tente donc de faire un:
        
        apt-get remove avahi-daemon
        
        chez moi ca done:
        
        > sudo apt-get remove avahi-daemon Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : python-avahi python-gdbm Veuillez utiliser « apt-get autoremove » pour les supprimer. Les paquets suivants seront ENLEVÉS : avahi-daemon avahi-discover avahi-utils bluez-cups cups cups-browsed cups-daemon hplip libnss-mdns printer-driver-gutenprint printer-driver-hpcups printer-driver-postscript-hp pulseaudio-module-zeroconf telepathy-salut
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par xcomcmdr le 22 mars 2014 à 15:00. Évalué à 2.
        
        Sous Arch, c'est très "rigolo" :
        
        max-laptop% sudo pacman -Rsnc avahi
        [sudo] password for max:
        vérification des dépendances…
        :: ffmpegthumbnailer peut nécessiter gvfs: support for gio uris
        :: git peut nécessiter gnome-keyring: GNOME keyring credential helper
        :: gnupg peut nécessiter libusb-compat: scdaemon
        :: htop peut nécessiter lsof: show files opened by a process
        :: imagemagick peut nécessiter ghostscript: for Ghostscript support
        :: imagemagick peut nécessiter libwmf: for WMF support
        :: imagemagick peut nécessiter librsvg: for SVG support
        :: jdownloader peut nécessiter libnotify: notification support
        :: jre7-openjdk peut nécessiter gtk2: for the Gtk+ look and feel - desktop usage
        :: jre7-openjdk-headless peut nécessiter libcups: needed for Java Mauve support - libmawt.so
        :: lib32-alsa-plugins peut nécessiter lib32-jack: Jack plugin
        :: lib32-alsa-plugins peut nécessiter lib32-libsamplerate: libsamplerate resampling plugin
        :: libpulse peut nécessiter avahi: zeroconf support
        :: libsidplayfp peut nécessiter vice: better SID support
        :: mjpegtools peut nécessiter gtk2: glav GUI
        :: netctl peut nécessiter ppp: for pppoe connections
        :: networkmanager peut nécessiter bluez: Bluetooth support
        :: networkmanager peut nécessiter ppp: Dialup connection support
        :: nvidia-utils peut nécessiter gtk2: nvidia-settings
        :: pinentry peut nécessiter gtk2: for gtk2 backend
        :: pulseaudio peut nécessiter pulseaudio-alsa: ALSA configuration (recommended)
        :: pulseaudio peut nécessiter avahi: zeroconf publishing and discovery
        :: pulseaudio peut nécessiter bluez: Bluetooth
        :: pulseaudio peut nécessiter gconf: paprefs configuration
        :: pulseaudio peut nécessiter lirc-utils: IR control
        :: qt4 peut nécessiter libmariadbclient: MariaDB driver
        :: qt5-base peut nécessiter libmariadbclient: MariaDB driver
        :: subversion peut nécessiter libgnome-keyring: for GNOME Keyring for auth credentials
        :: timidity++ peut nécessiter gtk2: for using the GTK+ interface
        :: tumbler peut nécessiter poppler-glib: for PDF thumbnails
        :: udisks2 peut nécessiter parted: partition management
        :: virtualbox peut nécessiter net-tools: Host-only or bridged networking support
        :: wine peut nécessiter lib32-libldap
        :: wine peut nécessiter lib32-libxml2
        :: wine peut nécessiter lib32-libxcomposite
        :: wine peut nécessiter cups
        :: wine peut nécessiter samba
        :: xdg-utils peut nécessiter kdebase-runtime: for KDE support in xdg-open
        :: xdg-utils peut nécessiter exo: for Xfce support in xdg-open
        
        Paquets (491): aalib-1.4rc5-10 accountsservice-0.6.35-2 akonadi-1.11.0-1
        arandr-0.1.7.1-2 at-spi2-atk-2.10.2-1 at-spi2-core-2.10.2-1
        atkmm-2.22.7-1 audacious-3.4.3-1 audacious-plugins-3.4.3-2
        audacity-2.0.5-2 audio-convert-0.3.1.1-7 audit-2.3.2-3
        babl-0.1.10-1 bc-1.06.95-1 bluez-5.16-1 cairomm-1.10.0-3
        cheese-3.10.2-2 cifs-utils-6.2-1 classpath-0.98-7 cln-1.3.3-2
        clucene-2.3.3.4-8 clutter-1.16.4-3 clutter-gst-2.0.10-1
        clutter-gtk-1.4.4-4 codeblocks-13.12-2 cogl-1.16.2-1
        colord-1.0.6-1 colord-gtk-0.1.25-1 convertlit-1.8-6
        cups-1.7.1-4 cups-filters-1.0.48-1 cups-pk-helper-0.2.5-1
        dconf-0.18.0-1 desmume-0.9.10-2 desura-1-19 devede-3.23.0-1
        djvulibre-3.5.25.3-1 dolphin-emu-1:4.0.2-4 dvdauthor-0.7.1-7
        ebook-tools-0.2.2-1 evince-3.10.3-1 exempi-2.2.1-2
        exo-0.10.2-2 farstream-0.2.3-1 farstream-0.1-0.1.2-3
        fceux-2.2.2-1 ffmpeg-compat-1:0.10.11-1 file-roller-3.10.2.1-1
        filezilla-3.7.4.1-1 firefox-28.0-1 firefox-i18n-fr-28.0-1
        flashplugin-11.2.202.346-1 freerdp-1.0.2-4
        frei0r-plugins-1.4-1 gamin-0.1.10-8 gavl-1.4.0-1
        gcdemu-2.1.1-1 gconf-3.2.6-3 gconf-editor-3.0.1-3
        gconf-sharp-2.24.2-3 gconfmm-2.28.3-1 gcr-3.10.1-3 gd-2.1.0-2
        gdb-7.7-1 gdl-3.10.0-1 gdlmm-3.7.3-1 geany-1.23.1-1
        gegl-0.2.0-10 gens-gs-2.16.7-4 geoclue-0.12.99-1
        geoclue2-2.0.0-1 geocode-glib-3.10.0-1 ghex-3.10.0-1
        ghostscript-9.10-3 gimp-2.8.10-1 gksu-2.0.2-4 glibmm-2.38.1-1
        gnome-bluetooth-3.10.0-1 gnome-calculator-3.10.2-1
        gnome-color-manager-3.10.1-2 gnome-control-center-3.10.2-2
        gnome-desktop-1:3.10.2-1 gnome-disk-utility-3.10.0-1
        gnome-icon-theme-3.10.0-1 gnome-icon-theme-symbolic-3.10.1-1
        gnome-keyring-3.10.1-2 gnome-menus-3.10.1-1
        gnome-online-accounts-3.10.2-1 gnome-screensaver-3.6.1-7
        gnome-search-tool-3.6.0-2 gnome-settings-daemon-3.10.2-3
        gnome-subtitles-1.3-1 gnome-system-monitor-3.10.2-1
        gnome-video-effects-0.4.0-2 gobject-introspection-1.38.0-1
        gparted-0.18.0-1 gperf-3.0.4-4 gsfonts-1.0.7pre44-4
        gst-plugins-good-1.2.3-2 gstreamer0.10-bad-0.10.23-8
        gstreamer0.10-bad-plugins-0.10.23-8
        gstreamer0.10-ffmpeg-0.10.13-2 gstreamer0.10-good-0.10.31-5
        gtk-aurora-engine-1.5.1-3 gtk-engine-murrine-0.98.2-1
        gtk-engine-unico-1.0.2-3 gtk-engines-2.21.0-1
        gtk-recordmydesktop-0.3.8-6 gtk-sharp-2-2.12.22-1
        gtk-vnc-0.5.3-3 gtk2-2.24.22-1 gtk2-xfce-engine-3.0.1-1
        gtk3-3.10.7-1 gtk3-xfce-engine-3.0.1-1 gtkglext-1.2.0-9
        gtkmm-2.24.4-1 gtkmm3-3.10.1-1 gtksourceview2-2.10.5-2
        gtksourceview3-3.10.2-1 gtksourceviewmm-3.2.0-4
        gtkspell-2.0.16-3 gucharmap-3.10.1-1 gufw-14.04.1-1
        gvfs-1.18.3-3 gvfs-afc-1.18.3-3 gvfs-afp-1.18.3-3
        gvfs-gphoto2-1.18.3-3 gvfs-mtp-1.18.3-3 gvfs-smb-1.18.3-3
        handbrake-0.9.9-5 harfbuzz-icu-0.9.26-1 hyphen-2.8.6-1
        icon-naming-utils-0.8.90-2 imlib2-1.4.6-1 iniparser-3.1-4
        intel-tbb-4.2_20131118-1 iso-codes-3.44-1 json-glib-0.16.2-1
        k3b-2.0.2-9 kactivities-4.12.3-1 kde-base-artwork-4.12.3-1
        kdebase-keditbookmarks-4.12.3-1 kdebase-runtime-4.12.3-1
        kdebase-workspace-4.11.7-2 kdegraphics-mobipocket-4.12.3-1
        kdenetwork-krdc-4.12.3-1 kdenlive-0.9.6-4
        kdepim-runtime-4.12.3-1 kdepimlibs-4.12.3-1
        kdesdk-thumbnailers-4.12.3-1 kega-fusion-3.63-16 ladspa-1.13-4
        lcms-1.19-5 ldb-1.1.16-1 lib32-atk-2.10.0-1
        lib32-cairo-1.12.16-1 lib32-curl-7.35.0-1 lib32-db-5.3.28-1
        lib32-e2fsprogs-1.42.9-1 lib32-flashplugin-11.2.202.346-1
        lib32-gdk-pixbuf2-2.30.6-1 lib32-glew-1.10.0-1
        lib32-gstreamer0.10-0.10.36-2
        lib32-gstreamer0.10-base-0.10.36-5 lib32-gtk2-2.24.22-1
        lib32-jack-0.124.1-1 lib32-keyutils-1.5.8-1
        lib32-krb5-1.12.1-1 lib32-libaio-0.3.109-6
        lib32-libcanberra-0.30-4 lib32-libcups-1.7.1-1
        lib32-libldap-2.4.39-1 lib32-libltdl-2.4.2-12
        lib32-libsamplerate-0.1.8-1 lib32-libssh2-1.4.3-1
        lib32-libtiff-4.0.3-2 lib32-libxcomposite-0.4.4-1
        lib32-libxml2-2.9.1-1 lib32-libxmu-1.1.2-1 lib32-libxt-1.1.4-1
        lib32-nspr-4.10.3-1 lib32-nss-3.15.4-1
        lib32-nvidia-cg-toolkit-3.1-4 lib32-openssl-1.0.1.f-1
        lib32-orc-0.4.18-1 lib32-pango-1.36.2-1 lib32-pixman-0.32.4-1
        lib32-portaudio-19_20140130-1 lib32-readline-6.3.000-1
        lib32-soundtouch-1.7.1-2 lib32-sqlite-3.8.4.1-1
        lib32-tdb-1.2.12-1 lib32-wxgtk2.8-2.8.12.1-2
        libart-lgpl-2.3.21-3 libavc1394-0.5.4-2 libbsd-0.6.0-2
        libburn-1.3.6.pl01-1 libcaca-0.99.beta18-2 libcanberra-0.30-4
        libcanberra-pulse-0.30-4 libcdaudio-0.99.12-7
        libcdio-paranoia-10.2+0.90+1-2 libcroco-0.6.8-1
        libcups-1.7.1-4 libdaemon-0.14-2 libdc1394-2.2.1-2
        libdmtx-0.7.4-5 libetonyek-0.0.3-1 libevdev-1.0.1-1
        libevent-2.0.21-3 libexif-0.6.21-2 libftdi-compat-0.20-1
        libgdiplus-2.10.9-3 libgee-0.12.0-1 libgexiv2-0.7.0-2
        libgksu-2.0.12-5 libglade-2.6.4-5 libglademm-2.6.7-2
        libgnome-keyring-3.10.1-2 libgnomecanvas-2.30.3-2
        libgnomecanvasmm-2.26.0-2 libgnomekbd-3.6.0-2
        libgphoto2-2.5.3.1-2 libgtop-2.28.5-1 libguess-1.1-2
        libgusb-0.1.6-1 libgweather-3.10.2-1 libgxps-0.2.2-3
        libibus-1.5.6-1 libical-1.0-3 libid3tag-0.15.1b-8
        libidl2-0.8.14-3 libiec61883-1.2.0-4 libirman-0.4.5-3
        libisofs-1.3.6-1 libjpeg6-6b1-2 libkcddb-4.12.3-1
        libkeybinder2-0.3.0-1 libkfbapi-1.0-1 libkgapi-2.1.0-1
        libkolab-0.5.0-1 libkolabxml-1.0.1-1 liblrdf-0.5.0-2
        libmariadbclient-5.5.36-1 libmbim-1.8.0-1 libmowgli-2.0.0-2
        libmpcdec-1.2.6-3 libmpd-11.8.17-2 libmtp-1.1.6-6
        libmusicbrainz5-5.0.1-1 libnautilus-extension-3.10.1-1
        libnet-1.1.6-2 libnewt-0.52.17-1 libnice-0.1.4-1
        libnotify-0.7.6-1 libodfgen-0.0.4-1 libpaper-1.1.24-7
        libpng12-1.2.51-1 libpurple-2.10.9-1 libpwquality-1.2.3-1
        libqalculate-0.9.7-4 libqmi-1.8.0-1 libraw-0.16.0-1
        libraw1394-2.1.0-2 libreoffice-af-4.2.2-1
        libreoffice-calc-4.2.2-2 libreoffice-common-4.2.2-2
        libreoffice-extension-grammalecte-fr-0.3.6.2-1
        libreoffice-gnome-4.2.2-2 libreoffice-impress-4.2.2-2
        libreoffice-kde4-4.2.2-2 libreoffice-sdk-4.2.2-2
        libreoffice-sdk-doc-4.2.2-2 libreoffice-writer-4.2.2-2
        librsvg-1:2.40.1-3 libsecret-0.16-2 libshout-1:2.3.1-2
        libsigc++-2.3.1-1 libspectre-0.2.7-1 libspiro-20071029-3
        libssh-0.5.5-3 libtracker-sparql-0.16.4-1 libunique-1.1.6-6
        libusb-compat-0.1.5-1 libuser-0.59-2 libvirt-1.2.2-1
        libvirt-glib-0.1.7-2 libvirt-python-1.2.1-1 libvisio-0.0.31-2
        libwacom-0.9-1 libwbclient-4.1.6-1 libwmf-0.2.8.4-12
        libwnck-2.30.7-1 libwpd-0.9.9-1 libwpg-0.2.2-2 libwps-0.2.9-1
        libxfce4ui-4.10.0-1 libxfcegui4-4.10.0-1 libxklavier-5.3-1
        libxres-1.0.7-1 libzip-0.11.2-1 lirc-utils-1:0.9.0-70
        lm_sensors-3.3.5-1 lpsolve-5.5.2.0-2 lsb-release-1.4-14
        lsof-4.87-2 mariadb-5.5.36-1 mariadb-clients-5.5.36-1
        mash-0.2.0-3 mencoder-36498-5 mime-types-9-1 miniupnpc-1.9-1
        mkvtoolnix-gtk-6.8.0-1 mlt-0.9.0-5
        mobile-broadband-provider-info-20120614-2 modemmanager-1.2.0-3
        mono-3.2.8-1 mono-addins-0.6.2-3 mousepad-0.3.0-2
        mozilla-common-1.4-3 mplayer-36498-5 musicbrainz-2.1.5-6
        nautilus-3.10.1-1 nautilus-sendto-3.8.1-1 nemiver-0.9.5-1
        nepomuk-core-4.12.3-1 nestopia-1.45-1
        net-tools-1.60.20130531git-1 network-manager-applet-0.9.8.8-1
        newt-syrup-0.1.2-2 numactl-2.0.9-2 nvidia-cg-toolkit-3.1-2
        ogmrip-1.0.0-3 openbsd-netcat-1.105_7-6 opencv-2.4.8-1
        orage-4.10.0-1 orbit2-2.14.19-3 oxygen-icons-4.12.3-1
        p7zip-9.20.1-9 pangomm-2.34.0-1 pangox-compat-0.0.2-1
        paprefs-0.9.10-2 parole-0.5.4-1 parted-3.1-4
        pavucontrol-2.0-2 pcsx2-1.2.2-2 pcsxr-1.9.93-3
        perl-xml-simple-2.20-1 pidgin-2.10.9-1 pinta-1.4-1
        pnmixer-xfce4-3-1 polkit-gnome-0.105-2 polkit-kde-0.99.0-2
        poppler-0.24.5-1 poppler-glib-0.24.5-1 poppler-qt4-0.24.5-1
        portaudio-19_20140130-1 ppp-2.4.6-2 prison-1.1.0-1
        pulseaudio-alsa-2-2 pycups-1.9.66-1 pygobject-devel-3.10.2-1
        pygobject2-devel-2.28.6-9 pygtk-2.24.0-3 pysmbc-1.0.13-2
        python2-beaker-1.6.4-1 python2-cairo-1.10.0-1
        python2-gconf-2.28.1-8 python2-gobject-3.10.2-1
        python2-gobject2-2.28.6-9 python2-ipaddr-2.1.11-1
        python2-ipy-0.81-1 python2-mako-0.9.1-1
        python2-markupsafe-0.19-1 python2-netifaces-0.8-2
        python2-notify-0.1.1-12 python2-pycurl-7.19.3.1-1
        qimageblitz-0.0.6-3 qjson-0.8.1-2 qpdf-5.1.1-1
        qrencode-3.4.3-1 recordmydesktop-0.3.8.1-6 rest-0.7.90-2
        ristretto-0.6.3-3 ruby-atk-2.1.0-2 ruby-cairo-1.12.8-1
        ruby-gdkpixbuf2-2.1.0-2 ruby-glib2-2.1.0-2 ruby-gtk2-2.1.0-2
        ruby-iconv-1.0.4-2 ruby-pango-2.1.0-2 rubyripper-0.6.2-5
        samba-4.1.6-1 sg3_utils-1.37-1 shared-color-profiles-0.1.5-1
        shared-color-targets-0.1.2-1 shotwell-0.18.0-1 slang-2.2.4-3
        smbclient-4.1.6-1 smplayer-0.8.6-1
        sound-theme-freedesktop-0.8-1 sox-14.4.1-4 spice-gtk3-0.23-1
        startup-notification-0.12-4 steam-1.0.0.47-1
        system-config-printer-1.4.3-2 systemd-ui-2-2 t1lib-5.1.2-5
        taglib-1.9.1-1 talloc-2.1.0-1 telepathy-farstream-0.6.0-1
        telepathy-glib-0.22.1-1 telepathy-qt-0.9.3-7 tevent-0.9.21-2
        thunar-1.6.3-1 thunar-archive-plugin-0.3.1-3
        thunar-media-tags-plugin-0.2.1-1 thunar-volman-0.8.0-1
        thunderbird-24.4.0-1 thunderbird-i18n-fr-24.4.0-1
        transmission-gtk-2.82-1 udisks-1.0.5-1 ufw-0.33-3
        urlgrabber-3.10.1-2 vcdimager-0.7.24-5 vice-2.4-5
        virt-manager-1.0.0-2 vte-0.28.2-3 vte-common-0.34.9-1
        vte3-0.34.9-1 wavpack-4.70.0-2 webkitgtk-2.2.5-2
        wxgtk-3.0.0-2 wxgtk2.8-2.8.12.1-1 wxgtk2.9-2.9.5-1
        x11-ssh-askpass-1.2.4.1-4 xcb-util-renderutil-0.3.8-1
        xerces-c-3.1.1-5 xfburn-0.5.0-1
        xfce-theme-albatross-git-1.5_19_g38617a1-1
        xfce4-appfinder-4.10.1-1 xfce4-battery-plugin-1.0.5-1
        xfce4-clipman-plugin-1.2.4-1 xfce4-cpufreq-plugin-1.1.0-1
        xfce4-cpugraph-plugin-1.0.5-1 xfce4-datetime-plugin-0.6.2-1
        xfce4-dict-0.7.0-1 xfce4-diskperf-plugin-2.5.4-1
        xfce4-embed-plugin-1.2.0-1 xfce4-eyes-plugin-4.4.2-1
        xfce4-fsguard-plugin-1.0.1-1 xfce4-genmon-plugin-3.4.0-1
        xfce4-hardware-monitor-applet-git-1.4.4.r53.4f7535e-1
        xfce4-mailwatch-plugin-1.2.0-2 xfce4-mixer-4.10.0-2
        xfce4-mount-plugin-0.6.4-1 xfce4-mpc-plugin-0.4.4-1
        xfce4-netload-plugin-1.2.0-1 xfce4-notes-plugin-1.7.7-4
        xfce4-notifyd-0.2.4-1 xfce4-panel-4.10.1-1
        xfce4-places-plugin-1.6.0-1 xfce4-power-manager-1.2.0-6
        xfce4-quicklauncher-plugin-1.9.4-7 xfce4-screenshooter-1.8.1-1
        xfce4-sensors-plugin-1.2.5-1 xfce4-session-4.10.1-3
        xfce4-settings-4.10.1-1 xfce4-smartbookmark-plugin-0.4.5-1
        xfce4-soundmenu-plugin-0.4.10-1 xfce4-systemload-plugin-1.1.1-1
        xfce4-terminal-0.6.3-1 xfce4-time-out-plugin-1.0.1-2
        xfce4-timer-plugin-1.0.0-1 xfce4-verve-plugin-1.0.0-3
        xfce4-volumed-pulse-0.2.0-3 xfce4-wavelan-plugin-0.5.11-1
        xfce4-weather-plugin-0.8.3-3
        xfce4-whiskermenu-plugin-git-1.3.0.14.gf44af50-1
        xfce4-xkb-plugin-0.5.6-1 xfdesktop-4.10.2-1 xfwm4-4.10.1-1
        xfwm4-themes-4.10.0-1 xine-lib-1.2.4-3 xorg-utils-7.6-8
        xorg-xinit-1.3.3-3 xorg-xmessage-1.0.4-1 zenity-3.10.2-1
        zip-3.0-3 zziplib-0.13.62-2 avahi-0.6.31-11
        
        Taille totale supprimé : 3140,21 MiB
        
        :: Voulez-vous désinstaller ces paquets ? [O/n] ^C
        Interrupt signal received
        
        max-laptop% sudo pacman -Rs avahi
        
        vérification des dépendances…
        erreur : la préparation de la transaction a échoué (la satisfaction des dépendances a échoué)
        :: gvfs : requiert avahi
        :: libcups : requiert avahi
        :: libvirt : requiert avahi
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par xcomcmdr le 22 mars 2014 à 15:25. Évalué à 2.
        
        Ah, avec un -Rdd ça passe mieux :
        
        max-laptop% sudo pacman -Rdd avahi
        [sudo] password for max:
        :: libpulse peut nécessiter avahi: zeroconf support
        :: libpurple peut nécessiter avahi: Bonjour protocol support
        :: pulseaudio peut nécessiter avahi: zeroconf publishing and discovery
        
        Paquets (1): avahi-0.6.31-11
        
        Taille totale supprimé : 1,88 MiB
        
        :: Voulez-vous désinstaller ces paquets ? [O/n]
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Donk le 22 mars 2014 à 16:47. Évalué à 2.
        
        ~$ sudo apt-get remove avahi-daemon Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants seront ENLEVÉS : avahi-daemon avahi-utils libnss-mdns telepathy-salut 0 mis à jour, 0 nouvellement installés, 4 à enlever et 0 non mis à jour.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par claudex le 22 mars 2014 à 17:01. Évalué à 3.
        
        Je confirme, j'ai installé ubuntu dans une vm, installé cups. Et en tentant de supprimer avahi :
        
        xavier@ubuntu:~$ dpkg -l|grep cups ii cups 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - server ii cups-client 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - client programs (SysV) ii cups-common 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - common files ii cups-filters 1.0.18-0ubuntu0.2 OpenPrinting CUPS Filters ii cups-ppdc 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - PPD manipulation utilities ii ghostscript-cups 9.05~dfsg-0ubuntu4.2 interpreter for the PostScript language and for PDF - CUPS filters ii libcups2 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - Core library ii libcupscgi1 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - CGI library ii libcupsfilters1 1.0.18-0ubuntu0.2 OpenPrinting CUPS Filters - Shared library ii libcupsimage2 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - Raster image library ii libcupsmime1 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - MIME library ii libcupsppdc1 1.5.3-0ubuntu8 Common UNIX Printing System(tm) - PPD manipulation library xavier@ubuntu:~$ sudo apt-get remove avahi-daemon [sudo] password for xavier: Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: avahi-daemon libnss-mdns 0 upgraded, 0 newly installed, 2 to remove and 14 not upgraded. After this operation, 470 kB disk space will be freed. Do you want to continue [Y/n]?
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Batchyx le 22 mars 2014 à 18:51. Évalué à 2.
        
        Dans ce cas là, c'est toute la fonctionnalité "imprimer sur une imprimante réseau" qui est inutile pour toi. Le fait qu'il y ai de la découverte via mDNS, via du cups en broadcast ou via de la découverte maison spécifique à une imprimante n'est qu'un dommage collatéral.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Domi le 23 mars 2014 à 14:26. Évalué à -1.
        
        La majorité des imprimantes d'aujourd'hui sont des imprimantes réseaux, et ceci depuis plusieurs années. Donc de plus en plus de particuliers ont des imprimantes réseaux.
        
        Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par claudex le 23 mars 2014 à 14:42. Évalué à 3.
        
        Je n'ai jamais vu d'imprimante réseau chez un particulier qui n'était pas très geek, donc ça m'étonnerait que la majorité soit des imprimantes réseaux.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par gnx le 23 mars 2014 à 17:52. Évalué à 6.
        
        La plupart des imprimantes grand public ont depuis quelques temps le Wi-Fi, donc sont des imprimantes réseaux.
      - [^] # Re: Merci Lennart (and sinma)
        
        Posté par Albert_ le 22 mars 2014 à 00:10. Évalué à 3.
        
        C'est absolument horripilant quanf tu es au boulot, qu'il y a des utilisateurs mac autour avec leur bonjour et que tu te retrouves avec plein d'imprimantes inutile et que tu ne peux pas forcement utilise. C'est encore plus genant quand le systeme d'impression est centralise et que tu doives utilise une queue d'impression avec un login bien particulier. Tout le monde met le nom conseille par les IT et du coup tu sais jamais si l'imprimante que tu as utilise c'est celle que tu as configure toi. Enfin si la solution apres avoir chercher a comprendre pourquoi nous recevions les impressions de quelqu'un d'autre et inversement.
        
        Tres tres chiant! Il existe deux solutions: virer ce truc inutile qu'est avahi et/ou donner un autre nom a la queue.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Batchyx le 22 mars 2014 à 17:40. Évalué à 2.
        
        C'est absolument horripilant quanf tu es au boulot, qu'il y a des utilisateurs mac autour avec leur bonjour et que tu te retrouves avec plein d'imprimantes inutile et que tu ne peux pas forcement utilise.
        
        Mauvais administrateurs, changer administrateurs. Si l'imprimante n'est pas utilisable out of the box, faut pas l'annoncer via mDNS.
        
        C'est encore plus genant quand le systeme d'impression est centralise et que tu doives utilise une queue d'impression avec un login bien particulier.
        
        Dans ce cas là, tu n'a pas besoin d'un démon cups local. Tu pointe juste ton client cups vers ton serveur central et puis c'est tout. C'est bien plus simple que de gérer un démon cups local qui rebalance sur un distant.
        
        Tout le monde met le nom conseille par les IT et du coup tu sais jamais si l'imprimante que tu as utilise c'est celle que tu as configure toi.
        
        Gné ?
        
        Tres tres chiant! Il existe deux solutions: virer ce truc inutile qu'est avahi […]
        
        Tu sais, tu peux aussi désactiver l'utilisation d'mDNS dans la conf de cups. Mais si tu n'a pas du tout besoin d'avahi, tu peux aussi le virer, pas comme Systemd.
        
        [^] # Re: Merci Lennart (and sinma)
        
        Posté par Misc (site web personnel) le 23 mars 2014 à 14:25. Évalué à 4.
        
        Tres tres chiant! Il existe deux solutions: virer ce truc
        inutile qu'est avahi et/ou donner un autre nom a la queue.
        
        Virer les macs est aussi une solution…
    - [^] # Re: Merci Lennart (and sinma)
      
      Posté par ariasuni le 21 mars 2014 à 23:28. Évalué à 2.
      
      Pas sur Arch Linux visiblement.
      
      Écrit en Bépo selon l’orthographe de 1990
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 24 mars 2014 à 15:16. Évalué à 0.
  
  Ce commentaire a été supprimé par l’équipe de modération.
# systemctl --user import-environment

Posté par Sylvain Blandel le 21 mars 2014 à 15:21. Évalué à 6.
Les sessions utilisateurs de systemd gagnent également la commande import-environment :
```
$ systemctl --user import-environment
```
systemctl gained a new "import-environment" command which uploads the caller's environment (or parts thereof) into the service manager so that it is inherited by services started by the manager. This is useful to upload variables like $DISPLAY into the user service manager. (notes de publication de systemd 209)

Je poste ce message depuis Firefox démarré par ma session utilisateur de systemd !
- [^] # Re: systemctl --user import-environment
  
  Posté par ariasuni le 21 mars 2014 à 15:42. Évalué à 3.
  
  Oui j'ai pas tout traduit, quand c'était vraiment trop technique et/ou que ça ne me semblait pas très intéressant.
  
  Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: systemctl --user import-environment
  
  Posté par Yamakaky le 21 mars 2014 à 18:33. Évalué à 3.
  
  Simpa ! J'avais essayé de faire fonctionner xorg avec systemd il y a bien 6 mois, mais ce fut un cuisant échec. Quelle technique utilises-tu ?
  - [^] # Re: systemctl --user import-environment
    
    Posté par Sylvain Blandel le 25 mars 2014 à 19:50. Évalué à 5.
    Quelle technique utilises-tu ?
    
    Pour avoir Firefox démarré par ma session utilisateur de systemd, j'ai crée le fichier /home/moi/.config/systemd/user/firefox.service dont voici le contenu :
```
[Unit]
Description=Firefox dans ma session utilisateur

[Service]
ExecStart=/usr/bin/firefox
Type=simple
```
    Ensuite, je me connecte graphiquement. Et en tant qu'utilisateur, je fais :
    systemctl --user import-environment systemctl --user start firefox.service
    Remarque : la commande systemctl --user daemon-reload peut servir si on modifie les fichiers .service de l'utilisateur.
    
    Simpa ! J'avais essayé de faire fonctionner xorg avec systemd il y a bien 6 mois, mais ce fut un cuisant échec.
    
    Le contenu de cette page devrait te plaire. :-)
    - [^] # Re: systemctl --user import-environment
      
      Posté par Moonz le 26 mars 2014 à 11:03. Évalué à 7.
      
      Par curiosité, c’est quoi l’intérêt de lancer Firefox avec systemd ?
      - [^] # Intérêt des sessions utilisateurs
        
        Posté par Sylvain Blandel le 27 mars 2014 à 18:57. Évalué à 4.
        
        Par curiosité, c’est quoi l’intérêt de lancer Firefox avec systemd ?
        
        Pour Firefox, euh … Je ne sais pas :o)
        
        Firefox n'est qu'un exemple de logiciel lancé par l'utilisateur (plutôt que par root). L'intérêt des sessions utilisateurs de systemd est d'imposer des conditions et contraintes aux logiciels, même lorsqu'ils sont lancés par l'utilisateur. Malheureusement, plusieurs options intéressantes fonctionnent avec les services lancés par root, mais pas avec les services lancés par l'utilisateur :-(
        
        Voici un service que fonctionne, même lorsqu'il est lancé par l'utilisateur :
        $ cat /home/moi/.config/systemd/user/essai.service
        
        [Unit]
        Description=essai dans la session utilisateur de moi
        ConditionPathExists=/tmp/machin
        ConditionACPower=true
        
        [Service]
        ExecStart=/usr/bin/chmurck
        Nice=14
        IOSchedulingClass=idle
        WorkingDirectory=/tmp/bac-a-sable
        Type=simple
        Environment="VAR1=word1 word2"
        StandardOutput=syslog
        Restart=always
        
        Le nom de chaque option est un lien vers la section adéquate du manuel.
        
        Je n'ai pas d'exemple en tête où ces options seraient pertinentes. Des idées ?
        
        [^] # Re: Intérêt des sessions utilisateurs
        
        Posté par claudex le 28 mars 2014 à 10:48. Évalué à 8.
        
        Pouvoir lancer les « services » de sessions (comme owncloud, le gestionnaire de torrent…) avec des politique d'io ou de cpu particulière me parait intéressant. Ou couper l'indexeur de fichier quand le portable est sur batterie.
        
        « 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
# Debian

Posté par claudex le 21 mars 2014 à 15:29. Évalué à 6.

Et pendant ce temps, Debian en est toujours à systemd 204.

« 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: Debian
  
  Posté par Benoît Sibaud (site web personnel) le 21 mars 2014 à 16:48. Évalué à 7.
  Actuellement il y a 11 architectures supportant systemd 44 et seulement 8 supportant systemd 204 en wheezy/stable (et en jessie/testing). En sid/unstable il y a 16 architectures supportant systemd 204 et encore une (inexistante en stable/testing) bloquée en systemd 44. J'imagine que cela explique une partie du problème du retard de versions. Sans parler d'une faille de sécu restante :
```
Bug jessie  sid wheezy  Description
CVE-2013-4392   vulnerable  vulnerable  fixed   systemd, when updating file permissions, allows local users to change ...
```
- [^] # Re: Debian
  
  Posté par freem le 21 mars 2014 à 22:27. Évalué à 1.
  
  C'est normal.
  Après tout, Debian vise la stabilité, et, même s'ils ont accepté de passer à systemd, ils ne vont pas mettre à jour la stable à chaque version de build, qui apporte manifestement autant de bugfix que de ~~nouveaux bugs~~ nouvelles fonctionnalités.
  
  ( vous m'avez pourri mon dredi à pas troller pendant mes 7H… alors je me dévoue un peu )
  - [^] # Re: Debian
    
    Posté par claudex le 21 mars 2014 à 22:56. Évalué à 3.
    
    Je ne parlais pas de la stable (qui est en version 44) mais de testing et de unstable qui sont recevoir recevoir des nouvelles versions.
    
    « 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: Debian
      
      Posté par Albert_ le 21 mars 2014 à 23:05. Évalué à 0.
      
      euh si cela ne supporte pas les architectures de debian meme en testing ou unstable ca va pas le faire.
    - [^] # Re: Debian
      
      Posté par freem le 21 mars 2014 à 23:18. Évalué à 2.
      
      Non, testing n'est pas censé recevoir les dernières nouveautés. Testing, c'est la beta, après tout.
      
      Au fait, quelqu'un sait comment sont incrémentés ces numéros de version?
      Je n'arrive pas à les lire…. enfin… à les interpréter.
      Avec le système initié par ubuntu, donc, les dates, on arrive à connaître l'âge d'une version.
      Avec le système plus éprouvé M.m.b on arrive à estimer la différence de fonctionnalités.
      Mais, avec les numéros débiles type firefox, chrome, et systemd, je n'arrive vraiment pas à avoir la moindre idée de la somme des changements entre 2 versions…
      
      Pour les archis restée en 44, c'est pas illogique qu'elles ne soient pas montées plus haut. Ces systèmes sont minoritaires, et la portabilité de systemd est plus que discutable. Le sieur Lennart code pour la dernier version de linux, si je ne m'abuse, et les autres peuvent aller brouter ailleurs.
      Conclusion: ceux qui ont des archis différentes, auront des emmerdes avec systemd. Mais bon, rien de neuf ici.
- [^] # Re: Debian
  
  Posté par zebra3 le 24 mars 2014 à 10:54. Évalué à 5.
  
  Ça tombe bien, la 208 vient d'arriver dans unstable, juste avant ton commentaire :-)
  
  Et je viens de voir que la 204 est dispo dans les backports de Wheezy, je m'en vais essayer ça pour le fun.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# X.org

Posté par neil le 21 mars 2014 à 18:36. Évalué à 5. Dernière modification le 21 mars 2014 à 18:37.

Note : côté sécurité mais un peu en marge, la version 3.0 des pilotes Intel pour X.Org permettra à ce dernier de tourner sans les droits root en s'appuyant sur systemd/logind (le défunt OS Moblin 2.0 avait étrenné dès 2009 cette fonctionnalité rendue théoriquement possible par KMS).

Fonctionnalité disponible sous BSD sans utiliser SysTemD (pour Intel et ATI).
- [^] # Re: X.org
  
  Posté par antistress (site web personnel) le 21 mars 2014 à 19:03. Évalué à 7.
  
  Dingue BSD vient juste d'avoir KMS et paf ! Ils dont rootless X dans la foulée.
  Les pilotes KMS sous Linux ça fait des années et arrive seulement rootless X (Moblin mis à part) o_O
  - [^] # Re: X.org
    
    Posté par ariasuni le 21 mars 2014 à 19:44. Évalué à 3.
    
    Faut croire qu’on est un peu nul sous GNU/Linux… :p
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: X.org
      
      Posté par freem le 21 mars 2014 à 22:28. Évalué à 2.
      
      La solution:
      Utiliser GNU/FreeBSD :p ( faut vraiment que je fasse le test, d'ailleurs )
      - [^] # Re: X.org
        
        Posté par anaseto le 22 mars 2014 à 13:06. Évalué à 2.
        
        De ce que j'en sais, X sans root c'est disponible encore que sous OpenBSD (mais ça sera peut-être porté vers les autres BSDs).
# Pulse Audio et BlueZ 5

Posté par Maclag le 21 mars 2014 à 20:22. Évalué à 10.

Je suis le seul à être choqué par la régression sur les casques VoIP?

Non, sérieusement, depuis combien de temps ça existe les casques Bluetooth pour la VoIP? Un bout de temps non?

"Nouveau, grâce à la toute dernière version… 'a marche pu!"

Sérieux, moi qui lisais il n'y a pas si longtemps encore qu'un bon casque audio a forcément un fil physique et que les casques BT sont juste bons pour la VoIP (opinion qui n'émane pas de moi, j'y connais pas grand chose de toute façon), ben voilà quoi!

Tu veux faire de la VoIP sous Linux? On a de supers clients libres, mais euh, par contre, les casques BT, trop compliqué. T'as qu'à utiliser Android… ou Windows!??
- [^] # Re: Pulse Audio et BlueZ 5
  
  Posté par BAud (site web personnel) le 21 mars 2014 à 21:16. Évalué à 5.
  
  Je suis le seul à être choqué par la régression sur les casques VoIP?
  
  non, il y a tankey< aussite dans ceux que je connais.
  
  moi c'est plutôt la limitation de la prise audio (avec la prise jack) sur le PC qui ne reconnaît pas que j'ai un micro qui me gêne, ça fonctionne sur mon mobile depuis pas mal de temps pourtant :/
- [^] # Re: Pulse Audio et BlueZ 5
  
  Posté par Tonton Benoit le 21 mars 2014 à 23:06. Évalué à 7.
  
  Je suis d'autant plus d'accord que je suis confronté à ce problème.
  De un, ça m'a obligé à compiler le git de pulseaudio, de deux j'ai pas le micro, donc exit l'utilisation VOIP/FlightSim…
  
  Bon après je comprend la position des développeurs de bluez, qui préfèrent larguer les interfaces spécifiques, surtout les lourdes comme l'interface audio, et se concentrer sur une interface générique, au client derrière de gérer son bouzin. Mais un peu plus de coordination, attendre que les clients soit près pour virer la fonction aurait été appréciable.
  - [^] # Re: Pulse Audio et BlueZ 5
    
    Posté par freem le 21 mars 2014 à 23:21. Évalué à 8.
    
    En fait, tu souhaiterais qu'ils mettent la fonction en deprecated avant de la virer quoi?
    
    Tu te rends compte de la somme de travail et maintenance que ça leur demanderais?
    Je ne parle pas au niveau du code, bien entendu, mais au niveau moral: il leur faudrait alors accepter que ce qui est nouveau n'est pas optimal!
- [^] # Re: Pulse Audio et BlueZ 5
  
  Posté par Albert_ le 21 mars 2014 à 23:13. Évalué à 4.
  
  Ben en meme temps il ne faut pas utiliser une distribution qui ne propose que bluez5…
  - [^] # Re: Pulse Audio et BlueZ 5
    
    Posté par Tonton Benoit le 22 mars 2014 à 00:08. Évalué à 4.
    
    J'aime gérer mon bluetooth via Gnome.
    
    Et puis sous Gentoo le problème n'est pas de proposer que Bluez5 (ce qui n’est pas le cas), mais vu que chacun compile son paquet, la bonne dépendance doit être présente sur la machine.
    - [^] # Re: Pulse Audio et BlueZ 5
      
      Posté par Albert_ le 22 mars 2014 à 00:12. Évalué à 4.
      
      via Gnome.
      
      Tout le monde a le droit de faire des erreurs :)
  - [^] # Re: Pulse Audio et BlueZ 5
    
    Posté par Maclag le 22 mars 2014 à 02:34. Évalué à 6.
    
    Ma distro n'est pas à BlueZ 5. Mais je lis bien que BlueZ 5 largue les profils hors A2DP, et pour avoir autre chose, il faudra se reposer sur d'autres parties (oFono ici).
    
    Pour moi, PA devait être la clé qui permettait d'utiliser tout ce bordel correctement:
    Passer à la volée des HP au casque à prise jack en façade, à une sortie BT, ou autre d'ailleurs. Pareil pour les entrées: micro jack, BT, pourquoi pas USB ou autre: ça devrait être simple et transparent pour l'utilisateur.
    
    Alors quand je lis que chacun s'occupe d'un élément à géométrie variable du puzzle, je me demande: est-ce que quelqu'un a une vision globale ou tout le monde s'en fout?!
    - [^] # Re: Pulse Audio et BlueZ 5
      
      Posté par Albert_ le 22 mars 2014 à 08:34. Évalué à 4.
      
      Très bonne question. Et avec cette nouveauté cela enlève le seul truc utile, pour moi, qu'apportait PA. Donc autant utiliser alsa uniquement.
- [^] # Re: Pulse Audio et BlueZ 5
  
  Posté par reno le 24 mars 2014 à 10:54. Évalué à 3.
  
  Je suis le seul à être choqué par la régression sur les casques VoIP?
  
  Oui et non, si je comprends bien il y a différent profils d'utilisations, ils ont réduit le nombre de profils gérer et les distributions ne se sont pas adaptées en proposant un autre outil pour les profils qui n'étaient plus supportés..
  
  Donc clairement pour l'utilisateur c'est un gros problème, maintenant à qui la faute?
  Aux devs de BlueZ qui n'ont pas bien communiqué sur les restrictions de leur nouvelle version?
  Aux distributions qui n'ont pas fait le travail?
  Difficile à dire sans investiguer plus précisément..
# Régression dans Gnome

Posté par Pif le Chien le 22 mars 2014 à 00:21. Évalué à 7. Dernière modification le 22 mars 2014 à 00:23.

Des distributions ont migré vers BlueZ 5 sans fournir aux utilisateurs la possibilité de rester avec BlueZ 4. Certaines de ces distributions ont probablement fait la transition sans en comprendre les conséquences — elles ont maintenant une sérieuse régression en terme de fonctionnalités, […] GNOME a aussi pris la décision, peut-être en étant mal informé, d’abandonner la prise en charge de BlueZ 4 dans leur dernière version"

C'était pas dans leur roadmap ?
# cours ou amputation

Posté par Ms-Mac le 22 mars 2014 à 09:09. Évalué à -5.

N'étant pas un pro je me suis écrit un fichier pseudo-script pour mes iptables.
Alors!! Dois je prendre des cours de langage ou me préparer à ne plus utiliser iptables lorsque je vais migrer mes serveurs de wheezy ==> jessie ??

Merci pour vos conseils

Tout le monde a un cerveau. Mais peu de gens le savent.
- [^] # Re: cours ou amputation
  
  Posté par ariasuni le 22 mars 2014 à 13:14. Évalué à 3.
  
  systemd n'est pas un/ne possède pas de remplaçant à iptables car ça n'a rien a voir, si ce n'est que l'on peut activer l'unité iptables pour charger ses règles iptables au démarrage.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: cours ou amputation
    
    Posté par Ms-Mac le 22 mars 2014 à 22:11. Évalué à -6.
    
    Merci pour la réponse. C'est mieux que le moinssage type éducation nationale..
    Je sais que systemd ne remplace pas iptables mais acceptera t'il mon pseudo-script ou devrais je apprendre un langage spécial pour que cela fonctionne. Car cela n'est pas mon truc ..
    
    Tout le monde a un cerveau. Mais peu de gens le savent.
    - [^] # Re: cours ou amputation
      
      Posté par Sufflope (site web personnel) le 22 mars 2014 à 22:18. Évalué à -3.
      
      C'est mieux que le moinssage type éducation nationale..
      
      Je sais pas pour toi mais lors de ma scolarité j'avais droit aux corrigés / solutions des contrôles, pour comprendre pourquoi j'avais faux.
      
      Nan je déconne j'avais la plupart du temps raison. Du coup je me faisais chier pendant les corrections mais elles étaient néanmoins là.
      
      Un traumatisme à partager pour expliquer cette phrase, cher réac. ?
    - [^] # Re: cours ou amputation
      
      Posté par Arthur Accroc le 22 mars 2014 à 23:41. Évalué à 4.
      
      Je sais que systemd ne remplace pas iptables mais acceptera t'il mon pseudo-script ou devrais je apprendre un langage spécial pour que cela fonctionne.
      
      Qu’appelles-tu un « pseudo-script » ? En quoi est-il « pseudo » ???
      
      Si ton script crée des tables statiques, tu le lances comme tu fais le habituellement, tu sauvegardes les tables résultantes avec iptables-save et tu actives le service iptables de systemd au démarrage du système avec systemctl enable iptables.service ; il chargera les tables telles qu’elles ont été sauvegardées à l’étape précédente.
      
      Sinon, il faut que tu crées un service systemd qui lance ton script.
      
      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
      - [^] # Re: cours ou amputation
        
        Posté par Ms-Mac le 23 mars 2014 à 09:22. Évalué à 1.
        
        j'avais droit aux corrigés / solutions des contrôles, pour comprendre pourquoi j'avais faux.
        
        hé oui c'est mieux que le moinssage mais plus difficile à faire.
        
        @ Arthur
        
        Mon pseudo-script est un fichier qui ne comporte pas de |start|restart|stop|.
        Simplement un petit exécutable qui entre les tables au démarrage via /etc/rc2.D.
        D'ou mon inquiétude avec systemd
        
        Mais ta réponse me donne déjà une voie à explorer reste à trouver une machine sur laquelle je peux installer une jessie systemd pour essayer.
        
        Encore merci.
        
        Tout le monde a un cerveau. Mais peu de gens le savent.
# Ils ont de l'avance, c'est pourtant pas le premier avril !

Posté par Domi le 22 mars 2014 à 21:45. Évalué à -10.

J'ai jamais autant rit quand lisant la nouvelle sur pulseaudio ! Et comme cela n'est pas le 1er avril, on dirait même que c'est vrai !

Un remède radical, ALSA + JACK +
cat ~/.asoundrc

pcm.rawjack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}

pcm.jack {
type plug
slave { pcm "rawjack" }
hint {
description "JACK Audio Connection Kit"
}
}

pcm.!default {
type plug
slave { pcm "rawjack" }
}

pcm.dsp pcm.!default

Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
- [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
  
  Posté par navaati le 23 mars 2014 à 19:11. Évalué à 10.
  
  Attends, t'es sérieux ?
  
  Donc là, la dépêche raconte que pulse a des problèmes avec le bluetooth. En plus c'est même pas leur faute c'est celle de bluez qui a droppé des fonctionnalités.
  
  Et toi tu viens te foutre de leur gueule en faisant le barbon avec jack, qui n'a strictement aucun moyen de faire du bluetooth ? Donc qui n'est même pas le début d'une solution au problème de pulseaudio ?
  
  Putain…
  - [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
    
    Posté par Maclag le 24 mars 2014 à 04:43. Évalué à -2.
    
    Ben oui, du coup t'es jamais déçu parce que ça le faisait déjà pas avant. ;)
    
    Sinon, pour PA, c'est un peu facile de dire que c'est pas leur faute, c'est BlueZ:
    Si j'utilise libtruc1 à un moment donné et qu'on me dit que libtruc2 va virer des fonctionnalités dont j'ai besoin, ben c'est simple: je dis haut et fort que je reste sur libtruc1 jusqu'à ce que libtruc2 me permette d'en faire autant qu'avant.
    
    Visiblement ce n'est pas ce qu'on a décidé chez les dévs de PA. Ils ont décidé que passer à la lib suivante c'est mieux et tant pis si les utilisateurs se retrouvent avec une put… de régression.
    Désolé mais là clairement: l'utilisateur, on s'en fout!
    
    En poussant à l'extrême, si BlueZ6 lâche complètement l'audio, alors ce ne sera pas la faute de PA s'ils déclarent que dès la prochaine version, il n'y aura plus moyen d'avoir de son via BT?
    - [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
      
      Posté par ariasuni le 24 mars 2014 à 09:50. Évalué à 10.
      
      Visiblement ce n'est pas ce qu'on a décidé chez les dévs de PA. Ils ont décidé que passer à la lib suivante c'est mieux et tant pis si les utilisateurs se retrouvent avec une put… de régression.
      
      Est-ce que tu peux lire la dépêche s'il te plait? PulseAudio 5 est compatible BlueZ 4 et BlueZ 5.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par xcomcmdr le 24 mars 2014 à 12:48. Évalué à 2. Dernière modification le 24 mars 2014 à 12:49.
        
        Lire pour troller ? Et puis quoi encore ? Savoir argumenter, ne pas rester dans le flou, lire avant de cliquer sur "inutile" ou "pertinent" ?
        
        Y'a que 24 heures dans une journée, naméo ! ;-)
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Maclag le 24 mars 2014 à 14:16. Évalué à 5.
        
        Effectivement j'ai mal lu!
        Mea maxima culpa!
        
        Vous pouvez remplacer "les devs PA" par "les distros qui ont migré sans regarder".
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Albert_ le 24 mars 2014 à 15:46. Évalué à 1.
        
        Chuttt on ne dit pas de mal de Fedora
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Misc (site web personnel) le 24 mars 2014 à 22:06. Évalué à 2.
        
        En même temps, y a pas de raison de dire du mal de Fedora, vu que ça n'a pas été fait sans regarder, il suffit de voir le thread sur le sujet ou il est dit que le profile hfp doit être codé ailleurs que dans bluez :
        
        https://lists.fedoraproject.org/pipermail/devel/2014-January/194512.html
        
        Et notamment la partie sur "bluez 4 n'était plus maintenu depuis 1 an"
        
        https://lists.fedoraproject.org/pipermail/devel/2014-January/194757.html
        
        Et que la QA de Fedora a vu la regression, mais n'a pas jugé ça suffisamment important pour bloquer la release :
        
        https://lists.fedoraproject.org/pipermail/devel/2014-January/194375.html
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Albert_ le 24 mars 2014 à 22:39. Évalué à 0. Dernière modification le 24 mars 2014 à 22:40.
        
        c'est cool je suis sur que les utilisateurs de Fedora ayant des casques bluetooth seront ravis de savoir que cela ne fonctionne plus mais cela a ete fait en toute connaissance de cause…
        
        En meme temps, pour utiliser Fedora il faut etre bien conscient que n'importe quoi peut etre considere comme terrain de jeu.
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Sufflope (site web personnel) le 24 mars 2014 à 22:53. Évalué à 4.
        
        En meme temps, pour utiliser Fedora il faut etre bien conscient que n'importe quoi peut etre considere comme terrain de jeu.
        
        Bon bah voilà, pourquoi tu gueules en fait ? Fedora a tué ton chien ?
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Albert_ le 24 mars 2014 à 23:39. Évalué à -2.
        
        Mais je ne gueule pas je fais juste une constatation que la distribution la plus celebre qui ne propose que bluez5 et donc que PA supporte l'un et l'autre n'a aucun interet c'est Fedora.
        
        Je ne faisais donc que donner une information mais tu peux ne pas apprecier cela ne change pas les faits.
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Misc (site web personnel) le 24 mars 2014 à 23:23. Évalué à 4.
        
        c'est cool je suis sur que les utilisateurs de Fedora ayant des > casques bluetooth seront ravis de savoir que cela ne fonctionne
        plus mais cela a ete fait en toute connaissance de cause…
        
        au contraire des gens qui bénéficient des nouveautés de bluez 5, qui devraient ne pas en bénéficier pour ça ?
        
        ( les nouveautés sont détaillés sur http://lwn.net/Articles/531133/, par exemple, le support des 5 nouveaux profiles BT )
        
        Et quand tu as un peu de bouteille dans la création d'une distribution, tu vois assez vite qu'il y a toujours un arbitrage à faire pour chaque upgrade important.
        
        C'est pas "est ce que je rajoute une régression ou pas juste pour faire chier les gens", c'est "est ce que la fonctionnalité vaut le risque de rajouter une régression". Et comme je dit, le changement a été annoncé upstream et dans Fedora, avec l'input de la communauté ( https://fedoraproject.org/wiki/Changes/Bluez5 ). Ouais, y a eu une régressions, mais c'est l'upstream qui a décidé. Et l'upstream a bougé le code dans ofono donc dans son usecase ( ie ofono + bluez, par exemple sur un téléphone ), ça marche. Je me doute bien que ça puisse faire chier, mais que je sache, tu utilises pas Fedora donc je ne pige pas en quoi ça semble te géner toi ( sauf à t'abroger le droit de parler au nom d'un groupe dont tu ne fait pas parti )
        
        [^] # Re: Ils ont de l'avance, c'est pourtant pas le premier avril !
        
        Posté par Albert_ le 24 mars 2014 à 23:35. Évalué à -3.
        
        Rate j'utilise aussi Fedora… mais bon j'ai l'habitude que cela soit toujours un peu casse.
# Sortie de la version 212 de systemd

Posté par Sylvain Blandel le 27 mars 2014 à 12:23. Évalué à 6.

La version 212 de systemd est sortie.
- [^] # Re: Sortie de la version 212 de systemd
  
  Posté par ariasuni le 27 mars 2014 à 15:07. Évalué à 3.
  
  Je referais une dépêche, t'inquiètes pas. :p
  
  É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.