Journal systemd est un "bloat"

Posté par  (Mastodon) . Licence CC By‑SA.
40
2
mai
2011

Bon, le titre trollesque, c'est juste pour attirer le chaland. En fait, c'est plus subtil.

Daniel Kahn Gillmor (alias dkg) a testé systemd sur Debian. Il y trouve des points positifs : la gestion des daemons, la gestion saine des états des processus, l'élimination de la redondance dans les scripts init, le démarrage des services réseaux. Bref, tout ce qui convient à un serveur robuste se trouve dans systemd.

Mais il est aussi inquiet. Principalement par deux choses :

  • d'une part, systemd a besoin d'autres briques qui sont plutôt destinées aux desktops, comme dbus, et dont on aimerait se passer sur un serveur (d'où le bloat). Les commentaires apprennent que dbus n'est qu'un outil pour éviter de réimplémenter un n-ième système d'IPC.
  • d'autre part, il critique l'aspect linuxocentré de systemd. À l'heure où Debian permet d'utiliser le noyau de FreeBSD, il serait dommage de s'enfermer dans un système mono-culture, pense-t-il.

Pour lui, la solution consisterait à séparer les fonctionnalités serveur utiles du reste. Malheureusement, la manière de faire de Lennart Poettering fait qu'il est difficile à l'heure actuelle d'avoir cette séparation.

Enfin, la cerise sur le gâteau, au début de son test, il a eu droit à un beau coredump dû à un assert dans systemd. Il pense que, même si ce bug a été résolu rapidement et trivialement, le logiciel qui prétend devenir un jour le PID 1 devrait peut-être être un peu plus tolérant aux assertions loupées.

  • # gn

    Posté par  . Évalué à 10.

    le logiciel qui prétend devenir un jour le PID 1 devrait peut-être être un peu plus tolérant aux assertions loupées

    Cette phrase me laisse songeur.

    • [^] # Re: gn

      Posté par  (Mastodon) . Évalué à 10.

      C'est simple : il ne s'agit pas d'écrire un logiciel aussi sensible comme un goret en mettant plein d'assertions partout qui font que dès qu'il y a le moindre petit truc qui ne va pas, ça plante. C'est le premier processus, s'il plante, rien ne peut se lancer, c'est quand même très gênant. Un petit exemple : si j'ouvre un fichier avec fopen, je peux très bien mettre un assert(f != NULL) juste après, parce que la plupart du temps, ça va marcher. Mais dans le cas de init, il vaudrait mieux savoir quoi faire au cas où on ne puisse pas ouvrir le fichier et continuer autant que faire se peut, parce que sinon, tout est bloqué.

      • [^] # Re: gn

        Posté par  . Évalué à 10.

        Je doute que systemd soit écrit comme un goret, ta vision de l'usage des assertions est loin d'être universelle, et beaucoup de monde considère que la présence d'assertions est justement la marque d'un logiciel réfléchis. Tout le fonctionnement d'ADA beaucoup utilisé dans les systèmes critiques est justement basé sur des assertions.

        Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug. C'est cette qualité entre autre qui fait le succès du kernel Linux (dans lequel il y a des assertions). Et la chasse aux bugs se fait bien plus facilement en remontant les anomalies au plus tôt et en validant les données par des contraintes plutôt que de les utiliser naïvement en espérant que ça passera. Une anomalie non traitée va très certainement provoquer d'autres problèmes un peu plus loin, qui vont être plus compliqués à diagnostiquer et à traiter.

        La tolérance aux bugs est un autre point qui concerne tout particulièrement init comme tu l'indiques. Comme il est a mon avis impossible de traiter tous les cas tordus qui risquent de se produire, et qui ne sont pas forcément liés à des bugs de l'exécutable, il serait préférable d'avoir un mécanisme capable de reprendre en cas d'erreur, par exemple en re-lançant le programme a son point de départ ou à un point connu. Ces mécanismes sont déjà utilisés dans un certain nombre de logiciels tel que bind, apache, syslog-ng... Ils ne corrigent pas magiquement tous les bugs et les erreurs, mais permettent juste d'assurer la continuité de service.

        • [^] # Re: gn

          Posté par  . Évalué à 6.

          Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug.
          Dans ce cas on fait un truc minimaliste et simple, pas un truc qui essaye de tout faire, qui a des interaction avec l'extérieur via IPC [1].

          [1] Surtout dbus, je n'arrive pas a comprendre comment un truc qui ce voulait simple est arrivé à une telle API. "D-Bus is a message bus, used for sending messages between applications.
          Conceptually, it fits somewhere in between raw sockets and CORBA in
          terms of complexity.". C'est bien plus proche du corba que des sockets...

          • [^] # Re: gn

            Posté par  . Évalué à 6.

            Surtout dbus, je n'arrive pas a comprendre comment un truc qui ce voulait simple est arrivé à une telle API. "D-Bus is a message bus, used for sending messages between applications.
            Conceptually, it fits somewhere in between raw sockets and CORBA in
            terms of complexity.". C'est bien plus proche du corba que des sockets.

            Si j'etais mechant je dirais qu'une bonne techno, DCOP, pondu par KDE a ete pervertie par Gnome pour produire DBUS et curieusement cela ressemble, d'apres ce que tu dis, a du CORBA l'ancien dada de ce projet.

      • [^] # Re: gn

        Posté par  . Évalué à 5.

        Oui, et puis afficher un message d'erreur compréhensible aussi.
        Notons de plus que les assert sont désactivés en mode non-debug, c'est-à-dire sur l'immense majorité des configurations.

        • [^] # Re: gn

          Posté par  . Évalué à 2.

          Désactiver les assert d'un logiciel buggé -- dans lequel elles mettent justement ces bugs bien en évidence au lieu de se contenter que les bugs générent des plantages potentiellement encore plus catastrophiques, trous de sécu et autres joyeusetés -- n'est sans doute pas une idée qui fera l'unanimité. Pour jouer dans son garage, pourquoi pas, pour une utilisation plus sérieuse, ça persiste à augmenter mon niveau de perplexité.

  • # Un systéme d'ipc sur un seveur OMG

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

    Quoi, des IPCs sur un serveur. Mais aucune boite n'oserait proposé ça. Ah si, Sun l'a fait avec rpc. Et aussi Microsoft avec Samba, dans une moindre mesure. Et puis, des IPCs dans unix, ben y a que ça. Et puis, des interfaces RESTs aussi. Et puis des appels à distances erlang pour ejabberd.

    Soit on fait un systeme sans meta data ( genre signaux, /dev/initctl ), soit on fait un truc plus riche car on a des trucs plus riche à gérer. À partir de la, reprendre l'existant est semble t'il meilleur que repartir de 0.

    Concernant l'assertion, il s'agit d'un vrai bug corrigé :
    http://cgit.freedesktop.org/systemd/commit/?id=a133bf10d09f788079b82f63faa7058a27ba310b

    Le fait de compiler en désactivant les assertions est aussi possible, IIRC. Donc ( si je me trompe pas ) c'est charge aux distros de rendre systemd plus tolérant.

    • [^] # Re: Un systéme d'ipc sur un seveur OMG

      Posté par  . Évalué à 6.

      Le fait de compiler en désactivant les assertions est aussi possible, IIRC. Donc ( si je me trompe pas ) c'est charge aux distros de rendre systemd plus tolérant.

      Et lorsque le code continue a s'executer avec une condition non satisfaite et plante ou corrompt des donnees, on considere que c'est plus tolerant?

      La demande, c'est d'avoir une gestion des erreurs plus complete, pas de virer les assertions et laisser systemd planter miserablement plus loin dans le code.

      J'ai deja vu du code qui faisait ca, et ben ca fait peur:

      assert(data != NULL);
      data->samples = numsamples;
      memcpy(data->buffer, source, data->samples * sizeof(data->buffer[0]));
      
      • [^] # Re: Un systéme d'ipc sur un seveur OMG

        Posté par  . Évalué à 7.

        J'ai deja vu du code qui faisait ca, et ben ca fait peur:

        assert(data != NULL);
        data->samples = numsamples;

        hmm, ça peut faire peur mais pas nécessairement, par exemple si la fonction dans laquelle se trouve ce code est du genre:

        cequetuveux mafonction(struct Y * data, ...) {
        /* mafonction: prend un "struct Y *" data non-null en entrée et retourne "cequetuveux" */
        assert(data != NULL)
        ...
        }
        

        ici le assert est totalement légitime, voire souhaité. amha.

        • [^] # Re: Un systéme d'ipc sur un seveur OMG

          Posté par  . Évalué à 3.

          tout à fait. Cf programmation contractuelle.

          • [^] # Re: Un systéme d'ipc sur un seveur OMG

            Posté par  . Évalué à 6.

            cequetuveux mafonction(struct Y * data, ...) {
            /* mafonction: DOIT prendre un "struct Y *" data NON NULL en entrée et retourne "cequetuveux" */
            y = 2*data->x;
            ...
            }
            

            0:)

            J’appelle ça la programmation par contrat-ou-ça-te-pêtera-à-la-gueule, ou encore : t’avais qu’à lire la documentation couillon !

            • [^] # Re: Un systéme d'ipc sur un seveur OMG

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

              Mais, si par malheur il y a un bug à un endroit ou un autre dans le code qui appelle cette fonction, dans un cas tu aura

              ASSERT "data != null" in monfichier.c:42

              et dans l'autre

              segmentation fault

              Et pas plus d'info sans sortir un débuggeur.

            • [^] # Re: Un systéme d'ipc sur un seveur OMG

              Posté par  . Évalué à 5.

              ou encore : t’avais qu’à lire la documentation couillon !

              bah oui c'est sûr, la doc c'est pas fait juste pour faire beau, normalement.

              bon après, le risque inhérent à ce type d'usage, ça dépend surtout de l'audience de la fonction :

              si c'est une fonction librairie destinée à être utilisée par tout un chacun (donc des couillons) alors cette obligation se DOIT d'être clairement documentée/définie/autre. Si par malheur le couillon donne quand même un NULL à la fonction dans un cas très particulier de son code et que ça pête une centrale nucléaire dû à un équipement de refroidissement qui est sur son cul dû fait que le soft le controllant est simplement planté alors Fukushima^² quoi !

              • [^] # Re: Un systéme d'ipc sur un seveur OMG

                Posté par  . Évalué à -1.

                « t’avais qu’à lire la documentation couillon ! »

                « ça dépend surtout de l'audience de la fonction »

                Aurais-je oublié de préciser que la majorité de mes codes sont pour mon usage personnel ? :) Plus sérieusement je n’aime pas trop multiplier les tests de validité, sauf entrées de l’utilisateur. Je préfère largement bien préciser ce qu’attend la fonction en entrée (le Python est un régal pour ça…) et m’y tenir.

                • [^] # Re: Un systéme d'ipc sur un seveur OMG

                  Posté par  . Évalué à 3.

                  Oui enfin, souvent l'erreur n'est pas faite à l'appel direct de la fonction, mais bien avant. L'erreur se propage sans causer d'erreur apparente, puis vient l'appel de ta fonction où ça explose. Faire des vérifications un peu partout aide à trouver plus facilement où ça a merdé, mais aussi à avertir qu'une erreur a été détectée. Sans ça, le code pourrait très bien continuer à tourner, mais avec un fonctionnement qui n'est plus garanti.

                  • [^] # Re: Un systéme d'ipc sur un seveur OMG

                    Posté par  . Évalué à 0.

                    Faire des vérifications de ce style au petit bonheur la chance n’a jamais garanti le bon fonctionnement d’un programme.

                    Par contre bien définir les ensembles d’entrée/sortie, minimiser les effets de bord, si. (/Me commence à être tenté par la programmation fonctionnelle:).

            • [^] # Re: Un systéme d'ipc sur un seveur OMG

              Posté par  . Évalué à 1.

              euh avec l'assert ça te pête aussi à la gueule hein. Mais plus poliment, plus utilement, et parfois avec moins de trous de sécurité. Par contre vouloir dans une biblio userspace (ou plus généralement dans le même espace d'adressage et du même niveau de privilège) faire du EINVAL absolument partout en essayant de couvrir 100% des codes paths de mauvaise utilisation, et le tout sans jamais d'effet de bord néfaste, relèverait du fantasme et nécessiterait des soins psychiatriques d'urgence.

        • [^] # Re: Un systéme d'ipc sur un seveur OMG

          Posté par  . Évalué à 8.

          Moi ce qui me fait peur, c'est pas le assert, pourquoi pas, mais plutot le:
          sizeof(data->buffer[0]) sans verifications d'indice et le memcpy de boeuf sur une technique de "a-zy, ca rentrera, pis si ca rentre pas, tu pousses un peu et tu bourres..."

          c'est bien cool de checker que data est non nul, mais si c'est pour dereferencer un tableau juste apres en decidant qu'il fera telle taille sans en avoir la moindre idee, honnetement pourquoi se faire chier avec le premier assert?
          Et note que je ne parle meme pas du memcpy de cowboy

          J'allais dire "il manque peut etre des lignes qui viennent avant pour etre sur que ca a pas ete verifie", mais acceder a data->buffer avant assert(data != nil) c'est un peu couillon quand meme :)

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Un systéme d'ipc sur un seveur OMG

            Posté par  . Évalué à 2.

            Pourquoi il est moinsé ?
            Perso c'est aussi ce qui me choquait dans ce code

            • [^] # Re: Un systéme d'ipc sur un seveur OMG

              Posté par  . Évalué à 3.

              Ma nature de dissident linuxfaitrien qui a l'outrecuidance ne pas dire du mal d'apple me fait poster a -2 par defaut.
              La derniere fois j'ai prit -10 pour avoir dit qu'ios est gratuit.

              D'apres baud123 j'ai un karma proche du zero absolu, ceci explique cela.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: Un systéme d'ipc sur un seveur OMG

            Posté par  . Évalué à 3.

            Moi ce qui me fait peur, c'est pas le assert, pourquoi pas, mais plutot le:
            sizeof(data->buffer[0]) sans verifications d'indice

            Pourquoi veux tu faire une vérification d'indice ici ?

            • [^] # Re: Un systéme d'ipc sur un seveur OMG

              Posté par  . Évalué à 0.

              Si le mec verifie son pointeur initial, c'est qu'il sait pas trop d'ou il vient.
              S'il sait pas trop d'ou il vient, buffer peut etre null ou vide.
              Si c'est le cas, ca va faire paf pasteque.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: Un systéme d'ipc sur un seveur OMG

      Posté par  . Évalué à 3.

      Je ne comprends pas trop les histoires d'IPC, un processus sans IPC ça n'est pas très utile!

      Alors OK sous *nix, il y a beaucoup d'IPC, bah il y a aussi beaucoup de shells (ksh, zsh, bash, sh,..),
      ou est le problème exactement?

  • # Même si le liens est dispo en fin de l'article pointé...

    Posté par  . Évalué à 8.

    il serait peut-être bon, avant, de lire le post de présentation de Lennart avant (car il me semble que c'est somme toute un réponse à ce post) :
    http://0pointer.de/blog/projects/

    • [^] # Re: Même si le liens est dispo en fin de l'article pointé...

      Posté par  (Mastodon) . Évalué à 4.

      C'est lumineux.
      Bien que forcément positif (donc pincettes) ce résumé met en lumière cela, entre autre :

      • pas de shell (oufff)
      • compatibilité sysV complète (native services & initctl)
      • ok aussi avec sysctl
      • prise en charge du profiling
      • ipc (donc) entre services + ceux plus haut (dbus)
      • et unification des (fichiers/scripts de) services entre distributions

      Malgré son aspect bloatware, et malgré son linuxcentrisme. Et malgré que la présentation pose forcément pas mal de question au péquin de base (telle que : respawning on services crash without loosing connection... [goût de marketting] heu il fait le café aussi ?. Ou ck/pk integration : à ce niveau c'est utile ???

      ... bref ça a tout l'air d'une très belle avancée.

      /avide_de_vos_lectures

    • [^] # Re: Même si le liens est dispo en fin de l'article pointé...

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

      Je kiffe le gros troll sur Git, Subversion et Bazaar, dans la section "Miscellaneous" :-)

    • [^] # Re: Même si le liens est dispo en fin de l'article pointé...

      Posté par  . Évalué à 8.

      J'ai rien contre systemd ou Lennart (je suis sous FreeBSD) mais l'article que tu donnes en référence a quelques traits franchement ridicules. Par exemple il y est écrit:

      As the tables above hopefully show in all clarity systemd has left behind both sysvinit and Upstart in almost every aspect. With the exception of the project's age/maturity systemd wins in every category.

      Sympa la victoire à plate couture auto-proclamée ... Mais jetons donc un œil à ces catégories. Vers le début:

      Première information: shell-free bootup est un aspect positif. Deuxième information: c'est tellement positif que je le compte deux fois: vu que les deux autres utilisent le shell pour la procédure d'amorçage, c'est clair qu'on ne peut pas y coller des modules en C.

      De plus en y regardant de plus près, le deuxième point est plutôt mauvais pour systemd, puisque les fonctions sont rendues par des modules, qui peuvent être écrits dans n'importe quel langage puisque le SHELL est utilisé pour coordonner l'éxécution de ces programmes.

      Et maintenant

      Qu-est-ce que c'est que ces no? À la fin de la procédure d'amorçage à la systemv les systèmes de fichiers ne sont pas montés peut-être? À moins qu'il veuille dire que le démon puisse s'occuper de monter et démonter les disques à la demande de l'utilisateur? C'est bien mais il y a déjà les commade mount et umount pour ça, non?

      Il y a beacuoup de features saugrenues et son as the tables above hopefully show in all clarity est loin de me convaincre: elle ressemble plutôt à une tentative piteuse de rationnaliser une préférence personnelle.

      Pourtant son initial announcement de systemd est plus persuasif mais son systemd a quand-même un gros côté fourre-tout: en gros tout ce qui est susceptible de démarrer un programme se retrouve dans systemd: ainsi les dæmons classiques inetd se retrouve dupliqué par le module socket, etc. L'intérêt de ces modules n'est pas motivé, vu que systemd est présenté comme un outil d'amorce qui permet de booter la machine plus rapidement, il me semble qu'il fallait plutôt modifier un peu inetd' pour qu'il signale les services qu'il lance àsystemd` (d'ailleurs cela ferait moins de roues réinventées).

      Si j'ai bien compris sa présentation les deux aspects intéressants de systemd sont:

      1. Comme de plus en plus de démons utilisent dbus pour se synchroniser au démarrage et bien on a intérêt à démarrer dbus le plus rapidement possible: OK, ce n'était certainement pas la peine de réecrire toute la séquence d'amorçage pour faire ça.

      2. Every executed process gets its own cgroup

      Cela devrait permettre d'améliorer la gestion des services sur la machine. C'est bien.

      Et le reste des features c'est franchement du remplissage et de la duplication de fonctions existant déjà.

      • [^] # Re: Même si le liens est dispo en fin de l'article pointé...

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

        Je suis plutôt d'accord avec toi, mais tu as eu un problème de citation apparemment. Les premiers ce doit être:

        Shell-free bootup
        Modular C coded early boot services included
        

        et les autres autour de

        Mount handling

        c'est ça?

        En la regardant de près, cette liste semble plutôt être celle des features de systemd qu'une comparaison! Tu as raison, il y a plein d'aspect étranges, comme la feature

        Built-in kexec support

        qui n'a rien à faire dans un comparatif, si?

        En plus en le lisant, je trouve qu'il est vraiment léger sur certaines argumentations, par exemple dans son pissage sur les fichiers de configuration qui ne sont pas tous aux mêmes endroits. Systemd ne résout rien puisque des fois au lieu de lire les fichiers, on les écrit, et systemd n'apporte rien! Si on veut s'y retrouver, au lieu de faire des _#ifdef orgies_ comme il le suggère (d'ailleurs en lisant ça on prend peur), il suffit de (alternative):
        1. demander aux gens d'ad{a,o}pter les standards;
        2. définir une correspondance entre noms symboliques de fichiers et noms réels qui dépendent des distributions;
        3. créer un standard genre fhs-1.0 qui impose d'avoire des links aux fichiers de configuration dans un dossier bien défini (comme /etc/fhs/1.0/)

        D'ailleurs, si ça l'amuse un admin peut monter la solution 3 en très peu de temps, en toute indépendance, et ne plus se perdre dans les arborescences ...

  • # Lennart est un troll

    Posté par  . Évalué à 8.

    Lennart est bien gentil, mais c'est le spécialiste du bloatware...
    rappelons qu'il est coupable de..
    * avahi
    * pulseaudio
    et maintenant
    * systemd

    bref... a l'écouter, toute machine est avant tout un desktop, les serveurs avec des configs statiques, pour être sur que ça fonctionne, ça n'existe pas

    • [^] # Re: Lennart est un troll

      Posté par  . Évalué à 3.

      Tu peux pas lui reprocher de développe des techniques pour le desktop. Si tu es du genre à avoir besoin d'une config statique, tu as certainement les compétences pour l'écrire toi-même, voire utiliser d'autres logiciels libres plus à ton gout.

      • [^] # Re: Lennart est un troll

        Posté par  (Mastodon) . Évalué à 1.

        A priori, il n'y aura pas besoin de "l'écrire toi-même", la compatibilité sysV étant totale, une distribution serveur prendra certainement soin de conserver bien propre un paquet sysv, ainsi que les scripts d'init. Donc à charge du sysadmin d'install cekivabien (et pas de faire "clique->suivant"), que ça soit avec debian-fai ou cobbler ou un truc maison, ou simplement par choix (dans l'installeur, ou bien alamano pour une préparation préalable). Non ? Pour ceux ne faisant que "clique->suivant" et ayant besoin d'un serveur, ça m'étonnerait que systemd les gêne vraiment...

        A priori, donc, la maintenance simultanée d'un sysv historique et de systemd ne pose pas de problème ni ne prendra de temps (au vue des features annoncées de systemd)

        • [^] # Re: Lennart est un troll

          Posté par  (Mastodon) . Évalué à 2.

          J'ai peut être rêvé à voix haute un peu trop vite, là :p ça n'a pas l'air si simple que ça de maintenir les deux.

    • [^] # Re: Lennart est un troll

      Posté par  . Évalué à 9.

      A l'écouter il ne force surtout personne à utiliser ses trucs.

      Il a mis le couteau sous la gorge de Ubuntu pour intégrer Pulseaudio ?
      Quand j'installe Archlinux chez moi, j'ai pas un Lennart Pottering qui sonne à la porte pour taper un "pacman -S avahi-daemon" en furtif.
      Et quand Fedora décide de passer sous systemd le haut conseil local le fait en toute connaissance de cause.

      Alors bon, si certains trouve que X est un bloat, qu'ils reprennent leur SysV init et sa collection de scripts mitonnés aux petit oignons et qu'on nous laisse bloater nos machine tranquillement.

      • [^] # Re: Lennart est un troll

        Posté par  . Évalué à 10.

        Quand j'installe Archlinux chez moi, j'ai pas un Lennart Pottering qui sonne à la porte pour taper un "pacman -S avahi-daemon" en furtif.

        Tu as bien de la chance, ça m'arrive à chaque fois que je laisse mon ordi non verrouillé.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Lennart est un troll

        Posté par  . Évalué à 6.

        A l'écouter il ne force surtout personne à utiliser ses trucs.

        Pareil pour n'importe quel logiciel propriétaire ou protocole propriétaire ou format propriétaire. Personne ne t'oblige à faire quoi que ce soit de ton ordinateur.

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

      • [^] # Re: Lennart est un troll

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

        A l'écouter il ne force surtout personne à utiliser ses trucs.

        Pourtant il écrit ça:

        In order to gently push everybody to standardize on these files we also want to make clear that sooner or later we plan to drop the fallback support for the old configuration files from systemd. That means adoption of this new scheme can happen slowly and piece by piece. But the final goal of only having one set of configuration files must be clear.

    • [^] # Re: Lennart est un troll

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

      Ben moi j'aime bien les technos développé par ce mec:
      A la maison, j'ai un PC de salon avec de bonnes enceintes et un portable, Eh ben grâce à avahi+pulseaudio, je vois les enceintes du PC de salon dans la liste des sorties disponibles sur le portable et je peux écouter la musique du portable sur les enceintes du salon, comme ça en wifi, juste en un clic.
      Et ça c'est quand même super user-friendly. Ok, je parle d'une utilisation desktop, mais comme dit: il ne force aucun serveur à utiliser ses technos.

      • [^] # Re: Lennart est un troll

        Posté par  (Mastodon) . Évalué à 8.

        Les enceinte de ton salon on un système+du wifi ?? Sacrées enceintes !!!

        Moi, avec ALSA et BLUEZ, j'envoie du gros son sur ma chaîne hifi, seule, grâce à un module bluethoot branché sur une entrée jack. Chaîne seule, économie pc juste pour "envoyer du son sur les enceintes du salon". OK je parle d'une utilisation desktop, mais ALSA et BLUEZ ne force personne à utiliser leurs logiciels.

        • [^] # Re: Lennart est un troll

          Posté par  . Évalué à 3.

          Oula, ca me semble très intéressant ça.

          Pourrais tu donner des détails sur le module bluetooth en question (références, origine) ?
          Est-ce que la configuration se fait sans trop s'arracher les cheveux avec la doc ALSA/BLUEZ, ou bien tu as quelques liens utiles ?

          • [^] # Re: Lennart est un troll

            Posté par  (Mastodon) . Évalué à 2.

            Ben en fait je ne fais qu'utiliser bluez-alsa ( voir ici ) Et comme pour faire cela, il n'y a besoin que de l'A2DP (un truc simple : pas de contrôle distants, les contrôles sont ceux du client sur le laptop, donc pas besoin de AVRCP, ni de hidp ou autres joyeusetés :p). Lien hommage à slackware :)

            Pour le tit module bluetooth, au départ était parti du "le faire moi même" et puis ça reviens drôlement plus cher que les trucs bas de gamme. Donc... fais ton marché :-)

        • [^] # Re: Lennart est un troll

          Posté par  . Évalué à 4.

          Comme shbrol je suis TRES interesse par ta methode. Car je n'en peux plus de PA.

          • [^] # Re: Lennart est un troll

            Posté par  . Évalué à 3.

            Ben, moi, pulseaudio me permet d'écouter Deezer sur ma chaine qui est relié au NAS (Synology). Le syno n'ayant pas de client Deezer, il récupère le flux rtp généré par une carte virtuelle de PA.
            Une fois qu'on a pigé le truc, je trouve que PA est carrément génial.

            • [^] # Re: Lennart est un troll

              Posté par  . Évalué à 2.

              Sauf que exemple que j'ai tous les jours:

              J'ai une webcam avec un micro integre. Je choisi avec les controls gnome que le micro qui doit etre utilise soit celui la, je test (je vois bien que le micro fonctionne par le fait que en desous du control de volume les petits piquots se colorisent), et que se passe t'il? Naturellement mes correspondants ne m'entendent pas.

              LA solution: killall -9 pulseaudio

              Je pense que cela ne merite pas plus de commentaire! Donc PA est un probleme (pour moi) et non pas la solution!

              • [^] # Re: Lennart est un troll

                Posté par  . Évalué à 5.

                Tu utilise quoi comme système pour communiquer avec tes correspondants, c'est peut-être celui qui ne regarde pas quel micro est choisi.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Lennart est un troll

                  Posté par  . Évalué à -1.

                  De quoi?

                  Tu veux dire que le fait de tuer PA sur mon ordi fait un changement sur l'ordi d'en face? Si c'est le cas cela fait peur.

                  Mode soyons serieux:
                  Le probleme existe avec TOUTES les applications sons. Le probleme existe aussi avec gnome-record ou cheese, la SEULE facon de faire marcher ce putain de micro (je m'en moque qu'il existe une prise micro sur la carte son vu qu'elle est pas branchee) c'est de tuer PA.

                  Probleme rencontre sur Opensuse et ubuntu et comme deja dit lors d'un troll. Un systeme tel que PA qui est, semble t'il pas simple du tout a integrer dans le systeme s'eloigne passablement de la philosophie KISS de UNIX et que j'apprecie. Si je veux avoir des merdes de ce style j'utilise windows. Heureusement il existe, encore, des solutions de rechange pour Linux!

                  • [^] # Re: Lennart est un troll

                    Posté par  . Évalué à 4.

                    Essayé à l'instant sur un Dell XPS 15 (L502x) avec une Fedora 15 64 bits dessus : pas de problème dans gnome-recorder en revanche Cheese produit une vidéo figée (clairement un bug) tout en enregistrant correctement le son.

                    Un problème spécifique à ta machine ?

                    Quant au concept KISS, on dirait qu'il est souvent synonyme ici d'une vision idyllique du monde où tout est simple... bisounours land pour le logiciel, surtout celui du son qui comme chacun le sait ne recouvre pas l'utilisation de cartes sons aux possibilités techniques ultra-différentes, et ne demande jamais d'optimisations tordues pour tout effectuer en «temps-réel».

                    • [^] # Re: Lennart est un troll

                      Posté par  (Mastodon) . Évalué à 10.

                      C'est justement the question : pourquoi avoir besoin de pulseaudio pour juste "du son qui comme chacun le sait ne recouvre pas l'utilisation de cartes sons aux possibilités techniques ultra-différentes, et ne demande jamais d'optimisations tordues pour tout effectuer en «temps-réel»." ????

                      pulseaudio, le truc :

                      • qui devait être un daemon, qui ne l'est toujours pas (c'est toujours déconseillé, du coup les distribs sont obligés de faire de hacks externes, des watchdogs style pour le relancer alors qu'il n'est pas en dameon.
                      • qui de plus ne prends que rarement en charge (même sur fedora et ubuntu) le bluetooth par défaut, de suite illico en deux clicks, non faut se taper une config dans deux outils différents (différents du bouton volume, sauf pour les distros qui ajoutent le menu au gnome-volume-manager [c'est upstream, ça, maintenant ?].
                      • Ou encore qui aujourd'hui font déconne flash, alors qu'au début c'était le flash l'avantage de pa.
                      • Qui ajoute des boutons volumes partout, on ne sait plus qui est master / pcm, pourquoi le volume est faible ... Un tit dernier ? allez...
                      • Qui masque l'accès au mixeur réel de la vraie carte son (seule Fedora à ma connaissance, fait ça proprement).

                      Non, y a un moment, faut savoir dire stop. Ok ça a été testé, ok ça a des avantages. Mais objectivement ça ne bouge que par hacks des distros, presque. Chacun dans son coin, et pour un truc réellement bancal. Alsa ça fonctionne, et voilà. Pour un usage poussé (genre bluetooth) tu fais la config une fois, ensuite c'est une histoire réglé. Et pour les usages encore plus avancés y a jack. Mais ALSA seul c'est parfait, très bien et suffisant du moins.

                      • [^] # Re: Lennart est un troll

                        Posté par  (Mastodon) . Évalué à 2.

                        Ha vi.. le tit dernier :

                        • pa en rt... mouhahaha. rtkit ? ça c'est bien (bon ça existait avant, et allemand aussi, bref). PA en rt tout seul : laggue, il est le rt ? pourtant passer quelques heures dessus, ce ne sont pas des mots à la légère. (avec jack sur gentoo / ubuntu / fedora c'est réglé configuré en 10mn). Bon, ça c'est quant il est tout seul. Facilité ? sur Fedora, intégration la meilleure, tout fonctionne très bien par défaut. (jack + pa) Oui, mais pousse un peu le bousin... paf pa se vautre (heureusement jackdmp, jack2 en c++ est devenu réistant à ce genre de gag).

                        Bref que cela soit pour la définition que tu emploi, soit "du son, simplement" il ne convient (tjs) pas. Et pour un usage par les pros, ben c'est marrant le site de référnce audio (linux-audio.org, en fr) ben les vrais pros du son ils n'en causent pas trop... ceci incluant autant les utlisateurs avancés que les développeurs, ces derniers ne sont pas précipité pour remplacer jack ou tout faire par défaut sur pa. C'est toujours ALSA (et jack) les références. Là encore, pa à tout fait.

                        Vraiment y a un moment où faut se dire "pa : dehors, fini"

                        • [^] # Re: Lennart est un troll

                          Posté par  (Mastodon) . Évalué à 2.

                          Est il besoin de causer de la conso cpu de pa ? qui, si, là, objectivement, la situation s'est améliorée, reste quant même toujours bien plus élevée pour mixer un son flash + un son musique + un son sip, que ALSA seul. Sans commune mesure, pour rendre le même service. Il est le gain ? ça suce mieux la batterie du portable ?

                          • [^] # Re: Lennart est un troll

                            Posté par  . Évalué à 1.

                            Normalement, PA est justement fait pour consommer moins, sauf avec des cartes qui ne supportent pas certaines de ses fonctionnalités (enfin, il s'agit d'un problème ALSA -- même si «il fonctionne»).

                        • [^] # Re: Lennart est un troll

                          Posté par  . Évalué à 0.

                          Je n'ai rien compris à ton paragraphe sur le RT...

                          Pour l'usage pro, PA n'a jamais été présenté comme la solution mais comme une possibilité en parallèle à Jack. Clairement PA et Jack évoluent avec deux objectifs précédents alors pourquoi les comparer ?

                          Donc, PA pas dehors sauf pour des besoins spécifiques (et encore, il peut être mis en pause il me semble).

                          • [^] # Re: Lennart est un troll

                            Posté par  . Évalué à 2.

                            PA n'a jamais été présenté comme la solution mais comme une possibilité en parallèle à Jack.

                            PA peut tout a fait utilisé Jack au lieu de ALSA.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: Lennart est un troll

                        Posté par  . Évalué à -1.

                        Un démon système tu veux dire parce qu'actuellement c'est un démon utilisateur. Euh... Qu'est-ce que ça peut te foutre ?

                        Pas de problème avec le Flash à première vue. Ou alors il faudra que tu m'expliques comment tu le diagnostiques parmi tous les plantages de Flash.

                        Les boutons, c'est ALSA... Mais tu seras heureux d'apprendre qu'alsamixer sur Fedora 15 ne m'affiche pas 50 boutons.

                        Pas stop donc. Et je ne sais pas si «ALSA fonctionne» est aussi vrai que tu le dis.

                    • [^] # Re: Lennart est un troll

                      Posté par  . Évalué à 3.

                      Non pas un probleme machine car present sur un DELL et sur un thinkpad et deux distributions differentes. Je vais me repeter mais le SEUL point commun ou plutot la SEULE facon de tout faire fonctionner comme il faut etant de tuer PulseAudio, je suis persuade que le probleme est dans ce logiciel. Si c'etait un probleme hardware, tuer un process n'aurait aucun effet.

                      • [^] # Re: Lennart est un troll

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

                        Le mercredi 04 mai 2011 à 07:42 +0200, Albert_ a écrit :
                        > la SEULE facon de tout faire fonctionner comme il faut etant de tuer
                        > PulseAudio

                        alors pourquoi l'installer ?

                        • [^] # Re: Lennart est un troll

                          Posté par  . Évalué à 2.

                          Parceque je n'ai plus le temps de m'amuser avec LFS et autre Gentoo. Donc par defaut il est installe!

                          • [^] # Re: Lennart est un troll

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

                            Le mercredi 04 mai 2011 à 20:09 +0200, Albert_ a écrit :
                            > Donc
                            > par defaut il est installe!

                            killall -9 pulseaudio

                            plusieurs fois par jour

                            VS

                            aptitude purge pulseaudio 1

                            une bonne fois pour toute...

                            • [^] # Re: Lennart est un troll

                              Posté par  . Évalué à 2.

                              Parceque je ne suis pas le seul sur ce pc et que l'autre personne a un casque bluetooth. D'ou ma question pour pouvoir utiliser cela sans PA. (Bon maintenant il va falloir le convaincre...)

                            • [^] # Re: Lennart est un troll

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

                              Et dire que j'hésitais.
                              Des plombes que pulseaudio pourrissait ma machine.
                              J'ai lu ton commentaire, et hier soir, j'ai viré pulseaudio.
                              Miracle ! Plus besoin de "killall -9 pulseaudio" dès que je change d'appli voulant produire du son. Encore mieux, deux applis différentes peuvent utiliser la carte son en même temps ! Grâce à toi, ma machine revit !

                              N.B. : je suis en Debian Sid, mise à jour régulièrement depuis des années. Toutes les conditions pour qu'il y ait un max de bogues. Je ne suis donc pas en train de dire que pulseaudio est pourri, juste qu'il pose problème sur une configuration comme la mienne...

  • # linuxo-centré.

    Posté par  . Évalué à 7.

    À l'heure où Debian permet d'utiliser le noyau de FreeBSD, il serait dommage de s'enfermer dans un système mono-culture, pense-t-il.

    Soit on essaie de faire plaisir à tout le monde, soit on essaie de faire un truc utilement optimisé. Le libre a beaucoup gagné grâce à l'innovation rapide de Linux. De l'autre côté, le libre gagne aussi avec le polissage méthodique des projets BSD. Essayer de supporter les deux approches avec le même userland (comme le fait debian) est voué à créer des problèmes☆.

    ☆ Lire aussi ce post de blog Debian, Gentoo, FreeBSD, GNU/kFreeBSD

    • [^] # Re: linuxo-centré.

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

      Soit on essaie de faire plaisir à tout le monde, soit on essaie de faire un truc utilement optimisé.

      C'est vrai ça... On se demande pourquoi il y a des emmerdeurs à vouloir une LSB, une FHS, du freedstop, sans ces emmerdeurs à vouloir des normes communes, ça serait tellement plus rapide d'innover...

      Au fait, cet argument tient très bien aussi pour Microsoft et Apple qui n'ouvrent pas les specs de plein de choses (c'est plus rapide d'innover quand on n'a pas à discuter de tout ça, tant pis pour les autres si c'est pas compatible, ça nous ralentirai de faire attention aux autres).

      • [^] # Re: linuxo-centré.

        Posté par  . Évalué à 8.

        1) justement, l'auteur de systemd a impliqué les projets et distros dans son idée, de façon à ce que les étapes nécessaires soient faites de façon cohérente.

        2) mauvaise foi. Les specs de systemd sont ouvertes, le code aussi, les discussions avec toutes les distributions ont lieu. C'est le processus d'intégration de code dans le noyau ou des distros linux et celui des BSD qui est irréconciliable.

        Le noyau linux offre une API qui des fonctionnalités différentes par rapport aux noyaux BSD [notamment parce que les gens de chez BSD n'acceptent pas aussi rapidement des changements radicaux comme il y en a eu dans la branche 2.6]. On doit s'interdire d'écrire des programmes qui tirent parti de l'API du noyau linux, parce que les gens de chez BSD n'en ont pas voulu ? De toute façon, chez BSD, ils ont leur système d'init et en sont contents. On doit donc s'interdire d'écrire des programmes pour l'API linux parce que Debian a décidé que deux noyaux totalement différents devaient booter avec le même système d'init ?

        • [^] # Re: linuxo-centré.

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

          On doit donc s'interdire d'écrire des programmes pour l'API linux parce que Debian a décidé que deux noyaux totalement différents devaient booter avec le même système d'init ?

          Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Debian GNU/kFreeBSD.
          Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal. Refuser une belle avancée technologique comme systemd juste parce que ce n'est pas compatible avec Debian GNU/kFreeBSD ce serait, amha, une monumentale connerie.

          • [^] # Re: linuxo-centré.

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

            Une belle avancée technologique

            Un truc qui pète FHS, qui éloigne encore un peu plus linux de la beauté des unix. qui n'est pas portable, qui va la migraine aux administrateurs systèmes, qui réinvente la roue dans tous les sens...

            Hum on ne doit pas avoir la même définition de "belle avancée technologique".

            • [^] # Re: linuxo-centré.

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

              «beauté des unix» ?
              Entre SMF chez Solaris et les scripts d'init hardcoded pour une machine specifique, l'init chez les unix est très loin d'être beau ou portable ...

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 1.

                Le logiciel, ça se modifie, surtout les scripts. C'est un peu l'avantage du logiciel par rapport au matériel d'ailleurs (enfin bon le matériel aussi, ça se modifie, mais c'est quand même moins facile et moins pratique). Ne pas vouloir modifier quoique ce soit dans sa configuration est illusoire, car au final la configuration sera tout de même modifiée, mais à un endroit moins accessible, découvrable, pratique, clair. Cf Windows. Les systèmes libres qui n'incitent pas à modifier son système en cas de besoin (ou pire, qui freine de telles tentatives) sont de mon point de vue inférieurs à ceux qui le font. Quand au mythe de la personne lambda pouvant administrer toute seule son ordinateur personnel sans apprendre l'informatique ni même lire ce qu'il y a écrit sur son écran, ahahah.

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 2.

              Un truc [...] qui va donner la migraine aux administrateurs systèmes, qui réinvente la roue dans tous les sens

              J'ai surement pas les connaissances pour juger mais d'après ce qu'avance Lennart ( http://0pointer.de/blog/projects/ ), c'est mieux pour les admins systèmes car il a travaillé avec les différentes distribs et ils ont "standardisé" (ou normaliser) pas mal de trucs (qui vont donc être identique maintenant sur toutes les distribs utilisant systemd). De plus, systemd n'est pas portable justement parce qu'ils ont veillé à ne pas réinventer la roue (utilisation de dbus à la place d'un truc propre à systemd)

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 5.

                De plus, systemd n'est pas portable justement parce qu'ils ont veillé à ne pas réinventer la roue (utilisation de dbus à la place d'un truc propre à systemd)

                Donc, tu veux dire que dbus n'est pas portable ? joli.

                S'il n'est pas portable, c'est parce qu'il utilise plein d'APIs linuxo-centriques, c'est tout.

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à -1.

                  :) Pour cette remarque, je dirais que soit tu es de mauvaise foi, soit tu as fait un beau sophisme, soit tu as perverti délibérément l'argumentation pour t'en servir pour exprimer ton idée...

                  L'idée était de savoir si systemd réinventait la roue ou pas (pas de savoir s'il était portable). Et à çà, j'ai répondu.

                  Maintenant, je vais te répondre à toi ;)
                  Oui, systemd (on parlait bien de systemd, hein!?! pas de dbus) n'est pas portable A L'HEURE ACTUELLE car dbus (entre autre) n'est pas ENCORE porté. Et non pas importable... mais je crois pas que les BSD soit interressé par porter cette techno donc ça risque d'être difficile pour un portage de systemd sous BSD. Les autres dépendances problématique sont policykit, cgroups et surement d'autres que j'ignore.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 4.

                    Oui, systemd (on parlait bien de systemd, hein!?! pas de dbus) n'est pas portable A L'HEURE ACTUELLE car dbus (entre autre) n'est pas ENCORE porté.

                    Tu feras gaffe, tu t'enfonce dans ton erreur la..

          • [^] # Re: linuxo-centré.

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

            Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Linux.
            Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal (note: la, je triche un peu, c'était infinitésimal avant 2000, mais c'est pour montrer que le noyau Linux a bien commencé un jour avec Debian). Refuser une belle avancée technologique comme (mettre ici n'importe quelle techno Apple ou Microsoft) juste parce que ce n'est pas compatible avec Linux ce serait, amha, une monumentale connerie.

            Ah oui, ça marche aussi ;-). C'est rigolo quand même : quand les windowsiens disent "pfff... Vous êtes pas nombreux à utiliser votre truc Linux la, on va pas prendre en compte votre cas", ça hurle qu'il faut prendre en compte les OS minoritaire, quand les linuxiens disent "pfff... Vous êtes pas nombreux à utiliser votre truc Debian GNU/kFreeBSD la, on va pas prendre en compte votre cas", ça n'a pas l'air de gêner (moi, ça me gène). Finalement, il y a assez peu de différence entre linuxien et un windowsien vis à vis des minorités... Et après ça va aller faire la morale aux windowsiens! Poutre, paille...

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 2.

              Finalement, il y a assez peu de différence entre linuxien et un windowsien vis à vis des minorités... Et après ça va aller faire la morale aux windowsiens! Poutre, paille...

              La critique ne porte pas sur les mêmes choses (ou alors cite ton exemple).

              On critique un auteur windowsien qui n'a juste pas envie de cross-compiler pour linux, alors que son programme n'a rien de spécifique à windows et pourrait facilement être rendu portable. On ne critique pas un auteur qui a décidé (p.ex.) que DirectX11 était sans nul doute possible plus simple pour son projet que OpenGL. C'est à linux de supporter DirectX s'il le veut (et ça vient petit à petit).

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 7.

                On critique un auteur windowsien qui n'a juste pas envie de cross-compiler pour linux, alors que son programme n'a rien de spécifique à windows et pourrait facilement être rendu portable.

                Tu crois que ça se fait en deux secondes de "cross-compiler sous Linux" (en utilisant, j'imagine, la bouse nommée autotools) quand ton soft est développé sous MSVC ?

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 2.

                cross-compiler ça veut dire compiler pour un système différent de celui faisant tourner le compilateur, je pense que tu voulais dire un programme portable.

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 2.

                  Je voulais vraiment dire cross-compiler. Je suppose que l'auteur d'un programme, par exemple développé sous linux, peut 1) faire l'effort de rendre son programme portable et 2) suivre un tuto pour produire un binaire pour windows à partir de sa machine linux☆, sans rien toucher à sa chaine de compilation, sans redémarrer. Pour suivre des mailing-lists où ce genre de choses se produit, il peut y avoir des problèmes (le glisser-déposer ou les binding python qui arrêtent de marcher d'une version sur l'autre), mais c'est mieux que rien et on peut produire automatiquement un binaire pour un autre système sans grand effort, sans avoir à redémarrer sur ce système.

                  http://www.dumbbell.fr/howto/win32-cross-compilation.fr.html

                  Pour répondre à la question de la personne juste au-dessus, je ne sais pas comment passer d'un projet MSVC aux autotools, mais le contraire n'est pas trop difficile (ok pas avec les autotools mais avec un truc plus moderne genre scons ou cmake). Je n'ai pas cherché la direction msvc → autre chose, vu qu'elle ne m'intéresse pas le moins du monde, mais j'imagine qu'il y a des outils pour ça.

            • [^] # Re: linuxo-centré.

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

              Finalement, il y a assez peu de différence entre linuxien et un windowsien vis à vis
              des minorités...

              Euh, patrick_g, c'est la voix des Linuxiens ?

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 1.

              Refuser une belle avancée technologique comme (mettre ici n'importe quelle techno Apple ou Microsoft) juste parce que ce n'est pas compatible avec Linux ce serait, amha, une monumentale connerie.

              Je suis d'accord avec ça, ne pas progresser pour rester compatible c'est une connerie.

              ça hurle qu'il faut prendre en compte les OS minoritaire

              Non, ça hurle (et encore la on met tout le monde dans le même panier) qu'il faut que ce soit libre (dans le cas d'un logiciel) ou (plus important selon moi) que les les specs soient publique (dans le cas d'un protocole ou du matos) de façon à ce qu'il soit possible de l'implémenter sur des OS minoritaires (soit même ou en payant quelqu'un si on en a besoin).

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 5.

              Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Linux.
              Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal

              Si on compte les smartphones sous Android, PalmOS, les routeurs, les *box, les TV Samsung ou Sony, les GPS TomTom, bref, tout plein d'équipements réseau, multimédia ou mobile, il y a peut-être plus de gens qui utilisent Linux sans le savoir que de gens sous Windows + Mac réunis.

              Et pour ces gens, un boot plus rapide sera forcément un plus.

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

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 2.

                Et pour ces gens, un boot plus rapide sera forcément un plus.

                C'est plutôt Windows qui a besoin d'un boot rapide, avec les autres OS on ne passe pas son temps à redémarrer la machine. Un boot rapide, c'est la dernière de mes préoccupations, qu'il dure 2 minutes ou 8 secondes, cela ne représente pas grand chose sur une session de travail de plusieurs heures voire plusieurs jours ou semaines.

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 5.

                  Ça dépend.

                  Quand j'allume ma TV Samsung, je dois attendre quinze bonnes secondes avant qu'elle soit utilisable.

                  Auparavant, ma vieille TV cathodique s'allumait quasi instantanément.

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

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 2.

                Et pour ces gens, un boot plus rapide sera forcément un plus.

                C'est évident, ceci dit je ne suis pas dur que systemd s'adresse aux systèmes embarqués, où dbus est plutôt rare (même si utilisé par android et meego).
                De plus init est souvent réécrit pour chaque système.

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 2.

                  Justement, peut-être que la réécriture ne sera plus nécessaire.

                  Après tout, le bon est déjà conséquent pour un PC, pourquoi ne le serait-il pas pour un téléphone ?

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

          • [^] # Re: linuxo-centré.

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

            Pour rajouter de l'huile sur le feu j'aimerais bien savoir combien de gens utilisent vraiment Debian GNU/kFreeBSD.
            Je n'ai aucune donnée mais je suis prêt à parier ma chemise que ce nombre est infinitésimal. [...]

            En même temps Debian GNU/kFreeBSD est sorti en février 2011 ... On est en mai 2011, donc il faut pas non plus s'attendre à une adoption massive en 3 mois d'un projet aussi "particulier". Il faut aussi laisser le temps au temps, mais si je regarde un peu autour de moi, je vois Mac OS X qui s'appuie sur un noyau issu en partie du monde BSD et le succès de ce système est là.

            Il est donc possible que Debian GNU/kFreeBSD devienne la distribution qui atteint 5% de part de marché des OS de bureau (OS X est autour des 8%) ou alors ça peut-être le fiasco complet, mais dans tous les cas c'est une expérience formidable et ce que le projet Debian en retira ne sera que bénéfique pour toutes les distributions; et je crois que Debian a fait ses preuves en tant que distribution de référence (et pouvant être à l'origine d'un succès sur le bureau -> Ubuntu).

            En tout cas je suis de ceux qui vont essayer de mettre un serveur sur Debian GNU/kFreeBSD, étant utilisateur Debian GNU/Linux et FreeBSD.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 4.

              On bascule dans le hors-sujet, mais tu serais peut-être une des personnes les plus qualifiées pour répondre à LA question: qu'attends-tu d'une Debian GNU/kFreeBSD par rapport à une Debian GNU/Linux et un pur FreeBSD?

              Je me suis toujours dit que l'intérêt majeur de ce projet c'était surtout dans la beauté du geste, qui permet de mettre en valeur le titre de système d'exploitation universel et le très grand souci de portabilité chez Debian (oui, c'est un peu grandiloquent, mais je ne vous cacherai pas que j'aime vraiment beaucoup Debian!).

              Donc concrètement, si on isole le noyau, que trouve-t-on chez FreeBSD qui manque chez Linux et vice-versa?

              • [^] # Re: linuxo-centré.

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

                Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum. Tu vas monter un serveur /nginx/Linux et un serveur */Apache/FreeBSD, si un des couples serveur Web/noyau est victime d'une faille de sécurité, tu peux facilement le déconnecter du réseau, attendre la mise à jour de sécurité, mettre à jour et reconnecter sans interrompre ton service Web.

                Bien entendu la partie application (
                ) sera victime des mêmes failles (à moins que tu aies un psychopathe qui décide, par exemple, de faire une version Perl et un version PHP de l'application ... ça reste possible), mais ta partie serveur Web et noyau est suffisamment hétérogène pour avoir une sécurité "supplémentaire".

                Ensuite il y'a débat pour savoir lequel de FreeBSD ou de Linux est plus performant pour le réseau/accès disque/nombre de processus/..., on pourrait imaginer avoir deux serveurs concurrents identiques derrière un proxy. Chaque requête est transmise aux deux serveurs et la requête la plus rapide est servie au client, la plus lente est supprimée. À la fin d'un période de test, on peut aisément déterminer lequel des deux systèmes est le plus adéquat pour le travail en question.

                On peut aussi imaginer le cas où tu te retrouves avec du matériel supporté que par l'un (genre tu as plusieurs machines différentes et un de ces machines à du matériel uniquement supporté (ou mieux supporté) par FreeBSD).

                Mais sinon si on isole les noyaux, il ne reste plus de différence entre les deux, c'est bien le but du projet.

                Comme pour l'administration ça reste une Debian, tu peux beaucoup plus facilement mettre en place ce genre de solutions. Ça reste encore une hypothèse, mais c'est le genre de choses que j'ai imaginé quand j'ai appris le naissance du projet kFreeBSD, mais je n'ai pas encore eu le temps de mettre en pratique mes délires :)

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 2.

                  Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum. Tu vas monter un serveur /nginx/Linux et un serveur */Apache/FreeBSD, si un des couples serveur Web/noyau est victime d'une faille de sécurité, tu peux facilement le déconnecter du réseau, attendre la mise à jour de sécurité, mettre à jour et reconnecter sans interrompre ton service Web.

                  C'est un point intéresssant.

                  • [^] # Re: linuxo-centré.

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

                    Oui on avait déjà parlé de l'hétérogénéité comme facteur améliorant la résilience d'un groupe il y a quelques temps: c'est exactement la même idée.

                  • [^] # Re: linuxo-centré.

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

                    C'est un point intéresssant.

                    Ou pas.

                    Dans son exemple, si le but est de filer des données sensibles suivant des autorisations, le mal sera fait avant qu'il éteigne le serveur troué. Et en face, l'attaquant a deux fois plus de possibilités pour trouver une faille (deux OS et deux serveurs avec des failles possibles).

                    C'est une fausse meilleur sécurité qu'il présente, avec comme conséquence une plus mauvaise sécurité.

                    La où il est intéressant d'avoir de l'hétérogène, c'est pour des données différentes : si l'un est attaqué, l'autre est encore pas attaquable, moitié de "perte". Si il faut les deux serveurs pour accéder à la donnée sensible cryptée, c'est toujours sécurisé dans ce cas.

                    En gros faire la différence entre ET logique et un OU logique.

                    • [^] # Re: linuxo-centré.

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

                      C'est une fausse meilleur sécurité qu'il présente, avec comme conséquence une plus mauvaise sécurité.

                      Ce n'est pas juste une plus mauvaise sécurité: d'un côté il y a un nombre plus grand de failles potentiellement exploitables, de l'autre une meilleure disponibilité du service lorsque une faille est repérée. Il y a donc un vrai choix à faire.

                      • [^] # Re: linuxo-centré.

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

                        Je cite:

                        Un exemple, tu as une application web qui sert des données sensibles et tu souhaites te protéger au maximum

                        Avec deux OS différent qui peuvent fournir le même contenu et son indépendants ("tu peux facilement le déconnecter du réseau,") : sécurité, Fail.

                        Ou alors j'attend l'argumentation, car je n'ai pas compris comment ça améliore la sécurité.

                        Par contre, oui, c'est sécurité contre disponibilité, juste que la on parle de sécurité.

                        • [^] # Re: linuxo-centré.

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

                          Par contre, oui, c'est sécurité contre disponibilité, juste que la on parle de sécurité.

                          Au temps pour moi, je n'avais pas lu tout le fil précédent, tu as raison.

                        • [^] # Re: linuxo-centré.

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

                          ... en même temps je pensais pas qu'il était nécessaire de préciser qu'un service réseau vise 100% de disponibilité. Dans ton raisonnement, autant débrancher la machine du réseau (électrique compris).

                          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: linuxo-centré.

          Posté par  . Évalué à 4.

          Il n'est pas interdit d'organiser son code pour simplifier un éventuel portage.

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

          • [^] # Re: linuxo-centré.

            Posté par  . Évalué à 2.

            Ce serait même assez intéressant en fait.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: linuxo-centré.

        Posté par  . Évalué à 1.

        Avec cette très légère différence que les éditeurs propriétaires ont la fâcheuse tendance à ne proposer ni code source, ni vague brouillon rassemblant les spécifications.

        Autrement dit, il n'existe absolument aucun moyen de savoir comment un format ou un protocole est foutu, dans ces conditions.

        Il ne s'agit pas de discuter, juste de permettre aux autres de se démerder pour être compatibles. Ce que le libre fait même dans le pire des cas, vu qu'il y a le code source (ce n'est pas idéal, certes, mais c'est beaucoup mieux que rien).

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: linuxo-centré.

          Posté par  . Évalué à 10.

          Mouais, ça change pas grand-chose d'avoir le code source, ici...

          Ce n'est pas en ayant le code source des fonctionnalités du noyau Linux abondamment utilisées par systemd que l'on va facilement pouvoir les implémenter dans les noyaux BSD, par exemple (rien que pour des raisons de licence). Alors, on dit plus haut que Lennart ne met pas de couteau sous la gorge, OK, mais il y a aussi la question de pouvoir faire autrement, à long terme.

          Le problème, selon moi, c'est qu'un composant utilisé par les distributions les plus populaires (Fedora, Ubuntu...) devient rapidement un standard de fait. Par exemple, Slackware fait quand même quelques choix très marqués (pas de Gnome, pas de PAM, pas de PulseAudio, un init BSD-like), et, de l'aveu même de Pat, les choses deviennent de plus en plus compliquées à maintenir comme ça.
          Par exemple, Policykit est dépendant de PAM, à la base. Il a fallu qu'un contributeur développe une solution (basée sur shadow) pour que ça puisse marcher avec Slackware. Solution qui a été en partie reprise par OpenBSD, qui ne veut pas non plus de PAM. Un autre exemple : Chrome, qui veut aussi des bouts de PAM et de Gnome. Encore un autre exemple : Xfce 4.8, pour lequel certaines fonctionnalités ont en partie disparu pour les BSD.

          Un autre exemple encore : bash. C'est est le shell par défaut sur la majorité des distributions Linux, donc beaucoup de gens, inconsciemment, partent du principe que tous les shells se comportent comme bash. Cela est surtout intensifié par le fait que, même lancé en tant que /bin/sh, bash accepte encore des fonctionnalités qui lui sont propres. Du coup, le nombre de scripts (avec le shebang #!/bin/sh) remplis de bashismes est monstrueux.

          Moi, je suis bien content de l'init BSD-like de ma Slackware. Je le trouve tout simple (y a pas whatmille niveaux de liens symboliques, c'est du bourne shell, les scripts ne font pas des kilomètres, bref : c'est humainement utilisable). En plus, pour peu qu'on le fasse utiliser dash et awk plutôt que des cut | rev | tr | rev | sed, ça me fait un temps de démarrage d'environ 15 secondes, ce que je trouve tout à fait acceptable (malheureusement, Pat est plutôt frileux à accepter ces changements).
          Mais je n'aimerais pas que l'on parte dans une homogénéité totale des différents Linux et *BSD. La diversité, c'est bien, et pour moi, la liberté de choisir devrait être une des libertés fondamentales.

          A force de vouloir faire de Linux un Windows gratuit, j'ai bien peur de finir par avoir un truc aussi frustrant à utiliser. De toutes façons, je pense que vouloir rendre Linux prêt pour le desktop est voué à l'échec de par le fait du modèle du bazar (qui fait qu'il y aura toujours quelqu'un pour être insatisfait et lancer son propre truc) : échec soit par le fait que ça n'arrivera jamais (parce que c'est difficile de concilier tout ce bazar, justement, avec tout le monde qui fait son truc à sa façon dans son coin), ou alors parce que le résultat aura largement perdu en qualité. Je pense que si on veut avoir un système un minimum "prêt pour le desktop", il faut quand même avoir un ensemble assez homogène, et donc il y a un moment où il faut imposer ses choix à l'utilisateur qui perd alors une bonne partie de sa liberté de faire ce qu'il veut sur sa machine, ce que je ne souhaite pas, personnellement (par contre je trouve que ça décrit bien Mac OS — mais ça ne pose pas de problème aux fanboys puisqu'ils trouveront toujours parfait ce qu'Apple les autorise à faire... pas bête le Steve).
          Ce qui ne veut pas dire qu'il n'y a pas d'efforts d'uniformisation à faire (c'est vrai qu'il ne s'est pas passé grand-chose ces 10 dernières années à ce niveau-là, comparé aux changements qui sont survenus), mais il ne faut pas partir dans l'excès "UNIX = GNU/Linux Fedora/Ubuntu".

          Je ne critique pas tout ce qu'à pu faire Lennart ; ça sert à rien et puis il y a certaines de ses idées qui me plaisent (ce qu'il propose sur l'uniformisation des fichiers de configuration de base, par exemple — surtout qu'il propose des noms de fichiers très UNIX : courts, logiques et simples), mais bon, généralement je me porte mieux en n'installant pas ses projets sur ma machine, et j'aimerais pouvoir continuer à le faire pendant encore un bon moment.

          a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence

          • [^] # Re: linuxo-centré.

            Posté par  . Évalué à 1.

            Ça serait pas plus simple une bonne fois que quelqu'un qui veut avancer forke un BSD et place son fork sous licence GPL, de façon à pouvoir bénéficier de ce qu'il considère comme le meilleur des deux mondes ?

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 4.

              Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 2.

                Mais si, il saura entendre raison.

                Il suffit d'un bon débat contradictoire!

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 1.

              Le problème, c'est qu'il faut aussi forker Théo, pour que ça soit efficace. Et quelque-chose me dit qu'il ne se laissera pas faire si facilement ;)

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 9.

                Attention, tu as forké ton commentaire.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 2.

                  Il y a recrudescence de double posts en ce moment. Si je savais quoi mettre en dehors de ça je ferai une entrée dans le suivi /o\

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 3.

                    Moi aussi

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # double post

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

                    Si je savais quoi mettre en dehors de ça je ferai une entrée dans le suivi /o

                    Clic sur "envoyer". vu que le serveur met un peu de temps (Ruby? ;-) ), j'ai le temps de malencontreusement ré-appuyer sur "envoyer" (je suis pas doué, double-clic sans faire exprès), et vu qu'il n'y a pas de code Javascript qui désactive le bouton avant d'envoyer le post, et vu qu'il n'y a pas de test de post en double pour ne pas le prendre en compte, ben post en double au final.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 1.

                    Moi aussi.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 1.

                    Moi aussi.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 1.

                    Moi aussi.

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 3.

                Je suis moi-même convaincu que c'est sans espoir.

                Je suggère un débat contradictoire, juste pour la forme.

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 2.

              Tu peux utiliser/contribuer à debian/kfreebsd, gentoo/freebsd ou freebsd-arch, en choisissant celle qui a le mélange bsd/gpl qui te convient le mieux.

      • [^] # Re: linuxo-centré.

        Posté par  . Évalué à 9.

        sans ces emmerdeurs à vouloir des normes communes, ça serait tellement plus rapide d'innover...

        Justement, pour la partie desktop, le coeur du problème est que les gens de BSD ne s'investissent pas assez dans les efforts de standardisations formelles (freedesktop) ou informelles (fournir du code, tester les projets communs).
        Quant à la partie système, c'est bien de respecter les normes mais les seules évolutions qu'a connu POSIX cette décennie passée ont été: fusion avec SUS, toilettage de l'API, prise en compte d'IPv6 etc ... On peut ânonner POSIX jusqu'à la fin des temps ou bien se sortir les doigts du cul et utiliser des alternatives plus avancées.
        Là ou Lennart marque un point, c'est que les normes se basent sur les innovations proposées par les différents participants, or la plupart des innovations se font dans Linux (ou GNU dans un contexte plus large) qui est devenu le standard de FAIT. Le problème c'est que POSIX n'évolue plus, donc soit on le sort de l'ornière, soit on crée un nouveau groupe de standardisation sur le modèle fd.o (j'ose pas imaginer le niveau trollesque d'une liste réunissant quotidiennement de Raadt, Trollvalds, RMS etc ...) pour collaborer plus étroitement.

        Sinon pour revenir au sujet principal:
        * systemd n'est pas un bloatware: la portabilité à tout prix a un coût, le choix du linux-o-centrisme a été fait pour éviter justement que systemd devienne un bloatware.
        * le choix de D-Bus: D-Bus est un protocole qui s'appuie sur un IPC plus que standard: les sockets BSD. En plus, systemd s'appuie sur une toute petite lib, rien n'interdit de la réimplémenter, si elle est trop bloated.
        * Lennart n'a rien contre la portabilité et les standards, au cours du développement de systemd, il a rapporté plus de bogues au FHS à lui seul que la majorité des distros ces dernières années. Le but n'est pas de péter FHS mais de corriger ces lacunes et de standardiser ça au lieu que chaque distro fasse son hack dans son coin comme c'est le cas actuellement. Au final, systemd contribuera a simplifier le boulot de ces feignasses de sysadmins sous GNU/Linux (quant aux BSD, ils utilisaient déjà leurs propres init donc ça change pas grand chose de ce côté là)

        • [^] # Re: linuxo-centré.

          Posté par  . Évalué à 3.

          POSIX n'évolue plus, donc soit on le sort de l'ornière, soit on crée un nouveau groupe de standardisation sur le modèle fd.o (j'ose pas imaginer le niveau trollesque d'une liste réunissant quotidiennement de Raadt, Trollvalds, RMS etc ...)

          Je ne vois pas ce que RMS viendrait faire là-dedans, sauf si on veut aussi standardiser les éditeurs de texte.

      • [^] # Re: linuxo-centré.

        Posté par  (Mastodon) . Évalué à 10.

        Zenitram, ça me fait peur, je suis encore d'accord avec toi.

        Et je trouve que ceux qui mettent dans la balance l'innovation devraient relire un peu l'histoire de UNIX (oui, GNU/Linux est toujours un Unix et essaie au maximum de respecter les standards, c'est marqué dans toutes les manpages) et notamment la partie sur la balkanisation : aucun de ces super UNIX qui innovaient à fond comparé au voisin n'a survécu. Non par manque d'innovation (certains ont eu de très bonnes idées), mais par manque de compatibilité les uns avec les autres.

        Alors, oui, c'est chiant de standardiser et les organismes genre opengroup sont un peu long à la détente. Mais si le problème vient des organismes, il ne faut pas jeter le standard, mais bien l'organisme (ou le réformer). Parce que ce n'est pas en marginalisant les BSD qu'on arrivera à imposer Linux, ne nous trompons pas d'ennemis. Les BSD sont des alliés, et standardiser un protocole ou une API permet toujours d'en voir tous les défauts (par la multiplicité des points de vue).

        • [^] # Re: linuxo-centré.

          Posté par  . Évalué à 4.

          Sauf que les BSD ont déjà un système d'init différent de celui des Linux et que systemd est déjà compatible avec le système d'init actuel des distributions. Pour l'instant, on ne fait rien de différent de l'actuel.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: linuxo-centré.

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

            Sauf que les BSD ont déjà un système d'init différent de celui des Linux

            Comme ArchLinux et Slackware ?

            • [^] # Re: linuxo-centré.

              Posté par  . Évalué à 2.

              Et puis Ubuntu avec Upstart... Sans compter que les scripts de démarrage s'appuient tous sur les spécificités de chaque distribution avec, par exemple, des fichiers de configuration dans /etc/sysconfig chez Redhat mais pas chez Debian.

              La vérité, c'est que le démarrage des systèmes Linux n'est pas normalisé et n'a pas même réussi à se standardiser alors pourquoi ne pas tenter autre chose ?

              Il y a quand même une fonctionnalité qui a l'air de rester invisible ici alors qu'elle me paraît être la killer-feature de systemd. Systemd peut faire redémarrer des services sans avoir à redémarrer la machine : les sockets stockent les données qui leur arrivent pendant que le service concerné redémarre, puis ce service peut traiter ce qui était en attente dans les sockets qu'il utilise. Ce n'est pas une fonctionnalité utile pour un serveur ou même pour une simple machine ?

              • [^] # Re: linuxo-centré.

                Posté par  . Évalué à 5.

                Comme dit auparavant systemd c'est peut etre bien, en theorie. Le probleme c'est que la personne ayant pondu ca a la sale habitude de laisser en plan un truc a moitie fait. Du coup on se retrouve avec Avahi et PA. Les deux a la base ont de bonnes idees et au final pour l'utilisateur lambda c'est bien souvent inutilisable ou tellement complique que ca ou rien c'est presque pareil (voir pire dans certains cas).

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 2.

                  Dans ce cas, ce que tu reproches, ce n'est pas le fait que PA ne soit pas fini, mais le fait que ta distribution te l'impose comme choix par défaut.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 2.

                    Ma distribution? Comme je ne suis mono-distribution ni ethocentrique je dirais que toutes les grosses distributions t'imposent ce truc et que a cause de cela, les alternatives n'existent pas vraiment.

                • [^] # Re: linuxo-centré.

                  Posté par  . Évalué à 1.

                  Pour Avahi, je n'en sais rien (ça a toujours tourné tout seul sur toutes mes machines sans problème). Pour PA, les problèmes ont généralement trait à des interactions avec Jack. De cela, en déduire que tout ce que fait ce gars est mauvais est honteux. Juste une attaque gratuite. Par ailleurs, j'imagine mal Redhat, Suse et Debian laisser systemd devenir un machin inutilisable alors que ce programme est de la première importance.

                  • [^] # Re: linuxo-centré.

                    Posté par  . Évalué à 2.

                    je n'ai pas dit que ce que fais LP etait mauvais ou honteux je dis que cela n'est pas fini.

                    Note: compare avahi avec ce que propose bonjour sous mac et tu verras a quel point c'est pas encore "in working state".

                    • [^] # Re: linuxo-centré.

                      Posté par  . Évalué à 2.

                      J'y connais pas grand chose, alors je lis wikipédia : Avahi vs. Bonjour. Je ne vois que des éloges pour Avahi. Peux-tu expliquer les problèmes ?

                      • [^] # Re: linuxo-centré.

                        Posté par  . Évalué à 2.

                        je ne sais plus cela c'est passe il y a quelques mois. Mais sous son mac il a reussi a faire un truc que j'ai jamais reussi avec avahi. Alors c'est peut etre faisable mais la ou je considere que c'est pas fini c'est que pour un utilisateur lambda c'est pas utilisable. Si il veut ameliorer les trucs pour le desktop comme il le dit, le fait de rendre les technos qu'il met facilement utilisable est fondamental. De ce point de vue la, au minimum, avahi (et PA) ne sont pas fini.

                        • [^] # Re: linuxo-centré.

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

                          il a reussi a faire un truc que j'ai jamais reussi avec avahi.

                          Quel truc ?
                          Merci d'argumenter avant d'attaquer gratuitement un logiciel.

                        • [^] # Re:linuxo-centré.

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

                          Le mercredi 04 mai 2011 à 20:36 +0200, Albert_ a écrit :
                          > je ne sais plus cela c'est passe il y a quelques mois.

                          à 20h06 tu dis qu'un soft ne tiens pas la comparaison avec un
                          concurrent.
                          à 20h36 tu ne sais plus pourquoi

                          ...

                          • [^] # Re:linuxo-centré.

                            Posté par  . Évalué à 2.

                            Se connecter sur le pc voisin. C'etais fait en deux clics avec les macs et avec avahi cela aurait du etre pareil et bien cela ne l'etait pas mais bon OpenSuse doit faire une integration de merde ou bien l'utilisateur devrait aller tripatouiller a la mano dans /etc/avahi c'est super friendly ca.

                            Le truc c'est regle utilisant kio ssh sur l'adresse ip c'etait plus rapide et cela fonctionnait sans se prendre la tete.

                            • [^] # Re:Re:linuxo-centré.

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

                              Le jeudi 05 mai 2011 à 14:13 +0200, Albert_ a écrit :
                              > Se connecter sur le pc voisin. C'etais fait en deux clics avec les
                              > macs et
                              > avec avahi cela aurait du etre pareil

                              c'est fait en un clic, avahi annonce les services (chez moi ssh, sftp)
                              et nautilus y accède facilement.

                  • [^] # Re: linuxo-centré.

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

                    Pulseaudio, un programme de la première importance ? Y a un truc pas clair dans ta tête...

                    • [^] # Re: linuxo-centré.

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

                      Par ailleurs, j'imagine mal Redhat, Suse et Debian laisser systemd devenir un machin inutilisable alors que ce programme est de la première importance.

                      Sa tête a l'air d'aller bien, par contre il te faut peut être faire vérifier ta vue ...

        • [^] # Re: linuxo-centré.

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

          Zenitram, ça me fait peur, je suis encore d'accord avec toi.

          Fait gaffe, à force tu es capable de finir par m'apprécier ;-).

          Non par manque d'innovation (certains ont eu de très bonnes idées), mais par manque de compatibilité les uns avec les autres.

          Exactement. Et en ne faisant pas attention à BSD, c'est ce qui peut revenir, si jamais un jour BSD prend de l'importance. Aujourd'hui, la chance est que Linux a une part de marché des *nix importante, mais le jour où un autre *nix viendra titiller, ben même problème que les UNIX, l'histoire est un éternel recommencement, l'être humain a du mal avec l'histoire

          Mais si le problème vient des organismes, il ne faut pas jeter le standard, mais bien l'organisme (ou le réformer).

          Par définition, décider à plusieurs sera toujours plus long que tout seul. Tout comme la démocratie est longue à décider par rapport à un dictateur. Mais c'est un mal nécessaire.

          les BSD sont des alliés, et standardiser un protocole ou une API permet toujours d'en voir tous les défauts (par la multiplicité des points de vue).

          On va être trop souvent en phase ;-).

    • [^] # Re: linuxo-centré.

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

      Je suis bien d'accord.

      Pourquoi vouloir à tout prix assurrer une compatibilité quasi totale entre BSD et Linux (voire entre les distros Linux), si c'est pour, au final, ne connaître quasiment aucune différences entre les systèmes et stagner sur des fonctionnalités utiles ? Autant en finir avec l'un ou l'autre.

  • # Quand même... pourquoi ?

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

    Déjà que j'ai toujours pas compris l'utilité de avahi à part bouffer de la RAM sans jamais servir à rien (et que j'ai toujours pas pigé à quoi servent les bloats type consolekit non plus), là ça ressemble bien à un bloat quand même, déjà par l'utilisation de DBUS (dans le process de démarrage WTF ?!), et rien qu'en voyant la liste monstrueuse des fonctionnalités et ceci : 2688 ko occupés, contre 244 ko pour sysv (paquets debian). 10 fois plus ! Quand on travaille comme moi sur une étendue de machines allant du quad core 8 Go de ram au celeron 64Mo en passant par des trucs à base d'ARM avec quelques Mo de RAM seulement, on ne peut que flipper en voyant une telle taille pour une tâche aussi simple normalement.

    Quand au problème de la rapidité, je dirais : vaut-il vraiment tous ces efforts, tout ce bordel ? Depuis debian squeeze mon laptop démarre en quelques secondes seulement, mon desktop un peu plus mais bon ça dépasse pas une minute. Pour une utilisation desktop justement, on s'en fout pas mal d'attendre 20 secondes de moins, on ne démarre sa machine qu'une fois par jour en général... Là où ça serait utile ça serait sur les équipements embarqués, par exemple sur mon e-reader oui 20 secondes de boot c'est naze, mais c'est le genre de matos ou de toutes façons un tel soft n'a aucune chance d'avoir sa place vu le bloat que ça semble être, sans compter les dépendances délirantes...

    Bref franchement : quel est l'intérêt de ce truc ?

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Quand même... pourquoi ?

      Posté par  . Évalué à 3.

      (et que j'ai toujours pas pigé à quoi servent les bloats type consolekit non plus)

      Ne t'inquiète pas les features de ConsoleKit vont être intégrée à systemd et tu pourra enlever CK de ta machine. \o/
      A quoi ça sert? A "amener systemd jusqu'au sessions utilisateur".

      http://lwn.net/Articles/441328/

    • [^] # Re: Quand même... pourquoi ?

      Posté par  . Évalué à 10.

      j'ai toujours pas pigé à quoi servent les bloats type consolekit

      Tu ne dois pas être le seul, l’auteur de la doc de ConsoleKit ne semble pas le savoir non plus :

      1. Introduction

      Defining the problem

      To be written.

      ConsoleKit sert donc à résoudre un problème que l’on ne savait manifestement pas résoudre avant sans lui, mais on ne sait pas exactement lequel.

Suivre le flux des commentaires

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