systemd est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init LSB. systemd a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (cgroups) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services.
systemd ne fait pas partie du projet freedesktop.org, bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs.
La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions.
Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre).
Sommaire
- systemd est monolithique
- systemd a été conçu pour la vitesse
- La vitesse de systemd ne sert à rien pour les serveurs !
- systemd est incompatible avec les scripts shell
- systemd est compliqué
- systemd n’est pas modulaire
- systemd est seulement pour les ordinateurs de bureau
- systemd est un résultat du syndrome NIH (NdT : Not Invented Here, « Pas inventé ici »)
- systemd est un projet freedesktop.org
- systemd n’est pas UNIX
- systemd est complexe
- systemd est une usine à gaz
- systemd seulement pour Linux, pas sympa pour les BSD
- systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
- systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
- systemd n’a pas de raison de ne pas être portable
- systemd utilise des fichiers de configuration binaire
- systemd est un cauchemar de fonctionnalités
- systemd vous force à faire quelque chose
- systemd rend impossible l’utilisation de syslog
- systemd est incompatible
- systemd n’est pas scriptable, à cause de son utilisation de D-Bus
- systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
- systemd est instable et bogué
- systemd n’est pas déboguable
- systemd fait des changements pour le plaisir de changer
- systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
- systemd ne gère pas l’utilisation d’un
/usrséparé du répertoire racine - systemd ne permet pas de remplacer ses composants
- L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ce qui suit est en grande partie une traduction d’un article Les 30 plus grands mythes à propos de systemd paru en janvier 2013 sur le site de Lennart Poettering.
Donc à partir de maintenant et jusqu’à la fin, c’est Lennart Poettering qui (indirectement) parle !
Depuis la première proposition d’inclusion de systemd au sein des distributions, on en a fréquemment parlé sur de nombreux forums, listes de diffusion et conférences. Dans ces discussions, on peut souvent entendre certains mythes à propos de systemd, qui sont répétés encore et encore, sans que cette répétition ne les rende vrais pour autant. Prenons le temps d’en briser quelques-uns :
systemd est monolithique
systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés. D’une part, systemd a été conçu pour être sécurisé : chaque binaire effectue une tâche très spécifique avec des privilèges minimaux — en utilisant les capacités (capabilities) du noyau par exemple — pour réduire la surface d’attaque et l’impact de failles de sécurité. Cela rend également systemd plus robuste et plus facile à faire évoluer et à déboguer. D’autre part, cette séparation est essentielle pour que systemd puisse lancer ces binaires en parallèle. Beaucoup d'entre eux sont même si bien séparés qu’ils peuvent aussi être utiles en dehors de systemd (systemd-detect-virt, systemd-tmpfiles ou systemd-udevd, par exemple).
Un ensemble de plusieurs dizaines de binaires peut difficilement être qualifié de monolithique. À la différence de ce qui se pratiquait auparavant, les composants sont dans une seule archive, et ils sont tous maintenus en amont dans un seul dépôt avec un cycle de publication unifié — ce qui est sans doute bénéfique au bon fonctionnement de l’ensemble.
systemd a été conçu pour la vitesse
Oui, systemd est rapide (on peut obtenir un espace utilisateur presque complet en à peu près 900 ms !), mais c’est principalement un effet secondaire d’avoir fait les choses correctement. En fait, nous n’avons jamais essayé d’optimiser chaque parcelle de systemd ; au contraire, nous avons fréquemment choisi en toute connaissance de cause un code légèrement plus lent en faveur de la lisibilité du code. Cela ne veut pas dire que la vitesse ne nous intéresse pas, mais réduire systemd à sa vitesse est une idée fausse, car ce n’est pas du tout dans nos priorités.
La vitesse de systemd ne sert à rien pour les serveurs !
C’est complètement faux. Beaucoup d’administrateurs désirent réduire les temps d’arrêt des fenêtres de maintenance. Pour les configurations à haute disponibilité, c’est sympathique d’avoir une machine indisponible qui redevient très vite disponible (le besoin utilisateur étant « toujours disponible », même s’ils oublient les interventions techniques (montée de version de logiciel, d’OS…), vu qu’ils ont une approche « nos utilisateurs » pour lesquels une nouvelle version ne correspond qu’à des ajouts, pas des régressions…). Pour les configurations dans les nuages avec un nombre important de machines virtuelles ou de conteneurs, le cout d’un démarrage lent est multiplié par le nombre d’instances. Passer plusieurs minutes de temps CPU et d’entrées/sorties sur des démarrages très lents de milliers de machines virtuelles ou de conteneurs réduit la densité de votre système de façon importante, cela vous coute même plus d’énergie. Un démarrage lent peut vous couter beaucoup d’argent, alors qu’un démarrage rapide permet d’implémenter une logique d’activation de conteneurs par socket pour augmenter la densité de votre système dans les nuages.
Bien entendu, pour la plupart des configurations de serveur, le temps de démarrage n’est pas intéressant, mais systemd est censé couvrir le plus de cas possibles. Et oui, je suis au courant que c’est souvent le micrologiciel du serveur qui prend le plus de temps au démarrage, et que le système d’exploitation démarre vite en comparaison, mais tous les serveurs n’ont pas un aussi mauvais micrologiciel, et certainement pas les machines virtuelles ni les conteneurs, qui sont un type de machine virtuelle également.
Note : nous essayons de faire notre petite part pour rendre les micrologiciels meilleurs. En mettant les performances de démarrage du micrologiciel en évidence dans la sortie de systemd, nous espérons que la honte poussera les auteurs de micrologiciels à nettoyer leur travail.
systemd est incompatible avec les scripts shell
C’est complètement bidon. Nous ne les utilisons pas pour le processus de démarrage parce que nous pensons qu’ils ne sont pas le meilleur outil pour cette tâche spécifique, mais cela ne signifie pas que systemd n’est pas compatible avec eux. Vous pouvez facilement lancer des scripts shell en tant que service systemd, systemd n’a strictement rien à faire de ce qui est à l’intérieur de votre exécutable. De plus, nous utilisons énormément les scripts shell pour installer, construire et tester systemd. Et vous pouvez continuer à utiliser vos propres scripts très tôt dans le démarrage, les utiliser comme des services normaux, les lancer à l’extinction de la machine, il n’y a quasiment aucune limite.
systemd est compliqué
C’est aussi un non-sens total. Une plateforme systemd est en réalité beaucoup plus simple que les Linux traditionnels, car elle unifie le système d’objets et leurs dépendances en unités systemd. Le langage des fichiers de configuration est très simple et on se débarrasse des fichiers de configuration redondants. Nous fournissons des outils uniformes pour la plupart des tâches de configuration du système. Le système est beaucoup moins aggloméré que les Linux traditionnels. Nous avons également une documentation plutôt complète (tout est présent sur la page d’accueil) sur à peu près tous les détails de systemd, et cela ne couvre pas seulement les interfaces pour utilisateur et administrateur, mais également les API pour les développeurs.
systemd nécessite bien sûr un apprentissage. Comme toute chose. Cependant, nous aimons croire que c’est vraiment plus simple de comprendre systemd qu’un démarrage fondé sur des scripts shell pour la plupart des gens. Surpris de ces paroles ? Eh bien, il s’avère que le shell n’est pas un langage sympathique à apprendre, sa syntaxe est obscure et complexe. Les fichiers unités de systemd sont beaucoup plus simples à comprendre, ils ne nous exposent pas à un langage de programmation, mais sont simples et déclaratifs par nature. Cela dit, si vous avez de l’expérience en shell, en effet, adopter systemd vous demandera un petit peu d’apprentissage.
Afin de rendre l’apprentissage facile, nous avons fait notre maximum pour fournir une compatibilité avec les solutions précédentes. De plus, sur de nombreuses distributions, vous remarquerez que certains des outils traditionnels vous diront — en faisant ce que vous leur aviez demandé — comment vous pourriez le faire avec les nouveaux outils à la place, possiblement d’une façon plus agréable.
Bref, systemd ne peut probablement pas être plus simple qu’il ne l’est déjà pour la tâche qu’il remplit, et nous avons travaillé dur pour qu’il soit simple à apprendre. Alors oui, si vous connaissez sysvinit alors adopter systemd va vous demander un peu d’apprentissage ; mais franchement, si vous maitrisez sysvinit, alors systemd devrait être facile pour vous.
systemd n’est pas modulaire
Tout faux. À la compilation, il y a beaucoup d’options de configuration pour choisir ce que vous voulez compiler ou non. Et nous documentons comment sélectionner encore plus en détail ce dont vous avez besoin, en allant plus loin que les options de configuration.
Cette modularité n’est pas totalement différente de celle du noyau Linux, où vous pouvez sélectionner beaucoup de fonctionnalités individuellement à la compilation. Si le noyau est assez modulaire pour vous, alors systemd l’est probablement.
systemd est seulement pour les ordinateurs de bureau
Ce n’est certainement pas vrai. Avec systemd, nous essayons à peu près de couvrir la même portée que Linux. Alors, que nous tenons compte des usages bureautiques, nous tenons aussi compte des usages serveur, ainsi que des usages embarqués. Vous pouvez parier que Red Hat ne voudrait pas en faire une pièce centrale de RHEL 7 si ce n’était pas la meilleure option pour gérer les services des serveurs.
Des personnes de différentes entreprises travaillent sur systemd. Les fabricants de voitures l’intègrent dans leurs voitures, Red Hat l’utilise pour ses systèmes d’exploitation pour serveurs, et GNOME utilise nombre de ses interfaces afin d’améliorer le bureau. Vous le trouvez dans les jouets, les télescopes et dans les éoliennes.
La plupart des fonctionnalités sur lesquelles j’ai travaillé récemment, relèvent du domaine des serveurs, comme le support des conteneurs, le management des ressources ou des fonctionnalités de sécurité. Nous couvrons plutôt bien les systèmes bureautiques pour le moment, et il y a de nombreuses entreprises faisant du développement sur systemd pour l’embarqué, certaines offrent même des services de consultance pour lui.
systemd est un résultat du syndrome NIH (NdT : Not Invented Here, « Pas inventé ici »)
Ce n’est pas vrai. Avant que nous commencions à travailler sur systemd, nous poussions l’adoption à grande échelle d’Upstart (et Fedora/RHEL l’utilisent également depuis un moment). Cependant, nous sommes finalement arrivés à la conclusion que le cœur de sa conception présentait des défauts (au moins à nos yeux : plus fondamentalement, il laisse la gestion des dépendances à l’administrateur/au développeur, au lieu de résoudre ce problème difficile dans le code) et, si quelque chose ne va pas dans le cœur, il vaut mieux le remplacer que de le corriger. Ça n’est pas la seule raison cependant, d’autres choses ont joué, comme le bordel autour du CLA. NIH n’était cependant pas une des raisons…
Note : et puis, devinez quel projet inclut une bibliothèque « libnih » — Upstart ou systemd ? (indice : ça n’est pas systemd !)
systemd est un projet freedesktop.org
Ma foi, c’est vrai que systemd est hébergé sur fdo, mais freedesktop.org n’offre pas grand-chose de plus qu’un dépôt pour le code et la documentation. À peu près tous les développeurs peuvent demander de l’espace et déposer leurs affaires ici (à condition d’avoir un vague rapport avec l’infrastructure des systèmes libres). Il n’y a pas de cabale, pas de processus de standardisation, pas de vérification de projet, rien. C’est juste un hébergement sympa, gratuit et solide pour mettre un dépôt. De ce point de vue, c’est un peu comme sourceforge, github, kernel.org, mais de nature non commerciale et sans demandes excessives et donc, un bon endroit où mettre notre projet.
Donc oui, nous avons choisi fdo pour l’hébergement, mais l’hypothèse implicite de ce mythe, qu’il existe un groupe de gens qui se rencontrent et qui décident du futur des systèmes libres, est entièrement fausse.
systemd n’est pas UNIX
Il y a certainement du vrai en cela. Les sources de systemd ne contiennent pas une seule ligne de code héritée de l’UNIX originel. En revanche, notre inspiration nous vient d’UNIX et c’est pourquoi il y a beaucoup d’UNIX en systemd. Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs. Ensuite, une des fonctionnalités originelles d’UNIX était celle des multi-terminaux (multi-seat), basée sur la prise en charge des consoles (terminaux d'ordinateurs). Les consoles en mode texte ne sont pas vraiment la manière dont vous interagissez avec votre ordinateur de nos jours. Avec systemd, nous avons apporté le retour de la gestion des multi-terminaux, mais cette fois avec la gestion complète des composants modernes, des cartes graphiques aux souris, systèmes audio, webcams et bien plus, et tout cela complètement automatique, branchements à chaud et sans configuration. En effet, le design de systemd en tant que suite d’outils intégrés dont chacun a ses buts propres, voilà la philosophie du cœur d’UNIX. Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.
Enfin, UNIX est quelque chose de différent pour chacun. Pour nous, les mainteneurs de systemd, c’est quelque chose dont nous nous inspirons. Pour d’autres, c’est une religion, et tout comme les autres religions du monde, il y a différentes façons de lire ou d’interpréter. Certains définissent UNIX comme un héritage de certains bouts de codes spécifiques, d’autres le voient juste comme un ensemble d’idées, d’autres comme un ensemble de commandes, et d’autres encore comme une définition de comportements. Bien sûr, il est impossible de faire en sorte que toutes ces personnes soient heureuses.
Finalement, la question de savoir si quelque chose est UNIX ou non importe vraiment peu. Être techniquement excellent n’est pas exclusif à UNIX. Pour nous, UNIX est une influence majeure (zut, la plus grosse), mais nous avons aussi d’autres influences. Ainsi, dans certains domaines systemd sera vraiment UNIX et dans d’autres un peu moins.
systemd est complexe
Il y a un fond de vérité à cela. Les ordinateurs modernes sont des choses complexes et le système qui tourne dessus doit donc être complexe aussi. Toutefois, systemd n’est pas plus complexe que les implémentations précédentes des mêmes composants. Au contraire, il est plus simple et réduit les redondances (voir plus haut). De plus, construire un système simple basé sur systemd impliquera moins de paquets qu’un système Linux traditionnel. Avoir moins de paquets facilite la construction du système et permet de se débarrasser des interdépendances et des comportements divergents de chaque composant impliqué.
systemd est une usine à gaz
Hé bien, il y a probablement plusieurs définitions de « usine à gaz ». Mais dans la plupart des définitions, systemd est probablement l’opposé d’une usine à gaz. Vu que les composants systemd partagent une base de code commune, ils ont tendance à partager plus de code pour les fonctions générales. Voici un exemple : dans une configuration Linux traditionnelle, sysvinit, start-stop-daemon, inetd, cron, dbus implémentent tous une façon de lancer des processus avec des options de configuration variées dans un environnement que l’on espère propre. Dans systemd, les fonctions pour tout ceci, que ce soit le parsing (NdT : analyse syntaxique si vous y tenez vraiment) de la configuration ou le lancement lui-même, sont partagées. Cela se traduit par moins de code, moins de place pour faire des erreurs, moins de mémoire occupée et moins de pression sur le cache, et donc c’est une très bonne chose. Et en plus, vous gagnez une tonne de nouvelles fonctionnalités grâce à ça.
Comme mentionné plus haut, systemd est aussi plutôt modulaire. Vous pouvez choisir à la compilation les composants dont vous avez besoin et ceux dont vous pouvez vous passer. De sorte que les gens peuvent choisir à quel point systemd est une « usine à gaz ».
Quand vous compilez systemd, il ne demande que 3 dépendances : glibc, libcap et dbus. C’est tout. Il peut utiliser beaucoup plus de dépendances, mais elles sont toutes entièrement optionnelles.
Donc oui, sous tous les angles, ce n’est vraiment pas une usine à gaz.
systemd seulement pour Linux, pas sympa pour les BSD
Complètement faux. Les gens de chez BSD ne sont pas vraiment intéressés par systemd. Si systemd était portable, cela n’aurait rien changé, ils ne voudraient pas l’adopter quand même. Et la même chose est vraie pour les autres Unix dans le monde. Solaris a SMF, BSD a son propre système rc, et ils l’ont toujours maintenu séparément de Linux. Le système d’initialisation est très proche du cœur du système d’exploitation. Et ces autres systèmes d’exploitation se définissent eux-mêmes, entre autres choses, par le cœur de leur espace utilisateur. L’hypothèse qu’ils aient adopté notre cœur d’espace utilisateur si nous l’avions juste rendu portable est sans aucun fondement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
NdT : Debian est déjà passée à systemd, mais on traduit aussi cette partie pour le plaisir. :p
Debian prend en charge des noyaux non-Linux dans leur distribution. systemd ne fonctionnera pas sur ceux-ci. Est-ce que c’est cependant un problème, et cela doit-il gêner l’adoption de systemd par défaut ? Pas vraiment. Les gens qui ont porté Debian sur ces noyaux sont prêts à investir du temps dans un portage qui demande beaucoup de travail, ils ont mis en place des systèmes de tests et de compilation, patché et compilé de nombreux paquets pour atteindre ce but. La maintenance à la fois d’une unité systemd et d’un script d’initialisation classique pour les services empaquetés est une charge de travail négligeable comparé à cela, en particulier parce que le plus souvent ces scripts existent déjà.
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
C’est tout simplement faux. Faire un portage de systemd sur d’autres noyaux n’est pas faisable. Nous utilisons trop d’interfaces spécifiques à Linux. Pour certaines, on peut trouver des remplacements sur les autres noyaux, pour d’autres nous pourrions les désactiver, mais pour la plupart, ce n’est vraiment pas possible. Voici une petite liste non exhaustive: cgroups, fanotify, umount2(), /proc/self/mountinfo (incluant les notifications), /dev/swaps (de même), udev, netlink, la structure de /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capacités, espaces de nommages en tout genre, divers prctl()s, de nombreux ioctls, l’appel système mount() et sa sémantique, SELinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, et ainsi de suite.
Si vous regardez cette liste et prenez les quelques éléments auxquels vous pouvez trouver un équivalent évident dans d’autres noyaux, alors réfléchissez à nouveau, et regardez ceux que vous n’avez pas considérés et la complexité nécessaire pour les remplacer.
systemd n’a pas de raison de ne pas être portable
Ça n’a aucun sens ! Nous utilisons des fonctions spécifiques à Linux parce que nous en avons besoin pour implémenter ce que nous voulons. Linux a beaucoup de fonctionnalités qu’UNIX/POSIX n’a pas, et nous voulons que les utilisateurs puissent en tirer parti. Ces fonctions sont incroyablement utiles, mais seulement si elles sont offertes de manière conviviale à l’utilisateur et c’est ce que nous voulons faire avec systemd.
systemd utilise des fichiers de configuration binaire
Je n’ai aucune idée d’où est sorti ce mythe fou, mais ça n’est absolument pas vrai. systemd est configuré quasi exclusivement par de simples fichiers textes. Vous pouvez également modifier quelques options avec la ligne de commande du noyau ou par des variables d’environnement. Il n’y a rien de binaire dans sa configuration (même pas de XML). Seulement des fichiers en texte brut, simples, et faciles à lire.
systemd est un cauchemar de fonctionnalités
Eh bien, systemd couvre certainement plus de terrain que par le passé. Ce n’est plus uniquement un système d’initialisation, mais le bloc de base de l’espace utilisateur à partir duquel construire un système d’exploitation ; mais nous faisons attention de garder optionnelles la plupart des fonctionnalités. Vous pouvez en désactiver beaucoup lors de la compilation, et encore plus lors de l’exécution. Ainsi pouvez-vous choisir librement combien de fonctionnalités injecter.
systemd vous force à faire quelque chose
systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».
systemd rend impossible l’utilisation de syslog
C’est faux, nous avons fait attention lors de l’introduction du journal à ce que les informations soient transmises au serveur syslog. En fait, s’il y a bien une chose qui a changé, c’est surtout le fait que syslog reçoit maintenant plus d’informations, car nous nous occupons du début du démarrage système ainsi que des flux STDOUT/STDERR de tous les services du système.
systemd est incompatible
Nous faisons de notre mieux pour garantir la meilleure compatibilité possible avec sysvinit. En fait, la grande majorité des scripts d’initialisation fonctionne telle quelle sous systemd, sans modifications. Toutefois, il y a effectivement quelques incompatibilités, mais nous essayons de les documenter et d’expliquer comment y réagir. En fin de compte, tout système qui n’est pas systemd aura une certaine dose d’incompatibilité avec lui vu qu’il n’aura pas exactement la même structure d’exécution.
Notre but est que les différences entre les multiples distributions restent à un niveau minimum. Cela implique que les fichiers unité fonctionnent généralement bien sur une distribution différente de celle où ils ont été conçus, ce qui est un énorme progrès sur les scripts classiques d’initialisation qui sont très difficiles à écrire d’une façon portable à d’autres distributions Linux, compte tenu des nombreuses incompatibilités entre elles.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
Ce n’est pas vrai. Presque chaque interface D-BUS que fournit systemd est aussi accessible via un outil en ligne de commande, par exemple dans systemctl, loginctl, timedatectl, hostnamectl, localectl et autres. Vous pouvez aisément appeler ces outils depuis des scripts shell, ils donnent accès à pratiquement toute l’API depuis la ligne de commande avec des commandes faciles d’emploi.
Cela dit, D-Bus a aussi une interface (NdT : bindings) pour presque tous les langages de script de ce monde. Même depuis le shell on peut invoquer des méthodes D-Bus quelconques avec dbus-send ou gdbus. Finalement, cela facilite son utilisation dans des scripts grâce à la bonne gestion de D-Bus par les différents langages de script.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n’est pas vrai du tout. Nous proposons des outils de configuration, et leur utilisation vous fournit quelques fonctionnalités complémentaires (par exemple, la complétion en ligne de commande de tous les paramètres !), mais ils ne sont en rien nécessaires. On peut toujours modifier les fichiers en question directement si on le souhaite, et c’est totalement accepté. Bien sûr que quelquefois on a besoin de recharger explicitement la configuration d’un démon après l’avoir modifiée, mais ceci est vrai de la plupart des services UNIX.
systemd est instable et bogué
Selon nos données, certainement pas. Nous analysons minutieusement le système de suivi de bogues (NdT : bugtracker) de Fedora (et d’autres) depuis longtemps. Le nombre de bogues est très faible pour un tel composant central du système d’exploitation, surtout si on en retranche les nombreuses propositions d’améliorations (NdT : RFE) que nous enregistrons dans ce projet. Nous sommes plutôt bons pour maintenir systemd hors de la liste des bugs bloquant la distribution. Notre cycle de développement est plutôt rapide avec principalement des modifications incrémentales pour conserver un haut niveau de qualité et de stabilité.
systemd n’est pas déboguable
Faux. Certains sous-entendent que le shell était un bon débogueur. Hé bien pas vraiment. Dans systemd nous vous fournissons de véritables capacités de débogage. Par exemple, le débogage interactif, une traçabilité détaillée, la possibilité de masquer n’importe quel composant pendant le démarrage et plus encore. Nous fournissons aussi la documentation associée.
Il est sans aucun doute parfaitement débogable, nous en avons nous-mêmes besoin pour notre propre développement. Cependant nous reconnaissons une chose : il utilise des outils de débogage différents, dont nous pensons qu'ils sont plus appropriés à l’objectif.
systemd fait des changements pour le plaisir de changer
Largement mensonger. Nous avons à peu près uniquement des raisons techniques aux différents changements apportés, et nous les expliquons dans les multiples documentations, pages de wiki, articles de blogues et annonces dans les listes de diffusion. Nous faisons un réel effort pour éviter les changements incompatibles, et si nous y sommes contraints, nous essayons d’en documenter en détail la cause et la modalité. Et s’il vous reste des questions, n’hésitez pas à nous les poser !
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
C’est faux. Actuellement (NdT : 2013-01-16), il y a 16 développeurs avec le droit de commit sur le dépôt git. Dans ces 16 développeurs, seulement 6 sont employés par Red Hat (NdT : le compte a changé depuis). Les 10 autres sont des gens d’ArchLinux, de Debian, de Mageia, d’Intel, de Pantheon et même de Canonical, ainsi qu’un certain nombre de gens de la communauté. Et ils font souvent de grosses modifications et des changements majeurs. Ensuite, il y a aussi les 374 particuliers avec des patchs dans notre dépôt. Ils viennent aussi d’horizons et d’entreprises variés et plusieurs ont bien plus qu’un seul patch dans le dépôt. Les discussions sur le futur de systemd sont faites de façon ouverte sur notre canal IRC (#systemd sur freenode, vous êtes les bienvenus), sur notre liste de discussion et lors de nos hackfests publiques (comme la prochaine qui aura lieu à Brno, où vous êtes cordialement invité). Nous assistons régulièrement à diverses conférences pour avoir des retours, pour expliquer ce que nous faisons et pour quelle raison, à un degré que peu de projets font. Nous gardons à jour les blogs, nous engageons la discussion sur les réseaux sociaux (nous avons du contenu assez intéressant sur Google+, et notre communauté Google+ est relativement vivante aussi), et nous tentons ardemment d’expliquer pourquoi et comment on fait les choses et on écoute les retours, afin de trouver où sont les soucis (par exemple, avec ces retours, nous avons écrit cette liste de mythes courants sur systemd…).
La plupart des contributeurs à systemd partagent probablement une idée grossière de ce à quoi un bon système d’exploitation devrait ressembler, ainsi que le désir de la voir se concrétiser. Cependant, par la nature Open Source même du projet et son implantation dans la communauté, systemd est simplement ce que les gens veulent qu’il soit et si ça n’est pas ce qu’ils veulent, ils peuvent influencer la direction du projet avec des patchs et du code, et si ça n’est pas possible, il y a alors de nombreuses autres options à épuiser. systemd n’est jamais fermé.
Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS. Dans ce cadre, nous adoptons parfois une méthode spécifique à une distribution et l’utilisons par défaut pour systemd dans le but de pousser gentiment tout le monde vers le même ensemble de configurations de base. Ce n’est cependant pas une obligation, les distributions peuvent continuer de le faire à leur manière. Cependant, si elles finissent par adopter le standard, leur travail devient plus simple et elles peuvent gagner une fonctionnalité ou deux. Actuellement, la plupart des standards que nous avons adoptés venaient de Debian plutôt que de Fedora/RHEL. Par exemple, les systèmes qui utilisent systemd stockent généralement leur nom d’hôte dans /etc/hostname, ce qui était auparavant spécifique à Debian et maintenant utilisé sur plusieurs distributions.
Une chose que je vous accorde cependant est que nous pouvons certaines fois avoir l’air de monsieur-je-sais-tout. Nous essayons d’être préparés à chaque fois que nous ouvrons notre bouche, dans le but de soutenir nos affirmations. Cela peut nous faire passer pour des monsieur-je-sais-tout.
De façon générale, effectivement, quelques-uns des plus influents contributeurs de systemd travaillent pour Red Hat. Cependant ils sont une minorité et systemd est une communauté saine et ouverte avec différents intérêts, différentes expériences, simplement unifiée par quelques idées grossières de la direction à prendre, une communauté où le code et sa conception comptent, mais certainement pas l’affiliation à une entreprise.
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Absurde. Depuis ses débuts systemd gère l’option --with-rootprefix= pour son script configure, ce qui vous permet de dire à systemd de bien séparer les choses nécessaires au début du démarrage de celles nécessaires plus tard. Toute cette logique est complètement présente et nous la gardons à jour dans le système de compilation de systemd.
Bien sûr, nous ne pensons toujours pas qu’amorcer sans /usr disponible est une bonne idée, mais nous le prenons parfaitement en charge dans notre système de compilation. Cela ne corrigera pas les problèmes inhérents du procédé que vous rencontrerez partout, mais vous ne pouvez pas accuser de cela systemd, car dans systemd nous le gérons très bien.
systemd ne permet pas de remplacer ses composants
Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près. Et ces exceptions (comme journald) en général vous permettent d’utiliser une alternative côte à côte tout en coopérant avec elle.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Cette affirmation est déjà contradictoire en elle-même : D-Bus utilise les sockets comme transport. Donc, chaque fois que D-Bus est utilisé pour envoyer quelque chose, une socket est utilisée. D-Bus est pour majeure partie une sérialisation standardisée de message à envoyer à travers ces sockets. Cela le rend plus transparent, car ce format de sérialisation est bien documenté, compris, et il y a de nombreux outils de traçage et des liaisons de langage (language bindings). C’est complètement à l’opposé des habituels protocoles maison que les divers démons Unix classiques utilisent pour communiquer localement.
Hum, ai-je écrit que je voulais briser juste « quelques » mythes ? Peut-être qu’il y en avait plus que quelques-uns… Quoi qu’il en soit, j’espère que j’ai réussi à éliminer certaines idées fausses. Merci de votre temps.
Aller plus loin
- Site officiel de systemd (201 clics)
- Dépêche: « Évolutions techniques de systemd » (304 clics)
- Les 30 plus grands mythes à propos de systemd (233 clics)
# _o/
Posté par sirrus . Évalué à -10.
Preums !
# On est gâtés!
Posté par FantastIX . Évalué à 10.
C'est sympa d'avoir publié cette dépêche un troll-di 13! C'était prémédité? ;-)
Ceci dit merci pour la traduction. Après la dépêche sur le nouveau noyau Linux, nous voilà gâtés.
# Petit retour d'expérience
Posté par eric1803 . Évalué à 2. Dernière modification le 13 juin 2014 à 13:20.
Tout cela est bel et bon mais je voudrais vous faire part d'un petit retour d'expérience:
PC principal : debian/unstable+ experimental boot super long a cause d'un no-auto sur un fs dans le fstab qui doit être noauto pour systemd. Correction du bug. Pas de shutdown à cause de bug dans les script d'init de samba. 3 semaines pour avoir le fix officiel (patché dans la minute sur le PC). Ensuite pas de son (carte audio analogique pas détectée par pulse + extrême lenteur du démarrage a cause d'un probloème de dbus. Problème non corrigé à ce jour. Et si vous revenez en arrière a sysv init pas de montage de périphérique USB a cause des dépendences introduite entre policykit/dbus/usdisk2/libpam-systemd
PC de boulot: idem bug pulse audio.
NAS sous debian : pas de boot après migration. Je pense que le raid n'etant pas en noauto et vu que le script NFS introduisait un deadlock (corrigeai depuis), j’avais aucune chance.
Ah et si vous avez customisé votre distrib (installé votre propre noyau mis un grub sans sans intramfs, mis un /usr différent de /) c'est même pas la peine d'y penser…
[^] # Re: Petit retour d'expérience
Posté par ʭ ☯ . Évalué à 10.
En fait tu expliques que Debian a mal intégré systemd et pulseaudio, et qu'ils sont pas réactifs?
O->
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Petit retour d'expérience
Posté par CrEv (site web personnel) . Évalué à 10.
Non, il explique que "debian/unstable+ experimental", parfois c'est instable ou expérimental. Heu…
[^] # Re: Petit retour d'expérience
Posté par kursus_hc . Évalué à -3.
"Unstable" dans "Debian unstable" veut dire "qui change souvent", pas "qui plante souvent". Par contre oui, "experimental" veut dire "experimental" :)
[^] # Re: Petit retour d'expérience
Posté par ariasuni . Évalué à 7.
Pour rappel, Unstable ça veut dire instable.
Source (site web de Debian)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par kursus_hc . Évalué à 2.
Encore une fois instable car
Pour croire que Debian Sid est "instable-qui-plante" il faut vraiment ne jamais l'avoir utilisé.
[^] # Re: Petit retour d'expérience
Posté par ariasuni . Évalué à 10.
Je dis pas que c’est inutilisable au quotidien, je dis juste que ce plaindre d’instabilités alors que le site web de Debian indique clairement que:
C’est un peu du foutage de gueule quand même (surtout quand ça marche très bien chez d’autres personnes qui sont sur d’autres distributions).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par kursus_hc . Évalué à -1. Dernière modification le 18 juin 2014 à 01:22.
Oui bien sur c'en est, mon message allait dans ce sens mais je voulais préciser que sid est une distribution qui ne plante pas.
Quand systemd arrive dans sid, il marche. Et si il ne marche pas c'est une situation "anormale" qui est très rapidement corrigée. La qualité Debian se retrouve dans sid. C'est plutôt "testing" dans laquelle il n'est pas rare de voir des paquets cassés et qui a peu d'intérêt à être utilisée (et je ne parle pas d'experimental).
Le message sur le site de debian est plutôt un disclaimer sur l'abscence de support "officiel".
[^] # Re: Petit retour d'expérience
Posté par LeMagicien Garcimore . Évalué à 1.
Tu mélangerais pas Unstable (aka Sid) et Testing (aka Jessie) par hasard ?
Parce que le processus de développement standard c'est Unstable -> Testing -> Stable.
https://www.debian.org/releases/testing/
[^] # Re: Petit retour d'expérience
Posté par kursus_hc . Évalué à 2. Dernière modification le 18 juin 2014 à 02:30.
Non je ne mélange pas, ça peut paraître bizarre mais c'est comme ça.
Le but de testing est d'avoir une stable "stable". Si testing a besoin d'être cassée pendant 3 jours pour que la future stable soit plus stable, c'est ce qu'il se passera.
De l'autre côté unstable n'a aucun intérêt à être cassée. Elle doit même être "stable" pour que testing puisse y piocher des paquets. Si un paquet sort d'experimental, chez debian, ça veut dire qu'il marche. Quand une techno lourde sort d'experimental, elle marche. Cela peut ne pas être le cas quand elle arrive dans testing, et encore plus au cours du temps.
[^] # Re: Petit retour d'expérience
Posté par barmic . Évalué à 8.
Oui mais faut pas être surpris si ça casse.
Pour rappel Sid ça vient aussi de Toy Story, c'est le gamin des voisins qui casse tous les jouets. Ça n'a pas était choisi par hasard.
Experimental est là pour des paquets qui bloqueraient le travail de trop de contributeurs.
Donc oui c'est utilisable au quotidien, mais se plaindre que ça plante n'est pas très pertinent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petit retour d'expérience
Posté par Bigon . Évalué à 7.
C'est moi qui aie fait les changement dans policykit/udisks2 pour utiliser logind (à la place de ConsoleKit) dans Debian.
Normalement si une session logind est ouverte, tout devrait fonctionner. Y a une bug qui a été ouvert pour ça?
[^] # Re: Petit retour d'expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
Et pas de mise en veille non plus, pour les mêmes raisons de trucs machins BiduleKit qui ont changé.
Je n'ai pas ouvert de bug parce que je n'ai aucune idée des paquets concernés par ces lennarteries.
[^] # Re: Petit retour d'expérience
Posté par Bigon . Évalué à 5.
Le paquet
systemd-shimest installé?[^] # Re: Petit retour d'expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Non. Il faudrait ?
Pour info, j'avais relaté cela ici : http://tanguy.ortolo.eu/blog/article128/ck-allow-suspend-xorg-disable-monitor
Quelqu'un m'avait fourni une solution simple, que je n'ai pas encore eu le loisir d'essayer, mais de toute façon, parti comme c'est je sens que je vais faire encore plus simple et mettre ce qu'il faut (halt, reboot et compagnie, ainsi que les pm-suspend et pm-hibernate) en setuid root et exécutable par le groupe powerdev uniquement. Une bonne vieille solution à la Unix qui marche partout et tout le temps.
[^] # Re: Petit retour d'expérience
Posté par Bigon . Évalué à 3. Dernière modification le 13 juin 2014 à 15:59.
Oui,
systemd-shimimplémente une émulation pour certains services qui autrement sont fournis par systemd PID1. En regardant rapidement le code, le suspend est implémenté en appelant les scripts depm-utils.Dans unstable
libpam-systemddépend desystemd-sysv|systemd-shimpour cette raison.Au passage, le support pour le suspend et hibernation a été retiré de upower 0.99.
[^] # Re: Petit retour d'expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Et à quoi sert donc encore UPower au juste ? Et quelle commande faudra-t-il exécuter pour lancer la mise en veille du coup ? Une invocation D-Bus avec d'autres paramètres ?
[^] # Re: Petit retour d'expérience
Posté par gnumdk (site web personnel) . Évalué à 3.
systemctl suspend?
[^] # Re: Petit retour d'expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5. Dernière modification le 13 juin 2014 à 16:12.
Ceci dit j'apprécie le fait d'avoir une commande simple, parce que l'invocation D-Bus de UPower mal documentée, ça ressemblait sérieusement à de la magie noire.
[^] # Re: Petit retour d'expérience
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Bon, comme il me faut quelque chose qui marche, je sens que je vais devoir repasser au bon vieux sudo ou aux exécutables setuid. Propre, simple, compréhensible et surtout, ça marche.
[^] # Re: Petit retour d'expérience
Posté par neil . Évalué à 2.
Perso le
sudo pm-suspendne fonctionne plus (problème d’hibernation de carte son et wifi notamment). Mais tout fonctionne correctement à travers systemd.[^] # Re: Petit retour d'expérience
Posté par Bigon . Évalué à 3.
UPower permet maintenant uniquement d'obtenir des informations concernant l'énergie sur la machine et les devices (souris sans-fil et co).
systemctla l'air de faire cela ou sinon appeler la méthode dbusorg.freedesktop.login1.suspendje suppose[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à 1.
Oui c'est obligatoire si tu veux à la la fois le nouveau udisk2 et rester en sysv init.
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à 1.
Je confirme. Mais il y a déjà un bug ouvert je crois.
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à 3.
Le pb c'est qu'avec systemd j'ai des bugs inacceptable sur l'audio et que j'ai du resinstaller sysvinit-core => du coup pas de logind/lipam-systemd ou alors ca marche pas.
[^] # Re: Petit retour d'expérience
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 13 juin 2014 à 19:20.
systemd c'est devenu l'Union Européenne : quoi qu'il arrive, c'est sa faute! (on réfléchira après, ou pas du tout, sur le rapport entre le reproche ou l'outil accusé). C'était mieux aaaaaaaaaaaaaavant.
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à 3.
Oui sauf que le simple fait de repasser en sysv5 init et l'audio remarche. Le bug est ouvert chez debian avec toutes les traces. Dans le même genre de philosophie de comptoir, l'herbe est toujours plus verte à coté. Pour moi le bilan est pour l'instant négatif.
[^] # Re: Petit retour d'expérience
Posté par LeMagicien Garcimore . Évalué à 4.
s/systemd/la version unstable+experimental de ma distribution, avec l’intégration en cours de systemd,/
Fait des retour d’expérience vers les mainteneur, propose des patchs… mais ne viens pas te plaindre que systemd ça ne marche pas quand c'est clairement pas lui le problème.
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à -4.
C'est bien lui le problème…
[^] # Re: Petit retour d'expérience
Posté par LeMagicien Garcimore . Évalué à 8.
Et comment peux-tu affirmer ça ?
Allons vite prévenir RH, parce que RHEL7 va être une catastrophe !
Si tu veux un OS qui fonctionne bien, avec des packages assez a jour, installe Jessie. Mais ne viens pas nous les briser parce que Sid est cassé. Mettre Sid sur un NAS faut aimer vivre dangereusement quand même…
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à -6.
Et comment peux tu affirmer le contraire? Tu as les log de ma machine et les straces du pb?
[^] # Re: Petit retour d'expérience
Posté par Anonyme . Évalué à 10.
En constatant que sur une autre distro utilisant systemd, ca fonctionne très bien.
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à -7.
CQFD
[^] # Re: Petit retour d'expérience
Posté par Albert_ . Évalué à 3.
Une autre distro qui a eu bizarrement aussi droit a la primeure de PA et ou cela marchait comme systemd alors que cela plantait partout ailleurs. Je me demande bien quel est le point commun entre ces deux technos et la distrib en question…
[^] # Re: Petit retour d'expérience
Posté par barmic . Évalué à 2.
Affirmer le contraire est falacieu, seul les mainteneurs Debian peuvent t'aider mais pour ça il faut les contacter plutôt que de baver sur systemd sans savoir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à -10.
Et tu crois que je t'ai attendu? Je vois que le geek est tjs aussi sûr de détenir l'unique vérité. Ca te passera avec l'age ;-)
[^] # Re: Petit retour d'expérience
Posté par barmic . Évalué à 4.
Si tu avais posté un rapport de bug à ce sujet ou un mail dans une mailing list et qu'un mainteneur de systemd dans Debian t'aurais dis que ça viens effectivement d'upstream, etc, tu te serais fais un plaisir de nous donner le lien pour appuyer ton propos d'une personne qui a plus de poids dans ce genre de discussion.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Petit retour d'expérience
Posté par eingousef . Évalué à 5.
Pour monter les disques externes en simple utilisateur, sans utiliser policykit, tu peux utiliser des programmes comme pmount. Ou alors jouer avec sudo, mount et udev, mais c'est moins pratique. Mais ça s'utilise en ligne de commande, pas directement via l'explorateur de fichiers (ou alors j'ai pas trouvé comment faire).
*splash!*
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à 1.
C'est/c'était jouable avec policykit
more 10-mount.rules
polkit.addRule (function (a,s) {
if (a.id.indexOf ('org.freedesktop.udisks2.') == 0 && s.isInGroup(plugdev))
return polkit.Result.YES;
});
A marché jusqu'à la modif udisk2
[^] # Re: Petit retour d'expérience
Posté par ariasuni . Évalué à 4.
less is more. Utilise plutôt:
En effet, dans le manuel de less, on peut lire:
Ou alors tu peux aussi utiliser most, parce que most is more than less. :p Plus d’infos
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par hokata . Évalué à 1.
De mon côté avec Debian Unstable XFCE depuis quelques années, j'ai eu de gros problèmes avec systemd et notamment avec la mise en veille.
Dès le passage sur systemd mon PC portable se mettait en veille automatiquement lors de la fermeture de l'écran. Or le retour de la mise en veille ne marche pas et freeze le PC.
Pas eu le temps de regarder et le disque dur n'a pas survécu.
Réinstallation en Debian Testing Gnome sur un nouveau dd => impossible d'éteindre le PC sans passer par un sudo halt, car systemd n'est pas activé comme système d'init.
Repassage en Debian Unstable Gnome, même problème que précédemment avec la mise en veille.
Conclusion, on va revenir en Debian Stable + Backports quelques temps et faire des tests via VM.
[^] # Re: Petit retour d'expérience
Posté par ariasuni . Évalué à 4.
Je n’ai plus le problème depuis un moment, mais si ça persiste tu peux éditer
/etc/systemd/logind.confet y ajouter la ligneHandleLidSwitch=no.À part ça, je n’ai jamais eu de problèmes de ce type avec systemd, pourtant j’utilise systemd depuis que c’est dispo sur Arch en gros.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Petit retour d'expérience
Posté par Argon . Évalué à 10.
Pour contre balancer ton post de "chez moi il y a rien qui marche", bah chez moi tout marche je n'ai jamais eu de soucis avec pulseaudio (et j'utilise des sortie différentes, du bluetooth, du casque audio usb, etc…) et systemd. J'ai 1 PC Fixe récent sur Archlinux, un portable plutôt vieus sur Archlinux, un PC Fixe plutôt vieux sur Archlinux et quelques VMs içi et là.
En fait le seul truc où je bute c'est d'utiliser systemd avec mpd.
A part ça quand j'ai commencé avec systemd c'était dur c'est clair, beaucoup de possibilités, de commandes et tous les automatismes acquis réduit à zéro. Mais après 2 ans de systemd je ne peux plus m'en passer quand quelques choses se passe mal tout est très facile à identifier/réparer/maintenir.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Petit retour d'expérience
Posté par eric1803 . Évalué à -3.
Chez debian c'est sûr que c'est tout chaud comparé à d'autres distribs.
D'un autre coté, quand je vois la taille de systemd et l'approche de la récriture intégration de tout je dois dire que mon expérience ne me prédit rien de bon.
[^] # Re: Petit retour d'expérience
Posté par Yannick . Évalué à 2.
Et bien moi c'est l'inverse. Les seule distributions avec qui j'ai eu des problèmes avec systemd, ce sont Fedora et Archlinux.
Avec Debian, aucun problème. Ce n'est certes pas la dernière version de systemd, mais je trouve que l'intégration par les mainteneurs est bien faite. Comme quoi, les expériences…
[^] # Re: Petit retour d'expérience
Posté par Argon . Évalué à 1.
J'espère que tu te rends compte que mon post était ironique hein ?
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Petit retour d'expérience
Posté par vv222 . Évalué à 6.
Une Debian Sid à jour, avec XFCE.
Systemd comme système d'init.
Tout fonctionne parfaitement. Absolument tout.
Maintenant, doit-on généraliser ton expérience ou la mienne ?
[^] # Re: Petit retour d'expérience
Posté par cluxter . Évalué à 6.
Si je comprends bien, tu te plains/tu t'étonnes d'avoir des bugs sur une version Beta (Unstable) ou même carrément Alpha (Experimental) de Debian ?
Etrange…
# Correction
Posté par cosmocat . Évalué à 3.
"c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git"
[^] # Re: Correction
Posté par cosmocat . Évalué à 4.
"systemd n’a pas de raison de ne pas être portable"
[^] # Re: Correction
Posté par cosmocat . Évalué à 3.
[^] # Re: Correction
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Merci, corrigés.
[^] # Re: Correction
Posté par Snark . Évalué à 2.
Dans le titre: "systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient"—j'imagine que ce sont SES mainteneurs qui sont visés?
Et avant, mais je n'ai pas noté, il y avais des emplois du verbe coûter sans l'accent circonflexe.
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
couter. (cf. ma signature :P)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Oui mais ça c'est l'orthographe de 1990, et dans certains cas, notamment celui-ci, c'est hideux.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Donc c’est une orthographe valide.
Et si je te dis que je trouve que coûter c’est hideux, on fait quoi?
Si j’écris de cette façon, c’est parce que je trouve ça plus logique et plus simple: si on peut justement l’accent circonflexe dans forêt ou hôpital parce qu’on dit forestier et hospitalier, quelle justification peut-on trouver pour coûter?
Et tout ce qu’on me répond c’est «c’est moche». Nan mais à ce moment-là la prochaine fois qu’on me parle de GNOME Shell je n’argumenterais pas, je dirais juste «c’est moche».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par barmic . Évalué à 3.
Je n'ai aucune idée du pourquoi mais des fois on remplace l'accent circonflexe par un « s » placé après la lettre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
Avant (il y a très très très longtemps hein) on disait couster, hospital, forest. On a cessé de le prononcer de cette façon, mais on a quand même mis un accent pour la prononciation et pour dire que quand même il y avait un s avant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par sebas . Évalué à 3. Dernière modification le 13 juin 2014 à 20:22.
Au Brésil, encore aujourd'hui, on dit hospital, floresta, custar, hostelaria, j'imagine que la racine commune vient du bas-latin. En tout cas, c'est super-pratique de parler portugais pour savoir où mettre les accents circonflexes ;-)
[^] # Re: Correction
Posté par William Steve Applegate (site web personnel) . Évalué à 3. Dernière modification le 13 juin 2014 à 22:00.
Ou italien. Sans doute aussi castillan, et d'autres langues latines qui ne font pas dans la complication comme le français (on est vendredi, j'ai le droit). Par ailleurs, je remercie les Belges et les Suisses pour septante, octante et nonante qui sont quand même plus logiques que leurs contreparties made in France.
De toute manière, la question va être bientôt réglée : après les fichiers de configurations différents, Lennart estime que les différences d'écriture entre locuteurs rendent la compréhension mutuelle compliquée, aussi la prochaine version de systemd uniformisera tout cela en intégrant un correcteur orthographique qui vous forcera à utiliser la bonne orthographe (celle que Lennart aura choisi pour vous, bien évidemment).
Envoyé depuis mon PDP 11/70
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Je ne peux que plussoyer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Sufflope (site web personnel) . Évalué à 3.
Et moi je ne suis pas d'accord. J'aime bien le Système vicésimal, je fais la tortue sur mon lit pour compter sur mes vingt doigts.
Et encore je suis sympa avec vous mal-lotis, si je m'écoutais je compterais en base 21 :o)
[^] # Re: Correction
Posté par ariasuni . Évalué à 0.
Bah l’un n’exclue pas l’autre.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 13 juin 2014 à 23:10.
Oui, d'ailleurs l'un avec l'autre c'est le système vigésimal partiel, notamment soixante-dix et quatre-vingts-dix que tu critiquais :D
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Ah d’accord je viens de comprendre.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par tyoup . Évalué à 1.
C'est pas donné à tout le monde :-) il doit falloir y consacrer son temps et sa vie.
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 2.
En soi, ce n'est pas une invention des suisses et des belges mais bien des termes du français de France qui sont considérées comme valide d'ailleurs (mais considérés comme vieillis).
Ils n'ont pas persisté pour des raisons historiques obscurs, on sait bien que suivant les régions certaines expressions ou mots sont plus présents qu'ailleurs car la propagation de tout ceci est long (surtout avant l'existence de nos moyens de communications).
[^] # Re: Correction
Posté par Rolinh (site web personnel) . Évalué à 3.
En fait, en Suisse on dit huitante et pas octante. Sauf à quelques endroits, dont Genève notamment, où le quatre-vingt persiste malgré le fait que septante et nonante soient utilisés.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
ah j’avais pas fait gaffe, moi aussi je pensais à septante, huitante et nonante et pas à septante, octante et nonante.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par claudex . Évalué à 4.
Et en Belgique, on dit quatre-vingt, mais on dit bien septante et nonante.
« 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: Correction
Posté par ariasuni . Évalué à 2.
Ça marche quand même vachement les dérivés en français pour les français.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ben, si, justement, on veut garder la proximite' ! Pourquoi la foutre a la poubelle alors qu'elle a du sens ? Si t'en n'a rien a fiche, c'est ton probleme. Mais pour ceux qui apprennent le francais, c'est tres utile.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
C’est qui on?
J’ai pas dit qu’il fallait, j’ai juste réfléchi «à voix haute»… Au passage marrant la personne qui me gueule dessus parce que j’ai une idée qui «abimerait» le français mais qui ne met pas les accents qui sont pourtant très utiles, même pour les français. :)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
C'est le même "on" que celui dont tu parlais. Tu as oublié ?
Tu remarqueras que la tranche horaire à laquelle je poste des messages avec accents est toujours différente de celle à laquelle je poste des messages avec accents. Tu remarqueras aussi que j'ai souvent tendance à poster en fin de journée, voire en pleine nuit. Tu pourras alors inférer que je me trouve sur un autre continent, et que je n'ai pas accès à du bépo partout où je suis.
[^] # Re: Correction
Posté par jben . Évalué à 5.
Non mais cette excuse pourrie, à un moment ça suffit. Ça fait plusieurs années que j'utilise un qwerty-us en France ou ailleurs (actuellement ailleurs), et je ne vous pas en quoi ça pose un problème.
Tu peux avoir plein de raison de ne pas mettre les accents, allant de la mauvaise foi à la flemme en passant pas l'ignorance orthographique (ce qui est mon cas), mais le choix du clavier ne fait définitivement pas partie de ces raisons. Te viendrais-t'il à l'idée de poster sur un forum russe/chinois/whatever en utilisant que l'ASCII avec comme excuse « nan mais je ne sais pas faire autre chose avec mon clavier ».
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
Excuse pourrie, mais pourtant vraie. Sinon, je ne vois pas pourquoi juste la moitié de mes messages auraient les accents (y compris les espaces insécables) et pas les autres, et tu vois même que je note les « é » finaux comme « e' » ce qui montre bien que je n'ai pas de config avec les accents (sinon, autant écrire « é »).
Ça fait des années que je suis en bépo, mais je suis de temps à autres sur des machines sans bépo, et sans mon clavier (et je peux difficilement taper sur un clavier autre que le mien).
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
Ah c’est pour ça! Je croyais que c’était une faute de frappe.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . Évalué à 4.
C’est vrai que j’ai que ça à faire, vérifier les heures à laquelle les commentaires sont postés. :)
Bah dans la plupart des cas, tu peux avoir accès à une disposition de clavier avec des touches mortes pour les accents non? Enfin bon c’était juste une remarque comme ça, il y a tellement de commentaires sur Linuxfr sans accents qu’un de plus ou un de moins… :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 1.
Personnellement, je comprends un peu… étant au Japon, sur un laptop japonais, si je veux vraiment écrire correctement, je dois passer par un layout US international.
Sauf que voilà, le qwerty japonais, c'est pas vraiment encore pareil, toute la ponctuation est chamboulée, et au bout d'un moment, soit tu retiens de tête le layout US, soit tu switches toutes les 2 secondes quand tu veux une ponctuation.
Si on ajoute à ça que je travaille 50/50 en anglais et japonais, effectivement, j'écris parfois sans accents. C'est pas une excuse…
PS: US international c'est quand même super pratique quand j'écris en español, je sais pas comment je faisais avant. Si quelqu'un sait comment avoir des touches mortes avec un layout japonais sous Win7 (boulot oblige) je suis preneur ! Parce que bon, taper à l'aveugle, c'est pas vraiment ça quand même.
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Je ne sais pas comment ça fonctionne sous Windows, mais sous GNU/Linux c’est possible d’avoir la traduction des rōmajis vers des kanas utiliser n’importe quelle disposition.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 2.
(soupir) oui je sais, c'est une des choses qui me manquent le plus au boulot…
[^] # Re: Correction
Posté par nodens . Évalué à 1.
Essaie donc WinCompose. C'est libre, c'est gratuit, ça juste marche et c'est Sam qui l'a fait.
https://github.com/SamHocevar/wincompose
[^] # Re: Correction
Posté par Ytterbium . Évalué à 3.
Et surtout hôte et hote ne se prononceraient pas de la même manière :
- hôte se prononce comme tous les ô de la même manière que bateau (o phonétique)
- hote se prononcerait comme la plupart (tous ?) les o plutôt comme hotte (ou sort) (ɔ phonétique)
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
C’est vrai.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Thomas Douillard . Évalué à 1.
Ou pas, parce qu'entre le français théorique et le français pratique, en général on lève le sourcil quand on entend quelqu'un qui marque la différence théorique de prononciation.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Tu ne fais pas la différence (à l’oral) entre hôte et hotte?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Thomas Douillard . Évalué à 2.
Si mais les lettre redoublées sont déjà là et sont une règle bien plus commune. Genre entre ôter, oter ou hoter hôter (voire hoster en info /o\ ). Entre (hypothétiquement) cloture et clôture … le encore hypothétique "clotture" se prononcerait naturellement différemment par contre.
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Bah ôter et oter se prononce pareil, c’est hôte et hote qui ne se prononcent pas pareil à cause du e final (on dit bien moto ou coma).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Claude SIMON (site web personnel) . Évalué à 2.
Il y a aussi fenêtre : défenestration. Il existe d'ailleurs aussi fenestration, mais c'est moins courant…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Correction
Posté par esdeem . Évalué à 3. Dernière modification le 14 juin 2014 à 00:12.
Au hasard, l'étymologie ?
coûter, du latin constare, être fixé, avec une nuance de prix en bas latin, d'où avoir un prix.
Bon, soyons d'accord, c'est une truc de vieux cons qui ont fait de longues études dont je suis. Néanmoins, la piste étymologique tient encore la route…
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à -1.
Oui évidemment que c’est comme ça à cause de l’étymologie. Mais pour l’individu lambda, pour l’intérêt général, c’est quoi le plus important: que la langue soit simple ou que la langue soit plus proche du latin/grec?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Qu'elle soit comprehensible. Et la, pouf, l'etymologie donne des points a l'orthographe traditionelle.
[^] # Re: Correction
Posté par ariasuni . Évalué à 0.
Hé là, pouf, un argument sorti du chapeau. Parce que s’il faut connaitre l’étymologie d’un mot pour savoir l’écrire, c’est que la langue est mal foutue.
Or depuis la réforme de 1990, c’est quand même plus simple pour les accents circonflexes par exemple: je ne met jamais d’accent circonflexe sur i ni sur u sauf pour les cas où il pourrait y avoir ambigüité (sur et sûr, du et dû, etc) qu’il fallait déjà retenir avant, du coup ça fait quand même moins de trucs à retenir.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par esdeem . Évalué à 6. Dernière modification le 14 juin 2014 à 20:37.
C'est comme pour toute chose, il faut en apprendre les règles.
[ my life ]
Et du temps où j'étais enfant, dans les années 80, on avait, mais semble-t-il la chose ne se fait plus, des cours de français contenant grammaire, orthographe et vocabulaire, avec étude des mots de la même famille ainsi que les racines latines et grecques.
[ /my life ]
[ mon avis ]
Si ensuite on trouve que c'est inutile, on se contente d’utiliser quelques milliers de mots et on ne se plaint pas de ne pas connaître la langue que l'on parle, ni ses règles.
De même on ne met pas sur le compte de la complexité de la langue son propre manque d'éducation.
[ /mon avis ]
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Non, on étudie pas vraiment les racines grecques et latines… (sauf si on fait latin ou grec évidemment).
Pourtant la langue française est extrêmement complexe, et devant la brillante simplicité de l’espéranto, je trouve la complexité des autres langues indécentes. C’est pourquoi on devrait s’indigner devant un tel refus de voir la langue évoluer vers une plus grande simplicité.
En effet, certaines erreurs que les gens font régulièrement (et qui pourtant parle la langue tous les jours, je n’imagine pas pour les étrangers) sont la violation de règles qui n’ont aucun sens — en tout cas je n’ai jamais pu trouver une explication. Pourquoi un journal, des journaux, alors qu’on dit un chacal, des chacals?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par esdeem . Évalué à 5.
Ben en ce qui me concerne, ce fut le cas. De façon basique certes, mais tout de même.
Depuis quand l'évolution des langues tend-elle naturellement vers la simplicité ?
La règle, c'est -al/-aux (règle), un héritage du cas régime et du cas sujet de l'ancien français (explication). A-t-elle un sens a part celui de l'héritage ? Va savoir…
Après se tromper sur les exceptions, c'est plus compréhensible.
Quant à chacal, c'est un mot d'origine turque entré en français au 17e siècle, dont effectivement le pluriel ne suis pas l’alternance -al/-aux (qui n'est du coup pas étymologique).
La plupart des mots empruntés ne prennent pas naturellement, ni immédiatement un pluriel "régulier".
Cela dit, il n'y a pas nécessairement de bonne raison à une irrégularité…
Pour en revenir à la complexité de la langue française, je suis d'accord avec toi, elle est relativement importante. Je comprends parfaitement que l'on veuille tendre vers une simplification des irrégularités. Mais une décision de ce genre se heurte à l'usage. Le français n'est pas à sa première phase de « régularisation » et contient en effet toujours des bizarreries, par exemple l'emploi du système vigésimal pour certains nombres.
Mais cela s'apprend.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à -1.
Depuis qu’on a inventé l’académie française et d’autres qui définissent l’orthographe et la grammaire à partir de l’existant. Sinon on écrirait encore le français comme on veut.
Pluriels des mots en -al.
Une centaine de mots, ça fait quand même une tripotée d’exceptions. L’exemple du -al me frappe tout particulièrement parce que j’entends régulièrement des gens — français depuis la naissance, qui parlent correctement tout ça — faire cette erreur, même moi ça m’arrive, et j’en suis venu à la conclusion que ça complexifiait la langue pour rien.
Il n’y a pas de bonnes raisons à une irrégularité, il n’y a que des excuses.
C’est quand même un peu dommage que l’on doive étudier l’étymologie des mots — ou apprendre des milliers d’exceptions et des centaines de règles — pour savoir comment s’écrivent où se prononcent certains mots. Je ne dis pas que c’est inutile, mais que la langue devrait se suffire en elle-même un maximum. Et ça devient de pire en pire avec l’arrivée de mots anglais alors que dans la plupart des cas, un équivalent français existe.
Je ne comprends pas, on dirait que personne ne soutient l’idée de l’amélioration du français; c’est souvent un «l’orthographe de 1990 sapu»/«ça se heurte à l’usage»/etc et ça s’arrête là. Pourtant dans le domaine des logiciels libres, ça ne serait pas la première fois qu’on fait quelque chose qui se heurte à l’usage.
Il suffirait que suffisamment de gens écrivent et parlent d’une certaine façon et ça rentrerait dans l’usage, mais évidemment si tout le monde trouve que c’est une mauvaise idée… Et je sens qu’on va me ranger dans la même case que les gens de l’ortograf (mais qui ont le mérite de pointer un vrai problème).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Maclag . Évalué à 5.
La langue parlée est très différente du logiciel libre. Le logiciel a vocation à être efficace, la langue porte avec elle une histoire et fait partie de la culture.
On ne peut pas la simplifier comme un bête outil de communication logique et cohérent, on lui enlèverait son âme.
Alors oui, du coup, on enchaîne les règles et les exceptions comme un ensemble pas forcément très cohérent et bien construit. L'Esperanto pour ça semble super.
Mais puisque je deviens un vieux con, je trouve plus de charme à une vieille maison dont la déco est un bric-à-brac de choses accumulées au cours de l'histoire de ses occupants plutôt qu'un bloc de béton tout neuf avec une déco post-moderne fade faite par un décorateur pressé.
Quant à l'usage, c'est ce qui a fait évolué la langue depuis toujours, et c'est bien pour ça qu'on parle Français, Italien ou Espagnol et pas Latin.
[^] # Re: Correction
Posté par Thomas Douillard . Évalué à 4.
Si on pouvait préserver la culture sans torturer les écoliers et les dyslexiques, ce serait pas mal :)
Et puis finalement écrire une nouvelle page de l'histoire de notre langue, c'est pas une trahison de la culture, c'est juste enrichir le livre …
[^] # Re: Correction
Posté par esdeem . Évalué à 2.
Remarque non seulement pertinente, mais poétique !
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Une langue nationale a vocation à permettre aux individus d’un même pays (au moins) de communiquer. La langue peut porter une histoire et une culture tout en évoluant, la preuve: jusqu’à maintenant, le français a énormément changé et continuera de changer. La langue s’enrichira probablement encore; mais à nous de faire en sorte que ça évolue vers plus de simplicité lorsque c’est pertinent.
Réaction typique. Dans de nombreux, cas on le peut; cf. le cas du pluriel en -al. C’est pas parce qu’on ne peut plus faire la blague «un chacal, des chacaux» que ça tue la langue.
Rha mais la mauvaise fois quand même. Tu parles de «déco fade» et de «décorateur pressé», ton exemple est complètement biaisé.
Mais malgré le fait que ça soit une langue horrible, j’aime bien le français. Mais il faut aussi savoir remettre certaines choses en question, et au lieu d’encourager ce genre de réflexion, on les casse net en disant que c’est pas possible à cause de l’histoire et de la culture.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par esdeem . Évalué à 0.
On peut abandonner derechef l'idée de langue nationale et ton assertion reste valide.
Euh, pas mieux ?
Parce que tout ton discours n'est fait que de bonne foi ?
Commence par reconnaître que tu n'as pas nécessairement raison mais un avis, et que ceux qui ne sont pas du tien ont aussi peut-être quelque chose d'intéressant à dire.
C'est probablement la différence fondamentale entre nous : j'ai toujours considéré que le français avait du charme.
Moi de même. Et heureusement, nous n'avons pas le monopole de ce sentiment envers notre lingua franca.
[PS HS]
J'ai bien ri en voyant cette image s'afficher alors que j'éditais ma bafouille.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
Bah oui, «elle perd son âme» c’est très vague et très orienté. Alors que si tu me dis que ne plus avoir de pluriels en -aux augmente l’uniformité de la langue et donc la rend moins poétique, ça c’est déjà plus un argument. Je pense néanmoins que c’est faux, puisque plein de langues ont des pluriels réguliers sans que cela ait empêché des gens de faire de la poésie, du chant, etc — et si vous pensez que le charme du français tiens à ces exceptions, je vous dirais que vous avez une bien mauvaise opinion du français.
Mais c’est ce que je m’efforce de faire, même si je n’y arrive pas forcément. Je ne me souviens néanmoins pas avoir dit que j’avais raison et que tu avais tort globalement, j’ai par contre affirmé que cet argument en particulier était moisi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par esdeem . Évalué à 2.
Tu ne réponds pas à la question ! Je parlais d'évolution naturelle. Cela dis, même sans cela, ta réponse est factuellement et temporellement fausse. N'as-tu jamais entendu parler de la Pléïade, qui par son œuvre prolifique a « standardisé » le français tout en faisant exploser le vocabulaire en piochant dans les racines grecques et latines de la langue qu'elle défend depuis son manifeste ?
Quel argument ! je suis sans voix…
Ton argumentaire se base sur l'idée que parce que tu parles ta langue maternelle, tu en devrais avoir la pleine conscience. Toute chose doit être apprise. Si tu fais fi de cela, forcément, tout est compliqué à comprendre.
Et le français aurait enfin une langue fille, ou presque…
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par anaseto . Évalué à 2.
Apprendre la langue maternelle, c'est quand même de toute façon ce qui prend le plus de temps aux enfants pendant leurs premières années à l'école, ce n'est pas quelque chose de facile. Avec le français, ce travail est multiplié et compliqué, au point que beaucoup ne parviennent jamais à le maîtriser suffisamment pour ne pas être pénalisés dans la suite de leurs études. C'est un facteur d'inégalités sociales regrettable, d'autant plus que tout le monde n'est pas logé à la même enseigne sur le sujet, et en fonction du milieu auquel il appartient aura plus ou moins de chances de faire partie de ceux qui seront pénalisés. Bref, je ne dis pas qu'il y a une solution facile au problème, mais il y a quand même un problème, et d'autres pays en souffrent beaucoup moins.
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
Tu as tout à fait raison, c’est d’ailleurs une des raisons pour lesquelles j’ai cette idée de simplification du français qui me trotte dans la tête, et aussi la raison pour laquelle j’adore l’espéranto.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par esdeem . Évalué à 3. Dernière modification le 15 juin 2014 à 20:56.
Effectivement, ça peut l'être, mais combien qu'autres points plus dramatiques le sont qui ajoutent à ces inégalités sociales ? Le plus important d'entre eux n'est pas non-maîtrise la langue, celle-ci n'en est souvent que le symptôme.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par anaseto . Évalué à 1.
Je suis d'accord que d'autres pays avec une langue plus facile s'en sortent quand même très bien pour créer des inégalités sociales. Ceci dit, parmi les inégalités sociales liées aux compétences, je pense que la langue n'est pas à négliger : c'est une des compétences les plus dures à acquérir (le temps se compte en années, pas en mois), demandée très jeune, et qui constitue une barrière efficace. Et d'autant plus s'il y a d'autres problèmes plus profonds : en rajouter un qui représente des années d'apprentissage ne va pas aider.
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Je pense que la plupart des gens sont comme toi et sous-estimes l’importance de la langue. À l’école, il faut lire, toutes les leçons, tous les supports de cours (en tout cas les plus importants et les plus nombreux) sont sous forme d’écriture; on repère tout de suite les gens qui parlent et/ou écrivent mal le français et ça les freine fortement dans la vie; il est facile de balayer les arguments de quelqu’un en ne retenant que la forme et en se moquant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Maclag . Évalué à 3.
Donc tu préfères cacher la poussière sous le tapis plutôt que trouver des solutions pour aider les élèves qui ont des difficultés d'apprentissage?
Comme tu dis, la langue, c'est flagrant. Souvent, les autres matières suivent, parce que le problème, ce n'est pas la langue!
Les Chinois, Taiwanais et Hong-Kongais ne sont pas les élèves les plus nuls du monde, pourtant ils partent avec un sérieux handicap à la lecture et l'écriture.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Où est-ce que j’ai dit ça? Si tu aides un élève, bah le prochain faudra l’aider de la même manière. Si tu simplifies la langue, tu aides tous les nouveaux apprenant, et les élèves ont alors un peu moins besoin d’aide.
Par ailleurs, les dyslexiques ont énormément de mal avec des langues telles que l’anglais et le français par rapport à des langues plus simples au niveau de la prononciation comme l’italien ou l’espagnol — ou l’espéranto.
Non, mais plus les difficultés s’accumulent, plus c’est difficile, alors si on peut leur épargner de la peine inutile pour se concentrer sur des matière ou la complexité n’est pas réductible, ça serait vraiment bien.
Pour eux je ne sais, mais j’ai lu que les Kanjis sont un problème pour les japonais, pour lire les journaux par exemple.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Je te rassure : les gens qui lisent les journaux n'ont pas de problèmes en kanji, et inversement… Il y a une forte corrélation entre la capacité à lire/écrire et la volonté de le faire.
Notons par ailleurs que le fait de connaitre l'étymologie aide à l'écriture, à la lecture, et à la compréhension aussi en japonais/chinois/coréen. Et c'est pas un luxe.
Par ailleurs, une autre difficulté du japonais (et du coréen), c'est la politesse. C'est souvent enseigné ou poli en entreprise une fois qu'on a fini ses études. Rien ne t'empêche de ton côté te mettre maintenant à l'orthographe et l'étymologie.
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
C’est donc bien un problème.
L’étymologie en japonais… Tout un programme. :)
Ah voui, ça doit être bien chiant ça. :/
Je n’ai pas compris le rapport avec la phrase d’avant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
] C’est donc bien un problème.
Mon point était que les gens qui se plaignent sont ceux qui sont désintéressés. « Quand on veut, on peut. »
]] Rien ne t'empêche de ton côté te mettre maintenant à l'orthographe et l'étymologie.
] Je n’ai pas compris le rapport avec la phrase d’avant.
Ben, je voulais dire que tu peux te mettre au grec et au latin, et tu trouveras alors le français vachement logique et plus simple. Il n'est pas trop tard !
[^] # Re: Correction
Posté par ariasuni . Évalué à 4.
C’est pas parce que des gens y arrivent qu’on doit laisser ça comme ça, sinon on avance pas… Si on a l’eau courante, c’est pas parce qu’on arrivait pas à avoir de l’eau sans.
Je préfère apprendre des langues vivantes. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par robin . Évalué à 6.
J'ai effectué avec plaisir 7 ans d'étude de latin, deux de grec, j'adore l'étymologie, j'ai été un excellent lecteur dès mon plus jeune age jusqu'à ma première environ (j'ai notamment dans mes faits d'armes la trilogie du seigneur des anneaux en 1 mois à 11 ans), au collège, je connaissais par cœur la très grande majoritée des règles de grammaire,…
J'avais donc tous les atouts pour être très bon en orthographe. Malgré cela, je suis réellement nul en français à un point qui me déprime. Les (déjà) nombreuses remarques que j'ai eu sur linuxfr ne font que le confirmer. Quand je suis fatigué, je fait au minimum une faute tout les huit mots, et quand je suis en forme, après relecture, j'ai énormément de mal à écrire plus de 60 mots de suite sans fautes.
Je suis donc au regret de te dire que pour moi
systemd ne marche pasl'orthographe du français est trop compliquée.Pour moi, ce qui fait la richesse et la beauté du français c'est son vocabulaire poétique, le fait que le sens des mots s'affinent avec le contexte, que la conjugaison soit très précise (on peut exprimer des rapports temporels de manière très précis), et enfin l'ordre des mots (qui est très différent de celui du latin). Le français est une très belle langue, tant à l'oral qu'a l'écrit de par sa construction et son vocabulaire, aucunement de par ses aberrations d'illogismes à l'écrit.
Ce qui me gène le plus c'est que le français oral n'a pas de correspondance directe avec le français écrit (de l'écrit vers l'oral c'est plus simple). Par exemple, le son « o » a de nombreuses écritures, il y a de nombreuses lettres muettes, les doublements de consonnes sont relativement aléatoires (et pas forcément constant dans une même famille de mots). Les exceptions du type « al/aux » sont moins grave, vu qu'elles se retrouvent également à l'oral.
Quand j'ai commencé à étudier le latin en 5ème, au bout de deux heures de cour, notre prof nous à fait une dictée en latin. Nous savions tous écrire en latin, malgré le fait que nous ne comprenions rien à cette langue. Au bout de cinq ans d'étude, j'estime avoir commencé à en voir les subtilités, ce qui m'a permit d'en profiter pendant encore deux ans. Découvrir les arcanes d'une autre langue m'a permis de mieux comprendre la richesse de ma langue. En revanche, pour le français, au bout de près de 20 000 heures de cours (soit 16 ans d'études), je suis toujours incapable d'avoir ce niveau, et je ne sais toujours pas écrire. C'est très frustrant.
bépo powered
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 5. Dernière modification le 16 juin 2014 à 23:30.
Pourtant bon nombre de japonais préfèrent lire en anglais ou un japonais à écriture latine que le Kanji dont l'expression par les journaux est d'un registre très soutenu avec de nombreux symboles peu utilisés au quotidien (pour le japonais lambda en tout cas).
Les langues asiatiques sont très longues à apprendre en général, c'est un fait. Cela ne les aide pas du tout.
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Ils aimeraient savoir lire en anglais, mais ils ne le font pas.
Les kanji des journaux sont courants : ils sont très régulièrement utilisés dans les journaux, justement. Et leur lecture est indiquée s'ils sortent un peu des sentiers battus.
'fin, je trouve le japonais de base beaucoup plus simple à apprendre que le français de base…
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 3.
C'est vrai que quand on fait abstraction des niveaux de politesse par exemple, ça devient tout de suite beaucoup plus simple.
Mon père s'y est mis pour pouvoir baragouiner un peu avec son petit fils. Réaction d'un quinquagénaire qui n'a pas été à la fac après 3 mois : "bon, faut retenir les mots, mais il y a presque pas de grammaire du tout alors ? Chouette !".
Quant à l'assertion selon laquelle les japonais préfèrent lire en caractères latins, j'ai de TRÈS gros doutes à ce sujet. Pour la simple raison que le japonais devient imbitable, du fait des très nombreux homophones. Je dirais même plus, ça leur prendrait considérablement plus de temps de lire en romaji qu'en kanji, pour ceux qui y arriveraient en tout cas.
Quant à lire en anglais, ahem, désolé, j'ai ri ^
[^] # Re: Correction
Posté par Zenitram (site web personnel) . Évalué à 4.
Revenant de tourisme au Japon, j'avoue que tu m'as bien fait rire de si bon matin avec cette phrase, merci.
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
C'est sûr qu'en revenant d'un voyage de tourisme, on connaît intimement la population à son retour.
Toi aussi tu m'as bien fait rire :)
[^] # Re: Correction
Posté par Zenitram (site web personnel) . Évalué à -1.
Quand tu fais du tourisme, surtout dans un pays où mêmes les locaux ne comprennent pas toujours comment fonctionne une addresse postale, quand tu cherches ton chemin (route, rail, métro…), quand tu vas dans différents hotels (où les locaux doivent être ceux qui parlent plus anglais que les autres, ils accueillent le plus d'étrangers), quand tu discutes avec les guides locaux sur comment fonctionne le pays, quand tu te renseigne pour savoir si tu es seul avec cette impression, tu te rends très vite compte du niveau moyen d'anglais de la population locale, ne t'en déplaise.
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
bon nombre de japonais != personnes que tu rencontres dans la rue aléatoirement en faisant ton tourisme
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 2.
Après vu comment c'était dit, le commentaire laissait entendre que c'était sinon une majorité, au moins une bonne grosse minorité…
Si on veut s'amuser au détriment des mouches, sur un pays de 120 millions d'habitants, 1/10000 ça fait quand même "un bon nombre" qui reste très marginal.
Personnellement, je suis plutôt d'accord que le niveau moyen en anglais est très bas, malgré la multitude d'écoles de langues et la foison de profs d'anglais autoproclamés pour qui ça représente un visa de travail. C'est fou la quantité d'argent que brasse ce business en dépit du peu de résultats…
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Un bon nombre c'est très relatif, et ça dépend du milieu du locuteur.
Le niveau moyen peut être très bas, néanmoins on peut imaginer que si quelqu'un fréquente le milieu de la recherche en informatique, dans lequel le niveau d'anglais doit être bien au-dessus de la moyenne, un « bon nombre » peut être vite atteint.
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 2.
Donc en gros, on en conclut que parmi les gens qui ont un bon niveau d'anglais, un bon nombre lisent le journal en anglais… Ça me paraît pas terrible comme conclusion ^
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Non, on en conclut que parmi les gens qui parlent bien anglais, un bon nombre préfère lire en anglais ou un japonais à écriture latine que le Kanji.
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 4.
Encore une fois, je ne connais PAS UN SEUL japonais qui prefera lire sa langue en romaji plutot qu'en kanji… anomalie statistique ???
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
Personnellement je n'ai pas d'avis sur la question, j'ai juste fait remarquer l'absence de logique du commentaire de Zenitram.
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Non. J'ai fait une partie de mes études supérieures au Japon, et le niveau d'anglais est pas meilleur.
Un salaryman bourré dans un troquet parle aussi bien anglais… Le "bon nombre" n'est pas atteint.
[^] # Re: Correction
Posté par Maclag . Évalué à 7.
Ce qui serait vraiment bien, c'est que quand on constate un échec à l'école on envisage d'autres solutions que la simplification à outrance, ce qui a été fait quasi systématiquement depuis des décennies.
Résultat: le Bac de nos parents signifiait quelque chose, le nôtre peu de choses, et celui de nos enfants est parti pour être une vaste blague. M'enfin le plus important c'est de se gargariser tous les ans avec le taux de réussite au Bac en montrant entre deux des étudiants stressés et en faisant comme si l'examen n'avait pas baissé de niveau.
On retrouve donc à la fac, tous le ans, une armée d'étudiants frais et naïfs qui viennent se vautrer sur les murs de l'examen de première année, parce que le niveau à la fac, lui, ne baisse pas, et heureusement!
Pourquoi d'ailleurs nos chers journalistes ne passent pas autant de temps à parler du taux de réussite à la fac au lieu de parler des résultats du Bac?
Le milieu social ne conditionne pas seulement les résultats en Français mais dans toutes les matières. À moins de simplifier le monde entier, on ne résoudra aucun problème en simplifiant le Français.
Et le pire, c'est que ça ne marche même pas: on n'a cessé de simplifier les programmes avant le supérieur, et on retrouve toujours une différence de niveau corrélée avec le milieu social d'origine.
Jusqu'où il faut descendre pour comprendre que ça ne marche pas? Jusqu'au monde d'Idiocracy??
[^] # Re: Correction
Posté par claudex . Évalué à 6.
Parce qu'alors ce serait le niveau de la fac qui baisserait.
« 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: Correction
Posté par ariasuni . Évalué à 2.
Vous sur-interprétez à mort ou quoi? J’ai pas dit que ça résoudrait tous les problèmes du monde, j’ai dit que c’était un pas peut-être petit mais significatif qui permet d’équilibrer un peu la balance des inégalités.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 5.
Cette critique est d'un classique. Aristote se préoccupait lui aussi de la baisse du niveau éducatif à son époque. :)
Je ne pense pas que le niveau du bac ait particulièrement baissé depuis nos parents. Je pense qu'il a tout simplement changé.
Depuis les années 1990, il y a eu une diversification importante des matières enseignées. L'emploi du temps n'étant pas extensible à l'infini, cela a un impact en terme de volume horaire sur les matières de base comme les maths ou le français.
Donc oui aujourd'hui les élèves sont moins bons dans ces deux matières fortes par rapport au passé, mais ils auront fait une LV1 et LV2, ils auront une culture plus large avec de la musique, arts plastiques, technologie, informatique, etc.
Quand on regarde le programme du bac général français par rapport au programme des écoles à l'étranger pour un adolescent de 18 ans, la France a un très bon niveau (surtout par rapport aux USA). Serait-ce un complot mondial ou un phénomène sain que de diversifier le savoir des enfants ?
Puis bon, en soit le bac n'est plus important non plus. Il y a 20-40 ans, avec le bac tu pouvais avoir un travail facilement, et même un travail "qualifié". Aujourd'hui c'est presque impossible car la plupart des étudiants arrivent à valider un bac +2, les études s'allongeant en moyenne, le bac a perdu son rôle de premier diplôme "utile" professionnellement.
Le bac reste surtout important pour habituer les étudiants à passer un examen (dans le supérieur il y a en général 1-2 examens par an), faire un premier filtre (malgré tout il y a des échecs), et valider un minimum de connaissances de bases.
[^] # Re: Correction
Posté par rewind (Mastodon) . Évalué à 7.
Bonjour les clichés !
Ouvre des bouquins de l'époque où le bac S s'appelait bac C et tu vas comprendre ta douleur.
Je reprends l'exemple du bac S. De nos jours, il n'y a même plus d'épreuve d'Histoire-Géographie au bac S (elle est seulement en option) ! Donc, bonjour la diversification…
Alors non, tous les étudiants n'arrivent pas à valider un bac+2 comme ça. Il y en a un nombre non-négligeable qui trouvent la marche entre le bac et l'université un peu haute (et ça ne va pas en s'arrangeant) et qui échoue. Sans compter que bac+2, de nos jours, avec un système LMD, ça ne signifie plus rien. Et ce que tu décris, c'est exactement ce qu'on reproche au bac, d'être devenu un diplôme inutile alors qu'on pourrait très bien avoir un peu plus d'ambition. La seule chose qui semble compter pour le bac, c'est le taux de réussite qui doit augmenter sans cesse. Et on fera comment le jour où on arrivera à 100% ?
Pourtant, mes étudiants passent 0 examen par an… Mince alors ! Oui, le contrôle continu, ça existe aussi à l'université.
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 6.
Le baccalauréat C correspond au Bac S + spé maths.
J'ai vu quelques sujets de bac C maths, et globalement tout est accessible à un bachelier S, les sujets sont plus durs mais les notions sont abordées au programme.
Le bachelier C avait 9h de maths par semaine, aujourd'hui un spé maths aura 7-8h ce qui est moins, donc logiquement le niveau du sujet sera plus simple pour être plus abordable (car ils ont eu moins de temps d'enseignement).
Le bac S a plus d'heures de physique et de SVT que par le passé, ce qui a permis de voir plus de notions.
De même, j'ai cru voir que la LV2 n'était pas obligatoire, aujourd'hui ça l'est, et la LV1 s'est renforcé.
On est passé d'environ 300h d'enseignement scientifique par an pour un bac C à 200h aujourd'hui, le gain ayant été distribué à des matières plus littéraires ou diversifiées (langues, histoire-géo (avant sa suppression), TPE, etc.).
Donc oui ça paraît plus simple, mais quand tu y passes moins de temps dessus, on ne va pas te filer la même difficulté sinon ça serait totalement impossible. Et comme il y a d'autres matières où tu vas moins en profondeur, ils paraissent simples, mais les matières s'accumulant le tout n'est pas si évident que ça en a l'air.
Je regrette que l'histoire géo ait été supprimée, mais le niveau n'a pas fondamentalement baissé.
Petite étude sur le bac (qui cherche à mettre en évidence la baisse de l'enseignement mathématiques depuis les années 70 avant le supérieur) : http://danielduverney.fr/documents/textes-courts-systeme-educatif/BaccalaureatS.pdf
[^] # Re: Correction
Posté par Funigtor (site web personnel) . Évalué à 1.
[^] # Re: Correction
Posté par rewind (Mastodon) . Évalué à 2.
Wikipedia dit que c'est une épreuve facultative et le lien de la note de bas de page dit que ça reviendra en obligatoire en 2015.
[^] # Re: Correction
Posté par Funigtor (site web personnel) . Évalué à 1.
Effectivement, il y a bien une option en Terminale mais tous les S ont au moins eu une partie obligatoire en épreuve anticipée.
[^] # Re: Correction
Posté par Ytterbium . Évalué à 2.
En revanche, le programme de physique de terminale a lui été réellement trucidé par le dernier programme. C'est bien beau d'avoir de la relativité restreinte, mais à comprendre (sans formule comme support), c'est pas facile. Je comprends d'ailleurs mieux certains phénomènes quand j'ai la formule (et la démonstration qui va avec) que leur explication "avec les mains".
D'ailleurs regarde le sujet de bac de cette année ; j'ai compté qu'il fallait connaître en tout et pour tout une seule formule : v = d/t (et f = C/λ pour l'exercice de spé).
La marche vers le supérieur est rude (horreur : des formules à apprendre).
[^] # Re: Correction
Posté par Sufflope (site web personnel) . Évalué à 3.
Pour le bac je n'ai pas de donnée précise, mais je peux parler pour la prépa (MP - maths spé me concernant).
Je l'ai faite dans une prépa du haut du panier (pas Louis le Grand mais pas trop loin), le genre où on vise minimum une Mines ou une Centrale, et qui envoie des éléments à l'X ou en ENS. Et je dis même pas ça pour me la péter, moi j'ai choisi une école moins huppée que ça (et on s'est bien foutu de ma gueule pour la peine), juste pour dire que j'étais pas dans une classe de branlos. Bah quelques fois en DS on s'est mangé des sujets de concours d'écoles merdiques (vues les ambitions de mes camarades), mais des années 70-80… putain on a jamais autant ramassé nos dents. Un sujet de Polytechnique des années 2000 après ça c'était de la crème Nivea sur nos plaies.
Alors pas de baisse de niveau, mon cul ouais.
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
C'est pas parce que le concours était plus dur que les élèves réussissaient mieux…
[^] # Re: Correction
Posté par Albert_ . Évalué à 2.
Euh un concours c'est pas fait pour que les eleves reussissent c'est fait pour faire un tri. Apres que la moyenne soit a 2.5 ou a 19 cela ne veut rien dire.
[^] # Re: Correction
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Oui c'est ce que j'essayais de dire. Ce qui compte ce n'est ni la difficulté ni la moyenne mais bien les deux ensembles.
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 5.
Le lien et la réflexion que j'ai posté plus haut montre une chose :
Les mathématiques en bac C avaient un nombre d'heures bien plus élevé qu'aujourd'hui même pour un bac S spé maths. Cette sureprésentation des mathématiques se faisait au détriment des autres sciences (SVT, SI ou Physique). Depuis les années 90 deux réformes successives ont baissé le nombre d'heures de cette matière pour les mettre ailleurs, notamment dans les matières non scientifique.
Une prépa scientifique normalement ne se préoccupe réellement que de trois matières : Physique, Maths et SI (sauf pour des catégories types agricoles). Si tu diminues au bac le niveau de maths, cela va se ressentir en prépa. C'est logique. Mais le niveau de bac ne sera pas pour autant plus simple, les maths au bac le seront (vu qu'il y a eu moins d'enseignement) mais il y a des matières ou des sujets plus complexes / diversifiées dans ceux où le nombre d'heures a augmenté.
Les maths ne sont pas la seule matière au bac, ni dans le supérieur, si le niveau de cette matière a baissé, ce n'est pas forcément le cas des autres… Le bac étant un ensemble de matière, il faut regarder l'ensemble des matières et non une seule.
[^] # Re: Correction
Posté par rewind (Mastodon) . Évalué à 4.
Il n'y a pas que le nombre d'heures, il y a le programme globalement. Même si les heures ont baissés de 9 à 7h par semaine, le programme a été raboté largement plus en proportion. Dans le lien que tu donnes plus haut, en annexe 15, il y a la comparaison des programmes entre 1982 et 2002. Et bien, ça n'a juste rien à voir. On a l'impression que c'est pareil de loin parce qu'il y a le même nombre de lignes, mais quand on regarde de plus près, on constate que toutes les notions importantes pour la suite des études ne sont plus vues ou plus vues correctement. Quelques exemples parmi d'autres :
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 3.
Pourtant 2h par semaine c'est environ 60h par an. C'est énorme.
Pour avoir suivi ces notions en prépa scientifiques (car ce n'était plus au bac) c'est à peu près la quantité donnée pour passer ces points en revue. Le rythme de prépa est élevé, mais je suis sûr que ces points vus en terminale C l'étaient de manière plus allégée aussi qu'en prépa actuelle (formalisme moins rigoureux, moins d'exercices…).
Sans compter que la terminale S spé maths a de l'arithmétique, ce qui n'était pas le cas avant, ce qui concerne sans doute 10-30h d'enseignement ce qui n'est pas négligeable. Cela fait 90h dans l'année en moins pour le reste du programme par rapport au bac C, donc virer ces notions se fait bien par rapport au taux horaire !
Puis la Terminale n'est qu'une année parmi les autres, ces réformes ont touché l'organisation du lycée en générale, le programme mathématiques de seconde et de première a du être rabotée. De fait, les élèves sont moins forts en terminale en maths et ne peuvent tenir le même rythme que les bacheliers C.
Et si on regarde bien, et l'étude le précise, le bac C était sans doute le programme de maths le plus relevé au monde ! Très peu si ce n'est aucun pays n'avaient un programme de maths aussi intense et aussi profond avant le supérieur. Donc est-ce mal de se mettre au niveau des autres ? La France était réputée pour son niveau de mathématiques (il suffit de voir son historique et les récompenses individuelles pour s'en convaincre), mais la formation d'une élite est bien mais souvent fait au détriment des élèves les plus faibles. C'est tout le problème de l'éducation française aujourd'hui.
Que le bachelier ait plus d'ouverture est normal. Beaucoup d'élève en S ne suivent pas des formations scientifiques dans le supérieur (typiquement, le droit). Et je ne suis pas convaincu que le report de l'enseignement des développements limités, de l'algèbre linéaire et autres soient une grande perte avant le bac. En tout cas les formations d'ingénieurs ou de physique/mathématiques du supérieurs le font aujourd'hui et ça se passe bien. Ces notions sont importantes, mais de là à considérer que ça doit être dans le socle de base d'enseignement, bof bof…
[^] # Re: Correction
Posté par rewind (Mastodon) . Évalué à 5.
Je suis en désaccord profond avec ta vision des choses. Tu as une vision purement utilitariste des mathématiques et donc le raisonnement qui va avec : «si ça sert à rien, autant ne pas l'enseigner». Mais l'école est faite pour apprendre des choses qui ne servent à rien ! Elle n'est pas là pour former des petits soldats prêt à l'emploi, elle est là pour ouvrir l'esprit et apprendre des concepts et des manières de penser et résoudre des problèmes. On résume souvent ça à «former l'homme, le citoyen, le travailleur».
Et même dans une vision utilitariste, un truc comme les matrices qui doivent servir dans à peu près toutes les sciences, ça me semble être un fondamental (et pour ceux qui feront du droit, ça ne sera pas un mal). La tournure employée «intuitive» montre bien l'abandon d'ambition pour cette école. Alors non, avoir un des niveaux les plus élevés en maths, ce n'est pas mal, c'est même bien ! Vouloir rabaisser sans arrêt le niveau global, ça n'est jamais bon, ça amène des gens à raconter plein de conneries (même des ministres de la Culture dans un hémicycle) et à croire le premier illuminé venu (souvent complotiste).
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 3.
Oui l'école ne doit pas être utilitariste (je ne vois pas en quoi je soutiendrais cette thèse). Mais les mathématiques ne sont pas la seule matière nécessitant un enseignement. Je pense qu'il est plus utile et intéressant que l'élève avant le bac ait une couverture large des sujets qu'une connaissance approfondie d'une matière unique.
Il est justement plus important d'insister sur les matières annexes, même en S, à savoir les langues, le français ou l'histoire-géo qui permettent de comprendre le monde, de s'y ouvrir et d'avoir une culture que de savoir ce que sont des matrices et des développements limités. Et même, je pense qu'il est aussi important que les autres sciences soient mieux enseignées que les mathématiques presque seules.
[^] # Re: Correction
Posté par barmic . Évalué à 6.
Et donc pour ça il vaut mieux avoir un niveau de malade en mathématiques ou diversifier les enseignements ?
Tu nous la refais avec on va dire un argument qui tiens un minimum debout ? En une phrase t'a pris 2 raccourcis de folie. Pour quelqu'un qui semble apprécier les manières de réfléchir résonnés…
Note pour ta dernière phrase qu'on peut en faire pleins des comme ça. Par exemple le niveau exécrable depuis tout temps empêche les gens de respecter un minimum la présomption d'innocence, fait qu'ils ne connaissent pas bien leur droits (par exemple quand ils se retrouvent face à leur patron ou une multinationale) et les poussent à croire le moindre journaleux qui leur donne une vision biaisée d'une décision de justice.
Le droit aussi apprend à réfléchir et à construire un raisonnement, ainsi qu'à faire des abstractions.
Tout ça pour dire qu'il n'y a pas que les maths dans la vie. Il y a un paquet de domaines totalement transversaux qui peuvent être considérés comme de vrai manque (j'ai parlé du droit, mais c'est par exemple aussi le cas de la santé). Bien sûr que faire un bac S spé maths doit entraîner pas mal de mathématiques, mais tous les titulaires d'un tel bac n'ont pas vocation à aller à math sup et devront apprendre un paquet d'autres choses. Chercher à tout prix à considérer que les maths sont la seule (et la plus importante) des matières ne me semble pas vrai.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Correction
Posté par rewind (Mastodon) . Évalué à 2.
Pourquoi opposer les deux ? Je n'ai jamais opposé les deux et je pense qu'on pourrait faire les deux.
Ce n'est pas ce que j'ai fait, j'ai pris l'exemple des maths parce que c'est celui qui était dans le document cité au dessus. On pourrait faire la même avec la physique ou la SVT ou même l'histoire-géographie sans aucun problème je pense. Raboter l'histoire-géographie, ça n'aide à rien. Je me souviens avoir vu à l'école l'exemple de la Côte d'Ivoire et du coup, quand il y a eu des remous là bas, je me suis souvenu globalement de ce que j'avais appris. Idem pour le Soudan, j'avais gardé en tête une carte qui montrait les frontières religieuses et culturelles qui traversaient le pays et donc, la création du Soudan du Sud s'expliquait assez simplement. Je ne suis pas sûr que les coups de rabots sur le programme d'histoire-géo de ces dernières années aident à comprendre le monde tel qu'il évolue en ce moment.
[^] # Re: Correction
Posté par barmic . Évalué à 5.
Parce que le temps est incompréssible et que le fait d'avoir ajouté/renforcé les langues entre autre se fait nécessairement à l'encontre d'autre chose.
Comme quoi…
Tu viens de dire que l'école ça doit former à réfléchir et là tu parle d'éléments totalement utilitaire (tu recrache ce que tu a bachoté). Si ta formation ne t'a pas parlé des tensions dans les balkans, en Asie du Nord, en Ukraine ou ailleurs tu te retrouve le bec dans l'eau ? On ne peut pas tout savoir, c'est un fait, ce qu'on peut c'est apprendre à s'informer correctement. Par exemple connaît-tu la différence entre un sunnite et un shiite ? Est-ce l'école qui t'a appris ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 3.
Tu vas m'expliquer comment tu veux retrouver le niveau des maths du bac C tout en gardant les enseignements actuels et même idéalement en enseignant l'informatique, le droit, l'économie (qui sont des matières importantes mais non vues par un élève de bac S).
Leur nombre d'heures a légèrement augmenté et je n'ai pas vu de régression pour eux.
En 2009 le bac d'histoire-géo de S me semblait assez large et complet pour qu'on comprenne le monde. Pas forcément le Soudan ou la Côte d'Ivoire (qui sont des cas particuliers). Je ne me prononce pas sur l'après.
Personnellement je trouve que tu te fondes trop sur un ressenti personnel que sur quelque chose de bien formalisé avec des preuves et des comparaisons de programmes sur l'ensemble des matières.
[^] # Re: Correction
Posté par Ytterbium . Évalué à 1.
Pour les SVT, non, mais pour la physique oui avec la dernière réforme. Il suffit de comparer un livre de Terminale de l'ancien et du nouveau programme pour voir la différence : le nouveau est tout joli, il y a plein de documents, mais en contenu, il y a pas grand chose.
En tout cas, avoir mis le bac d'histoire-géo en première pour les S était une belle bêtise. Et puis de ce que je me souviens, la géographie ne portait quasiment que sur l'aménagement du territoire français (berk). Vive alors l'ouverture sur le monde…
Et c'est pas les deux heures d'histoire en option en Terminale qui compensent.
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 3.
Je ne parlais pas des dernières réformes qui vont, apparemment, être revues, mais bien des années 90-00 où de nombreuses personnes déjà se plaignaient d'un recul.
En 2009 en géographie de S tu avais : Façade Atlantique Nord, Asie du Sud-Est, USA, Japon, Espace méditerranéen, mondialisation
Histoire : IVe et Ve République (jusqu'à Chirac président), Guerre froide, colonisation (Afrique et Asie), décolonisation (Afrique et Asie)
Et il y a sans doute des points de programmes dont j'ai oublié leur présence. Ça me paraît correct, intéressant et bien ouvert sur le monde.
[^] # Re: Correction
Posté par Pierre Roc . Évalué à 4.
On ferait mieux d’enseigner les probabilités et les statistiques. C’est sûrement sur ce point que l’enseignement français a des lacunes. Ce d’autant que c’est ultra-utilisé, y compris et surtout par le citoyen.
Oh et puis une remarque aussi sur la “baisse de niveau”. La marche entre le lycée et la prépa, en math et pas en physique, est très dure à franchir. Mon prof de prépa math sup’ attribuait cela à la baisse de niveau en lycée qui n’a pas été répercutée en prépa. Au final on a démocratisé le bac, mais ça n’a pas réduit les inégalités d’accès. En effet, quelques élèves de ma prépa étaient allé dans des lycées spécifiques qui permettaient de préparer l’élève aux prépas (et pas seulement au BAC). D’ailleurs c’est un fait tellement bien admis que j’ai reçu mon admission avant de passer mon BAC, et que le lycée d’origine est pris en compte dans le choix des élèves.
Je peux vous dire que j’en ai chié en première année, heureusement que j’adorais ce qu’on y faisait. Il faut tenir compte de ce genre d’effet pervers dans une politique de réduction des inégalités sociales. Évidemment la prépa est un système élitiste, certes, mais supposé fonctionner au mérite… en théorie.
[^] # Re: Correction
Posté par Renault (site web personnel) . Évalué à 3.
Sauf que le programme qui a été retiré du bac en maths a été ajouté en prépa.
Tu n'as pas besoin de faire des maths hors programme au lycée pour être au niveau en maths en prépa.
En soit c'est enseigné, mais après il faut que les élèves retiennent la leçon aussi dans le temps (pendant 40-60 ans quand même).
Mes profs ont dit que ça a toujours été difficile et que les élèves en ont toujours chié.
Que ceux qui ont des facilités ou qui avaient l'habitude d'un programme mathématiques aussi poussés s'en sortaient bien, il ne faut pas se leurrer, avant ce n'était pas plus facile pour les élèves.
Le bac en soit ne représente rien, ça ne te teste que sur une portion ridicule du programme de l'année. Un bulletin scolaire sur plusieurs années donne une meilleure vue de l'élève, son comportement, sa capacité à surmonter des difficultés, etc.
Plusieurs profs de prépas avaient faits des études sur leur lycée et globalement les meilleurs élèves en prépa n'étaient pas forcément ceux avec la meilleure note au bac. Notamment parce que ceux qui ont plus de difficultés ont l'habitude de travailler de manière plus intensive. Tu peux retrouver cela facilement.
Comme tout le monde.
[^] # Re: Correction
Posté par ariasuni . Évalué à 1.
Quelle réponse! Je suis sans voix…
Les irrégularités n’ont aucun intérêt en elle-mêmes, donc moins il y a d’exceptions, mieux c’est.
Est-ce que tu trouves qu’à 19 ans j’ai toujours besoin d’un correcteur orthographique et grammatical pour écrire correctement? Et encore je fais peu d’erreurs, mais je suis plutôt l’exception que la règle.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par anaseto . Évalué à 3.
L'intérêt, c'est qu'arrivée la cinquantaine, tu peux toujours continuer à avoir des discussions intéressantes avec d'autres lettrés sur si tel verbe est suivi de telle préposition ou de telle autre, « après que » suivit du présent et « bien que » du subjonctif, et débattre sur le bien fondé de ces choses, tout en tirant fierté de ta connaissance de la richesse de la langue, et finalement réussir quand même à faire une faute d'orthographe impardonnable de temps en temps si tu ne te relis pas bien comme il faut… quand tu n'aboutis pas carrément à un gros doute et là c'est le drame, mais c'est ta faute, jamais celle de la langue.
[^] # Re: Correction
Posté par barmic . Évalué à 5.
Donc l'intérêt c'est de pouvoir jouer à qui a la plus grosse et de pouvoir se la péter élitiste ?
Moi qui pensait que la langue avait pour but de fournir un moyen de communication efficace (ce qui implique qu'elle soit répandue).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Correction
Posté par Pierre Roc . Évalué à 2. Dernière modification le 19 juin 2014 à 15:33.
Une langue complexe permet d’exprimer une pensée complexe. Je trouve assez ridicule cette focalisation sur l’orthographe là où le style, l’expression écrite et la capacité à assimiler ce qu’un autre écrit, sont des compétences bien plus importantes pour la maîtrise de la
languecommunication.[^] # Re: Correction
Posté par esdeem . Évalué à 0.
J'en ai trente-sept et peu importe la langue, je vérifie toujours dans dictionnaire et je relis toujours, parce que je ne suis pas une machine. Donc oui, je trouve cela normal.
Je fais la même chose quand je codes : je fais des erreurs et la coloration syntaxique me rappelle à l'ordre. Et si malgré tout il reste des erreurs, c'est la compilation qui va me rappeler à l'ordre. Le problème n'est pas ma connaissance du langage, mais mon attention.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Correction
Posté par ariasuni . Évalué à 0.
Nan mais si je connais un mot en espéranto, que je connais sa prononciation, je sais l’écrire (et certains langues naturelles aussi sont phonétiques). En français on en est vraiment très très loin. Et quand on écrit sur papier c’est encore plus problématique…
Et encore, les correcteurs grammaticaux arrivent à se planter tellement c’est complexe, par contre en espéranto les règles sont beaucoup simple et les chances de se planter d’autant plus réduites. Non seulement j’ai moins de chance de faire des erreurs mais en plus le correcteur a plus de chance de trouver celles que je fais.
La question n’est pas «est-ce que c’est normal de faire des erreurs de temps», mais «est-ce normal que ça soit si compliqué»? On peut l’expliquer, mais on peut difficilement le justifier.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Tu connais beaucoup de langues naturelles qui soient simples, sans exception, sans irrégularité ? Peut-être que la norme est différente de ton idéal… Peut-être que les justifications te dépassent ?
[^] # Re: Correction
Posté par ariasuni . Évalué à 2.
Non. Mais certaines sont plus simples que d’autres dans ou plusieurs domaines.
Je n’ai jamais dit que les langues naturelles devraient atteindre un idéal, d’ailleurs ça serait impossible à moins de refaire toute la langue ce qui n’a aucun intérêt vu qu’on a déjà l’espéranto, l’ido, l’interlingua, le lojban…
Peut-être que j’ai choisi le mauvais mot. Donc à moins que tu penses que c’est bien que les langues soient compliquées, on ne peut pas justifier (dans le sens «donner une raison valable à cette complexité d’exister» en dehors de l’aspect historique).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par PyroTokyo . Évalué à 1.
Personnellement en termes simplicité, j'ai toujours été ébahi par l'espagnol. Bien sûr il y a des exceptions, comme partout, mais côté prononciation et orthographe je n'ai jamais eu de surprises, malgré les abondants emprunts à l'arabe.
C'est clair qu'à côté, le français et l'anglais c'est le joyeux bazar.
L'italien a l'air assez régulier aussi, mais ne le parlant pas, je ne peux pas me prononcer.
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 0.
Bon, je repasse en mode sans accents…
Comment justifier l'humain, alors qu'un organisme unicellulaire, c'est quand meme vachement plus simple ?
Je doute que beaucoup de langues aient evolue' car certains voulaient les compliquer. Certains choix ont ete' certainement plus arbitraires que d'autres, mais la fixation de la langue s'est faite dans un but d'harmonisation. La langue francaise est un melange de nombreuses langues, et vouloir tout simplifier, c'est tirer un trait sur la culture des locuteurs du francais. On peut supprimer l'orthographe (et perdre l'etymologie, puis donc la capacite' a comprendre le sens de mots nouveaux), simplifier la grammaire (et perdre la capacite' a decrire des relations complexes sans ambiguite', temporelles, possessives ou autres), puis retirer les synonymes (et perdre la capacite' a exprimer des nuances concisement), mais que gagne-t-on vraiment ?
Tu preferes l'esperanto pour des raisons de simplicite', mais as-tu deja goute' aux possibilites qu'offrent d'autes langues plus "complexes" ? La simplicite' a un cout. Et ce cout est relatif. J'ai la chance de parler plusieurs langues, et je trouve qu'elles ont toutes des avantages les unes sur les autres. La complexite' de certaines est aussi souvent leur point fort.
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Sauf que ça n’a rien à voir.
T’extrapoles à mort. J’ai jamais dit qu’il fallait tout simplifier, mais qu’il y avait de nombreux points qu’on pouvait améliorer sans nuire ni à l’expressivité, ni à la culture que véhicule la langue.
Je ne suis pas partisan de l’ortograf.
On peut avoir une grammaire simple et puissante. J’ai parlé de simplifier, pas de castrer, et il y a quelques règles de grammaire qui ne portent pas de sémantique.
Ça dépend des synonymes, mais globalement je ne nie pas l’utilité des synonymes.
L’espéranto est simple à apprendre mais très puissant.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 17 juin 2014 à 07:47.
Prendre comme exemple une langue même pas née (morte avant d'avoir été vivante, ou jamais vivante, ou je ne sais pas comment on peut définir "ça") pour dire qu'il n'y a pas d'exception, c'est pour faire rire les gens?
Peux-tu donner un exemple de langue vivante, c'est à dire utilisée pour plus que du hobby? Car bon les exception viennent avec… L'usage de la langue.
[^] # Re: Correction
Posté par gouttegd . Évalué à 5.
Le turc ? La prononciation du turc ne cache aucun piège, chaque lettre a une prononciation et une seule, qui ne change jamais en fonction des lettres voisines (une seule exception, car même la règle disant qu’il n’y a pas d’exception doit bien admettre une exception : le « ğ », qui change très légèrement selon les lettres entre lesquelles il se trouve). Le turc se prononce comme il s’écrit, et s’écrit comme il se prononce.
[^] # Re: Correction
Posté par Ignatz Ledebur . Évalué à 5.
Le coréen a aussi cette réputation. Et notons qu'inversement l'anglais, bien que réputé plus facile, est pire que le français pour ce qui est de l'orthographe. Un bon article du Tigre sur (entre autres) ce sujet.
[^] # Re: Correction
Posté par anaseto . Évalué à 5.
Le basque aussi n'a pas vraiment d'exceptions, et il me semble que le hongrois est du même type. En fait, la plupart des langues qui sont agglutinantes n'ont pas d'exceptions ou presque. Je pense que c'est parce que les utilisateurs sont habitués à combiner des particules, et à leur donner un sens, donc dès que quelqu'un tente une exception, elle choque beaucoup plus avec le reste de la langue et ces habitudes agglutinantes, et donc disparaît d'elle-même. Avec des langues comme le français, ou encore plus l'anglais, les exceptions rentrent beaucoup plus facilement, car les particules sont indissociables des mots, et n'ont pas un sens défini : il suffit de se répéter par exemple plusieurs fois boulangiste ou boulangeur pour que ça semble aussi naturel que boulanger, parce que contrairement aux langues agglutinantes -iste -eur et -er n'ont pas un sens propre qui les différencie. C'est d'ailleurs je pense la raison pour laquelle l'espéranto est restée une langue sans exceptions pendant plus d'un siècle, et continuera à le rester, même si elle devient la langue la plus parlée : car tout comme le turc, le basque, etc… elle est agglutinante.
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Nan, en coréen, c'est pas le cas. T'as plein de lettres qui deviennent muettes, t'as des combinaisons dont la prononciation n'est pas celle des lettres qui les composent, et t'as deux voyelles au son identique…
[^] # Re: Correction
Posté par ariasuni . Évalué à 5.
D’après Wikipédia: «L'espéranto est la seule langue construite qui a dépassé le stade de projet pour devenir une langue vivante, avec des locuteurs actifs répartis dans la plupart des pays du monde.»
Firefox, LibreOffice, Pidgin, Minecraft, Mageia, Distrowatch sont traduits en espéranto; il y a des tas de bouquins traduits en espéranto; il y plein d’associations et de rencontres espérantistes; il y a presque 200 000 pages en espéranto sur Wikipédia.
Peut-être pas significatif selon toi, mais dire que l’espéranto n’est pas une langue c’est, comment dire… du foutage de gueule?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par ariasuni . Évalué à 3.
Je voulais dire, pas une langue vivante.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Le problème d’une langue c’est qu’elle n’est pas en écriture seule. Elle est en lecture/écriture, et donc les réformes se cassent les dents sur le patrimoine.
La langue française est d’abord celle que j’ai appris à lire, pas celle que l’on voudrait me faire écrire.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Correction
Posté par ariasuni . Évalué à -1.
Il faudrait qu’on soit beaucoup à propager une nouvelle façon d’écrire/parler le français. :)
Pourtant tu te plies aux règles de l’académie française, non?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Correction
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Indirectement, j’apprends de mes lectures. :-)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Correction
Posté par jihele . Évalué à 10.
Ah, je croyais que couter sans accent circonflexe ça voulait dire printfer.
# Portabilité et forçage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10. Dernière modification le 13 juin 2014 à 13:30.
C'est ça, et je suis sûr qu'il apprécient vachement de voir GNOME, puis maintenant Xfce, devenir de moins en moins utilisables sans systemd.
C'est cela oui : on commence à avoir le choix entre utiliser systemd ou devoir se passer de GNOME, de udev… Bon, ceci dit, avec la mafia, tu es libre de coopérer ou de finir coulé dans du béton, ce qui n'est pas tout à fait pareil, je le reconnais.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 10.
Mauvaise fois. Il faut aller se plaindre à GNOME et Xfce de dépendre des API de systemd sans attendre que les BSD et autres les prennent en charge, il n’y a aucun problème du côté de KDE.
Ou alors il faut bosser/financer la prise en charge de ces API en dehors de systemd, ce qu’Ubuntu a fait et ça marchait bien à priori.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 10.
ça arrive :
http://www.openbsdfoundation.org/gsoc2014.html#systemd
Sinon, le problème majeur, quand l'API n'est pas assez abstraite/portable pour être ré-implémentée simplement sous un autre OS, mais là je mettrais plus udev et udisks dans cette catégorie là que systemd. Par exemple, udev a une fonction new_device_from_systpath(ctx, path), ou path est une chaine. Abstraction : 0. En gros, soit tu as sysfs, avec exactement la même interface que linux, soit tu as pas udev.
[^] # Re: Portabilité et forçage
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 13 juin 2014 à 14:14.
Correction : tu es libre de coopérer ou de proposer une alternative. Quelle contriante peut t'imposer une personne qui ne te connait même pas? Oh zut, l'esclavagisme a disparu et tu aimais bien être esclavagiste…
Maintenant, il va falloir expliquer en quoi les développeurs de systemd sont responsables.
Bon, moi je vais dépendre d'in logiciel (hypothétique) à toi, et les gens viendront te voir et diront "tu es la mafia, tu m'obliges à t'utiliser!", tu leur répondras quoi? "Oh oui, c'est ma faute si d'autres dépendent de moi", on est d'accord?
On a beau essayer d'expliquer, les anti-systemd n'essayent même pas d'adapter leur pseudo-critiques aux remarques qu'il leurs sont faites pour être plus crédibles, ils sortent les mêmes stupidités énormes (c'est factuel), qui ne peut convaincre qu'eux. Le pire étant je crois qu'ils ne sont même pas les développeurs les plus impactés (euh ont testé, et… ils ont pris systemd!)
On se marre toujours autant.
[^] # Re: Portabilité et forçage
Posté par isildur37 . Évalué à 10.
Vous etes un peu de mauvaise foi: systemd n'est pas responsable du fait que gnome se branche directement dessus. Cette responsabilité revient aux developpeurs des systèmes qui en dépendent.
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 9.
Le fait que systemd et GNOME soient développés en grande partie par des gens issus de la même entreprise n'y est sans doute pour absolument rien dans cette histoire…
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 10.
Donc ce que tu critique c'est gouvernance de Gnome, pas systemd.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 1.
Les deux. Pour la gouvernance de GNOME, apparemment, c'est un problème pour certaines personnes assez impliquées dans GNOME.
Mais après, pourquoi est-ce également un problème venant de systemd ? Et bien parce que systemd a réinventé la roue en partant de 0 et donc a cassé tout un tas de compatibilités et d'API qui permettaient à tout le monde de s'y retrouver (distributions Linux, BSD). Ça c'est une volonté délibéré de l'auteur principal de s'en foutre complètement du monde (non-Linux voire même non-RedHat) qui l'entoure. Ça viendrait de Microsoft, on dirait que c'est de l'enfermement. Mais comme c'est libre, on pardonne et on fait semblant de rien.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 8.
Et alors ? Si moi je m'amuse à écrire un système d'init qui ne gère pas grand chose et basé sur des fichier binaire, est-ce que c'est grave ? Si j'ai envi d'écrire un éditeur de texte from scratch qui encode les fichiers dans l'encodage michel_encoding qu'est ce qui me l'interdit ? Si je veux développer un bootloader qui ne marche qu'avec linux 3.x x étant un nombre premier ça me rend criminel ? Ceux qui tentent de plus ou moins révolutionner l'approche CLI et qui fusionne la notion d'émulateur de terminal et de shell sont-ils si horrible parce qu'il font quelque chose qui ne réutilise pas dash, bash, zsh, tcsh et autre ?
Non clairement pas tout le monde à bien le droit de développer ce qu'il veut surtout quand il est crée son projet from scratch. Si son logiciel pose problème alors il n'est pas utilisé/intégré.
Ce serait pareil avec une techno MS ou Apple, si ça pose un vrai problème alors ce n'est pas intégré si ça apporte vraiment quelque chose c'est intégré (à moins que tu pense que les communautés de développeurs sont touchées par des lobbyistes MS/Apple). D'ailleurs c'est le cas cups viens d'Apple, si je ne m'abuse. Si ça n'apportait rien face à lp personne ne ce serait embêté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 10.
Sans sombrer dans la paranoïa et la théorie du complot, il faudrait arrêter de tomber dans l'idyllique là.
C'est une vue de l'esprit ça, ce n'est pas la réalité. Ta dernière phrase sonne comme une sorte d'évidence qui n'en est absolument pas une. Le fait que le développeur de systemd soit payé pour écrire ce code implique, de fait, que ce code fait partie d'une stratégie d'entreprise. Je ne porte aucun jugement de valeur hein, c'est juste une réalité économique. L'entreprise ne va pas laisser un développeur faire du code qui ne sert à rien. Donc, l'entreprise qui emploie l'auteur de systemd cautionne la manière dont celui-ci est fait, sans doute depuis le début, et a pour objectif de l'intégrer. Il n'y a pas de compétition entre systemd et un autre et RedHat choisirait entre les meilleurs, ce n'est absolument pas comme ça que ça se passe. RedHat pousse systemd pour remplacer SysV ou Upstart ou n'importe quoi mais c'est clairement pas pour le mettre en concurrence avec les autres et choisir éventuellement un autre à la fin. Si moi je me mets à développer un init merveilleux qui résout les mêmes problèmes que systemd et qu'il est mieux foutu que systemd, RedHat n'abandonnera pas systemd.
Et le fait que dans GNOME, il y ait également beaucoup d'employés de RedHat et que ceux-ci poussent pour utiliser… systemd, ce n'est pas un hasard. C'est également une stratégie d'entreprise. Mais on peut continuer à faire comme si tous ces braves gens étaient des philanthropes qui vivaient d'amour et d'eau fraîche, et qui n'avaient aucun intérêt dans cet ensemble.
Oui, c'est clair, Microsoft ne pousse jamais ses nouvelles technos avec des méthodes de bourrin. Que ce soit les DirectX non compatibles ou .Net pour les exemples les plus visibles, MS attends gentiment que les gens se rendent compte de la supériorité technique de la nouvelle solution par rapport à l'existant. Sans aucune pression, ni aucune publicité, ni rien.
CUPS a été racheté par Apple bien après avoir été le standard de fait sur toutes les distributions Linux. Ton exemple est mauvais.
[^] # Re: Portabilité et forçage
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 13 juin 2014 à 17:26.
Red Hat a pourtant abandonné Upstart parce que systemd était techniquement mieux foutu.
C'est une boite ou les ingénieurs ont beaucoup de pouvoir de décision et ou l'efficience technique est un argument recevable pour décider d'un changement de direction.
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 6.
Tu crois vraiment que le fait que systemd soit développé par un gars de la maison n'a pas joué ? Je ne suis peut-être plus assez naïf pour y croire et je pense même que ça a été prépondérant.
[^] # Re: Portabilité et forçage
Posté par Zenitram (site web personnel) . Évalué à -2.
Yep, le gars Lennard il est employé RH, Debian, Ubuntu, Fedora, SuSE, Mageia, Arch, il est employé de partout, trop fort, quel argument crédible sur la raison pour laquelle systemd est choisi par une distro. Ou alors, on a juste la démonstration que systemd est choisi parce qu'il est… Bon. Autant par son employeur que par les autres.
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 2.
Une fois que GNOME a (des interfaces de) systemd en dépendance, tu crois que c'est facile de créer et maintenir des implémentations des interfaces utilisées (surtout par des bénévoles) ? Non, le plus simple, c'est de dépendre directement de systemd. Et donc tout le monde switche. La stratégie d'entreprise de RedHat s'impose alors à tout le monde, pour le meilleur ou pour le pire (l'avenir le dira).
[^] # Re: Portabilité et forçage
Posté par Maclag . Évalué à 7.
Sont trop forts chez RH, ils imposent leur intégration de Gnome, ils imposent systemd grâce à Gnome.
Et encore, quand je lis la liste des contributeurs RH au noyau, je me dis qu'une conclusion s'impose: RH impose des changements dans le noyau à toute la communauté et personne ne fait rien pour les arrêter!
Nan vraiment, ces gens payés pour faire du Libre, ça devrait pas exister!
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 5.
Pas tant via GNOME que via udev. Le mainteneur principal de LFS n'aime pas systemd et trouve les scripts shell plus simples et pédagogiques. Le problème c'est qu'udev est devenu trop compliqué à extraire de systemd. Aussi, pendant un temps, l'idée a été de lancer les scripts d'init de LFS via systemd (c'est dire si le gars n'est pas sectaire), mais là encore la complexité du montage a eu raison de sa bonne volonté, si bien qu'aujourd'hui la LFS principale (développée, rappelons-le, en parallèle avec la LFS-systemd) utilise eudev.
Bon, après je ne dis pas que c'est effectivement un plan de conquête du monde de RH, certains comportements à la tête du développement, relevés entre autres par Linus, pouvant suffire à expliquer.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 0.
Le shell quand même. C’est moche le shell. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 5.
Les goûts, les couleurs, toussa. Moi j'adore le shell et j'aime beaucoup le Perl, alors que je trouve le PHP hideux, et que l'unique fois où j'ai touché du JS j'ai sangloté sous la douche durant 5h. Il n'y a rien de rationnel en fait, à part qu'on préfère ce qui nous déstabilise le moins et donc ce qui nous est le plus familier. :)
Note pour le troll que parmi ceux qui trouvent le shell plus clair que ce dont il est question ici, il n'y a pas que des râleurs inutiles et incompétents en design :
Ça rejoint assez bien ce qui s'est produit dans LFS.
[^] # Re: Portabilité et forçage
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
C'est pas pratique de coder sous l'eau.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 1.
Nan mais franchement, on peut pas dire que la syntaxe des conditions soit simple à comprendre par exemple.
Nan mais il y a un petit peu de mauvaise foi dans son commentaire quand même:
Euh… chez moi ça marche, donc c’est que ça ne doit pas être si merdique que ça.
Donc pour lui SysV c’était génial parce qu’il pouvait facilement work around brain damage?
«J’ai fais un truc et c’est de la faute à systemd si ça marche plus».
Je ne dis pas que ce qu’il dit est entièrement faux, mais quand même.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 3.
Ça ne m'a jamais frappé par rapport à tout ce que j'ai pu toucher (Perl, AWK, C, Python, Ocaml). Qu'est-ce que tu trouves dur exactement ?
Oui, mais ce n'est pas le cœur de son propos, car ici il parle de design. Il ne dit pas « c'est nul, ça ne marche pas », mais « quand ça ne marche pas, c'est très difficile de comprendre pourquoi. »
Perso, si j'ai un jour besoin de faire un init, je sais que je peux lire de A-Z celui de ma distro pour comprendre comment les choses s'imbriquent et saisir ce qui est essentiel pour bien démarrer. Ce juste en connaissant le shell et en utilisant les manuels. En C, ce sera beaucoup moins évident, et pas seulement à cause de la faiblesse de mon niveau (les langages de script sont nés précisément parce que le C est difficile à manipuler).
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
Pour l’égalité c’est pas
=ou==mais-eq, mais attention seulement pour les entiers parce que sinon c’est bien==pour les chaines de caractères. Hé nan en fait on utilise pas&&ouandet||ouor, on utilise-aet-o. Et si on utilise pas la syntaxe des crochets il faut mettretestdevant, mais attends est-ce que la syntaxe crochet elle fonctionne avec/bin/sh? Et puis ça veut dire quoi une condition entre doubles parenthèses? Et puis si on veut exécuter un truc pour le mettre dans une variable il faut utiliser les accents grave, mais sauf que maintenant il faut utiliser$(), à moins que ça non plus ça ne marche pas sur tous les shells?C’est peut-être vrai, mais ce qu’il raconte ne démontre rien. Le problème avec NetworkManager pouvait venir de NetworkManager; le problème concernant le «je comprends pas pourquoi certaines unités sont lancées» se résous avec
systemctl list-dependencies --reverse foobar.service(trouvé dans les commentaires de son post); enfin comme je le disais son problème de touches de luminosité me parait plus que douteux, systemd ne s’occupe pas de ça.Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par anaseto . Évalué à 4.
Oui, c'est bien là le point important à remarquer : c'est que
[]n'est au fond qu'un raccourci syntaxique pourtest, et que donc pour être cohérent avec le reste de la syntaxe du shell, les-a,-o, etc… sont juste des options detest, c'est peut-être surprenant par rapport à d'autres langages, mais ça reste cohérent au niveau du shell où la brique de base est la commande, parce qu'ici le reste ce sont des arguments àtest, pas des expressions. Utiliser des symboles aurait été une irrégularité du langage.Pour composer et enchaîner des commandes par contre on utilise des symboles comme
&&, ce qui correspond à l'usage traditionnel dans d'autres langages pour enchaîner des expressions avec évaluation conditionnelle par exemple.En fait, le seul point non cohérent dans ce que tu cites c'est d'utiliser des symboles pour l'égalité des chaînes, j'imagine que c'est juste que
-eqet compagnie étaient déjà pris. D'un autre côté, ça ne porte pas vraiment à confusion car l'égalité de deux commandes n'aurait pas de sens, et le seul truc dommage c'est qu'inverser les symboles pour entiers et chaînes aurait été plus intuitif.Je pense que oui, après je n'ai pas lu en détail le standard, mais ça marche même avec dash. D'ailleurs, dit en passant, la page man de dash est une très bonne introduction au shell par rapport aux pages mans d'autres shells plus conséquent.
Celle avec des crochets
[...]simples crochets oui, celle avec[[...]]non (elle n'a d'ailleurs plus rien à voir avec test).[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
Le problème avec une syntaxe de ce type c’est qu’on s’attend à avoir les symboles habituels. Et c’est quand même, moins lisible que les autres langages (même si on arrive à s’y retrouver à peu près).
Ouais, surtout que dans pas mal de langages et notamment les langages de script,
==s’applique à tous les types.Je trouve que globalement le Bash est beaucoup moins intuitif et lisible que la plupart des autres langages. Et du coup c’est un peu chiant. Ce que je faisais avant avec un script shell, je le fais beaucoup rapidement et lisiblement avec Python (et j’imagine qu’on peut facilement remplacer Python par le nom d’autres langages sympathiques).
Ça me fait penser qu’il y a eu un système d’init en Python, qui a été créé pour Pardus, mais qui n’a pas été adopté par d’autres distributions.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 5.
Autant j'aime beaucoup le shell, autant je ne trouve pas que c'est un langage parfait.
Le typage est déficient.
La syntaxe est des fois très fragile avec des espaces avant les ; pour écrire les
foret lesif.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par anaseto . Évalué à 4.
Je suis bien d'accord, mais la raison est que ça ne rentre pas dans les objectifs du shell. Le shell a pour objectif de composer et enchaîner des commandes, et rien que ça, et d'être un outil pour l'utilisateur d'un unix-like (même pas programmeur). Lorsqu'on sent qu'on a besoin de typage, de structures de données plus complexes, de modularité, etc… c'est juste qu'on doit changer de langage, le shell n'est pas fait pour ça, et autant ne rien lui ajouter de tout ça, car ça risquerait de pousser les adeptes du tout-shell (il y en a pour tous les langages) à l'utiliser pour des tâches où il est sous-optimal et non pensé pour, plutôt que d'utiliser un langage vraiment approprié.
J'imagine que tu parles plutôt des espaces après
[et avant]? Parce que avant ou après;ça m'étonne. D'après la page man de dash :En gros, le shell coupe les mots aux espaces, retours à la ligne, et opérateurs de contrôle ou redirection, mais pas plus.
[n'est pas un opérateur, en fait, et quand j'ai dit raccourci syntaxique avant, c'est imprécis :[est un nom de commande, donc il est traité comme le reste des noms : il faut des espaces avant ou après. C'est juste qu'il s'agit d'une commande qui attend]comme dernier argument et fonctionne pour le reste identiquement àtest. Donc il s'agit d'un raccourci, qui améliore la lisibilité des conditions, mais ce n'est pas syntaxique.On peut aimer ou non l'analyse lexicale du shell, mais elle est vraiment très simple, un simple paragraphe suffisant à la décrire, et si elle paraît surprenante, ce sera probablement seulement pour le programmeur qui s'attend à retrouver des règles différentes auxquelles il est habitué dans d'autres langages, et qui ici seraient des irrégularités.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 4.
Pas vraiment le manque de typage entraîne des scripts fragiles (parce que les vérifications que le shell ne fait pas c'est à toi de les faire). C'est intéressant de voir ce que propose PowerShell à ce sujet là (oui je sais il a un paquet de problème dont le fait qu'il ne soit pas POSIX, pas unix-way et qu'il soit nécessairement lié à la plateforme .Net). C'est simple regarde le nombre de scripts qui appellent des commandes en leur passant des paramètres qui viennent d'entrées du script (soit en paramètre soit en entrée standard soit en en lisant un fichier) et qui ne séparent pas les options de ces arguments via un
--.Faut arrêter de parler de « simple » quand on veut dire « élémentaire » ou « naïf » (d'ailleurs ça fait parti des traductions que donne google traduction au mot anglais « simple »). C'est bien plus compréhensible que de dire « simple ». « KISS » → « Garde le stupidement élémentaire ».
Encore une fois j'aime beaucoup le shell que ce soit POSIX, bash ou zsh, mais il est (très) loin d'être dénué de problèmes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 2.
[est une commande à part entière, il y a un exécutable/usr/bin/[qui agit commetest(sauf qu'il attend un]à la fin des options). Après, certains shell remplace la commande test (et son associée [) par une commande builtin.[^] # Re: Portabilité et forçage
Posté par anaseto . Évalué à 1.
Oui, c'est ce que je venais de préciser juste au-dessus. Après, que ce soit builtin ou pas c'est juste pour des raisons pratiques, mais ça ne change rien au langage (même si les options peuvent être potentiellement différentes).
[^] # Re: Portabilité et forçage
Posté par gouttegd . Évalué à 2.
Juste au cas où il s’agirait de vraies questions :
À moins que sur ton système
/bin/shne soit réellement le « vrai » shell Bourne d’origine (et non un lien vers Ash, Bash, Dash, etc.), oui. La « syntaxe crochet » est définie par POSIX, tous les shells un tant soit peu modernes la supportent.Il n’y a guère que les plus barbus des développeurs GNU qui agissent encore comme s’ils s’attendaient à tout moment à tomber sur un système où le seul shell disponible est un Bourne shell antérieur à POSIX (et où le seul compilateur C disponible ne comprend que le C « K&R »). Un tel souci de la compatibilité est admirable, mais franchement en 2014 tu peux écrire un script shell sans te préocupper de le faire tourner sur une machine des années 1980…
Encore une fois cette syntaxe est définie par POSIX, elle fonctionne sur tous les shells conformes à POSIX (attention, le « C shell » et ses dérivés ne sont pas des shells POSIX).
Et plus sur le sujet du journal :
Ah bon ? Sur beaucoup de machines (toutes ?), les touches de luminosité sont gérées par ACPI (par production d’évènements
video/brightness{up|down}). Comme systemd prend en charge lui-même certains évènements ACPI (au point de pouvoir, éventuellement, remplacer complètementacpid), une éventuelle interaction malencontreuse (aka « bug ») de systemd avec ces touches n’est pas complètement invraisemblable (pas suffisamment en tout cas pour balayer cette hypothèse comme émanant forcément d’un Lennart-hater…).[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 3.
Il me semblait que c’était géré directement par l’environnement de bureau. Je sais que systemd peut changer la luminosité, par contre je trouve ça bizarre qu’il empêche les touches de changement de luminosité de fonctionner.
Maintenant, j’ai peut-être rien compris au fonctionnement de ces touches, et dans ce cas-là je m’en excuse.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 3. Dernière modification le 15 juin 2014 à 12:27.
-eq c'est pour forcer un contexte arithmétique, qui va avec -lt/-gt… qui n'ont pas d'équivalent pour les chaînes de caractères. Et pour les chaînes de caractères, ce n'est pas "==" mais "=" en shell POSIX. Ça pourrait paraître mauvais, mais dans la mesure où les espaces sont requis autour de l'opérateur de comparaison et proscrits autour de celui d'assignation, le risque de confusion est nul (pas comme en C).
Note que Perl a fait les choix inverses ("eq" pour les chaînes, "==" pour l'arithmétique), je passe donc assez régulièrement de l'un à l'autre sans plus de douleur que ça.
Usage découragé par POSIX à présent. Perso, je trouve cependant ça assez pratique pour combiner des tests composés, par ex. "[ -d dir/ -a ! "$flag1" ] && [ "$flag2" -o ! "$flag3" ]".
C'est beaucoup plus cohérent, puisqu'on récupère en fait la sortie d'un sous-shell "( … )", de sorte que tu peux écrire "$(echo a; echo b; echo c)"
Pour le reste sur cette partie, d'autres on répondu mieux que je ne saurais le faire.
Tu aurais du lire la suite, où il dit qu'il a justement besoin du contraire (dans le commentaire que conclut la première citation que j'ai faite) :
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 1.
Bon en fait tout ça c’était pour dire que Bash c’est un langage de script, et on l’a utilisé pour faire un système d’init complet, plusieurs milliers de lignes qui à priori était difficilement maintenables vu la rapidité à laquelle il a été adopté sur différentes distributions (notamment Frugalware, Fedora et Arch Linux) et les propos tenus par certains de leurs mainteneurs (en tout cas ceux d’Arch).
Bah donc
systemctl --list-dependencies --reverse foobar.service, non? L’option--reverseça fait bien le contraire.Et donc systemd prend en charge les touches de changement de luminosité?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 2.
Ce serait un argument acceptable (au delà de l'effet de mode, souvenons-nous de KDE4, et rappelons qu'un démarrage plus rapide est très vendeur pour les distros grand public) si udev était resté une brique indépendante. Ceux qui auraient voulu maintenir un init à base de scripts aurait pu le faire sans problème exactement comme avant et ça aurait àmha été beaucoup moins polémique (alors que là, couplé avec une certaine… attitude à la tête du dev de systemd, ça ne pouvait qu'être détonnant).
Bah non :
Et la suite qui enfonce le clou :
C'est ce qu'il aimerait comprendre justement.
[^] # Re: Portabilité et forçage
Posté par Anthony Jaguenaud . Évalué à 2.
Je ne reparlerai pas de
testcf commentaire précédent. Mais comme tous les programmes bien écris retourne0si ok et≠0si pas ok. C’est par exemple le principe de la commandecd(changer de répertoire courant) :Et ça marche avec toute les commandes. De même que le
&&qui est très pratique pour lancer une commande si et seulement si la précédente est bonne.Ça marche parce que si tu as deux prédicats : A et B. On évalue d’abord A s’il est faux, le prédicat sera faux, donc pas besoin d’évaluer B.
De même que le
ouon évalue le nombre de droite que si le gauche et faux.On peut écrire A && B || C. Si A ou B sont faux alors C sera exécuté. Pour reprendre mon exemple précédent :
Fait la même chose en plus condensé.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 3.
NON !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Anthony Jaguenaud . Évalué à 2. Dernière modification le 15 juin 2014 à 22:14.
As-tu un exemple concret où
echoretourne autre chose que0? À part en fermant le flux de sortie, mais là, en shell, je ne sais pas faire.Édit:
Tu parlais du cas général, et moi de mon cas particulier. Je suis d’accord avec toi si la deuxième commande peut-être fausse. Ce n’est pas le cas de
echo.[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 3.
Un simple truc comme ça:
Tu peux tenter aussi
Mais dans un cas plus proasaique, je suis pas sur que echo renvoie pas 1 si le tty disparait ( genre, tu tues sshd )
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 4.
Je sais pas, si je redirige la sortie standard du script vers un fichier et qu'
echone peux plus écrire de dans (par exemple parce qu'il n'y a plus de place). Qu'est ce qui se passe.Mais dans l'absolu c'est très sensible d'utiliser ça. Si tu remplace
echoparlogger, tu obtiens pas forcément ce que tu veux. Perso dans mes scripts un minimum maintenu je n'utilise echo que pour de la mécanique interne les affichages utilisateur sont fait par des méthodes spécifiques (ce qui me permet de plus facilement les horodater si je veux, les pousser dans un fichier de log par exemple vialogger, de faire diverses mises en forme,…).De plus si tu prend l'habitude d'utiliser cette syntaxe qui marche que dans des cas spécifiques rien ne garantie que tu ne va pas l'utiliser dans des cas aux limites qui posent problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Ignatz Ledebur . Évalué à 2.
exec 1>&-, qui plantera à peu près n'importe quelle commande tentant d'écrire sur la sortie standard.[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 4.
Son propos c'est « je comprends ce qui existait et aujourd'hui j'amalgame simple à "ce que je sais" ». Pour passer à systemd, il y a quelques prérequis :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à 0.
non car Linus veille
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 3.
Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.
Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.
[^] # Re: Portabilité et forçage
Posté par patrick_g (site web personnel) . Évalué à 4.
En gros la liste c'est ça : https://www.kernel.org/doc/linux/MAINTAINERS
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 3.
Pourquoi tant de haine envers Red Hat?
Argumentaire d’un développeur d’Arch Linux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 10.
Tu parles de Tom Gundersen, le développeur que Red hat a embauché pour bosser sur networkd, sans doute pour le récompenser d'avoir mis systemd au sein de Arch Linux. Il est fort probable que le but obscure de la manœuvre soit d'infecter la distro qui monte et qui menace la main mise de la société sur le marché des serveurs.
Moi je dit, il faut se méfier de tout le monde, je suis même sur qu'ils sont parmis nous ici à surveiller et à répandre la propagande pour cacher le plan de domination du libre !
(je précise que c'est du sarcasme, pour le cas ou des gens souffriraient du même travers que le docteur Sheldon Cooper.)
[^] # Re: Portabilité et forçage
Posté par xcomcmdr . Évalué à 2. Dernière modification le 13 juin 2014 à 22:57.
Arch et d'autres distributions sont passé à systemd bien avant les histoires des de dépendance de Gnome envers systemd.
D'ailleurs, Gnome étant multi-distribution, c'est on ne peut plus logique de choisir le système d'init le plus répandu (ou en vogue) quand on veut pas s'embêter à faire une couche d'abstraction permettant d'être compatible avec plusieurs systèmes d'init (et c'est plutôt ça le problème en fait : la flemme/manque de temps/budget/bras/whatever côté Gnome).
Quant à Xfce, ça fonctionne bien sans systemd. Mais clairement, prendre en charge plusieurs systèmes d'init et de gestion d'alimention/de disque sur Linux ou BSD (et encore, pas parfaitement), n'est pas une partie de plaisir pour les développeurs Xfce.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Portabilité et forçage
Posté par PilouPilou . Évalué à -5.
Le fait que Lennart soit employé Red-Hat joue effectivement.
Le fait que ce soit les même qui dev systemd et en partie Gnome joue : oui aussi.
Apres osef, ca fait bien longtemps que je n'utilise plus gnome et les *kit qui vont avec.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 4.
T'es sûr que tu n'inverse pas la cause et l'effet ? Ce ne serais pas parce qu'ils ont trouvé des problèmes dans upstart qu'ils se sont mis à bosser sur systemd ? (ce qu'ils affirment depuis des années soit dit en passant)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 8.
Je peux donner des contre exemples. Les nouveaux produits comme the foreman, openshift sont en ruby en rails, ou en go ( geard ), alors que RH promeut java via jboss ( et a du monde sur le jdk, etc ), du monde sur gcc, et fait son propre language par dessus la jvm.
De même, openshift utilise depuis quasiment le début ActiveMQ plutôt que Qpid, qui est pourtant "de la maison". Des esprits chagrins et observateurs vont dire qu'avec le rachat de fusesource, RH a mis le pied dans ActiveMQ, mais la chronologie ne colle pas, car Openshift est antérieur à ce rachat.
Ou le fait d'avoir choisi de mettre en avant docker plutôt que virt-sandbox ou une solution basé sur les lxc et libvirt, pour ne parler que des choses récentes.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 4. Dernière modification le 13 juin 2014 à 17:47.
Je n'ai pas dis que RH est bien. J'ai dis que le problème, ce qui leur donne du pouvoir, c'est le fait qu'ils soient très impliqués dans la gouvernance de gnome.
Donc ce que tu critique c'est que RedHat pousse l'utilisation dans tous les projets où il est impliqué. C'est un problème de gouvernance de ces projets. Regarde il paraît que KDE fonctionne très bien sans, de même pour e17. Comme quoi l'intégration est le fait des projets qui dépendent et non pas de systemd en lui même.
C'est ce que je dis. Ton problème c'est le fait que le projet Gnome n'a pas de réel indépendance vis à vis de RedHat. Le reste en s'en fou.
Ce que tu dis c'est que RedHat cherche à poussé de l'incompatibilité peut être, mais ce qui lui permet de le faire ce n'est pas le développement de systemd c'est le fait qu'il soit très impliqué dans Gnome. Sinon nous aurions eu à peu prêt la même chose avec ubuntu et upstart ou unity.
Tout le monde a le droit d'écrire le code qui lui plaît compatible ou non qu'il soit une entreprise ou non, mais c'est le fait de pousser dans les logiciels au quel il contribut des dépendances volontairement incompatibles et/ou de faire en sorte que cette dépendance soit forte qui est critiquable.
Tu le dis par la suite des techno qui ont étaient poussée, il y en a à la pèle. Le problème ce n'est pas les techno en soit c'est le fait qu'elles soient utilisées.
Je vois pas le rapport (note que je ne dis pas qu'il y a pas des entreprises qui cherchent à segmenter leur marché, je dis que le problème vient (si problème il y a) vient de gnome.
Bien meilleur exemple. Ça n'a pas plut, la gouvernance du projet à choisi de développer un nouveau langage (vala).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Maclag . Évalué à 8.
Sans sombrer ni dans la parano, ni dans l'idyllique:
-RedHat a évidemment des intérêts en tant qu'entreprise à ce que les développements soient cohérents avec sa stratégie
-Personne n'a élu RH coordinateur des développements de l'écosystème Linux en général. Encore une fois, si RH est suivie par les autres distros, c'est que ses contributions sont considérées comme bénéfiques aux autres distros.
J'imagine bien les dirigeants des Suse en train de se dire "oh, non! une techno de merde de chez RH! tant pis, intégrons-là le plus vite possible!". Je ne crois pas que ça se passe comme ça non plus chez eux…
Parfois on marche un peu sur la tête: on est content de mettre RH comme les champions de GNU/Linux, avec beaucoup de moyens dans le développement et une certaine aura, mais j'ai l'impression aussi qu'on aimerait que RH soit une asso sans but lucratif avec une assemblée de geeks qui décideraient ce qu'elle doit développer ou pas.
[^] # Re: Portabilité et forçage
Posté par rewind (Mastodon) . Évalué à 0.
Décider de ne pas suivre, ça a un coût que ne peuvent supporter la majorité des distributions. Les communautaires parce que créer et maintenir une solution alternative, c'est hors de leurs moyens. Les commerciales parce que même quand elles ont un millionnaire comme mécène, elles n'ont pas des moyens infinis et donc, elles préfèrent quand ce sont d'autres qui font. Bref, la décision, elle ne se fait pas sur des considérations techniques, mais simplement par réalisme.
Or, dans notre cas, GNOME a commencé à avoir des dépendances fortes envers systemd (puisqu'il n'existait aucune autre implémentation de ces interfaces), et tout le reste est venu. Avant que GNOME ne s'y mette, systemd vivait dans son coin et personne ne songeait à switcher, ou en tout cas pas si vite étant donné la quantité de problème qui restait à régler avec systemd.
Développer du logiciel libre, ce n'est pas comme développer du logiciel tout court, il y a des règles tacites, des communautés à prendre en compte. Faire du logiciel libre ne garantit pas de ne pas faire de la merde hein. Si la stratégie d'entreprise de RedHat est si merveilleuse et bénéfique pour l'ensemble du monde libre, alors que RedHat essaie de convaincre plutôt que de passer en douce sans avoir l'air d'y toucher. RedHat reste une entreprise avec ses intérêts particuliers et il se peut qu'un jour les intérêts de RedHat soient en contradiction avec les intérêts du monde libre.
[^] # Re: Portabilité et forçage
Posté par Maclag . Évalué à 4.
Devant de telles difficultés, on devrait donc être bien content de l'existence d'un poids lourd tel que RH, sinon les autres distros rameraient à mort pour avoir un résultat moins évolué.
C'est bien ça?
J'ai du mal à suivre: ce sont les communautés qui sont trop connes et suivent RH au lieu des anti-systemd qui te posent un problème?
Si RH pourrit autant l'écosystème, encore une fois, pourquoi est-ce qu'on ne voit pas les autres acteurs s'organiser pour proposer autre chose?
Ah, peut-être parce que les autres acteurs sont très contents de ce que produit RH, et c'est ça qui agace.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 5.
Tu veux dire "ne rien faire rends dépendant de ceux qui font les choses, car sinon, on arrive pas à suivre ?"
khof BSDs khof
Fedora a switché. Suse, Mageia, Arch. Debian et Gentoo l'ont mis en option depuis longtemps. Je boote mon serveur Debian stable avec. Et il est dans Debian depuis 2010. Pour un truc ou personne ne songé à switcher, je trouve que les gens ont vite fait le travail.
Sinon quoi ?
Ah oui, sinon, les gens vont râler sur linuxfr et slashdot. En vérité, les règles, c'est pas "faut respecter les communautés". C'est plus "on propose, et si les gens sont content, ils suivent, sinon, ils se barrent". Et visiblement, la majorité se barre pas. Ou plutôt, la majorité qui compte, cad les contributeurs. L'équipe de systemd a consulté les gens des autres distributions dés le début, c'est pour ça que le système utilise /etc/hostname et d'autres debianismes.
Si tu ne respectes pas les règles de la communauté, tu as personne qui vient contribuer sur ton logiciel, et on se retrouve avec la même communauté qu'un logiciel proprio ( ie, personne ne t'aide ). Le fait que des externes au projet contribuent semble montrer que les règles sont respectés.
En pratique, ça serait quoi ?
Le code est libre, si tu changes la licence, l'ancienne s'applique encore sur les anciens tarballs distribués. RH fait parti de l'OIN, donc je ne pense pas que les brevets soient un souci. Il reste divers trademarks, qui devraient bloquer qu'une paire de projets de la boite.
Le plus gros souci, ça serait d’arrêter de aire du libre. Mais pour ça, la solution, c'est que le reste du monde en fasse plus, et pour ça, faut arrêter de zoner sur linuxfr et commencer à contribuer.
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 1.
Un peu comme les pilotes propriétaires non ? Chacun est libre de développer un pilote libre. Et si le pilote propriétaire pose problème à des gens, alors il n'est pas utilisé/integré.
Oh wait.
[^] # Re: Portabilité et forçage
Posté par claudex . Évalué à 7.
À partir du moment où on a les specs, je ne vois pas le problème. Et les specs de systemd, elles sont disponible. Sinon, tu veux demander aux fabricants d'écrire et tester un pilote pour Windows, Linux, Mac, BeOS, FreeBSD, NetBSD, ReactOS, OpenBSD, Hurd, etc. ?
« 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: Portabilité et forçage
Posté par Enj0lras . Évalué à -3.
Non, je préfère que les fabricant écrivent des drivers portables. Ce que certains font. (faisaient ?)
[^] # Re: Portabilité et forçage
Posté par claudex . Évalué à 9.
Il faudra m'expliquer comment tu fais un pilote portable, vu que quasiment chaque OS a sa propre API plus ou moins différente des autres. Bien sûr, certains système sont assez proche, ou d'autre ont une couche de compatibilité mais il arrive toujours un cas qui ne marche pas. Et tu ne répond pas à la question du test. Sur combien de système le pilote doit-il être validé (parce qu'un pilote « portable » qui ne marche pas, ça ne sert pas à grand chose) ?
« 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: Portabilité et forçage
Posté par Enj0lras . Évalué à 3.
Apparament, des gens savent le faire. Notament les pilotes wifi intel et atheros. Ou l'implémentation de référence pour acpi. Et dans la théorie, DRM au début avait été écrit pour être portable. ça se ressent encore un peu dans DRM lui meme, mais plus du tout dans GEM, TTM, ou les pilotes.
La solution tient en un mot : abstraction. C'est pas si différent de faire un toolkit portable. Quand tu prends Qt, tu as pleins d'abstraction pour gérer les fonctionnalités qui sont différentes entre tout les OS. Pour un pilote c'est pareil. Du moment que le développeur du pilote fournit une abstraction bien fichue, et documentée, il ne reste alors plus qu'aux devs des OS d'écrire une implémentation de cette abstraction pour leur OS.
Pour ce qui est à la validation, il est parfaitement acceptable de ne le tester que sur un OS et laisser les développeurs d'autres OS faire de l'intégration et remonter les bugs. Intégrer un pilote est énormément plus simple qu'en développer un nouveau.
[^] # Re: Portabilité et forçage
Posté par claudex . Évalué à 6.
Tu veux dire, un pilote libre avec un matériel documenté ? Tu m'étonne que c'est assez simple à porter. Mais donc, le fabricant ne fournit pas qu'un pilote, il doit aussi libérer le code et documenter le matériel, ce qui est très loin de ce qui était évoquer au début.
Et donc, après, on s'est rendu compte que ce n'était pas possible ?
Et Qt fait un travail de portage assez impressionnant mais il y a plein de bugs d'intégration. Si on prend l'équivalent pour un pilote, ça veut dire qu'on ne peut pas exploiter son matériel correctement (consommation d'énergie trop importante, performances réduites, fonctionnalités absentes…) c'est loin d'être une situation idéale.
En gros, c'est ce qui se fait actuellement avec l'acpi et Windows. Résultat, les développeurs des OS passent leur temps à écrire des contournements pour plein de trucs. C'est vraiment un comportement à la con.
« 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: Portabilité et forçage
Posté par ariasuni . Évalué à 2.
Quels bugs?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par claudex . Évalué à 4.
Alors, c'est principalement sous mac il me semble (sous Windows, il n'y a pas grand chose et sur Linux, il n'y a pas beaucoup d'intégration vu qu'il n'y a pas beaucoup de truc où s'intégrer (pas d'ui commune par exemple)). Par exemple, le comportement de la scroll bar n'est pas celui par défaut, les champs de texte n'utilise pas ceux du système (compliquant l'utilisation d'un correcteur orthographique ou d'un système de synthèse vocale). Ce sont les deux dont je me souviens, je ne l'utilise pas sous autre chose que Linux (avec KDE en plus), donc je ne me souviens pas de tout.
« 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: Portabilité et forçage
Posté par Enj0lras . Évalué à 0.
Et au passage, j'aimerais bien les specs de udev.
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 2.
Tu veux dire "l'API" ?
http://www.freedesktop.org/software/systemd/libudev/
ça se trouve sur un moteur de recherche
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 2.
Tu as lu cette doc ? Les propriétés des devices n'y sont pas documentés.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 4.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 1.
documentées même :).
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 1.
Sauf erreur de ma part, c'est visiblement pas un problème pour la communauté gnome, vu qu'Emily Gonyer n'a pas été élu:
https://vote.gnome.org/results.php?election_id=22
Je doit reconnaitre que je pige pas trop la méthode de comptage, mais je doute qu'on puisse contester que ça n'a pas bousculé vraiment le scrutin.
Oui. parce que c'est libre, c'est pas de l'enfermement. C'est juste des gens qui font pas ce que tu veux mais qui t’empêche pas de faire ce que tu veux. Que la majorité ne te suive pas est une autre paire de manche.
[^] # Re: Portabilité et forçage
Posté par Ph Husson (site web personnel) . Évalué à 3.
Comme LibreSSL ?
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -5.
fais semblant de pas comprendre que Red hat pousse systemd dans gnome
oui le probleme est red hat
Ils savent que les autres n'ont pas les moyens de leur resister
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
Franchement j’ai envie de travailler pour Red Hat juste pour faire chier ceux qui crachent dessus à longueur de journée.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par moulator . Évalué à -2.
Et la prise d'otage d'udev par systemd, qui a rendu toutes les applications dépendantes d'udev dépendantes de systemd, c'était quoi ? Ce n'était pas pour "forcer la main" de tous ceux qui utilisaient udev peut-être ?
[^] # Re: Portabilité et forçage
Posté par Maclag . Évalué à 2.
Et l'abandon du développement d'udev par tous ceux qui ne voulaient pas de systemd, c'est pas un complot pour pouvoir dénoncer un pseudo-complot de chez RH?
[^] # Re: Portabilité et forçage
Posté par moulator . Évalué à -6.
Ben si udev n'avait pas été rendu dépendant de systemd, je suppose que ce ne serait pas arrivé… l'abandon n'est donc que le résultat de la prise d'otage.
[^] # Re: Portabilité et forçage
Posté par Maclag . Évalué à 10.
Prise d'otage par qui?
udev est Libre, comme le reste.
Gnome ne plait plus? Les intéressés forkent et ça avance.
udev ne plait plus? Personne ne fait rien à part râler. Ah si, il y a eu une tentative de fork qui n'a (il me semble) pas duré longtemps parce que bon, une fois qu'on met les mains dedans, on se rend compte que c'est vraiment beaucoup de travail. Et ces salauds de développeurs refusent de nous écouter nous, la minorité, quand on leur explique ce qu'ils doivent ou ne doivent pas faire du projet.
Moi j'exige qu'on développe un module qui me permette d'utiliser un smartphone avec stylet comme interface d'entrée au même titre que clavier ou souris.
Mais ces salauds de développeurs prennent en otage mon idée en ne la développant pas sans rien en échange que ma gratitude.
Tu ne trouves pas ça profondément injuste?
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 3.
Et sans parler du fait que chacun est libre de maintenir sa propre version d'udev, c'est un mensonge que de dire que udev a été rendu dépendant de systemd. Il est développé dans le meme git que systemd, mais à ma connaissance ca ne l'empeche pas de pouvoir fonctionner sans systemd.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 1.
En pratique c’est plus compliqué que ça, mais les développeurs d’udev n’ont pas été forcé de travailler avec les gens de systemd hein… Et je trouve ça plutôt bien qu’il y ait de la collaboration (même si du coup c’est dommage que ça soit plus compliqué de faire tourner udev sans systemd).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 5.
Y a eudev : https://github.com/gentoo/eudev/commits/master
Alors bien sur, ça reprends beaucoup de udev, preuve que c'est pas si simple. Et grosso modo, y a quelques distros qui doivent proposer ça, mais y a pas la vivacité de systemd.
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à 3.
d'un autre cote il est pas censé remplacé systemd mais udev….
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à -4.
En tout cas, il est dépendant de linux. ça c'est un fait. Et pas udev lui même, son API est dépendante de linux. Donc non chacun n'est pas "libre" de développer sa propre version d'udev.
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 3.
De quoi tu parles ? udev est dépendant de linux, et alors ?
Ben si, udev est libre et l'a toujours été, donc chacun est libre de forker et maintenir sa propre version si ce que font les mainteneurs actuels ne convient pas.
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à -3.
Tu vis dans un monde magnifique. N'empêche que quand tu as une API comme ça qui devient utilisée par de très nombreux programmes, et que ces programmes ne fonctionnent pas sans cette API, et que cette API est liée fortement à un OS, tu n'es pas "libre de forker".
Tu ne peux pas forker, à moins de recoder linux. Donc il y a une contrainte, qui vient du fait que l'API n'est pas portable. Dans ce cas, moi je dis qu'on m'impose udev d'une certaine manière.
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à -3.
À tout ceux qui moinssent, je vous mets au défi de vous confronter avec la réalité et d'essayer de recoder udev. Avant d'affirmer de telles choses, j'ai essayé.
[^] # Re: Portabilité et forçage
Posté par GnunuX (site web personnel) . Évalué à 10.
Moi je ne "moinssent" pas du tout pour cette raison là. Dans la même page tu dis que :
C'est un peu … contradictoire.
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 0.
Euh non ? C'est gros systemd. Tu peux réinventer des choses et en réutiliser d'autres, je ne vois pas en quoi c'est contradictoire.
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 3.
Cette discussion était en réponse à un message qui pretendait que udev a été rendu dépendant de systemd.
Et ce qui a été dit c'est que si c'était le cas (ce qui ne l'est pas à ma connaissance), il serait toujours possible de forker udev pour continuer à le rendre independant de systemd.
Et je vois pas ce que viennent faire ici tes histoires de "recoder linux" ou que l'API ne soit pas portable sur autre chose que linux, puisque udev a des le début été crée pour le noyau linux spécifiquement, et ca n'a rien à voir avec le merge dans le meme dépot git que systemd.
Tout comme le noyau linux t'impose son API, Libreoffice t'impose son format de fichier, apache t'impose son format de fichiers vhost, docker t'impose son format de conteneurs, etc … Bon en fait on pourrait dire que tous les logiciels utilisés par beaucoup de gens t'imposent leur APIs, protocoles ou formats de fichiers, et tu peux pas les modifier librement sans que ca pose des problèmes.
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -2.
sauf que sauf le noyau tu peux aussi ne pas les utiliser et libreoffice ne permet pas d'ecrire des fichier .txt ?
si c'est le cas c'est une honte
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 5.
Désolé mais ta phrase ne veut rien dire.
utiliser quoi ?
libreoffice permet sans doute d'ecrire des fichiers .txt, mais je ne vois pas le rapport.
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -3.
erreur de ma part sauf le noyau les autres tu peux ne pas les utiliser donc leur format on s'en fou un peu
tu vois pas le rapport ?
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 6.
Ben udev aussi tu peux ne pas l'utiliser. Et tu peux aussi ne pas utiliser d'ordinateur du tout si tu veux.
Et alors ?
[^] # Re: Portabilité et forçage
Posté par Enj0lras . Évalué à 0.
C'est au sujet de 'je suis forcé d'utiliser systemd'
N'empêche que ça reste un composant important de systemd qui rend plus difficile la réutilisation de certains composants (notament comme logind) sous d'autes OS. hors, logind devient une API utilisée par les logiciels utilisateurs.
Toutes ces choses, je peux les utiliser sur n'importe quel OS.
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 4.
Ce qui ne veut rien dire. La phrase c'était "Tu ne peux pas forker, à moins de recoder linux". Quel est le rapport entre cette phrase et etre soit disant forcé d'utiliser systemd ?
Mais de quoi tu parles ? Que vient faire logind la dedans ?
Oui et alors ?
[^] # Re: Portabilité et forçage
Posté par eingousef . Évalué à 6.
Je suis debian testing (jessie) et j'arrive à utiliser XFCE sans systemd. Pour ça j'ai viré :
*splash!*
[^] # Re: Portabilité et forçage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -10. Dernière modification le 13 juin 2014 à 15:14.
Du coup tu n'as plus de gestion dynamique des connexions, plus de gestionnaire de connexion graphique, plus de montage de media en tant que simple utilisateur, plus de prise en charge des imprimantes HP, plus de prise en charge des systèmes de fichiers réseau par le gestionnaire de fichier. Super le Xfce sans systemd.
Il faut se rendre à l'évidence : systemd est un cancer.
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 7.
wicd ne fonctionne plus ?
Il y a un paquets de logiciels qui utilisent directement udev pour faire ça.
Et l'ensemble des gens de Gnome, XFCE, Debian, Arch, Fedora,… sont des jambons qui ne comprennent rien à ce qui est évident pour toi ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -6.
déja repondus :ils n'ont pas forcemment les moyens humains de le faire
c'est quoi ce melange logiciel et distribution….
les distribution n'ont pas forcemment les moyens humains de le faire ou les inconvenient de systemd sont pas suffissant pour qu'il passe du temps a faire autre chose
chez gnome c'est red hat qui pousse systemd chez xfce j'en sais rien
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
C’est le trouze-millième commentaire qui affirme ça… SOURCE?
Peut-être comme chez GNOME, le fait que les API systemd sont bien?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Anonyme . Évalué à 4.
Donc systemd c'est globalement bien, et qu'il y a peu d'inconvenients ce qui fait qu'il n'y a pas suffisement d'interet pour vouloir passer du temps à faire autre chose ?
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -3.
tu sais ce que veut dire ou ?
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
T’as pas dit que c’était un ou exclusif. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à -2.
a ou b veut dire: soit a soit soit b soit a et b mais en aucun uniquement a et b
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 10.
C'est un ensemble de projet qui ont fait le choix de systemd. Tu pense vraiment qu'il y a tant de gens qui se font enflés et qui le font sans crier sur tous les toits qu'ils marchent en crabe tellement ils ont mal ? Il y a aucun de ces projets qui communique vraiment pour dire que RH c'est des gens pas bien et que systemd ça pue mais qu'ils sont contraints et qu'ils en pleure toutes les nuits. Il y a des débats oui, mais aucun de ces projets n'affirme de manière un minimum officiel ce que vous avancé, c'est bizarre, non ? Et dans le lot j'ai pas mis d'autres mastodontes comme Novel ou Canonical.
Ils n'ont pas les moyens humains pour avoir ce genre de communication ou RH a des agents infiltrés partout ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 7.
Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.
Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 4.
Ouais Canonical ont du mal à faire de l’argent aussi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 3.
S'ils ont une possibilité pour faire un truc qui les démarque de RH et qui fait rêver les utilisateurs ça devraient leur rapporter. Ils considèrent que ça n'est pas une valeur ajouté suffisante pour leur rapporter, dis autrement, ils pensent que les gens qui gueulent ne sont pas prêt à financer le maintiens d'une alternative.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 1.
Upstart et Mir ça ne fait pas rêver les utilisateurs je pense (moi non plus d’ailleurs :P).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par barmic . Évalué à 3.
Ils ont abandonné upstart. Pour Mir on verra.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 8.
Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).
Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.
RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:
RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.
On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).
On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.
Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).
Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.
Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 2.
Oui c’est sûr qu’Upstart avait déjà des idées, mais il avait aussi des problèmes qui faisaient que ça ne valait pas forcément le coup d’y passer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 3.
Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.
Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.
Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 2.
Passer de ptrace aux cgroups aurait nécessité de refaire tout… ah bah d’ailleurs on l’a fait, ça s’appelle systemd. ;) Pour le reste je ne sais pas.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 3.
Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.
IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.
Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.
[^] # Re: Portabilité et forçage
Posté par eingousef . Évalué à 5.
Pour la connexion graphique j'utilise slim :)
Pour monter les médias amovibles en simple utilisateur il y a diverses solutions, j'ai opté pour pmount.
Les imprimantes je m'en fous j'en utilise pas.
Et pour me connecter en sftp, j'utilise sshfs (qui utilise fuse).
Après c'est sûr, vouloir conserver sysvinit oblige à se réconcilier avec la ligne de commande. /o\
*splash!*
[^] # Re: Portabilité et forçage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Pas de problème, personnellement je n'utilise pas du tout de bureau graphique, je disais juste que xfce se retrouve franchement castré sans systemd.
[^] # Re: Portabilité et forçage
Posté par eingousef . Évalué à 2.
Tous les environnements de bureau nan ? Je crois que tous les meta-paquets task-machin-desktop de testing ont des dépendances qui nécessitent systemd maintenant.
*splash!*
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 4.
Pas KDE en tout cas. Et je pense qu’Enlightment peut s’en passer et fonctionner très bien sans mais à confirmer.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par eingousef . Évalué à 2.
Je vois network-manager et policykit dans l'arbre des dépendances de task-kde-desktop. Mais dolphin et konqueror peuvent être installés sans systemd.
*splash!*
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 7. Dernière modification le 13 juin 2014 à 16:27.
D’ailleurs si vous pouviez éviter de supposer que tout le monde est sur Debian en citant un nom de méta-paquet hors contexte ça serait quand même vachement sympa pour ceux qui lisent. Je dis ça sans méchanceté hein, ça arrive à tout le monde.
Je sais pas ce qu’ils font chez Debian, KDE peut fonctionner sans Network-manager (et sans systemd). Par contre c’est marrant je viens de voir que le paquet Arch
qt5-basedépend de systemd, étrange.Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par esdeem . Évalué à 2.
Quoi, tout le monde n'utilise pas Debian ? ;)
Blague a part le fait que
qt5-basedépende de systemd sous Arch est tout de même plutôt étonnant.0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Portabilité et forçage
Posté par appzer0 (site web personnel) . Évalué à 2.
Xfce fonctionne très bien ici sans systemd. Il faut en revanche garder à l'esprit que les sessions doivent être gérées pour permettre le montage de volumes en tant que simples utilisateurs (entre autres.
Il faut donc utiliser le mécanisme polkit + consolekit + udisks. Seul GNOME3 demande systemd pour gérer ses sessions desktop ainsi que le suspend/resume si ma mémoire est bonne. systemd est un cancer mais un bon dépistage permet de l'éviter.
J'ajoute pour le troll que systemd depuis sa version 214 demande CINQ utilisateurs dédiés sur le système ainsi que SIX groupes dédiés, dont le groupe "systemd-bus-proxy", groupe qui fait 17 caractères.
Dixit "man 8 groupadd" à la section "Avertissements" :
[^] # Re: Portabilité et forçage
Posté par vv222 . Évalué à 2. Dernière modification le 13 juin 2014 à 22:05.
Sur une Debian Jessie (passwd version 4.2) :
[^] # Re: Portabilité et forçage
Posté par Misc (site web personnel) . Évalué à 2.
La version anglaise dit 32, la version française ( qui doit avoir du retard sur ma machine ) dit 16.
Et en fait, c'est dépendant de l'os :
http://community.aegirproject.org/developing/architecture/unix-group-limitations
Donc si on veut faire vraiment portable sur les anciens OS, c'est 8.
Et en effet, si on veut être compatible avec les systèmes à 16:
[^] # Re: Portabilité et forçage
Posté par Sufflope (site web personnel) . Évalué à 10.
4 characters for groups should be enough for everyone
Si on écoutait les anti-systemd, on mangerait encore de la viande cuite seulement si la foudre est tombé récemment sur un arbre à proximité.
[^] # Re: Portabilité et forçage
Posté par ariasuni . Évalué à 6.
Nan mais sérieusement, vous pouvez pas discuter deux secondes sans chier sur la gueule de systemd?
Et donc, ça tue des bébés chatons?
Pourquoi cette limitation arbitraire? Est-ce que ça a causé un problème jusque là? Parce que là ça ressemble un peu à du pinaillage quand même.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Portabilité et forçage
Posté par xcomcmdr . Évalué à 6.
Ah ben oui, le prix du Kilo-octet a explosé ma bonne dame !!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Portabilité et forçage
Posté par El Titi . Évalué à 9. Dernière modification le 14 juin 2014 à 14:03.
Bon alors pourquoi le premier post du fil est pour râler pour la non compatibilité avec Gnome ?
En fait t'es soit un trolleur de première
Soit un conservateur qui au nom de SA conception soi disant altruiste du monde veut restreindre la liberté des autres de le changer.
Systemd et mariage gay même combat pour les cathos.
Ne faites pas ce que je n'aime pas même si je ne suis pas concerné.
[^] # Re: Portabilité et forçage
Posté par eingousef . Évalué à 3.
J'ai oublié de dire : pour le wifi j'utilise wpa_supplicant avec dhclient. J'ai essayé wicd mais c'est un peu de la merde.
*splash!*
[^] # Re: Portabilité et forçage
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Perso pour les connexions j'utilise ifupdown, tout simplement. Il a d'ailleurs une fonctionnalité peu connue de profils de connexion :
permet par exemple de configurer l'interface wlan0 selon les paramètres précisés dans le fichier d'interface sous le nom sl2014.
[^] # Re: Portabilité et forçage
Posté par Sufflope (site web personnel) . Évalué à 10.
Comme la GPL ?
[^] # Re: Portabilité et forçage
Posté par jihele . Évalué à 10.
D'après Wikipedia, il est né le 30 mars 2010. Ce serait donc plutôt un bélier.
[^] # Re: Portabilité et forçage
Posté par modr123 . Évalué à 1.
il serait poisson pas belier
http://fr.wikipedia.org/wiki/Astrologie_sid%C3%A9rale
# Quel joli troll !
Posté par Enj0lras . Évalué à 10.
Ça ressemble à un post de propagande à mon avis, j'aimerais faire quelques commentaires.
Bien que je n'irais pas jusqu'à dire que systemd est monolithique (je pense que ça s'apparente de plus en plus à un OS à la BSD, ce qui n'est pas une critique), je pense que ça va un peu loin.
En effet, je dirais que systemd n'est pas moins sécurisé qu'autre chose, mais de là à dire qu'il a été concu selon le modèle séparation des privilèges, il y a un pas (énorme). Exemple : le code qui parse les units s'execute en root, et il est privilégié. Ce qui augmente énormément la surface d'attaque;
Je ne suis pas sûr de ça du tout. En tout cas, la courbe d'apprentissage est très élevée. Je pense qu'un logiciel simple c'est un logiciel qui fournit un petit nombre d'objets simples qui peuvent être composés simplement pour obtenir des choses complexes. C'est le cas de vi, c'est le cas du shell. CE qui n'est pas le cas de systemd du tout. Je prendrais un exemple simple, d'une option aléatoire :
IgnoreOnIsolate=
AllowIsolate=
IgnoreOnSnapshot=
Quelle mauvaise foi ! Recode une bibliothèque dhcp alors qu'il en existe des 10aines ? Recoder un émulateur de terminal alors qu'il en existe des dizaines ? Si ce n'est pas du NIH, je ne sais pas comment ils appellent ça.
Je ne rentrerais pas sur la polémique "les gens qui affirment ça sont des intégristes religieux", mais je ne reprendrais ce que j'ai dit un peu plus haut. Unix on dit souvent que c'est "tout est fichier". Ce qui est bien à cela c'est que l'OS fournit des commandes basiques pour s'occuper de fichiers. Et ils fournit un outil formidable pour composer ces commandes et obtenir des operations complexes. Le shell. Alors après, le shell est vieilli, je ne suis pas un fanatique du shell, je suis totatlement ouvert à autre chose. Mais encore une fois, "composer des operations simples" c'est ça unix. Le pipe a été une invention majeure dans la création d'unix. Et je trouve que systemd ne respecte pas vraiment ce principe.
Comme BSD ne veut pas d'un système non portable et qui reinvente pleins de bibliothèques présentes dans le systeme de base, on peut faire un tel systeme et dire que de toute façon il ne le veulent pas.
Admettons. Il y a une certaine logique à cela :). personnellement je pense que certains BSD n'auraient pas craché sur un nouvel init simple qui fait du monitoring et du démarage parallele.
[^] # Re: Quel joli troll !
Posté par Prosper . Évalué à 2.
La raison de la gestion du reseau et donc de dhcp dans systemd est surtout d'une part d'avoir un os connecté le plus tôt possible, d'autre part avoir des containers qui se lancent extrêmement rapidement cf https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8 .
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 10.
Ce n'était peut être pas très clair, mais comme je le dis au début, je ne critique aucunement le fait d'avoir la gestion du réseau (ou d'autre chose) dans le dépot systemd et intégré avec systemd.
Cela dit, rien n'interdit de réutiliser une lib dhcp existante. En coder une nouvelle, c'est du NIH. ça ne veut pas dire que c'est bien ou mal, ça veut dire que c'est du NIH, affirmer le contraire c'est nier la réalité des faits.
[^] # Re: Quel joli troll !
Posté par Prosper . Évalué à 7.
Ce que je voulais noter c'est que ça semble largement plus rapide que les bibliothèques existantes. Donc c'est pas exactement réinventer pour faire la même chose mais pour faire mieux et/ou differement, comme de très nombreux logiciels qui sortent tous les jours. Et puis personne ne dit que nginx c est du NIH d'apache , dpkg du NIH de rpm ( ou inversement) ou pour aller beaucoup plus loin , les 1032343 distributions Linux , du NIH de Yggdrasil.
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 2.
Donc au lieu d'opmitimiser une bibliothèque existante, on en écrit une autre. Si c'est pas du NIH c'est quoi ?
Le parallele nginx apache ne tient pas car nginx a un design fondamentalement différent de nginx. Pour le reste oui je suis d'accord. C'est du NIH. Après tu peux aimer le NIH, mais prétendre que ça n'en est pas, c'est un peu gros.
[^] # Re: Quel joli troll !
Posté par Diagonale de Cantor (site web personnel) . Évalué à 10. Dernière modification le 13 juin 2014 à 14:50.
Ce qui n’a rien à voir avec le design d’apache qui s’oppose à celui d’apache !
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . Évalué à 8.
La réponse est sur le g+ du dev:
https://plus.google.com/+TomGundersen/posts/U6Es8bpmMbP
ie, "l'existant ne nous va pas, mais on a regardé et on va bosser sur une nouvelle lib proposé par quelqu'un d'autre". Donc reprendre le code de connman, c'est pas vraiment du NIH.
Voir aussi https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8
Et les commentaires, surtout la fin, ou il dit avoir regardé les 3 libs et en avoir repris une.
Il explique aussi pourquoi systemd a sa propre lib pour la communication avec le kernel :
https://plus.google.com/+TomGundersen/posts/JhaBNn8Ytwu
( TLPL: les libs sont synchrones et bloquantes, le dev veut de l'asynchrone non bloquant, ça implique de tout refaire dans tout les cas )
[^] # Re: Quel joli troll !
Posté par Prosper . Évalué à 9.
Sinon imaginons le problème à l'envers, si systemd avait été dépendant de dhcpcd, t'aurais eu des gens pour râler que systemd est encore dépendant de trop de choses gnagnagna c'est nul .
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à -1.
Des gens auraient râlé si l'utilisant avait été réutilisé, donc, c'est pas du NIH ?
Je ne suis pas sûr de suivre ton argumentation.
[^] # Re: Quel joli troll !
Posté par Prosper . Évalué à 2.
Non rien à voir avec le NIH là.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . Évalué à 6.
En fait, y a pas de lib dhcp. Je sais qu'il y a des discussions en cours entre les gens de connman chez intel et des gens qui bossent sur systemd pour justement avoir une lib.
Mais la, y a rien que je sache. Et c'est dommage, notamment pour dhcpv6 ou toute les options sont pas supportés aussi partout.
[^] # Re: Quel joli troll !
Posté par moulator . Évalué à -2.
Il y a très longtemps que Linux est capable de booter en "diskless", avec du DHCP intégré au noyau ; on a pas attendu systemd pour le faire.
[^] # Re: Quel joli troll !
Posté par Anonyme . Évalué à 10.
Alors qu'il existait deja des clients dhcp. Encore du NIH, c'est scandaleux !
[^] # Re: Quel joli troll !
Posté par Ignatz Ledebur . Évalué à 3.
C'est pas un peu contradictoire avec soutenir que la vitesse de systemd n'est qu'accidentelle et pas du tout un point essentiel de design ? :|
[^] # Re: Quel joli troll !
Posté par Anonyme . Évalué à 3.
La vitesse de boot, c'est pas un point de design. C'est le resultat de la facon dont est fait systemd, qui permet de tout lancer en parallel.
Et c'est pas par ce qu'il y a des gens qui travaillent pour optimiser au maximum la vitesse de boot que ca en fait un point essentiel.
Tout comme tu peux certainement trouver des commits dans le kernel linux qui commencent par "optimize blabla …", ce qui ne veut pas dire que les performances c'est le point essentiel du noyau, avant la securité, stabilité, portabilité, etc …
[^] # Re: Quel joli troll !
Posté par Ignatz Ledebur . Évalué à 3.
J'entends bien que ça découle de la parallélisation, mais quel est l'intérêt de paralléliser, à part aller plus vite ? Sauf à soutenir que systemd est accidentellement parallélisable, je ne vois pas comment on peut soutenir que ça n'a rien à voir avec le design initial…
[^] # Re: Quel joli troll !
Posté par ariasuni . Évalué à 3.
Bien découpé → parallélisable. Mais oui ils essaient aussi d’améliorer la vitesse de systemd et je trouve que ça fait bien dans les bancs d’essai contre Windows. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par Zenitram (site web personnel) . Évalué à 3.
On peut souhaiter qu'un élément qui met 10 minutes à se lancer ne bloque pas toute la machine, et que le reste soit accessible au bout de 30 secondes comme sans cet élément plutôt car les autres services mettent 30 secondes en tout (sérialisé). Et manque de chance, quand on implémente, on a pas bloqué la paralélisation à 2 process, on a tapé "10" (par exemple) à la place de "2" dans la ligne de code, on tombe sur 10 secondes. Faudrait-il changer "10" en "2" pour te faire plaisir?
[^] # Re: Quel joli troll !
Posté par Anonyme . Évalué à 7.
systemd est concu pour gerer les services de facon fiable. Pour gerer les services de facon fiable, il faut gerer correctement les dépendances entre les differents services (en incluant la dedans les techniques comme la creation de sockets par systemd). Ca permet donc d'avoir un systeme de boot fiable, et tellement fiable qu'on peut se permettre de tout démarrer en meme temps, et au passage avoir un boot plus rapide. Ca veut pas dire que le boot plus rapide est l'objectif principal.
[^] # Re: Quel joli troll !
Posté par ariasuni . Évalué à 5.
Sans vouloir remettre ta parole en doute, source? De plus, les scripts SysV étaient exécutés par root non? (vrai question)
Ce qui rendrait le langage bien plus compliqué pour un gain à peu près nul, alors que là c’est TRÈS facile à analyser, en plus c’est un format standard de fait pour la configuration des logiciels. En plus il est facile de savoir si un script est faux, alors que si on commence à faire de la composition c’est déjà bien plus difficile. Là on a un nombre déterminé de champs que l’on maitrise parfaitement.
Pour la bibliothèque DHCP je ne sais pas, mais depuis quand systemd contient un émulateur de terminal?
Pourtant, les multiples unités de systemd qui peuvent être chacune activées ou désactivées indépendamment des autres (sauf dépendance entre deux unités bien sûr), il est beaucoup plus facile de désactiver certaines opérations qui auparavant faisaient partie du cœur du système d’init. Et grâce aux outils en ligne de commande on peut récupérer plus d’infos qu’avant, plus facilement et les traiter via la ligne de commande, les tubes tout ça. :)
Ils ne sont pas et n’ont jamais été intéressé par systemd, et ne le serait pas s’il était portable d’après tout ce que j’ai pu lire.
Quant au NIH, encore une fois, j’attends une preuve un peu plus convaincante qu’en affirmation en l’air.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 2. Dernière modification le 13 juin 2014 à 17:16.
Je pense que la déserialisation est implementée ici : http://cgit.freedesktop.org/systemd/systemd/tree/src/core/unit.c
et pour autant que je sache c'est executé dans le contexte du pid 1.
Après, oui les scripts sysV ont le même problème, je n'essaye pas de dire que c'est mieux ou moins bien que systemd, je réponds juste à certains points sur lesquels je suis en désaccord concernant systemd.
Admettons. C'est un point de vue que je ne partage pas, mais on peut dire que ça se rapporte à l'eternel débat vi/emacs, c'est deux visions des choses différentes :).
J'ai cherché justement après avoir posté ça, apparament ça n'a pas été mergé, mais il y avait un début de code. J'espère juste simplement qu'ils vont ajouter cette fonctionnalité (parce que c'est une bonne idée) mais qu'ils vont se baser sur l'existant, notament kmscon.
Par systemd non. Par un nouvel init, c'est pas aussi simple.
Je pense que DHCP est un bon exemple, mais si ça te suffit pas, il y aussi timesyncd
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . Évalué à 5.
C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser. Non pas que ça veuille dire "on s'en fout de la sécurité", mais que le fait de faire l'analyse du fichier dans un process à part avec un canal de communication avec le pid 1 est une complication qui n'a pas jugé valoir la chandelle pour le moment. Une des choses que j'ai trouvé complexe dans le code d'upstart est justement ça, l'overhead lié à la communication interprocessus, avec les problématiques de synchronisation, etc, etc. Peut être que ça arriveras plus tard, mais je pense que c'est plus important pour un browser que systemd.
C'est le lien que tu cherches, je pense :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html
Visiblement, c'est le dev de ksmcon qui a proposé systemd-consoled, mais j'imagine qu'il fait du NIH sans le vouloir :)
DHCP est pas le meilleur exemple de NIH. Timesyncd est déjà mieux. Ensuite, le client que tout le monde utilise ou presque, c'est celui de l'ISC. Pareil pour ntpd. Je dit pas qu'il y a un lien mais bon, peut être qu'il y a une piste.
Mais après avoir vu le code, il semble que timesync fasse juste du sntp client ( tu va pas loin avec 1200 lignes de code ), et pas la totale comme ntpd qui peut faire serveur, qui a un algo bien spécifique pour gérer les cas particuliers et le drift, etc.
( et tout comme dhcp, y a pas de lib existant qui vont permettre l'usage du code de ntpd, donc tu doit refaire tout ).
[^] # Re: Quel joli troll !
Posté par ariasuni . Évalué à 5.
En plus, utiliser un format simple et standard, ça permet de limiter fortement les anomalies.
kmscon n’a rien à voir avec systemd à la base, c’est pour remplacer les tty tout moisi. C’est une console virtuelle qui utilise KMS, XKB donc les dispositions de claviers de X.org, UTF-8 et tout, prise en charge du multi-siège et plein de trucs cool comme ça. Donc en gros ça sera plus moderne et ça uniformisera le fonctionnement de certains trucs avec X.org/Wayland (notamment KMS et le fonctionnement du clavier).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2.
C'est déjà le cas de la console Linux normale.
C'est déjà le cas de la console Linux normale avec console-setup.
C'est déjà le cas de la console Linux normale.
Ah, ça c'est une vraie nouveauté. Qui ne sert à peu près à personne, mais c'est cool dans l'idée.
Tu as des exemples ? De trucs vraiment nouveaux, je veux dire.
Notamment d'autres trucs j'espère, parce que ça, ce sont des choses déjà uniformisées avec la console Linux normale…
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 7.
Le vrai avantage par rapport à la console linux, c'est que ça tourne pas dans l'espace noyau.
[^] # Re: Quel joli troll !
Posté par ariasuni . Évalué à 2.
Donc seulement sous Debian/Ubuntu et c’est un peu de la bidouille quand même non?
Ok j’ai peut-être exagéré, mais ça a l’air vachement bien. :)
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 2. Dernière modification le 13 juin 2014 à 15:57.
C'est bien ce que j'avais compris. Mais, je ne sauterais pas aussi vite que toi sur la conclusion. Les units sont distribués par des logiciels tiers, que tu peux ne pas vouloir faire tourner en root (souvent tu lances un daemon sous un autre utilisateur par exemple). Après je dis pas que c'est une faille majeure, et évidement c'est beaucoup moins important que dans un navigateur, pour autant je trouve un peu rapide une affirmation comme :
Oui je suis au courant que c'est le même dev, je vois pas en quoi ça change. Tu peux toujours te NIH tout seul. Bon après c'est probablement pas le meilleur exemple, mais encore une fois il y a des 100aines de libs pour emuler les terminaux, dont certaines avec un nombre minimal de dépendance. Par exemple il y a des gens qui travaillent sur le meme type de projet pour BSD qui reutilisent ce qui a été écrit pour le noyau. Après, je ne juge pas, je ne dis pas que c'est mieux ou moins bien, juste que pour moi ça rentre dans la catégorie NIH.
Presque tout le monde sous linux :). Sinon je ne te suis pas. Quel est le soucis avec ISC ? Dans tout les cas, il y a toujours moyen d'extraire le code générique des logiciels existant, et de ne recoder que la partie qui t'intéresse, c'est à dire dans ce cas le glue avec systemd et les units. Je pense vraiment que réutiliser du code stable est toujours gagnant.
[^] # Re: Quel joli troll !
Posté par gnumdk (site web personnel) . Évalué à 7.
On est vendredi mais tout n'est pas permis, en particulier assumer de dire une telle ânerie!
[^] # Re: Quel joli troll !
Posté par Anonyme . Évalué à 8.
Si tu as accès en écriture à un fichier unit, alors tu peux faire executer ce que tu veux en root. Donc si tu as pas confiance dans le logiciel tiers qui distribue le fichier unit, je pense que tu as un problème quelle que soit la facon dont est fait le parsing.
Et si le parsing de ces fichiers était fait par un processus avec des droits restreints qui transmet le resultat du parsing au pid 1, ca ne rendrait pas un bug dans le parsing moins important. Si tu peux prendre le controle du processus qui fait le parsing, alors tu peux lui faire transmettre au pid 1 n'importe quelle commande à executer en root. Donc ca n'apporterait aucune sécurité en plus, et au contraire ca complexifierait le fonctionnement, ce qui augmenterait les possibilités de bug.
[^] # Re: Quel joli troll !
Posté par kna . Évalué à 5.
Si tu as accès en écriture à un script init SystemV, alors tu peux faire executer ce que tu veux en root. Donc si tu as pas confiance dans le logiciel tiers qui distribue le script init, je pense que tu as un problème quelle que soit la facon dont il est lancé.
À la différence, que tu as plus vite fait de vérifier un unit systemd, qu'un script SystemV obscur comme on en trouve dans plusieurs distribs.
Par ailleurs, tu as le même problème avec les conf des daemons que tu lances en root, par exemple http://httpd.apache.org/docs/2.2/fr/invoking.html#startup
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 1.
fair point.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . Évalué à 3.
Dans ce cas, systemd le permet, via User=. Encore mieux, via l'activation par socket, tu peux même espérer avoir les softs ne jamais voir l'uid root, dans certains cas spécifiques.
En fait, non seulement systemd permet ça, mais en plus, permet de rajouter facilement la configuration via les drop-in config ( ie, faire un fichier /etc/system/foo.service.d/foo.conf avec juste User=foo et paf, il va faire ce que tu veux, à savoir combiné ton service et celui du distributeur tierce en gérant l'upgrade proprement )
Le NIH, c'est "Not Invented Here". Quand tu refait ton propre code, c'est pas vraiment du NIH, par définition. Est ce que pour toi, NIH veut dire "refaire du code alors que du code existant rempli une partie des besoins", auquel cas, on peut qualifier tout un tas de trucs de NIH…
( ou du moins, je pense que systemd-consoled n'est pas un NIH de ksmcon pour ma définition de NIH, mais c'est juste mon point de vue ). J'imagine qu'on ne mets juste pas la même chose sous le terme NIH.
Personnellement, je leur reprocherais une certaine obscurité et/ou de l'amateurisme. Exemple, le bug tracker de bind qui est une liste de discussion, les VCS des projets sont parfois non publiques et/ou mal documentés ( celui de dhcp me semble assez récent par exemple, bind < 10 n'etait pas existant). L'abandon soudain de bind 10 est un exemple de process interne non discuté en publique, etc, etc.
Donc je pense que la collaboration peut être difficile avec l'ISC, d'ou sans doute le fait que personne ne tente de faire une lib pour le dhcp en partant de dhcpd (encore une fois, l'équipe de connman bosse sur ça)
[^] # Re: Quel joli troll !
Posté par Enj0lras . Évalué à 3. Dernière modification le 14 juin 2014 à 00:48.
Ok. Cela dit il est possible de partir de dhclient (de BSD). La version dans OpenBSD est maintenue par les gens d'openbsd, qu'il est quand meme difficile de traiter d'amateurisme.
[^] # Re: Quel joli troll !
Posté par Misc (site web personnel) . Évalué à 5.
Je pense que l'affaire du dernier bug d'openssl montre bien pourquoi les gens preferent manger du verre pilé que de traiter avec Theo.
Sinon, le client des BSD est dérivé de celui de l'ISC :
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sbin/dhclient/dhclient.c?rev=1.311;content-type=text%2Fplain
Et il est pas portable tel quel sur Linux. Exemple, prenons le premier fichier, le code pour faire un socket bpf ( http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/bpf.c?rev=1.32;content-type=text%2Fplain ). Openbsd demande à ouvrir un device dans /dev, Linux fait ça via une option sur le socket ( https://www.kernel.org/doc/Documentation/networking/filter.txt ).
La syntaxe des filtres BPF semble aussi ne pas être la même, donc il faut aussi faire des adaptations.
Les ioctl sont pas pareil ( je pense pas que BIOCVERSION existe sous Linux, aprés une rapide recherche ). Et je suis sur que l'ajout de route non plus. Et après lecture du code, je suis pas sur qu'il gére pas le dhcpv6 ( avec délégation de prefix, etc, etc ).
Et c'est pas une lib.
Donc si le but, c'est juste de forker le code pour faire chier Theo, je suis pas sur que ça vaille le coup, vraiment.
Et pour Freebsd, bah pareil, le client dhcp est dérivé de openbsd, et en plus, utilise capsicum (non dispo sur linux) :
http://svnweb.freebsd.org/base/head/sbin/dhclient/bpf.c?revision=263234&view=markup
[^] # Re: Quel joli troll !
Posté par Anonyme . Évalué à 4.
Et pourquoi faudrait il absolument repartir d'un truc deja existant ?
Y a des cas ou repartir d'un truc existant pour l'ameliorer est le plus simple. Mais y a aussi des cas ou rien de ce qui existe deja est adapté à ce qu'on veut faire, et ou le plus simple c'est de repartir de zero. Et parfois aussi on ne peut pas dire de facon evidente laquelle des 2 solutions est la meilleure.
Et au final c'est juste un choix à faire par le developeur, y a pas de regle generale la dessus. Comme le choix du language, du type de base de données, du format de fichier, de l'environment de dev, etc …
[^] # Re: Quel joli troll !
Posté par gnumdk (site web personnel) . Évalué à 4.
http://it-ebooks.info/read/1533/
C'est sur, y'a moins à retenir…
# Mise aux poings
Posté par Tit . Évalué à 7.
C'est de l'humour ? (on va s'en prendre plein la gueule)
[^] # Re: Mise aux poings
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Oui, c'est un trait d'humour de l'auteur (ou d'un des auteurs en tout cas).
# OK, merci pour la traduction
Posté par fridim . Évalué à 2.
Par contre :
La dépêche est une traduction d'un post sur le blog de l'auteur de systemd qui date de l'année dernière.
Donc si je résume, il s'agit de propos à jour, complètement objectifs, sans parti pris, sur un sujet pas du tout controversé ?
Vu que c'est vendredi, j'avoue, j'ai souri! :)
[^] # Re: OK, merci pour la traduction
Posté par ariasuni . Évalué à 7.
L’architecture de systemd ne change pas tous les quatre matins (et j’ai ajouté une note quand une donnée chiffrée avait changé, ou alors c’est précisé que c’était à la date de la publication de l’article).
Au moins on sait de quoi ça vient, et je pense qu’un développeur de systemd, de surcroit son développeur originel et principal payé pour bosser dessus sait à peu près comment il fonctionne.
On est trolldi sur trollfr après tout.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: OK, merci pour la traduction
Posté par Enj0lras . Évalué à 10.
C'est pas parce que c'est orienté que c'est pas intéressant.
[^] # Re: OK, merci pour la traduction
Posté par esdeem . Évalué à 5.
Parfaitement !
Personnellement, j'ai participé parce que c'était un challenge de traduire un truc avec lequel je ne suis pas vraiment d'accord.
Gros avantage, maintenant je sais de quoi je parle quand je donne mon avis sur le sujet ! :D
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: OK, merci pour la traduction
Posté par fridim . Évalué à 0.
vrai, mais c'était pas présenté comme ça
# À mon tour
Posté par benoar . Évalué à 10.
Comme d'hab, ça n'est pas que je n'aime pas systemd (il y a plein de bonnes idées dedans), mais la manière dont c'est fait et présenté. Mes quelques remarques :
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX… Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
C'est tellement hypocrite… les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX…). Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 0.
Quel existant? Plein de commandes de systemd n’existaient pas avant. En plus avec ces commandes peuvent facilement être utilisées dans des scripts par exemple.
Ou alors tu parles de SysV ou de l’init à la BSD d’Arch, et à ce moment-là c’est un peu con parce que justement un des buts de systemd c’était d’éliminer le code Bash exécuté au démarrage; à moins que tu ne parles d’Upstart qui a une conception très différente de systemd.
Du coup je ne comprends pas trop ce que tu reproches à systemd, est-ce que tu pourrais être plus précis?
Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau; normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.
En quoi?
Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.
Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.
Bah systemd propose de nouvelles API et les gens les utilisent, c’est tout.
Avant ils faisaient comment avec SysV et tout?
Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.
Mais il reste beaucoup de petits projets qui manquent de bras aussi.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par benoar . Évalué à 2.
C'te blague ; extrait de https://github.com/systemd/systemd/tree/master/src là ou je vois des outils qui existaient déjà : ask-password, backlight, cryptsetup, fsck (sans déconner !), hostname, locale, modules-load, network (je vois qu'ils ont réimplémenté tout iproute, sans même utiliser libnl), readahead, remount-fs, resolve, sysctl, …
En passant, à chaque fois aucun commentaire en haut du fichier pour expliquer ce que ça fait exactement : il faut aller voir le main().
Alors après, l'existant c'est un paquet de spaghetti hétéroclite immonde, mais avec des années et des années de polissage derrière. On sait très bien que quand un mec arrive en disant qu'il va tout régler d'un coup, on va se prendre des systèmes cassés pendant des lustres. Peut-être qu'il était tant, mais bon, non, ça n'a pas été fait de manière « modulaire » itérative, comme on aurait pu remplacer petit à petit les outils.
Ah ouai, carrément ?
Heu… Lennart ne trouvait pas ça « normal » à priori avant, vu que c'est comme ça que c'était depuis un bout de temps. Et donc maintenant, les cgroup ça doit appartenir à systemd et c'est tout point ; voilà un système coopératif… Alors après, ils ont étudié les solutions et c'est à priori la meilleure, mais alors qu'on ne se targue pas de se la jouer « à la UNIX » : non, tu fais différemment ; et bien assume-le.
Et bien maintenant tu as un mainteneur tête de nœuds pour la base d'une partie énorme de ton système. Pour caricaturer UNIX, les « haters » disaient que l'auteur de "head" n'était pas le même que celui de "tail" (et c'est vrai !) ; c'est un peu extrême, mais ça a toujours été comme ça que ça se passe. Les projets avec un mono-maniaque qui décide d'une partie énorme de ton système, ça craint. Torvalds est visé du coup, mais disons que lui fait plus « consensus », si on peut dire.
Heu… ça fait un peu « parain de la mafia » comme remarque…
Je parlais des communications par dbus. Choses que l'utilisateur ne voit pas, mais quand tu écris un soft et que tu veux communiquer avec le démon « système » maintenant, tu dois te palucher du XML.
Nan mais tu as pris la grosse tête comme Lennart ? Moi j'ai écrit des scripts SysV pour des softs, oui, et je me permet d'aller voir dans le code que je veux, quand il est pas trop mal fait.
[^] # Re: À mon tour
Posté par Anonyme . Évalué à 9.
On appelle ca des wrappers. Un petit programme qui permet d'integrer un outil deja existant à systemd.
C'est pas par ce qu'il y a un fichier cryptsetup.c ou fsck.c que systemd réimplement cryptsetup et fsck.
Faudrait un jour arreter de raconter n'importe quoi pour toujours tout mettre sur le dos de Lennart. Le changement dans les cgroups n'a rien à voir avec Lennart, c'est le mainteneur kernel des cgroups qui s'est rendu compte que la facon dont c'était fait c'était le bordel, et qu'il serait mieux qu'il n'y ait qu'un seul daemon qui se charge de la gestion des cgroups, et qui est allé voir Lennart pour lui proposer de faire une implementation dans systemd de la nouvelle interface.
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 5.
Ah, tu veux dire rester compatible avec les scripts SysV par exemple? Oh wait…
Bah pour une partie de l’espace utilisateur.
Bah ils ont trouvé que c’était mieux, donc ils ont changé.
Je ne vois pas ce qui est fondamentalement «pas Unix». D’ailleurs tout ne tourne pas autour d’Unix. Le but est de savoir si ça fonctionne bien, si c’est utile, si c’est flexible, si c’est efficace, pas de respecter les principes Unix sans réfléchir.
Non seulement en citant Linus tu viens de contrer ton premier argument (genre Linus n’a jamais déclenché de polémiques, et parmi les développeurs de distributions il semble plutôt faire consensus).
D’autre part, pour réagir à ton «ça a toujours été comme ça», je te conseille de lire ceci. «ça a toujours été comme ça» est un des pires arguments qui existent.
Est-ce que c’est un argument? systemd n’a pas forcé GNOME à utiliser exclusivement les API systemd. systemd n’a pas forcé les développeurs udev à les rejoindre.
Dbus c’est pas des commandes? Qu’est-ce que ça peut te faire que derrière dbus utilise du XML?
Pourquoi dis-tu que Lennart a la grosse tête? Par ailleurs je parlais de modifier le système d’init pas de créer un script SysV/une unité systemd; c’est plus facile de créer une unité systemd pour quelqu’un qui ne connait pas la programmation, qu’un script Bash…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par LeMagicien Garcimore . Évalué à 8.
Il parait que le mec a fait l’implémentation avec un flingue sur la tempe pendant que Lennart retenait sa femme et ses gosses en otage !
Ou alors il était juste convaincu que c’était une bonne idée, ou que c’était un mal nécessaire. Mais ça me parait déjà beaucoup moins plausible…
Des changements dans le kernel pour des choses spécifiques dans le userland, il y en a toujours eu et il y en aura toujours. Mais si c'est pour Systemd, c'est automatiquement honteux ?
[^] # Re: À mon tour
Posté par rogo . Évalué à 6.
C'est sûr qu'aujourd'hui aucun petit bénévole ne peut suivre le développement des composants au cœur du système. D'ailleurs, il n'y a plus aucun bénévole qui suive l'évolution du noyau Linux. Et quelques rares professionnels osent compiler eux-mêmes un noyau avec une config sur mesure, ou compiler systemd avec des composants désactivés. Il paraît même que C++11 a rendu le C++ trop compliqué pour les non-professionnels : les bénévoles devraient en rester à PHP3.
[^] # Re: À mon tour
Posté par Anonyme . Évalué à 10.
Il y a des bénévoles qui contribuent à systemd.
Et puis personnellement, tant que c'est libre et que ca fonctionne bien, je m'en moque que ca soit fait par des bénévoles ou pas.
Bon en fait non, je m'en moque pas complement. Si en plus de déveloper des trucs libres qui fonctionnent bien, ils peuvent etre payés pour ce qu'ils font, je trouve ca encore mieux.
[^] # Re: À mon tour
Posté par Misc (site web personnel) . Évalué à 6.
L'existant pour quoi ?
Les options de systemd-detect-virt réutilise pas l'existant de ou ?
Ou journalctl devrait reprendre quel options existantes ?
Pour les trucs ou ça a du sens, c'est exactement ce qui est fait. Exemple, /etc/fstab, /etc/hostname, /etc/cryptsetup. Quand il y a rien, ou quand il y a des implémentations divergentes, il faut faire un choix.
On parle de systemd, pas de SMF…
Tu sembles tout d'un coup te réveiller d'un sommeil de 10 à 15 ans. Tu connais beaucoup de gens qui bosse sur gcc sur leur temps libre ? Sur la glibc, le kernel ou Xorg ?
Tu t'es dit que des trucs comme xen ou kvm sont arrivés sans avoir des gens à temps plein dessus ?
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 5.
C’est normal que les textes que tu cites soient coupés à à peu près 80 caractères?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par claudex . Évalué à 7.
Il doit sûrement utiliser 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: À mon tour
Posté par Misc (site web personnel) . Évalué à 2.
Oui. Je pense que j'ai la sale habitude de retailler les citations pour que ça rentre dans la boite de dialogue pour éviter de casser l'alignement, et en effet, ça doit donner une coupure à 80 caractères.
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 4. Dernière modification le 14 juin 2014 à 11:46.
Il y a déjà eu une discussion de ce genre sur une dépêche qui condamnait ce genre de comportement, et en plus je ne vois pas pourquoi tu fais ça pour les citations et pas ta propre prose, du coup ça perd tout son «intérêt».
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par claudex . Évalué à 5.
Je le comprends, j'ai aussi tendance à vouloir le faire. Quand, dans la boîte d'édition, on voit un truc du genre :
On a tendance à vouloir ajouter des
>au début de chaque ligne.« 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: À mon tour
Posté par ariasuni . Évalué à 3.
Ça se soigne j’espère, parce que franchement se faire chier alors que c’est inutile, pire, que ça casse la mise en page, c’est quand même dommage. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par jben . Évalué à 4.
Sans vouloir le défendre, quand j'écris un commentaire sur linuxfr, je mets des retours à la ligne un peu n'importe où, avec l'habitude que les retours à la ligne (non dupliqués) ne sont pas significatifs en MarkDown. Ce n'est qu'après avoir écrit mon commentaire que je suis obligé de le relire pour les supprimer, et ça me les brise sérieusement. J'ai proposé un rapport de bug pour proposer de rendre ce comportement optionnel resté sans effet à ce jour.
Ceci n'est en aucun cas une critique, j'essaie juste d'avoir une explication rationnelle à certains retours à la ligne intempestifs que l'on constate.
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 1.
Moi ce que je trouve stupide, c’est de faire des sautes de ligne au milieu d’un paragraphe pour ça tienne sur x caractères. C’est le logiciel qui doit aligner le texte, pas l’humain.
On retrouve encore cet archaïsme dans le courriel et les commentaires de code source; pourtant ça serait vachement plus simple de ne pas s’en préoccuper. C’est assez ridicule le temps qu’on peut perdre à cause de ça (en tout cas c’est le ressenti que j’en ai).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par anaseto . Évalué à 1.
Un éditeur de texte configuré pour couper les lignes le fait automatiquement pour toi comme il faut, et les '>' s'insèrent automatiquement lorsque tu remets en forme le texte, donc c'est vraiment très rapide. Couper les lignes pour de vrai a l'avantage que ton texte ou ton code est plus facilement utilisable avec des outils comme grep, sed, aller directement à telle ligne corriger une erreur, etc… C'est pour ça que dans les langages de markup (LaTeX, markdown) souvent un nouveau paragraphe c'est une ligne blanche, et aussi le fait que c'est plus difficile de se tromper sans faire exprès (un retour à la ligne est vite arrivé, et pas forcément évident à l'œil).
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 1.
Et le jour où je veux passer de 80 à 100 caractères, il faut reformater tous ses documents?
Oui mais bon, pas forcément bien. Dans Thunderbird on est obligé de faire Ctrl+R faire que ça refasse le truc de façon propre. Le simple fait que je sois obligé de configurer un éditeur et/ou de connaitre un raccourci qui dépend des logiciels, c’est un peu broken by design.
Du coup pas vraiment utile pour de la prose, non?
C’est que ton éditeur de texte est mal configuré. :p D’ailleurs c’est un peu dommage qu’il n’y ai rien pour voir les sauts de ligne dans LibreOffice à part en saturant le texte de caractères ¶ partout.
Bref, si lorsqu’on fait de la programmation il n’est pas idiot de tenter de se limiter à un certain nombre de caractères par ligne pour améliorer la qualité du code, pour de la prose il n’y a aucun intérêt, c’est un vestige du passé.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par anaseto . Évalué à 1.
Ça dépend, si tu fais la plupart de ta prose en LaTeX par exemple, ou un autre langage de markup, ça reste utile de la considérer comme si c'était du code. Surtout si tu n'es pas sûr que tu n'iras pas l'améliorer, et à plus forte raison si plus d'une personne peut éventuellement contribuer (un diff sur des lignes qui font un kilomètre c'est pas terrible, c'est plus facile d'avoir des conflits). Ça vaut pour toute prose susceptible d'être modifiée au cours du temps.
Et un autre avantage à couper les lignes, c'est aussi que tu es à peu près sûr que tous les éditeurs te présenteront le texte de la même manière.
Pour un simple commentaire que tu écris puis ne modifies jamais tout ça n'a pas beaucoup d'importance, non, mais ni dans un sens ni dans l'autre.
Après, en considération annexe, pour ceux qui, comme moi, utiliseraient par économie le même éditeur pour tous leurs besoins d'édition, que ce soit du code, des mails, ou tout type de prose, c'est plus simple d'utiliser les mêmes conventions partout, surtout si ledit éditeur est pensé par défaut pour des textes organisés en lignes (descendre d'une ligne perd son sens avec des lignes « paragraphe »), ce qui sera sans doute le cas s'il sert aussi à écrire du code.
[^] # Re: À mon tour
Posté par ariasuni . Évalué à 3.
Bof, c’est pas comme du code où l’erreur peut se situer à peu près partout, là c’est juste sur quelques balises.
C’est vrai, mais c’est bien ce que je dis, l’humain qui fait le travail de la machine… Dans ce cas-là, autant faire une ligne par phrase, c’est plus logique.
Si c’est à longueur fixe, je ne peux pas profiter de la taille de mon écran, si je réduit la taille de la vue du fichier à moins que la longueur des lignes ça va faire de la merde (problème qu’on a sur mobile quand quelqu’un écrit un commentaire et saute des lignes arrivé aux 80 caractères…). Dans ce dernier cas, le rendu n’est pas identique. D’ailleurs quel intérêt à avoir un rendu identique, le but c’est que ça puisse être lu sans emmerder le lecteur, non?
Mon éditeur il fait les retours à la ligne automatique, mais si c’est à largeur fixe il sait les afficher aussi, (presque) n’importe quel éditeur sait le faire.
Je ne comprends juste pas pourquoi, à l’heure des interfaces réactives, des tailles d’écran et des fenêtres d’application à taille variable, des polices différentes, des personnes et des usages qui ne sont pas les mêmes, on doive se taper une limitation qui date des années 80.
Alors oui dans certains cas c’est pratique avec les outils que l’on a à l’heure actuelle. Mais je pense qu’on peut faire mieux.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par claudex . Évalué à 3.
Tout éditeur qui se respecte fait ça tout seul.
« 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: À mon tour
Posté par ariasuni . Évalué à 2.
Ouais, mais quand je supprime un mot bah je dois ré-indenter le bouzin. Alors bien sûr il y a des commandes qui le font automatiquement, mais je déteste cette manie de faire faire des trucs par l’ordinateur quand c’est pas nécessaire, ça rajoute de la complexité…
En plus, je viens de me rendre compte que si je supprime un mot et que je ré-indente tout, le diff risque de faire tout le paragraphe.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: À mon tour
Posté par claudex . Évalué à 4.
Je trouve quand même plus simple quand le compilateur LaTeX donne une erreur sur la ligne 42 d'avoir seulement 80 caractères pour la trouver plutôt que 2000.
« 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: À mon tour
Posté par jben . Évalué à 2. Dernière modification le 15 juin 2014 à 00:02.
Avec une phrase par ligne c'est assez rare d'avoir 2000 caractères, sauf quand j'écris aux impôts.
Après c'est aussi trompeur le numéro de ligne, des fois il fait référence à la dernière ligne du paragraphe…
Édit: j'ai cru que tu avais répondu à l'commentaires que je viens de poster dans ce thread.
[^] # Re: À mon tour
Posté par jben . Évalué à 3.
Le fait que le retour à la ligne (simple) ne soit pas significatif permet aussi des trucs sympa. J'essai par exemple lorque je rédige un document MarkDown ou LaTeX qui est versionné, d'utiliser la logique une phrase, une ligne. Les lignes peuvent être longues ce n'est pas le problème, je ne respecte pas de limite de nombre de caractères pas ligne. En tout cas, ça permet au gestionnaire de version d'être plus efficace, et d'avoir moins de conflits.
Mais pour cela, il faut que le retour à la ligne (simple, toujours) ne soit pas significatif.
# Calcul
Posté par MTux . Évalué à 5.
Cela fait quand même pas loin de 40% de gens de RedHat dans l'équipe :)
[^] # Re: Calcul
Posté par ariasuni . Évalué à 0.
Ça a sûrement dû évoluer depuis. Mais je ne sais absolument pas comment récupérer l’information (je pourrais demander à Lennart lui-même).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Calcul
Posté par Misc (site web personnel) . Évalué à 2.
Pour la liste des gens qui peuvent commiter, suffit de trouver une personne avec un accès à fdo et de dire "qui est dans le groupe qui peux commiter".
Pour savoir qui bosse chez RH, suffit de trouver un mec qui bosse chez RH et de demander.
En effet, demander à Lennart remplit les 2 conditions.
[^] # Re: Calcul
Posté par Maclag . Évalué à 8.
La bonne question ce serait s'ils refusent ou non des développeurs qui ne viendraient pas de chez RH dans l'équipe.
Sinon, je ne suis pas sûr de bien comprendre: on va reprocher à RH d'avoir trop de dévs, ou de trop contribuer au Libre?
[^] # Re: Calcul
Posté par Zenitram (site web personnel) . Évalué à 6.
RH, ce sont des salauds, ils embauchent les gens compétants! Et en plus ils font du libre, alors la ça devrait être la guilotine.
[^] # Re: Calcul
Posté par Atem18 (site web personnel) . Évalué à 1.
T'as confondu avec Canonical. :-P
[^] # Re: Calcul
Posté par Misc (site web personnel) . Évalué à 4.
Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.
Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.
Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.
Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.
Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.
[^] # Re: Calcul
Posté par Misc (site web personnel) . Évalué à 10.
Alors, j'ai demandé à un pote avec un compte chez FDO :
$ getent group systemd
systemd:x:882:david,walters,kay,harald,tfheen,lennart,mbiebl,holtmann,martin,colin,bor,michich,zbyszek,dreisner,straussd,tomegun,phomes,auke,dvdhrm,zonque,bphilips,msekleta,lnykryn,pflykt
Grosso modo, on a de chez RH:
- kay
- lennart
- msekleta
- lnykryn
- haralt
- tomegun
- walters
- michich
De chez intel, on a :
- pflykt
- auke
- holtmann
En indépendant, on a:
bphilips (brandon Philips) bosse chez CoreOS.
straussd (David Stauss), chez Pantheon system
dvdhrm (David Herman), est étudiant d'aprés sa page web
colin, (Colin Guthrie), chez une boite qu'il a fondé ( et pour le projet mageia )
dreisner (Dave Reisner), packager Arch, qui bosse chez Google d'aprés son compte github
tfheen (Tolef Fog Heen), Debian et qui bosse chez Fastly
mbiebl (Michael Biebl), Debian, étudiant
zbyszek, (Zbigniew Jędrzejewski-Szmek), bosse dans un labo de neuro science aux US
martin, (Martin Pitt), Canonical
Et ceux que je sais pas:
zonque ( Daniel Mack )
phomes ( Thomas Andersen )
bor ( Andrey Borzenkov ) ( potentiellement chez Suse, mais j'arrive pas à vérifier )
Et le reste, ou je suppose uniquement:
david, sans doute david stauss ( mais pourquoi 2 comptes )
On a donc 24 commiteurs, dont 8 gens chez Red Hat, 3 chez Intel.
Ça fait 33% de commiteurs chez RH, et donc 66% venant d'autres boites diverses et variées. On noteras qu'il y a des devs de divers distros (Arch, Debian, Ubuntu, Mageia, potentiellement Suse). Y a même des concurents (genre coreos, qui est relativement en concurence avec projectatomic de RH).
Et ça compte que les commiteurs, pas les gens qui filent des patchs sur la ml.
[^] # Re: Calcul
Posté par modr123 . Évalué à -1.
ca ne veut strictement rien dire tant qu'on sait pas qui fait le plus de modification car si les 8 font 99% des modifications
[^] # Re: Calcul
Posté par Maclag . Évalué à 10.
De ce que j'ai compris, l'équipe RH se divise en 2 groupes:
-ceux qui font un rollback sur toutes les contributions non RH
-ceux qui sabotent le code pour assurer la domination mondiale de RH
Et c'est pour ça que les autres contributeurs continuent: ils ont déjà accepté de se soumettre à la nouvelle autorité mondiale RH.
[^] # Re: Calcul
Posté par Misc (site web personnel) . Évalué à 7.
C'est simplificateur. Tu as aussi l'équipe qui va sur Phoronix pour répandre la propagande dans les commentaires, l'équipe qui étudie comment casser la compatibilité sacré avec Unix et le passé, l'équipe qui prends en otage les gens des projets communautaires pour faire ce que RH veux.
Je te trouves pas super respectueux envers tout ces groupes qui travaillent à rendre le libre sur le point d'exploser, sans doute un vaste plan de l'armée américaine (
http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ & http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ )
[^] # Re: Calcul
Posté par ariasuni . Évalué à 5. Dernière modification le 14 juin 2014 à 20:10.
J’avoue tout, je fais partie de la police de la pensée de Red Hat.
La guerre contre les autres systèmes d’init c’est la paix
La liberté de critiquer systemd c’est l’esclavage
L’ignorance d’Unix c’est la force
Écrit en Bépo selon l’orthographe de 1990
# Le vendredi c'est permis.
Posté par Kaane . Évalué à 10.
Sommaire
Après tout ce démontage d'idées reçues, il est temps de remonter un peu
systemd est monolithique
Systemd est constitué de pleins, pleins pleins de binaires. Donc il n'est pas monolithique. Le fait que tous ces binaires sont fortement interdépendant n'a aucun rapport avec la choucroute. En plus dans sytemd chaque binaire effectue une tache bien définie, comme par exemple vérifier la config réseau, lancer le DHCP, simuler les connexions en attendant l'initialisation resynchroniser tout ça et balancer les résultats via DBus pour qu'il soit loggués. C'est une tache simple, fine et précise. Pourquoi ? Parceque nous avons le soucis de la sécurité, grâce à l'utilisation de bon nombre de technologies flaguées "experimental" dans le noyau nous arrivons à limiter grandement les droits dont un processus a besoin pour effectuer sa tache. Ainsi il suffit d'être ROOT pour arreter ou relancer un service, il suffit également d'être ROOT et dans la hiérarchie de plus haut niveau dans les CGroups pour pouvoir auditer un autre processus. De même en étant simplement ROOT on peut envoyer des signaux à un autre processus ou encore créer une nouvelle unit.
systemd a été conçu pour la vitesse
Pas du tout, systemd a été conçu principalement pour être propre. Comme il a été conçu et pensé intelligemment, il est en plus rapide - mais c'est juste un effet de bord de notre travail de réflexion. Ce quic ompte c'est que systemd soit super bien conçu, tellement bien conçu même que le des systèmes simples comme les logs ou le monitoring d'initialisation de périphériques n'ont entrainnés qu'une petite dizaines de bugs critiques au démarrage chacun.
La vitesse de systemd ne sert à rien pour les serveurs !
Pas du tout, déjà même sur les gros serveurs dont la partie matérielle du boot matériel peut durer plusieurs minutes, 10secondes de plus ou de moins ca peut changer la vie. Mais sur les VMs qui vont booter en quelques secondes quoi qu'il arrive et avec lesquelles ont peut faire des snapshot à chaud pour les mise à jour de toutes les façons, cette différence de trois secondes est encore plus cruciale. Sur un système qui contient plusieurs centaines de VM et qu'il faut redémarrer en urgence, ces trois secondes gagnées par VM au boot peuvent faire un total de 6 voire 8 secondes. Et puis le SAN est tellement content de voire 250 VM venir lui faire coucou dans un intervalle maximal de 2 secondes.
systemd est incompatible avec les scripts shell
Totalement faux, on peut parfaitement utiliser des scripts shell avec systemd. Du moment que ces scripts sont lancés avec les droits root, ne modifient pas l'environnement, restent cantonnés dans leur CGroup, ne cherchent ni à arréter ni à relancer le processus, et bien entendu ne cherchent pas à remonter une autre info que start, stop, reload aux units - tout ce passe très bien. (Enfin pour le premier script shell, si vous avez besoin que plusieurs scripts shells interragissent avec la même unit ca peut nécessiter l'écriture d'une autre unit, ou d'un wrapper ou les deux.)
systemd est compliqué
Alors là c'est n'importe quoi, en quoi un système qui s'appuie sur les capabilities, les cgroups, DBus, un nouveau système de log, un nouveau système de controle, un petit 500 variables kernel (dont 200+ spécifiques à Linux) le tout derrière une boite noire affreuseument simpliste, serait-il plus compliqué de lancer httpd avec l'utilisateur apache depuis un script shell ?
En plus au cas exceptionnel au systemd viendrait à vous causer des soucis, journald loggue l'ensemble des évènement de façon si claire et si concise que le kernel Linux arive presque à digérer le flux à tous les boot.
systemd n’est pas modulaire
Oui c'est le même sujet que plus haut dans la section "systemd est monolithique" mais j'écris tout d'une traite et ça me fait chier de me relire et de corriger quand je tape du texte aussi.
Donc systemd est modulaire, on peut désactiver pleins de trucs à la compilation ou à l'éxecution. Si vous le fait ca cassera surement le système, mais inutile de nous envoyer un mail pour vous plaindre - au mieux on vous répondra poliment qu'on s'en cogne. Dans systemd vous pouvez désactiver à la compilation les cgroups (mais ca casse le système) les capabilities (mais ca casse le système) passer sur une version plus ancienne de dbus (mais ca casse le système) ou encore activer le mode de compatibilité pour utiliser une libsystemd pas tout à fait synchrone avec la version de l'executable (mais…)
Bref si vous aimez linux 1.xx vous allez adorer systemd.
systemd est seulement pour les ordinateurs de bureau
Pas du tout, quand on a créer systemd on a penser à toute la gamme de produit basés sur Linux. Nous avons déjà vu ce que la vitesse de systemd apportait au serveur. Mais ce n'est rien à coté de ce que DBus+Journald logé en RAM au démarrage+les capabilites+la nécessiter de passer par systemd pour gérer les CGroups peuvent apporter au monde de l'embarqué.
systemd est un résultat du syndrome NIH
Le problème que nous avions avec notre précédent système d'init, Upstart (outre le fait qu'il ne marchait pas non plus) n'est non pas qu'il n'avait pas été inventé par Red Hat, mais qu'il avait été inventé par Canonical. Honnêtement un init inventé par Debian ou même Suse ca ne nous aura pas posé autant de problèmes. Mais là quand même….
systemd est un projet freedesktop.org
Et voilà, sous pretexte que vous êtes hébergés par freedesktop, que votre système se met à gérer toutes les notions d'ACPI, le login et de getty et que son auteur est principalement pour avoir fait deux démons purement orienté utilisateur final non professionnel - vous êtes catalogué tout de suite. Pas du tout si on a fini sur le site freedesktop.org, c'est juste parceque justine, la scrétaire du troisième connait vachement bien le gars qui change les tubes néons dans la salle serveur 4 de chez FreeDesktop. Tout de suite à se faire des idées les gens.
systemd n’est pas UNIX
D'un certains coté c'est vrai que l'on s'est un peu éloigné de la philosophie UNIX. Mais le fondamental de la philosophie UNIX est "avoir un sous système qui fait une seule chose et qui le fait bien", nous un a un macro système qui fait pleins de chose, mais que délègue à plusieurs modules qui eux font … plusieurs choses aussi, d'accord, mais on est quand même proche de la philosophie UNIX. Quand même. En tout cas on s'en inspire. Par contre pour ce qui est de faire bien, je vous déjà dit à quel point on était bien conçu et rapide ?
systemd est complexe
Bonjour, veuillez regarder le bout de ce stylo s'il vous plait
FLASH
Bien sur que systemd est complexe, les ordinateurs aujourd'hui sont complexes - et comme on veut gérer l'ensemble du système de façon monolithique il est normale que ce soit compliqué et difficile à débugguer. Pour éviter les redondance on centralise les trucs avec des effets de bords WTF à la clef. Mais c'est normal !
Hop rebelotte stylo
FLASH
systemd est une usine à gaz
Mais pas du tout, avant pour lancer un service il suffisait d'avoir les droits sur l’exécutable et/ou le script concerné. Du coup n'importe qui pouvait lancer assez facilement des services sous réserve de ressources et de droits. Et bien c'est ca la vrai usine à gaz.
Nous on a un système centralisé ou pour lancer une copie d'un service qui tourne déjà avec d'autres paramètres il faut copier un template, le linker symboliquement, l'enregistrer, et finalement l'initialiser (éventuellement avec des scripts pre et post traitement) via des commandes DBus et/ou systemctl.
Pas la peine de nous remercier on aime rendre service.
systemd seulement pour Linux, pas sympa pour les BSD
systemd est un OS très différent de BSD. BSD utilise encore l'ancien système ou l'init du système sert principalement à initialiser le système puis à foutre la paix à l'admin. De part leur vision archaique ils ne peuvent pas être interressés par mon init, même si celui ci était portable, je suis sur qu'ils continueraient à me regarder avec des yeux et à me parler lentement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
Dans le monde, ce sont toujours les gens intelligents qui cèdent. Je me fait pas de soucis, ils utiliseront systemd…
(N.B : C'est fait)
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
On est tellement flexible, modulaire et léger que les autres systèmes seraient probablement incapables de copier les fonctionnalités simple et ciblées de systemd. Même partiellement. Honnêtement on ne peut pas porter systemd ailleurs.
systemd n’a pas de raison de ne pas être portable
On utilise partout et de façon centralisée pleins de fonctionnalités spécifiques Linux (mais en restant modulaire attention). Donc on est pas portable, centralisé, focalisé sur Linux exclusivement (mais modulairement … Et en s'inspirant de la philosophie UNIX aussi)
systemd utilise des fichiers de configuration binaire
N'importe quoi, systemd utilise des fichiers de configuration texte qui … Ah vous parliez de la configuration du comportement de systemd lui même, pas des units. Ben c'est encore plus n'importe quoi alors parce que le comportement systemd il est carrément codé en dur. Et toc !
systemd est un cauchemar de fonctionnalités
Vous pouvez penser ça aujourd'hui, mais dans 5 ans vous vous retourner et vous verrez qu'en fait il n'y avait pas tant de fonctionnalités que ça dans systemd à l'époque. En plus comme dit plus haut, vous pouvez désactiver pleins de fonctionnalités (mais ca casse votre système)
systemd vous force à faire quelque chose
Pas du tout, on est pas la mafia. Vous êtes libre de laisser votre ordinateur éteint ou de créer votre propre distrib. En plus il y a des promos sur les licences XP en ce moment. Vous êtes libres.
systemd rend impossible l’utilisation de syslog
Encore faux, systemd peut parfaitement renvoyer le contenu de journald sur syslog si vous tenez tant que ça à doubler les I/Os. J'ai dit doubler ? Mettez tripler en fait on a pas mal modifier la verbosité des logs avec notre nouveau systeme et c'est plutôt chiant à régler…
systemd est incompatible
Comme avec les scripts, du moment que vous avez les droits ROOT, que les fichiers sont là ou on vous à dit de les mettre et que vous respectez scrupuleusement les guidelines vous devriez être capables de lancer la plupart des services qui ne sont ni des sondes ni des outils de chiffrement.
Mais bon avec systemd on peut utiliser les unit d'une distribution sur une autre distribution. Je ne vois pas trop à quoi ca peut servir dans le monde professionnel ou la plupart des admins sérieux font des scripts d'init custom. Mais bon c'était très difficile à faire avant, donc on est assez fier.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
DBus est presque intégralement accessible par script depuis la plupart des clients (enfin des clients locaux) du moment que vous avez une fois de plus les droits ROOT. Donc argument invalide. Hop là, question suivante.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n'est pas vrai du tout. Vous pouvez éditer les fichiers de configs avec les outils que vous voulez. C'est pour qu'ils soient pris en compte que vous devez utilisez d'obscurs outils de configuration.
systemd est instable et bogué
Totalement faux, la liste bugtracker Fedora nous indique que nous avons assez peu de problèmes avec systemd. Si l'on exclu un certain Linus T qui commence sérieusement à nous casser les pieds avec ces menaces à peine voilées on est plutôt bien.
systemd n’est pas déboguable
En fait on a tellement peu de soucis que la page pour aider à débuguer systemd fait à peine quelques lignes et qu'elle a été mise à jour la semaine dernière (enfin la semaine d'avant ce texte, parceque depuis rien, que dalle, nada. Et ceci même alors que les saturations journald et les conflits udev ont fait crasher pas mal de machines au démarrage.)
systemd fait des changements pour le plaisir de changer
Très très mensonger. On évite les changement incompatibles autant que possible, mais malheureusement parfois l'ancienne solution n'est vraiment pas assez hype pour nos développeurs. En ce qui concerne l'ajout d'un serveur DHCP dans l'init, c'était obligatoires. Parceque des raisons.
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
Oh mon dieu, une attaque à mon orgueuil, vite une réponse de trois pages…
Les grecs anciens n'avaient pas le concept du zéro ….
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Non, nous on supporte très bien un /usr séparé. C'est Linux qui ne sait pas faire. D'ailleurs toutes les personnes qui fonctionnent avec /usr séparé, par exemple les techniques de doubles montages utilisé en pxeboot ou en /usr commun sur SAN ne marchent pas.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf en double montage - mais que personne n'arrive à faire marcher. Je vous jure, si, si)
systemd ne permet pas de remplacer ses composants
Comme déjà vu plusieurs fois, vous pouvez remplacer à peu près n'importe quel composant de systemd, du moment que vous avez les droits ROOT, que vous remplacez avec des composants systemd plus récents et que vous n'avez pas peur de casser votre systeme.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ahahaha. DBus utilise les sockets. Du moment que vous avez les droits root, une version custom de DBus avec tracages des paquets et la logique de désérialisation - ca n'est pas plus dur à suivre qu'un socket non DBus.
Promis j'ai commencé un vendredi, donc c'est autorisé.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . Évalué à 10.
comme ?
tu bullshites un peu ( comme d'hab ). Y a dbus-monitor, fourni de base, pas besoin de version custom.
Oui, ça marche, si tu fait monter le /usr par l'initrd. D'ailleurs, c'est la raison de l'unification de /bin et /usr/bin, refaire un /usr commun pour plusieurs containeurs.
Visiblement, tu as oublié de te relire ici, tu as oublié un 's' en trop dans ta précipitation et tu as oublié le lien vers le post qui donnent une raison. Heureusement, il y a des gens qui suivent pour te corriger:
https://plus.google.com/+TomGundersen/posts/ht4nn9jHbAR
Si je peux me permettre (c'est une formule de politesse), tu fait encore preuve d'imprécision (on t'en veux pas, on peut pas passer sa soirée sur un commentaire et savoir de quoi on parle), la page de man (c'est la documentation sous Unix, si tu connais pas) semble indiquer que si tu ne fait pas un repertoire /var:log/journal, alors rien n'est écrit sur le disque par journald. Donc je ne suis pas sur que les I/Os soient doublé, sauf si tu configures mal ton systéme aprés ne pas avoir lu la page de man.
Reference :
http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html
"By default, the journal stores log data in /run/log/journal/.". Comme /run est un tmpfs, ça fait pas d'I/O sur le disque (sauf si tu configures /run pour ne pas être un tmpfs, cad sauf si tu fait exprés de rendre les choses moins performantes).
Tu peux aussi filer à syslog et envoyer ça vers splunk/logstash ou autre. Enfin, ça, c'est pour les admins avec du pognon et ou des infras plus conséquentes.
Visiblement, en 4 ans, personne n'a tenté, et encore moins réussi. Donc soit c'est pas faisable et Lennart a raison, soit ça intéresse personne, et Lennart a raison de pas perdre de temps dessus. Dans les 2 cas, il a raison.
Non, tu fait le fichier et un include.
Faire un lien, comme sur gentoo et openrc ? C'est vrai, je me souviens des cris des gens quand on a dit "oui, faut faire un lien d'un script d'init pour en lancer plusieurs exemplaires, puis il faut connaitre le nom du nouveau script, puis taper 1 commande par script à lancer, comme c'était long. les gens ont râlés de partout à dire que Gentoo ne marcherais jamais avec un système si fastidieux. Je me souviens des gens envoyant des menaces à Daniel Robbins, etc.
Mais bon, je doit reconnaitre que ta mauvaise foi est distrayante, et ça change des fois ou tu as affirmé (je cite) que RHEL sortirais mi-2013 (supposition de ton chapeau), en envisageant sérieusement de ne pas mettre systemd. Comme tu as la mémoire courte (vu le nombre conséquent d'oubli à chaque fois), je te remets le lien:
https://linuxfr.org/nodes/96086/comments/1401229
En fait, ils envisagent tellement de revenir en arrière qu'il reste que 3 scripts d'init dans la version finale de RHEL 7.
[^] # Re: Le vendredi c'est permis.
Posté par Prosper . Évalué à 3.
250 Vms qui bootent en même temps , ton problème c'est clairement pas systemd , mais une très mauvaise gestion ( incompétence ? ) de ton hyperviseur…
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 2.
250 Vms qui bootent en même temps , ton problème c'est clairement pas systemd , mais une très mauvaise gestion ( incompétence ? ) de ton hyperviseur…
Ah mais je suis entièrement d'accord. Mais ça n'est pas de moi que vient cet argument.
[^] # Re: Le vendredi c'est permis.
Posté par Prosper . Évalué à 4.
Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 2.
Ou alors j'ai mal compris , ou alors tu extrapoles largement, mais c'est pas du tout ce qui est dit.
Déjà de base le texte est de mauvaise foie (je pense que c'est assez évident). Il s'en trouvera toujours pour penser que j'ai 14 ans et que je parle de systemd pour passer ma période pré-ado (bonjour Misc _o/ ), mais dans le fond, même si je n'utiliserais pas systemd avant qu'il y ait eu de gros changements (c'est à dire probablement jamais, parti comme c'est) je n'ai pas de ressentiment particulier vis à vis du logiciel.
Pour être clair je considère que systemd est comme internet explorer 5.0, ca rend service à pleins de gens, en surface c'est facile à mettre en oeuvre et à utiliser et ça juste marche pour 90% à 95% des cas. Maintenant c'est aussi un nid à bugs et à trous de sécu, et les 5% de cas ou systemd ne marchera jamais font qu'il est bon à mettre à la poubelle d'après moi. En tout cas pour l'utilisation que j'ai de l'outil informatique au niveau professionnel, non seulement il ne me sert à rien, mais en plus il est fondamentalement incompatible avec mon métier. (Par exemple il est hors de questions que mes sondes actives ou que mes watchdogs choppent les droits root. Donc soit je ne monitore pas, soit je n'utilise pas systemd - le choix est très vite fait.)
Revenons en à la question qui nous interresse
On a cette phrase là (je prend la traduction pour aller vite)
En substance ce qui est expliqué ici (très lentement, parce que les admins à qui ont confie des datacenters contenant plusieurs milliers de conteneurs sont rarement très malins) c'est le principe de la loi d'Erlang du temps d'attente - à savoir que de façon générale (à adapter en fonction des situations bien sur) un système servant plusieurs clients n'a pas besoin de disposer d'assez de ressources pour servir tous les clients en simultané. Typiquement si vous avez 50 employés et que vous n'êtes pas un call-center, dix canaux téléphoniques c'est suffisant.
Pour les VMs c'est pareil, pour peu que l'on arrive à mettre à disposition une VM assez rapidement, pas besoin de faire tourner toutes les VMs (ou conteneur) tout le temps, il suffit de lancer la VM au moment ou elle est demandé. Donc moins de charge CPU, moins de courant électrique, un datacenter plus dense etc.
Sauf que ça ne marche pas tout à fait comme ça.
Il existe (grosso-modo) trois grand types de VMs/Conteneurs dans le cloud.
- Les VMs pour faire du calcul
- Les VMs pour faire du traitement de données
- Les VMs pour faire du stockage de données
Plus un type hybride des trois : les serveurs dédiés virtuels.
Les VMs pour faire du calcul démarrent généralement en un temps record. Il s'agit le plus souvent d'OS ultra-dépouillés dont le seul rôle est de répondre le plus vite possible à un serveur maitre, donc avec un temps de boot minuscule. C'est généralement mis en place sur des très très grosses machines avec des quantités de ram délirante (le petit octo-déca coeur avec 2TO de mémoire vive est assez populaire). Elles vont être louées par paquets de 200/300 tranches pour plusieurs jours, voire semaines. Généralement la personne qui gère ce type de machine est prévenu plusieurs semaines à l'avance. (Que ce soit l'industrie du cinéma ou celui de la recherche, entre le moment ou le contrat est signé et celui ou l'argent est arrivé et ou les comptes sont ouverts il s'écoule un moment.) De toute les façon que ce soit coté client ou coté exploitant tout le monde se fout royalement de la demi-seconde gagné par une VM à booter sur systemd.
Les VMs pour faire du traitement de données sont principalement orienté de façon à minimiser les I/Os. Généralement ce sont des machines avec une grosse quantité de mémoire (pour pouvoir stoquer les index) et des I/Os disque ultra optimisés. Le but étant bien sur de pouvoir processer un flux d'information assez conséquent à toute allure. Sur ce genre de VM, le temps de boot est très négligeable comparé au temps de rapatriement des données/mise en place du flux et au temps de calcul des index. Donc toujours pas d’intérêt majeur à utiliser systemd (et totu ca sans même parler du temps nécessaire pour faire le sharding des données ou le fencing des machines si l'application le nécessite)
Les VMs pour faire du stockage de données sont généralement en fait des partitions de serveurs de fichier. C'est à dire qu'un service central (Mongo, Hadoop, Riak etc. ) sert plusieurs dizaines voire centaines de client finaux. La question de le démarrer à la demande ne se pose pas vraiment. Et une fois de plus il s'agit de serveurs très simple avec des OS très spécifiques qui vont avoir tendance à avoir des temps de boot très rapide. Ce temps de boot sera systématiquement très inférieur au temps mis par les services pour faire le mapping des données et les rendre accessibles.
Reste les serveurs dédiés virtuels, c'est à dire les produits type EC2, VPS OVH par VMWare, machines Gandi et autre google Cloud. Là éventuellement les principes de l'Erlang peuvent s'appliquer. On est sur une grande diversité de clients, avec des demandes ponctuelles et irrégulières dans le temps. Systemd possède donc un avantage ici, même si il est minime (attribution des ressources + mise en place monitoring/facturation + montages des données + initialisation de la VM et des instances fallback éventuelles >> temps gagné avec systemd). Mais le temps gagné par systemd sera très difficile à exploiter en vrai, tout d'abord parceque le temps de mise en attente toléré est très inférieur au temps de boot, même avec systemd (un serveur qui met plusieurs secondes à répondre sous pretexte qu'il n'y a pas eu de demandes depuis une heure, ca la fout mal) et ensuite parce que le temps d'usage est lui très très supérieur au temps de boot.
Généralement on va avoir un temps de mise en attente toléré de l'ordre de quelques millisecondes (entre 10 et 100), un temps de boot de plusieurs secondes (entre une et 10) et un temps d'utilisation de plusieurs heures (de 12h typiquement pour un service pro principalement utilisé pendant les heures de bureau)
Chercher à grapiller quelque chose là dedans ca va être l'horreur.
Deuxième soucis, le système va gagner quelques secondes au boot - à condition que les ressources soit prêtes. Ca c'est bien entendu le boulot de l'hyperviseur d'avoir des ressources disponibles au cas ou une demande arriverait, mais si les ressources sont disponibles on est déjà en consommation électrique "iddle" sur ces ressources.
Par exemple si mon hyperviseur est configuré pour avoir 15% de ressources préallouées par rapport au volume consommé, il aura exactement la même densité et la même consommation que ce soit en mode systemd ou init classique. Et comme je n'ai pas le temps de faire toute l'allocation à la demande (pour des raisons de temps de réponse du hardware - ouvrir une LUN sur un SAN par exemple ca ne sera jamais instantané, idem pour le temps de création d'un sous réseau virtuel avec les VLANs qui vont bien) - et bien au final ma consommation électrique et ma densité salle blanche ne bougeront pas d'un iota.
Donc dans tous les cas possibles parmis les plus fréquents, du minicloud entre potes au EC2 Amazon systemd n'apporte rien au niveau densité, consommation électrique ou vitesse de mise à disposition. Les facteurs limitants se trouvent systématiquement hors de portée des problèmes qu'un init peut résoudre.
Après l'exemple débile que j'ai donné n'a pas d'autres but que celui d'être humoristique. On se place dans un univers ou presque tout fonctionne comme Lennart Poettering le décrit (c'est à dire que tout ce que "controle" systemd, du temps de boot, au réseau, à la nécessité d'aller le plus vite possible au point que trois secondes sont salvatrices) et on regarde ce qu'il se passe juste après, et paf le SAN.
Bien sur que dans la vraie vie ca va bloquer à pleins d'endroits - le systèmes ne débloquera pas les 250 comptes simultanément, les 250 sous réseaux virtuels ne seront pas créés dans la même milliseconde, l'hyperviseur ne traitera pas toutes les demandes assez vite (si tant est qu'il en ait l'intention au début) etc.
[^] # Re: Le vendredi c'est permis.
Posté par barmic . Évalué à 7.
Tu as des CVE à montrer ?
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ?
Ou alors je ne comprends pas.
Ce n'est pas tout à fait ça à mon avis. Quand tu fais un cloud élastique, si le coût de création de tes VM est un point important. Pour un cas extrême si le temps que tu crée ta nouvelle instance le pic de charge est passé, ce n'est plus la peine de chercher à faire de l'élasticité. Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 0.
Tu as des CVE à montrer ?
Il y en a un paquet qui tombent régulièrement. La nécessité d'être root pour la majorité des opérations + la centralisation des méthodes de sécurité + la compelxité polkit/consolekit + … font qu'il risque de falloir un bon moment avant qu'il n'y ait pas deux ou 3 CVE par jour. (Rien que sur le bugzilla RH il y a eu plus de 5000 CVE systemd/udev don certains CANT et WONTFIX qui ne me donnent pas confiance.)
Rien que pour les bugs confirmés ou plus :
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&component=systemd&component=udev&component=udev-browse&component=udev-extras&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ?
Ou alors je ne comprends pas.
Non le problème c'est qu'un service qui est lancé avec autre chose que le cgroup le plus haut hierarchiquement et des droits root ne peut pas auditer/interragir/démarrer/redémarrer un autre processus. Ca n'est juste pas acceptable. J'ai besoin que Nagios (par exemple) puisse démarrer tout seul comme un grand nombre d'autres services, lesquels services doivent pouvoir interagir avec les services critiques, le tout surtout sans être root. C'est la base de l'admin système : on a des sondes qui tournent en permanence , mais pas beaucoup parceque les ressources sont pas gratuite. Et quand on a un soucis on doit pouvoir lancer d'autres services ou sondes qui vont essayer de diagnostiquer le problème - soitpour le corriger automatiquement (rare) soit au moins pour que l'admin n'ait pas à lancer 200 commandes à la queue leu leu pour se faire un idée de la situation.
Il faut aussi en cas de pépins pouvoir remonter des infos aux utilisateurs/à la production/aux admins services pour qu'il puissent réagir etc.
Tout n'est pas forcément accessible depuis les logs, et je vais pas refiler les droits root aux services qui créé le tableau de bord du client…
Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Mais il n'y a pas de goulot d'étranglement à ce niveau là. Je ne peux pas faire un diagnostique de mon data-center toute les minutes ce serait ultra consommateur de ressources pour rien - et d'un autre coté dans le cadre d'un cloud elastique je ne peux pas non plus demander au client de patienter une minute à chaque fois qu'il fait une modif ou qu'il passe d'un status iddle à un status plein régime. Donc l'ensemble du problème de consommation électrique ou de densité des data-center repose sur l'anticipation des admins et les optimisations du data-center. Le temps de boot d'une machine - dans la mesure ou il reste très inférieur au temps de mise à jour du status du data center ne rentre pas en compte.
Si je mets 8 minutes à mettre à jour le "load" de mon data center (ce qui sera déjà une performance - ou alors un gaspillage de performance suivant comment c'est fait), je ne vais pas attendre tout ce temps pour me dire "tiens ? On est plein il faudrait peut-être lancer un nouvel hyperviseur/monter des réseau virtuels des fois que la charge augmente". Comparé à ces huit minutes d'anticipation obligatoires (et encore une fois poler un datacenter complet en 8 minutes ca demande un certain doigté) les 4 secondes que va me faire gagner systemd au boot je m'en cogne. Le temps de boot de l'init c'est le 6 ème chiffre après la virgule d'une opération sur trois chiffres significatifs.
[^] # Re: Le vendredi c'est permis.
Posté par ariasuni . Évalué à 3.
Je comprends pas… Le nombre de rapports de bug n’est absolument pas un bon indicateur pour déterminer le nombre de bugs dans l’application. Et puis c’est bien qu’il y ait de l’activité sur le système de suivi de bugs, non?
Ah d’accord, effectivement c’est chiant. Est-ce qu’avec le changement tout récent de l’architecture des cgroups ça a changé? Si non, est-ce qu’il y a un rapport de bug?
P.-S.: et sinon la syntaxe pour les citations elle pue des pieds?
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . Évalué à 10.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
[^] # Re: Le vendredi c'est permis.
Posté par Prosper . Évalué à 6. Dernière modification le 17 juin 2014 à 14:23.
Moi j'ai plutôt l'impression qu'il invente des soucis spécifiquement hors des clous pour conclure que systemd c'est du caca. Enfin bon, c'est mon point de vue…
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . Évalué à 4.
Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 7.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Quelques temps - ca fait moins d'un an. Je crois que l'annonce de Lennart date du 21 juin 2013. On savait déjà que les cgroups allaient être unifiés (et c'est une bonne chose) mais le coup du controleur unique accessible uniquement via DBus ca fait bizarre.
Ca fait bizarre pour deux raisons :
- la première c'est qu'un processus acquiert son cgroup au lancement, et là soit il se retrouve dans le même cgroup que son père, soit on veut le mettre dans un autre cgroup. Mais si on veut le mettre dans un autre cgroup il faut être capable de dire à systemd d'une façon ou d'une autre "attention le prochain processus que je vais lancer doit aller dans le cgroup /bidule/truc" parce que une fois que le processus est lancé c'est rapé (du moins jusqu'à ce qu'on puisse balader un processus d'un cgroup à un autre.)
A partir de là il faut bien s'assurer que la session depuis laquelle on est ne va pas lancer un autre processus avant celui que l'on veut mettre en cgroup. C'est extrèmement facile à faire pour un service qui s'initialise, mais pour une session utilisateur ou encore pour une commande lancée par uns ervice après initialisation c'est tout de suite plus complexe, il faut bien faire attention aux conditions de courses et autres ratage de lancement (par exemple si je prépare un cgroup, mais que mon processus ne se lance pas - on fait quoi ?). Reste la solution de créer une nouvelle session par processus - Mais ca peut devenir assez problématique assez vite.
- la seconde est liée au comportement même des cgroups en mode comptabilité. Si j'utilise les cgroups pour mesurer la consommation de ressources de mes processus (très utile quand un client a l'habitude de faire du while 1 fork; sans le vouloir). A aujourd'hui, mon appli avec son propre temps CPU peut checker la consommation quand elle le veut. Mais demain si tout passe par DBus je me fais un peu de soucis, parceque gérer 3000 processus qui vont venir le questionner à tour de rôle ca peut être lourd à digérer.
Maintenant il s'agit juste de réflexions en me basant sur l'existant et sur ce qui a été dit. Ca me casse les pieds de faire évoluer mes archis pour prendre en compte les nouveaux cgroups, mais ca n'est pas fondammentalement mauvais. J'attend de voir ce qui sort pour donner un avis plus complet sur la question.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Il ne s'agit pas de faire faire du correctif à Nagios (Même si c'est faisable, et même plutôt salvateur sur certaines config, on va pas déranger un admin à chaque fois qu'il faut relancer un php??-?gi, on a pas les moyens d'embaucher assez de monde) - mais plutôt de pouvoir déclencher facilement des sondes supplémentaires quand un comportement anormal est détecté.
Typiquement je surveille le temps d’exécution moyen d'une requête. Et quand il augmente je lance d'autres sondes pour savoir si ca vient de grosses requêtes qui sont lancées, des I/Os qui foirent ou de la mémoire vive qui est pleine. Comme ça je lance un minimum de sondes et je ne passe sur des sondes plus fortes que si le besoin s'en fait sentir et seulement là ou j'en ai besoin.
Pour la majorité des sondes il suffit de chopper les logs et/ou se connecter via un canal spécial à l'appli en mode client. Pour d'autres sondes il faut aller triffouiller plus loin ce qui implique soit un reload de la config du serveur qui pose soucis, soit le chargement de certains modules par l'appli,soit carrément un restart avec une autre config.
Tout ceci se faisait avant très simplement en ligne de commande en balançant des commandes de type
/etc/init.d/monservice -reload -with module2 -activate stacktrace -verbosity 5
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que je ne la connais pas. Et j'ai beau chercher et ouvrir des tickets chez RH je n'ai pas encore eu de réponses satisfaisantes. (parceque très honnêtement modifier les pre,env et les posts d'un fichier unit avant de le réenregistrer et de faire un restart n'est pas une réponse satisfaisante).
dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl
Oui, il y a cette solution, mais elle implique une bonne baffe en performance (10 à 15%) lors de mes tests, le 7% annoncé par fedora me parait très optimiste. En plus SELinux c'est quand même pas évident à gérer et très facile à casser (ce qui en langage hypervisuer veut dire plus personne ne peut rien faire tant qu'on a pas rebooter la machine en single user et passé SELinux en audit only). Comme les modifications ne s'appliquent qu'au redémarrage dans la plupart des cas, on a assez fréquemment de mauvaises surprises.
Ensuite (mais honnêtement je ne sais pas si c'est encore vrai) SELinux ne fonctionnait avec systemd que dans le cadre d'une descente de privilèges. C'est à dire plus pour empêcher un processus root d'interagir avec des services que pour autoriser un service non root à le faire.
La page de RH ne donne pas non plus d'exemple d'élévation : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Systemd_Access_Control.html on y parle que de réduire les droits.
Es-tu sur que l'élévation de droits marche ? (Vraie question)
[^] # Re: Le vendredi c'est permis.
Posté par barmic . Évalué à 5.
L'option
Restartdes units ne suffit pas pour ça ? Avec la possibilité de conditionner le restart et la possibilité de lancer une commande avant le démarrage du service pour récupérer l'état de la machine lors du restart.C'est pas une question de configuration DBus ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 1.
L'option Restart des units ne suffit pas pour ça ? Avec la possibilité de conditionner le restart et la possibilité de lancer une commande avant le démarrage du service pour récupérer l'état de la machine lors du restart.
Les watchdogs de systemd sont pas mal pour les cas faciles. Mais c'est assez compliqué d'écrire des règles pour shooter les processus PHP seulement quand il y a une fuite de mémoire ou une boucle infinie. Il y a des raisons tout à fait valable pour que le PHP se mette à bouffer le CPU ou de la mémoire comme un goret sur des périodes de temps plus ou moins longues. Avant d'utiliser le shootgun il faut vérifier que la consommation est constante, que la mémoire ne baisse pas significativement de temps en temps (utilisation en dent de scie) etc.
Donc on polle toutes les cinq/dix minutes, si ca dépasse systématiquement les quotas on polle toute les trente secondes, puis surveillance intensive et enfin shootgun.
Les watchdogs systemd n'ont pas (en tout cas pas encore à ma connaissance) la capacité à passer d'une règle de surveillance à l'autre en fonction des résultats.
C'est pas une question de configuration DBus ça ?
Jusque récemment il était impossible d'envoyer un message au dbus system vers systemd avec autre chose que root non limité. Maintenant il est possible de limiter root pour autoriser seulement certains types de messages sur certaines units de systemd. Mais je ne crois pas qu'il soit possible de passer des messages si l'on n'est pas root.
[^] # Re: Le vendredi c'est permis.
Posté par barmic . Évalué à 7.
Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 1.
Tu peux avoir un service qui fait ça. Il vérifie le processus comme tu le souhaite, puis si vraiment il y a un problème il le dézingue et systemd le relancera.
Déjà j'aime pas trop "dézinguer" un service qui tourne, même si avec systemd il y a un relatif ménage derrière qui évite les zombis et les processus fils qui trainent (Mais qui n'évite pas forcément la rémanence de données inutiles dans les applis connectées à ce service, le post-traitement n'est pas appelé etc.)
Autre effet désagréable si on relance le service de cette façon, systemd va compter un "fail". Donc pour que le service soit relancé à chaque fois, il faut configurer systemd pour qu'il relance le service systématiquement. Ce qui n'est pas sans effet de bord quand le service se met vraiment à merder tout seul comme un grand.
Ensuite, c'est bien beau pour un service, mais pour deux cents ca devient pénible. Si on décide de faire des procédures différentes par client, de modifier toute sles procédures de surveillance, de changer temporairement une procédure (par exemple le client prévient qu'il y aura une forte charge et/ou des tests pendant une semaine) etc. Ben tu as deux cents services à mettre à jour. Quand c'est fait depuis Nagios, tu as une règle à changer - tu es sur de ne pas oublier de règle puisque tout est centralisé etc.
Finalement à ce compte là autant avoir un script à l'ancienne qui essaye au moins d'arréter le service proprement, tout en faisant la nique à systemd. Mais ca n'est pas possible avec tous les services (des que l'on touche au réseau en dehors de networkd, il se passe des choses indésirables). Pendant qu'on y est on va même carrément mettre ce script comme cible de l'unit systemd - comme ça systemd lance un script qui à son tour lance le programme voulu. Un émulateur sysV en quelque sorte - mais avec une interface de plus.
[^] # Re: Le vendredi c'est permis.
Posté par barmic . Évalué à 5.
T'es pas obligé de lancer un signal KILL, non plus.
Tu as plusieurs politiques dans systemd en jouant avec
RestartetSuccessExitStatustu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends). Au pire tu dois pouvoir encapsuler les accès à dBus dans un processus séparé qui est root. Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 3.
T'es pas obligé de lancer un signal KILL, non plus.
Peut importe le signal que je lance, il faut que ce soit interprété comme un fail par systemd. (Si je mets le service en restart même sur un status de sortie correct, ca veut dire que je ne peux plus jamais arréter le service à moins d'éteindre la machine.)
A partir de là, a part sigkill, sigterm et sigint j'ai pas grand chose.
Si le process est solitaire, un sigterm peut permettre une sortie en douceur si tout va bien, mais si il y a plusieurs processus ou que sigterm ne suffit pas il faut y aller plus fort. Et là le fait que mon service secondaire ne soit pas l'init que les différentes infos ne soient plus logguées comme avant et qu'elle ne soit pas accessible facilement par un processus non root peut entrainer des problèmes.
Tu as plusieurs politiques dans systemd en jouant avec Restart et SuccessExitStatus tu devrais pourvoir faire en sorte que systemd relance le service quand quand tu le souhaite.
Pas vraiment non. Si c'est le service "moniteur" qui envoie un sigkill, je veux que le service monitoré redémarre. Par contre si c'est moi qui envoit le sigkill je veux que ce soit pris en compte comme un ordre définitif. Généralement je ne fais pas de sigkill, mais quand j'en fais un c'est pas pour que le processus soit relancé immédiatement.
Et l'action de Nagios ça ne peut pas être de simplement tuer les processus à relancer ?
Pour certains services problématiques, c'est déjà le cas aujourd'hui, mais après avoir tenté plusieurs fois une extinction propre via les commandes init.
J'ai l'impression que ce qui te pose problème ça n'est pas l'architecture de systemd, c'est juste que son API dBus ne serait accessible qu'à root (ce qui me surprends).
D'un autre coté, le fait que le bus systeme avec la target qui controle tous les services ne soit acessible que à root n'est pas franchement choquant.
Ce qui est plus embétant c'est que systemd ne possède aucun moyen de lui passer des paramètres dynamiquement que ce soit à l'init ou pendant la vie du service.(j'ai bien dit "des" je sais qu'on peu en passer un via @ à l'init.)
Je ne serai pas aussi négatif si il y avait les fonctions suivantes dans systemd
- Un moyen de lancer plusieurs fois la même unit avec des paramètres différents (ex : /etc/init.d/startvirtualnet --ip=192.168.200.0/24 --with-dhcp=192.168.200.1 --vinterface=vl12)
- un moyen de balancer des messages au service en cours d'éxecution (ex: /etc/init.d/service --rehash --reindex)
- un moyen d'autoriser des services non root à lancer les deux types de commandes ci dessus.
A l'heure actuelle pour chaque service lancé par systemd je suis obligé de chopper le PID au vol et de le stoquer pour pouvoir balancer les commandes directement, d'enregistrer et de détruire des units à tour de bras et le tout en faisant gaffe à ce que systemd ne prenne pas mal ce que je suis en train de faire.
Le reste ça me semble plutôt intéressant de faire gérer les services via un seul point (systemd) qui va gérer ça aussi proprement et de manière aussi centralisée que possible.
La question est limite philosophique, mais je ne considère pas que gérer un service se limite à le lancer, le logguer et à l'arréter. Pas mal de service son des options que l'on peut régler dynamiquement, tant que l'on ne peut pas les gérer depuis systemd, on se trouve à écrire des gestionnaires secondaires pour faire tout ce que systemd ne gère pas.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . Évalué à 7.
Genre ça:
http://www.freedesktop.org/software/systemd/man/systemd-run.html
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . Évalué à 1.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine, tu as déjà ouvert des tickets entre temps, mais par toi même, tu as pas trouvé les présentations comme
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon.pdf
La doc officiel comme ça :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Modifying_Control_Groups.html
Ou les blogs comme
http://schnouki.net/posts/2013/12/19/resource-control-with-systemd/
Ou la doc de systemd comme :
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
Sinon, c'est du dbus. Cad que la doc que je trouve sur developpez.com avec google me semble suffisante :
http://yoannsculo.developpez.com/tutoriels/linux/introduction-dbus/#LIV
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.
Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 2.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine
Ca fait un petit moment qu'on évalue les différentes beta. Mais je te rassure on a encore rien en prod - et pour l'instant la question est plus "est-ce que" que "quand".
La doc officiel comme ça :
Il s'agit ici de modifier un la configuration d'un CGroup donné. Pas de placer un processus dans un autre cgroup que celui par défaut ou encre de déplacer un processus d'un cgroup à l'autre. (à ma connaissance le kernel ne permet de toute façon pas le déplacement à chaud en ce moment.)
Par exemple si tu veux mettre tous les processus d'un client au sein d'un même cgroups pour pouvoir contrôler les ressources en un seul point central - ben c'est compliqué.
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
J'ai bien conscience d'être assez difficile à suivre vu que a) je n'ai pas franchement des problèmes communs (systemd marche très bien 95% du temps) et que b) je ne peux pas franchement donner d'exemples concrets pour cause de contrats à la con. J'avoue que ça n'aide pas.
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Je parle en mode hyperviseur. Bien sur tu testes avant de passer en prod, bien sur tu audites pendant un moment avant d'ajouter la règle en dur (IE tu passes quelques semaines avec setenforce à permissive - c'est ce que je voulais dire par mode "audit only") Mais à un moment ou à un autre il faut bien passer en vraie prod. Et là parfois pour tout un tas de raisons (fin de mois, mise à jour des logiciels du client, changement du sens du vent - que sais-je) le container va faire une action ou avoir besoin d'une ressource que tu n'avais pas prévu. Et là on repart en permissive, on récupère le container client à la pince à épiler (parceque bien entendu c'était pendant une écriture en base de données que le bug a eu lieu - sinon c'est pas drole - et bien entendu la base c'est pas Postgresql - c'est une grosse base de données commerciale qui vit très mal le fait de plus pouvoir écrire sur le disque d'une seconde à l'autre). On fait de plates excuses au client. Une fois, deux fois et puis on arrête SELinux.
Alors ca c'est ennormément amélioré au cours des trois dernières années (et on a appris de nos erreurs aussi) mais ca reste un sujet sensible (chat échaudé toussa.)
[^] # Re: Le vendredi c'est permis.
Posté par Anonyme . Évalué à 5.
Non, un processus démarré par systemd va pouvoir comme n'importe quel autre processus démarrer et interragir avec d'autres processus. Et les cgroups sont de toute facon pas prevus pour limiter ca.
Donc arrete de raconter n'importe quoi.
[^] # Re: Le vendredi c'est permis.
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 16 juin 2014 à 13:14.
Perso, j'étais plutôt parti sur le quinca qui a pris ses habitudes, n'aime pas qu'on les lui change et surtout se retrouve à égalité technique avec les post-ado qui arrivent et maitrisent mieux les outils modernes, et ça lui fait mal à l'égo (la personne a de l'expérience! faut pas déconner…) alors il va chercher n'importe quelle petite bête pour se justifier.
Ca me rappelle des experts X25 (ou ATM) qui disaient toujours que IP c'était de la merde, ça ne peut pas marcher au niveau professionnel, c'était pour bidouilleurs du dimanche. Pareil pour la VoIP, le commuté c'était la garantie de qualité voyons, ou ADSL contre des lignes T1 pour les pros.
Bref, assez loin du pré-ado, donc je ne suis pas comment tu imagines que des gens imagines une période pré-ado.
Le problème est qu'au contraire ton "métier" se jette dessus car il lui sert.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . Évalué à 1.
Perso, j'étais plutôt parti sur le quinca qui a pris ses habitudes, n'aime pas qu'on les lui change et surtout se retrouve à égalité technique avec les post-ado qui arrivent et maitrisent mieux les outils modernes, et ça lui fait mal à l'égo (la personne a de l'expérience! faut pas déconner…) alors il va chercher n'importe quelle petite bête pour se justifier.
Tiens un autre quinca qui a du mal à suivre toutes les évolutions Linux et qui rale plutôt que d'apprendre :
https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU
[^] # Re: Le vendredi c'est permis.
Posté par Kwiknclean . Évalué à 4. Dernière modification le 17 juin 2014 à 23:21.
En même temps ils avaient/ont raison les quinca, ADSL c'est clairement de la merde face à T1 … jusqu'a preuve du contraire il n'y a strictement aucune causalité entre standard de fait, et performance/efficience … malheureusement l'expérience montre que cela semble être plutôt l'inverse … M$, VHS …
[^] # Les sessions utilisateurs de systemd.
Posté par Sylvain Blandel . Évalué à 1.
J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd. Ce fil de discussion en parle, de même que cette page.
[^] # Re: Les sessions utilisateurs de systemd.
Posté par Kaane . Évalué à 2.
J'ignore si cela peut résoudre les problèmes que tu rencontres : des utilisateurs non-root peuvent créer, lancer et stopper des unités systemd.
Oui, mais seulement dans leur session. En d'autres termes l'utilisateur Nagions ne peut pas interragir avec le programme lancé par l'utilisateur Nginx sans être route. Et ce même si l'utilisateur Nagios aexactement les mêmes droits que l'utilisateur Nginx.
Le but du jeu ici est de pouvoir interragir avec des units systèmes, pas des units session.
[^] # Re: Les sessions utilisateurs de systemd.
Posté par KiKouN . Évalué à 2.
Ton correcteur orthographie fait soit trop de zèle ( Nagions, route ) soit pas assez ( aexactement ).
# mouaih
Posté par coucou78 . Évalué à -9. Dernière modification le 15 juin 2014 à 07:41.
Moi je le sens pas ce systemd : ca sent le truc pas clair, y'a de trop grosses enseignes derrieres …
Et quand je vois que M$ fut le sponsors numero un du dernier salon Linux : ca fait reflechir !
Faut que je le maitrise pour statuer definitivement.
[^] # Re: mouaih
Posté par Anonyme . Évalué à 9.
Oui, c'est louche tout ca. Comme tu l'as dit, M$ est sponsors du dernier salon Linux, et quand on connait les liens étroits entre M$ et la NSA, c'est très clairement les services secrets qui sont derrière systemd. Et tout le monde connait la relation entre la NSA et la NASA (c'est visible rien que dans le nom: juste un A en plus), qui est l'organisme chargé de gérer la communication et les relations avec les extraterrestres (officiellement, l'agence est juste chargée de l'exploration de l'espace car les extraterrestres n'existent pas, mais tout le monde sait ce qu'il en est réellement). Et face à tous ces éléments indiscutables, je pense qu'on peut affirmer ce qui est maintenant une évidence: systemd est un logiciel produit par les extraterrestres dans le but de faciliter une invasion de la terre dans les prochaines années, lorsque systemd aura été déployé sur tous les systemes du monde.
Oui, je sais que je prend des risques en affirmant cela, mais je le fais quand meme.
[^] # Re: mouaih
Posté par Maclag . Évalué à 5.
Nan mais faut arrêter le délire avec les extra-terrestres.
Tout ça c'est du vent pour ridiculiser les partisans de la théorie du complot, qui eux savent très bien que tout ça c'est la Corée du Nord qui avance ses pions pour mieux conquérir le monde!
[^] # Re: mouaih
Posté par Thomas Douillard . Évalué à 6.
Du Complot est d'ailleurs l'homme le plus influent de tous les temps. La preuve: personne ne sait qui c'est !
[^] # Re: mouaih
Posté par Sébastien TeRMiToR . Évalué à 0.
Chut!!!
# Je n'ai toujours pas compris comment fonctionnait ce bordel ...
Posté par Kwiknclean . Évalué à -3.
… faudrait que je prenne le temps de me documenter un jour.
Le seul avantage que je perçois actuellement sur ce sac de nouille est que sur les dernières RH lorsqu'un LUN iSCSI est introuvable tu ne patientes pas 1 à 2 minutes avant d'avoir le timeout et continuer le boot .. plutôt pratique lorsque tu en as plusieurs en carafes.
Après c'est sûrement exceptionnel puisque c'est porté par RH, ça je peux pas remettre en cause, tout comme la saincro-saint puissance de VMWare plébiscitée chaque jour par mes collègues.
# C'est toujours la même rengaine
Posté par Pseudo007 . Évalué à 4.
À chaque fois qu'il y a une grosse évolution, on en trouve plein pour gueuler (et raconter n'importe quoi).
Je trouve maintenant vain d'essayer de convaincre ces gens-là. C'est quasi contre-productif.
Le simple fait de vouloir les convaincre fait qu'ils vont encore plus se braquer. Genre "hum, on veut me convaincre, ça doit cacher quelque chose". Ils sont dans une attitude, ils veulent se croire la résistance face aux "vilains".
Mais, c'est du logiciel libre !
Si vous n'êtes pas content, au-lieu de gueuler, sortez vous les doigts du cul et codez quelque chose de mieux. C'est ça le logiciel libre ! C'est pas de la politique démagogique pour obtenir facilement des suffrages, c'est du code.
[^] # Re: C'est toujours la même rengaine
Posté par claudex . Évalué à 8.
Mais non, ça sert à rien de se sortir les doigts du cul, c'est un complot. Si tu fais un logiciel qui n'utilise pas systemd, dès que tu vas aux toilettes, un employé de Red Hat va sur ton PC pour ajouter la dépendance.
Mais plus sérieusement, je ne suis d'accord avec toi, sauf qu'il est quand même bien de corriger les gens pour ceux qui lisent et qui n'ont pas d'avis, qu'ils ne se fassent pas de mauvaises idées (enfin, je dis que c'est bien de le faire, ce n'est pas pour ça que j'en ai le courage).
« 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: C'est toujours la même rengaine
Posté par Maclag . Évalué à 5.
Inutile, le but de systemd étant que la NSA peut accéder à ton PC à distance par une porte dérobée, même quand tu n'es pas connecté.
Les gens du réseau, Monsieur, les gens du réseau!
[^] # Re: C'est toujours la même rengaine
Posté par Plinn . Évalué à 2.
Et puis quand tu te sorts le doigt du cul…. il sent mauvais.
Désolé, pouvais pas m’empêcher… -->[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.