Journal GNOME seulement compatible avec Linux ?

Posté par (page perso) . Licence CC by-sa
75
18
mai
2011

Tout se perd ma bonne dame et les traditions ancestrales ne sont plus respectées. Alors que nous sommes encore à plus de 26 heures du vendredi fatidique un troll magistral, épique même, a débuté sur la liste de diffusion du projet GNOME.

Tout est parti d'un mail de Lennart Poettering intitulé « systemd as external dependency » dans lequel notre brave trolleur développeur proposait tout simplement que GNOME accepte systemd en tant que dépendance et devienne, donc, de ce fait, incompatible avec les systèmes sur lesquels systemd n'existe pas (les BSDs par exemple).
L'idée de Lennart est de se servir de systemd pour améliorer le fonctionnement général de GNOME. Il propose par exemple de faire gérer les sessions par son démon ou de lancer les applications automatiquement dans des cgroups. Selon lui ce sera un progrès qualitatif sensible que d'interfacer ainsi un bureau avec un système init aussi moderne et versatile que systemd. La vitesse de démarrage de la session serait aussi largement augmentée si c'est systemd qui prenait en charge cette tâche.
Bien entendu il aborde le sujet de la compatibilité mais c'est pour l'évacuer aussitôt en affirmant:

systemd est compatible uniquement avec Linux. Cela signifie que si nous continuons à nous préoccuper des plate-formes non Linux alors des logiciels de remplacement devront être écrits.

Josselin Mouette, développeur Debian bien connu, lui a rétorqué que l'abandon de la compatibilité avec tout ce qui n'est pas Linux était inacceptable:

Je n'ai rien contre le fait de requérir systemd, c'est certainement le meilleur système d'init qui est disponible actuellement. Mais la dépendance sur Linux est complètement inacceptable pour nous. Avoir des fonctionnalités optionnelles qui ne sont compatibles qu'avec Linux c'est OK. Exiger Linux cela ne l'est pas.

Réponse brutale de Lennart:

A la lumière du projet GNOME OS je pense que nous devons nous poser la question à nous même de savoir si il est positif pour le projet de continuer à supporter tous ces noyaux qui ne peuvent pas suivre le rythme de Linux.

Nous arrivons ici au coeur de la controverse. Le noeud du problème c'est que le rythme d'évolution du noyau Linux est extrêmement rapide et n'a plus rien à voir avec le train de sénateur des autres systèmes d'exploitations libres.
Pour prendre un exemple la technologie qui permet d'avoir la « gestion dynamique des interruptions » date du noyau Linux 2.6.21 (option CONFIG_NO_HZ). Avec ça vous pouvez avoir un système qui va arrêter complètement les réveils périodiques (tickless kernel). Tout ça date d'avril 2007 soit il y a plus de quatre ans maintenant.
En comparaison le système FeeeBSD, le plus avancé des BSDs sur cette question, va peut-être proposer un noyau tickless avec la future version 9.0. Selon l'excellente page « What's cooking for FreeBSD 9 ? » la réécriture de l'infrastructure des timers est effectuée mais le tickless kernel n'a que le tag « probably ».
Qu'on le veuille ou non il va donc y a voir de plus en plus de tensions entre ceux qui veulent profiter des nouvelles fonctions excitantes implémentées dans Linux et ceux qui préfèrent préserver la compatibilité à tout prix en se limitant au plus petit dénominateur commun ou en ayant des chemins de code différents.
En même cette solution n'est pas toujours possible. Après le mail de Josselin:

Jusqu'à présent rien n'a empêché GNOME de fonctionner sur un BSD, et ajouter une dépendance à Linux juste parce que tu ne veux pas maintenir quelques #ifdef dans systemd serait une grande perte.

Lennart a eu beau jeu de souligner que systemd utilisait à fond des dizaines de fonctions spécifiques de Linux et qu'il ne s'agissait nullement d'ajouter quelques bifurcations dans le code:

Il ne s'agit pas de quelques #ifedf. Laisse moi lister quelques interfaces Linux que nous utilisons dans systemd et pour lesquelles il faudrait trouver des remplacements:
cgroups
timerfd
signalfd
epoll
autofs4
inotify
fanotify
/proc/*/stat
/proc/*/comm
/proc/*/cmdline
libudev
POSIX mqueue comme fd
AF_UNIX/SOCK_SEQPACKET
espace de nommage abstrait AF_UNIX
get_current_dir_name()
canonicalize_file_name()
O_CLOEXEC/SOCK_CLOEXEC
/proc/*/fd
des tonnes de contrôles prctl() comme PR_SET_NAME, PR_CAPBSET_DROP, PR_SET_PDEATHSIG, ...
capabilities
des quantités d'ioctls, comme TIOCLINUX, VT_ACTIVATE, TIOCSTTY/TIOCNOTTY ...
/sys
/dev/urandom
/dev/char/*, /dev/disk/by-label/*, /dev/disk/by-uuid/*
openat() et toutes les variantes
O_DIRECTORY
waitid()
/sys/class/tty/console/active
/sys/class/dmi/id
ioprio
toutes les rlimits, comme RTPRIO/RTTIME
F_SETPIPE_SZ
IP_FREEBIND
oom score
binfmt_misc

Bien entendu certaines de ces fonctions seraient faciles à émuler ou bien ont des contreparties évidentes chez les autres OS, mais ce que je voulais montrer c'est qu'il ne s'agit en rien de quelques #ifdef. Il faudrait en mettre dans chaque ligne de systemd et je ne voudrais pas maintenir un tel monstre.
Ceci dit git est votre ami. Si des gens veulent porter ça sur d'autres systèmes il sont les bienvenus. Mais je ne partagerai pas votre souffrance si vous vous lancez.

Il a été pointé que le manque de bonne volonté de Lennart rendait les choses difficiles et décourageait les bonnes volontés des éventuels volontaires pour le portage:

Les gens ne feront pas ce boulot parce que tu a choisi de leur faire un doigt dès le début.
C'est la raison principale pour laquelle nous ne pouvons pas utiliser systemd dans Debian. Cela impliquerai, pour chaque paquet d'un démon, de fournir un script d'init sysv pour insserv un service systemd. Donc nous sommes coincés, au mieux, à devoir utiliser le plus petit dénominateur commun entre les différents systèmes d'init.
Au final ce comportement ne rend pas seulement la vie des volontaires pour le portage impossible. Cela dessert aussi l'adoption de ton logiciel.

Lennart a répliqué que Debian kFreeBSD ne devait pas se transformer en boulet empêchant l'innovation:

Je ne rend pas les choses plus difficiles. C'est vous mêmes qui vous rendez les choses difficiles. Debian kFreeBSD est un système d'exploitation jouet (toy OS). Environ 10 personnes sur cette planète l'utilisent. A peu près 0,4 de ces personnes fait tourner GNOME dessus. Et, sur cette demi-personne, seulement 0,2 s'attend à ce que ça marche correctement.
Je ne suis pas certain de comprendre pourquoi vous me demandez de m'intéresser à cet OS joujou. Je ne suis pas certain de comprendre pourquoi vous vous attendez à ce que votre intérêt pour ce système fixe l'agenda du projet GNOME.

Outre l'immense travail que nécessiterait une adaptation de systemd aux autres systèmes, Lennart a souligné que son objectif était de se servir de son démon comme un moyen pour standardiser certains fichiers de configuration. Cet objectif serait remis en cause si les autres OS avaient la possibilité de tout bloquer:

C'est du logiciel libre. Vous pouvez toujours démarrer votre projet, mais en définitive je ne pense pas que ce soit sensé pour moi de supporter tout ce travail de portage dans mon dépôt. Et n'oubliez pas que nous pourrions être amenés à utiliser systemd comme un moyen de standardiser des fichiers de configuration et que j'ai des doutes sérieux que nous puissions faire accepter ça aux autres noyaux. Par exemple si nous disons que /etc/locale.conf est le seul endroit ou on peut définir les paramètres des locales alors je doute sérieusement que les gars des BSDs ou de Solaris seront enthousiastes pour faire ça.

Voilà ou nous en sommes actuellement dans le monstro-thread lançé par Lennart. Il n'y a évidemment pas de décision de prise et, à la lecture des réactions, il semble fort probable que la proposition d'ajout de systemd comme une dépendance de GNOME sera rejetée...pour cette fois.
Si systemd démontre qu'il est vraiment supérieur à tout ce qui existe, si les fonctions qu'il apporte aux utilisateurs sont réellement uniques alors la tentation sera grande pour le bureau GNOME de profiter de ces bienfaits et de basculer complètement vers ce système. Nous verrons bien.
Et en attendant j'ai envoyé une demande d'interview à Lennart histoire de finir d'exaspérer complètement le squad ;-)

  • # Pas de systemd pour les autres OS, mais...

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

    Lennart, bien que n'étant peut être pas le champion du monde des diplomates, indique tout de même qu'il est tout à fait d'accord pour que d'autres projets implémentent les interfaces de systemd (par exemple, pour le centre de contrôle Gnome, toute l'interaction avec systemd serait via DBus). Pour les fonctions de base du style changer le hostname/la timezone, il serait trivial de faire un petit daemon pour BSD implémentant ces interfaces. Pour l'intégration avec les cgroups, il faudrait en effet rendre ça optionnel dans GNOME, mais c'est une partie qui est déjà bien plus hypothétique pour le moment. ConsoleKit ou PolicyKit de mémoire ne marchent déjà que plus ou moins bien sur les OS autres que Linux, et ça a été gérable jusqu'à présent...

  • # patrick_g...

    Posté par . Évalué à  10 .

    ... l'homme qui vous empêche de travailler. :-)

  • # Sale temps pour les BSDistes...

    Posté par . Évalué à  10 .

    Et pour les OS alternatifs en général.

    Xfce avait déjà commencé, avec sa dépendance à udev qui rend la compatibilité avec les BSD plus compliquée...

    Puis y'a pas que kFreeBSD chez Debian, y'a surtout la Debian Hurd !

    Mais toutes les fonctionnalités dont parle Lennart marchent-elles sur toutes les plateformes où Linux fonctionne ? Certaines ne sont-elles pas uniquement dispo en x86/amd64 par hasard ?

    • [^] # Re: Sale temps pour les BSDistes...

      Posté par . Évalué à  10 .

      Xfce avait déjà commencé, avec sa dépendance à udev qui rend la compatibilité avec les BSD plus compliquée...

      ca a déja été discuté ici, donc je rétablis une fois de plus la vérité.. Xfce est un DE qui se préoccupe de la portabilité, et le fait de manière propre.
      Cf la liste des dépendances fortes : http://wiki.xfce.org/releng/4.8/schedule#dependencies_fixed_after_2009-09-13

      Dans les versions précedentes (et ce depuis un bail), thunar-volman dépendait déja de HAL, xfce4-power-manager de upower. Dans la 4.8, HAL disparait et est remplacé par udev. Sachant que thunar-volman n'est pas dans le core d'Xfce ni indispensable a "l'expérience utilisateur", Xfce est toujours aussi portable sur les os alternatifs. Xfce4-session a une dépendance optionnelle sur policykit, consolekit, upower et consorts. En fallback, y'a sudo.

      • [^] # Re: Sale temps pour les BSDistes...

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

        Dans les versions précedentes (et ce depuis un bail), thunar-volman dépendait déja de HAL, xfce4-power-manager de upower. Dans la 4.8, HAL disparait et est remplacé par udev. Sachant que thunar-volman n'est pas dans le core d'Xfce ni indispensable a "l'expérience utilisateur", Xfce est toujours aussi portable sur les os alternatifs. Xfce4-session a une dépendance optionnelle sur policykit, consolekit, upower et consorts. En fallback, y'a sudo.

        C'est certainement un des commentaires les plus pertinents de la page! Je voudrais un peu développer sur le dernier point: en fallback, y'a sudo.

        HAL signifie hardware abstraction layer et abstraction signifie abstraction vis à vis de l'OS. Avant HAL on pouvait faire la liste du matériel et le manipuler par des outils userland s'en remettant au noyau, et chaque OS a ses méthodes et ses outils.

        Si j'ai bien compris, le projet de HAL est de fournir un moyen homogène d'accéder à ces énumérations et à ces opérations. Sur mon système (FreeBSD) HAL n'a jamais été complètement fonctionnel (énumération redondante de périphériques, pas de gestion de l'almentation, du réseau, etc.) et à ce que je sais, c'est le cas général sur les autres UNIX libres. L'hypothèse d'un HAL pleinement fonctionnel correspond donc dans les faits à l'hypothèse d'une machine Linux: abstraction 0, layer 1. Ainsi HAL n'a jamais résolu les problèmes qu'il prétendait résoudre: il est devenu un layer tout court, la façon moderne ou trendy d'accéder au matériel, en se donnant l'illusion d'une portabilité qui est toujours restée potentielle.

        En toute honnêteté, je ne comprends pas l'intérêt de se lancer dans un projet aussi grand que HAL alors qu'une petite famille de scripts servant à donner une interface homogène à l'accès au matériel aurait fait tout aussi bien pour la quasi-totalité des fonctionnalités de HAL (lire: pour monter les périphériques amovibles et éteindre la machine) avec une chance de succès bien supérieure.

        Pour monter les disques, depuis plus de 10 ans, j'utilise encore et toujours sudo.

  • # BSD pour serveurs uniquement ?

    Posté par . Évalué à  -7 .

    Les BSD seraient-ils en passe de n'être que pour serveurs uniquement ? OpenBSD, NetBSD et DragonFlyBSD, ils s'en cognent un peu de X.

    Là, Lennart s'attaque en fait principalement à FreeBSD. C'est un sale coup pour les adeptes de ce système et certainement pas le dernier.

    • [^] # Re: BSD pour serveurs uniquement ?

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

      OpenBSD, NetBSD et DragonFlyBSD, ils s'en cognent un peu de X.

      Toutafé et la secrétaire de chez M:tier elle fait tout en console.
      http://undeadly.org/cgi?action=article&sid=20110420080633

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question. | Free Softwares Users Group Arlon, Belgique : http://fsugar.be/

    • [^] # Re: BSD pour serveurs uniquement ?

      Posté par . Évalué à  9 .

      Les BSD seraient-ils en passe de n'être que pour serveurs uniquement ? OpenBSD, NetBSD et DragonFlyBSD, ils s'en cognent un peu de X.

      Toi, on voit que tu sais clairement de quoi tu parles.

      Saches qu'on peut avoir un desktop tout ce qu'il y'a de plus fonctionnel, avec Gnome/Kde/Xfce, et ca sous n'importe lequel des BSD. Fou ca, on peut même lire des vidéos, utiliser LibreOffice, Firefox 4 ou Chrome, jouer à des jeux, et écouter de la musique.

      • [^] # Re: BSD pour serveurs uniquement ?

        Posté par . Évalué à  6 .

        Je n'ai pas dit le contraire.

        Au sujet des BSD sauf FreeBSD, certes, j'y vais un peu fort avec "cogner". Simplement, je voulais dire qu'ils ne semblent pas (je modère) qu'ils concentrent leurs efforts sur l'expérience utilisateur. C'est ce que je voulais dire par X.

        Enfin, effectivement, je ne sais pas de quoi je parle, c'est pourquoi j'ai utilisé quelques points d'interrogations.

        • [^] # Re: BSD pour serveurs uniquement ?

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

          Simplement, je voulais dire qu'ils ne semblent pas (je modère) qu'ils concentrent leurs efforts sur l'expérience utilisateur. C'est ce que je voulais dire par X.

          Ça me parait clair que la cible pour les BSD est plutôt les serveurs, pas forcément par choix mais plutôt par manque de ressource. Mais tu peux quand même faire un desktop avec, ça demande juste plus de travail et il faut bien choisir son matériel.

          Quant à l'expérience utilisateur, sachant que l'utilisateur bsd moyen typique est aigri et mange les enfants, vaut mieux pas faire d'expériences avec.

        • [^] # Re: BSD pour serveurs uniquement ?

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

          je voulais dire qu'ils ne semblent pas (je modère) qu'ils concentrent leurs efforts sur l'expérience utilisateur.

          Ah oué... Tu devrais essayer un OpenBSD récent. Tu clickouilles pareil qu'avec
          un Linux, mais les pages de man sont bien plus claires..

          * Ils vendront Usenet quand on aura fini de le remplir.

        • [^] # Re: BSD pour serveurs uniquement ?

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

          Il y a des BSD qui visent spéficiquement une utilisation de bureau "standard". PCBSD et DesktopBSD, tous deux basés sur FreeBSD, en sont des exemples.

      • [^] # Re: BSD pour serveurs uniquement ?

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

        "jouer à des jeux"

        Tu veux dire d'autres jeux que Frozen Bubble ? Si oui, pourquoi ils sont pas portés sous Linux ? Zut alors !

    • [^] # Re: BSD pour serveurs uniquement ?

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

      ils s'en cognent un peu de X

      C'est certainement pour ça que la FreeBSD foundation paye quelqu'un _
      to implement support of GEM, KMS, and DRI for Intel Drivers._

      http://www.freebsdfoundation.org/project announcements.shtml#Kostik

    • [^] # Re: BSD pour serveurs uniquement ?

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

      OpenBSD [...] ils s'en cognent un peu de X.

      La Sparc64 de mon gamin est en OpenBSD, et crois-moi, X11, il ne s'en cogne pas.

      * Ils vendront Usenet quand on aura fini de le remplir.

  • # toujours la même chose

    Posté par . Évalué à  5 . Dernière modification : le 18/05/11 à 23:44

    On en revient toujours plus au moins à la même chose -> https://linuxfr.org/users/defmonkey/journaux/toujours-plus-vite#comment-1168975

    Toujours du blabla :

    • suivant le démarrage je peux faire ça ou pas
    • suivant le service qui plante je peux faire ça ou pas

    Maintenant j'aimerais qu'on me dise dans la vrai vie :

    • si c'est vraiment utilisé par d'autres personnes que les 4 qui m'ont répondues ?
    • que ceux qui l'utilisent me disent à quel fréquence ils ont un démarrage différent ?
    • si finalement c'est la bonne façon de faire ? Pourquoi ne pas proposer une interface une fois dans le Desktop Environment pour gérer les services à arrêter/démarrer (pour les gens allergiques à la ligne de commande).
    • [^] # Re: toujours la même chose

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

      Oui je pense que nous sommes nombreux à utiliser les bienfaits d'un init à plusieurs niveaux. Par exemple sur mon netbook, j'ai un runlevel spécifique pour la batterie. Franchement, je crois que tu passes à coté d'une fonction essentielle.

  • # dépêche !

    Posté par . Évalué à  -2 .

    Passionnant. Dépêche !

  • # BSD is dying

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

    Pour prendre un exemple la technologie qui permet d'avoir la « gestion dynamique des interruptions » date du noyau Linux 2.6.21 (option CONFIG_NO_HZ). Avec ça vous pouvez avoir un système qui va arrêter complètement les réveils périodiques (tickless kernel). Tout ça date d'avril 2007 soit il y a plus de quatre ans maintenant.

    D'accord mais tu as des cas où FreeBSD est en avance, par exemple les super pages ou la suppression du giant lock (et sûrement d'autres choses).

    On a les jails, ZFS, carp, Packet Filter... Perso je garde mon baril de BSD, ça marche out of the box et y'a pas à choisir son noyau à quatre décimales prêt...

    Pour udev, c'est pas forcément un bon exemple : il y a depuis longtemps devfs sous FreeBSD qui peut faire la même chose et ce serait assez facile de faire un wrapper autour. Visiblement le problème c'est plutôt qu'il n'y a pas de spec pour udev.

    • [^] # Re: BSD is dying

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

      Visiblement le problème c'est plutôt qu'il n'y a pas de spec pour udev.

      +1

      * Ils vendront Usenet quand on aura fini de le remplir.

    • [^] # Re: BSD is dying

      Posté par . Évalué à  2 .

      On a les jails, ZFS, carp, Packet Filter

      Jails ==> LXC (inclus de base dans le noyau et qui avec CGroups offre déjà des fonctionnalités plus fine que les jails), OpenVZ, VServers etc ... On peut aussi comparer le support de la virtualisation en tant que host (FreeBSD => VirtualBox, NetBSD => Xen, OpenBSD => qemu + support incertain de Kqemu, sous Linux, nativement, tu as KVM, lguest et bientôt Xen)
      ZFS ==> BtrFs et deux ports natifs sous Linux sont en cours.
      CARP ==> certes, pas de support natif dans la kernel, mais UCARP est là.
      PF ==> PF a de grandes qualité, mais si on mets de côté la syntaxe atroce d'IPTables (qui contraste furieusement avec celle simplissime de PF - et IPFilter et IPFW sont encores plus simples bien qu'étant moins souples que PF), sur le plan fonctionnel, ils se valent.

      Les *BSD ont d'énormes qualités (robustesse, cohérence, etc ...) mais ils sont à la traine, est-ce que la solution est de figer TOUTE innovations ? je comprends le point de vue de Lennart, et ça n'est pas la première fois que les *BSD sont laissés pour compte (suffit de voir l'état lamentable de X.org sur *BSD - merci, KMS & cie - où FreeBSD tente tant bien que mal de revenir sur cette régression fonctionnelle), je comprends que ça exaspère les *BSD-istes (dont je fais partie), mais quelle est la solution ? mettre des #ifdef partout au point de rendre le code non-maintenable à long terme ? (le but de systemd c'est à l'origine de se débarasser de TOUT les vieux hacks à la con dont certains plus personne ne se rappelle la raison d'être !), se limiter à un socle commun qui n'évolue PLUS ? ou bien de relancer le processus de standardisation autour de Posix ou bien d'un autre process de normalisation (Standard BSD and Open Unix-like Base ?) plus ouvert et plus aggressif ? Redynamiser le développement autour des *BSD faire contrepoids au tentaculaire Linux ?

      • [^] # Re: BSD is dying

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

        Les *BSD ont d'énormes qualités (robustesse, cohérence, etc ...) mais ils sont à la traine, est-ce que la solution est de figer TOUTE innovations ? je comprends le point de vue de Lennart, et ça n'est pas la première fois que les *BSD sont laissés pour compte

        AHAHAHAH pardon, mais laisse moi rire, je vais donc aller coder upstream des interfaces FreeBSD only pour telle ou telle fonctionnalité sans réfléchir à la portabilité et aller baver partout que linux est a la traîne parce qu'il n'implémente pas lesdites fonctionnalité et ne peut pas bénéficier de la dernière version de l'appli.

        Parce que libudev, par exemple. L'API est complètement délirante et linux centrique, pourquoi ne pas avoir réfléchi (sick) à une API propre ET générique genre je veux un truc qui me donne telle ou telle information. Et seulement ensuite chercher à l'implémenter au dessus des APIs linux ça aurait été plus simple et PORTABLE.
        Alors biensûr implémenter le tas de merde qu'est l'API actuelle de libudev au dessus des autres OS c'est possible mais au prix de noeuds au cerveau sur les autres OS et donc c'est long et sale. Ce n'est pas un boulot intéressant du tout donc c'est repoussé jusqu'à ce que l'on n'ai plus le choix.

        Ce n'est pas une question de retard mais une question de design pourri, il est passé où le temps ou les gens réfléchissait avant de pondre un code, le temps où l'on essayait coûte que coûte de pondre du code simple et portable ? etc.

        • [^] # Re: BSD is dying

          Posté par . Évalué à  4 .

          L'API est complètement délirante et linux centrique, pourquoi ne pas avoir réfléchi (sick) à une API propre ET générique genre je veux un truc qui me donne telle ou telle information

          Ce qui est délirant, c'est qu'aucun développeur *BSD n'ait daigné participer au développement de udev et après on vient se plaindre que les développeurs Linux font des interfaces spécifiques ... bah oui, forcément, faut p'tet descendre de sa tour d'ivoire et reconnaitre que les torts ne sont pas à sens unique.

          il est passé où le temps ou les gens réfléchissait avant de pondre un code, le temps où l'on essayait coûte que coûte de pondre du code simple et portable ?

          Certes, mais pour moi, le coeur du problème, c'est qu'il n'y a plus de concertation et qu'il n'y a aucun effort de normalisation quelconque. Il faudrait un FreeDesktop.org pour les OS Unix/Unix-like et beaucoup moins de mauvaise foi de part et d'autre.

          Signé, le monsieur qui bave et qui ne sait pas de quoi il parle.

          • [^] # Re: BSD is dying

            Posté par . Évalué à  10 .

            Ce qui est délirant, c'est qu'aucun développeur *BSD n'ait daigné participer au développement de udev et après on vient se plaindre que les développeurs Linux font des interfaces spécifiques ... bah oui, forcément, faut p'tet descendre de sa tour d'ivoire et reconnaitre que les torts ne sont pas à sens unique.

            Comment savoir lors de la création de udev qu'il allait devenir incontournable et qu'il fallait que les dev BSD participent au développement de Linux pour pouvoir se faciliter la vie quelques années plus tard?

            • [^] # Re: BSD is dying

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

              Surtout que dans le principe on n'avait pas besoin de libudev c'est pas comme si sur le papier libudev nous apportait quelque chose qui nous manquait... Donc aller participer a du dev linux sur quelque chose qui fournit un fonctionnalité que l'on a déjà...

              Bref.

              • [^] # Re: BSD is dying

                Posté par . Évalué à  2 .

                Certes, mais dans le cas de XFCE, aucune couche d'abstraction n'existe et quasiment tout les devs sont sur Linux (c'est le point d'achoppement). C'est un problème intrinsèque au libre, tu ne peux pas forcer les développeurs à développer pour un système qu'il n'utilise pas, comme on peut pas te forcer à développer pour linux.
                La solution, c'est qu'il y ait plus de gens de BSD dans les projets upstream, envoyer des patchs, normaliser les interfaces et que les gens sous GNU/Linux soient un peu plus ouverts mais tant qu'on reste dans une logique de guerre tranchées, c'est le plus fort (et pas forcément le meilleur) qui l'emportera.

                • [^] # Re: BSD is dying

                  Posté par (page perso) . Évalué à  10 . Dernière modification : le 19/05/11 à 10:20

                  quasiment tout les devs sont sur Linux (c'est le point d'achoppement).

                  Heu..il me semble que Gaston fait partie des 8 membres listés dans la nouvelle foundation XFCE non ?
                  Donc dire que les devs BSD ne s'impliquent pas c'est un peu fort de café ;-)

                  • [^] # Re: BSD is dying

                    Posté par . Évalué à  3 .

                    Donc dire que les devs BSD ne s'impliquent pas c'est un peu fort de café ;-)

                    D'où le quasiment ;) C'est du logiciel libre, on n'impose rien à personne, si XFCE impose une dépendance à udev pour Thunder, bah faut proposer une alternative or ça n'a pas été le cas pour le moment. Idem pour GNOME (c'est une proposition, rien n'est décidé, si quelqu'un a une meilleure proposition ==> feel free to do it), mais tant que personne ne fera preuve d'empathie, les BSD-istes continueront de penser que les GNU/Linuxiens sont des "cow-boys égoïstes" et les derniers que les premiers sont une espèce en voie de disparition juste bon à râler.

                    • [^] # Re: BSD is dying

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

                      tant que personne ne fera preuve d'empathie

                      C'est clair qu'il y a peut-être un phénomène de méfiance mutuelle, de concurrence entre les OS, de fanboyisme éhonté, etc.
                      Mais amha il ne faut pas oublier que la controverse ne repose pas que sur ces problèmes de compréhension mutuelle. C'est aussi une question technique comme tu le sais fort bien. Lennart a choisi de créer systemd en tant que projet propre, au code le plus réduit possible et en utilisant pleins de fonctions modernes de Linux. Il pense que se contorsionner pour ajouter des couches de compatibilité et des hacks pour faire marcher le bouzin sous BSD n'est pas envisageable. C'est un choix technique et l'empathie n'y changera rien. Après tout c'est son droit le plus strict de mener sa barque comme il veut.

                      Maintenant la question d'ajouter systemd en tant que dépendance de GNOME est complètement différente. Il me semble que GNOME ne devrait pas ainsi se couper des principaux systèmes alternatifs à Linux et je suis plutôt de l'avis de Josselin Mouette quand il dit OK pour des fonctionnalités optionnelles mais pas plus.

                      • [^] # Re: BSD is dying

                        Posté par . Évalué à  2 .

                        Ce n'est pas un choix technique mais un choix stratégique de restriction/ouverture de la population à laquelle le projet GNOME s'adresse.

                        BeOS le faisait il y a 15 ans !

                        • [^] # Re: BSD is dying

                          Posté par . Évalué à  4 .

                          Gnome peut sans problème s'enfermer avec Linux, je ne le pleurerai pas.

                          • [^] # Re: BSD is dying

                            Posté par . Évalué à  7 .

                            Moi non plus, vu que j'utilise les deux.

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

                          • [^] # Re: BSD is dying

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

                            Moi non plus, vu que je n'en utilise aucun.

          • [^] # Re: BSD is dying

            Posté par . Évalué à  7 .

            Oui enfin vu comment le developpement se passe de temps en temps surtout dans le monde lie a Gnome c'est pas simple de participer et vu que ce monde la refuse tout ce que eux n'ont pas pondu cela rend le probleme encore plus important.

            http://linuxfr.org/users/gnumdk/journaux/putain-de-nazis-de-linterface

            • [^] # Re: BSD is dying

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

              Il est sur que dans la logique "GNOME OS", normalement, les devs GNOME devraient en avoir rien à branler de *BSD.

      • [^] # Re: BSD is dying

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

        ZFS ==> BtrFs et deux ports natifs sous Linux sont en cours.

        Sauf que ce n'est pas encore utilisable, contrairement à ZFS sous BSD.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: BSD is dying

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

        Le jour est j'ai voulu configurer ucarp sous linux, j'ai juste eu peur et je suis vite retourné à carp et son unique ligne de conf sous openbsd.

        • [^] # Re: BSD is dying

          Posté par . Évalué à  4 .

          Si on voulait être de mauvaise foi, on pourrait dire que les développeurs d'OpenBSD ne l'ont pas conçu dans une optique de portabilité et que c'est pour ça que ça n'existe pas dans Linux. Et après les monsieurs de BSD nous répondront que les développeurs de Linux n'avaient qu'à participer au développement de CARP. :]

          Théo et Linus ont deux points communs, ils sont tout aussi compétents et tout aussi imbuvables socialement parlant, si on veut que les choses avancent, il faudra bien à un moment ou à un autre faire preuve d'empathie et discuter autour d'une table (ou d'un arbre, c'est rigolo aussi).

          • [^] # Re: BSD is dying

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

            Théo et Linus ont deux points communs, ils sont tout aussi compétents et tout aussi imbuvables socialement parlant

            Pas d'accord. Linus aime parfois troller et il a des opinions bien arrêtées sur pleins de sujets mais il me semble que son comportement n'a absolument rien à voir en comparaison de celui de gars comme Theo de Raadt ou Ulrich Drepper.

            • [^] # Re: BSD is dying

              Posté par . Évalué à  8 .

              son comportement n'a absolument rien à voir en comparaison de celui de gars comme Theo de Raadt ou Ulrich Drepper

              Ulrich Drepper c'est une catégorie à lui seul et quelques mondes le sépare du reste du peloton de tête. Je doute qu'on puisse encore le rattacher à l'espèce humaine.

              Linus aime parfois troller et il a des opinions bien arrêtées sur pleins de sujets

              comme Théo, je pense honnêtement que si tu les mets face à face, la question de savoir lequel des deux est le moins collaboratif risque d'être indéterminée.

              • [^] # Re: BSD is dying

                Posté par . Évalué à  1 .

                Au moins Linus a un vernis de sociabilité. Le Theo, dans son comportement c'est quand même un mini Drepper, non ?

                • [^] # Re: BSD is dying

                  Posté par . Évalué à  9 .

                  Ils ont en commun de diriger leur projet d'une main de fer et de reagir souvent de facon musclee.

                  Mais la comparaison s'arrete la a mon avis. Pour UD, on a des dizaines et de dizaines de cas documentes dans le bugtracker ou il refuse de corriger des bugs ou des problemes de portabilite en soit niant le probleme, soit en disant que cela ne concerne que des trucs pas importants et que donc c'est inutile de corriger les bugs.

                  Pour Theo, il y a peut-etre des dizaines de fois ou il refuse de corriger un bug ou d'aller regarder si il y a un probleme (portabilite, securite), mais j'ai comme un doute.

                  Dans tous les cas, je veux bien des liens sur Theo (et plus d'un ou deux tout de meme), histoire de me corriger si je me trompe.

                  • [^] # Re: BSD is dying

                    Posté par . Évalué à  2 .

                    Je parlais surtout de la facilité avec laquelle il insulte les gens. M'enfin, ce n'est qu'un ressenti ...

                    • [^] # Re: BSD is dying

                      Posté par . Évalué à  3 .

                      Je peux te citer sans problème une dizaine de personnes plus violentes que Théo de Raadt, mais plus dictatorial que le dictateur Ulrich sans hésitation = {0}

      • [^] # Re: BSD is dying

        Posté par . Évalué à  0 .

        Jails ==> LXC (inclus de base dans le noyau et qui avec CGroups offre déjà des fonctionnalités plus fine que les jails), OpenVZ, VServers etc ...

        Toi, t'as jamais utilisé les jails.

        Sedullus dux et princeps Lemovicum occiditur

        • [^] # Re: BSD is dying

          Posté par . Évalué à  6 .

          Toi, t'as jamais utilisé les jails.

          J'ai probablement plus utilisé les jails que toi LXC ...

          Si tu tiens à savoir, j'ai deux serveurs freeBSD uniquement pour ça, le premier me permet de confiner divers services (lighttpd, postgres, nginx, git, mercurial) -migré parce que la syntaxe affreuse d'IPTables me sortait par les trous de nez-, le second des slaves de compilation pour Jenkins pour tester diverses combinaison de bibliothèques.

          Côté Linux, j'ai pas mal utilisé OpenVZ et LXC, la seule chose que LXC aurait à envier aux jails, c'est les outils userland qui sont clairement à la ramasse pour LXC (c'est moins le cas avec OpenVZ qui a des outils très sympas mais qui lui est à la traine en terme de support).

  • # compatible avec rien ?

    Posté par . Évalué à  10 .

    La question de "Gnome est-il seulement compatible avec Linux" mériterait d'être posé différemment : "Gnome est-il encore compatible avec quelque chose" ? Parce qu'entre l'affichage dégueulasse (parait que c'est ma carte nvidia qui n'est pas assez puissante, pas assez compatible ou que sais-je), les problèmes lors des retours de veilles (artefacts, encore la carte, ou un autre composant ?), et cela sur plusieurs ordinateurs, quand je vois comment ça rame et c'est pas fonctionnel, j'en viens à me demander si gnome ce n'est tout simplement pas compatible avec rien du tout.

    Et encore, si on trouve qu'il y a redire à l'ergonomie, c'est forcément que l'on n'est pas compatible avec la vision avant-gardiste des dev de gnome, qui sont forcément plus calés que tout le monde sur le sujet, vu le nombre d'années qu'ils cogitent là dessus.

    J'aimais bien ce projet auparavant, mais maintenant ça ne ressemble plus à grand chose. Ils auraient mieux fait de forker et de proposer un nouveau nom (Calf par exemple)

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: compatible avec rien ?

      Posté par . Évalué à  6 .

      Il y a des bugs avec le CD de test ou distribution alpha que tu as essayé, mais de la à dire que ce n'est compatible avec rien c'est quand même exagéré.
      J'ai sauté le pas, et je tourne sous Gnome 3.0.1 avec des drivers libres pour Radeon (le kernel 2.6.39 qui vient de sortir devrait permettre à plus de carte NVidia de fonctionner aussi). Et je n'ai pas le moindre bug graphique.
      Après on aime ou aime pas le design. Mais j'ai essayé Unity et c'était de bidouille à côté de Gnome 3.
      Sous mon Gnome 3 en utilisation de tous les jours:

      • On peut finalement activer les 3 boutons pour minimiser/agrandir/fermer. On peut activer les icones sur le Bureau.
      • On peut gérer ses thèmes directement dans l'onglet Thèmes des Activités (extension)
      • On peut avoir un dock directement sur le bureau pour gérer ses fenêtres/applications/favoris. (extension)
      • Il y a un nouveau Menu Places sur le Panel pour accéder à ses racourcis comme avant. (extension)
      • Il y a un nouveau Menu Drives sur le Panel pour accéder à ses disques durs comme avant. (extension)

      Ces fonctionnalités sont activés via un système d'extensions très facile à utiliser. Il y a juste qu'aucune distribution ne les a intégré, donc pour le moment il faut les installer soit même soit en compilant soit en activant des dépôts faits par la communauté en attendant que les distributions reprennent leurs boulot.

      Franchement, tous les reproches qu'on a fait sur les fonctionnalités non disponibles dans Gnome 3, sont déjà corrigés upstream. Les options de personnalisation sont disponible dans Gnome-Tweak-UI + Gnome-Shell-Extensions + Thèmes.

  • # mesdeuxcents

    Posté par . Évalué à  4 .

    Cette fois ce n'est pas pulseaudio (un truc en plus qui n'apporte presque rien, surtout comparé à d'autres à une évolution alsa_inside), c'est bien de pouvoir profiter des avancées du noyau... Et Lennart à moins le mérite, même s'il prends le rôle du chieur, de poser dès maintenant les objectifs de demain, (unifier, laisser de côté les doublons, compacter) donc les enjeux et la casse éventuelle.

    Finalement, tout est là :

    Si systemd démontre qu'il est vraiment supérieur à tout ce qui existe, si les fonctions qu'il apporte (...) sont réellement uniques

    Avoir des fonctionnalités optionnelles qui ne sont compatibles qu'avec Linux c'est OK. Exiger Linux cela ne l'est pas.

    ça doit être doublement tentant : d'un côté avoir des facilités pour profiter de ce que propose le noyau, et d'un autre moins de boulot sur le bureau.

    • [^] # Re: mesdeuxcents

      Posté par . Évalué à  2 .

      arff ...deux lignes commençant par > fait une seule citation, même avec un saut de ligne entre les deux.

  • # tant mieux

    Posté par . Évalué à  1 .

    Lennart a eu beau jeu de souligner que systemd utilisait à fond des dizaines de fonctions spécifiques de Linux et qu'il ne s'agissait nullement d'ajouter quelques bifurcations dans le code:

    Tant mieux, le jour ou debian passera a systemd, je crois que j'envisagerait de passer a une autre distrib (j'ai attendu 2 ans avant de me résigner a installer udev...; le montage par UID est une atrocité).

    • [^] # Re: tant mieux

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

      Gentoo n'est apparemment pas prêt de faire le pas vers systemd non plus, en tout cas pas par défaut. Ils sont passé au Baselayout 2 et à OpenRC récemment.

      « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: tant mieux

      Posté par . Évalué à  5 .

      Par curiosité, quel est le problème avec le montage par UUID ?

      • [^] # Re: tant mieux

        Posté par . Évalué à  10 .

        Et surtout où est le rapport avec udev ? J'utilise (et c'est surement le cas de plein de monde) udev et je monte mes partitions soit classiquement avec /dev/sdXY, soit par label avec /dev/disk/by-label/SWAP par exemple (lisible, pratique, etc. tant qu'il n'y a pas de conflits).

      • [^] # Re: tant mieux

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

        En ce qui me concerne j'éprouve des difficultés insurmontables à me souvenir des UUID des partitions de mes différentes partitions ; alors que je retenais sans trop de peine des hdaN et des sdbM. Je suppose qu'il existe des moyens simple pour s'y retrouver. Mais j'ai quelques fois un peu de mal à m'orienter à travers la prolifération de couches d'abstractions diverses dont l'importance ne me paraît pas systématiquement flagrante.

        • [^] # Re: tant mieux

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

          Tu n'utilise pas de fichier fstab? Tu monte tous tes disques à la main? Dans ce cas, tu peux toujours utiliser les /dev/sdXY mais les UUID ne sont pas fait pour toi.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: tant mieux

          Posté par . Évalué à  3 .

          j'éprouve des difficultés insurmontables à me souvenir des UUID

          Et même sans avoir à s'en souvenir, les recopier depuis /dev/disk/by-uuid/ sans copier coller, bonjour la galère .

          • [^] # Re: tant mieux

            Posté par . Évalué à  8 .

            Franchement, être sous Linux et se plaindre de devoir manipuler du texte, je trouve que c'est assez fort.

            On a quand même grep, cat, sed voire vim pour faire ça, et si vraiment ça ne va pas, avec GPM tu as la souris et le copier coller en console.

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

            • [^] # Re: tant mieux

              Posté par . Évalué à  1 .

              On a quand même grep, cat, sed

              Oui enfin d'un coté on se plain des fichiers de config XML, mais si c'est pour mettre des UUID dans des fichiers plats c'est gère mieux.

              Franchement il aurait pas été plus malin de maintenir dans un autre fichier de config le mapping UUID => /dev/sdXY, afin qu'il reste stable ?
              Ou je sais pas au moins accepter comme git de ne préciser que le début de l'UUID.

              • [^] # Re: tant mieux

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

                Franchement il aurait pas été plus malin de maintenir dans un autre fichier de config le mapping UUID => /dev/sdXY, afin qu'il reste stable ?

                Pas bête tiens, du coup je te suggère une idée : mettre ce mappage dans un fichier ''/etc/fstab''. Un truc comme ça :

                # <UUID>                               <nom>
                # c5fd6598-c233-4efa-98e3-a1e252491618 sda1
                
                # <file system>                           <mount point> <type> <options>         <dump> <pass>
                UUID=c5fd6598-c233-4efa-98e3-a1e252491618 /             ext4   errors=remount-ro 0      1
                
            • [^] # Re: tant mieux

              Posté par . Évalué à  9 .

              Sinon, il y a les LABEL.

              • [^] # Re: tant mieux

                Posté par . Évalué à  4 .

                C'est tellement plus pratique, les labels... En plus ils ne disparaissent pas lors de l'installation d'un autre o.s :-)

                Et si je comprends la critique "une abstraction de plus dont l'importance n'est pas flagrantes" (grosso modo, au dessus, par Anglade Pierre-Matthieu), j'aurais tendance à la comparer avec le nommage des LVM, qui n'est pas, lui non plus, très friendly Pourtant ça fonctionne bien, et ce, depuis des années. Enfin il existe tellement de solutions pour retrouver la translation name / uuid (identiquer spécifiquement dans la fstab, comme le font certaines distributions qui simplifient la vie, ou bien dans /dev, etc etc) et de solutions pour ne pas avoir à les copier à la main qu'en fait je ne vois plus trop la critique réelle envers random/uuid

                • [^] # Re: tant mieux

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

                  En fait la critique de ma part — si tant est qu'il y en ait une — me serait plutôt adressée : je suis un horrible conservateur. J'avais mes petites habitudes qui marchaient plutôt bien pour mes petits usages et … pouf voilà que tout est bouleversé. Comment ? D'autres gens se permettraient-ils d'avoir des besoins différents des miens ? Et en plus les développeurs n'ont pas trouvé le moyen de me faire parvenir la doc des nouveautés directement dans le cerveau. Je suis obligé de me taper des pages de manuel et des recherches sur internet pour savoir comment gérer ces trucs nouveaux.

                  • [^] # Re: tant mieux

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

                    Je ne comprends pas, tu peux toujours monter tes disque avec le chemin /dev/sdXY, donc je ne comprend pas ce qui change dans tes habitudes.

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                    • [^] # Re: tant mieux

                      Posté par . Évalué à  2 .

                      le nommage /dev/hdxx dynamique par exemple, qui change entre 2 reboot ? Sur un serveur c'est pas génial.

                      • [^] # Re: tant mieux

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

                        C'était déjà le cas avant. Donc je ne comprend en quoi ses habitudes ont changé.

                        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: tant mieux

                    Posté par . Évalué à  2 .

                    +1. Tu décris merveilleusement bien mon attitude après chaque changement un peu marquant. Premier réflexe : grrrr !!!

              • [^] # Re: tant mieux

                Posté par . Évalué à  2 .

                Sauf quand on branche un second disque qui contenait aussi un système, et qu'on se retrouve avec deux partitions différentes de deux disques différents qui ont la même étiquette (par exemple, "boot" ou "root").

          • [^] # Re: tant mieux

            Posté par . Évalué à  2 .

            vim est très bien pour faire des "copier-coller", même si tu n'as pas X.

        • [^] # Re: tant mieux

          Posté par . Évalué à  9 .

          Oui, enfin, les UUID, pour moi, ca permet surtout de faire fonctionner un système automatiquement en montant automatiquement les partition, même si derrière tu rajoutes un autre disque dans ta machine et que l'ordre /dev/hdx# ou /dev/sdx# est changé.

          Je n'utilise jamais les UUID pour monter les partoche à la main, c'est du masochisme ;)
          Ca sert juste pour que le système continue a booter alors que tu n'as qu'ajouté un disque ou changé de nappe/port IDE/sata en bidouillant ta machine.

          • [^] # Re: tant mieux

            Posté par . Évalué à  3 .

            Comme écrit au dessus par quelqu'un d'autre, les labels pour ça, c'est BIEN aussi ! C'est comme les UUID, sauf que c'est lisible ^^ (pour peu qu'ils existent sur le type de filesystem concerné?)

        • [^] # Re: tant mieux

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

          La migration de certaines machines virtuelles d'un host à l'autre est également horrible.

        • [^] # Re: tant mieux

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

          Il y a des contextes où elle peut l'être, par exemple lorsque tes disques peuvent changer de /dev/sdX (ici j'ai du iSCSI avec des tiroirs de disques... d'un redémarrage à l'autre les sdX changent).

          Par contre, si ça n'a pas été enlevé, tu peux mettre des label sur tes systèmes de fichiers, et faire les montages en utilisant ces labels.

          Cf par exemple:

          • [^] # Re: tant mieux

            Posté par . Évalué à  3 .

            C'est génial de découvrir que dix ans après Linux découvre les UUID et les labels.
            Encore un petit effort et vous utiliserez la base de registre en ne disséminant pas des fichiers de configs aux 4 coins du dd et dans 15 formats différents ,ne recréerez pas des bousins chargés uniquement de les assembler pour les rendre présentables, et qui sait ... découvrirez peut-être les joies de la compatibilité binaire.

            • [^] # Re: tant mieux

              Posté par . Évalué à  2 .

              Il ne me semble pas avoir jamais lu une critique envers la base de registre. Vraiment, jamais. Ce qui est critiqué c'est son accès d'une part, et son organisation visible d'autre part : rien n'est fait dans l'esprit "clair, simple et documenté", au contraire : tout y est obscurci (pour des raisons qui dépasse le cadre de la remarque).

              Au cas où tu ne l'aurais pas remarqué systemd et sa potentielle clarification de etc (ainsi que /usr/share, brrr que c'est moche de coller de l'etc là dedans, par exemple pour alsa -merci qui ?, tiens, bizarre...-) reprends exactement l'idée de centralisation et de cohésion qui ont menées certainement la base de registre à être crée.

              • [^] # Re: tant mieux

                Posté par . Évalué à  1 .

                Sauf que la persistance des infos se fait toujours dans des fichiers dispersés aux 4 coins, qu'au lieu d'exposer une seule API, on en a 50, que l'implémentation est plus complexe puisqu'il faut tenir compte de plein de cas tordus.

                Les efforts de standardisation, les protocoles, c'est bien mais ca n'aide pas à homogénéiser entre
                - ceux qui veulent garder la compatibilité avec l'existant
                - ceux qui ne veulent pas se plier au standard mais demande à ceux qui maintiennent le bousin de s'y plier
                - ceux qui veulent un autre standard
                - ceux qui veulent un autre implémentation du standard et finissent pas adapter ce même standard
                ...

                Une API et une implémentation de référence unique propre au niveau kernel reprise par les couches de dessus ca aiderait. Soit en DB, soit dans sa propre arbo de fichier mais qui oblige à passer par l'API (sauf en cas de pb).
                C'est pourquoi l'idée de Lennart me séduit même si ca part d'en haut.

                Alors oui ca existe déjà mais en attendant ca n'est pas LE standard

  • # tickless comme justification de la modernité et de l'incompatibilité avec != linux ???

    Posté par . Évalué à  10 .

    L'exemple du tickless est très mauvais puisque gnome en a probablement rien à foutre que ton noyau soit tickless ou pas, sans doute comme 99.999999999% du userspace (l'epsilon restant étant d'éventuels programmes de diagnostique que je pourrais même ne pas compter du tout de par leur caractère particulier)

  • # Ouais.

    Posté par . Évalué à  10 .

    Sinon , il n'y aurait pas d'autres alternatives ?
    Ah ben si , il y a KDE.

    Sedullus dux et princeps Lemovicum occiditur

    • [^] # Re: Ouais.

      Posté par . Évalué à  10 .

      Et e17 !

      Ah non pas encore ...

  • # Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

    Posté par . Évalué à  10 .

    Nous arrivons ici au coeur de la controverse. Le noeud du problème c'est que le rythme d'évolution du noyau Linux est extrêmement rapide et n'a plus rien à voir avec le train de sénateur des autres systèmes d'exploitations libres.

    Je me contente de lire dlfp plutôt que d'y participer, pour diverses raisons, le manque de temps en étant la principale. Mais il y a des réflexions qui poussent parfois à remettre en cause ce choix, et celle-ci en est une.

    Ce message s'adresse d'abord à toi, mais aussi à la grande partie des libristes pingouinistes qu'il m'arrive de lire sur ce site.

    Il faudrait un jour que vous arriviez à vous faire à l'idée que comparer "Linux" à "BSD", c'est comparer des choux et des carottes. D'un, parce qu'il y a des différences fondamentales en terme de système, de communauté, de manière de travailler, deux, parce que les objectifs suivis par chacun diffèrent.

    Puisqu'on parle de train de sénateurs des autres systèmes d'exploitation libres, contre argumentons donc un peu.

    • d'un point de vue API: prenons l'exemple de kqueue/kevent, qui n'avait aucun équivalent sous Linux (et qui peine encore aujourd'hui à fournir des APIs similaires, sans être aussi broken que epoll()...). Linux a décidé de réinventer la roue à sa sauce. Heureusement que la libevent() est passée par là. Je me demande ce qu'il serait arrivé si on avait forcé tout le monde a exploiter les API kevent directement?

    • parlons des repompages de code BSD qui repartent subrepticement dans Linux, avec la facheuse tendance à oublier d'où ils viennent (tiens... les drivers Wifi de Damien Bergamini... oh, radiotap...). Forcément, heureusement (?) pour Linux, la mutualisation des efforts ne va pas dans l'autre sens. Evidemment, c'est la faute aux BSD parce qu'ils n'ont pas pris la bonne licence. Euh. Voyons voir. Peut être parce que Linux ne fait pas l'effort du dual licensing. Ah oui, suis-je bête. On se demande qui a raison.

    • dans la même veine, je passe sur les annonces bubuntuesque qui parle du premier système avec un X déprivilégié. J'invite certains à se renseigner sur ce que fait OpenBSD depuis... longtemps.

    Arrêtons là: chacun avance à son rythme, avec ses objectifs. Linux est loin d'avoir un rump à la NetBSD, les containers manquent de fonctionnalités que les jails et les zones ont depuis des années (pile réseau virtualisée, voire migration à chaud). Et pour profiter de ces fonctionnalités, faut déjà commencer par récupérer le patch qui traine sur un site X et recompiler le kernel. Bon. On se demande ce qu'est Linux au final, celui qui est packagé Redhat ou bien le fait maison par un hobbyiste ou une entreprise quelconque.

    La ou la communauté Linux a toujours voulu s'imposer, et n'y est jamais arrivé depuis 10 ans, c'est sur le marché du desktop, bien controlé par quelques acteurs. Comble de tout cela, le seul "OS Linux" (tellement modifié avec un userland "tout sauf GPL" qu'on se demande si c'est encore Linux) qui s'est démocratisé avec fulgurance n'utilisera pas systemd avant très longtemps (jamais?): Android. S'il fallait compter en volume, je voudrais bien comparer le nombre de variantes d'OpenSSH dans le monde avec les variantes Linux, tiens.

    Les BSD (du moins ceux que je connais bien, Net et Open) ont toujours souhaité faire les choses proprement et de la meilleure façon possible, et que ce travail puisse être réutilisé par d'autres sans contrainte (qui parlait de "liberté d'innovation"?). Le monde réel fait que ca n'est toujours pas possible; on s'y attache. Et tant pis si la dernière feature n'y est pas, parce que considérée comme bizarre, mal pensée, ou inutile/redondante.

    L'attitude puante des nombrilistes pensant que leur idée est la bonne et que le monde entier devrait se mettre au pas est assez préoccupante. Il m'est arrivé de lire ici qu'il était question avant tout de choix libre, non contraint, avec l'interopérabilité comme toile de fond. Vous savez, celle qui vous fait régulièrement cracher sur Microsoft ou Apple. Propos que je trouve subitement hypocrites.

    Si ca amuse la communauté Linux de reproduire un glibc/eglibc like, ou un fork GCC, libre à elle. C'est plus embêtant quand ca commence à polluer l'environnement FLOSS à cause de la grande gueule d'un seul, avec le soutien derrière de sa boite, qui a tout intérêt à dire que les autres systèmes libres sont à la traine, vu que ce sont ses concurrents directs (sans blague? Ben oui.)

    Tenez vous le pour dit, on n'obtient pas tout le temps de bons résultats en forçant la main aux gens.

    -- jym@NetBSD

    • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

      J'utilise Linux, je n'ai jamais essayé BSD autrement que via une Freesbee il y a quelques années.

      Mais franchement je trouve l'attitude de Poettering et ses soutiens en complète contradiction avec ce qu'a été le mouvement libre jusqu'à maintenant.

      Juste un truc:
      "Oh, ATI et nVidia, quand est-ce que vous arrêtez de jouer Windows seulement?
      - Ben ton serveur X m'emmerde, je veux pas l'utiliser, et puis vous êtes minoritaires. Sinon vous pouvez le faire vous-même!
      - Enfoirés!!"

      et maintenant:
      "Oh, les dévs Gnome, quand est-ce que vous arrêtez de jouer Linux seulement?
      - Ben j'aime pas ton noyau et ses fonctions manquantes, je veux pas l'utiliser, et puis vous êtes minoritaires. Sinon vous pouvez le faire vous-même!"

      Vous devinez la réponse?

      Elle est passée où la Liberté de choix, la Communauté du Libre (oui, avec un grand "C"), la notion de partage, tout ça?
      Ah ben non, c'est Linux, Linux, Linux, et les autres vont se faire foutre s'ils n'arrivent pas à "suivre".
      Définition de "suivre": abandonner son indépendance sur les choix techniques et copier systématiquement les nouvelles fonctions Linux pour éviter de se faire larguer.

      Franchement, si on arrive là, on pourra alors se demander à quoi bon utiliser la copie plutôt que l'original.

      Je n'ai même pas envie de commenter le "train de sénateur" tant ça manque de respect envers les développeurs qui travaillent sur ces noyaux.
      Poettering veut emmener l'écosystème Linux sur la voie de l'arrogance tant décriée chez les autres.

      J'aurais presque envie de dire à Poettering que s'il n'aime pas la politique de portabilité de Gnome, il peut le forker et on verra qui le suit!

      Sur la page d'accueil de Gnome:
      "We make great software available to all."

      Et sur la page "About":
      "it is the most popular desktop environment for GNU/Linux and UNIX-type operating systems."

      Ah ben non, plus maintenant?

      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

        Vous devinez la réponse?

        Surtout un fait : les linuxiens ne sont pas plus ouverts que les Windowsiens, dès qu'on parle de minorité :
        - Tu fais partie de la minorité, tu vas te plaindre de ne pas être pris en compte
        - Tu fais partie de la majorité, tu vas dire qu'ils font chier ces minorité.

        l'OS utilisé ne fait pas l'égalité et le regard sur les minorité dans la tête des gens...

        • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

          Toi tu n'as rien compris...

          Il y a une différence entre minorité d'utilisation d'un logiciel libre de celui de logiciels propriétaires dont Windows.

          Les utilisateurs mécontents de GNOME et *BSD par exemple sont libres de modifier ces projets pour que malgré les bâtons dans les roues que l'on pose, ils puissent les utiliser de concert comme bon leur semble. Sous Windows et les logiciels propriétaires, c'est marche ou crève, en somme on a pas le choix et toute décision de l'éditeur est irréversible.

          Exemple :
          Flash n'est disponible que pour Windows, Mac OS X et GNU/Linux par son éditeur Adobe. Etant propriétaire, il est impossible pour les utilisateurs de *BSD de le recompiler ou même le modifier afin que les utilisateurs *BSD puissent en bénéficier quelque soit leur volonté. La seule solution est de coder une alternative fonctionnelle ce qui est beaucoup plus difficile à réaliser.

          Par contre, ici, GNOME et *BSD sont des projets libres, si jamais GNOME n'était plus compatible avec *BSD pour une raison ou une autre, rien n'empêche aux utilisateurs de *BSD qui aiment GNOME de modifier ces projets afin que tout fonctionne correctement. Ceci est possible théoriquement et c'est bien plus simple et réalisable que le cas de Flash par exemple.

          Pour moi ces exemples expliquent pourquoi fondamentalement les cas que tu assimiles sont bels et bien différents. On critique aux logiciels propriétaires de ne pas donner la possibilité de porter leur application vers notre OS et de l'adapter, on ne leur demande pas de le faire mais d'en avoir la possibilité. Tu noteras par exemple que les développeurs de pilotes du noyau veulent surtout que les constructeurs libèrent leurs spécifications pour le matériel plus qu'ils ne le codent comme des pieds un pilote tout moche et propriétaire. Car au moins on aura la possibilité de le faire correctement.

          Ajoute à cela que non, on aime le logiciel libre mais on ne peut pas tout faire. Qui se préoccupe de porter naturellement ses applications vers Haiku, FreeDOS, ReactOS ou Hurd ? Personne pourtant ce sont des logiciels libres. Pourquoi ? Car leur communauté est ridiculement petite face à *BSD et GNU/Linux. Donc en tant qu'utilisateur du Logiciel Libre, on doit porter notre application vers tous ces systèmes d'exploitation même quand il n'y a que 2 pékins qui l'utilisent ? Non, en tant que développeurs, même si ce n'est pas une obligation, on doit rendre possible le portage, c'est à l'utilisateur de l'OS de porter si ça l'intéresse mais pour cela on doit lui donner la possibilité de rendre cela possible techniquement parlant. De même que beaucoup de développeurs ne font pas des paquets pour Fedora, Mandriva, Ubuntu, etc. très souvent il est préférable de donner des archives avec le code source et de laisser les empaqueteurs de faire les paquets pour leur distribution préférée.

          Car malgré tout avec ce système :
          -Tu facilites la vie du développeur qui se préoccupe de créer son logiciel et le rendre fonctionnel en évitant de perdre du temps et de l'énergie pour des utilisateurs peut être inexistants de son logiciel vers certaines plates-formes.
          -En général les empaqueteurs font de meilleurs paquets pour leur distribution que les développeurs qui n'utilisent pas cette dernière, il vaut mieux une archive bien construite pour facilité la vie des empaqueteurs que 10 paquets à construire de lui même pour faire plaisir aux gens
          -Cela ne bride pas l'évolution s'il y a rupture de compatibilité, les utilisateurs non satisfaits pourront forker ou patcher
          -Les utilisateurs peuvent avoir leur application favorite sur leur OS même s'ils ne sont que 10 à l'utiliser

          Cela n'entraine que deux inconvénients :
          -Le développeur du logiciel devra sans doute accepter et relire les patchs des utilisateurs qui ont perdu leur logiciel niveau compatibilité
          -Les utilisateurs du logiciels devront faire du travail eux mêmes pour avoir le droit à leur logiciel préféré

          Moi je vois le libre comme cela, en donnant la possibilité aux gens d'utiliser des logiciels comme bons leur semble sans demander au développeur la Lune.
          Puis je finirais que c'est un peu chiant de généraliser la pensée des utilisateurs de Logiciel Libre suivant les déclarations de quelques uns, ce n'est pas parce que certains s'offusquent du mauvais traitement de GNU/Linux par les éditeurs propriétaires que c'est le cas de tout le monde ici...

          • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

            Posté par . Évalué à  8 .

            ar contre, ici, GNOME et *BSD sont des projets libres, si jamais GNOME n'était plus compatible avec *BSD pour une raison ou une autre, rien n'empêche aux utilisateurs de *BSD qui aiment GNOME de modifier ces projets afin que tout fonctionne correctement. Ceci est possible théoriquement et c'est bien plus simple et réalisable que le cas de Flash par exemple.
            T'es un grand comique, toi.

            Définition d'un projet libre "type Linux" :
            - on a une idée
            - on code
            - on fournit le source
            - bien sur aucune spec définie, on fournit le source c'est suffisant
            - on trouve un truc génial qui casse toutes les specs initiales qu'un gus a essayé de retrouver pour pouvoir porter le bouzin
            - on code le truc génial : pendant ce temps le gus qui veut porter le bouzin essaie tant bien que mal
            - le truc nouveau est fini, on trouve un autre truc encore mieux, et on recasse ce qui a été fait avant.
            - pendant ce temps la premiere version avec les specifications initiale n'a pas été implémentée, et est déjà obsolète.

            Faudrait peut-être penser à spécifier avant de codern et ne pas faire les spécifications à la volée, surtout pour des trucs qui servent de briques de base à d'autres trucs de plus haut niveau.

          • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

            Posté par . Évalué à  3 .

            Tu noteras par exemple que les développeurs de pilotes du noyau veulent surtout que les constructeurs libèrent leurs spécifications pour le matériel plus qu'ils ne le codent comme des pieds un pilote tout moche et propriétaire.
            Tu ne veux pas de la libération de leur pilote proprio pourri pour retrouver les specs ?

            • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

              Rien ne dit que le pilote implémente toutes les possibilités du matériel, mieux vaut avoir les specs (idéalement sous licence libre afin d'être en mesure de les redistribuer déjà, voire de les actualiser en fonction de ce qui est visible dans l'implémentation, au besoin par rétro-ingénierie - légale en Europe - des fois qu'il y ait des choses plus complètes que dans la spec ou distinctes :D).

              Parfois les pilotes proprios relèvent de la magie avec des énumérations dont tu ne comprends pas forcément la plage de valeurs et ce qu'il se passe en mettant une valeur distincte ; la spec est censée identifier le comportement attendu (bon généralement le développeur a le bon goût de le mettre dans un header avec une description en commentaire, mais cela prête parfois un peu à interprétation, il est plus simple de comprendre la logique globale).

              Pour l'avoir vécu sur eagle-usb, cela peut prendre du temps de se décider à jeter le pilote écrit avec les pieds mais qui marchotte, en extraire des specs pour recoder plus simplement. C'est quand l'excellent Damien Bergamini l'a fait pour les *BSD que cela a permis de franchir le pas... et de lancer ueagle-atm qui a fait son chemin dans le noyau (en double licence BSD et GPL-2+ iirc, histoire que les modifs puissent repartir si besoin côté *BSD), simplifiant ainsi énormément sa maintenance et son utilisation par le commun des mortels : forcément un pilote de modem ADSL qu'il faut d'abord télécharger pour en bénéficier, ça fait un peu poule et l'oeuf :/ (bon après ya l'histoire du firmware, mais un seul troll à la fois on va dire :D).

      • [^] # Re: Du train desénateursdes autres OS libres, et de la mauvaise foi des libristes

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

        Le jeudi 19 mai 2011 à 07:00 +0200, maclag a écrit :
        > Définition de "suivre": abandonner son indépendance sur les choix techniques
        > et copier systématiquement les nouvelles fonctions Linux pour éviter de se
        > faire larguer.

        ils peuvent aussi proposer des patchs à systemd pour prendre en charge
        BSD ou proposer des patchs à Gnome pour se passer de systemd

        • [^] # Re: Du train desénateursdes autres OS libres, et de la mauvaise foi des libristes

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

          ils peuvent aussi proposer des patchs à systemd pour prendre en charge
          BSD

          Systemd n'a pas été conçu pour ça, c'est possible mais ça va être long et difficile, et sans aide du développeur principal.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Du train desénateursdes autres OS libres, et de la mauvaise foi des libristes

          Posté par . Évalué à  10 .

          ils peuvent aussi proposer des patchs à systemd pour prendre en charge BSD

          Et comme Lennart n'en voudra pas, ca va bien les avancer. Il dit lui meme qu'il ne veut pas salir le code avec plein de #ifdef's (raison legerement bidon par ailleurs, il est parfaitement possible de faire du code portable avec des interfaces internes bien definies et minimiser fortement le nombre de #ifdef's). Et que la solution privilegie, c'est forker le projet et faire ca de facon separee.

          Avec un mainteneur comme ca, c'est sur qu'on va trouver beaucoup de monde pour bosser avec lui.

    • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

      Posté par . Évalué à  4 .

      Linux est loin d'avoir un rump à la NetBSD

      CoLinux, UML etc ....

      les containers manquent de fonctionnalités que les jails et les zones ont depuis des années (pile réseau virtualisée, voire migration à chaud

      Actuellement, seul FreeBSD propose encore les jails, ça fait plus d'un an que NetBSD et OpenBSD ont retiré le support à cause d'un problème de sécurité. La migration à chaud, je le faisais avec OpenVZ quand NetBSD avait encore le support des jails, LXC le fait (Cf. freeze/unfreeze), pour la pile réseau virtualisé, c'est disponible

      Il m'est arrivé de lire ici qu'il était question avant tout de choix libre, non contraint, avec l'interopérabilité comme toile de fond. Vous savez, celle qui vous fait régulièrement cracher sur Microsoft ou Apple. Propos que je trouve subitement hypocrites.

      Le problème c'est que Microsoft ou Apple t'empêche d'être intéropérable, alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre (ils sont où les gens de NetBSD sur fd.o ?), pour les APIs noyaux, il n'y a quasiment plus aucun effort de standardisation et c'est fort regrettable. Je pense pas que côté *BSD, on soit aussi irréprochable que tu le dit.

      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

        Posté par (page perso) . Évalué à  9 . Dernière modification : le 19/05/11 à 10:27

        Le problème c'est que Microsoft ou Apple t'empêche d'être intéropérable, alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre

        Elle est où la spec de libudev (au moins udisk d'ailleurs) ? Je parle bien de spec complète histoire que pour implémenter libudev sur FreeBSD je n'ai pas a deviner ce que Linux ferait dans son /sys et tenter de transformer les identifiants de matos FreeBSD en équivalent /sys ?
        Elle est où l'annonce disant sur freedesktop: "hé, on va coder une interface générique pour l'accès au matos sous la forme d'une lib parce que hal était une mauvaise idée, voici mes idées discutons en ?"

      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

        Posté par . Évalué à  5 .

        Oui Fd.o cela semble ok si c'est Gnome qui pond une norme dessus, de preference sans discuter avec personne, mais si c'est KDE, par exemple, cela ne sera jamais adopte par Gnome.

        Par exemple:

        http://linuxfr.org/users/gnumdk/journaux/putain-de-nazis-de-linterface

        • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

          Posté par . Évalué à  1 .

          cela semble ok si c'est Gnome qui pond une norme dessus, de preference sans discuter avec personne

          Arrête de dire n'importe quoi, les archives des listes fd.o sont publiques, les normes fd.o sont discutés puis validés, après faut pas venir se plaindre.

          mais si c'est KDE, par exemple, cela ne sera jamais adopte par Gnome.

          Quelle norme ? si tu parles dbus-menu, Canonical et KDE ont fait leur truc dans leur coin avant de tenter de l'imposer.

          • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

            Posté par . Évalué à  -1 .

            Quelle norme ? si tu parles dbus-menu, Canonical et KDE ont fait leur truc dans leur coin avant de tenter de l'imposer.

            Donne donc le lien ou Gnome a discuter de cela sur fd.o avant meme que les propositions canonical et KDE soit la.

            Ce n'est pas beau de re-ecrire l'histoire!

            • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

              Posté par . Évalué à  0 .

              Ce n'est pas beau de re-ecrire l'histoire!

              tu te fous de notre gueule ? On en a déjà parlé, et quand KDE avait lancé la discussion mclasen et vuntz avait fait des suggestions qui sont allés tout droit dans /dev/null et plusieurs mois après, KDE et Canonical se pointent avec un truc fini fait dans un coin en disant: "voilà, utilisez notre truc" et aseigo & cie ont fait leur numéro d'autistes digne d'un mccann. Les listes sont publiques, encore une fois.

              • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

                Posté par . Évalué à  -2 .

                Mais je croyais que KDE et Canonical avaient fait leur truc de leur cote? Tu te contredis un petit peu.

                Je sais que tu defendras Gnome et RH (et tout ce qui tourne autour) comme pbpg defend Microsoft et je n'ai ni l'envie, ni le temps de troller aujourd'hui.

                • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

                  Posté par . Évalué à  4 .

                  Mais je croyais que KDE et Canonical avaient fait leur truc de leur cote? Tu te contredis un petit peu.

                  1. KDE propose un truc sur la liste fd.o
                  2. mclasen et vuntz font des suggestions > /dev/null
                  3. Canonical et KDE s'associent et font leur truc dans leur coin sans jamais en parler sur fd.o où inviter des mecs externes à participer.
                  4. 9 mois* plus tard, dbus-menu vient au monde et les papas tout fiers demandent qu'on adopte le bébé et refusent toute critique

                  C'est quoi qui est contradictoire là-dedans ?

                  • durée non contractuelle pour les malcomprenants, j'ai la flemme de recompter la durée exacte en millionième de seconde séparant 1. et 4.
      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

        Posté par . Évalué à  10 .

        CoLinux, UML etc ....

        Raté, ce sont des port usermode d'un OS. Ce que n'est pas rump, qui est surtout une architecture kernel. J'invite à lire le site du projet un peu plus en détail. Voir le 3e commentaire sur le post du blog, par exemple.

        Le problème c'est que Microsoft ou Apple t'empêche d'être intéropérable, alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre (ils sont où les gens de NetBSD sur fd.o ?), pour les APIs noyaux, il n'y a quasiment plus aucun effort de standardisation et c'est fort regrettable. Je pense pas que côté *BSD, on soit aussi irréprochable que tu le dit.

        Houla, j'ai jamais dit que les BSD sont irréprochables. Etant développeur NetBSD, c'est difficile de me convaincre du contraire, je connais bien leurs qualités et aussi... leurs défauts.

        Microsoft et Apple n'empêchent pas de réimplémenter leurs specs: ca ne pose pas de problème à Wine.

        La coopération avec fd.o est parfois pénible, pour les mêmes raisons qu'avec la Linux Foundation d'ailleurs (voir le débat de la FHS sur la ML NetBSD). C'est une entité qui s'est imposée d'elle même étant donné le bordel qu'est l'écosystème de distributions Linux, et le manque d'homogénéité entre les distribs. Pour certains de ces standards (pas tous, heureusement), ils sont clairement pensés vers le "dénominateur commun": ouf, Linus a accepté de merger mon travail dans vanilla, c'est bon, c'est standard. Même si c'est fait en vitesse, et que cela amène à casser des fonctionnalités -- bienvenue, CONFIG_SYSFS_DEPRECATED_V2). Ca n'est que quand le bordel devient ingérable qu'on commence à se poser des questions. Bon.

        Voyez vous, un standard n'est pas une bête spécification qui dit "si vous voulez telle fonctionnalité, utilisez telle API." C'est un travail collaboratif entre plusieurs acteurs qui a un historique, et suit une démarche de rationalisation: ca doit rester stable dans le temps, et pas évoluer au gré des vents et des caprices d'un quidam qui a une nouvelle idée à rajouter dans le kernel parce que c'est bien. On se plaint régulièrement de la lenteur de POSIX à évoluer: c'est le propre même d'un standard, qui demande une certaine réflexion.

        Là ou le bat blesse, c'est que le monde FLOSS s'y prête mal; à cause des egos forts; du droit discrétionnaire de certains à disposer de leur bébé (le cas de la glibc est criant -- et un OS sans libc, ca va pas loin); du manque de moyens et d'investissement.

        Qu'il y ait peu de devs BSD qui collaborent avec fd.o est un fait; personnellement c'est un problème qui existe entre différents projets FLOSS: la coopération demande des ressources, et des projets critiques ont déjà du mal à staffer en développeurs. Vu que personne ne veut payer pour ca au final...

        Quant aux standards imposés façon "politique du fait accompli", cela refroidit beaucoup, et n'incite pas à collaborer. L'épopée HAL a servi de leçon, perso j'ai eu ma dose de debugging avec cette horreur. Faudrait comprendre qu'on a pas 1500 développeurs et que tous ne peuvent se permettre de réécrire la pile IP lundi, USB pour le mardi, et changer 3 fois les API du scheduler parce que ca nous chante.

        Après, c'est une question de design: quand le système est bien conçu, enrichir en fonctionnalités n'est pas tellement couteux, ni comme contourner le problème.
        Même si le "modèle systemd" arrive à s'insinuer partout avec ses linuxeries, c'est pas comme si on avait des compat_linux ou Linuxulator. Si cela en devient tellement pénible que le système est difficile à exploiter, on se tournera vers ailleurs. D'ici là que systemd s'impose partout, on sera passé à autre chose, et l'OS (au moins coté client) se bornera à être une couche pour lancer un web browser.

        En parlant de web browser, cette histoire d'API "forcing fonctionnalité" me rappelle les pleurs des libristes pour le support de l'accélération graphique matérielle sous Linux. Sauf que cette fois, ils étaient pas du bon coté de la barrière.

        • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

          Posté par . Évalué à  7 .

          Raté, ce sont des port usermode d'un OS. Ce que n'est pas rump, qui est surtout une architecture kernel.

          Au temps pour moi, décidément, j'ai du mal à cerner rump (si quelqu'un cherchait une idée d'article pour GLMF, ça fait un moment que j'ai rien lu autour des BSD :] )

          Microsoft et Apple n'empêchent pas de réimplémenter leurs specs: ca ne pose pas de problème à Wine.

          La différence majeure à mes yeux, c'est qu'en l'absence de specs, le source est disponible pour les balles d'yeux, les développeurs sont disponibles pour répondre aux questions, ce qui est rarement le cas avec nos zigotos de M$ et la pomme.

          C'est une entité qui s'est imposée d'elle même étant donné le bordel qu'est l'écosystème de distributions Linux, et le manque d'homogénéité entre les distribs

          En 2000, c'était le bordel pour l'interopérabilité des bureaux *nix, c'est pour ça que Havoc Pennington a eu l'idée d'un espace de discussion. Même si ça n'est pas parfait, fd.o a aplanit énormément de problèmes, et les petits s'y retrouvent (du moins, c'est moins pire qu'avant).
          Pour les couches basses du système (noyau + userland), ça commence à sentir très mauvais, Posix s'encroute, le rift est en train de s'agrandir et les égos sont encore plus énormes que ceux des développeurs de bureaux. Il est d'autant plus important de créer un espace de discussion et de faciliter les échanges de code (ne serait-ce que pour les pilotes ou définir des interfaces) que l'on est en train de recréer l'enfer des *nix propriétaires en pire et sans rien d'autre à gagner que de fragmenter inutilement le marché

          Faudrait comprendre qu'on a pas 1500 développeurs et que tous ne peuvent se permettre de réécrire la pile IP lundi, USB pour le mardi, et changer 3 fois les API du scheduler parce que ca nous chante

          certes, on a un gros problème d'incompréhension mutuelle, et un front désuni des OS libres ça n'aide pas à mutualiser les ressources (la division du marché pour obtenir la collaboration des fabricants, le manque de ressources -pas que chez BSD, Linux manque parfois de bras dans certains domaines-)

          On se plaint régulièrement de la lenteur de POSIX à évoluer: c'est le propre même d'un standard, qui demande une certaine réflexion.

          Le problème c'est qu'il n'y a plus de réflexion dans Posix, on toilette les API, y a eu la fusion avec SUS et c'est à peu près tout. Par exemple, avoir une interface standard moderne pour la gestion de notification; ça serait pas du luxe dans Posix, entre kqueue de BSD et les gesticulations linuxiennes, ben, on est content que libevent soit là (enfin, ça commence également à chier avec l'arrivée libevent 2.x)

          Là ou le bat blesse, c'est que le monde FLOSS s'y prête mal; à cause des egos forts; du droit discrétionnaire de certains à disposer de leur bébé (le cas de la glibc est criant -- et un OS sans libc, ca va pas loin); du manque de moyens et d'investissement.

          Je te plussoie.

      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

        Posté par . Évalué à  4 .

        alors qu'avec fd.o, tu as des specs librement implémentables et discutés dans un espace neutre
        Il n'y a pas de specs.

    • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

      Posté par . Évalué à  6 .

      La ou la communauté Linux a toujours voulu s'imposer, et n'y est jamais arrivé depuis 10 ans, c'est sur le marché du desktop, bien controlé par quelques acteurs.

      Peut-être à cause du fait qu'elle veuille toujours sacrifier à la mode du "il faut satisfaire tout le monde" qui n'est jamais d'accord sur la solution.
      Interopérabilité, réutilisabilité, modularité, abstractions, couches d'abstraction, piles, ... A force de construire une archi de bric et brocs interchangeables ... un peu mais pas complétement, les devs passent leur temps à tergiverser à s'adapter au lieu d'avancer vers une archi unifiée et cohérente.
      Entre les distribs, les systèmes de packaging, les modules, les serveurs X, les libs graphiques les desktops, les IPC ... même Canonical y perd son latin.

      J'en viens à regretter qu'Haiku ne progresse pas.

      Je trouve que la proposition de Lennart va dans le bon sens.

      patrik_g aurait pu avoir la décence d'attendre vendredi.

    • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

      Résumons, nous avons :

      Les BSD (...) ont toujours souhaité faire les choses proprement et de la meilleure façon possible, et que ce travail puisse être réutilisé par d'autres sans contrainte (qui parlait de "liberté d'innovation"?). Le monde réel fait que ca n'est toujours pas possible; on s'y attache. Et tant pis si la dernière feature n'y est pas, parce que considérée comme bizarre, mal pensée, ou inutile/redondante.

      Soit : BSD c'est bien, c'est interopérable, c'est propre, c'est vraiment libre.

      Il m'est arrivé de lire ici qu'il était question avant tout de choix libre, non contraint, avec l'interopérabilité comme toile de fond. Vous savez, celle qui vous fait régulièrement cracher sur Microsoft ou Apple. Propos que je trouve subitement hypocrites.

      Soit : Le monde Linux c'est une licence pas tout à fait libre, et une interopérabilité pas tout à fait véritable, bref c'est pas tout à fait bien.

      L'attitude puante des nombrilistes pensant que leur idée est la bonne et que le monde entier devrait se mettre au pas est assez préoccupante.

      Chercher l'erreur...

      Bon, plus sérieusement, heureusement qu'il n'y a pas que les nombrilistes pour penser que leurs idées sont bonnes car sinon personne ne les défendrait hein...

      Ou quoi ? Pour ne pas passer pour un nombriliste je ne vais défendre que des idées que je juge mauvaises ? Où alors je ne défend rien du tout, je ne me bat pour rien ? Why not, mais dans ce cas on la ferme (sinon on défend nécessairement quelque chose, y compris le droit de ne rien défendre...).

      Bref, tout ça c'est du blabla !

      Vous pensez que BSD c'est mieux et que l'interopérabilité quasi totale entre tous les Unix devrait être une priorité et c'est bien. Bah voilà, vous avez une idée, vous pensez qu'elle est bonne et vous la défendez. Et c'est très bien comme cela !

      Après chacun argumente pour ou contre etc.

      Mon avis personnel sur la question ? Franchement, je ne sais pas si systemd est meilleur qu'un autre, mais si demain GNOME n'est plus compatible BSD ça ne me fera pas mal pour autant. J'aime beaucoup GNOME 3, je l'utilise tous les jours sur mon Linux. Si demain je ne peux plus l'utiliser sur BSD, franchement il y a plein d'autres environnements que je trouve très bien qui pourront le remplacer (su BSD, je le garde sur Linux) et voilà !

      Au fond la remarque de je ne sais plus qui est juste : dans les fais personne ne se préoccupe d'une interopérabilité totale. Ça n'existe pas. Dans les faits presque tout le monde se fiche de HaïkuOS et de Hurd. L'interopérabilité dans le monde Unix ça veut dire : BSD et Linux, et c'est tout.

      La seule question est donc : GNOME est-il indispensable à BSD et BSD à GNOME pour justifier le freinage d'ajouts de fonctionnalité attendues, ou pas ?

      Ça n'est pas comme si GNOME était le seul desktop utilisable UNIX...

      • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

        Posté par . Évalué à  4 .

        Chercher l'erreur...

        Y'en a une belle: pousser des gens à s'aligner sur ses idées sans discernement (ie. admettre que les objectifs de GNOME ne sont pas ceux de Lennart), pour ensuite déprécier le travail des autres en les tournant en dérision (toy OS), c'est pas le meilleur moyen pour se faire respecter.

        Que je sache, on fait pas du forcing pour imposer les APIs BSD partout. Et pourtant, ca ferait pas de mal d'avoir un vrai sysctl, une interface proplib et pas whatmilles ioctl(), etc.

        Au fond la remarque de je ne sais plus qui est juste : dans les fais personne ne se préoccupe d'une interopérabilité totale. Ça n'existe pas. Dans les faits presque tout le monde se fiche de HaïkuOS et de Hurd. L'interopérabilité dans le monde Unix ça veut dire : BSD et Linux, et c'est tout.

        Le problème, c'est que compatible "Linux" ne veut rien dire. Déjà que c'est le bordel actuellement (s'assurer une compatibilité binaire correcte entre Debian/Mandriva/Gentoo/Redhat/Suse/Ubuntu passe forcément par de la recompilation, et pourtant c'est "Linux"), ca n'a pas l'air de s'arranger. Et je parle même pas d'Android, c'est pourtant "Linux" aussi.

        • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

          pousser des gens à s'aligner sur ses idées sans discernement (ie. admettre que les objectifs de GNOME ne sont pas ceux de Lennart), pour ensuite déprécier le travail des autres en les tournant en dérision (toy OS)

          C'est fascinant. En quoi Lennart "pousse-t-il" les gens à s'aligner sur ses idées ?

          Il leur met un flingue sous la gorge ?

          Il retire ses 3 milliards $ de dons annuel à GNOME pour forcer le projet à accepter ses décisions personnelles ?

          Non, il fait comme vous : il critique ce qui lui semble critiquable, il défend ce qui lui semble bon (et il réalise ses idées par ses logiciels) et il dit ce qu'il pense de certains projets (kFreeBSD).

          Comme vous qui dites ce que vous pensez de Linux, de Lennart etc.

          Un exemple ? Faut pas chercher bien loin :

          pour ensuite déprécier le travail des autres en les tournant en dérision (toy OS), c'est pas le meilleur moyen pour se faire respecter

          et puis juste après

          Le problème, c'est que compatible "Linux" ne veut rien dire. Déjà que c'est le bordel actuellement (...) ca n'a pas l'air de s'arranger

          C'est difficile d'accepter que l'on a des idées et qu'on les défend ?

          C'est difficile d'accepter que les propos de Lennart sont exactement du même type que les votre ?

          Que l'on critique Lennart, ça ne me gêne pas. Que l'on vienne lui reprocher de défendre ses idées, je trouve ça stupide, car tout le monde fait pareil, et vous faites pareil en ce moment même.

          Après on peut reprocher des manières de dire, très bien. Je ne connais pas le personnage de Lennart et je ne me suis pas occupé de toutes ces polémiques, je ne dirais donc rien là-dessus. Mais ça n'est pas cela qui me gêne dans vos propos.

          • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

            Posté par . Évalué à  10 .

            C'est fascinant. En quoi Lennart "pousse-t-il" les gens à s'aligner sur ses idées ?

            Vous n'avez manifestement pas lu les liens de l'article...

            Il leur met un flingue sous la gorge ?

            C'est pénible les argumentations à l'extrême. Pas la peine d'aller jusque là.

            C'est difficile d'accepter que l'on a des idées et qu'on les défend ?

            Si la défense consiste à attaquer d'autres projets, il y a un problème fondamental de communication et de respect d'autrui.

            C'est difficile d'accepter que les propos de Lennart sont exactement du même type que les votre ?

            Euh, non, je n'accepte pas.

            Certes, chacun voit midi à sa porte. Plus que les propos, c'est l'attitude qui est répréhensible. Surtout quand elle est éprise d'une certaine mauvaise foi. Adopter une attitude "codez avec les APIs de mon OS chéri sans réfléchir, ignorez le reste du monde", c'est un reproche maintes fois entendu contre d'autres systèmes, et qui continue de poser des problèmes. Manifestement, la leçon n'a pas été apprise.

          • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

            Posté par . Évalué à  2 .

            C'est fascinant. En quoi Lennart "pousse-t-il" les gens à s'aligner sur ses idées ?

            Il leur met un flingue sous la gorge ?

            Faut arrêter la démagogie. Si je viens sur linuxfr et que je crée un journal pour dire que la version RoR elle est nulle et qu'il faut tout recoder en Catalyst, c'est que je viens pousser l'utilisation d'un framework.

            C'est juste ridicule de parler comme ça. Personne ne force personne, tu n'est pas obligé d'acheter un PC avec Windows dessus, personne n'est venu te dire de faire quoi que ce soit,...

            Après quand on a un nom, tout le monde sait que ça auras plus d'impact.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

              Faut arrêter la démagogie. Si je viens sur linuxfr et que je crée un journal pour dire que la version RoR elle est nulle et qu'il faut tout recoder en Catalyst, c'est que je viens pousser l'utilisation d'un framework.

              Et bien oui, c'est précisément ce que je dis. Lennart a une idée et il l'a défend, comme tout le monde ici. Mes réponses sur ce fil consistaient moins à défendre Lennart qu'à critiquer le discours à l'origine de ce fil :

              L'attitude puante des nombrilistes pensant que leur idée est la bonne et que le monde entier devrait se mettre au pas est assez préoccupante.

              C'est cette idée que je critique ici : l'idée selon laquelle défendre ce que l'on croit être bon est forcément un truc de nombrilistes.

              C'est simplement ridicule. Tellemement ridicule que dans le même message cette personne défend ce en quoi elle croit (BSD) en critiquant... Linux (par forcément à tort d'ailleurs) !

              C'est tout ! Lennart pense que systemd c'est bien pur GNOME, il le dit et il a raison de le faire.

              Après on peut dire, d'accord pas d'accord, mais venir lui taper directement dessus juste pour cela me semble pour le coup hypocrite.

              C'est juste ridicule de parler comme ça. Personne ne force personne, tu n'est pas obligé d'acheter un PC avec Windows dessus, personne n'est venu te dire de faire quoi que ce soit,...

              Alors là je suis moins sûr, la vente liée etc.

              • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

                Posté par . Évalué à  3 .

                C'est juste ridicule de parler comme ça. Personne ne force personne, tu n'est pas obligé d'acheter un PC avec Windows dessus, personne n'est venu te dire de faire quoi que ce soit,...

                Alors là je suis moins sûr, la vente liée etc.

                Il y a quelqu'un qui braque les gens pour leur demander d'aller acheter leur ordinateur chez Dell, Carrefour ou Géan ? Non ! Il est impossible d'obtenir un PC sans SE ? Non ! Il faut avoir un bac +5 logiciel libre pour savoir comment l'obtenir ? Non ! Au pire les gens sont ils obligés d'acheter des ordinateurs ? Non, à l'heure actuelle ils peuvent même prendre simplement une tablette android avec leur connexion internet (désolé mais cet argument il est du même niveau que de dire que ceux qui ne veulent pas (ou ne peuvent pas avoir systemd) peuvent très bien utiliser openbox).

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Du train de sénateurs des autres OS libres, et de la mauvaise foi des libristes

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

              D'ailleurs, au passage, je ne suis pas là pour défendre les idées de Lennart tout simplement car je ne connais pas systemd.

              Il est fort probable que faire dépendre GNOME de systemd soit une erreur, je ne nie rien de tel.

  • # il est chiant

    Posté par . Évalué à  8 .

    Je pense que Lennart devrait re-ecrire tout Gnome pour le rendre uniquement compatible avec RH/Fedora/systemd/pulseaudio et avahi. Tout le reste, vu que ce n'est pas ecrit par lui c'est de la merde en boite.

    Il y en a des melons dans le monde mais lui dans le logiciel libre.

    De plus il faut mentionner que Gnome ne tourne pas que sous *BSD et Linux mais aussi Solaris, AIX etc. Mettre des dependances comme celle la c'est une debilitude mais bon c'est du meme tonneau que la facon dont pulseaudio a ete force a tous les projets malgre tous les problemes que cela a engendre et continu de engendrer. Systemd est peut etre mieux foutu ou moins bugge que PA mais si c'est uniquement un truc existant sous linux cela ne DOIT pas etre une dependance forte d'un projet de desktop.

    • [^] # Re: il est chiant

      Posté par . Évalué à  4 .

      il n'a jamais imposé systemd, il propose que GNOME utilise l'interface DBus de systemd, rien n'interdit d'implémenter un daemon BSD pour faire la même chose différemment. DBus a été créé pour faciliter l'interopérabilité entre les bureaux, autant s'en servir, si l'interface de systemd pue, proposez autre chose, Lennart n'a jamais été fermé à la discussion (hein, il a réussi à mettre tout le monde d'accord au sein du mastodonte FHS), même si il est (très) rugueux sur les bords.

      De plus il faut mentionner que Gnome ne tourne pas que sous *BSD et Linux mais aussi Solaris, AIX etc.

      Tu veux que ton expérience de bureau soit limité au plus petit dénominateur commun ? bon courage avec AIX.

    • [^] # Re: il est chiant

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

      Il y en a des melons dans le monde mais lui dans le logiciel libre.

      Maintenant que l'on s'est fait plaisir en tapant sur la gueule d'un gars qui se retrousse, quand même, les manches pour faire avancer des trucs dans le monde du libre, on va quand même regarder un peu les faits : qui impose quoi ?

      Lennart est-il un dictateur qui a tout pouvoir sur ses esclaves que sont les devs de GNOME, eux-mêmes petits dictateurs de la standardisation Linux ?

      A-t-il imposé quoi que ce soit ? Non, il a proposé quelque chose, il a donné son avis, comme vous, comme moi en ce moment. Faut-il le brûler sur la place publique pour cela ?

      Cracher sur pulseaudio c'est bien joli mais qui vous impose son utilisation ? Et ceux qui apprécie pulseaudio (comme moi), vous leur dite quoi ? Que ce sont des cons qui n'ont pas compris que c'est de la merde en boîte ?

      Mais franchement, c'est quoi le monde du libre ?

      Des OS : Linux, BSD, Haïku, Hurd, ReactOS...

      Du son : OSS, ALSA, Pulse, Jack...

      Des DE : KDE, GNOME, XFCE, Enlightenment, GNUStep...

      Des WM : dwm, Metacity, Window Maker...

      Des éditeurs : ... n'en parlons même pas !

      Bref, c'est du CHOIX ! Et c'est pas parce que chez GNOME on dit un jour : on choisi systemd, que tout va disparaître.

      "Ah oui m'ai j'aurai plus mon GNOME sur mon kFreeBSD".

      Comme si un gars qui s'installe un kFreeBSD était incapable de se mettre à Xfce, voire OpenBox...

      • [^] # Re: il est chiant

        Posté par . Évalué à  -1 .

        Comme si un gars qui s'installe un kFreeBSD était incapable de se mettre à Xfce, voire OpenBox...

        Dis moi ce dont tu as besoin, je te dirais comment t'en passer. Tiens ca ressemble a la politique de la boite de redmond ca...

        • [^] # Re: il est chiant

          Posté par . Évalué à  4 .

          Tu te rends compte que tu arrives à cracher sur Microsoft alors que ni le thread ni le commentaire auquel tu réponds n'en parlent ?
          Tu ne penses pas que tu fais une légère fixation ?

        • [^] # Re: il est chiant

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

          Dis moi ce dont tu as besoin, je te dirais comment t'en passer. Tiens ca ressemble a la politique de la boite de redmond ca...

          Je ne suis pas à la direction de GNOME, je ne défend aucune stratégie marketing et je ne cherche pas à connaître les besoins de untel ou untel.

          Je ne dis à personne comment se passer de quelque chose, ce que j'ai dis c'est que les personnes qui utilisent BSD ont les moyens de se bouger les fesses et de passer de GNOME à KDE/XFCE/que sais-je et donc que si un jour (car ça n'est pas le cas actuellement) GNOME n'est plus dispo sur BSD, ça n'est pas la fin du monde pour ces systèmes ni pour ses utilisateurs.

          • [^] # Re: il est chiant

            Posté par . Évalué à  2 .

            Tu va loin dans la mauvaise foie.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: il est chiant

        Posté par . Évalué à  2 .

        D'autant plus que pulseaudio n'est pas indispensable, les liaisons sont artificielles (dépendances dans les paquets) et irréelles pour le système. On retire pulseaudio, on ne casse rien : le système continue de fonctionner, et on ne perds pas de fonctionnalités.
        (ps : ne met pas tout ceux n'utilisant pas pulseaudio dans le même sac, stp, beaucoup ne font que poser la question de son utilité réelle, et ne l'utilise pas. point)

        Avec systemd everywhere ce n'est plus la même sauce. Si Gnome se met à l'utiliser de manière exclusive et très intégrée, il ne semble pas qu'il soit alors possible de simplement le retirer du système, sans impact... ni de pouvoir le sélectionner en optionnel à la compilation. Donc ça ressemble réellement à une impasse. Ce que n'est pas pulseaudio (heureusement)

      • [^] # Re: il est chiant

        Posté par . Évalué à  10 .

        Oui tout est une question de choix. Si tu n'aime pas un truc, tu n'a qu'à l'éviter.

        Tu n'aime pas systemd ? Change de DE.
        Tu n'aime pas le monde propriétaire ? Passe au libre.
        Tu n'aime pas HADOPI ? Pourquoi rester en France ?

        Bref ton argumentaire est pathétique. Les gens gueulent parce qu'ils apprécient Gnome et ne pourront bientôt plus s'en servir ou ne pourront pas se servir de toutes ces fonctionnalités (si c'est déjà le cas ils voient que ça empire) ou qu'ils voient là de dans une dérivent qu'ils n'apprécient pas.

        Et toi tu viens la bouche en fleur "oui mais le gars il a bossé dur pour faire quelque chose qui marche pas chez vous, si vous êtes pas content quittez Gnome".

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: il est chiant

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

      Et puis franchement, quand j'entends la foule de couillons cracher sur les nazis de l'interface que sont les gars de GNOME, je me dis qu'ils devraient se réjouir d'apprendre qu'il pourrait ne plus être dispo sur BSD à l'avenir, ce sera une pollution en moins sur leur système de puritains pisse vinaigre.

      Ça fait surtout une bonne occasion de se faire une conscience en tapant sur la gueule à autrui.

      Ce que je fais moi-même en ce moment, hein... on se refait pas !

      • [^] # Re: il est chiant

        Posté par . Évalué à  2 .

        Tu as des chiffres pour savoir si ce sont plutôt les utilisateurs Linux ou BSD qui disent ça ? Ce qu'ils peuvent faire aussi c'est arrêter le projet si sur tout les systèmes où ils fonctionnent il y a quelqu'un qui a dis qu'ils étaient des nazis.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: il est chiant

        Posté par . Évalué à  3 .

        Et puis franchement, quand j'entends la foule de couillons cracher sur les nazis de l'interface que sont les gars de GNOME, je me dis qu'ils devraient se réjouir d'apprendre qu'il pourrait ne plus être dispo sur BSD à l'avenir
        Tiens pour ma part, je ne vais pas dire que ça me réjouit (je ne suis pas un grand fan de gnome, mais je suppose que certains utilisateurs B SD l'aiment bien). Par contre, s'il disparait des BSD, je ne le pleurerai pas.

    • [^] # Re: il est chiant

      Posté par . Évalué à  2 .

      De plus il faut mentionner que Gnome ne tourne pas que sous *BSD et Linux mais aussi Solaris, AIX etc. Mettre des dependances comme celle la c'est une debilitude mais bon c'est du meme tonneau que la facon dont pulseaudio a ete force a tous les projets malgre tous les problemes que cela a engendre et continu de engendrer. Systemd est peut etre mieux foutu ou moins bugge que PA mais si c'est uniquement un truc existant sous linux cela ne DOIT pas etre une dependance forte d'un projet de desktop.

      PA a été forcé à tous les projets ? C'est bizarre, j'ai jamais vu PA dans Slackware. D'ailleurs même sous Fedora, PulseAudio c'est pas obligatoire:

      $ sudo yum remove pulseaudio
      $ killall pulseaudio
      

      Testé et approuvé sous Fedora 13 et 14 KDE.
  • # Darwin chez les OS

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

    Sans vouloir troller... c'est le propre même du monde open source : les meilleurs restent et sont utilisés et interfacés par tous, les autres disparaissent lentement par manque de support et de volonté...

    Evidemment, je vois cela de la perspective d'un utilisateur Linux-only, je traiterais probablement Lennart de nazi des systèmes d'initialisation si j'étais adepte d'autres alternatives Unix...

    Forum Software Reviews: Comparez et testez les logiciels de forums Internet!

    • [^] # Re: Darwin chez les OS

      Posté par . Évalué à  2 .

      Fatche ! osé !
      Bientôt Dalvik (ou Harmony enhanced, ou Ceylon) nos desktops ?
      Brrr fear !

      Au delà des qualités techniques de systemd (ou pas, d'ailleurs) et au delà de la volonté de pouvoir profiter pleinement des avancées du noyau linux sur les desktops linux (ce qui me semblent bien légitime), y a juste un truc qui me chiffonne (vue d'en bas, hein) : que cela soit un mec et un seul qui propose. Parceque là, ce que j'ai lu des pointeurs donnés, il me semble que ça manque beaucoup de point d'interrogations (de questions aux gens).

  • # et si debian disait juste non

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

    Ce serait marrant de voir ce qui se passerait si debian disait non et n'implémentait ni systemD ni gnome trop dépendant de système D.

    On verrait bien ce qui se passerait.

    • [^] # Re: et si debian disait juste non

      Posté par . Évalué à  0 .

      On aurrait peut etre enfin une distribution majeur (et non mourrante) qui supporterait KDE...

      • [^] # Re: et si debian disait juste non

        Posté par . Évalué à  3 .

        Slackware et Arch sont mourantes ?

        • [^] # Re: et si debian disait juste non

          Posté par . Évalué à  5 .

          Tu as rate un mot, je t'aide sous la forme d'un pendu:

          m _ _ _ _ r

          (je garde la faute d'orthographe pour que cela soit coherent entre les deux messages :) )

          • [^] # Re: et si debian disait juste non

            Posté par . Évalué à  4 .

            et toi de ton côté tu as dû rater le mot "Arch"...

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: et si debian disait juste non

              Posté par . Évalué à  3 .

              Euh comment te dire... Arch c'est mignon mais de la a appeler cela une distribution majeure il y a un pas que je ne franchirai pas. Une distribution non negligeable peut etre mais majeur surement pas. Pour moi et c'est une liste tres personnelle je dois l'admettre les distributions majeures sont liste sur distrowatch et je suis desole mais non Arch n'en fait pas parti:

              http://distrowatch.com/dwres.php?resource=major

              • [^] # Re: et si debian disait juste non

                Posté par . Évalué à  2 .

                C'est vrai qu'on entend beaucoup plus parler de gens sous Mint ou sous PCLinuxOS (j'avais jamais entendu parlé de cette distro...) que de gens sous Arch !

              • [^] # Re: et si debian disait juste non

                Posté par . Évalué à  6 .

                marrant parce que dans la liste que tu pointes il y a Slackware, que justement tu ne comptais pas dans les distributions majeures, d'après ton commentaire précédent.

                D'autres part, distrowatch présente comme des distributions majeures divers fork, par exemple Linux Mint qui est un fork d'Ubuntu, ou PCLinuxOS qui est un fork de Mandriva. Archlinux a une base beaucoup plus originale (certains diront même, plus saine), et surtout question popularité, elle se situe justement avant Pclinuxos, Slackware, CentOS et Mandriva, pourtant classées comme "majeures", en arrivant en 6ème position de l'activité internet aboutissant à sa page sur distrowatch, depuis les 6 derniers mois (et 5ème en comptant depuis seulement le mois dernier, preuve de son intérêt constamment croissant)

                À mon avis il faudrait juste qu'ils révisent cette page des "distributions majeures", qui ne me semble pas vraiment refléter la réalité.

                Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                • [^] # Re: et si debian disait juste non

                  Posté par . Évalué à  3 .

                  D'autres part, distrowatch présente comme des distributions majeures divers fork, par exemple Linux Mint qui est un fork d'Ubuntu, ou PCLinuxOS qui est un fork de Mandriva.

                  Et Ubuntu c'est un fork pas libre de Debian (désolé j'ai 2 heures d'avance).

              • [^] # Re: et si debian disait juste non

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

                et c'est quoi l'importance d'utiliser une distribution majeure quand à
                la base tu n'utilise pas un OS majeur ni un DE majeur ?

      • [^] # Re: et si debian disait juste non

        Posté par . Évalué à  3 .

        Là maintenant Debian ne supporte pas KDE ? Tu sors ça d'où ?

        • [^] # Re: et si debian disait juste non

          Posté par . Évalué à  -3 .

          Il y a tellement de troll sur ce site que c'est difficile a suivre. J'ai deja repondu a cette question dans le fils:

          http://linuxfr.org/users/gnumdk/journaux/putain-de-nazis-de-linterface#comment-1231791

        • [^] # Re: et si debian disait juste non

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

          Je n'ai pas essayé récemment mais, à l'installation, quand on demandait d'avoir un environnement de bureau sous Debian, on se retrouvait avec Gnome par défaut sans autre choix.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: et si debian disait juste non

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

            Le jeudi 19 mai 2011 à 16:07 +0200, Xavier Claude a écrit :
            > Je n'ai pas essayé récemment mais, à l'installation, quand on demandait
            > d'avoir un environnement de bureau sous Debian, on se retrouvait avec Gnome
            > par défaut sans autre choix.

            ça veut pas dire pour autant que KDE n'est pas supporté.

            • [^] # Re: et si debian disait juste non

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

              C'est un exemple parmis d'autre, tous les outils de conf graphique sont en Gtk pour prendre un autre exemple. KDE est pris en charge, mais est clairement mis de côté.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: et si debian disait juste non

                Posté par . Évalué à  2 .

                C'est un exemple parmis d'autre, tous les outils de conf graphique sont en Gtk pour prendre un autre exemple.

                C'est quoi les outils de conf Debian ? Synaptic, Gdebi et l'installeur graphique ?
                Je l'utilise et je l'apprécie beaucoup, mais je ne connais pas beaucoup de logiciels graphiques Debian (et pas d'un projet upstream).

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: et si debian disait juste non

                Posté par . Évalué à  5 .

                Quels outils de conf graphique ?

                Debian n'a aucun outil de configuration graphique, si ce n'est ceux fournis par les bureaux (et dans ce cas, c'est normal que certains soient en GTK).

                Et si tu me parles de l'installateur, tu remarqueras que celui de Suse est en Qt, et que c'est pas pour ça que GNOME y est mis de côté.

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

          • [^] # Re: et si debian disait juste non

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

            nan, il y a un sous-menu pour l'environnement de bureau qui propose au moins kde et lxde, (pour xfce je ne voudrais pas dire de connerie), mais c'est vrai que si on ne va pas dans le sous-menu, on se retrouve avec gnome.... grrrrrrr

    • [^] # Re: et si debian disait juste non

      Posté par . Évalué à  3 .

      Pour quelle raison Debian refuserait si ça reste du libre ? En quoi ça violerait les DFSG ?

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

      • [^] # Re: et si debian disait juste non

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

        peut être que systemd leur plait pas et donc "non supporté" donc gnome deviendrait non supporté.

        • [^] # Re: et si debian disait juste non

          Posté par . Évalué à  4 .

          Tu dois pas beaucoup connaître Debian...

          Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: et si debian disait juste non

          Posté par . Évalué à  5 .

          Tu dis ça comme si Debian n'était qu'une seule et même personne.

          Alors qu'il suffit qu'un seul développeur Debian aient envie (et le courage) de packager ça et ça sera intégré.

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

          • [^] # Re: et si debian disait juste non

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

            D'ailleurs, il suffit de voir que debian a décidé de pas intégré QT à l'époque pour voir que ça a totalement interdit à KDE de continuer. Il suffit de voir que Fedora a décidé de ne pas mettre passanger ( pour ror ) ou node.js pour que ces technologies n'avancent pas. Il suffit de voir que Gnome-shell n'est pas intégré dans Ubuntu pour voir que le projet n'est jamais sorti. </ironie>

            Si debian ne veut pas d'un truc, c'est pas la mort ni pour eux, ni pour le projet qu'ils refusent. Ça va faire une séparation de plus, pas de souci, on gére depuis des années, on va continuer.

  • # Ethique or not ethique

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

    Les devs GNOME veulent supprimer la compatibilité avec les unix libres... Soit. Auront-ils autant de zèle pour supprimer la compatibilité avec les OS propriétaires Windows et Mac OS X ?

    On a des valeurs ou on n'en a pas !

    • [^] # Re: Ethique or not ethique

      Posté par . Évalué à  2 .

      Pour avoir une vraie comparaison, il faudrait que GNOME puisse s'installer sur Windows ou sur MacOSX, ce qui est loin d'être le cas.

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

      • [^] # Re: Ethique or not ethique

        Posté par . Évalué à  3 .

        je pense qu'il pensait plutôt à la gestion des ipod, à son implication avec mono et autres systèmes verrouillées :

        http://projects.gnome.org/hipo/

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: Ethique or not ethique

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

          Sauf que ça n'a rien à voir. Il existe un projet pour les ipod parce que quelqu'un fait le boulot. Il existe rien pour le moment pour l'api de systemd sur les os non linux parce que personne ne fait le taf. Le but est pas d'exclure, mais de choisir entre "attendre que quelqu'un fasse le boulot pour avancer" et "avancer pour que des gens fassent le boulot". Quelqu'un fait la remarque que personne ne savait qu'udev prendrais de l'importance. Soit, et du coup, ça rale pour ça.

          La, il y a eu des annonces ( le fait de reprendre systemd dans gnome-session date quand même de l'annonce initiale il y a un an ), il y a une proposition, donc l'excuse de "on savait pas que ça servirais à ça" est à mon avis non valide. Et pour le moment, c'est pas encore fait.

          Parler d'éthique, c'est totalement hors sujet, c'est oublier les fondamentaux d'un travail bénévole, à savoir que les paroles ne valent rien si c'est pas suivi de code et d'acte.

          • [^] # Re: Ethique or not ethique

            Posté par . Évalué à  3 .

            le but est pas d'exclure,

            pourtant tout le code de Gnome 2, qui fonctionnait parfaitement, et passé à la poubelle lors de la réécriture de gnome 3.
            Idem pour le projet Compiz, qui fonctionnait parfaitement avec gnome2, et qui n'est plus prévu pour gnome 3 et gnome shell.

            Et depuis gnome 3, je ne peux plus faire appel à des programmes gtk3 depuis un DE différent (KDE par exemple), ça bloque les boutons.

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: Ethique or not ethique

              Posté par . Évalué à  5 .

              pourtant tout le code de Gnome 2, qui fonctionnait parfaitement, et passé à la poubelle lors de la réécriture de gnome 3.

              Faux. Rien que le panel est toujours là, avec plus d'options qu'avant d'ailleurs (il est maintenant possible de centrer une applet).

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

            • [^] # Re: Ethique or not ethique

              Posté par . Évalué à  7 .

              pourtant tout le code de Gnome 2, qui fonctionnait parfaitement, et passé à la poubelle lors de la réécriture de gnome 3.

              Euh, la plupart des bibliothèques et applications ont été portées sur Gtk+3 et adaptés au shell, le peu de code qui est allé à la poubelle c'est essentiellement du code déprécié.

              Idem pour le projet Compiz, qui fonctionnait parfaitement avec gnome2, et qui n'est plus prévu pour gnome 3 et gnome shell.

              T'as essayé de faire fonctionner un autre windows manager avec Unity/Compiz ? T'as exactement le même problème qu'avec GNOME Shell/Mutter.

              Et depuis gnome 3, je ne peux plus faire appel à des programmes gtk3 depuis un DE différent (KDE par exemple), ça bloque les boutons.

              Sous F15, OpenSuSE Factory, ça juste marche hors de la boite (testé avec KDE 4.6, LXDE, XFCE), en revanche, t'es obligé d'utiliser le thème adwaita si tu veux pas que tes applications Gtk+3 soient dépareillées avec les applications Gtk+2.

Suivre le flux des commentaires

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