Journal Archlinux est morte…

Posté par  .
Étiquettes :
-28
8
oct.
2012

Voilà ce que je peux lire dans /var/log/boot depuis quelques jours :

HOSTNAME= is deprecated. See rc.conf(5) and hostname(5) for details.
HARDWARECLOCK= is deprecated. See rc.conf(5) and hwclock(8) for details. 
TIMEZONE= is deprecated. See rc.conf(5) for details

Ça y est, je considère que Archlinux n’est plus, elle a été remplacée par une espèce de distro générique, chiante à administrer, avec des fichiers de configuration disparates ayant des syntaxes toutes différentes les unes des autres.

  • # Tu portes vraiment bien ton pseudonyme

    Posté par  . Évalué à 10.

    Tout est dans le titre.

    Franchement tu l'éditais souvent le rc.conf ? A part les DAEMONS, moi non.
    Ca va te prendre peut-être 5 minutes à tout casser, de plus pour éditer les bons fichiers sous systemd mais après tu n'y touches plus.

    Faut arrêter avec la guerre anti systemd. Surtout si c'est pour se ridiculiser avec des arguments qui n'ont aucune logique à part la simple résistance au changement…

    Fais avancer le débat et sors nous des vrais points techniques ou ergonomiques, je t'écoute.

    Personnellement, j'ai fait la migration, ca se fait en 10 minutes, et je n'ai rien perdu en fonctionnalité.

    • [^] # Re: Tu portes vraiment bien ton pseudonyme

      Posté par  . Évalué à 4.

      Franchement tu l'éditais souvent le rc.conf ? A part les DAEMONS, moi non.

      À chaque fois que je provisionne une VM sous Arch, à peut près une fois par semaine depuis deux mois.

      • [^] # Re: Tu portes vraiment bien ton pseudonyme

        Posté par  . Évalué à 8.

        T'as peut-être envie d'automatiser ça du coup, non ?

        Surtout que ce n'est pas particulièrement difficile…

        Ça ne répondra vraissemblablement pas à tes besoins, mais voilà ma solution : https://github.com/pcarrier/vagrant-images/blob/archlinux/build.sh

        Elle me permet de placer ma config dans overlay/, donc pas de grosse différence qu'il y ait un fichier avec plusieurs sections ou plusieurs fichiers…

      • [^] # Re: Tu portes vraiment bien ton pseudonyme

        Posté par  . Évalué à -3.

        Perso si je devais provisioner un vm par semaine depuis 2 mois, ca fait 7 semaines que j'aurais automatise la creation desdites vm.
        C'est pas comme si c'etait un des interet principaux des vm, l'automation, apres tout.

        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Tu portes vraiment bien ton pseudonyme

      Posté par  (site web personnel) . Évalué à 3.

      La guerre anti-systemD c'est pour ceux n'ayant pas encore regarder plus bas, dans la gestion des 'dépendances'…
      hein ? quoi ?

    • [^] # Re: Tu portes vraiment bien ton pseudonyme

      Posté par  . Évalué à 7.

      Fais avancer le débat et sors nous des vrais points techniques ou ergonomiques, je t'écoute.

      Personnellement, j'ai fait la migration, ca se fait en 10 minutes, et je n'ai rien perdu en fonctionnalité.

      Bof c'est pas des arguments. Je ne connais pas Arch alors je ne sais pas à quel point le changement peut être dérangeant, mais tout n'est pas question d'ergonomie et de fonctionnalité. Par exemple, si j’installe Mac OS X, je ne vais pas perdre en fonctionnalités, voir même pas en ergonomie (même si l'interface me correspond beaucoup moins, elle est objectivement ergonomique il me semble). SI il y a autant de ditrib c'est pour correspondre à des attentes différentes. Il me semble qu'en changeant pour systemd, Arch se prive de ce qui attirait une part non négligeable de ses utilisateurs, et je ne trouve pas que ce soit une bonne idée, sans que ce soit de l'anti-systemd primaire. Par exemple, je ne trouverais pas idiot de le voir arriver sous Ubuntu.

      • [^] # Re: Tu portes vraiment bien ton pseudonyme

        Posté par  . Évalué à 8.

        Je ne connais pas Arch
        Il me semble qu'en changeant pour systemd, Arch se prive de ce qui attirait une part non négligeable de ses utilisateurs

        Alors puisque tu ne connais pas : "A simple, lightweight distribution" mais aussi "Based on a rolling-release model, Arch strives to stay bleeding edge, and typically offers the latest stable versions of most software."

        On a donc une distribution simple et légère, qui reste toujours à jour. En aucun cas on ne refuse le "progrès" avec Arch, la tendance est clairement à pousser les nouveautés. Pour le meilleur et pour le pire d’ailleurs. Par exemple je n'ai personnellement pas du tout apprécié de voir débarquer Gnome 3 à peine deux semaines après ça sortie, sans possibilité de garder un Gnome 2. Mais c'était un choix cohérent avec la philosophie de la distro, on s'adapte et on passe à autre chose si on aime pas. La flexibilité inhérente au modèle de fonctionnement de Arch fait qu'aujourd'hui Gnome 2 est de retour (avec Mate), et qu'on à toujours le choix entre tous les WM existant.

        Après qu'on n’essaye pas de venir dire des conneries sur la validité des choix effectués par les mainteneurs, eux même ont été passablement énervés des réactions de beaucoup d'utilisateurs venus se plaindre sans avoir essayer systemd bien sur, et avec des arguments à la mord moi le noeud (genre comme ceux que l'on trouve dans les innombrables journaux anti systemd (et autre…) ici même). J'arrive pas à retrouver le thread en question mais ça a déjà été évoqué sur linuxfr.

        Ceci étant dit, je pense qu'on reste dans la philosophie en installant systemd, qui est de mon point de vue et de ceux qui l'ont essayé :
        - moderne et à jour, et oui désolé, systemd n'a pas 25 ans…
        - simple, car tous les services démarrent "à la demande"; configuration en moins de 10 minutes (voir wiki, très bien fait)
        - rapide, par ce que c'est franchement très rapide (la va falloir l'essayer pour voir)
        - bien "outillé", avec des choses comme systemd_ui, systemd_analyse, des outils jamais vu avec le bon vieux sysVinit, encore moins de façon intégrés et génériques
        - HO MON DIEU, on à maintenant des fichiers de conf génériques à la place du rc.conf unique à Arch Linux. Vraiment, ça vaut bien la peine de changer de distro…

        • [^] # Re: Tu portes vraiment bien ton pseudonyme

          Posté par  . Évalué à 1.

          Ce qui me gène dans systemD c’est l’éloignement de 1 outil qui fait une chose, mais qui la fait bien. Avant, si on avait une faille dans un service réseau, on pouvait désactiver ce service en attendant une correction. Après, si une faille dans la couche réseau de systemd apparait, et je serais étonné que ça n’arrive jamais, impossible de le désactiver la distribution ne l’a pas prévu…
          Un autre point qui me gène, c’est que quand tu as fini de démarrer, ben en fait, il en reste encore… (un peu comme paic citron) mais là c’est dans le mauvais sens. Ça fait un peu comme winXP, comme quoi microsoft avait 10 ans d’avance.
          Quelle sera la prochaine évolution ? Inclure wayland dans systemd pour plus de réactivité ?
          « Je me fais vraiment trop vieux pour ces conneries. »

          • [^] # Re: Tu portes vraiment bien ton pseudonyme

            Posté par  . Évalué à 5.

            Avant, si on avait une faille dans un service réseau, on pouvait désactiver ce service en attendant une correction. Après, si une faille dans la couche réseau de systemd apparait, et je serais étonné que ça n’arrive jamais, impossible de le désactiver la distribution ne l’a pas prévu…

            Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.

            En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités. Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer (comme udev, readahead, les logs, hostname, dbus, etc). Comme SysV, sauf qu'il est plus modulaire (on n'est plus limité à six runlevels dont trois sont réservés).

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Tu portes vraiment bien ton pseudonyme

              Posté par  . Évalué à 10.

              Il n'y a pas de couche réseau dans systemd. Ce n'est qu'une unité comme un autre.
              Non, mais il y a trois couches communicantes en dépendance (2 IPC et les sockets). Ca laisse pas mal de place pour des failles réseau. Et puis les virtual sockets c'est pas techniquement dans systemd, mais c'est vraiment pas loin à coté.

              En fait, systemd est très KISS : il ne fait qu'une chose, il gère des unités.
              Pas vairment non, il fait appel à plusieurs dépendances pour gérer des unités (qui elle mêmes on des sous dépendances pour pouvoir fonctionner, la liste complète est là : http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) en comptant bien il y en a juste 40 dont deux IPC (DBus et treaty) plusieurs FS et les mounters qui vont avec etc. Donc dire que systemd est KISS c'est juste une blague.

              Et tout ce qu'on lui reproche de faire en trop ne sont que des unités qu'il se contente de gérer
              On lui reproche d'avoir d'ennormes dépendances pour au final en faire moins que SystemV init. On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.

              Comme SysV, sauf qu'il est plus modulaire
              Non il est nettement moins modulaires que SystemV init. Il ne supporte pas les sous scripts d'init, pas les templates, il faut recompiler toute la chaine de boot à chaque modif etc. La ils sont en train de massacrer udev pour le rendre plus compatible avec systemd et ils demandent au kernel de faire des modifs aussi pour corriger les bugs qu'ils ont introduits dans udev.
              Egalement l'init systemd ne fonctionne pas avec
              - La plupart des systemes de fichiers chiffrés
              - le /usr distant (au revoir les terminaux léger)
              - le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.
              - le pxe "à rebond" (le initram charge deux environnement le premier pour authentifier l'utilisateur/la machine - le second qui est le "vrai" environement de travail) mais bon c'était déjà foutu pour les terminaux léger.
              - la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.
              - la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.

              On notera aussi pèle-mèle :
              La complexité de la maintenance du truc : si un jour vous cassez votre boot process au niveau de systemd, vous avez interet à avoir une machine très similaire avec un environnement très très proche pour réparer systemd. Sur une machine un peu custom, réparer systemd depuis un LiveCD c'est juste un massacre.
              Le coté (LSB/Fedora style)/Linux only. Systemd n'est pas compatible avec tous les systèmes même si ce sont des Linux récents. Encore faut-il avoir un processeur et un environnement qui peuvent s'y préter.

              A part la vitesse de boot (dont personnellement je me fous royalement) Systemd est loin derrière SystemV init à tous les points de vues. Que se soit la compatibilité, la flexibilité, la maintenance (et même la capacité à fermer des processus et/ou à logguer leur comportement). Il ne faut pas oublier que l'on peut parfaitement utiliser cgroups avec SystemV init (95% des gens qui défendent systemd défendent en fait l'utilisation de cgroups dans les scripts d'init - ca marche très bien avec SystemV init, même mieux qu'avec systemd vu que la plupart des shells sont turing complets).

              • [^] # Re: Tu portes vraiment bien ton pseudonyme

                Posté par  . Évalué à 0.

                On dira ce qu'on voudra mais systemd n'est pas turing complet, les shells si.

                Par ce qu'un systeme d'init a besoin d'etre turing complet ?

                Faudrait choisir. Systemd c'est nul par ce que :
                - c'est pas KISS, ca fait trop de choses
                - c'est pas turing complet, ca fait pas assez de choses

                Egalement l'init systemd ne fonctionne pas avec
                - La plupart des systemes de fichiers chiffrés

                Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?

                • le multiboot du même service (service qui se clone et qui se ferme mais ou il ne faut pas fermer les clones) - on peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init. Bon c'est un peu con en période d'explosion du cloud, mais on peut pas penser à tout.

                On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière

                • la gestion des mots de passe au boot. Merci de donner les clefs de tout vos certificats à systemd ou de lancer vos services à la main si vous devez taper un mot de passe à un moment. le parallélisme ca ne va pas avec l'interactif.

                Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
                http://www.freedesktop.org/software/systemd/man/systemd-ask-password.html

                • la gestion des templates. Vous devez démarrer 6 ou 7 VPN ? Ben ca fera 6 ou 7 services à configurer indépendamment les uns des autres mon bon monsieur.

                Tout comme le reste c'est faux.
                http://0pointer.de/blog/projects/instances.html

                Y a il un seul truc exact dans cette liste ?

                La quantité de mensonges par ligne dans ce message est assez impressionante !

                • [^] # Re: Tu portes vraiment bien ton pseudonyme

                  Posté par  . Évalué à 10.

                  Par ce qu'un systeme d'init a besoin d'etre turing complet ?
                  Je sais pas… Tu penses que l'informatique va évoluer ou pas ? Si tu penses que ca va encore évoluer ben il vaut mieux avoir un système turing compler, parceque sinon si on se retrouve sur un cas que l'on ne sait pas gérer on risque de devoir encore changer de système d'init.
                  Par cotnre si tu penses que l'informatique c'est un produit fini et stable, alors ca ne pose pas de problème.

                  Faudrait choisir. Systemd c'est nul par ce que :
                  - c'est pas KISS, ca fait trop de choses
                  - c'est pas turing complet, ca fait pas assez de choses
                  C'est clair qu'il faut faire un choix, mais tu as l'air de considérer que si je considère le produit à la fois comme incomplet ET surchargé c'est parce que je ne sais pas ce que je veux.
                  Et pourtant le produit est à la fois bloated (40 dépendances pour les units - et qu'on ne vienne pas me dire qu'on peut désactiver des units, il y a tellement de dépendances croisées et de d'assomptions que c'est un cauchemar) et incomplet (pas moyen de faire des templates par exemple - dans un monde ou on créé dynamiquement des VM à la demande c'est quand même dommage)

                  Le systeme de fichier chiffré que j'utilise ne ferait donc pas partie de la plupart des systemes de fichiers chiffrés ?
                  Grosso modo systemd fonctionne avec deux méthode de chiffrement, et recommande fortement d'utiliser luks. Egalement systemd ne fonctionne pas avec tous les systemes de fichiers à clef distante (ie il faut s'authentifier sur un serveur pour récupérer les infos sur la clef). Tu as un des deux systemes qui marche et ca te convient, tant mieux pour toi. Mais systemd continue quand même à ne pas fonctionner avec la plupart des systèmes de chiffrement existant.

                  On peut choisir si il faut tuer tous les process, uniquement le principal, ou aucun mais executer une commande particulière
                  Je sais je l'ai dit : On peut mettre un mode dégradé en place pour dire à systemd de ne surtout toucher à rien, mais du coup on est moins bien qu'avec SystemV init
                  Seulement si on choisit de ne rien tuer (la seule option valable dans ce cas) on ne peut plus rien piloter avec systemctl, il faut donc créer d'autres scripts (donc travail double et maintenance en parallèle) pour les opérations standard du daemon (restart/stop/reload etc.)

                  Il suffit que le service soit configuré pour utiliser systemd-ask-password pour demander le mot de passe.
                  Petit extrait :
                  The purpose of this tool is to query system-wide passwords—that is passwords not attached to a specific user account.
                  Petit problème le mot de passe d'un certificat (apache par exemple) est à la fois non global au système ET lié à un utilisateur ET plusieurs instance du serveur peuvent avoir besoin de mots de passe différents (le proxy n'utilise pas forcément le même certificat que le serveur frontal). Donc pour débloquer des certificats systemd-ask-password ne marche pas.

                  Tout comme le reste c'est faux.
                  http://0pointer.de/blog/projects/instances.html
                  Et blam en plein dedans, tout le but de cet article est d'expliquer comment se passer des templates en créant un service par fichier de config (et en éditant à la suite les liens symboliques à la main pour que ca marche).
                  Donc le but de cet article tout entier est d'expliquer comment contourner le problème des templates qui ne fonctionnent pas sous systemd.

                  Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de config il faut créer 10 services
                  systemctl start toto@config0
                  systemctl start toto@config1
                  systemctl start toto@config2

                  systemctl start toto@config9

                  Puis ensuite bien sur aller éditer 10 liens symboliques à la main

                  Y a il un seul truc exact dans cette liste ?
                  La quantité de mensonges par ligne dans ce message est assez impressionante !

                  Je suis supposé dire quoi là ? Te renvoyer ton commentaire insultant au visage en t'indiquant qu'il ne suffit pas de lire trois mots d'un article en anglais qui semble aller dans ton sens (de loin et dans le brouillard) mais qu'il faut aussi lire les specs et les comprendre.

                  • [^] # Re: Tu portes vraiment bien ton pseudonyme

                    Posté par  (site web personnel) . Évalué à -3.

                    40 dépendances pour les units

                    Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.

                    Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne. En gros, tu parles mais sans même essayer de comprendre. Mais c'est sur que c'est plus compliquer de comprendre un truc qu'on utilise pas.

                    Grosso modo systemd fonctionne avec deux méthode de chiffrement,

                    Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?

                    Donc pour débloquer des certificats systemd-ask-password ne marche pas.

                    «Right now this is used exclusively for encrypted harddisk passphrases but later on this is likely to be used to query passphrases of SSL certificates at Apache startup time as well.»

                    En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.

                    une horreur immonde. Si on a dix fichiers de config il faut créer 10 services

                    C'est tellement mieux un script bash avec un case à ralonge…

                    systemctl start toto@config0
                    systemctl start toto@config1
                    systemctl start toto@config2

                    systemctl start toto@config9

                    Puis ensuite bien sur aller éditer 10 liens symboliques à la main

                    Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.

                    • [^] # Re: Tu portes vraiment bien ton pseudonyme

                      Posté par  . Évalué à 10.

                      Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.

                      Et allez on commence par une attaque. Tu es sur de toi là ? Non parce que supposons que j'arrive à démontrer que ce que je dis se tient tu fais quoi ?

                      Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne.

                      C'est juste des variables et des interfaces DBus ? Ouf tout va bien alors - ca devrait donc être possible à implémenter sous tous les systèmes qui ont un portage de DBus alors. Ah ben sauf que non, dans la liste que j'ai donné (et que je redonne http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart ) il n'y a quasiment que des "no" dans systemd Implementation portable to other OSes or non-systemd distributions et le reset c'est partially.
                      Une variable non portable c'est quoi ? C'est un caractère qui n'existe que sous Linux ? Une interface DBus non portable c'est un acte de divination que fait Linux mais que les autres implémentations n'ont pas ?
                      Si ces variables et ces interfaces sont non portables c'est qu'elles dépendent à leur tour d'autres éléments du système qui eux n'existent que sous Linux. Ce sont bien des dépendances au sens fort du terme. C'est à dire qu'il faut des éléments système actifs supplémentaires pour que la fonctionnalité soit présente.

                      Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?

                      On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille), ou du systemd qui existera peut être dans 5 ans ?
                      Non parce que le systemd d'aujourd'hui il a plein de chose qui sont gênantes pour pas mal de systèmes de chiffrement
                      a) Déjà le /usr doit être accessible - donc lui si il est chiffré il ne peut l'être que par une des deux méthodes compatibles aujourd'hui
                      b) Les virtual sockets foutent pas mal la grouille dans tous les chiffrements qui requièrent une synchro précise avec une base de temps extérieure. Ca peut se contourner en rajoutant des dépendances dans tous les sens (ie en ayant tout un pan du processus de boot qui s’exécute de façon séquentielle, donc systemd n'apporte plus rien à ce niveau là) mais systemd va mettre des batons dans les roues pour debugguer (si on oublie une dépendance, l'authentification va foirer, mais on aura aucun message permettant de comprendre pourquoi vu que le socket virtuel aura avalé l'erreur)
                      c) Je ne vois pas avec l'architecture actuelle comment systemd pourra gérer le chiffrement des partitions liés à un device interactif extérieur (par exemple un lecteur carte à puce dans lequel l'utilisateur doit insérer sa carte puis composer un code au bon moment pour que la partition se débloque). Vu les récentes discussions au sujet de udev et le point de vue du mainteneur actuel ca me semble mal parti pour être corrigé dans un délai court.
                      d) Dans la même veine, et même sans interaction avec la console je vois mal comment l'automount de systemd va gérer une clef usb (ou équivalent) insérée pendant le boot et qui contient un certificat nécessaire à la poursuite du boot.

                      Ca c'est pour les exemples qui me viennent en tête là maintenant. Mais honnêtement même un bête déchiffrement via auth kerberos externe pose des problèmes en ce moment.

                      En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.

                      Et que donc ça ne marche pas, mais c'est pour autant que l'on ne va pas le mettre en prod au détriment d'un système qui lui fonctionne. Ben voyons.

                      C'est tellement mieux un script bash avec un case à ralonge…

                      Pas de case à rallonge, juste un script qui parse un fichier de conf et attribue des variables. C'est assez courant en fait.

                      Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.

                      Donc
                      a) J'ai toujours dix services à maintenir (N.B : sur un système que je maintiens en ce moment les config sont auto-générées et stockées en base, je dois en avoir un peu plus de 3000 là - et non ca n'est pas une mauvaise utilisation du produit)
                      b) J'ai aussi un script de plus à maintenir pour lancer et enregistrer mes configs (sauf que je ne veux pas toutes les enregistrer, je ne lancerais jamais les 10 VPN en même temps sur ma machine, la plupart n'ouvriront que deux ou trois VPN différents maximum au cours de leur vie, mais je ne peux pas savoir d'avance lesquelles)
                      c) Au moment de mettre à jour les configs il faut que je me ramasse en plus des tests pour savoir dans quel état est systemd, et si le #@!$ de lien symbolique est en cours d'utilisation ou pas.
                      d) Il ne faut pas oublier de lancer le script de mise à jour après chaque modif des fichiers de conf, comme au bon vieux temps des premiers lilo. COOL

                      • [^] # Re: Tu portes vraiment bien ton pseudonyme

                        Posté par  (site web personnel) . Évalué à -3.

                        a) J'ai toujours dix services à maintenir

                        FAUX, 1 seul!

                        Après, pour le reste, vu qu'on ne sait pas ce que tu fais, c'est un peu compliqué de savoir la validité de tes propos…

                      • [^] # Re: Tu portes vraiment bien ton pseudonyme

                        Posté par  . Évalué à 2.

                        On parle du systemd de maintenant que les distribs sont en train de nous déployer en prod en masse (sauf Red Hat qui se tate encore pour la 7, ce qui en soit devrait mettre la puce à l'oreille) […]

                        Debian non plus, wheezy n'est pas sous systemd et Sid non plus. Actuellement il y a sysinitv partout par défaut et des paquets pour tenter upstart, systemd, minit, etc.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Tu portes vraiment bien ton pseudonyme

                    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 10 octobre 2012 à 23:36.

                    Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple
                    /etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de
                    config il faut créer 10 services

                    J'avais pas vu celle là!

                    Donc avant, y'avait un script avec des arguments… Si on veut, parce que je vois pas comment ca peut être fonctionnel ton truc, depuis quand sysvrc passe autre chose que start/stop comme argument au boot ? Allez, pour te faire plaisir, on va dire que ca fonctionne (même si dans la vraie vie, à moins de foutre les appels en dur dans rc).

                    Et maintenant y'a ca:
                    dhcpcd\@.service qu'on appelle comme cela: systemctl start dhcpcd@eth0

                    Et qu'on peut activer au boot avec le paramètre voulu:
                    systemctl enable dhcpcd@eth0

                    En gros, tu viens de démontrer qu'avant c'était pourri et que maintenant c'est générique. Bravo…

                    • [^] # Re: Tu portes vraiment bien ton pseudonyme

                      Posté par  . Évalué à 2.

                      Si on veut, parce que je vois pas comment ça peut être fonctionnel ton truc, depuis quand sysvrc passe autre chose que start/stop comme argument au boot

                      Au hasard parce que les fichiers shells lancés par sysvrc peuvent prendre en compte l'environnement, faire des tests, valider des conditions etc.
                      En fait je crois même que c'est une des choses principales que leur reproche Lennart.

                      En gros, tu viens de démontrer qu'avant c'était pourri et que maintenant c'est générique. Bravo…

                      Alors déjà le jour ou ça marche avec autre chose que certaines fonction réseau tu me fais signe (N.B : systemd ne sait toujours pas gérer les templates)
                      Ensuite mon script réseau il lance dhcpcd sur eth0 seulement si il y en a besoin (et donc il n'essaye pas de le lancer si il n'y en a pas besoin) sans que j'ai besoin de l'activer ou de le désactiver en fonction de comment je pense rebooter.
                      De plus mon script ne fais pas croire à tous les autres services qu'il y a une interface active et configurée avant de leur dire que c'était pour rire 30 secondes plus tard.
                      Et pour finir j'ai pas besoin de créer un fichier de service/unit quand je rajoute une interface en cours de route (bonjour les VM) je fais /etc/init.d/monscriptRéseau.sh eth42 et hop.

                      Donc je ne sais pas ce que j'ai réussi à démontrer, mais toi j'ai une petite idée.

                      • [^] # Re: Tu portes vraiment bien ton pseudonyme

                        Posté par  (site web personnel) . Évalué à 1.

                        Donc je ne sais pas ce que j'ai réussi à démontrer, mais toi j'ai une petite idée.

                        Bon, je vais pas batailler, tu n'as pas l'air de comprendre…

                        dhcpcd\@.service C'EST UNE SEUL UNIT!

                        DONC:
                        quand je rajoute une interface en cours de route (bonjour les VM) je fais systemctl start dhcpcd@eth42.service et hop.

                        Tu comprends mieux là ? T'as pas 1 unit par interface!

                        • [^] # Re: Tu portes vraiment bien ton pseudonyme

                          Posté par  . Évalué à 4.

                          dhcpcd\@.service C'EST UNE SEUL UNIT!

                          Si toutes les options sont identiques oui, on peut se démerder pour faire uen seule unit en effet.
                          Maintenant supposons que sur une des cartes je veuille utiliser l'option -H (demande à dhcpcd de changer le nom d'hote) par exemple (option dont bien entendu je ne veux surtout pas sur les autres cartes). Ben faut faire une deuxième unit.
                          Sur une autre carte je veux l'option -K (conserve la liste resolv.conf) et sur encore une autre (qui n'est activé qu'en cas de soucis majeur) je veux les deux options.
                          Bien sur les cartes qui sont de la forme /dev/vethX ont des parametrages différents de celles qui sont en /dev/ethx, certaines cartes utilisent un autre fichier de conf (configuré via -L), elles ne loguent pas toute au même endroit donc en systemd ce sont des units différentes. etc. etc.

                          Bon je te rassure dans le cas de dhcpcd (et pour quelques autres dont ifup/ifdown) on peut tricher en mettant un script bash en pre exec qui va se charger de mettre à jour les variables d'environnements sur lesquelles s'appuie systemd. mais pour d'autres systèmes ca n'est tout simplement pas possible.

              • [^] # Re: Tu portes vraiment bien ton pseudonyme

                Posté par  (site web personnel) . Évalué à 0.

                • le /usr distant (au revoir les terminaux léger)

                J'aimerai bien savoir comment tu peux mettre ces deux parties ensemble? Genre ou est obligé de monter un /usr à part pour faire un boot réseau ?

              • [^] # Re: Tu portes vraiment bien ton pseudonyme

                Posté par  . Évalué à 1.

                Egalement l'init systemd ne fonctionne pas avec
                - La plupart des systemes de fichiers chiffrés

                Ben si, je l'utilise.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Tu portes vraiment bien ton pseudonyme

            Posté par  (site web personnel) . Évalué à 9.

            Ce qui me gène dans systemD c’est l’éloignement de 1 outil qui fait une chose, mais
            qui la fait bien.

            Moi ce qui me gène, ce sont les gens qui ressorte cette phrase alors qu'ils ne l'ont jamais compris. Cette philosophie n'a de sens que pour le shell, pouvoir faire des choses complexes en assemblant des commandes.

            Donc, quand tu fais un programme, essaye qu'il ne fasse qu'une tache et donc si t'as autre chose à faire, fais un second programme… Ce sera utile un jour à quelqu'un.

            Mais pour un SGBD, un environnement de bureau ou un système d'init, cela n'a aucun sens.

        • [^] # Re: Tu portes vraiment bien ton pseudonyme

          Posté par  . Évalué à 3.

          La flexibilité inhérente au modèle de fonctionnement de Arch fait qu'aujourd'hui Gnome 2 est de retour (avec Mate), et qu'on à toujours le choix entre tous les WM existant.

          Ici, les mainteneurs de Arch abandonnent l'ancien système d'init. Que des utilisateurs puissent le maintenir de leur coté c'est pas du à la flexibilité de Arch, c'est du au fait que c'est libre.

          Après qu'on n’essaye pas de venir dire des conneries sur la validité des choix effectués par les mainteneurs, eux même ont été passablement énervés des réactions de beaucoup d'utilisateurs venus se plaindre sans avoir essayer systemd

          Heu si les mainteneurs s'énervent que leur boulot ne plaisent pas à leurs utilisateurs, y'a un problème quand même… C'est juste leur boulot d'essayer de leur plaire dans l'idée hein. Après évidemment, ils ne sont pas payés, donc ils peuvent choisir de ne pas les écouter, mais faut pas venir se plaindre qu'ils ne soient pas content. Surtout qu'on est pas obligé d'utiliser systemD pour dire qu'on en est pas content, principalement parce que techniquement il marche surement très bien, je ne pense pas que le problème vienne de la… Cela dit, si concrètement il y a eu une discussion sur la ML et qu'il en est ressorti qu'il était mieux d'utiliser systemD, OK. Moi je trouve juste que c'est pas KISS, et pas conforme a l'idée que je me faisait d'Archlinux et qui fait que je ne vais surement pas y passer.

          Cela dit, la description que tu donnes me fait plutôt penser à Fedora. Certe Arch est rolling release, mais loin du "on intègre tout ce qui est nouveau si c'est bien techniquement". La première ligne du site français dit quand même : "Arch Linux est une distribution légère et rapide dont le concept est de rester la plus simple possible (philosophie KISS)". Pour moi ça veut dire qu'on intègre pas des technos qui sont compliquées à apprendre/utiliser pour l'administration du système. Clairement j'ai du mal à voir systemD comme "le plus simple possible". Encore une fois, c'est bien dans Ubuntu, mais, personnellement, je ne trouve pas qu'il ai sa place dans Arch.

          • [^] # Re: Tu portes vraiment bien ton pseudonyme

            Posté par  . Évalué à 0.

            Que des utilisateurs puissent le maintenir de leur coté c'est pas du à la flexibilité de Arch, c'est du au fait que c'est libre.

            Selon moi la flexibilité d'Arch ne vient pas du fait qu'elle utilise des logiciels libre libre, mais car elle permet aux utilisateurs de créer très facilement des paquets avec les PKGBUILDs, de poster directement ces paquets utilisateurs sur le site officiel, voir même de les intégrer directement dans les dépôts si ces paquets sont suffisamment utilisés et demandés par les utilisateurs (système de vote sur AUR).
            Dans une autre distribution Mate serait peut être resté indéfiniment sur un obscure dépot d'un utilisateur, alors que sur Arch on peut faire "packer -S mate".

            Heu si les mainteneurs s'énervent que leur boulot ne plaisent pas à leurs utilisateurs, y'a un problème quand même… C'est juste leur boulot d'essayer de leur plaire dans l'idée hein.

            Je pense vraiment pas que les mainteneurs ont pour objectif de plaire, mais de faire la meilleure (selon eux) distribution possible.

            Certe Arch est rolling release, mais loin du "on intègre tout ce qui est nouveau si c'est bien techniquement"

            Systemd n'est ni nouveau, experimental ou compliqué. C'est un choix imposé par les mainteneurs car faisant vraiment parti du système de base. Outre le système d'init (et d'ailleurs on peut quand même en changer), très peu de paquets sont vraiment imposés dans Arch, la philosophie reste quand même "fait ta propre tambouille et installe ce que tu veux".

  • # Pas tout à fait

    Posté par  . Évalué à 10.

    Je vois que certains postent des journaux mais ne lisent pas ceux des autres …
    Dans un précédent journal, il est dit que les dev de Archlinux consentent à conserver SysVInit, si il y a des volontaires pour le faire. Sinon, il y a aussi Archbang.

    Emacs le fait depuis 30 ans.

  • # Bof

    Posté par  . Évalué à 10.

    Franchement en faire tout un plat pour 3 parametres …

    C'est pas comme si toute la conf d'une arch tenait dans le rc.conf …

    Un fichier de conf pour 1 fonctionnalité ça se tient aussi question logique

  • # Et tu remplaces Arch Linux par quoi ?

    Posté par  . Évalué à 7. Dernière modification le 08 octobre 2012 à 21:24.

    Question bête, mais pas tant que cela… Comme tu sembles fuir les distros génériques, je me demande vers quoi tu vas migrer :
    - Debian : pas assez bleeding Edge par rapport à Arch.
    - Frugalware : trop tard, systemd inside.
    - Fedora : idem.
    - Gentoo : en 10 ans, j'ai eu un paquet d'avertissements comme ceux que tu mentionnes. Je n'en suis pas mort et mon système non plus. En plus, c'est pédagogique…
    - Ubuntu : c'est d'un commun…
    - OpenSuse : idem.
    - Wampas et des meilleures (désolé, je n'ai pas la nimage adéquate).

    Restent dans le désordre :
    - Slackware (pour combien de temps ?).
    - LFS.
    - *BSD.
    - Windows 8 (LOL).
    - Mac OS X (re-LOL mais moins depuis la sortie de cups 1.6 amputé de la directive BrowsePoll).

    Franchement, il ne faut pas exagérer. Non seulement, il n'y a que 3 malheureux fichiers de conf à retoucher mais en plus, le système a la gentillesse de te prévenir…

    • [^] # Re: Et tu remplaces Arch Linux par quoi ?

      Posté par  . Évalué à 2.

      Je n’ai trouvé aucune distro digne de Arch.

      C’est d’ailleurs tout le problème que j’ai : elle ne fonctionne bien que sur le desktop mais impossible de m’en passer.

      • [^] # Re: Et tu remplaces Arch Linux par quoi ?

        Posté par  . Évalué à 3.

        j'aimerai bien connaître les points qui la font déconseiller pour un serveur (à part l'aspect instable de rolling-release) ?
        je précise que c'est une vraie question :-)

        Envoyé depuis mon Archlinux

        • [^] # Re: Et tu remplaces Arch Linux par quoi ?

          Posté par  . Évalué à 5.

          Le premier c’est le nombre de paquet (impossible sous Arch de trouver Nagios, Icinga ou Shinken par exemple) :

          (root) |> ~ <| pacman -Sql core extra community | wc -l
          5654
          
          

          Mais y a d’autre soucis : la mise à jour du kernel inplace (qui oblige à rebooter tout de suite), les mises à jour kernel (linux-lts) toutes les 2 semaines quasiment (les VM je m’en fous mais les serveurs physiques, j’aime pas les rebooter trop souvent), ce genre de chose.

          C’est difficile de faire une liste, c’est surtout des problèmes qui arrivent à l’utilisation.

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  . Évalué à 4.

            Pour linux-lts, tu le mets dans HoldPkg dans /etc/pacman.conf et tu suis les sorties pour savoir quand des problèmes qui t'affectent vraiment (genre sécurité) requièrent une mise à jour et un redémarrage.

            Personnellement cette approche me plaît bien, surtout que je fais grosso modo la même chose avec les autres distributions.

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  . Évalué à 6.

            Pendant ce temps, sur les dépôts utilisateurs… nagios 3.4, icinga et shinken.

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  (site web personnel) . Évalué à 2.

            (impossible sous Arch de trouver Nagios, Icinga ou Shinken par exemple) :

            yaourt -S nagios
            yaourt -S icinga
            yaourt -S shinken

            Les 3 sont dans les dépôts utilisateurs, avec un bon score et des mises à jour récentes, j'imagine donc qu'ils sont fonctionnels.

            Pour le reste, je te rejoins, les mises à jour du noyau sont trop fréquentes, je ne vois pas trop pourquoi ils ne s'en tiennent pas aux mises à jour du noyau officiel, ou du moins pourquoi ils ne font pas au maximum une mise à jour intermédiaire.

            « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

            • [^] # Re: Et tu remplaces Arch Linux par quoi ?

              Posté par  (site web personnel) . Évalué à 6. Dernière modification le 09 octobre 2012 à 11:58.

              Pour le reste, je te rejoins, les mises à jour du noyau sont trop fréquentes, je ne vois pas trop pourquoi ils ne s'en tiennent pas aux mises à jour du noyau officiel

              Je ne connais rien à Arch mais je suppose que le paquet linux-lts est la version Long Term Support du noyau. Dans ce cas les mainteneurs Arch suivent simplement le rythme des mises à jour de Greg KH (effectivement environ une par semaine ).
              N'oublions pas qu'il y a des corrections de sécurité dans ces versions 3.x.y. On retrouve quasi-systématiquement la phrase rituelle : All users of the 3.x kernel series must upgrade.
              Donc ce n'est pas anormal pour une rolling distro de proposer ça.

              Est-ce que le paquet linux-lts est le seul disponible sur Arch ?

              • [^] # Re: Et tu remplaces Arch Linux par quoi ?

                Posté par  . Évalué à 4.

                Il y a aussi linux qui est actuellement à la version 3.5.6.

                Il existe également différentes saveurs dont le détail est donné sur le wiki : https://wiki.archlinux.org/index.php/Kernel

              • [^] # Re: Et tu remplaces Arch Linux par quoi ?

                Posté par  . Évalué à -2.

                Donc ce n'est pas anormal pour une rolling distro de proposer ça.

                À noté que je ne me plain pas du suivi upstream. Je disais simplement que ça rend Arch inutilisable sur un serveur.

                Par contre, pour ce qui est du changement inplace, là, oui, je me plains :)

                Est-ce que le paquet linux-lts est le seul disponible sur Arch ?

                Il y a deux paquets : linux (3.5.6) et linux-lts (3.0.44).

                D'autres noyaux sont compilables depuis AUR (qui n'est pas, quoi qu'en disent les gens de mauvaises foi, un dépôt utilisateur). Ce sont, pour la plupart, des noyaux avec des patch précis (comme grsec, p.ex.).

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  (site web personnel) . Évalué à 1.

            Mais y a d’autre soucis : la mise à jour du kernel inplace (qui oblige à rebooter tout de suite)

            Et pourquoi ça ? les kernels debian sont mis a jours 'inplace' eux aussi, c'est pas pour ça que je reboot "de suite".

            Sur un serveur le matos connecté ne bouge pas habituellement, tu peut meme supprimer le vmlinux + /lib/modules sans que ça dérange le système
            (bon le reboot suivant risque d'être compliqué par contre :)).

        • [^] # Re: Et tu remplaces Arch Linux par quoi ?

          Posté par  . Évalué à 5.

          Déjà l'aspect rolling ce n'est pas anecdotique, bien au contraire. Je ne dis pas que c'est mal, mais ça peut réserver des surprises.

          Ensuite le problème c'est justement que ça va trop vite pour des softs tiers qui ne peuvent ne plus fonctionner après mise à jour car incompatibles.

          De plus, les mises à jour sont plutôt gourmandes en bande passante, un rebuild de lib et tu es parti pour réinstaller la moitié de ta distrib.

          Et des confs qui périment très vite car les mises à jour de versions majeures arrivent plus souvent, tu es toujours à mettre à jour les configs de tes softs.

          Même moi qui aime bien le bleeding edge et le rolling, j'ai laissé tombé pour les serveurs.

        • [^] # Re: Et tu remplaces Arch Linux par quoi ?

          Posté par  . Évalué à 8.

          j'aimerai bien connaître les points qui la font déconseiller pour un serveur (à part l'aspect instable de rolling-release) ?

          La réponse est dans la question :-)

          Arch est une très bonne distribution donc l'aspect instable est à mon avis la seule raison, mais c'est une raison majeure. Un serveur n'a pas les mêmes besoins qu'un desktop, notamment sur les domaines de sécurité et de fiabilité.

          Pour la sécurité c'est évident : s'il est allumé et héberge des services actifs en permanence, il a besoin que ces derniers soient blindés. Tu n'es pas dessus en permanence, et un système de supervision ne suffit pas toujours. Et pour le peu que certains services soient sur internet, tu n'as pas le droit à l'erreur.

          Mais comment veux-tu blinder un serveur dont les logiciels évoluent sans cesse ? Tu ne peux jamais être sûr qu'une nouvelle version n'apporte pas une faille, ou n'aggrave pas une faille existante ? Et ça n'est pas forcément une question de bug, ça peut venir d'un changement de comportement ou d'un changement de dépendance.

          Et c'est pareil pour la fiabilité : sur un desktop, on peut tolérer quelques bugs et ralentissements ici et là, mais sur un serveur c'est plus visible car ça peut empêcher tout son fonctionnement et tu n'as pas forcément la main dans l'immédiat pour corriger le problème (quand tu peux agir directement sur un desktop vu que tu es dessus).

          Et là c'est pareil : une nouvelle version ne va pas forcément corriger tes bugs tout en t'en amenant de nouveaux.

          Avec une distribution stable (au sens des versions), les mises à jour n'apportent que des correctifs de bugs ou de failles : pas de nouveau code structurel, pas de changement de comportement, pas de nouvelles erreurs.

          Bien sûr, on ne peut pas te garantir que ces correctifs n'apportent pas d'autres problèmes, mais c'est très largement minime par rapport au risque d'une nouvelle version (avec un nouveau packaging qui peut également apporter ses problèmes, comme des mauvaises dépendances). Surtout que les bonnes distributions comme Debian fournissent un système de suivi très complet.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  . Évalué à 1.

            • Pour un serveur perso Arch Linux ça tient la route
            • Pour le côté stabilité faudrait suivre ArchServer vu que c'est encore en développement
            • Il y a aussi la page de wiki sur les serveurs
            • Ça fait plus de 6 mois que j'ai mon serveur perso et j'ai du faire deux changements (lors du changement de l'emplacement des fichiers de conf de Nginx et le passage à PHP 5.4), et au pire avec les flux RSS du site officiel + suivre ce qu'on te dit lors des mises à jour, ça casse pas trois pattes à un canard.
            • Redémarrage pas obligatoiro comme dit au-dessus, après les mises à jour noyau sont pas toutes critiques, une mise à jour toutes les deux semaines c'est suffisant… Bref, je conseillerais pas à tous le monde mais ça tourne bien.

            Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Et tu remplaces Arch Linux par quoi ?

      Posté par  (site web personnel) . Évalué à 2.

      Linux mint c'est pas mal. J'ai été étonné de voir qu'ils suivaient les évolutions de par exemple Firefox, proposant des mises à jour régulières des dernières versions (par exemple la 15 en ce moment), même avec une base de distribution vieille de 6 mois et sans tout mettre à jour.

      Je l'ai installé chez mon père, ça tourne bien, sans mauvaise surprise.

      Pour le moment je lorgne du côté de BSD, quitte à apprendre de nouvelles choses, au moins c'est plus enrichissant que des technologies qui me tapent sur le système. Je garde mon archlinux pour le moment, le temps de la transition, en tout cas c'est clair que je ne vais plus installer un système neuf en Arch à l'avenir. Tant pis.

      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

      • [^] # Re: Et tu remplaces Arch Linux par quoi ?

        Posté par  . Évalué à 1.

        Pour le moment je lorgne du côté de BSD

        Et y a-t-il une variante de BSD avec un système de paquets qui tienne la route, pour la gestion des dépendances, mais aussi des mises à jour ?

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Et tu remplaces Arch Linux par quoi ?

          Posté par  . Évalué à 3.

          pkgin, qui a commencé à faire parler de lui en 2009, est utilisé sous NetBSD, DragonFly.
          Sous FreeBSD, plus récemment, la suite pkg(ng) dont la v1 est arrivée il y a un peu plus d'un mois. Peut-être encore un peu jeune mais très prometteur.

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  (site web personnel) . Évalué à 2.

            Intéressant pkg(ng), vivement que ça soit généralisé.

            Et sous PCBSD, AppCafe est très pratique et convivial à utiliser. En plus il y a un créateur de paquets au format PBI, semi-automatisé, à partir de l'arbre des ports.

            « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: Et tu remplaces Arch Linux par quoi ?

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            pkgin, qui a commencé à faire parler de lui en 2009, est utilisé sous NetBSD, DragonFly.
            Sous FreeBSD, plus récemment, la suite pkg(ng) dont la v1 est arrivée il y a un peu plus d'un mois. Peut-être encore un peu jeune mais très prometteur.

            Et il ne faut pas non plus oublier OpenBSD, qui prend en compte les paquets binaires et leur mise à jour.

            • [^] # Re: Et tu remplaces Arch Linux par quoi ?

              Posté par  (site web personnel) . Évalué à 4.

              Et il ne faut pas non plus oublier OpenBSD, qui prend en compte les paquets binaires et leur mise à jour.

              Mouais. C'est vrai mais OpenBSD ne produit pas de paquets stables, seulement pour les releases (et j'ai du mal à croire à un php pas troué pendant 6 mois). Tu devras compiler toi même (ou avoir une ferme de paquet pour les construire) à un moment ou un autre.

              FreeBSD pas mieux, on a un outil pour gérer les paquets (pkgng qui est un superbe travail) mais pas de paquets…
              À mon avis ça va prendre un bout de temps (au moins deux ans) pour avoir des paquets cohérents entre eux (quand je dis cohérent par exemple si on supporte IPV6, tous les paquets devraient avoir l'option ipv6 à "on"; ou ldap pour l'authentification (postfix, etc)). La conséquence c'est qu'on va avoir plein de trucs installés qui ne servent pas forcément (et ça ne va pas plaire à tout le monde). Tout ça pour avoir la joie de faire un "pkg upgrade" (et c'est quand même vraiment la joie, merci Baptiste & co). Bref on va devoir produire nos paquets nous même pour un moment (poudriere est cool pour ça) même si il y a un gros progrès.

              les pixels au peuple !

      • [^] # Re: Et tu remplaces Arch Linux par quoi ?

        Posté par  (site web personnel) . Évalué à 4.

        J'ai été étonné de voir qu'ils suivaient les évolutions de par exemple Firefox,
        proposant des mises à jour régulières des dernières versions

        Mwai, enfin c'est Canonical qui fait cela hein ;)

        http://packages.ubuntu.com/precise-updates/firefox

      • [^] # Re: Et tu remplaces Arch Linux par quoi ?

        Posté par  . Évalué à -1.

        C'est vrai que linux mint fait un boulot extraordinaire en repackageant une distrib, en ajoutant un plugin gnome-shell et en changeant le fond d'écran par défaut en un truc vert pastel [/ironie]

    • [^] # Re: Et tu remplaces Arch Linux par quoi ?

      Posté par  (site web personnel) . Évalué à 3.

      • Debian : pas assez bleeding Edge par rapport à Arch.

      avec un petit coup de pinning je trouve ça bien stable.

  • # bien

    Posté par  . Évalué à 9. Dernière modification le 08 octobre 2012 à 22:28.

    Archlinux est censée être en avance sur les autre distros, alors, il faut être heureux qu'elle ait rattrapé son retard sur les fichiers de conf.

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Tu n'es pas le centre du monde

    Posté par  (site web personnel) . Évalué à 6.

    je considère que Archlinux n’est plus

    Archilinux est, et sera, ce n'est pas quand quelques personnes râlent sans se bouger (rappel : il y a un journal sur la recherche de mainteneur, tu n'as pas l'air très motivé…) et disent qu'à cause de ce changement (celui-ci mais aussi des milliers d’autres avant) il quitte le navire (ce qu'il fait rarement) ou que le projet est mort (ce qui est fort rare, au contraire même) qu'il ne faut pas avancer, sinon on avance jamais.

    Archlinux est juste… Vivante, au contraire du titre de ton journal.


    Finalement, ce qui est rigolo, c'est de voir les mêmes résistances aux changements, les mêmes tirades d'utilisateurs pas content parce que x ou y est que c'est mort maintenant, de le voir… Sur tous les projets. Si on écoute tous les gens, tous les projets seraient morts!

    • [^] # Re: Tu n'es pas le centre du monde

      Posté par  . Évalué à -10.

      rappel : il y a un journal sur la recherche de mainteneur, tu n'as pas l'air très motivé…

      Rappel : pour être motivé, il faut avoir les compétences.

      Archlinux est juste… Vivante, au contraire du titre de ton journal.

      Non, Archlinux, non.

      Pour ce qui est de la pseudo-distro avec ça configuration décentralisé, ces 6000 paquets, son installateur « à la bite et au couteau », là, oui, je te l’accord, elle est vivante celle là.

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 10.

        Rappel : pour être motivé, il faut avoir les compétences.

        Si tous les gens compétents au sein de la distribution (et des autres) font ce choix, il faut s'y résoudre.
        De plus, on ne peut forcer au sein d'un projet d'avoir ta vision des choses et de forcer des gens à faire ce qu'ils n'ont pas envie alors qu'ils ne sont pas pour la plupart payés (et même pas par toi).

        Non, Archlinux, non.

        Car les utilisateurs non contributeurs savent mieux que quiconque ce que doit accepter ou non le projet ? Je veux bien comprendre qu'une distribution comme Mandriva ou un logiciel comme OpenOffice.org se sont tirés une balle dans le pied, mais Archlinux fait un choix cohérent, réfléchi et qui ne nuit pas à sa philosophie. Les technologies évoluent et c'est bien de l'accepter parfois. Surtout qu'en général c'est assez peu argumenté techniquement sur les méfaits de ces changements.

        Pour ce qui est de la pseudo-distro avec ça configuration décentralisé, ces 6000 paquets, son installateur « à la bite et au couteau », là, oui, je te l’accord, elle est vivante celle là.

        Je te signale qu'il y a beaucoup d'admins systèmes et distributions qui trouvent cela justement pratique et agréable. Ta vision n'est pas partagée par les responsables de ces projets, donc soit ta vision des choses est biaisée, ou alors il faudrait que vous fassiez votre propre projet. Je trouve toujours cela marrant que des non contributeurs puissent se montrer si critique et manquer de recul vis à vis de telles décisions qui ne sont jamais forcées.

        • [^] # Re: Tu n'es pas le centre du monde

          Posté par  . Évalué à -1.

          Car les utilisateurs non contributeurs savent mieux que quiconque ce que doit accepter ou non le projet ?

          C’est très marrant le clivage développeurs/utilisateurs, j’avoue…

          Les technologies évoluent et c'est bien de l'accepter parfois.

          Oui oui, toujours le même argument : tu refuses certains changements = tu refuses totalement le changement.

          Je te signale qu'il y a beaucoup d'admins systèmes et distributions qui trouvent cela justement pratique et agréable. Ta vision n'est pas partagée par les responsables de ces projets

          Et maintenant l’argument d’autorité.

          Je te signale qu’il y a des gens qui utilisent Plan9 et qui trouvent cela justement pratique et agréable. Est-ce que ça rend les choix des développeurs Plan9 meilleurs que ceux des développeurs Arch ?

          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  (site web personnel) . Évalué à 3.

            C’est très marrant le clivage développeurs/utilisateurs, j’avoue…

            Dans le Logiciel Libre, l'utilisateur n'a aucun pouvoir pour que le logiciel change, sauf s'il devient développeur à son tour.

            Oui oui, toujours le même argument : tu refuses certains changements = tu refuses totalement le changement.

            Oui car systemd, comme d'autres technologies, sont souvent critiqués sur des bases de philosophie informatiques fumeuses et rarement avec des arguments techniques intéressants. Au contraire, systemd répond à de nombreuses problématiques, que tout le monde passe sous silence, et suffisamment pour que les distributions l'adoptent volontairement (et donc sans contrainte).

            Je te signale qu’il y a des gens qui utilisent Plan9 et qui trouvent cela justement pratique et agréable. Est-ce que ça rend les choix des développeurs Plan9 meilleurs que ceux des développeurs Arch ?

            Plan 9 et ArchLinux ne sont pas basés sur la même chose, Plan 9 est un projet de recherche qui pousse certains concepts plus loin que Unix, en profitant notamment des évolutions matérielles depuis. Je suis sûr que les développeurs de Windows et Mac OS X sont bons, indépendamment de la qualité du système, car ils font avec les moyens du bord et que la programmation de ce niveau demande de grandes compétences.
            Les gens qui font ces choix techniques ne sont pas des abrutis, ils sont là grâce à leur expérience et compétences après des années de collaboration pour certains, je fais confiance à ce type d'individus, surtout qu'ils mettent en avant des arguments techniques pour ce choix contrairement aux détraqueurs…

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  . Évalué à 3.

              Oui car systemd, comme d'autres technologies, sont souvent critiqués sur des bases de philosophie informatiques fumeuses et rarement avec des arguments techniques intéressants. Au contraire, systemd répond à de nombreuses problématiques, que tout le monde passe sous silence, et suffisamment pour que les distributions l'adoptent volontairement (et donc sans contrainte).

              Avant systemd : un système de scripts System5 simple à comprendre :
              - /etc/init.d/monscript start
              /etc/init.d/monscript stop
              /etc/init.d/monscript status
              - un lien dans /etc/rcN.d vers le script en question avec tous les scripts qui commencent par K pour arret, et S pour start et un chiffre indiquant l'ordre de démarrage.

              Aujourd'hui, avec systemd : un tas de fichiers de conf dans tous les sens avec des liens partout, dans lesquels on ne comprend pas grand chose. Il suffit de lire le dernier linux mag pour se faire une idée de l'horreur (ça m'a donné envie de vomir ce truc). On en arrive à un truc immonde ressemblant d'assez près aux services Windows. On perd un certain contrôle par rapport à la simplicité de System5 tout ça pour gagner quelques secondes au démarrage.

              Pour un desktop, à la limite, pourquoi pas, mais pour un serveur, non merci.

              Là je vois juste un changement pour le changement, rien d'autre. Je suis prêt à changer d'avis, mais pour l'instant les arguments en faveur de SystemD ne m'ont pas convaincus. Si tu en as je suis preneur.

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  (site web personnel) . Évalué à 6.

                On perd un certain contrôle par rapport à la simplicité de System5 tout ça pour gagner quelques secondes au démarrage.

                Arrêtez avec cette histoire de temps de démarrage, c'est ridicule car ce n'est qu'une conséquence de l'architecture de systemd et non le but voulu à la base.
                Tu peux trouver pas mal de personnes qui expliqueront ses possibilités et te diront que c'est confortable dans de très nombreux cas.

                Mais merci d'arrêter ce fud sur systemd, croire que c'est pour gagner du temps au démarrage montre que vous ne connaissez pas systemd en fait et que du coup votre argumentation contre lui est biaisé (oui quand on ignore 95% des possibilités d'un logiciel, on ne peut se permettre de le critiquer sur le sujet…).

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  . Évalué à 0.

                  Arrêtez avec cette histoire de temps de démarrage, c'est ridicule car ce n'est qu'une conséquence de l'architecture de systemd et non le but voulu à la base.

                  Quel est donc le but voulu alors ?

                  Tu peux trouver pas mal de personnes qui expliqueront ses possibilités et te diront que c'est confortable dans de très nombreux cas.

                  Je veux des exemples. Pour l'instant les personnes qui me l'ont expliqué ne m'ont pas convaincues.

                  Mais merci d'arrêter ce fud sur systemd, croire que c'est pour gagner du temps au démarrage montre que vous ne connaissez pas systemd en fait et que du coup votre argumentation contre lui est biaisé (oui quand on ignore 95% des possibilités d'un logiciel, on ne peut se permettre de le critiquer sur le sujet…).

                  Si ces 95% de possibilités sont inutiles, ….

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  . Évalué à 2.

                    Si ces 95% de possibilités sont inutiles, ….

                    Qui te dit que ce sont les mêmes 95% pour tout le monde ?

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  (site web personnel) . Évalué à 6.

                    Quel est donc le but voulu alors ?

                    avoir un système intégré.

                    Par exemple, je crois pas qu'on puisse dire avec les scripts actuelles "tu lances tel truc avec tel limitation sur le fs, ou sur le réseau" ( http://0pointer.de/blog/projects/security.html ). Je pense pas que les systèmes courants permettent de faire des templates de scripts de lancement (autrement qu'en faisant un gros cut and paste crade ) comme décrit ici http://0pointer.de/blog/projects/instances.html . ( oui, gentoo le fait, mais c'est bien les seuls ).

                    Tu as aussi des tas de softs avec des soucis moisis. Par exemple, comme je le dit à chaque fois, bind requiert d'attendre pour se relancer car il utilise un mécanisme de communication asynchrone, donc stop/start, ça peut ne pas marcher. Sympa a plus d'une fois bloqué le boot d'un serveur dont je m'occupais car il a besoin que postgresql (dans le cas de la config du serveur) soit lancé et disponible, chose qui n'arrive pas toujours, et dépendance qu'on ne peux pas exprimer avec les systèmes classiques ( sauf à mettre des workarounds du style "je vais attendre 5 secondes pour rien" )

                    On peut aussi dire ce qu'on veut, c'est plus simple et plus propre d'avoir un fichier de 10 lignes qu'un script de 100. Aussi bien à écrire pour les packageurs, qu'à relire pour l'admin. Rien que la facilité et le fait de pouvoir le déposer upstream mérite le coup ( car bien sur l'admin moyen ne voit pas le coup de maintenance du script, vu qu'il n'a pas à la faire ).

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  . Évalué à 4.

                    Tu peux trouver pas mal de personnes qui expliqueront ses possibilités et te diront que c'est confortable dans de très nombreux cas.

                    Je veux des exemples. Pour l'instant les personnes qui me l'ont expliqué ne m'ont pas convaincues.

                    Tu peux commencer par ça : https://linuxfr.org/news/%C3%A9volutions-techniques-de-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: Tu n'es pas le centre du monde

                Posté par  . Évalué à 5.

                Avant systemd : un système de scripts System5 simple à comprendre :
                - /etc/init.d/monscript start
                /etc/init.d/monscript stop
                /etc/init.d/monscript status
                - un lien dans /etc/rcN.d vers le script en question avec tous les scripts qui commencent par K pour arret, et S pour start et un chiffre indiquant l'ordre de démarrage.

                Un système simple, soit, mais souvent de scripts complexes. C'est pas toujours facile de gérer les dépendances entre services. L'ordre d'appel des scripts ne suffit pas toujours. Par exemple un SGBD qui doit être démarré avant les autres services mais qui prend des plombes, faut faire un sleep dans le script c'est crade.

                systemd me semble, je vois ça de loin, pas testé, plus homogène.

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  . Évalué à 0.

                  un SGBD qui doit être démarré avant les autres services mais qui prend des plombes, faut faire un sleep dans le script c'est crade.

                  ??? En quoi SystemD règle-t-il ce problème ? Et si le script de démarrage du SGBD rend la main avant que le SGBD ne soit démarré, ne serait-ce pas plutot le script de démarrage de SGBD qu'il faudrait réécrire plutot que l'ensemble du process de démarrage du système ?

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  . Évalué à 2.

                    ne serait-ce pas plutot le script de démarrage de SGBD qu'il faudrait réécrire plutot que l'ensemble du process de démarrage du système

                    Bah non, pour éviter d'avoir à modifier les scripts de chaque services justement ?

                    Enfin bon, je vais arrêter de parler dans le vent. Je ne connais pas assez systemd. En espérant que quelqu'un d'autre puisse te répondre plus précisément.

                    • [^] # Re: Tu n'es pas le centre du monde

                      Posté par  . Évalué à 1.

                      GNI ? Tu voudrais donc que systemd te permette d'écrire tes scripts de démarrage comme un goret et de mettre en place des services pourris ? C'est bien ce que je dis, les gens qui veulent ça veulent un windows.

                      Plutot que de casser un GNU/linux, pourquoi ne pas redévelopper un widows libre ?

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  . Évalué à 2.

                        Ce que je veux c'est que le démon qui gère le démarrage des services soit capable de dire : ne démarre pas ce service si celui là n'a pas finit de démarrer. Et ce, sans faire un test en shell dans le script d'init du démon.

                        C'est bien ce que je dis, les gens qui veulent ça veulent un windows.

                        Bof. Il veulent un GNU/Linux, pas forcément un système bien POSIX à l'ancienne. Debian garde l'init SysV à cause de kfreebsd, presque toutes les autres grandes distro sont passées à systemd. Mais toi tu sais mieux que tout le monde ce qui est bien c'est ça ?

                        Il y a freeBSD aussi, si GNU/Linux ne te plaît plus.

                        pourquoi ne pas redévelopper un widows libre ?

                        Ça existe déjà : http://www.reactos.org/fr/index.html

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 2.

                          Ce que je veux c'est que le démon qui gère le démarrage des services soit capable de dire : ne démarre pas ce service si celui là n'a pas finit de démarrer. Et ce, sans faire un test en shell dans le script d'init du démon.

                          Les entêtes LSB, tu connais ? C'est pas comme si c'était tout récent…

                          Et pour le coup de savoir si un service est démarré, désolé mais c'est de la responsabilité du service. Ce n'est pas simplement en regardant si une socket est ouverte que l'on sait si un service est près à être utilisé. Dans certains cas, un service ne peut pas savoir s'il est démarré ou pas, et on doit mettre des timeout foireux pour que ça colle dans un modèle de dépendance classique. Ce n'est pas un système d'init tel qu'ils soit qui va résoudre le problème.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 1.

                            Et pour le coup de savoir si un service est démarré, désolé mais c'est de la responsabilité du service. Ce n'est pas simplement en regardant si une socket est ouverte que l'on sait si un service est près à être utilisé.

                            Exactement. Je n'ai pas encore vu un seul argument dans cette discussion ou ailleurs qui me prouveront le contraire.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 2.

                            Les entêtes LSB, tu connais ? C'est pas comme si c'était tout récent…

                            C'est tout de même sacrément moche et bien fragile comme mécanisme.

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 3.

                            Les entêtes LSB, tu connais ? C'est pas comme si c'était tout récent…

                            C'est quand même un gros hack qu'on a fait pour éviter justement de faire évoluer l'existant en profondeur.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 1.

                          Ce que je veux c'est que le démon qui gère le démarrage des services soit capable de dire : ne démarre pas ce service si celui là n'a pas finit de démarrer. Et ce, sans faire un test en shell dans le script d'init du démon.

                          En quoi systemd répond à ça ? Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la faute au système de démarrage, mais au service en lui même.

                          Debian garde l'init SysV à cause de kfreebsd, presque toutes les autres grandes distro sont passées à systemd. Mais toi tu sais mieux que tout le monde ce qui est bien c'est ça ?

                          Je sais très bien ce qui est bien ou pas sur un serveur dans la mesure ou c'est mon job. Je sais très bien ce que donne ce genre de truc immonde pour avoir à gérer ce genre d'horreur sous Windows.

                          Il y a freeBSD aussi, si GNU/Linux ne te plaît plus.

                          Pour maoi ça va, ya longtemps que je suis sous NetBSD, et je ne gardais Linux que sur un portable (qu'on m'a volé hélas). A la limite ce genre de truc ne me gène pas trop sur un desktop, mais sur un serveur non merci. Et aujourd'hui, les xBSD ne sont pas légion dans le monde pro …

                          Ça existe déjà : http://www.reactos.org/fr/index.html

                          Ben faudrait demaner au guignol responsable de cette horreur de nous ficher la paix et d'aller développer dessus, il s'amuserait comme un fou.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 5.

                            En quoi systemd répond à ça ?

                            http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

                            ce n'est pas la faute au système de démarrage, mais au service en lui même.

                            [gnumdk@arch ~]$ grep sleep /etc/rc.d/*|wc -l                                                                   
                            37
                            
                            

                            Ben, doit y en avoir des services codés par des incompétents…

                            • [^] # Re: Tu n'es pas le centre du monde

                              Posté par  . Évalué à 2. Dernière modification le 10 octobre 2012 à 13:22.

                              L'exemple du sleep est mal choisi. En attendant, sur une Squeeze je suis obligé de (re)démarrer snort et bacula (qui utilisent postgres) dans rc.local si je veux être sûr qu'ils soient bien démarrés au boot.

                              • [^] # Re: Tu n'es pas le centre du monde

                                Posté par  . Évalué à 0.

                                Si le démon postgress rend la main au script avant d’être opérationnel, c’est un problème de postgress. Je suis sûr qu’il y a un tracker de bug quelque part.
                                Sinon, si le démon est lancé par le script en tâche de fond (&) alors c’est un bug du script d’init. Mais ce n’est pas la faute du système de démarrage. En plus ton contournement pourrait ne pas marcher si le boot allait plus vite ou autre… pas très safe comme méthode.

                                • [^] # Re: Tu n'es pas le centre du monde

                                  Posté par  . Évalué à 2. Dernière modification le 10 octobre 2012 à 14:16.

                                  c’est un problème de postgres

                                  .

                                  si le démon est lancé par le script en tâche de fond (&) alors c’est un bug du script d’init

                                  C'est bien ce que je disais. Avec la méthode actuelle c'est à chaque application de gérer ça. Si on a un système d'init qui peut s'en occuper ça évite aux développeurs (ou aux packagers) de chaque application de s'en occuper, les laissant ainsi bosser sur le cœur de l'application, non ?

                                  • [^] # Re: Tu n'es pas le centre du monde

                                    Posté par  . Évalué à -1.

                                    Le cas que tu as retenu est de lancer un démon dans un script ainsi :

                                    #!/bin/bash
                                    
                                    case "$1"
                                    start)
                                    demon -mon_option &
                                    ;;
                                    …
                                    
                                    

                                    On est d’accord que c’est de l’incompétence de la personne qui a écrit le script. Dans l’exemple ci dessous le démon est lancé comme dans mon cas 1.

                                    Ce que je voudrais, c’est que tu m’expliques comment dans le cas 1, puisque le cas 2 est impossible, systemd est mieux que un script d’init. Comment systemd après avoir démarrer le démon, et que celui-ci rend la main, sait-il si oui ou non le service est fonctionnel ?
                                    Explique moi comment ça empêchera d’avoir une tempo, ou un redémarrage pour bacula dans ton cas.

                                    • [^] # Re: Tu n'es pas le centre du monde

                                      Posté par  (site web personnel) . Évalué à 3.

                                      Comment systemd après avoir démarrer le démon

                                      Je vais pas poster mon lien sur les "sockets activations" tous les 3 commentaires…

                                      • [^] # Re: Tu n'es pas le centre du monde

                                        Posté par  . Évalué à 2.

                                        Ce à quoi il va répondre que ce n'est pas parce qu'il écoute la socket qu'il est prêt.

                                        Peut être mais il peut tout de même recevoir des requêtes qui iront s'entasser dans un buffer (jusqu'à ce que ce dernier pète on est d'accord).

                                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                        • [^] # Re: Tu n'es pas le centre du monde

                                          Posté par  . Évalué à 3.

                                          Certains services peuvent écouter la socket dès le départ, mais te jeter (genre pour un serveur HTTP, te renvoyer un 503 Temporarily unavailable) tant qu'il n'est pas prêt (par exemple, tant qu'il n'est pas connecté à un service distant). Socket activation ou pas, buffer ou pas, ce n'est pas un système d'init qui sera capable de te dire si un service est démarré et prêt à être utilisé.

                                      • [^] # Re: Tu n'es pas le centre du monde

                                        Posté par  . Évalué à 1.

                                        On s’éloigne de ce dont on parle. Je vais te resituer le débat.
                                        Totof2000 à écrit :

                                        En quoi systemd répond à ça ? Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la faute au système de démarrage, mais au service en lui même.
                                        
                                        

                                        gnumdk à répondu :

                                        http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation
                                        
                                        

                                        Signifiant (j’ai la flemme de traduire) :

                                        Socket activation
                                        
                                        Socket activation occurs when a service allows systemd to listen for connections to a specific socket and, when systemd receives a connection on that socket, it starts the service. To do this, the upstream source needs to have some minor coding work to let systemd listen for connections on the socket and there needs to be a .socket file in %{_lib}/systemd/system/ that tells systemd to listen to that socket and what to start when a connection is received. This is similar in function to inetd and some, but not all, services coded to work with inetd will work with socket activation. Simila to inetd, using socket activation for on-demand loading will impose a startup time penalty so we currently do not use this feature in Fedora.
                                        
                                        However, socket activation can also be used to allow parallel startup of services. If a service supports systemd socket activation as described above and we additionally start it explicitly on boot, then systemd will start it but allow things that depend on it to startup at the same time. If the dependent service makes a request to the socket activatable service before it has come up, then systemd will cause the request to wait until the socket activatable service has come up and can process the request. To achieve this effect, the service must be socket activatable as described above, the .service file for the service needs to have a Wants= line for the .socket, and the service must autostart. Since Fedora currently doesn't want any services to do on-demand loading, all socket activated services must autostart.
                                        
                                        In practical terms this means if the upstream tarball ships with a socket file you need to contact FESCo to get permission to enable your service on boot. Once you have permission, you can package the .socket file and use the systemd scriptlets that enable the service by default. You need to also check the .service file to make sure it has a Wants= entry on the .socket file as that ensures that starting the service will also inform systemd of the socket. 
                                        
                                        

                                        Marotte a ajouté :

                                        L'exemple du sleep est mal choisi. En attendant, sur une Squeeze je suis obligé de (re)démarrer snort et bacula (qui utilisent postgres) dans rc.local si je veux être sûr qu'ils soient bien démarrés au boot.
                                        
                                        

                                        /Me a répondu (Je retire le cas 2 qui était en fait une boutade) :

                                        Si le démon postgres rend la main au script avant d’être opérationnel, c’est un problème de postgres. 
                                        
                                        

                                        Marotte a sauté sur l’occasion pour pourrir les scripts du cas 2 mais sans répondre à la vrai interrogation (vois ci-dessus) :

                                        /Me a précisé que le cas 2 était un fake, et demandé :

                                        Ce que je voudrais, c’est que tu m’expliques comment dans le cas 1, (…), systemd est mieux que un script d’init. Comment systemd après avoir démarrer le démon, et que celui-ci rend la main, sait-il si oui ou non le service est fonctionnel ?
                                        
                                        

                                        gnumdk me prend de haut, sans répondre à la question :

                                        Je vais pas poster mon lien sur les "sockets activations" tous les 3 commentaires…
                                        
                                        

                                        Je passe sur l’humour de Michel qui n’apporte rien au débat.

                                        En attendant, je n’ai toujours pas compris comment systemd va permettre à Marotte de ne pas avoir à redémarrer bacula si postgress rend la main à systemd. Je ne vois pas comment systemd peut faire mieux qu’un script.
                                        Quelqu’un aurait-il assez de patience pour m’expliquer ?

                                        • [^] # Re: Tu n'es pas le centre du monde

                                          Posté par  . Évalué à 7.

                                          Avec systemd ca se passe comme ca :
                                          - systemd crée la socket utilisée par postgresql au tout début
                                          - démarrage de postgresql et de tout ce qui en dépend, en parallèle
                                          - bacula ou autre service utilisant postgresql démarre et tente de communiquer avec postgresql en ouvrant sa socket. Pas d'erreur, la socket est la, puisque crée par systemd. Le kernel bufferise ce qui arrive sur la socket en attendant que quelqu'un lise dessus.
                                          - postgresql démarre, commence à lire ce qui est a été bufferisé sur la socket, et y répond

                                          Avec un system d'init qui ne crée pas les socket :
                                          - démarrage de postgresql, fork. la main est rendue au system d'init, qui passe au démarrage du service suivant.
                                          - postgresql commence à lire sa conf, ses données, et quelques operations qui prennent du temps
                                          - démarrage de bacula, et tentative d'ouverture de la socket => erreur, la socket n'existe pas, postgresql n'a pas encore eu le temps de la créer => bacula quitte avec une erreur
                                          - postgresql qui a fini de lire sa conf, ouvre sa socket et commence à écouter dessus, mais c'est trop tard pour bacula

                                          Plus de details la :
                                          http://0pointer.de/blog/projects/systemd.html

                                          • [^] # Re: Tu n'es pas le centre du monde

                                            Posté par  . Évalué à 1.

                                            Merci d’avoir répondu à ma question. Je pense quand même qu’un démon devrait répondre quand il est prêt.
                                            Ex :

                                            lanceur 
                                               |
                                               ->  démon
                                                     |
                                                    fork ------
                                                père |        | fils
                                                     |      lit la conf
                                                     |        |
                                                     |      bricole (un certain temps)
                                                     |        |
                                                     |      est prêt
                                                     |        |
                                                     |      Se détache du père et préviens qu’il peut terminer
                                              se termine <----|
                                                     |        |
                                               |------        |
                                               V              | (continue sa vie)
                                            lanceur
                                            démarre
                                            service
                                            suivant
                                            
                                            

                                            Y a-t-il une raison de ne pas démarrer un démon comme ci-dessus ? Après tout, si un service prend son temps pour démarrer, ça n’impacte que les services qui en dépendent. Un démarrage en parallèle, ne devrait pas ralentir tant que ça.

                                            • [^] # Re: Tu n'es pas le centre du monde

                                              Posté par  . Évalué à 1.

                                              Ca serait possible, mais c'est assez compliqué à faire bien, et aurait besoin d'etre fait dans chaque démon. Et puis ca nécessite de gérer manuellement les dépendances, en listant tout ce qui a besoin de postgresql. Avec systemd il n'y a pas à gerer ces dépendances, on doit lui dire que postgresql utilise une socket, mais c'est tout, on a pas besoin de lui dire qu'un service va utiliser postgresql.

                                              La facon dont le fait systemd permet aussi, si on lui demande, de ne démarrer le démon que si quelqu'un tente de l'utiliser.

                                              • [^] # Re: Tu n'es pas le centre du monde

                                                Posté par  . Évalué à 1.

                                                Ca serait possible, mais c'est assez compliqué à faire bien, et aurait besoin d'etre fait dans chaque démon.

                                                Bah oui, comme chaque programme fait attention à ne pas faire de bug. C’est un choix de conception du démon ou un bug. Je trouve louche que tu me dises c’est compliqué a bien faire, alors on laisse le système de démarrage palier à notre problème de conception…
                                                Et pour répondre à un message de grumk un peu plus bas, ce n’est pas parce que tout le monde fait ça que c’est la meilleur solution. Sinon, on taillerait encore les branches avec des silex.

                                                Et puis ca nécessite de gérer manuellement les dépendances, en listant tout ce qui a besoin de postgresql.

                                                En quoi c’est manuel, prenons le cas openrc, tu as une fonction qui donne les dépendances dont tu as besoin. Donc openrc démarre d’abord tes dépendances avant de te démarrer. Ne me dit pas que systemd palie tout seul à ça, puisque à moins qu’il bind tous les ports sur toute les interfaces, il faut bien lui spécifier quelques part. Pour systemd c’est dans la config de postgres que tu dis qu’il utilise tel port… alors qu’avec openrc c’est dans la config de bacula que tu dis qu’il a besoin de postgres. Oui, j’admets qu’il faut écrire dépend de postgres une fois par service l’utilisant dans un cas. Mais est-ce si compliqué ?

                                                Avec systemd il n'y a pas à gerer ces dépendances, on doit lui dire que postgresql utilise une socket, mais c'est tout, on a pas besoin de lui dire qu'un service va utiliser postgresql.

                                                Effectivement. Mais comme je répond au dessus, est-ce compliqué ou long à faire ?

                                                La facon dont le fait systemd permet aussi, si on lui demande, de ne démarrer le démon que si quelqu'un tente de l'utiliser.

                                                Ça inet le faisait. Mais dans ce cas le service ne pouvait pas être lancé en mode démon ce qui semble le cas pour systemd ce qui est un avantage à ce dernier.

                                                Je comprend mieux certains aspect, mais je pense quand même que systemd fait trop de chose. Qui vivra verra.

                                                • [^] # Re: Tu n'es pas le centre du monde

                                                  Posté par  . Évalué à 2.

                                                  Je trouve louche que tu me dises c’est compliqué a bien faire, alors on laisse le système de démarrage palier à notre problème de conception…

                                                  Avec des remarques comme ca on serait tous en train de coder en assembleur … Quoi ? Utiliser un language de haut niveau, sous pretexte que c'est compliqué à écrire en assembleur ?

                                                  Y a aucun interet à garder un truc compliqué juste pour le plaisir. Si il y a un moyen de simplifier la création des programmes ca me semble une bonne chose. Surtout que tu ne donnes aucune raison de pas le faire, à part "c'est le demon qui devrait le faire". Pourquoi ?

                                                  Ne me dit pas que systemd palie tout seul à ça, puisque à moins qu’il bind tous les ports sur toute les interfaces, il faut bien lui spécifier quelques part.

                                                  Si c'est en local, on utilise un socket unix, pas tcp.

                                                  Oui, j’admets qu’il faut écrire dépend de postgres une fois par service l’utilisant dans un cas. Mais est-ce si compliqué ?

                                                  Oui c'est compliqué. Surtout que certains services peuvent utiliser postgresql, mysql, ou autre. Qui va penser à mettre à jour les dependances du script d'init lors d'un changement de conf ? Et il est facile d'oublier par exemple qu'un service utilise syslog, et doit donc démarrer après.
                                                  Si tout ca peut etre geré automatiquement sans avoir à s'en préoccupper, c'est mieux. Et en plus, c'est plus efficace, on démarre les processus le plus possible en parallèle, pour qu'ils commencent à faire ce qui peut etre fait sans attendre.

                                                  • [^] # Re: Tu n'es pas le centre du monde

                                                    Posté par  . Évalué à 1. Dernière modification le 11 octobre 2012 à 16:46.

                                                    Avec des remarques comme ca on serait tous en train de coder en assembleur …

                                                    Je te parle de conception logiciel tu me parles langage et implémentation… pas tout à fait la même chose.

                                                    Pour illustrer mon propos, je me suis fendu d’une implémentation simple de la bonne façon de faire à mes yeux. Qui ne me semble pas très compliquée.

                                                    main.c :

                                                    #include <unistd.h>
                                                    #include <stdio.h>
                                                    #include <stdlib.h>
                                                    
                                                    void demon()
                                                      {
                                                       sleep(60);
                                                      }
                                                    
                                                    void fils()
                                                      {
                                                       pid_t l_pid;
                                                    
                                                       printf("Debut du fils\n");
                                                       /* Initialisation */
                                                    
                                                       /* Bricolage */
                                                       printf("Debut du bricolage\n");
                                                       sleep(10);
                                                       printf("Fin du bricolage\n");
                                                    
                                                       /* Pret */
                                                       printf("Fils %d\n",getpid());
                                                       l_pid = setsid(); /* A partir de la, le process n'est plus associe a un terminal */
                                                       printf("setsid() = %d\n",l_pid); /* Les printf fonctionnent puisque herite du premier fork */
                                                       sleep(10);
                                                       printf("Enfin pret.\n");
                                                    
                                                    
                                                       /* Ferme les flux standard */
                                                       close(0);
                                                       close(1);
                                                       close(2);
                                                    
                                                       l_pid = fork();
                                                    
                                                       switch (l_pid)
                                                         {
                                                          case -1:
                                                             /* Soyons bourrin */
                                                             exit(1);
                                                          case 0:
                                                             demon();
                                                             exit(0);
                                                          default:
                                                             /* Synchronise le pere */
                                                             exit(0);
                                                         }
                                                      }
                                                    
                                                    void pere(pid_t p_pid)
                                                      {
                                                       /* Attente du fils */
                                                       printf("Attente du fils\n");
                                                       wait(p_pid);
                                                       printf("Fin de l'attente\n");
                                                      }
                                                    
                                                    int main()
                                                      {
                                                       pid_t l_pid;
                                                    
                                                       l_pid = fork();
                                                       switch (l_pid)
                                                         {
                                                          case -1:
                                                             printf("Fork fail\n");
                                                             return 1;
                                                          case 0:
                                                             fils();
                                                             printf("Fin du deamon\n");
                                                             return 0;
                                                          default:
                                                             pere(l_pid);
                                                         }
                                                       printf("Fils en demon\n");
                                                    
                                                       return 0;
                                                      }
                                                    
                                                    

                                                    On va utiliser 2 terminaux. Un avec un watch, et l’autre pour avec la commande lancée et la compilation.

                                                    Dans le terminal 1, on compile :

                                                    $ gcc main.c -o dem
                                                    $ 
                                                    
                                                    

                                                    Sur le 2 on surveille les processus :

                                                    $ watch "(ps -u user | grep dem)"
                                                    
                                                    

                                                    On démarre le démon sur le terminal 1 :

                                                    $ ./dem
                                                    Debut du fils
                                                    Debut du bricolage
                                                    Attente du fils
                                                    
                                                    

                                                    Pendant ce temps sur le terminal 2 :

                                                     5597 pts/7    00:00:00 dem
                                                     5598 pts/7    00:00:00 dem
                                                    
                                                    

                                                    Au bout de 10s :
                                                    Term 1

                                                    $ ./dem
                                                    Debut du fils
                                                    Debut du bricolage
                                                    Attente du fils
                                                    Fin du bricolage
                                                    Fils 5598
                                                    setsid() = 5598
                                                    
                                                    

                                                    Term 2

                                                     5597 pts/7    00:00:00 dem
                                                     5598 ?        00:00:00 dem
                                                    
                                                    

                                                    Enfin, la dernière étape :
                                                    Term 1

                                                    $ ./dem
                                                    Debut du fils
                                                    Debut du bricolage
                                                    Attente du fils
                                                    Fin du bricolage
                                                    Fils 5598
                                                    setsid() = 5598
                                                    Enfin pret.
                                                    Fin de l'attente
                                                    Fils en demon
                                                    $ 
                                                    
                                                    

                                                    Term 2

                                                    5661 ?        00:00:00 dem
                                                    
                                                    

                                                    Pour résumer, on a un fork, le père attend sont fils. Le fils créé son groupe de session setsid, puis fork. Le nouveau fils est détaché, il ne se terminera pas avec son père. Le premier fils se termine, rendant la main au père initial. On voit ici, que si l’initialisation est faite au bricolage, le dernier fils héritant du contexte de son père. On peut rendre la main quand on a fini de s’initialiser, d’ouvrir ses socket

                                                    Édition: correction mise en page.

                                                    • [^] # Re: Tu n'es pas le centre du monde

                                                      Posté par  . Évalué à 2.

                                                      Sur un cas simple c'est simple. Mais si ton demon utilise une série de processus il va falloir un plus de travail pour t'assurer qu'ils soient tous près (c'est le cas de pg qui a 4 ou 5 processus), si tes traitement sont asynchrones c'est encore un peu plus compliqué.

                                                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                        • [^] # Re: Tu n'es pas le centre du monde

                                          Posté par  . Évalué à 2.

                                          Je passe sur l’humour de Michel qui n’apporte rien au débat.

                                          Merci, c'est gentil. b annonce la même chose en plus détaillée. J'ai parlé de buffer qui pète simplement parce que j'ai imaginé le pire cas et que la taille des buffers est limités (donc au bout d'un moment s'il reçoit un tas de requêtes sans être près, les client reçoivent des erreurs, de la même manière qu'il peut y avoir un timeout).

                                          Je voulais souligner que ça ne protège pas de tout, mais que ça limite fortement les dégâts.

                                          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                          • [^] # Re: Tu n'es pas le centre du monde

                                            Posté par  . Évalué à 1.

                                            Merci, c’est gentil.

                                            Je te prie de m’excuser si je me suis emporté. Je réagissais à cette phrase :

                                            Ce à quoi il va répondre que ce n'est pas parce qu'il écoute la socket qu'il est prêt.

                                            Qui sous entend, de la connivence entre deux personnes qui ont compris et quelqu’un a qui ce n’est même pas la peine d’expliquer. Ce n’était sans doute pas ton propos. Donc je réitère mes excuses pour ma petite phrase mesquine.

                                • [^] # Re: Tu n'es pas le centre du monde

                                  Posté par  (site web personnel) . Évalué à 3.

                                  Si le démon postgress rend la main au script avant d’être opérationnel, c’est un problème de postgress

                                  Et cette affirmation elle sort d'ou ? Jamais le fait qu'un service rende la main ne veut dire qu'il est opérationnel, sauf dans tes rêves…

                                  Tu forks pas une fois ton programme en train de fonctionner mais avant.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 5.

                            Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la
                            faute au système de démarrage, mais au service en lui même.

                            TOUS les services font comme cela, entre le moment ou ils rendent la main et le moment ou ils écoutent sur leur socket, y'a forcément un laps de temps plus ou moins long en fonction du service.

                            Mais si tu penses vraiment que c'est pas normal, je te propose de faire un bug report aux devs de openssh (sshd) qui fait un fork() avant d'ouvrir quelque socket que ce soit.

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  (site web personnel) . Évalué à 10.

                /etc/init.d/monscript start

                # systemctl start monscript.service
                
                

                C'est vrai que c'est une horrible complexification…

                un lien dans /etc/rcN.d vers le script en question avec tous les scripts qui
                commencent par K pour arret, et S pour start et un chiffre indiquant l'ordre de
                démarrage.

                # systemctl enable monscript.service
                
                

                tas de fichiers de conf dans tous les sens avec des liens partout,

                Roh le foutage de gueule!

                [root@arch gnumdk]# systemctl  enable sshd.service
                ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
                ln -s '/usr/lib/systemd/system/sshdgenkeys.service' '/etc/systemd/system/multi-user.target.wants/sshdgenkeys.service'
                
                

                Soit deux liens alors qu'avant:

                [gnumdk@tina ~]$ find /etc/rc*.d -name *ssh*
                /etc/rc6.d/K25sshd
                /etc/rc3.d/S55sshd
                /etc/rc5.d/S55sshd
                /etc/rc1.d/K25sshd
                /etc/rc2.d/S55sshd
                /etc/rc0.d/K25sshd
                /etc/rc4.d/S55sshd
                
                

                J'aimerai bien savoir ou se trouve le bordel…

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  . Évalué à 1.

                  Comment faire pour configurer un nouveau service non intégré dans la distrib ?

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  . Évalué à 7. Dernière modification le 09 octobre 2012 à 17:54.

                    En lisant la doc ?

                    http://www.freedesktop.org/software/systemd/man/systemd.service.html

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Tu n'es pas le centre du monde

                      Posté par  . Évalué à 1.

                      Décris-le moi en 3 ou 4 lignes. La doc de systemd me donne mal à la tête.

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  (site web personnel) . Évalué à 1.

                        tu demandes à systemd un truc que tu ne demandes pas à rc.d… Parce que décrire rc.d en 3 ou 4 lignes, je demandes à voir!
                        Le problème de la résistance au changement, c'est qu'on demande au truc nouveau des choses qu'on ne demandais pas à ce qu'on a l'habitude d'utiliser.

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 2.

                          J'espère que tu n'as pas pris le "3 ou 4 lignes" au pied de la lettre quand même.

                          Le problème de la résistance au changement, c'est qu'on demande au truc nouveau des choses qu'on ne demandais pas à ce qu'on a l'habitude d'utiliser.

                          Quels trucs et pour quelle utilité ?

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 3.

                            La doc de systemd me donne mal à la tête.

                            Mwai, enfin cette phrase, ca fait vraiment gros noobz qui a la flemme et qui veut qu'on lui pré-mâche le travail…

                            Les mecs comme ça, aujourd'hui ils ont 50 ans et sont complètements largué en informatique parce que se mettre à la page, c'est vraiment trop compliqué.

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  . Évalué à 8.

                        On peut par exemple comparer le fichier de config systemd du daemon haveged, avec son script d'init rc.d.

                        Avec systemd :

                        $ cat /lib/systemd/system/haveged.service 
                        [Unit]
                        Description=Entropy Daemon based on the HAVEGE algorithm
                        
                        [Service]
                        Type=forking
                        PIDFile=/var/run/haveged.pid
                        ExecStart=/usr/sbin/haveged -w 1024 -v 1
                        
                        [Install]
                        WantedBy=multi-user.target
                        
                        

                        Avec rc.d :

                        $ cat /etc/rc.d/init.d/haveged 
                        #!/bin/sh
                        #
                        # Copyright 2011-2012 Jirka Hladky hladky_dot_jiri_at_gmail_com
                        # Copyright 2011-2012 Gary Wuertz gary@issiweb.com
                        #
                        # This program is free software: you can redistribute it and/or modify
                        # it under the terms of the GNU General Public License as published by
                        # the Free Software Foundation, either version 3 of the License, or
                        # (at your option) any later version.
                        #
                        # This program is distributed in the hope that it will be useful,
                        # but WITHOUT ANY WARRANTY; without even the implied warranty of
                        # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
                        # GNU General Public License for more details.
                        #
                        # You should have received a copy of the GNU General Public License
                        # along with this program.  If not, see <http://www.gnu.org/licenses/>.
                        
                        #
                        # haveged: Starts the haveged entropy daemon
                        #
                        # chkconfig: - 75 25
                        # description: havege entropy daemon
                        # processname: haveged
                        #
                        # source function library
                        . /etc/init.d/functions
                        
                        HAVEGED_BIN=/usr/sbin/haveged
                        
                        RETVAL=0
                        prog="haveged"
                        LOCKFILE=/var/lock/subsys/$prog
                        
                        test -x ${HAVEGED_BIN} || { echo "Cannot find haveged executable ${HAVEGED_BIN}" 1>&2 ; exit 5 ; }
                        
                        case "$1" in
                        start)
                          gprintf "Starting %s: " "$prog"
                          ${HAVEGED_BIN} -w 1024 -v 1 && success || failure
                          RETVAL=$?
                          [ "$RETVAL" = 0 ] && touch ${LOCKFILE}
                          echo
                          ;;
                        
                        stop)
                          gprintf "Stopping %s: " "$prog"
                          if [ -e /var/run/$prog.pid ]; then
                            kill `cat /var/run/$prog.pid` && success || failure
                          else
                            failure
                          fi
                          RETVAL=$?
                          [ "$RETVAL" = 0 ] && rm -f ${LOCKFILE}
                          echo
                          ;;
                        
                        restart|reload)
                          $0 stop
                          $0 start
                          ;;
                        
                        condrestart)
                          [ -f $LOCKFILE ] && $0 restart
                          ;;
                        
                        status)
                          status $prog
                          RETVAL=$?
                          ;;
                        *)
                          gprintf "Usage: %s {start|stop|status|reload|restart|condrestart}\n" "$prog"
                        esac
                        exit $RETVAL
                        
                        

                        Lequel des deux est le plus simple à comprendre ? Lequel des deux permet de voir le plus rapidement la commande qui est executée pour démarrer le daemon ? Lequel permet le plus simplement de modifier les parametres passés au daemon haveged ?

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 2.

                          Les 42 000 options que l'on peut insérer dans systemd sont loin d'être claires. Avec un script tu vois rapidement ce qui se passe. Ca nécessite de connaitre un peu la programmation shell (au moins savoir lire un script), mais au moins on voit du premier coup d'oeil ce qui se passe.

                          Après il y a les guignols qui passent leur temps à compliquer les choses, à décomposer un script en trois ou quatre scripts s'appelant les uns les autres, mais là ce n'est pas le systme d'init qu'il faut mettre en cause mais les gens qui ne savent pas s'en servir.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 3.

                            Y a pas tellement d'options, et tout est très bien documenté dans les pages man, on peut rapidement voir à quoi correspond n'importe quelle option.

                            Et une ligne comme "Type=forking" c'est nettement plus rapide à comprendre que 15 lignes de shell, à chaque fois differentes, pour gerer un ficher de pid, un fichier de lock, tester l'existence d'un repertoire dans /proc, parfois ne rien tester du tout, etc … Avec systemd, tous les services sont gerés de la meme facon, et c'est documenté.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 2.

                            mais au moins on voit du premier coup d'oeil ce qui se passe.

                            J'ai bien rit, c'est fou comme la résistance au changement amène comme phrase : un des plus gros défauts du système précédent que le nouveau système corrige se transforme en qualité comme par enchantement.

                            Non, on ne voit RIEN au premier coup d'oeil. Au contraire, c'est nébuleux complet, quel que soit la qualité du script, car le script est bien trop verbeux pour des taches de ce type.

                            Tu t'inventes des qualité de l'ancien système et des défaut du nouveau juste parce que maintenant, pour 1 personne qui avait les compétences pour lire et qui ne veut pas apprendre le nouveau système plus simple, il y a 10 personnes qui apprennent car plus simple, du coup on a moins la classe, ce qu'on a appris en en chiant n'est plus utile…

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  (site web personnel) . Évalué à 4.

                          Lequel des deux est le plus simple à comprendre ? Lequel des deux permet de voir le plus rapidement la commande qui est executée pour démarrer le daemon ? Lequel permet le plus simplement de modifier les parametres passés au daemon haveged ?

                          A mon avis la bonne question c'est : le quel est le plus simple a dépanner ? Parce que, un script shell j'y arriverai, un bidule pour systemd je ne sais pas.

                          (jamais vu de systemd dans la vrai vie encore)

                          les pixels au peuple !

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 4.

                            T'es entrain de dire que tu saurais dépanner quelque chose que tu connais et pas quelque chose que tu n'a jamais vu tourner dans la vraie vie ?

                            C'est pas de la résistance au changement, 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: Tu n'es pas le centre du monde

                              Posté par  (site web personnel) . Évalué à 3.

                              C'est pas de la résistance au changement, non…

                              Ben c'est que maintenant je suis un vieux con. Si ça change, j'aime bien que ça apporte un plus réel parce que j'ai pas que ça à faire.

                              Je m'occupe que de serveurs Linux (au boulot) et je suis un peu dubitatif sur l'apport de systemd.

                              les pixels au peuple !

                              • [^] # Re: Tu n'es pas le centre du monde

                                Posté par  (site web personnel) . Évalué à 3.

                                Si ça change, j'aime bien que ça apporte un plus réel parce que j'ai pas que ça à faire.

                                Ce qui changent non plus n'ont pas que ça à faire. Tu crois sérieusement qu'ils le font juste pour le plaisir de t'emmerder?

                                Je m'occupe que de serveurs Linux (au boulot) et je suis un peu dubitatif sur l'apport de systemd.

                                C'est pas faute à certains de faire des dépêches et d'autres de pointer des liens pour expliquer. "Ca n'apporte rien", alors qu'il y a plein d'infos sur pourquoi ça apporte et que bizarrement pas mal de distros y passent sans y être forcées, ça devient un peu lourd comme "argument".

                              • [^] # Re: Tu n'es pas le centre du monde

                                Posté par  . Évalué à 5.

                                Ben c'est que maintenant je suis un vieux con.

                                Loin de moi l'idée de te juger. Je dis juste que l'argument que tu pose (« je ne connais pas donc je sais pas faire »), c'est de la simple résistance au changement et ça s'applique avec à peu près tout.

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 7.

                          C'est intéressant comme comparaison (vraiment). Je me suis donc demandé si c'était vraiment un problème inhérent au système de scripts que systemd pourrait "solutionner". J'ai donc regardé sur la distro gentoo avec ton exemple. Gentoo utilise openrc sysvinit et un ensemble de script pour l'init donc c'est tout trouvé comme exemple alternative.

                          haveged est dans l'arbre portage. Pour le démon il y a 2 fichiers conf:
                          celui du service: /etc/init.d/haveged

                          #!/sbin/runscript
                          # Copyright 1999-2011 Gentoo Foundation
                          # Distributed under the terms of the GNU General Public License v2
                          
                          command="/usr/sbin/${SVCNAME}"
                          command_args="-r 0 ${HAVEGED_OPTS}"
                          pidfile=/var/run/${SVCNAME}.pid
                          
                          depend() {
                              provide entropy
                          }
                          
                          

                          celui de la config du démon: /etc/conf.d/haveged

                          # Copyright 1999-2011 Gentoo Foundation
                          # Distributed under the terms of the GNU General Public License v2
                          
                          WATERMARK=1024
                          
                          # -r0 is added always
                          HAVEGED_OPTS="-w ${WATERMARK} -v 1"
                          
                          

                          En dehors des commentaires, autant de lignes effectives que dans l'exemple avec systemd.
                          La doc. est faite aussi ici.
                          Le problème, est-ce vraiment la logique du script ou bien la "rigueur" dans la lisibilité qui pose problème?
                          Je comprends le point de vue de totof2000 ( et j'ai aussi lu le linux mag sur systemd (enfin pas tout encore)).

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à -3.

                            Wai, enfin la pour le coup, openrc se rapproche de systemd dans la syntaxe et le principe (de base)…

                            Les gens qui crachent sur systemd le font pour conserver les initscripts de leur distribution, pas sysvinit.

                            Donc si ils sont logiques, ils doivent aussi trouver que openrc c'est de la grosse merde ;)

                            • [^] # Re: Tu n'es pas le centre du monde

                              Posté par  . Évalué à 2. Dernière modification le 10 octobre 2012 à 13:26.

                              Wai, enfin la pour le coup, openrc se rapproche de systemd dans la syntaxe et le principe (de base)…

                              Non…
                              1/ il se veut portable. C'était le but du développeur initial. Il y a Robbins qui démarche chez Freebsd pour openrc . Je crois Debian se pose aussi la question d'un port.
                              2/ openrc n'est pas un init (c'est sysvinit ici)
                              3/ on utilise des scripts… chose sur quoi le débat a lieu ici.

                              Mais on peut pendre les scripts init rc de FreeBSD ou de NetBSD aussi … ils ne feront pas beaucoup de lignes non plus. ( haveged n'est pas pkgsrc mais l'écriture du script sera simple).

                            • [^] # Re: Tu n'es pas le centre du monde

                              Posté par  . Évalué à 1.

                              La différence c’est que openrc lance le démon. Alors que systemd, s’installe sur la socket pour démarrer le service quand il sera demandé (si j’ai bien compris). Il y a une différence de philosophie.
                              Dans les exemples sur gentoo, si tu démarres un service qui a besoin d’un autre service, la dépendance sera activé puis on lance le service voulu. Si un service qui n’a pas été demandé à démarrer par l’administrateur, mais qui l’a été en tant que dépendance d’un autre service et qu’on arrête se dit service, alors le service dépendant sera arrêté à la condition qu’aucun autre service ne dépende de lui. Déjà vu avec RPC.
                              Ce qu’il y a de sourd dans ce dialogue, c’est que toi tu dis que être contre systemd c’est être contre la simplicité, alors que ce n’est pas forcément le cas. Pour l’instant, rien ne me prouve que systemd est mieux que openrc, bien que se dernier soit du script…

                              • [^] # Re: Tu n'es pas le centre du monde

                                Posté par  (site web personnel) . Évalué à 1.

                                La différence c’est que openrc lance le démon. Alors que systemd, s’installe sur la
                                socket pour démarrer le service quand il sera demandé (si j’ai bien compris). Il y a
                                une différence de philosophie.

                                Uniquement si tu l'as configuré comme cela…

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  . Évalué à 4.

                        C'est vrai que la doc de Sysv est beaucoup plus simple : chaque distribution a la sienne.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  . Évalué à 3.

                Avant systemd : un système de scripts System5 simple à comprendre :

                Le système, peut-être, mais les scripts n'étaient pas toujours simples.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  . Évalué à 1.

                  Ne serait-ce donc pas plutôtles scripts compliqués qui aurait fallu changer ?

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  . Évalué à 2.

                    Comment ?

                    Chaque distribution a ses propres scripts, il n'y a qu'à comparer Red Hat et Debian.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Tu n'es pas le centre du monde

                      Posté par  . Évalué à 2.

                      Tu me dis que les scripts étaient compliqués. Soit, mais dans ce cas, pourquoi ne pas écrire des scripts simples ?

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  . Évalué à 5.

                        C'est ce qui a été fait. Les scripts compliqués ont été remplacés par de simple fichiers de configuration. Les actions qui avant étaient reimplementées à chaque fois dans chaque script, de facon plus ou moins similaire (mais pas exactement), maintenant sont remplacées par une simple option.

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 1.

                          Absolment pas. On a remplacé un principe simple par une usine a gaz sous pretexte que des gens aiment compliquer les choses. Les trucs de démarrage à la systemd, ça parait beau sur le papier, mais à l'usage on se trouve avec des trucs moisis qui explosent sans qu'on sache pourquoi. C'est typiquement le genre de truc qui font que je déteste autant Windows. Plus ça vient et moins j'aime Linux. Quel gachis.

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 0.

                            Vu que tu n'utilise quand même pas Linux (d'après un de tes messages plus haut), pourquoi tu viens emmerder ceux qui l'utilisent?

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 3.

                            J'ai encore jamais vu ce genre de retour. Toi oui ?

                            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 1.

                            On a remplacé un principe simple

                            C'est le concours de la plus grosse énormité? le truc remplacé est tout sauf simple à maintenir! C'est justement un des reproches fait. Tous les défauts du système précédent, une fois qu'on le remplace, se retrouvent comme par miracle transformés en qualité, fort, très fort cette résistance au changement…

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 4.

                            On a remplacé un principe simple par une usine a gaz

                            Si c'est si simple, pourquoi personne ne veut le maintenir chez Arch ?

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  . Évalué à 2.

                            Depuis quand Windows utilise quelquechose comme systemd ?

                          • [^] # Re: Tu n'es pas le centre du monde

                            Posté par  (site web personnel) . Évalué à 2.

                            On a remplacé un principe simple par une usine a gaz

                            Et comme d'habitude, zéro argumentation… On sens le mec qui aime parler de ce qu'il ne connait pas…

                            C'est typiquement le genre de truc qui font que je déteste autant Windows.

                            Parce que tu essayes de nous faire croire que tu a déjà essayé de savoir comment fonctionne le système d'init de Windows ?

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  . Évalué à 4.

                Il y a ici des explications sur systemd assez intéressantes je trouve : https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 08 octobre 2012 à 22:07.

        Rappel : pour être motivé, il faut avoir les compétences.

        A défaut de compétence et à défaut de vouloir les acquérir, tu peux payer des gens pour faire le boulot.
        Après, si pas de compétences, refus d'acquérir des compétences, et pas de sous, je crois qu'on peut dire que tu veux juste des esclaves pour toi. Les développeurs d'Arch ne sont pas tes esclaves, dommage pour toi.

        C'est rigolo, les non-mainteneurs (ceux qui ne bossent pas dessus) râlent, mais personne pour prendre la relève. Faut croire que le choix du changement était le bon.

        • [^] # Re: Tu n'es pas le centre du monde

          Posté par  . Évalué à 2.

          A défaut de compétence et à défaut de vouloir les acquérir, tu peux payer des gens pour faire le boulot.

          Même si j’avais envie d’acquérir les compétences, je doute que j’ai le temps de le faire.

          Pour l’argent (et là je répond au commentaire de Renault aussi) j’ai deux questions :

          • comment faites vous pour savoir ce que je donne ?
          • comment payer des développeurs aux justes prix sans gagner l’argent nécessaire ?
          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  (site web personnel) . Évalué à 4.

            comment faites vous pour savoir ce que je donne ?

            Je pars du principe que si tu ne peux participer au maintient de SysV ou en tout cas avoir une influence décisionnelle à ce niveau, ton investissement au projet, quel qui soit, et ton expertise technique n'est pas suffisant pour mériter le maintient de SysV chez ArchLinux.
            Du coup, tu ne peux rien exiger d'eux.

            comment payer des développeurs aux justes prix sans gagner l’argent nécessaire ?

            Le Logiciel Libre c'est soit tu bosses, soit tu payes un développeur, soit tu es pote avec l'un d'eux pour avoir ce que tu veux. C'est communautaire, chacun y participe de la manière qu'il souhaite et souvent avec ses principes, besoins et envies en ligne de mire.
            Si tu ne peux le faire car trop pauvre et pas assez compétent, passe ton chemin, tu ne peux exiger d'eux cela et cela me semble normal car ils ne te doivent rien. D'ailleurs les licences libres sont accompagnés en générale de la mention « distribution sans garantie », c'est bien la preuve qu'il n'y a aucune obligation contractuelle et qu'ils n'ont pas de compte à rendre, dont toi.

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  (site web personnel) . Évalué à 7.

              Du coup, tu ne peux rien exiger d'eux.

              En même temps, je n'ai rien lu dans le journal qui se rapproche d'une exigence, tout juste un "constat", qu'on est bien sûr pas obligé de partager.

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  (site web personnel) . Évalué à 2.

              justement je ne vois pas l'intérêt de payer pour un truc dont les développeurs eux-même ne veulent pas entendre parler : si c'est pour payer pour que ça fonctionne 6 mois et que ça soit abandonné ensuite, c'est de l'argent mal employé.

              « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  . Évalué à 3. Dernière modification le 09 octobre 2012 à 09:56.

              Bon a priori y'a des mecs qui n'ont pas pigé que ce n'est pas en filant du pognon qu'on motive ou qu'on fait contribuer davantage au développement d'un logiciel libre…

              En tout cas joli journal à troll pour enflammer un sacré paquet de personnes :)

              Where there is a shell there is a way

          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  (site web personnel) . Évalué à 0. Dernière modification le 09 octobre 2012 à 08:06.

            comment payer des développeurs aux justes prix sans gagner l’argent nécessaire ?

            Moi, je voudrais (mettre ici un truc x hors de prix que je ne peux pas me payer). Tu me l'offres? c'est ce que tu demandes pour toi.

            comment faites vous pour savoir ce que je donne ?

            La, je peux juste dire que personne n'a donné assez pour payer un dev' pour l'ancien système, je vois donc que tu n'as pas donné assez. Ce que tu donne, je m'en fou pour la discussion, je te fait remarquer juste que les gens ne sont pas des esclave, soit tu trouves un moyen pour payer suffisamment les personnes compétentes, soit un moyen pour apprendre et tu le fais, mais oui je bondis quand je vois les gens réclamer des choses à d'autres sans se bouger (suffisamment si tu donnes), se plaindre que ça va pas comme eux veulent (et ils sont sûr, sans avoir la main dans la merde, que la merde est bien et qu'il faut la garder).

            Je dis juste qu'on ne vit pas dans ton monde idéal où quand Arcaik veut quelque chose, une personne se lève et le fait pour faire plaisir. Et contrairement à ce que tu dis dans le journal, ça n'a absolument rien à voir avec l'état de santé de la distro, juste de toi qui refuses le changement sous des raisons… ah non, tu n'as même pas pris la peine d'expliquer pourquoi ce n'était pas bien de changer, juste "c'est pourri", aucun argument autre qu'une résistance au changement. Si tu étais en politique, j'aurai peur de ton budget en tant que citoyen : tu dépenserais les sous du contribuable (mais plus que ton budget) pour des choses que te plaisent et non pas des choses utiles, juste comme ça, pour ne pas changer un truc qui te plaisait. Heureusement, le monde ne fonctionne pas/plus comme ça.

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  . Évalué à 4.

              mais oui je bondis quand je vois les gens réclamer des choses à d'autres sans se bouge

              Tu n'as pas du bondir beaucoup en lisant ce journal alors. Je n'ai rien réclamé, j'ai simplement fait l'amer constat que Arch n'est plus la distribution quelle était.

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  (site web personnel) . Évalué à 2.

                quelle était.

                Correction : que tu voudrais qu'elle soit. Qui a dit que garder l'ancien init devait être permanent pour être "ce qu'elle était".
                Encore une fois, Arch est bien vivante, contrairement à ce que tu as bien écrit textuellement. Seulement elle ne vit pas comme toi tu voudrais.
                Arch continue à être la distribution qu'elle était : rolling release pour geek aimant bidouiller (je grossis le trait). Le changement vers systemd ne change pas ce qu'elle était.

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  (site web personnel) . Évalué à -4.

                  Encore une fois, Arch est bien vivante

                  Le changement vers systemd ne change pas ce qu'elle était.

                  on sent le témoignage vibrant et pertinent d'un utilisateur quotidien d'Archlinux. Tu as enfin abandonné Windows sur ton desktop ?

                  « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  (site web personnel) . Évalué à 0.

                    Je ne suis pas sectaire, et discute avec du monde, dont des gens de chez arch, ils sont vivant de chez vivants (très à jour). Ah oui, pardon, quand on utilise un OS, on n'a pas le droit de s’intéresser aux autres… Désolé de ne pas rentrer dans ce moule.

                    • [^] # Re: Tu n'es pas le centre du monde

                      Posté par  (site web personnel) . Évalué à 0.

                      moi mon voisin il m'a dit que le nouveau Windows 8 c'est vraiment de la daube, et que windows c'est mort. Donc je l'affirme Windows continue à être l'OS qu'il a toujours été : plantogène, sensible aux virus et utilisable par un grand public qui n'est pas très regardant (je grossis le trait). Le changement vers l'interface Metro ne change pas ce qu'il était.

                      « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  . Évalué à 3.

            Rappel : pour être motivé, il faut avoir les compétences.

            Et pour avoir les compétences, il faut être motivé.

            Si tu ne te bouges pas, c'est que tu n'en as pas tant envie que tu le prétends.

        • [^] # Re: Tu n'es pas le centre du monde

          Posté par  . Évalué à 2.

          C'est une proposition ? moi je te paye pour maintenir SysV sous Arch. Si cela me permet de moins être confronté au ton orgueilleux de tes commentaires.

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 8. Dernière modification le 08 octobre 2012 à 23:57.

        Rappel : pour être motivé, il faut avoir les compétences.

        Si tu n'es pas développeur, tu peux aussi te proposer de tester SysV init (dans la limite de tes compétences), maintenir les pages de wiki en relation, envoyer des rapports de bugs en cas de problème, etc. Cela ne résoudra pas magiquement le problème, mais si beaucoup de gens font comme toi, peut-être que la perspective d'une grande base de testeurs et d'une demande suffisamment forte motivera quelques développeurs intéressés, mais encore quelque peu refroidis par la charge de travail à fournir…

        (Edit: J'assume le côté bisounours de mon commentaire.)

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  . Évalué à 3.

        Rappel : pour être motivé, il faut avoir les compétences.

        J'aurais dit l'inverse : pour avoir les compétences, il faut être motivé.

        Et j'ajouterais que pour être motivé, il faut en avoir besoin ou envie. Tout dépend ensuite de ton usage d'Arch.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 4.

        Rappel : pour être motivé, il faut avoir les compétences.

        ça s'acquiert des compétences, par contre il faut être motivé.

    • [^] # Re: Tu n'es pas le centre du monde

      Posté par  . Évalué à 9.

      Raiders a changé de nom pour Twix
      Neil Armstrong est mort
      Archlinux passe sous systemd

      moi j'vous l'dis: la Vie est morte!!

    • [^] # Re: Tu n'es pas le centre du monde

      Posté par  . Évalué à 4.

      Archilinux est, et sera, ce n'est pas quand quelques personnes râlent sans se bouger

      Oui enfin on est pas obligé de contribuer pour pouvoir dire que l'on aime pas, encore heureux. L'avantage du libre c'est de pouvoir modifier comme on veut, c'est pas une obligation pour discuter des changements quand même.

      Finalement, ce qui est rigolo, c'est de voir les mêmes résistances aux changements,

      Le problème c'est surtout une perte de la diversité. Comme dit plus haut, le problème n'est pas que certaines distrib' utilisent systemd, mais que Archlinux qui prônait le principe KISS soit beaucoup moins KISS, alors que c'est ce qui attire ses utilisateurs.

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 4.

        Oui enfin on est pas obligé de contribuer pour pouvoir dire que l'on aime pas, encore heureux.

        Oui mais râler ne sert à rien, d'expérience. Si tu n'es pas content d'une décision prise, agis et c'est tout, sinon c'est une perte de temps (et si c'est juste pour débattre, on peut, c'est plus agréable que des coups de gueule et plus intéressant).

        mais que Archlinux qui prônait le principe KISS soit beaucoup moins KISS, alors que c'est ce qui attire ses utilisateurs.

        Personnellement j'ai du mal avec la définition de KISS, j'ai l'impression que c'est un mot cool, tout autant que la "philosophie UNIX" mais qu'en réalité la définition est assez floue pour permettre pas mal de choses. De ce que j'en lis du KISS, ici ou ailleurs, ne me fait pas penser que systemd ne l'est pas.

      • [^] # Re: Tu n'es pas le centre du monde

        Posté par  (site web personnel) . Évalué à 5.

        Oui enfin on est pas obligé de contribuer pour pouvoir dire que l'on aime pas, encore heureux.

        Dieu merci, quand on contribue, on peut ne pas écouter, vu que ça n'a aucun impact.

        • [^] # Re: Tu n'es pas le centre du monde

          Posté par  . Évalué à 3.

          Oui enfin j’attends des développeurs des logiciels que j'utilise qu'il écoutent un minimum les demandes de leurs utilisateurs… Bien sûr ils ne sont pas obligés, c'est eux qui font le boulot. Cela dit, dire qu'on est pas content d'un logiciel/distribution, c'est important, ça peut amener d'autres utilisateurs à s'exprimer, un débat ect. Certes, ce journal n'est pas hyper utile pour l'évolution d'Archlinux, vu que la décision a déjà été prise (mais les trolls sur systemD s'épuisaient, ces temps-ci..) mais en général, dire ce que l'on trouve une décision mauvaise, c'est pas inutile, même si on en participe pas.

          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  . Évalué à 2.

            Oui enfin j’attends des développeurs des logiciels que j'utilise qu'il écoutent un minimum les demandes de leurs utilisateurs

            Ben payes-les, tu peux être sûr qu'ils t'écouteront.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  (site web personnel) . Évalué à 5.

              Ben payes-les, tu peux être sûr qu'ils t'écouteront.

              payes-les correctement. J'en ai quelques uns qui sous couvert d'avoir filé 1€, pensent que toutes leurs demandes de développement, même si c'est 1 mois de dev, doit être fait en priorité et que c'est inadmissible si on dit que c'est seulement si il paye suffisamment, inadmissible car il a payé bordel. Si si ça arrive ce genre de "cas" :).

          • [^] # Re: Tu n'es pas le centre du monde

            Posté par  (site web personnel) . Évalué à 3.

            Oui enfin j’attends des développeurs des logiciels que j'utilise qu'il écoutent un minimum les demandes de leurs utilisateurs…

            Ecouter, oui. Obéir, non. Ici, on demande à des dev qui bossent gratos d'obéir à des utilisateurs qui ont del a simple résistance au changement sans aucun argument contre systemd hormis que ça leur change leur habitudes.

            Ces utilisateurs qui confondent obéir et écouter, c'est très lourd (j'en ai mon stock aussi, comme dans tout projet en fait, les lourds qui veulent tout en priorité et gratos bien sûr ça se trouve partout)

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  . Évalué à 2.

              Ecouter, oui. Obéir, non

              Oui, je suis bien d'accord, mais on me rétorque que ça sert à rien de râler… Ça sert à rien uniquement si les dév y prêtent pas attention. Après, entre prendre en compte des commentaires et les appliquer à la lettre, c'est différent. Après, comme je l'ai dit, râler sur Linuxfr c'est surtout pour troller/discuter.

              Ici, on demande à des dev qui bossent gratos d'obéir à des utilisateurs qui ont del a simple résistance au changement sans aucun argument contre systemd hormis que ça leur change leur habitudes.

              Je pense pas que ce soit de la résistance au changement, surtout de la part d'utilisateur d'une distrib rolling release… Par contre, Arch c'est avant tout le principe KISS, c'est rabâché partout sur leur site, et c'est ce qu'une bonne partie de utilisateurs cherchent je pense. Le problème de systemd est que ça va contre ce principe, je trouve normale que les utilisateurs râlent. Ceux qui préfèrent avoir systemd, il y a pleins d'autre distrib…

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  (site web personnel) . Évalué à 1.

                Oui, je suis bien d'accord, mais on me rétorque que ça sert à rien de râler… Ça sert à rien uniquement si les dév y prêtent pas attention. Après, entre prendre en compte des commentaires et les appliquer à la lettre, c'est différent. Après, comme je l'ai dit, râler sur Linuxfr c'est surtout pour troller/discuter.

                Je ne fais pas parti des gens qui te l'ont dit. Je remarque comme toi que ça sert absolument à rien de râler ici si c'est pour donner son mécontentement aux mainteneurs.

                Par contre, Arch c'est avant tout le principe KISS, c'est rabâché partout sur leur site, et c'est ce qu'une bonne partie de utilisateurs cherchent je pense. Le problème de systemd est que ça va contre ce principe, je trouve normale que les utilisateurs râlent.

                Tu y mets ton opinion, non partagée par tous : qui dit que ce qu'il y avait avant était KISS, qui dit que systemd n'est pas KISS? Désolé, mais quand je vois les scripts à l'ancienne tous pourris et les fichiers de conf de systemd, je fais mon choix : KISS, c'est systemd.
                Surtout, dans ce cas, virons tous les GUI, ils ne sont pas KISS, font trop de chose, faut arrêter avec le fantasme "KISS" à tout bout de champs.

                • [^] # Re: Tu n'es pas le centre du monde

                  Posté par  . Évalué à 3. Dernière modification le 10 octobre 2012 à 18:20.

                  Je ne fais pas parti des gens qui te l'ont dit.

                  Ben un peu : tu réponds "arrête de râler et code à la place" à l'auteur. Dans ce cas on ne fait pas de journaux pour dire que les majors qui veulent des droit d'auteurs illimité abusent, ni pour dire que ACTA c'est le mal. A la place, on écrit au majors pour les insulter copieusement, et on écrit aux députés européens pour leur dire de voter contre. Mais bon, on passe à coté de discutions/trolls intéressants (ou pas). Autant garder que les dépêches.

                  Je remarque comme toi que ça sert absolument à rien de râler ici si c'est pour donner son mécontentement aux mainteneurs.

                  J'ai dit que cela est très utile avant la prise de décision, et que les mainteneurs doivent prendre en compte ce genre de remarque si une grosse partie des utilisateurs disent qu'ils sont mécontent, mais que, malgré tout, c'est à eux de choisir.

                  Tu y mets ton opinion, non partagée par tous : qui dit que ce qu'il y avait avant était KISS, qui dit que systemd n'est pas KISS? Désolé, mais quand je vois les scripts à l'ancienne tous pourris et les fichiers de conf de systemd, je fais mon choix : KISS, c'est systemd.
                  Surtout, dans ce cas, virons tous les GUI, ils ne sont pas KISS, font trop de chose, faut arrêter avec le fantasme "KISS" à tout bout de champs.

                  On a tous bien compris que tu n'aimais pas le principe KISS, mais pourquoi vouloir l'imposer au autres? Si les gens aiment leur distro avec des script "tout pourris" tant mieux pour eux non? Sinon dire que systemd c'est KISS ça fait quand même un peu mauvaise foi :p Mais, admettons. Comme je l'ai dit, ce qui est important c'est qu'il y ai une discussion.Le truc c'est que c'est un sujet compliqué et c'est pas juste de la résistance aux changement, c'est normal que des utilisateurs râlent. C'est pas le truc que tu peu intégrer dans une distrib qui se dit KISS sans avoir bien vérifié que les utilisateurs ne trouvaient pas que ça cassait le concepts de Arch.

                  • [^] # Re: Tu n'es pas le centre du monde

                    Posté par  (site web personnel) . Évalué à 1.

                    On a tous bien compris que tu n'aimais pas le principe KISS,

                    Pardon? Tu as ta définition de KISS propre, qui change suivant ce qui t'arrange, c'est ton choix mais n'impose pas ta définition aux autres. KISS ne veut pas dire non plus faire chier les gens avec des trucs imbitables quand on peut faire simple!

                    mais pourquoi vouloir l'imposer au autres?

                    Je ne l'impose à personne :
                    - Je ne suis pas développeur Arch
                    - Je n'impose Arch à personne

                    Comme je l'ai dit, ce qui est important c'est qu'il y ai une discussion

                    La discussion a eu lieu, avec une conclusion : c'est la merde à maintenir et on préfère systemd, que ceux qui ne sont pas d'accord se bougent les fesses. Et bizarrement, pas foule pour se bouger, juste râler, c'est que finalement ça n'a pas l'air si horrible…

                    C'est pas le truc que tu peu intégrer dans une distrib qui se dit KISS sans avoir bien vérifié que les utilisateurs ne trouvaient pas que ça cassait le concepts de Arch.

                    Certains utilisateurs. Les mecs ont écouté, décidé, mais comme ça va pas dans le sens des râleurs ils se mettent à dénigrer. En plsu de la résistance au changement, nous voila avec de mauvais joueurs. Je plains les mainteneurs.

                    • [^] # Re: Tu n'es pas le centre du monde

                      Posté par  . Évalué à 3. Dernière modification le 10 octobre 2012 à 18:48.

                      Pardon? Tu as ta définition de KISS propre, qui change suivant ce qui t'arrange, c'est ton choix mais n'impose pas ta définition aux autres. KISS ne veut pas dire non plus faire chier les gens avec des trucs imbitables quand on peut faire simple!

                      Je ne vois pas quand j'ai changé de définitions? Sinon j'ai gardé celle du site de arch.

                      KISS ne veut pas dire non plus faire chier les gens avec des trucs imbitables quand on peut faire simple!

                      Non, c'est l'inverse. Pour dire que systemd est plus simple à comprendre/aprehender que sysV init faut le faire exprès quand même. Je ne dénigre pas les qualités techniques, hein, mais vu le gros bloatware pleins de modules qui font système, d'init, log, monitoring de démons, c'est plus compliqué et long à bien saisir qui fait quoi et comment, que avec SysV init.

                      La discussion a eu lieu, avec une conclusion : c'est la merde à maintenir et on préfère systemd, que ceux qui ne sont pas d'accord se bougent les fesses. Et bizarrement, pas foule pour se bouger, juste râler, c'est que finalement ça n'a pas l'air si horrible…
                      Certains utilisateurs. Les mecs ont écouté, décidé, mais comme ça va pas dans le sens des râleurs ils se mettent à dénigrer. En plsu de la résistance au changement, nous voila avec de mauvais joueurs. Je plains les mainteneurs.

                      Je suis globalement d'accord, mais je comprend pas ta haine et ton achatrnement contre les utilisateurs non-satisfaits de la décision. Dire archlinux est morte c'est pas aller insulter les mainteneur en leur disant que leur distrib c'est de la merde, c'est juste un pti coup de gueule sur linuxfr

                      • [^] # Re: Tu n'es pas le centre du monde

                        Posté par  (site web personnel) . Évalué à 1.

                        Je suis globalement d'accord, mais je comprend pas ta haine et ton achatrnement contre les utilisateurs non-satisfaits de la décision.

                        Satisfaits ou pas, je m'en fou. Je n'ai pas parlé de ça. Si l'auteur du journal avait dit qu'il n'était pas satisfait, en argumentant, OK. Ce n'est pas ce qu'il a dit (et il n'a pas pris la peine d'argumenter).

                        Quand à parler de haine… Tu vas trop loin, merci de ne pas imaginer ce que tu as envie. Tu aurais parlé de mépris, à la limite…

                        Dire archlinux est morte c'est pas aller insulter les mainteneur en leur disant que leur distrib c'est de la merde, c'est juste un pti coup de gueule sur linuxfr

                        Quand ça sera ton projet qui se prendra ce genre de "pti coup de gueule", on verra si tu apprécieras. Perso, je n'apprécie pas qu'on me le fasse ni qu'on le fasse à d'autres.

                        • [^] # Re: Tu n'es pas le centre du monde

                          Posté par  . Évalué à 2.

                          Quand à parler de haine… Tu vas trop loin, merci de ne pas imaginer ce que tu as envie. Tu aurais parlé de mépris, à la limite…

                          Désolé de ne pas situer exactement ton niveaux de mépris pour l'auteur…

                          Quand ça sera ton projet qui se prendra ce genre de "pti coup de gueule", on verra si tu apprécieras. Perso, je n'apprécie pas qu'on me le fasse ni qu'on le fasse à d'autres.

                          Je préfèrerai ça plutôt que l'on s'acharne sur moi au moindre commentaire posté parce que j'ai posté un journal qui n'argumente pas/qui n'est pas assez gentil. Et de loin.

            • [^] # Re: Tu n'es pas le centre du monde

              Posté par  . Évalué à 2.

              Ici, on demande à des dev qui bossent gratos d'obéir à des utilisateurs

              J'espère que tu ne parles pas du Journal en lui même parce que sinon, tu te trompes complètement.

              • [^] # Re: Tu n'es pas le centre du monde

                Posté par  (site web personnel) . Évalué à 1.

                Alors disons que l'auteur du journal ne demande pas qu'ils bossent gratos de manière franche, mais assène un coup "elle est morte" bien pourri pour (essayer de) pourrir la réputation de la distro qui ne fait pas comme ça lui chante, un peu un chantage "tu fais ce que je veux gratos ou alors je te pourri".
                Tu vas sans doute dire que c'est pas ça bla bla mais c'est bien l'effet du journal. Malheureusement pour l'auteur les gens n'ont pas gobé la chose et ont pourrit l'auteur du journal en lui montrant que c'est lui qui a un problème avec la résistance au changement et que la distro va bien, elle vivra sans l'auteur (si il part). Dommage, c'est raté.

  • # Deb & Ian

    Posté par  . Évalué à 4.

    Tient, pour ma part je suis quand même assez étonné, une Debian Squeeze boot assez vite :) C'est 20 secondes, même pas en ssd.

    Sinon c'est super cool que systemd arrive comme ça sur Archlinux :-)

    • [^] # Re: Deb & Ian

      Posté par  . Évalué à -1.

      Ton installation a un problème je pense.
      Sous Arch au démarrage avec SSD, la partie console est presque instantanée pour moi. Après, kdm prend une petite seconde et le login sous kde environ 3 ou 4 secondes.

      (Intel 330 series inside)

      • [^] # Re: Deb & Ian

        Posté par  . Évalué à 2.

        Tu as lu, trop vite :) Je n'ai pas de ssd. Sinon, c'est vrai que systemd est plus rapide d'un choullia, j'ai vite testé arch.

        • [^] # Re: Deb & Ian

          Posté par  . Évalué à 2.

          Au temps pour moi, j'avais compris le "20 secondes même pas en ssd" comme "à peine 20 secondes avec mon SSD". Il y a une ambiguïté au niveau de la tournure de cette phrase.

          Pas mal pour une installation sans SSD finalement.

          • [^] # Re: Deb & Ian

            Posté par  . Évalué à 7.

            Au temps pour moi, j'avais compris le "20 secondes même pas en ssd" comme "à peine 20 secondes avec mon SSD". Il y a une ambiguïté au niveau de la tournure de cette phrase.

            elle est tout à fait compréhensible sa phrase, il faut juste lire le petit élément qui donne tout son sens et que tu n'a pas mentionné dans ta citation: , "20 secondes, même pas en ssd"

      • [^] # Re: Deb & Ian

        Posté par  . Évalué à 2.

        Sous Arch au démarrage avec SSD, la partie console est presque instantanée pour moi. Après, kdm prend une petite seconde et le login sous kde environ 3 ou 4 secondes

        C'est mou ! :)

        En des temps reculés où la révolution systemd n'existait pas… une bande de geek bootaient en 5 secondes.
        Techno: une fedora/Moblin modifiée avec upstart, HAL sur un EEEPC.

        Il y a même eu un article du coin fait par patrick_g:
        http://linuxfr.org/users/patrick_g/journaux/booter-en-5-secondes

        Si systemd devait avoir une qualité, je ne mettrais pas en avant la vitesse de boot…

        • [^] # Re: Deb & Ian

          Posté par  (site web personnel) . Évalué à -1.

          le fameux boot rapide. Très peu utile quand on utilise l'hibernation ou la mise en veille de façon générale. Ah si, c'est bien quand on a 500 serveurs sous Arch, si on gagne 6 secondes par boot par rapport à une installation à l'ancienne (pour les geeks archaïques), en cas de mise à jour du noyau on gagne quand même 50 minutes…

          Et à part ça Haiku boote en moins de 10 secondes.

          « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

          • [^] # Re: Deb & Ian

            Posté par  . Évalué à 2. Dernière modification le 09 octobre 2012 à 14:30.

            Très peu utile quand on utilise l'hibernation ou la mise en veille de façon générale.

            Mais je n'ai pas dit le contraire… tu rajoutes une condition supplémentaire qui n'a rien à voir avec un boot à froid.
            Je te dis que si tu utilises le critère de vitesse de boot comme avantage de systemd par rapport à d'autres solutions et/ou optimisations, tu vas droit dans les choux. Ce qui fait le "succès" de systemd pour ses supporters est ailleurs.

            quand on a 500 serveurs sous Arch, si on gagne 6 secondes par boot par rapport à une installation à l'ancienne (pour les geeks archaïques), en cas de mise à jour du noyau on gagne quand même 50 minutes…

            Attends, attends… je ne comprends pas ton deal. Tu es en train de me dire que tu bootes tes serveurs en séries (6*500/60), l'un après l'autre, c'est ça?

            • [^] # Re: Deb & Ian

              Posté par  (site web personnel) . Évalué à 0.

              Mais je n'ai pas dit le contraire

              oui, c'était juste pour en rajouter une couche.

              Tu es en train de me dire que tu bootes tes serveurs en séries (6*500/60), l'un après l'autre, c'est ça?

              je parlais juste de temps machine brut (le truc qui n'a absolument aucun intérêt, comme le concours de temps de boot)

              « I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond

  • # Et donc ?

    Posté par  . Évalué à 6.

    Il y a quoi dans rc.conf(5), hostname(5) et hwclock(8) ?

    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Re:

    Posté par  . Évalué à 10.

    Tu te plaint que Arch devient une distrib générique alors que c'est là exactement son objectif ?

    Configurer son boot dans rc.conf c'était la voie générique, Arch n'a fait que le minimum de choix là ou c'était obligé, pour le reste c'est brut from upstream, je pense même qu'ils sont bien contents de se débarrasser de leur système de rc spécifique.

    Arch ne fournie aucune facilité d'administration, c'est sa marque de fabrique et c'est, entre-autre, pour cela que je lui préfère Gentoo qui regorge de petits outils bien pratiques.

    • [^] # Générique

      Posté par  . Évalué à 2.

      Configurer son boot dans rc.conf c'était la voie générique

      Dans le monde BSD.
      La majorité des distributions Linux avaient une (vraie) init de type System V, c’est-à-dire avec des liens dans /etc/rc0.d à rc6.d vers les services à démarrer ou arrêter.

      La solution du rc.conf, c’est une solution minimaliste, d’où son choix pour Arch, mais pas « générique ».

      « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re:

      Posté par  (site web personnel) . Évalué à 5.

      Arch ne fournie aucune facilité d'administration

      Avant il y avait au moins un installeur… Même ça ils l'ont viré maintenant :)

      • [^] # Re:

        Posté par  . Évalué à 7.

        Arch c'est le Gnome des distribs en fait ? /o\

      • [^] # Re:

        Posté par  (site web personnel) . Évalué à 4.

        Ils l’ont viré par manque de main d’œuvre, si j’ai bien compris.
        Et ça, c’est plus mortifère que systemd.

        • [^] # Re:

          Posté par  (site web personnel) . Évalué à 4.

          Et il avait besoin de main d'oeuvre parce que … ? Ah oui, parce qu'il y a eu plusieurs changements incompatibles, sans aucun intérêt pour personne, mais apparemment super importants.
          Ça me gêne pas qu'on me mette à contribution lors des mises à jour (j'ai choisi Arch pour ça), mais quand c'est pour des trucs débiles tels que :

          Je suis un petit peu de mauvaise foi par rapport à l'installeur, mais il marchait très bien depuis toujours, et je n'ai pas l'impression vu le peu de fonctionnalités qu'il avait que c'était un gros travail de maintenance.

          En tout cas c'est une situation très inquiétante, quand on arrive même plus à maintenir son propre installeur curses c'est mauvais signe.

          • [^] # Re:

            Posté par  . Évalué à 2. Dernière modification le 10 octobre 2012 à 12:25.

            Ça n'a rien de débile, c'est le cas le plus simple, mais parfois les gens doivent intervenir de manière un peu plus compliquée que ce qui est décrit (cas de /lib), ou corriger des problèmes de droits (cas de filesystem). Ce n'est pas possible d'automatiser certaines tâches parce qu'elles impliquent des changements qui ne sont pas identiques pour tout le monde.

            Sinon tu peux aussi lire les mailing lists, tout y est expliqué en long, en large et en travers, argumenté, contredit pour arriver au consensus que tu décries. N'hésite pas à y donner ton avis !

            Quand à la génération des clés, en lisant le wiki, on passe de 3 heures à 3 minutes (et encore).

  • # Archlinux

    Posté par  . Évalué à 6.

    Pour moi les spécificités d'Archlinux sont d'une part le fonctionnement en rolling release et d'autre part, comme l'a dit Tonton Benoit « aucune facilité d'administration », le choix d'un système d'init particulier n'a jamais été un des fondement de cette distribution.

    • [^] # Re: Archlinux

      Posté par  (site web personnel) . Évalué à 9.

      Tu as probablement raison.

      Il fût néanmoins un temps, où l'init BSD était fortement mis en avant dans l'auto-promotion d'Arch-linux.

      Après moult discussion ici même, il apparaît que l'init BSD était une sorte d'accident, qui n'était justifié que par un contexte particulier et ne définissait en aucun cas Arch-linux.

      C'est probablement vrai, mais on ne peut pas en vouloir aux utilisateurs d'avoir compris que Arch se définissait notamment par son init BSD.

      • [^] # Re: Archlinux

        Posté par  . Évalué à -2.

        Oui effectivement, ils vont devoir mettre à jour leur wiki :

        "Slackware et Arch sont toutes deux des distributions "simples". Les deux utilisent des scripts d'init de style BSD"

        http://wiki.archlinux.fr/Arch_vs_autres_distributions#Arch_et_Slackware

        Comment vont-ils maintenant amorcer la comparaison avec Slack ?

        Pour les aider, je propose :

        "Slackware et Arch sont toutes deux des distributions "simples". Bon, sauf pour le système d'init : nous on utilise le dernier truc super-in plus trop simple systemd et slack l'init à la BSD. Bon c'est vrai, du coup ça respecte plus trop la philosophie du KISS cet init mais tant pis, faîtes comme si"

  • # Un journal qui dénonce

    Posté par  . Évalué à 10.

    N'empêche c'est rare d'entendre un utilisateur d'archlinux se plaindre de sa distro et dire qu'il y a mieux ailleurs.

    • [^] # Re: Un journal qui dénonce

      Posté par  . Évalué à 1.

      J'ai jamais dit qu'il y avait mieux ailleurs. J'ai même dit l'inverse.

      • [^] # Re: Un journal qui dénonce

        Posté par  (site web personnel) . Évalué à 0.

        Cette distro est morte, les autres (il y en a beaucoup) ne sont pas mieux. Euh… Le problème n'est peut-être pas les distros.

      • [^] # Re: Un journal qui dénonce

        Posté par  . Évalué à 5.

        En fait tu recherches une distrib bleeding edge mais qui ne change pas trop tes petites habitudes. Archlinux ne promet en aucun cas cela et demande à ses utilisateurs un minimum d'investissement et d'adaptation. J'ai peur que ce que tu cherches soit un mouton à 5 pattes.

        Please do feed the trolls.

        • [^] # Re: Un journal qui dénonce

          Posté par  . Évalué à 3.

          Ubuntu avec des PPA
          Debian stable avec du pinning en sid
          CentOS avec rpmforge/EPEL
          FreeBSD (les packages évoluent mais le système reste le même)

          …ou Windows.

          • [^] # Re: Un journal qui dénonce

            Posté par  . Évalué à 3.

            Debian stable avec du pinning en sid

            Encore mieux : les backports. Ça apporte de nouvelles versions sans casser la distribution (installer un paquet sid implique beaucoup de chose comme mettre à jour la libc).

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Arch et systemd ça revient comme la marée

    Posté par  (site web personnel) . Évalué à 7.

    Tellement de journaux sur Archlinux depuis l’annonce de la fin du monde Sysvinit… Du coup, je me pose la question : comment vient-on à Arch ?

    Quand je m’y suis lancé, ma motivation était : rolling release.
    Pas tellement parce que marre de tout réinstaller tous les six mois, plutôt pour bénéficier des dernières fonctionnalités des programmes que j’utilise, fonctionnalités névralgiques sur certains.

    Le côté minimaliste n’était pas pour me déplaire, mais je pensais alors que je serais un utilisateur atypique, tellement la distrib avait une réputation de hackers only.

    Ben finalement, il s’est avéré que la maintenance d’Arch n’était pas si compliquée que ça. Ce n’est pas systemd qui me l’a cassé, c’est moi qui ai fait le con. Et même pas par incompétence, par étourderie.

    Pas grave. Les programmes que j’utilise sont arrivés à une maturité suffisante sur ma partition Xubuntu, Arch ne m’est plus réellement utile. Et sur sa partition, j’aurai plus vite fait d’installer autre chose, peut-être PC-BSD, que d’essayer de réparer et ensuite de comprendre systemd.

    Mais après tous ces journaux, j’en finis par me demander si au départ il n’y a pas eu un léger quiproquo. Honnêtement, cette distrib n’était pas le meilleur choix technique pour moi. Mais Scribus et TeXLive, par exemple, y étaient en avance sur les autres distributions, et ça m’était indispensable.

    Je retourne aux distribs grand public, et je me pose la question : étais-je si atypique ?
    C’est une question, ce n’est pas une réponse.
    J’ai l’impression que certains autres utilisateurs d’Arch atteignent leurs limites.

    • [^] # Re: Arch et systemd ça revient comme la marée

      Posté par  . Évalué à 1.

      Il y en a des tas d'autres qui sont "bleeding-edge" sans être rolling release…
      Je trouve que Fedora est pas trop mal, mon environnement KDE est passé du 4.8 au 4.9 récemment alors que je suis toujours sur la branche stable (la 17).
      C'est stable et sans prise de tête.

      • [^] # Re: Arch et systemd ça revient comme la marée

        Posté par  (site web personnel) . Évalué à 3.

        Je trouve que Fedora est pas trop mal, mon environnement KDE est passé du 4.8 au 4.9 récemment alors que je suis toujours sur la branche stable (la 17).

        KDE est assez unique dans cette gestion des versions, d'habitude on ne passe pas à la version supérieure durant une version de Fedora, du moins pour les gros programmes.
        Pour les programmes populaires et assez conséquents qui ont ce privilèges, il y a les programmes Mozilla, le noyau et KDE. Pas GNOME, XFCE, LibreOffice ou autres qui sont fixes.

        C'est donc un élément à savoir, cependant chaque version de Fedora intègre les dernières versions des autres logiciels, le gel se faisant assez tard (et pouvant accepter des logiciels encore en RC pour la sortie finale de Fedora, ce qui arrive souvent pour le noyau ou Eclipse…).

        • [^] # Re: Arch et systemd ça revient comme la marée

          Posté par  . Évalué à 1.

          Pour le coup je trouve ça dommage pour KDE que j'utilise avec Fedora. Le passage à la version 4.9.0 ne s'est pas fait sans douleur par rapport à la version 4.8.5 antérieure… N'y a-t-il pas moyen de contrôler ce comportement ? Ou, à défaut, avoir une liste des paquets mis à jour vers leurs versions supérieures durant une version de Fedora ?

          Et puis GNOME "pas assez populaire" pour ne pas avoir le privilège de passer à la version supérieure ? Hum… C'est un peu gros ça.

          (Si j'étais de mauvaise foi, je dirais que ça ressemble plus à un sabotage déguisé de KDE au profit de la stabilité de GNOME :o)

          • [^] # Re: Arch et systemd ça revient comme la marée

            Posté par  (site web personnel) . Évalué à 3.

            Et puis GNOME "pas assez populaire" pour ne pas avoir le privilège de passer à la version supérieure ? Hum… C'est un peu gros ça.

            Je n'ai pas dit ça. J'ai dit qu'il y avait quelques programmes populaires et conséquents qui ont ce changement de versions mais pas tous et Gnome en fait partie des exclus.
            KDE n'est pas le bureau par défaut, c'est un fait que Fedora s'intègre mieux à Gnome et qu'il est développé en pensant à cela. Du coup KDE doit avoir plus de liberté à ce niveau pour avoir le droit à la mise à jour (et surtout les mainteneurs ont envie de le afire, peut être que chez Gnome ils ne veulent pas par soucis de stabilité et de facilité pour eux).

  • # Et pendant ce temps là chez gentoo...

    Posté par  . Évalué à 6. Dernière modification le 10 octobre 2012 à 23:48.

    …il y a une poignée "d'irréductible" qui essaient une critique constructive.

    Il y a un étudiant gsoc (Xu Benda) qui a bossé sur OpenRC et une meilleure intégration avec un autre projet très sympa: Gentoo Prefix.
    Ca permet d'installer l'arbre portage en mode "unprivileged" sur différente plateforme ( comme à la pkgsrc de NetBSD):http://www.gentoo.org/proj/en/gentoo-alt/prefix/

    Bien sur, ça ne s'est pas arrêté là puisque Debian s’intéresse fortement à OpenRC: http://wiki.debian.org/OpenRC

    Résultat:

    • l'arbre de dépendance d'OpenRC est géré dynamiquement tandis que les scripts chez Debian utilisent les LSB, il y a un script qui lit les entêtes LSB pour les fournir à OpenRC.
    • Normalement OpenRC embarque avec lui les scripts réseau de Gentoo, mais il laisse la possibilité à Debian d'utiliser ses propres scripts.

    Mais ce n'est pas fini!
    Benda "s'amuse" à brancher openrc (qui n'est pas un init) à runit! http://www.awa.tohoku.ac.jp/~benda/projects/runit.html
    Mais qu'est-ce que runit? http://smarden.org/runit

    • un init
    • portable ( GNU/Linux, *BSD, Solaris)
    • qui supervise
    • léger (compilé avec dietlibc)

    Mais le plus drôle c'est s6 ! http://www.skarnet.org/software/s6/why.html
    mais qu'est-ce que s6?

    C'est en discussion pour une intégration avec openrc.

    Concernant des actions événementielles?
    Openrc a du code hotplug qu'il reste à fixer avec udev…
    … le problème reste udev:

    • il y a un fork qui peut intéresser
    • il y a des dev. qui travaille sur une possible branchement avec mdev.

    Il y encore des dev Gentoo qui déjà soignaient les scripts (pas de "bashism", "POSIX", utilisation de dash)
    et qui couple OpenRC avec busybox tout en limitant les dépendances et rendre le tout "light":
    blog.flameeyes.eu/2010/08/polishing-init-scripts
    http://blog.flameeyes.eu/2012/03/how-down-can-you-strip-a-gentoo-system
    Certains essaient de convaincre chez FreeBSD

    Il y a de quoi s'amuser, tester … puis comparer.

Suivre le flux des commentaires

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