anaseto a écrit 2229 commentaires

Je suis plutôt d'accord, je reste pas toujours devant l'écran au démarrage d'ailleurs. Après, peut-être que comme j'ai une configuration plutôt minimale, et j'utilise un simple tiling wm, que je démarre avec startx, ça fait longtemps que j'ai l'impression que tout est suffisamment rapide, d'où le fait que j'aie pas un vision claire de ce sujet sans doute.

En quoi est-ce incompatible avec les démarrages rapides et parallèles ?

Ce que je veux dire c'est que si ça démarre en une seconde j'ai le temps de rien voir, et pire encore si j'ai un écran de connexion qui apparaît avant que tout soit démarré.

Et le fait que ce soit stocké dans des logs te permet de vérifier si tu en as vraiment besoin.

Je suis d'accord, mais j'aime bien avoir un rendu visuel sur le moment, et s'il y a un souci je vais ensuite voir les logs pour les détails, car je vais pas systématiquement voir les logs après chaque démarrage non plus :)

Mais bon, mes préférences sont sans doute particulières, je voulais juste dire que démarrer instantanément et sans infos ne fait pas l'unanimité, et non sous-entendre l'opposé et que tout le monde doit avoir mes habitudes comme semble l'avoir compris Zenitram, désolé si je me suis mal exprimé. Et bon, je suis même pas si attaché que ça à mes habitudes en matière de boot, c'est pas comme si j'éteignais mon ordi juste après, content de l'expérience ;) Ni d'ailleurs que mon choix d'os ou distribution se fonde sur ce type de considérations.

Edit : Ah, et d'ailleurs, je pense à une chose : le seul moment où j'ai l'impression que le démarrage est trop long, c'est quand fsck fait son check des disques, et là je vois pas comment on pourrait raccourcir (enfin, peut-être, j'en sais rien).

Bref, plus on parle du système d'init de Linux, et plus on se rend compte qu'il a quelques années de retard…

Parler de retard laisse sous-entendre qu'il y a un chemin tout tracé à suivre dans le logiciel vers un certain objectif unique obscur, alors que c'est pas du tout le cas. Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement, et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non, alors, à quoi bon de tout vouloir faire à la fois ?

Ah, petite remarque : parler du système d'init sous Linux dans un journal qui parle des différents systèmes d'init, c'est rigolo.

Peut-être qu'en pratique ce sera quelque chose de plus granulaire : certains paquets comme gnome auraient une dépendance à systemd obligatoire pour simplifier la vie des packageurs, sans que cela affecte le choix d'un système d'init pour le système de base et les paquets pour lesquels supporter plusieurs systèmes d'init n'est pas un problème majeur. C'est de toutes façons comme ça déjà pour d'autres choses que le système d'init dans toutes les distributions, surtout binaires, où on peut pas faire des paquets précompilés pour toutes les options de compilation possibles pour permettre de gérer totalement ce qu'on veut ou non dans son système.

Sur openbsd nginx est installé par défaut depuis un certain temps, le script d'init est ici (dernière modification il y a presque deux ans), et représente moins de dix lignes de code que quiconque connaissant un peu de shell serait capable de faire, même si c'est son premier script d'init. Il faut qu'il connaisse aussi un peu nginx bien sûr, mais si celui qui écrit un script d'init pour un logiciel ne le connaît pas au moins un peu…

Donc je dirais que la réponse à :

Pour répondre à ta question : j'ignore si l'écriture de scripts shell pour démarrer/arrêter un démon est pénible, et j'ignore si la maintenance de ces scripts est chronophage.

est plutôt non.

C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.

Par contre, ici, en effet ça ne serait probablement pas optimal, car non prévu spécifiquement pour ce genre de choses. Et pour comble, sur le script que j'ai signalé ce ne serait même pas possible vu qu'openbsd ne supporte pas ce genre de fonctionnalités.

Tout dépend des fonctionnalités dont on a besoin, mais l'argument de la simplicité de maintenance des scripts d'init semble être valide ou non qu'au cas par cas, suivant les distributions et os (en supposant qu'un systemd ou équivalent fut possible ailleurs que sous linux). En ce qui concerne debian, vu qu'il a vocation à être un os universel, généraliste et populaire, le plus logique c'est que systemd soit supporté (par défaut ou non c'est une autre histoire), mais ça ne m'étonnerait que ça devienne le seul système supporté, tout simplement parce qu'il y a trop de gens derrière debian, avec des besoins variés et avis divergents, et qu'il y aura probablement bien quelqu'un pour packager openrc ou autre, m'enfin, peut-être que je me trompe totalement.

Par contre, je crois bien que ce sont les mainteneurs de paquets qui sont impactés. D'abord parce qu'il faudra tout convertir, mais surtout ensuite parce que la maintenance sera autrement plus simple avec systemd.

Je suis d'accord qu'avant tout le plus important est ce qu'en pensent les mainteneurs, et si systemd permet de faciliter les choses, tant mieux. Mais pour les distributions (ou des *BSD), qui se contenteraient de fonctionnalités basiques du type start-stop-restart-reload-check, je ne pense pas que la maintenance soit forcément plus facile avec systemd.

Je pensais à un remplacement plus léger et avec moins de fonctionnalités (genre mdev peut-être, mais je connais pas assez pour dire s'il y a vraiment un intérêt ou non), ou au fork sous gentoo pour se passer d'une dépendance à systemd, je sais pas si c'est vraiment un bonne idée non plus, mais pourquoi pas.

EDIT : je pense qu'il faut arrêter de critiquer tout uniquement parce qu'il y a le mot systemd dans la phrase. Oui avant on savait faire des trucs avant qu'aujourd'hui on ne fait plus forcément, mais c'est pareil pour tout. Il y a une époque sous Linux il fallait monter sa clé USB à la main, c'était cool cette époque. Aujourd’hui on a besoin de HAL ou de udev dans son système… C'est à peu près pareil pour tout, pour plus de conforts et d'efficacité certains composants sont apparus avec son lot de dépendance par la suite.

Perso, ce n'est pas le mot systemd qui me dérange, mais l'impression que ces derniers temps le problème du système d'init semble si important que si on n'accueille pas toutes les nouveautés avec enthousiasme en acceptant sans broncher qu'elles sont universellement supérieures aux solutions existantes c'est qu'on est un vieux conservateur qui veut en rester à la préhistoire. Le plus logique ne serait pas que, suivant les besoins, les ressources et les objectifs d'une distribution, un ou plusieurs de ces systèmes soient supportés ?

C'est comme HAL ou udev, c'est très bien, ça permet à un plus ample public de pouvoir monter des clés USBs facilement etc… mais est-ce vraiment utile dans tous les contextes? (vraie question, j'en sais rien si c'est possible de s'en passer sous linux) Et sinon, pourquoi faudrait-il voir d'un mauvais œil une distribution qui déciderait de ne pas les supporter ? (l'idée ne me semble pas choquante a priori)

Et en ce qui me concerne, le système d'init et udev ne sont pas des choses qui impactent mon utilisation quotidienne de type desktop, et je ne suis peut-être pas un cas isolé. Le seul truc qui change chez moi, c'est que si je devais passer à systemd, il me faudrait écrire un unit pour par exemple configurer mon réseau, ce qui est peu de chose, même s'il me semble un peu plus compliqué (peut-être parce que nouveau pour moi ?) que deux lignes dans /etc/conf.d/net avec openrc de gentoo, ou l'interfaces de debian, ou encore le hostname.if d'openbsd.

D'autres évènements exceptionnels sur wikipedia.

38 mm en une minute en Guadeloupe, et plus de 1800 mm en un jour à la Réunion, je sais pas comment l'île est toujours là ;)

Faut avouer que l'effet n'est pas spectaculaire, mais normalement on passe pas le gros de son temps sur des pages avec des widgets non plus, je sais pas, ça ne m'a jamais choqué particulièrement en tous cas.

En attenant que tout cela soit un peu plus disponible, y'a moyen de rendre Firefox GTK2 un peu moins MOCHE ?

Si tu ne tiens pas aux barres de menus et aux bords de fenêtres c'est facile : tu installes l'extension pentadactyl (ou vimperator) qui vire tout ça, et tu configures ton gestionnaire de fenêtres pour dessiner des bords très fins (comme par défaut sur les tiling wm). Il te restera les onglets, et chez moi j'ai laissé la scrollbar aussi, mais le tout n'est pas moche modulo la subjectivité en matière d'esthétique.

Perso, j'ai jamais fait autre chose que des calculs simples à la main avec la méthode où on élimine les sommets : tu normalises l'automate (un seul état initial et final), puis tu étiquettes progressivement les transitions par les expressions rationnelles au lieu de simple lettres : au début juste on étiquette par des classes de caractères, puis après tu élimines les sommets un par un en ajoutant des expressions aux transitions qui restent : en gros pour toute paire de sommets p et q tu dois tenir en compte les transitions qui vont de p au sommet que t'as éliminé, puis ensuite vers q, et tu factorise tout ça en une seule expression exprimant une transition de p vers q. À la fin il te reste juste une transition entre l'état initial et final qui correspond à l'expression régulière. Sur des exemples simples l'expression est en général potable, mais j'imagine que ça risque de devenir horrible si la taille augmente.

Je me souviens aussi d'un autre algorithme qui utilise des équations et le lemme d'Arden mais je l'ai plus en mémoire, et je sais plus du tout ce que ça donne à la main, faudra que je révise ça un de ces jours.

Méthode marteau-pilon : écris un automate complet qui reconnaît l'expression que tu as, et ensuite inverse les états finaux et non finaux, puis recalcule une expresssion du langage accepté par le nouvel automate :)

Oui, tu as raison, j'ai confondu les deux termes. Faut dire que hyper ~ super et vision ~ viseur ;) D'ailleurs c'est vrai que j'avais pas trop vu la logique de ta phrase du coup, je devais pas être très réveillé.

Je suis d'accord, et je suis sûr aussi que si autant de code a été écrit pour systemd c'est parce qu'il y avait des besoins réels.

Par exemple la capacité de systemd à connaître l'état des deamon pourrait permettre à des solution de supervision de s'auto-configurer ou de reposer sur systemd pour remplacer ou améliorer certaines sondes.

Peut-être, c'est sûr que ce n'est pas le système d'init d'OpenBSD qui va te permettre de faire ce genre de choses. Mais en l'occurrence tu trouveras que les gens OpenBSD n'ont réalisé encore aucune solution de supervision parce qu'ils considèrent que c'est impossible de virtualiser correctement les différentes architectures de manière fiable, et qu'ils conseillent plutôt des solutions moins parfaites en théorie, et moins pratiques, comme le chroot, ou la simple séparation des privilèges. Je ne dis pas que c'est forcément une bonne solution, je pense personnellement que la virtualisation est très utile, mais leur point de vue semble compréhensible aussi, et du coup leur objectif étant de rester simple, et OS à vocation pare-feu entre autres, sans doute que leur système d'init est suffisant pour leur objectif.

Avec des raisonnements pareils, autant éviter toute évolution ou nouveau développement.

Loin de moi l'idée de sous-entendre ça, vu le goût que j'ai pour les nouveautés, la recherche, etc… qui sont de très bonnes choses. Mais ça n'enlève pas que dans certains contextes tu n'as tout simplement pas besoin des nouvelles fonctionnalités apportées, ou que pour ton cas elles marchent moins bien que ce que tu as déjà, et enfin, si la stabilité est une des priorités on a le droit de vouloir utiliser un système plus simple et basique et qui a eu plus de temps pour mûrir, je ne pense pas qu'il y ait un mal à cela, ni que ça soit un frein à toute évolution, c'est juste que tout le monde n'innove pas sur les mêmes choses.

Il faut des gens pour tester les nouveaux systèmes d'init, d'autres pour tester les nouveaux langages (c'est plus le genre de chose qui m'amuse par exemple), d'autres le dernier tiling wm ou les dernières innovations des gros desktops, etc… ça veut pas dire qu'on doit tous tout tester maintenant, ni peut-être jamais, et que même si on teste une nouveauté on n'utilise pas aussi parallèlement d'autres bons vieux trucs qui marchent aussi.

Il me semble que \def est une macro TeX tandis que \newcommand est une macro LaTeX, donc de plus haut niveau. En règle générale, faire du pur TeX n'est pas la bonne voie, à moins que tu veuilles carrément faire un package.

J’ai pas fait d’études poussées sur le sujet mais j’ai vraiment pas l’impression que la religion soit un facteur de conflit sur-représenté relativement à son importance sociale historique.

Surtout que lorsqu'elle apparaît comme facteur, c'est plus un instrument détourné à mauvais usage qu'autre chose, comme pour les diverses idéologies qui en soit ne sont pas si palpitantes, et pourtant il en est fait tout et n'importe quoi en pratique, il suffit d'interpréter comme il faut. En vrai, tant qu'on en est à emmettre des hypothèses, je parirais que les pires atrocités ont été commises pour le pouvoir et l'argent.

Edit : j'avoue, je ne prend pas trop de risques en pariant ;)

J'ai regardé, ça fait 20 mil SLOC de C pour ksh (avec sloccount), donc petit pour un shell mais non négligeable. En suivant le même raisonnement, on peut aussi inclure gcc ou clang dans les deux cas, qui explosent facilement tout le reste, et on en conclut que la complexité du système d'init sera de toutes façons noyée dans le reste donc peu importe. Pourtant, ce raisonnement ne me semble absolument pas pertinent, voilà essentiellement pourquoi : le shell et gcc sont testés beaucoup plus amplement, pour des utilisations plus diverses et variées, depuis plus longtemps, et de toutes façons on ne pourra pas s'en débarrasser : pour le compilateur de C c'est clair, et pour le shell, je te laisse le soin d'inventer une évolution réaliste des systèmes à l'héritage Unixien qui nous permette de s'en passer, bonne chance!

L'init basique : si basique veut dire simple et compréhensible, je préfère systemd à SysV et similaires et leurs scripts. Si basique veut dire limité, j'en ai pas besoin.

S'il faut dire ça en une phrase, je dirais que basique veut dire ici limité tant que ça reste simple et compréhensible. Par exemple, sous la vm avec OpenBSD que j'ai (j'ai pas de FreeBSD mais ça ressemble peut-être) les scripts d'init sont tous du genre (donc moins de 10 lignes, voire souvent 3 lignes exactement) :

#!/bin/sh
#
# $OpenBSD: sshd,v 1.2 2013/02/05 00:26:31 halex Exp $

daemon="/usr/sbin/sshd"

. /etc/rc.d/rc.subr

rc_reload() {
        ${daemon} ${daemon_flags} -t && pkill -HUP -f "^${pexp}"
}

rc_cmd $1

et tous utilisent un script commun rc.subr qui fait 200 lignes. Le système d'init semble guidé par /etc/rc, script d'un peu plus de 500 lignes. Donc, je dis peut-être des bêtises (les système d'init c'est pas un de mes grands intérêts), mais ça m'a l'air aussi simple qu'on peut espérer niveau implémentation et maintenance si on ne veut que les fonctionnalités start-stop-restart-reload, et il y a moins de chance qu'il y ait un bug dans 700 lignes de shell que dans une centaine de millier en C, d'où l'intérêt.

Ceci dit, si t'as besoin d'un boot en parallèle ou que sais-je et utilisant des technologies plus complexes ce n'est sans doute pas ce qu'il faut, d'où l'intérêt de systemd aussi (voire d'autres systèmes comme openrc pour ceux qui sont mitigés dans leurs besoins et priorités).

Ça trolle souvent sur les systèmes d'init, mais j'ai quand même l'impression qu'au final le choix de système d'init devrait juste être déterminé par les besoins spécifiques de chacun, de l'utilisation qu'il en fait, et de ses priorités. Et si l'utilisateur n'a pas d'avis par rapport à ses besoins c'est que n'importe lequel des deux fera l'affaire.

http://marc.info/?l=openbsd-misc&m=139024400731106&w=2

Ils ont reçu cent mil dollars en une semaine!

Edit : vu leur méthode de marketing, c'est quand même pas mal ;)

Et puis, un code qui compile et testé sur VAX ou Motorola 881x0 ne veut pas dire qu'il ne se pétera pas la gueule en situation "stress" sur une autre plate-forme.

C'est plutôt le contraire qui est intéressant : il se peut qu'un certain bug peut être détecté plus facilement sur une certaine plateforme tout en étant quand même réel dans d'autres, et que tester sur les certaines vieilles architectures aide donc à découvrir de vrais bugs qui se manifestent sur les architectures courantes.

Il ne s'agit pas de limiter sa résistance au changement mais de faire les choses mieux.

Je pense que pour eux arrêter ce travail de test est justement faire les choses moins bien, et que c'est d'ailleurs un des points caractéristiques du projet.

Je respecte le projet OpenBSD, j'admire leur ténacité et leur rigueur mais moins leur entêtement et la grosse dépendance à De Raadt.

Si les opinions de De Raadt concernant ce problème n'étaient pas partagés par la plupart des développeurs ça se verrait sur la liste de diffusion, et ce n'est pas le cas visiblement.

Il ne faut pas s'étonner qu'OpenBSD suive un chemin plus à son rythme, et avec des objectifs un peu spéciaux : ils n'ont justement pas d'entreprise derrière qui les incite à telle ou telle fonctionnalité, et si c'est leur problème justement maintenant, c'est aussi peut-être ce qui fait son intérêt, et leur permet une certaine liberté quand à ce qu'ils considèrent comme des priorités.

Mais ce qui devrait compter pour une entreprise ce n'est pas vraiment la licence mais la main d'œuvre pas chère derrière : si les gens d'OpenBSD devaient arrêter leurs machines et arrêter leur travail, une entreprise qui dépendrait fortement des logiciels fait par les gens d'OpenBSD, voire utiliserait carrément OpenBSD, si elle ne veut rien perdre à l'histoire, elle va se retrouver à devoir changer son infrastructure vers un autre OS si elle l'utilise, ou en tous cas au moins va devoir chercher un moyen de s'assurer qu'openssh, pf, etc.. qu'elle utilise continuent à être maintenus avec la même qualité d'audit et de test.

Au final ça va être plus cher que de donner quelques milliers d'euros à des gens qui visiblement se satisfont d'un minimum pour continuer à travailler. Pour une grande entreprise ça ne représente vraiment rien comme somme, et c'est beaucoup plus rentable que de payer des développeurs pour faire ce même travail, avec probablement en plus un moins bon résultat. S'ils en arrivaient à ne pas pouvoir payer leur électricité (ça m'étonnerait un peu quand même), il y aurait sans doute plus d'une entreprise qui aurait une mauvaise surprise.

Donc oui, se plaindre que les entreprises ne donnent rien (même si elles ne sont pas obligées), du moins jusqu'à ce qu'il semble que ce soit vital pour que leur négoce n'en prenne pas un coup stupidement, n'est peut-être pas justifié par la licence, mais quand même un peu par le bon sens.

Ce journal vide (Sans aucune référence à la source, merci beaucoup, j'apprécie) est à +33 (allez voir dans le code source) le mien, documenté, la source originale, est à +10

C'est une question pratique, plutôt que de regarder le source pour vérifier l'authenticité du score, tu cliques sur pertinent, et tu regardes si ça passe à 1338.

Pour les cas typiques tu peux ajouter une ligne à ton /etc/fstab du type

/dev/sdb1 /mnt/usb auto noauto,user 0 0

Ici, je pars du principe que le label typique lorsque tu insères un clé usb est /dev/sdb1 (ça peut changer suivant le nombre de disques durs, etc…). Le auto c'est pour le type de système de fichiers, le noauto c'est pour que ça soit pas monté automatiquement au démarrage, et user c'est pour pouvoir monter sans root. Il te faut juste avoir un dossier /mnt/usb de créé. L'avantage c'est qu'après tu peux juste faire

$ mount /mnt/u<tab>

et le tour est joué, et pas besoin de spécifier le label.