Journal Archlinux va passer à systemd : appel à volontaire pour maintenir SysVinit

Posté par . Licence CC by-sa
21
6
oct.
2012

Archlinux utilisera prochainement systemd par défaut, en remplacement du vénérable système d'initialisation SysVinit. Cette migration n'est pas encore effective, les bénévoles qui maintiennent la distribution la préparent actuellement.

Conscients qu'un nombre significatif d'utilisateurs regrettent cette décision, les développeurs d'Archlinux lancent un appel à volontaire pour maintenir SysVinit (il sera également nécessaire de compiler des versions spécifiques de certains logiciels*).

Si la maintenance de SysVinit est rigoureuse et suivie dans le temps, les utilisateurs d'Archlinux auront le choix entre systemd (la solution par défaut) et SysVinit.

Ainsi, le maintien de SysVinit dans Archlinux semble possible … il « suffit » que quelqu'un fasse le travail nécessaire ! 😊

* Les développeurs d'Archlinux estiment que, prochainement, certains logiciels nécessiteront systemd. Les utiliser en l'absence de systemd pourrait néanmoins être possible, en recompilant les logiciels avec des options spécifiques.

  • # Utilité

    Posté par . Évalué à  2 .

    Cela me semble être une peine perdue si la plupart des autres distributions GNU/Linux passent à systemd. Selon moi c'est un peu du même ordre que vouloir maintenir Gnome 2. Si certains refusent systemd pour des raisons techniques il leur reste Debian (mais pour combien de temps encore…) et sinon les BSD. J'ai pas testé PC-BSD (basé sur freebsd) depuis un moment mais j'imagine que ça n'a pas forcément beaucoup à envier à une distribution GNU/Linux sur le coté user friendly pour le desktop de l'utilisateur lambda.

    • [^] # Re: Utilité

      Posté par . Évalué à  -1 . Dernière modification : le 06/10/12 à 00:23

      Euh, c’est quoi le problème si les autres distributions passent à systemd ? Tu veux dire que c’est un peu du même ordre que de maintenir pacman alors que les autres distributions utilisent rpm/apt ?

      Quel rapport entre systemd et passer à Debian ? Je crois que tu n’as pas bien compris l’intérêt de Arch… De même pour les BSD. À t’entendre on a l’impression qu’utiliser un noyau Linux sans utiliser systemd est une hérésie qui doit être supprimée.

      Merci pour ton avis sur le côté user-friendly pour l’utilisateur lambda de PC-BSD, mais là encore ça ne concerne pas les gens intéressés par cet appel à contribution.

      • [^] # Re: Utilité

        Posté par . Évalué à  5 . Dernière modification : le 06/10/12 à 01:09

        Tu veux dire que c’est un peu du même ordre que de maintenir pacman alors que les autres distributions utilisent rpm/apt ?

        Non j'ai parlé de Gnome 2. Un système de gestion de package c'est un peu l'âme d'une distribution, ce n'est pas pareil. Comme le dit Sylvain Blandel ça représente un surcroît de travail, non négligeable selon moi. De plus, si je ne dis pas de bêtise, systemd permet de profiter de certaines features de Linux.

        Quel rapport entre systemd et passer à Debian ?

        Debian reste sur SysVinit car elle supporte le noyau kfreebsd.

        Je crois que tu n’as pas bien compris l’intérêt de Arch…

        Peut-être. J'ai testé Archlinux mais je l'utilise vraiment très rarement. Pour moi l'intérêt c'est la rolling release, il y a peu de distributions de ce type.

        ça ne concerne pas les gens intéressés par cet appel à contribution

        Oui. Pardonne moi de donner mon avis sur cet appel…

    • [^] # Re: Utilité

      Posté par . Évalué à  9 .

      Si certains refusent systemd pour des raisons techniques il leur reste Debian (mais pour combien de temps encore …)

      À l'heure actuelle, les distributions qui utilisent systemd par défaut sont :

      Archlinux utilisera bientôt systemd par défaut, de même que la future version 7 de Red Hat Enterprise Linux (d'après cette dépêche).

      À l'heure actuelle, Debian, Ubuntu, Gentoo et Slackware n'utilisent pas systemd par défaut. L'utilisation de systemd par Debian semble improbable pour l'instant.

      c’est quoi le problème si les autres distributions passent à systemd ?

      Il me semble que systemd devient une solution générique pour l'initialisation du système et la gestion des services. Une distribution peut parfaitement se passer de cette solution générique, elle devra pour cela fournir un surcroît de travail (maintenir seule des trucs qui ne seront pas maintenu upstream).

  • # SysV rc

    Posté par (page perso) . Évalué à  4 .

    Attention, systemd n'est pas un remplaçant pour SysV init seul. SysV init, c'est le premier processus, qui lance ce qu'on lui demande dans /etc/inittab, soit très peu de chose. Il lance notamment SysV rc, qui lui va lancer tous ce qui se trouve dans /etc/rc?.d/.

    systemd est un remplaçant pour SysV init et SysV rc.

    • [^] # Re: SysV rc

      Posté par . Évalué à  6 .

      Il lance notamment SysV rc, qui lui va lancer tous ce qui se trouve dans /etc/rc?.d/.

      Pas sous Arch.

      Sous Arch il lance /etc/rc.sysinit qui lui va lancer les scripts contenu dans /etc/rc.d/ en fonction de la variable d’environnement $DAEMON du /etc/rc.conf. Une fois celà fait, /etc/rc.sysinit va lancer /etc/rc.local.

      • [^] # Re: SysV rc

        Posté par (page perso) . Évalué à  2 .

        Ça ressemble à file-rc. Comme je ne le disais pas, SysV init peut lancer un autre outil de démarrage que SysV rc.

      • [^] # Re: SysV rc

        Posté par (page perso) . Évalué à  -1 .

        Le système de boot /etc/rc.d/ est un héritage du monde BSD like et UNIX (si je ne m'abuse), que l'on retrouve sur slackware et arch.

        • [^] # Re: SysV rc

          Posté par . Évalué à  2 .

          Pourquoi est-ce que tu me dis ça ?

    • [^] # Re: SysV rc

      Posté par . Évalué à  2 .

      Attention, systemd n'est pas un remplaçant pour SysV init seul. SysV init, c'est le premier processus, qui lance […] notamment SysV rc

      […]

      systemd est un remplaçant pour SysV init et SysV rc.

      Y a-t-il un terme pour désigner l'association SysV init + SysV rc ?

      Le terme SysV aurait convenu, mais il désigne déja un système d'exploitation. 😞

  • # systemd ! Tant de complexité pour un moins bon fonctionnement…

    Posté par . Évalué à  2 .

    Dernièrement j’ai lancé l’arrêt d’une Fedora 17 et j’ai éteint l’écran.
    Quand je l’ai rallumé une vingtaine d’heures plus tard, la machine était toujours bloquée sur l’arrêt.
    Accessoirement, comme la Fedora s’est encore « améliorée » avec la 17, les messages d’arrêt des services (qu’on voit aussi bien sur une Fedora 15 que sur une Arch avec systemd) ne s’affichent plus (et j’ai vérifié toutes les consoles).

    J’avais déjà constaté avec Arch le problème de certains services qui partaient en sucette pendant plusieurs minutes quand systemd essayait de les arrêter, comme syslog-ng (remplaçable) ou à un moment Network Manager (difficilement remplaçable ; à l’essai wicd fonctionne moins bien). Ça m’avait conduit à repasser à l’init normale.

    Pourtant, je n’avais jamais constaté un tel problème avec la Fedora 15 (et je l’ai mise sur plus de 100 postes pendant un an), qui utilise systemd aussi, mais uniquement en mode compatible (avec les anciens scripts de /etc/rc.d/init.d).
    Il faut croire que ce n’est pas une question d’ordre d’arrêt qui serait inapproprié, mais plutôt que la manière super-fine de systemd de gérer les services pose des problèmes pour l’arrêt et pire, qu’il n’y a pas de timeout de prévu au cas ou un service ne se terminerait pas !

    Autant systemd, sur le papier, c’est intéressant.
    Autant, dans la pratique, c’est une calamité.

    Si seulement Lennart n’était pas si occupé à intégrer tout le reste du système dedans, il pourrait peut-être fiabiliser l’existant…

    Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

      Posté par . Évalué à  3 .

      Si seulement Lennart n’était pas si occupé à intégrer tout le reste du système dedans, il pourrait peut-être fiabiliser l’existant …

      Oh putain, que c'est vrai ! 😄

      D'après le wiki d'Archlinux, systemd gère (entre autres) le montage des systèmes de fichiers distants, et l'ACPI. Et il propose un équivalent à readahead.

      Avant de s'occuper de tout ça, il me semble que systemd devrait déjà faire parfaitement son boulot : démarrer et arrêter le système, lancer et arrêter les services.

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  3 .

        Avant de s'occuper de tout ça, il me semble que systemd devrait déjà faire parfaitement son boulot : démarrer et arrêter le système, lancer et arrêter les services.

        Et comment s'occuper des services sans monter les filesystems ? Tu as un truc ?

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

        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

          Posté par . Évalué à  0 .

          Et comment s'occuper des services sans monter les filesystems ?

          C'est juste.

          Reste que systemd se propose de gérer l'ACPI, les logs ainsi que le readahead. À mon humble avis, systemd serait plus robuste s'il se contentait de son « cœur de métier » : démarrer et arrêter le système, lancer et arrêter les services.

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  3 .

            Pas faux, mais tout ça ce sont des unités de systemd au même titre que les autres services :

            $ find /lib/systemd -name '*service'  | grep -E "acpi|journal|readahead"
            /lib/systemd/system/systemd-journald.service
            /lib/systemd/system/sysinit.target.wants/systemd-journald.service
            /lib/systemd/system/systemd-readahead-done.service
            /lib/systemd/system/systemd-readahead-collect.service
            /lib/systemd/system/acpid.service
            /lib/systemd/system/systemd-readahead-replay.service
            
            

            Il ne les gère donc pas différemment des autres, ce n'est pas le même démon qui s'occupe de ça et des arrêts du système.

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

    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

      Posté par . Évalué à  10 .

      Un certain Linus T. aimerait aussi quelques explications et recherche un certain Lennart ou un certain Kay pour un problème avec udev qui soit disant en fait ce serait pas de sa faute mais de celle du noyau….
      Avis de recherche sur la LKML

      Et sinon petit florilège :

      Stop this crazy. FIX UDEV ALREADY, DAMMIT.
      Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

      Stop this idiocy.
      The kernel doesn't have a lockup problem. udev does.

      Ca balance en ce moment :)

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  10 . Dernière modification : le 06/10/12 à 16:05

        Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.

        L'histoire se tient à propos du chargement des firmwares dans le noyau. Udev avec les nouvelles versions est très lent à les charger et ça fout la merde…
        Depuis le mois d’août, il y a eu des patchs mais Kay n'en tient pas compte, limite il s'en fout…
        Le pire, il accuse le noyau d'avoir des bugs … et ça gonfle clairement Linus.

        Résultat des comptes, pour le chargement des firmwares et probablement des modules, le noyau risque de complètement outrepasser udev. La raison? Des mainteneurs qui en font qu'à leurs têtes et inefficaces.

        Si vous n'aimez ce que devient udev en ce moment, prenez un sachet de pop-corn et lisez la LKML. Perso, j'ai fini mon sachet sans m'en rendre compte!
        Quelques perles spéciales Linus:

        Le meilleur reste celui de nix qui résume bien ce que devient udev.

        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

          Posté par . Évalué à  5 .

          Je pertinente même si ton début de message laisse penser que je balance sur systemd, je dis bien qu'il s'agit d'udev :-p

          J'aime bien aussi cette remarque d'Alan Cox :

          Just fix udev, and if you can't fix it someone please just fork the last working one.

          Mais c'est clair que ça gonfle Linus (pas que lui d'ailleurs) et je pense que c'est pour ça qu'il fait cet appel :

          Who maintains udev these days? Is it Lennart/Kai, as part of systemd?

          Vu qu'avec Kay c'est du n'importe quoi, il espère qu'un interlocuteur de systemd (notamment Lennart) intervienne sur ce sujet, vu qu'udev devient lié à systemd.

          En tout cas vu de loin c'est bien marrant (même si au final ça donne un peu raison à tous les détracteurs des évolutions actuelles :-/ ).

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  3 . Dernière modification : le 06/10/12 à 16:34

            Salut,
            Personnellement je ne suis pas Archiste. J'ai personnellement rien contre systemd à la condition que l'on ne me l'impose pas. Je suis sous OpenRC (Gentoo) et ça me convient… Le truc que je n'aime pas particulièrement ces derniers temps est udev, car le nouveau truc à la mode c'est de considérer que /usr doit être sur la même partoche que / sinon ça boote pas! ( ou bien avec une initramfs)
            Maintenant que udev est mergé avec systemd… on peut considérer que c'est un même projet.

            Pour l'instant on n'a pas vu Lennart mais je doute qu'il passe…

            Il y en a des très croustillants:
            Yes, doing it in the kernel is "more robust". But don't play games,
            and stop the lying. It's more robust because we have maintainers that
            care, and because we know that regressions are not something we can
            play fast and loose with. If something breaks, and we don't know what
            the right fix for that breakage is, we revert the thing that broke.
            .

            Le meilleur reste Nix

            • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

              Posté par . Évalué à  2 .

              Étant moi-même sous Gentoo depuis 10 ans, je partage ton avis et je suis bien content de rester pour l'instant avec OpenRC.

              D'ailleurs le problème soulevé ici n'est pas tant la qualité de l'un ou l'autre des logiciels, c'est qu'ils soient liés (au sens relation symbiotique).

              Et comme le dit Nix, autant avant udev pouvait obliger les autres à s'adapter autant là ça commence à aller un peu trop loin….

            • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

              Posté par . Évalué à  -1 .

              le nouveau truc à la mode c'est de considérer que /usr doit être sur la même partoche que / sinon ça boote pas!

              En même temps, je n'ai jamais compris à quoi pouvait servir de mettre /usr sur une autre partition. C'est le meilleur moyen d'être emm*rdé si le système est en vrac et qu'on n'a que la racine.

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

              • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                Posté par (page perso) . Évalué à  4 .

                Et donc, sous prétexte que tu n'en vois pas l'intérêt, il faut l'interdire ?

              • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                Posté par . Évalué à  7 . Dernière modification : le 08/10/12 à 17:45

                Non, j'attends juste qu'on m'explique en quoi ça peut être utile :-)

                J'ai des /usr sur du lvm2, raid et pour certains montages en nfs…avec la racine en dehors de ces technos… mais tout cela importe peu…

                Personnellement, ceux que je ne comprends pas, ce sont "les détracteurs" d'un /usr séparé de la racine, qui prennent l'argument historique pour assoir leur affirmations.

                L'objectif suivant Fedora c'est de déplacer /bin /sbin /lib en les plaçant dans /usr sous prétexte qu''historiquement l'ensemble /lib, /bin /sbin étaient là pour bootstrapper le système par manque d'espace.
                En effet, sur le pdp11, Unix fonctionnait sur une paire de disque RK05 de 1.5Mo chacun.
                Un seul était insuffisant pour contenir tout le système. Le 2ème disque contenait "/usr" mais /usr à cette époque contenait les données utilisateurs et les binaires utilisateurs:

                • "It is common for the totality of user files to be too voluminous
                  for a given device. It is then impossible for the directories of
                  all users to be members of the same directory, say /usr. Instead
                  they must be split into groups, say /usr1 and /usr2;" D.Ritchie p.1953-1954 Bell System Technical Journal (juillet-Août) 1978 UNIX Time-Sharing System: A Retrospective.

                • Il y a également des indices dans le papier de Bourne UNIX Time-Sharing System: The UNIX Shell même époque où le PATH de l'utilisateur s'écrit comme PATH=:/usr/fred/bin:/bin:/usr/bin

                /usr à commencer à perdre son sens ( d'ailleurs personne ne comprends à l'heure actuelle la signification de usr: Unix ressources, User ressources…) à partir du moment où /home est apparu (données utilisateurs) et qu'on a commencer à mettre des applis systèmes dedans:

                • "This directory [/usr] used to be the other file system on a UNIX machine. In the System V ABI it has lost most of its importance. The ABI states uses only for /usr/bin and /usr/share, and the name /usr has lost its original meaning: the ABI specifies /usr only as a location for system files that users may wish to access. "Chapitre 4 du livre de Greg Lehey: Porting Unix Software

                /usr n'a plus de sens, pourquoi le garder? En plus si c'est pour dire http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken:
                "The duty of the minimal boot system that consisted of /bin, /sbin and /lib on traditional Unix, has been taken over by the initramfs of modern Linux."
                Ha bah! alors, mettons tout le sytème de boot et la racine dans une initramfs alors, puisque c'était le but initial de /lib /sbin /bin … pour au final ne garder que /boot avec le noyau et l'initramfs et /others pour tout le reste sur un disque!

                et enfin arrêtons d'appeler systemd/udev un system d'init dans ce cas ( l'init c'est initramfs qui va se charger du montage) mais plutôt un controlleur de démons: "An initramfs that supports mounting /usr on top of / before it starts 'init'"

                La plupart des systèmes comme OpenBSD, NetBSD, Freebsd (hier(7)) definissent ce qu'on attend dans /usr "Contains the majority of user utilities and applications." Ca marche, c'est pratique, c'est rodé et le système boot sans initramfs! Je peux mettre n'importe quel filesystem dans /usr. En quoi c'est plus chiant à faire sur linux?

                D'ailleurs, comment est l'arborescence dans Plan 9?

                • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                  Posté par . Évalué à  0 .

                  J'ai toujours pas compris ce que ça peut apporter. Un exemple réel avec les avantages, ça ne serait pas de trop.

                  Personnellement, ceux que je ne comprends pas, ce sont "les détracteurs" d'un /usr séparé de la racine, qui prennent l'argument historique pour assoir leur affirmations.

                  Je n'ai jamais pris l'argument historique (je ne le savais même pas). Je prends l'argument de l'utilité : à quoi ça peut servir ? Peut-être qu'il y a un usage qui se justifie parfaitement, mais je n'en vois aucun.

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

                  • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                    Posté par . Évalué à  4 .

                    • LVM2 avec /usr dedans, tu adaptes la taille /usr à la volée sans te poser la question d'un quelconque partitionnement initial par exemple.
                    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                      Posté par . Évalué à  -1 .

                      Je répete : pour quoi faire ? Là, tu me donnes un moyen, pas une raison.

                      À ce compte-là, on peut tout faire : je peux mettre /usr/share/doc dans un volume à part, mais ça ne sert à rien.

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

                      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                        Posté par . Évalué à  1 .

                        souplesse,administration simplifiée
                        Pouquoi /usr et pas une sous-arborescence (si j'anticipe)?
                        * pourquoi pas? on laisse le choix, c'est flexible: si tu as envie tu peux, si tu veux rester simple tu peux aussi.
                        * 1 ligne sur le fstab
                        * migration plus simple aussi
                        * partage entre machine virtuelle simplifée
                        * mise à jour plus simple

                        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                          Posté par . Évalué à  1 .

                          souplesse,administration simplifiée

                          souplesse : je veux bien (encore que j'ai toujours pas vu l'intérêt)
                          administration simplifiée : ben non puisque ça fait un volume en plus.

                          Pouquoi /usr et pas une sous-arborescence (si j'anticipe)?

                          Ben oui, pourquoi ? Je ne vois pas l'intérêt non plus pour une sous arborescence.

                          • pourquoi pas? on laisse le choix, c'est flexible: si tu as envie tu peux, si tu veux rester simple tu peux aussi.

                          Je ne dis pas « il ne faut pas le faire », je dis « à quoi ça sert ? ». C'est pas pareil.

                          • 1 ligne sur le fstab

                          Euh c'est censé être une raison ?

                          • migration plus simple aussi
                          • mise à jour plus simple

                          En quoi ? Dans tous les cas, tu mets ta racine à jour avec, donc quel intérêt ? Tu as un exemple plus terre à terre ? Parce que là je ne vois pas trop :-/

                          • partage entre machine virtuelle simplifée

                          OK pour la VM, ça peut être intéressant. Mais pas besoin de la monter à part sur l'hôte pour ça. Un bind ou un export NFS suffit.

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

                          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                            Posté par . Évalué à  1 .

                            Le fait d'avoir une partition /usr m'a bien servi quelques fois, quand elle ne pouvait plus être montée (coupure de courant…). J'avais du coup droit à un environnement minimal pour la réparer au lieu d'un bref "cannot find root partition".

                            Il faut dire qu'à l'époque je n'utilisais pas d'initrd, maintenant c'est peut-être moins utile s'il y a tout ce qu'il faut dedans.

                  • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                    Posté par (page perso) . Évalué à  5 .

                    J'ai toujours pas compris ce que ça peut apporter. Un exemple réel avec les avantages, ça ne serait pas de trop.

                    Monter /usr (ainsi que /lib et quelques autres) en NFS en lecture seule, pour avoir une seule install d'un OS pour toutes les machines d'un réseau donné.
                    C'est un cas parfaitement réel.

                    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                      Posté par . Évalué à  -1 .

                      Mais dans ce cas pas question d'utiliser une distribution à base de paquets, car la DB des paquets installés est dans /var et ça va être impossible de faire correctement les mises à jour.
                      Il faut obligatoirement avoir installé les systèmes à la main (LFS, peut-être gentoo) et maintenir le /usr commun à la main également pour être sur qu'il est auto-contenu et ne dépend pas de choses qu'il faudrait remettre sur chacune des machines qui le partagent.

                    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                      Posté par . Évalué à  0 .

                      Pas besoin de monter /usr à part pour ça. Tu peux exporter un répertoire en NFS sans qu'il soit sur son propre volume.

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

                      • [^] # /usr sur NFS

                        Posté par . Évalué à  5 .

                        Ce n’est pas pour la machine maître que ça pose problème, c’est pour les autres.

                        Après, on peut envisager qu’elles aient un /usr minimal pour démarrer et qu’ensuite elles montent la version NFS par dessus, mais ce sera moins pratique si tu as à mettre à jour un des programmes qui sont le le /usr local.

                        Je n’utilise pas personnellement (entre autres, parce que les distributions Linux ne m’ont jamais semblé très adaptées à cette optique), mais ça me semble un choix légitime.

                        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

          Posté par . Évalué à  10 .

          Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.

          En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
          Sauf que bien sur du coup charge au kernel de
          a) comprendre que l'on a chargé un nouveau firmware
          b) surveiller les étapes de chargement
          c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
          d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)

          Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).

          Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  3 .

            (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).

            C'est Tanenbaum qui va être content… :)

            Moi j'ai un truc que je ne comprends pas… il n'est pas possible de faire quelque chose de modulaire avec udev? Si on respecte "un modèle en couche" propre, a priori c'est udev qui fournit un service à init, systemd, etc… pourquoi absolument privilégier une dépendance forte?

            D'ailleurs, Kaane, comme tu touches souvent du FreeBSD… il y a devd pour le remplissage à chaud de nouveau noeuds de périphériques. Tu as regardé le code? C'est une interface stable, non?
            De ce que j'ai regardé, c'est simple, propre (mais c'est mon avis), ça fait son travail et ça semble stable sur le temps… c'est quoi le problème avec udev? Ce serait vraiment Sievers/Lennart?

    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

      Posté par (page perso) . Évalué à  6 .

      Autant systemd, sur le papier, c’est intéressant.
      Autant, dans la pratique, c’est une calamité.

      C'est pas ce qui caractérise les projets menés par Lennart ca ?

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  10 .

        Il ne faut pas généraliser.

        PulseAudio, même sur le papier, c’est une usine à gaz rajoutée par dessus Alsa, alors que la principale justification de PulseAudio est qu’Alsa ne donnerait pas satisfaction. Cherchez l’erreur…

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

          Posté par . Évalué à  9 . Dernière modification : le 06/10/12 à 18:16

          En effet.

          Jusqu'à récemment, j'avais cherché à éviter pulseaudio comme la peste sur ma machine. Les raisons étant que :

          • Alsa fonctionnait parfaitement, et ce malgré une utilisation intensive (jeu sous wine + vidéo flash + musique + sons système + appel skype + conférence mumble).
          • Pulseaudio ne fonctionnait pas correctement, voire pas du tout, avec des logiciels qui n'avaient pas de son quand d'autres en avait, avec un son muet parfois, avec des plantages dans tous les sens sous KDE.

          Bref, Alsa me convenait tout à fait, donc je me fichais de ce pulseaudio pourri que j'avais désinstallé.

          Sauf que voilà, dans sa version 4.0, Skype ne fonctionne correctement qu'avec Pulseaudio (avec Alsa, faire un appel ou aller dans les options fait planter Skype). La première chose que j'ai fait a été de revenir à l'ancienne version de Skype, mais pour une raison que j'ignore, le fait d'avoir installé Skype 4.0 m'a également flingué les versions précédentes (mêmes plantages).

          En désespoir de cause, avant de réinstaller ma machine, j'ai donc redonné sa chance à Pulseaudio. Après tout, tant qu'à devoir tout réinstaller, autant en profiter pour tester des trucs bien merdiques avant.

          Au premier abord, l'intégration de Pulseaudio avait été améliorée. J'avais enfin du son dès le démarrage et plus aucun plantage du système audio sous KDE. Skype fonctionnait de nouveau, ainsi que grosso-modo l'ensemble de mes applications. J'ai donc repoussé la réinstallation, et ça fait maintenant quelques semaines que j'utilise mon système avec Pulseaudio. Voilà mon bilan de simple utilisateur.

          • Pulseaudio me gonfle, il m'a remplacé tous les curseurs de gestion des canaux de ma carte son par un seul. Je ne peux donc plus (facilement ?) gérer les aigus et les graves, la puissance du caisson de basse ou encore la répartition du son sur mes hauts-parleurs 5.1.
          • Pulseaudio me gonfle encore plus, car le curseur de réglage correspond au canal PCM, donc, pousser le volume à fond signifie pousser le canal PCM à fond. Or, cela engendre des parasites sur mes hauts-parleurs, un souffle permanent et particulièrement désagréable. Avec Alsa, je plaçais le canal PCM à 80% (seuil en-deçà duquel on n'entendait plus aucun souffle parasite), et je pouvais faire mumuse avec toutes les jauges – même la jauge principale – sans jamais souffrir le moindre parasite.
          • Pulseaudio me gonfle à l'extrême, car non seulement il a viré mes jauges de réglage du son, mais en plus, il m'en ajoute dynamiquement quand je lance des applications. Par exemple, lorsque je lance Kaffeine, j'ai en plus de la jauge général une nouvelle jauge qui apparaît et qui permet de régler indépendamment le volume sonore de Kaffeine. Super hein ! Mais à quoi ça me sert ? Kaffeine n'a-t-il pas déjà une jauge de réglage du son ? Ah ben si… Donc en fait, Pulseaudio ça ne fait qu'enlever des jauges essentielles pour rajouter des jauges inutiles ?
          • Pulseaudio est une sombre merde qui me balance un son à la puissance diminuée. Je ne sais même pas comment c'est possible, mais je suis désormais obligé de pousser les jauges et le système sonore à fond pour regarder décemment certains films, alors qu'auparavant avec Alsa, pousser le volume (le bouton physique) du système sonore à plus de la moitié réveillait mon quartier sous une pluie de tuiles. J'ai regardé dans alsaconf, et tout est à 100%… Et forcément en revenant à Alsa en virant Pulseaudio, je retrouve mon son d'avant, donc c'est bien Pulseaudio le coupable.
          • Pulseaudio me fait merder des applications, notamment celles qui n'utilisent pas Pulseaudio. Par exemple, lorsque Xine est configuré pour utiliser le moteur Alsa, faire une pause sur une vidéo dans Kaffeine induit un délai de ~2 secondes avant que la pause ne soit effective, et sortir la vidéo de sa pause provoque un délai de ~2 secondes durant lequel la vidéo est muette, bien que se déroulant.
          • Incidemment, régulièrement Kaffeine crashe en changeant de vidéo. En configurant Xine pour utiliser pulseaudio, on règle le problème de lag, et on réduit la fréquence des crashs de manière importante, mais ils ne disparaissent pas ! Alors qu'avec Alsa (et sans Pulseaudio), je n'avais ni crash ni lagg !
          • De même, en utilisant Pulseaudio, j'ai des films en .mkv qui ont une bande son complètement foirée : on n'entend plus les dialogues, seulement la musique et les effets spéciaux.
          • C'est désormais une plaie sans nom pour faire fonctionner certains jeux, que ce soit d'anciens jeux prévus pour tourner sous Linux, ou des jeux plus récents prévus pour Windows et qui tournent sous Wine.
          • etc.

          Bref, je compte réinstaller ces prochains jours, lorsque j'aurais fait le tour de tous les tests pouvant compromettre mon système que j'avais depuis longtemps envie de faire. Et il va sans dire que les paquets Pulseaudio seront dans la blacklist.

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  1 . Dernière modification : le 09/10/12 à 14:56

            J'ai regardé dans alsaconf, et tout est à 100%

            des souvenirs qu'il me reste du peu de temps pendant lequel j'ai supporté pulse audio, j'avais trouvé le moyen en ouvrant les préférences avancées de pulse de dépasser les 100%… bah oui, Lennart s'est dit que mettre le son à fond ça pourrait déranger les voisins alors il change le max de nos systèmes… le max de pulse ne correspond donc plus au max de ton matériel.

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  1 . Dernière modification : le 09/10/12 à 19:29

            Pour ma part, j'aime pas mal PulseAudio (principalement pour le volume sonore propre à chaque application : Sous Alsa, modifier le volume de Audacious modifie le volume PCM ou Master, donc ça affecte tout le monde : pas cool !)

            Mais j'ai dû (encore) le virer pour deux raisons :
            - Ça ne fonctionne pas avec Timidity (qui utilise ALSA), qu'il soit lancé en daemon ou non. Mon MIDI devient muet. Et ça, ça m'emmerde grave quand je veux l'entendre dans DOSBox ou ScummVM. Et pourtant, cette fois-ci, la dernière fois, ça avait fonctionné pendant un temps. Vraiment bizarre.
            - Aléatoirement, si xfce4-volumed a été démarré avant PulseAudio lors de l'ouverture de la session, je n'ai pas de son (la carte son est remplacée par une "sortie factice" !). Je suis obligé de tuer xfce4-volumed, et de redémarrer dans l'ordre PulseAudio, et ensuite xfce4-volumed.

            Le plus bizarre, est que je n'ai aucun de ces problèmes sous *buntu (je suis sous Archlinux) !

            edit : Ah tiens, dans les préférences du module de sortie ALSA de Audacious, j'ai mis le 'mélangeur' sur autre chose : 'Speaker', et ça n'affecte plus que Audacious. Pas propre, mais c'est résolu. J'ai rien dit!

    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

      Posté par (page perso) . Évalué à  -1 .

      Et ben moi bizarrement, depuis que j'ai migré sous systemd, je n'ai aucun problème à signaler, tout fonctionne comme prévu.

      Par contre, si ton pc ne s'arrête pas ou de façon aléatoire, c'est de la faute du noyau, enfin peut être plus de la faute de certains matériels.

      En gros, il faut rajouter reboot=bios dans les paramètres du noyau et cela fonctionne tout le temps. J'ai vu ce bug d'arrêt aléatoire sur énormément de matos Dell et un peu de HP.

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  4 .

        reboot=bios ne marche que pour des archi. bien spécifiques et notamment x86. [1]
        D'ailleurs, ce shutdown est un gros hack pour les machines Dell comme tu le dis [2]
        Il n'y a pas ce hack dans le code x86_64… apparemment, il faut repasser en mode 32 bit pour l'activer.[3]

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  1 .

        moi de même, strictement aucun problème avec des Mageia 2. Avant SystemD, il se pouvait que mon ordi ne s'éteigne pas également …

        Je tiens à signaler quand même, qu'un des effet de bord sympa de SystemD, c'est la vitesse de boot : j'arrive à 8 secondes avec un core/1 giga sous VirtualBox avec une Mageia 3 (sans compter l'initrd de 2 secondes).

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  2 .

        Et ben moi bizarrement, depuis que j'ai migré sous systemd, je n'ai aucun problème à signaler, tout fonctionne comme prévu.

        Ça m’a fait ça aussi au début, enfin après que je passe de syslog-ng à rsyslog. Puis c’est Network Manager qui a eu une période à vide. Puis ça a été le nettoyage de /tmp (placé sur une partition dédiée) qui ne s’est plus fait (eh oui, systemd prend aussi ça en charge). Tout de suite, ça a l’air de bien marcher (sur Arch), mais bon…
        Ça fait longtemps que tu as migré ?

        Par contre, si ton pc ne s'arrête pas ou de façon aléatoire, c'est de la faute du noyau, enfin peut être plus de la faute de certains matériels.

        Si c’était l’appel à l’extinction ou au redémarrage matériel qui ratait, je ne pourrais pas changer de console et ça ne se débloquerait pas au bout de 5 ou 15 mn, ce qui arrive assez souvent (le blocage persistent, c’est quand même l’exception ; une fois sur deux, ça s’arrête même en temps normal, génial, non ?).

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par (page perso) . Évalué à  1 .

        Systemd marche vraiment bien ici aussi.

        Et mieux encore, j'ai un vieux portable sur lequel ça fait des années que la mise en veille ne marchait plus, que ce soit avec pm-utils, uswsusp et leurs amis, rien à faire, le portable ne réussissait jamais à se réveiller, malgré mes efforts les plus sincères. J'en étais arrivé à la conclusion que c'était un problème matériel.

        Eh bien, depuis le passage à systemd (qui, entre autres choses, gère l'ACPI), ça remarche. Sans rien faire. Vexant !

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par (page perso) . Évalué à  4 .

        Systemd marche bien aussi sous Arch sur mon vieux portable (un Toshiba Satellite A40 Pro). Par contre, si je gagne en temps à l'arrêt de la machine, je ne gagne rien au démarrage comparé à l'init classique (dans lequel j'avais déjà parallélisé le lancement des daemons dans rc.conf).

        A côté de ça, si le démarrage et l'arrêt des services via des fichiers de propriétés à-la-ini est sympa, ça devient vite abscons dès qu'il s'agit de jouer avec des .target et des dépendances dans les .service (par exemple dépend de truc mais peut démarrer en même temps mais doit attendre que truc ait fini pour finir lui aussi (ouf), etc.) -> bref une complexité qui me laisse perplexe comparé aux besoins (ici le démarrage des services).

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  -1 .

        Pour ma part, systemd fonctionne très bien. C'est :
        - facile à configurer ( sudo systemctl enable/disable , et voilà! On peut faire un start/ restart/ stop ensuite si on est pressé),
        - facile de surveiller (d'autant que systemctl accepte de nombreux filtres en arguments) :
        > $ systemctl
        > UNIT LOAD ACTIVE SUB JOB DESCRIPTION
        > proc-sys…misc.automount loaded active waiting Arbitrary Executable File Formats File System Automount Point
        […]
        > cronie.service loaded active running Periodic Command Scheduler
        > cups.service loaded active running CUPS Printing Service
        > dbus.service loaded active running D-Bus System Message Bus
        > getty@tty1.service loaded active running Getty on tty1
        > lightdm.service loaded active running LightDM Display Manager
        > network.service loaded active running Legacy unit for network
        > NetworkManager.service loaded active running Network Manager
        > rc-local.service loaded active exited /etc/rc.local Compatibility
        > syslog-ng.service loaded active running System Logger Daemon
        > systemd-journald.service loaded active running Journal Service
        > systemd-logind.service loaded active running Login Service
        > systemd-…s-load.service loaded active exited Load Kernel Modules
        > systemd-…unt-fs.service loaded active exited Remount Root and Kernel File Systems
        > systemd-sysctl.service loaded active exited Apply Kernel Variables
        > systemd-…-setup.service loaded active exited Recreate Volatile Files and Directories
        > systemd-…rigger.service loaded active exited udev Coldplug all Devices
        > systemd-udevd.service loaded active running udev Kernel Device Manager
        > systemd-…ssions.service loaded active exited Permit User Sessions
        > systemd-…-setup.service loaded active exited Setup Virtual Console
        > udisks2.service loaded active running Storage Daemon
        > upower.service loaded active running Daemon for power management
        > wpa_supplicant.service loaded active running WPA supplicant
        > cups.socket loaded active running CUPS Printing Service Sockets
        > dbus.socket loaded active running D-Bus System Message Bus Socket
        > syslog.socket loaded active running Syslog Socket
        > systemd-initctl.socket loaded active listening /dev/initctl Compatibility Named Pipe
        > systemd-journald.socket loaded active running Journal Socket
        > systemd-shutdownd.socket loaded active listening Delayed Shutdown Socket
        > systemd-…control.socket loaded active listening udev Control Socket
        > systemd-…-kernel.socket loaded active running udev Kernel Socket
        > arch-daemons.target loaded active active Arch Daemons
        > basic.target loaded active active Basic System
        > bluetooth.target loaded active active Bluetooth
        > cryptsetup.target loaded active active Encrypted Volumes
        > getty.target loaded active active Login Prompts
        > graphical.target loaded active active Graphical Interface
        > local-fs-pre.target loaded active active Local File Systems (Pre)
        > local-fs.target loaded active active Local File Systems
        > multi-user.target loaded active active Multi-User
        > network.target loaded active active Network
        > remote-fs.target loaded active active Remote File Systems
        > sockets.target loaded active active Sockets
        > sound.target loaded active active Sound Card
        > swap.target loaded active active Swap
        > sysinit.target loaded active active System Initialization
        > syslog.target loaded active active Syslog
        > systemd-…es-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
        >
        > LOAD = Reflects whether the unit definition was properly loaded.
        > ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
        > SUB = The low-level unit activation state, values depend on unit type.
        > JOB = Pending job for the unit.
        >
        > 76 loaded units listed. Pass --all to see loaded but inactive units, too.
        > To show all installed unit files use 'systemctl list-unit-files'.

        (sans oublier la commande journalctl),
        - bien plus rapide que SysV (même sur un SSD),
        - fiable (au contraire de udev),
        - largement documenté ( man systemctl, man systemd, man journalctl).

        • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

          Posté par . Évalué à  3 .

          • facile à configurer ( sudo systemctl enable/disable , et voilà! On peut faire un start/ restart/ stop ensuite si on est pressé),
          rc.d {start,stop,restart,reload} <deamon>
          service <daemon> {start,stop,restart,reload}
          
          
          • facile de surveiller (d'autant que systemctl accepte de nombreux filtres en arguments) :

          $ systemctl
          […]

          rc.d list
          […]
          service status-all
          […]
          etc.
          
          
          • fiable (au contraire de udev)

          Je pense que, soit tu t’es trompé de nom, soit tu ne sais pas ce qu’est udev.

          • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

            Posté par . Évalué à  -1 .

            Si si je sais très bien ce que c'est, et c'est bien lui qui bloque le démarrage une fois sur deux.

            Y'a qu'à voir le bordel sur la LKML à son sujet.

            Quand à tes exemples, je ne comprends pas pourquoi tu met systemd et sysv en opposition. On dit que systemd est compliqué, je réponds avec mon expérience jusqu'ici, c'est tout. Il n'y a pas d'attaque envers SysV dans mes propos. Je suis d'ailleurs passé à systemd uniquement parce que c'était "obligé" par les auteurs de Archlinux (on peut choisir d'autres systèmes d'init si on est vraiment allergique à systemd, mais ça m'a semblé plus compliqué sous Archlinux, et moins supporté, que de passer à systemd. Ce qui m'a pris 5 minutes).

            • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

              Posté par . Évalué à  -1 .

              Si si je sais très bien ce que c'est, et c'est bien lui qui bloque le démarrage une fois sur deux.

              Y'a qu'à voir le bordel sur la LKML à son sujet

              Non, visiblement tu ne sais pas ce qu'est udev puisque tu penses qu'il a été remplacé par SystemD.

              Quand à tes exemples, je ne comprends pas pourquoi tu met systemd et sysv en opposition.

              Je pondérai simplement tes exemples.

              • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                Posté par . Évalué à  -1 .

                Non, visiblement tu ne sais pas ce qu'est udev puisque tu penses qu'il a été remplacé par SystemD.

                Non, je ne le pense pas et je ne l'ai jamais dit, ni pensé, ni cru. Tu te fais des idées.

                Ce que j'ai dit, c'est que Systemd ou SysV sont fiables. Udev ne l'est (toujours) pas. Que ce soit avec SysV ou SystemD, c'est bien udev qui m'emmerde un boot sur deux depuis bien avant le remplacement de sysV par systemd.

                Je pondérai simplement tes exemples.

                Ils n'en avaient nul besoin. Sauf si tu trouves que dès qu'on parle de systemd, faut que tu défendes ton cher SysV.

                • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

                  Posté par . Évalué à  2 .

                  Non, je ne le pense pas et je ne l'ai jamais dit, ni pensé, ni cru

                  Donc, quand tu dis que SystemD est fiable « au contraire de udev », tu ne compare pas SystemD et udev ? Ok… Pourquoi pas après tout…

                  Ils n'en avaient nul besoin. Sauf si tu trouves que dès qu'on parle de systemd, faut que tu défendes ton cher SysV.

                  Je comprends pas ce qui te dérange dans le fait que je pondère tes exemples. Tu dis que SystemD c'est trop cool parce qu'on peut faire X ou Y, je réponds qu'avec SysV on peut le faire aussi, je vois vraiment pas où est le problème.

    • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

      Posté par . Évalué à  1 . Dernière modification : le 08/10/12 à 10:39

      En même temps, Fedora sert un peu à ça. Elle est la première à intégrer certaines technos justement pour les debugger. Il faut s'attendre à ce que certains trucs ne marchent pas, et dans ce cas faut faire un rapport de bug.

      Bref, Fedora, c'est pas fait pour la prod : c'est un bac à sable, pour Red Hat principalement mais pas seulement car ça sert à tous. Si tu veux du fiable, prend RHEL ou Debian, voire Ubuntu LTS (pour du plus récent).

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

      • [^] # Fedora

        Posté par . Évalué à  2 .

        Quand tes utilisateurs veulent des logiciels récents, RHEL et Debian ne sont pas envisageables.

        À l’époque où j’ai commencé à mettre des Fedora, les noyaux des distributions embarquaient souvent pas mal de pilotes pas encore intégrés dans le noyau officiel.
        Et on tombait quelquefois sur une machine avec laquelle le noyau plantait net. C’est ennuyeux quand on a un parc hétérogène et qu’on espère installer le même système partout…
        Ce genre de surprises était bien plus rare avec la Fedora qu’avec la Mandriva ou l’Ubuntu de l’époque (le fait que RedHat employait des développeurs du noyau n’y était probablement pas étranger) et globalement, la Fedora tenait bien la route pour une utilisation en réseau, malgré ce que son côté bleeding edge pouvait faire craindre.

        Mais les choses ont évolué. Le noyau intègre les pilotes plus vite, Ubuntu a progressé, d’autres distributions sont apparues, tandis que Fedora se dégrade à plusieurs points de vue depuis quelques versions. Donc la 17 sera peut-être la dernière Fedora que j’installerai à mes utilisateurs.

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

      • [^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…

        Posté par . Évalué à  0 . Dernière modification : le 10/10/12 à 01:53

        Si tu veux du fiable, prend RHEL ou Debian, voire Ubuntu LTS (pour du plus récent).

        Pars sur du CentOS plutôt. C'est du « libre » sensé être aussi stable que RH. Fedora c'est du beeding edge à priori. Ubuntu c'est à part.

Suivre le flux des commentaires

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