Journal Upstart pour remplacer sysvinit

Posté par (page perso) .
Tags : aucun
0
28
août
2006
Ubuntu travaille actuellement sur Upstart, un nouveau démon pour lancer et stopper les processus.
On avait parlé dans un autre journal de Mandriva qui avait choisi pinit : http://linuxfr.org/~Dark_Schneider/20468.html
Il existe également le projet initng mais Ubuntu veut un démon dynamique qui ne nécessite aucune politique de démarrage prédéfinie. Avec initng on doit définir explicitement la liste des dépendances alors qu'Upstart est bien plus autonome. L'article discute également des systèmes d'Apple (launchd) et de Sun (SMF).
Selon l'auteur Upstart conservera la compatibilité avec les scripts actuels.
La seule question à laquelle l'article ne répond pas c'est la date de sortie du logiciel. On peut penser que pour Edgy c'est rapé mais pour la version suivante ce sera vraisemblablement prêt.
Le lien :
http://www.netsplit.com/blog/work/canonical/upstart.html
  • # date de sortie

    Posté par . Évalué à 6.

    L'article mentionne pourtant des dates de sortie.

    "The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems"

    Si je comprends bien, pour Edgy, upstart remplacera init (le système actuel) et prendra en charge le lancement des rcS.
    L'ambition pour Edgy est donc de fournir un "équivalent" fonctionnel à init.

    Les autres fonctionnalités seront pour plus tard. (edgy + 1, voire +2)
    • [^] # Re: date de sortie

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

      j'avais pas vu.
      Mea culpa, mea maxima culpa.
    • [^] # Re: date de sortie

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

      > Si je comprends bien, pour Edgy, upstart remplacera init (le système actuel) et prendra en charge le lancement des rcS.

      Comme le mentionnais Mark Shuttleworth expliquant les différentes dénominations d'Ubuntu, Edgy aura pour but de faire plaisir aux UberGeeks et pour cela, beaucoup de choses vont être changées dedans. C'est un bon début :)

      Steph
  • # 14 juillet tous les jours !

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

    Quand on voit que chaque distrib part dans son coin, avec les scripts de démarrage, XGL ou pas, les systèmes de packages, etc. Ok, c'est du libre, c'est du choix mais quand je vois ce que le libre implique rien que pour configurer un NIS/NFS avec Debian/Mandrake/Suse/RedHat sans compter les différences entre version de la même distrib ...
    Quand on me pose une question système, ma première question est "Quelle distrib ?", vous trouvez ça normal ???

    On va avoir de moins en moins de mal a expliqué que Linux n'est vraiment que le noyau :/
    • [^] # Re: 14 juillet tous les jours !

      Posté par . Évalué à 10.

      Ça en revient à la question qui avait été posé sur la pertinence de certifications propres aux distributions facent à une certification générale pour Linux.
      Est-ce un mal ? je trouve pas, ça peut rendre le tout un peu plus obscure aux yeux du néophite, mais ça permet d'avoir un choix nettement plus large.

      Le fait de dire Linux n'est que le noyau, c'est vrai, mais ça devient en fait encore plus compliqué. Car voilà qu'en est-il de bsd ? je viens de tester, et en fait, j'ai je ne trouve pas plus d'adaptation que si j'étais passé à encore une nième distribution Linux. Alors, y a-t-il plus de différence entre Gentoo et FreeBSD ou entre Gentoo et Mandriva ? pas si évident de répondre.

      Voilà, la définition de ce qu'est un OS devient de plus en plus difficile a expliquer à un néophite, même si c'est plus claire pour un informaticien.
      Voilà en effet, Linux, BSD, peut-être un jour Hurd, tout cela est quand même très proche, et je pense que le bazare actuelle aux niveaux des distributions ne devrait pas être un problème.

      J'aimerai d'ailleur qu'il y ai encore plus d'OS grand public.
      parce que là, il y en a disons majoritairement 3, donc les fabricants peuvent encore se permettent de développer pour Windows, Linux et MacOS, mais si un jour on se retrouve avec 15 OS ayant chacun des parts de marcher à peu près égale, peut-être que ce jour là les fabricants, verront l'utilité de publier les spécifications de leurs matériels et laisseront les programmeurs respectifs des différents OS intégré eux-même les pilotes.

      Voilà, c'était un peu long, mal construit, et vous savez le pire, je vais même pas me relire. J'ai pas encore prie mon café, et j'en ai pas le courrage (de me relire, pas de prendre mon café).
      • [^] # Re: 14 juillet tous les jours !

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

        Quand même, niveau filesystem, FreeBSD (testé avec PC-BSD dans mon cas) ce n'est pas la même chose.

        Mes scripts qui utilisaient #!/bin/bash ne marchaient plus
        La hierarchie /usr/local est déjà remplie
        On trouve d'autres dossiers à la racine

        Et il doit y avoir d'autres différences ... mais c'est vrai que j'ai pu facilement retrouver KDE et un peu plus difficilement Gnome et le tout se ressemble beaucoup.
    • [^] # Re: 14 juillet tous les jours !

      Posté par . Évalué à 5.

      Mais concrètement, si toutes les distribs allaient dans la même direction, à quoi servirait d'avoir plusieurs distribs ?
  • # A surveiller...

    Posté par . Évalué à 10.

    La démonstration faite sur la page dont le lien est donné dans ce journal est assez convaincante et répond à l'avance aux questions "Ce sera compatible avec mes anciens scripts d'init ?", "Ca va apporter quoi ?". En outre cette dernière se trouve étayée et renforcée par les comparaisons faites avec les autres projets (aboutis ou en cours) de remplacement de l'"init system V traditionnel".

    Upstart remplacerait à terme init + at + cron + udev/hotplug + inetd. En gros, il serait un "administrateur évènementiel de processus". Chaque programme serait lancé en fonction d'un ou plusieurs évènements figurant dans cette liste (non exhaustive) :

    * Le système vient de démarrer.
    * La partition racine est à présent accessible en écriture.
    * Un périphérique de stockage a été ajouté au système.
    * Un système de fichiers a été monté.
    * Une date/heure précises sont atteintes ou un lap de temps est écoulé.
    * Une autre tâche vient d'être lancée ou vient de s'arrêter.
    * Un fichier donné vient d'être modifié.
    * Des fichiers sont présents dans un répertoire "file d'attente".
    * Un périphérique réseau vient d'apparaître.
    * La route par défaut vient d'être ajoutée ou supprimée.
    * Une connexion entrante sur un port donné est détectée.
    ...

    Les scripts proprement dits seraient encapsulés dans des fichiers qui commenceraient par l'énumération des conditions de lancement du script.

    Aux grincheux qui disent "Et allez : encore un autre init..." je répondrai que le temps et la "sélection naturelle" feront leur oeuvre mais qu'il serait bon de garder un oeil curieux sur cette solution élégante qui remplacerait une floppée de petits daemons indépendants...

    Allez lire la page indiquée dans l'article et venez donner vos avis éclairés sur les mérites et/ou défauts de cette solution et si vous mettez le doigt sur un défaut, communiquez-le à l'équipe de développement.
    • [^] # Re: A surveiller...

      Posté par . Évalué à 7.

      C'est vrai que sur le papier, comme ça, ça à l'aire super intéressant et résouderait plein de problème.

      Actuellement pour l'init sur Linux, je crois qu'il y en a 2 (j'ai perdu les noms)
      - celui utilisé par Slackware et les BSD
      - celui utilisé par les autres.

      Je suis sur Gentoo et son système d'init est une chose qui m'a beaucoup plus dessus et qui me manque quand je vais sur une autre distribution (même grand public).
      Par exemple, je ne veux plus lancer apache2 au démarrage de ma machine : rc-update remove apache2, et si je veux le remettre rc-update add apache2 et il va tout seul se placer après ses dépendances.
      D'ailleur, si je fait un /etc/init.d/net.eth0 restart (redémarrage du réseau), il va avant m'arrêter tout les processus dépendant et les relancer après.
      Mais je ne sais cependant pas, si c'est toujours le même système que les autres qui a été juste modifié.

      Mais c'est vrai que ce qui semble être ici proposé passe encore à l'étape d'au dessus et est vraiment pratique.
      Mais je ne sais pas pourquoi les autres distributions n'ont pas repris le système de Gentoo (quand je vois les docs d'Ubuntu juste pour désactiver LVM au démarrage, je trouve ça abérant).

      Et merci pour ce descriptif.
      • [^] # Re: A surveiller...

        Posté par . Évalué à 2.

        Par exemple, je ne veux plus lancer apache2 au démarrage de ma machine : rc-update remove apache2, et si je veux le remettre rc-update add apache2 et il va tout seul se placer après ses dépendances.

        Sous Debian, c'est update-rc.d mais si tu laisses les paramètres par défaut, ça prend le niveau 20 en S et en K et c'est pas obligatoirement celui désiré. Donc il faut se faire un petit script à soi.

        D'ailleur, si je fait un /etc/init.d/net.eth0 restart (redémarrage du réseau), il va avant m'arrêter tout les processus dépendant et les relancer après.

        Très sincèrement, je n'ai pas forcément envie que TOUS les services qui ont besoin du réseau aient l'obligation de redémarrer. Si ces services doivent redémarrer alors qu'ils n'étaient pas en cours de communication (et même dans ce cas là ça peut se gérer), c'est qu'ils ne savent pas reprendre sur une interruption de service (ce qui n'est pas toujours évidement à coder).
    • [^] # Re: A surveiller...

      Posté par . Évalué à 9.

      Le gros défaut que je vois à un tel truc, c'est qu'il fait trop de choses en même temps... Depuis les débuts d'Unix, on fait des programmes simples qui ne font qu'une seule chose et qui la font bien. Ça a fait ses preuves je pense et je vois mal comment on peut espérer développer une usine à gaz comme ça en quelques mois.

      Même si je pense qu'il faut rénover le vieux système d'init, cette solution ne me semble pas être la bonne. Mais je peux me tromper, on verra bien.
      • [^] # Re: A surveiller...

        Posté par . Évalué à 10.

        Hmm, oui et non, c'est une question de point de vue, je trouve.
        Certes, il pourrait "remplacer" beaucoup de choses en même temps, et vu comme ça ce n'est pas bon signe.
        D'un autre côté, on peut dire qu'il exécute des fonctions très simples:
        - surveiller les "évènements"
        - exécuter un script en réponse à un "évènement"

        Et de là on peut décomposer en un tas de choses simples: détecteur d'évènements, etc.

        Bref, l'ensemble fait peut-être beaucoup de choses en même temps, mais à vue de nez il ne me semble pas du tout impossible qu'il ne s'agisse pas simplement d'une collection d'outils simples.

        Enfin, faudrait aller jeter un oeil au code pour se faire une idée, parce que finalement j'ai l'impression de parler beaucoup dans le vide là...
        • [^] # Re: A surveiller...

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

          D'un autre côté, on peut dire qu'il exécute des fonctions très simples:
          - surveiller les "évènements"
          - exécuter un script en réponse à un "évènement"


          D'après l'article, c'est le point de vu des auteurs du logiciels : faire un démon de gestion d'évenement, qui ne fasse que ça, et qui le fasse bien.

          Ce que j'en comprend, c'est qu'ils vont essayer de factoriser la partie évenementielle redondante et continuer d'utiliser l'existant (les scripts appelés) pour le reste.
          Présenté comme cela, ça me semble tout à fait pertinent, tant d'un point de vu de la philosophie Unix précité que de la qualité logicielle de manière générale, mais peut-être que je n'ai pas compris le but cherché.
          • [^] # Re: A surveiller...

            Posté par . Évalué à 5.

            Quitte à faire mon vieux con, le terme évènement est suffisament vague pour y faire rentrer tout et n'importe quoi. Et je ne pense pas qu'un évènement matériel (brancher une clef USB) puisse être traité de la même manière qu'un évènement logiciel (envoyer un mail à tel date pour rappeler l'anniversaire de maman).
            • [^] # Re: A surveiller...

              Posté par . Évalué à 3.

              En tous cas, je veux bien un truc qui me monte mes clés USB automatiquement moi. Surtout plusieurs tant qu'on y est. Je trouve cette initiative assez intéressante.
              • [^] # Re: A surveiller...

                Posté par . Évalué à 3.

                Ca ça existe dans pas mal de distributions déjà non ?
                Enfin... je me souviens pas m'être occupé de ça depuis... très très longtemps.
                Le truc qui manque c'est la fonction qui permettrait de trouver sur quelle clé se trouve le fichier que je cherche.
              • [^] # Re: A surveiller...

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

                Installe une distribution datant de après 2002, et ca devrait aller.
                • [^] # Re: A surveiller...

                  Posté par . Évalué à 1.

                  Une Slackware courante ne le fait pas par exemple. Maintenant, c'est clair que je n'ai pas la distribution la plus user friendly, mais bon.
                  • [^] # Re: A surveiller...

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

                    Effectivement, mais le fait est que ce que tu veux existe deja depuis un bout de temps... Meme sous slackware d'ailleurs, juste pas par défaut.
            • [^] # Re: A surveiller...

              Posté par . Évalué à 4.

              d'un autre cote, un autre truc super vague, c'est "faire une chose".
              Et un autre encore plus vague c'est "bien le faire".

              tout ca pour dire que cette phrase ne veut rien dire, si ce n'est "ecrivez vos specs correctement, et de preference avant de valider le produit".

              Notez que je ne prends pas parti dans le debat de l'init.
        • [^] # Re: A surveiller...

          Posté par . Évalué à 2.

          - surveiller les "évènements"
          - exécuter un script en réponse à un "évènement"

          at et cron c'est plus des générateurs d'événements.
          • [^] # Re: A surveiller...

            Posté par . Évalué à 3.

            Je pense que comme évènements, il pensait à, par exemple "il est minuit", ou bien "la charge processeur est descendue en dessous de 1%"... cron réagit à des évènements temporels, et lance des commandes en réponse à ces évènements, non ?
  • # Plus d'info

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

  • # ah...

    Posté par . Évalué à -3.

    ...enfin


    ok --> []
  • # Les révolutions permanentes des bureau libres

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

    Salutations,

    C'est tout de même dingues de voire le parts considérable de nos système qui sont en train de se re concevoir.

    Il y a seulement 3 ans, qui parlait de HAL, DBus, AIGLX, upstart, Usplash, NetworkManager, Cairo, pulseaudio, swsusp, LiveCD, Avahi, etc. ? Tant de domaines qui sont en train de se réformer tout en gardant la compatibilité avec l'ancien monde. Les bureaux linux sont plus que jamais prêt pour le bureau, mais combien de domaine sont encore en chantier permanent ? Combien de régréssion de support matériel ou de fonctionnalités dû à ce chamboule tout permanent !?

    L'avantage de ces améliorations incrémentales (Gnome, Ubuntu, Fedora, Forsight tout les 6 mois, etc.), c'est qu'on n'est loin de l'attente béate de Vista, on vit dans les bugs dès maintenants :)

    Aussi c'est un sentiment partagé d'espoir perpétuel dans la prochaine version, de déceptions de bugs, de promesses mal tenue, etc. (Et je parle pour moi et Gnome Scan aussi).


    Pour revenir sur upstart. Ça me fait plaisir de voir un tel système. Il y a quelques mois, j'avais rêver d'un système où l'installation de support de périphérique se faisait "à la demande" en réagissant aux évènement (branchement, détection de service mDNS, etc.) et ce, dès l'installateur. J'ai écrit la specs : https://features.launchpad.net/distros/ubuntu/+spec/install-(...) pour Ubuntu. Quel joie de voir que la spec à été rataché à https://features.launchpad.net/distros/ubuntu/+spec/replacem(...) !

    Bref, l'avenir des bureaux libres et toujours aussi excitant. Je viens de découvrir auojurd'hui le "compiz tray icon" qui permet de passer de compiz à metacity à compiz en deux clics :).

    Que du bonheur.
  • # Pas les seuls

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

    En ce moment ça foisonne de ce côté là :
    FreeBSD a porté launchd (Apple) durant le SoC, non intégré pour des problèmes de licence (APSL inside)
    Fedora a aussi ouvert le chantier : http://fedoraproject.org/wiki/FCNewInit?highlight=%28init%29

    Je pense qu'il doit y en avoir plein d'autres.
    • [^] # Re: Pas les seuls

      Posté par . Évalué à 2.

      Il semble un peu au point mort. Néanmoins les fonctionnalités d'un nouveau init ont été largement débatues sur mailing et validées. Il y a un solide consensus. Il manque un développeur de disponible pour le développer.
  • # reverser dans debian ?

    Posté par . Évalué à 3.

    Si ils arrivent a faire un truc bien, peut-on esperer voir ce systeme dasn debian ?

    Je n'utilise ni debain ni ubuntu, mais comme j'ai cru comprendre que des gens chez debian n'apprecie pas enorment ubuntu, là pour le coups ca servirai la communauté... ca serait pas mal, non? pensez-vous qu'il puiss y avoir des retissences de debian ? (du point de vue politique donc) ?
    Savez-vous si un quelconque code ubuntu/canonical a déjà ete integré dans debian ?
    • [^] # Re: reverser dans debian ?

      Posté par . Évalué à -2.

      J'ai du mal à comprendre ce qu'est upstart, mais j'ai visiblement l'impression que c'est très orienté desktop, et n'a pas grand intérêt pour un serveur. Si c'est le cas (et je n'en suis pas sûr), ça ne correspond pas aux objectifs de Debian, et ça ne sera donc pas intégré.
      • [^] # Re: reverser dans debian ?

        Posté par . Évalué à 3.

        Tu sous-entends que Debian n'est qu'orienté serveur ?
      • [^] # Re: reverser dans debian ?

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

        Je dirais qu'il y a de très fortes chances que ce logiciel soit intégré. Mais je ne pense pas qu'il sera installé par défaut, c'est tout ...
        • [^] # Re: reverser dans debian ?

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

          Le paquet upstart dans son état actuel a été uploadé hier dans Debian (il est toujours dans NEW pour l'instant et devrait faire son apparition dans l'archive d'ici quelques jours).

          Il semble donc que Debian soit interessée (en l'occurence, c'est Scott James Remnant - le développeur ubuntu à l'origine de l'annonce - qui a fait l'upload)
      • [^] # Re: reverser dans debian ?

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

        L'objectif de Debian n'est pas de faire une distribution orientée serveur, mais de proposer tous les choix disponibles dans le monde libre à ses utilisateurs...
        Donc comme dit un peu plus haut, ça risque d'être intégré, si l'outil est libre...
      • [^] # Re: reverser dans debian ?

        Posté par . Évalué à 3.

        Euh, debian est pas forcément super orienté serveur en particulier, mais ils sont par contre très attentifs aux besoins "serveurs".

        D'ailleurs, on peut trouver des paquets init-ng sur debian, et qu'on ne vienne pas me dire que c'est une super avancée pour les serveurs!!

        Alors moi je dirais:
        - oui, il y a des chances qu'on voit ça sur debian un jour, sous la forme de paquets installables par qui en voudra, et bien sûr à condition que quelqu'un ait envie de le porter sous debian...
        - non, pour ce qui est de l'installation par défaut, ça m'étonnerait que ça se fasse de suite...
    • [^] # Re: reverser dans debian ?

      Posté par . Évalué à 2.

      Savez-vous si un quelconque code ubuntu/canonical a déjà ete integré dans debian ?

      Je me souviens avoir lu un changelog d'un paquet Ubuntu avec le changlog debian intégré et à un moment y'avait un truc comme "patch truc_bidule : thanks to Ubuntu developpers"
    • [^] # Re: reverser dans debian ?

      Posté par . Évalué à 1.

      Ouaip, par exemple :
      http://lists.debian.org/debian-devel/2006/08/msg01081.html

      Mais je ne suis pas sur que ce soit le meilleur exemple...
    • [^] # Re: reverser dans debian ?

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

      Franchement, même si je suis fan d'ubuntu et que je pense que Canonical avec leurs moyens peuvent initier de gros projets, je pense que la question ne doit pas être "peut-on esperer voir ca dans debian" mais "peut-on esperer voir ca dans toutes les distribs qui en tireraient avantage".

      Vu la grosseur du projet et les changements qui devront en découler (patcher à peu près tous les démons), j'espère vraiment que si le projet marche et qu'il s'avère convaincant, toutes les distribs potentiellement interressées s'y mettront histoire d'arriver à quelque chose de bien fini et sans bugs. Canonical tout seul ne peut pas je pense arriver à cela tout seul.

      Parce que pour le moment comme on peut voir dans l'article, chacun fait dans son coin et je crains que cela finisse en guerre "commerciale" mandriva/sun/apple/canonical/gentoo/etc et que chacun reste la avec son "mon truc est mieux" et qu'au final on avance pas.

      Donc que le meilleur (projet) gagne et que tout le monde soutienne le meilleur !
      • [^] # Re: reverser dans debian ?

        Posté par . Évalué à 1.

        guerre "commerciale" mandriva/sun/apple/canonical/gentoo/etc et que chacun reste la avec son "mon truc est mieux"


        Ah ben non, au contraire, avec l'avalanche de disparition de trolls ces derniers temps, il va bien falloir une nouvelle génération pour les remplacer! Là on va avoir AIGLX/GLX/autre/mieux/plus/Obiwan Kenobi et maintenant 14 systèmes qui vont succéder à init pour des trolls plus gros, plus velu, et plus mieux que les trolls d'ancienne génération!!

        Et d'ailleurs, ça me donne une idée révolutionnaire:
        -"Quel Troll est le meilleur Troll parmi les meilleurs Troll qui sont les suivants:
        * debian vs ubuntu
        * emacs vs vim
        * gnome vs kde vs rest-of-the-world!
        ?"

        Et voilà! Je viens d'inventer... le META-TROLL!!!
        • [^] # Re: reverser dans debian ?

          Posté par . Évalué à 2.

          * gnome vs kde vs rest-of-the-world!

          Pfffu, faux troll ... tout le monde sait que rien ne vaut FVWM ...
      • [^] # Re: reverser dans debian ?

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

        > Franchement, même si je suis fan d'ubuntu et que je pense que Canonical
        > avec leurs moyens peuvent initier de gros projets, je pense que la question ne
        > doit pas être "peut-on esperer voir ca dans debian" mais "peut-on esperer voir
        > ca dans toutes les distribs qui en tireraient avantage".

        Oui, mais du point de vue de Canonical, l'intégration de tel ou tel soft dans Mandriva n'est effectivement pas leur problème. L'intégration dans Debian, par contre, c'est un point clé d'après ce que dit Shuttleworth. Une question importante derrière ça, c'est : « si je veux faire du bien à Debian, est-ce que je peux le faire en m'investissant dans Ubuntu ».
    • [^] # Re: reverser dans debian ?

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

      > Savez-vous si un quelconque code ubuntu/canonical a déjà ete integré dans debian ?

      Euh, quand même, je sais bien que le troll sur Ubuntu est à la mode, on peut dire que Canonical ne fait pas assez d'efforts pour Debian par rapport aux beaux discours de Shuttleworth, mais quand même, oui, du code d'Ubuntu a déjà été intégré dans Debian, heureusement :

      $ zgrep -i ubuntu */changelog.gz | wc -l
      1319

      (ça inclue peut-être des « Remove the bloated f*cking patch from those ubuntu bastards », mais bon ;-) ).

      (ça, c'est sur les paquets installés chez moi)
      • [^] # Re: reverser dans debian ?

        Posté par . Évalué à 2.

        j'savais pas, c'etait un pas un troll (promis j'le jure, je n'utilise ni l'un ni l'autre, j'en suis a mandriva laors)

        Mais en fait ma question était plus "y a t'il des outils majoritairement canonical" plutot "des patchs canonical" ?
        Je penseais avoir comme reponse plutot "oui l'outils XXXX a été pondu par canonical et est maintenant utilisé pas debian".
        • [^] # Re: reverser dans debian ?

          Posté par . Évalué à 4.

          Il y a une update-notifier par exemple. Apparement Debian l'a modifié à sa sauce d'après la dernière DWN :

          Nouvelles fonctionnalités du bureau. Gustavo Noronha Silva a annoncé l'envoi d'une nouvelle version d'update-notifier. Cet outil, qui a été initialement créé par Ubuntu, place une icône de notification dans la zone de notification et avertit l'utilisateur quand des mises à jour sont disponibles. La version du paquet Debian envoie une notification qui indique la nécessité de redémarrage pour les paquets critiques seulement et informe l'utilisateur de l'insertion de CD/DVD dans le lecteur. De telles fonctionnalités devraient contribuer à faire de Debian une distribution plus agréable pour le bureau.

          Source : http://www.debian.org/News/weekly/2006/34/
      • [^] # Re: reverser dans debian ?

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

        mouais :

        $cd /usr/share/doc

        $zgrep -i ubuntu */changelog.gz | wc -l
        1385

        presque que comme toi

        $dpkg -l | grep "^ii" | wc -l
        2233

        j'ai donc 2233 "paquets" installés

        $zgrep -i ubuntu */changelog.gz | cut -d':' -f1 | sort | uniq | wc -l
        91

        j'ai donc 91 "paquets" qui mentionne ubuntu, en admettant qu'il ai tous un patch, ça fait 4% des paquets installés chez moi qui ont des retours d'Ubuntu.

        sachant que qu'il y'a pas mal de DD chez ubuntu dans les 95 paquets sont comptés les adresses mails de DD en machin@ubuntu.com

        maintenant tentons :

        $zgrep -i ubuntu */changelog.gz | grep patch | cut -d':' -f1 | sort | uniq | wc -l
        28

        ça vaut ce que ça vaut mais ça compte aussi les fucking patchs :)
        donc ça nous fait : 1.25% des paquets qui des auraient des patchs d'Ubuntu ...

        Oserais je dire que ton commentaire c'est du FUD ?

        M.
        • [^] # Re: reverser dans debian ?

          Posté par . Évalué à 2.

          Il serait bon qu'Ubuntu annonce officiellement l'intention de ne rien reverser à Debian.
          Comme ça on pourrait s'extasier quand par un malheureux concours de circonstance un micro patch bricolé avec les pieds par un incompétent de Canonical se retrouvait intégré par erreur à Debian. Voir même en faire une news de première page....
          • [^] # Re: reverser dans debian ?

            Posté par . Évalué à 2.

            > Il serait bon qu'Ubuntu annonce officiellement l'intention de ne rien reverser à Debian.

            Il est un peu crétin ton propos. Ubuntu fait du taff, si ça plait à Debian, Debian le reprend. C'est du logiciel libre, Debian n'a pas à attendre l'autorisation d'Ubuntu. Il est plus facile de reprendre quelque chose de développé que de le développer.
            Debian doit aussi avoir plein de taff de chez Red Hat ou Novell, Debian n'a pas attendu que Red Hat ou Novell le "reverse" à Debian.

            Puis, Ubuntu ne doit pas "reverse" son taff à Debian, mais il doit le mettre en upstream. Comme ça tout le monde en profite. Un bon exemple est AIGLX. C'était développé dans le cadre de Fedora, maintenant c'est dans Xorg (depuis la version 7.1).

            > Comme ça on pourrait s'extasier quand par un malheureux concours de circonstance un micro patch bricolé avec les pieds par un incompétent de Canonical se retrouvait intégré par erreur à Debian.

            C'est Debian qui maintient Debian ou c'est Ubuntu ?
            • [^] # Re: reverser dans debian ?

              Posté par . Évalué à 2.

              Oula... manifestement j'ai oublié les balises humour...
            • [^] # Re: reverser dans debian ?

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

              Tu réponds visiblement au premier degré à un post ironique, mais je vais marcher dedans aussi ;-).

              > Ubuntu fait du taff, si ça plait à Debian, Debian le reprend.
              > C'est du logiciel libre, Debian n'a pas à attendre l'autorisation d'Ubuntu.

              Bien sûr que c'est du logiciel libre, et heureusement.

              Mais le problème avec Canonical, c'est que quand tu écoutes les talks de Mark Shuttleworth (et d'un certain nombre de ses fans), on a l'impression qu'Ubuntu est la meilleur chose qui soit jamais arrivée à Debian, qu'Ubuntu a été créée pour booster Debian et pas pour la concurrencer. Et dans la pratique, bon nombre de développeurs Debian disent plutôt le contraire.

              > Puis, Ubuntu ne doit pas "reverse" son taff à Debian, mais il doit le mettre en upstream.

              Oui et non. Les contributions aux logiciels doivent ou devraient être remontés en upstream, mais il y a aussi tout le boulot de packaging, et là, il n'y a pas d'échange de code entre Debian et RedHat, mais le boulot fait par Ubuntu peut et doit être intégré à Debian si il est de qualité.
              • [^] # Re: reverser dans debian ?

                Posté par . Évalué à 5.

                mais il y a aussi tout le boulot de packaging, et là, il n'y a pas d'échange de code entre Debian et RedHat

                Ca peut arriver quand meme. Pour un package que je maintiens dans Debian, j'ai deja aide le mainteneur Fedora pour le packaging, en lui envoyant mes patches, lui expliquant quelles options je passais a la compilation, les problemes possibles, etc...
              • [^] # Re: reverser dans debian ?

                Posté par . Évalué à 6.

                > Tu réponds visiblement au premier degré à un post ironique

                Tant mieux si je me suis trompé.

                > Mais le problème avec Canonical, c'est que quand tu écoutes les talks de Mark Shuttleworth (et d'un certain nombre de ses fans), on a l'impression qu'Ubuntu est la meilleur chose qui soit jamais arrivée à Debian

                Ben en un sens oui. Pour le projet Debian, il doit certainement être plus facile de récupérer Xorg 7.1 d'Ubuntu que Xorg 7.1 de Fedora.
                Si Fedora améliore RPM, je pense que Debian en a rien à foutre. Si Ubuntu améliore dpkg, c'est que du bonheur pour Debian (et Fedora en a rien à foutre).

                > Ubuntu a été créée pour booster Debian

                Sûrement pas.

                > pas pour la concurrencer.

                Ubuntu concurrence (presque) tout le monde. Combien d'utilisateurs de Mandr(ake|iva) sont allez chez (K)Ubuntu ?
                Un beau paquet. Et combien de développeurs ? Un beau paquet aussi.
                Idem pour Fedora, Mepis, etc.
                Canonical n'a pas un arbre à développeurs et utilisateurs. Les développeurs et les utilisateurs sont venus d'ailleurs.

                > Et dans la pratique, bon nombre de développeurs Debian disent plutôt le contraire.

                Je vais être dur, mais Debian avait un capitale de sympathie principalement à cause de apt et car ça faisait "élite" d'utiliser Debian. Pourtant le projet Debian (je ne parle pas de la distribution) merdait. Des ressources considérables mais pas de leader pour fixer un cap et le tenir (voir Sarge et ses 18 mois de retard, voir le retard considérable par rapport aux autres pour avoir AMD64 presque "out of the box" alors que Sarge sortait en même pour des "ça se fait plus" qui représentaient 0,01 % des bécanes, etc).
                Quand Ubuntu est sorti, ça semblait une Debian (la distribution) sans les problèmes de Debian (le projet). Sauf pour les serveurs (mais pour 1 serveur il y a combien de desktop ?).

                Quand Ubuntu est sorti, beaucoup on dit que c'était un gros coup de pied au cul de Debian. Ca se confirme.

                Ceux qui participent à Debian ne sont pas contents. Et alors ?
                Ont-ils réellement été spolié ?
                Par vraiment, Ubuntu mène la dance et n'attend pas Debian, n'a pas (ou plus) besoin de Debian.

                Ce sont surtout les utilisateurs d'Ubuntu qui ont gagné avec la création d'Ubuntu. Et surtout les ex-utilisateurs de Debian.

                > le boulot fait par Ubuntu peut et doit être intégré à Debian si il est de qualité.

                C'est le boulot de Debian :-)
                Peut-être qu'au-delà de ces "broutilles", c'est surtout un manque de coopération (notamment dans les décisions qui orientent durablement les distributions) entre Debian et Ubuntu qui existe.
                Mais; Et si Debian n'etait pas la référence des distributions basées sur Debian ? Et si aujourd'hui c'était Ubuntu ?
                Et si finalement Ubuntu n'était plus basée sur Debian ?
                Et si finalement c'était Debian qui aujourd'hui était basé sur Ubuntu ?
                Et si Ubuntu est à Debian ce que Fedora est à RHEL, alors Debian est basé sur Ubuntu.
                C'est sur Fedora et Ubuntu que vont les développeurs. Pas sur Debian et RHEL.

                Avant la création d'Ubuntu, l'attractivité de Debian était presque une anomalie.
                • [^] # Re: reverser dans debian ?

                  Posté par . Évalué à 6.

                  "
                  Je vais être dur, mais Debian avait un capitale de sympathie principalement à cause de apt et car ça faisait "élite" d'utiliser Debian."

                  Apt et dpkg sont pour moi un grand mystère. Car encore aujourd'hui en 2006 ils sont bien plus performants que tout ce que j'ai pu toucher depuis la première fois que j'ai installé un système linux. (je ne compte pas le système de package rudimentaire de slackware, pour des raisons évidentes. Les tgz c'est rapide mais ce n'est rien d'autre que des répertoires compressés, sans plus..)

                  J'ai comparé les deux, au fil des années j'ai bien eu le temps. Installer un rpm téléchargé parait toujours plus long qu'installer un .deb. Utiliser yum dans la command line prends une éternité alors qu'apt-get install prends 3 secondes. Lancer Synaptic ou le nouvel outil d'Ubuntu prends moins de temps que le frontend graphique de Yum, et le système de recherche est plus rapide aussi.
                  Red Hat, SuSE et compagnie devraient ravaler leur fierté et se mettre au couple apt/dpkg. Parce que là, yum ou le fiasco ZMD de la dernière SuSE, c'est du purin.
                  • [^] # Re: reverser dans debian ?

                    Posté par . Évalué à 2.

                    > J'ai comparé les deux, au fil des années j'ai bien eu le temps. Installer un rpm téléchargé parait toujours plus long qu'installer un .deb. Utiliser yum dans la command line prends une éternité alors qu'apt-get install prends 3 secondes. Lancer Synaptic ou le nouvel outil d'Ubuntu prends moins de temps que le frontend graphique de Yum, et le système de recherche est plus rapide aussi.

                    En gros, apt est plus rapide. C'est tout.

                    > Red Hat, SuSE et compagnie devraient ravaler leur fierté et se mettre au couple apt/dpkg.

                    Tu devrait regarder d'un peu plus près rpm au-lieu de seulement voir la vitesse d'installation d'un paquet.

                    Depuis combien de temps il y a la signature des paquets dans dpkg ? Quelques semaines alors que ça existe depuis dans années dans rpm. Comment se passe la vérification des fichiers installés lorsque ces fichiers ont été modifiés par prelink ? Mal avec dpkg, sans problème avec rpm. Peut-on les controlers par rapport à la signature ? Comment sont détecter les dépendances à la création du paquet ? etc...

                    Simplement car apt est rapide, tu penses que rpm est de la merde. Notes bien que apt et synaptic existent pour rpm et qu'ils sont aussi rapides.
                    Effectivement yum est lent par rapport à apt. Yum c'est du python et apt du C. Tu t'attendais à quoi ?
                    Yum a un système de plugin. Et apt ?
                    Les dépôts Yum sont des fichiers au format xml. Et apt ?
                    Peut-on faire des requêtes sur les dépôts apt comme on peut le faire avec repoquery : http://www.die.net/doc/linux/man/man1/repoquery.1.html (160 champs du format rpm sont interrogables ).

                    ETC, ETC...

                    Je connais mal dpkg/apt et j'ai fort probablement dit des conneries ici sur dpkg, mais rpm ce n'est pas de la merde. Et OUI, python est plus lent que le C.
                    • [^] # Re: reverser dans debian ?

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


                      Yum c'est du python et apt du C (...)
                      Les dépôts Yum sont des fichiers au format xml. (...)


                      J'ai du mal a voir le rapport avec la choucroute. Contrairement au reste de ce que tu dis, aucune de ces 2 affirmations n'est un argument valable: on s'en fout de leurs choix technologiques ici, on essaye juste de voir la différence pour l'utilisateur...
                    • [^] # Re: reverser dans debian ?

                      Posté par . Évalué à 7.

                      Voir un tants d'approximations mensongères et personne pour y répondre... Allez, je me dévoue.

                      Je commence par citer la fin de ton message pour bien comprendre tout le reste:

                      Je connais mal dpkg/apt et j'ai fort probablement dit des conneries ici sur dpkg.


                      Donc je confirme, tu as dit des conneries...

                      Depuis combien de temps il y a la signature des paquets dans dpkg ? Quelques semaines alors que ça existe depuis dans années dans rpm.


                      Ca existe depuis au moins un an donc si "quelques" vaut au moins 52 dans ton esprit, ok.

                      Comment se passe la vérification des fichiers installés lorsque ces fichiers ont été modifiés par prelink ? Mal avec dpkg.


                      Tu peux sans doute nous faire part de ton expérience personnelle qui t'a poussé à affirmer ceci... Nous t'écoutons. Je n'ai jamais eu aucun probleme, notamment avec un xorg.conf modifié et jamais écrasé. Dpkg demande a l'utilisateur ce qu'il faut faire dans ces cas la, donc tu as le choix, et tu peux meme voir le diff entre les deux avant de prendre ta decision. Evidemment, si tu reponds yes sans regarder ce qu'on te demande, ne viens pas te plaindre.

                      Peut-on les controlers par rapport à la signature ? Comment sont détecter les dépendances à la création du paquet ?


                      RTFM : http://www.debian.org/doc/manuals/apt-howto/

                      Yum c'est du python et apt du C. Tu t'attendais à quoi ?


                      Faux argument d'une part (comme dit auparavant), python peut être plus ou moins rapide que C. Et erreur dans l'argument parce qu'APT est en C++.

                      Yum a un système de plugin. Et apt ?


                      Tu peux m'expliquer en quoi avoir un systeme de plug-in rend un outil meilleur ? C'est un argument de commercial ca : "y'a des pug-in donc saibien !". Apt est un outil en ligne de commande facon Unix a l'ancienne, il fait une seule chose (enfin presque) et il la fait bien. Et tu as une foultitude de petits utilitaires a cote pour faire autre chose.

                      Les dépôts Yum sont des fichiers au format xml. Et apt ?


                      Un bon vieux fichier texte compressé. Et même depuis peu de temps, on ne télécharge que des diff, ce qui fait qu'on a quelques kilo-octets par jour plutôt que quelques centaines de kilo-octets. Bon, ca ne fait pas l'unanimité encore, surtout pour ceux qui ne mettent pas a jour souvent. Mais je ne doute pas que ca va s'ameliorer.

                      Peut-on faire des requêtes sur les dépôts apt comme on peut le faire avec repoquery


                      apt-query ? apt-cache ? apt-file ? p.d.o ?


                      En conclusion, je dirais qu'on s'en fout de savoir qui a la plus grosse. Apt marche très bien et a fait une partie du succès de Debian, c'est tout. Rpm avait beaucoup de defauts a l'epoque ou dpkg a ete cree (notamment le fait de ne pas pouvoir creer de meta-package). Depuis, rpm court derriere dpkg. Apt utilisant un systeme de package plus performant n'a fait qu'exploiter ce potentiel.
                      • [^] # Re: reverser dans debian ?

                        Posté par . Évalué à 3.

                        notamment avec un xorg.conf modifié et jamais écrasé.

                        Il a dit "modifié par prelink", pas "modifié par l'utilisateur".

                        Bon sinon, à part ça, il me semble bien qu'apt a un système de plugins. En tout cas, pour moi, des trucs comme apt-listchanges et apt-listbugs, ce sont des plugins.
                      • [^] # Re: reverser dans debian ?

                        Posté par . Évalué à 1.

                        > Ca existe depuis au moins un an donc si "quelques" vaut au moins 52 dans ton esprit, ok.

                        Tout le monde peut se tromper.

                        > Je n'ai jamais eu aucun probleme, notamment avec un xorg.conf modifié et jamais écrasé. Dpkg demande a l'utilisateur ce qu'il faut faire dans ces cas la, donc tu as le choix,

                        On ne parle pas de la même chose.

                        > Faux argument d'une part (comme dit auparavant), python peut être plus ou moins rapide que C.

                        Et les futurs OS seront écrit en Java. Ok, ok, ok...

                        > Tu peux m'expliquer en quoi avoir un systeme de plug-in rend un outil meilleur ?

                        S'il n'y a pas de plugin, en rien.

                        > Depuis, rpm court derriere dpkg.

                        Dpkg a les paquets "recommandés" et/ou "suggeré" et c'est tout de mieux que rpm.
                        Au-lieu d'affimer gratuitement que dpkg est mieux que rpm, dites ce que dpkg a de mieu.

                        > Apt utilisant un systeme de package plus performant n'a fait qu'exploiter ce potentiel.

                        Marche aussi avec rpm.
                        Dis ce que apt pour dpkg a de mieu que apt pour rpm.
                        • [^] # Commentaire supprimé

                          Posté par . Évalué à 3.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: reverser dans debian ?

                            Posté par . Évalué à 3.

                            Rpm n'est pas un système pour installer tout et n'importe quoi.
                            Ce n'est pas parce que le fichier ce termine par .rpm, qu'il s'installe sur un système utilisant rpm.
                            Sûr de chez sûr qu'il y a des paquets Ubuntu qui ne s'installent pas sur Debian et vice versa.

                            > j'ai pas la lib truc_bidule.so.6.12.0.

                            Et ?
                            Si le programme a besoin de libtruc_bidule.so.6.12.0, qu'il n'est pas sur la bécane ou sur un dépôt, que l'installation de libtruc_bidule.so.6.12.0 fait downgrader des librairies ou programmes, rpm a raison de ne pas installer le programme. C'est son job !

                            Ici tu montres seulement que rpm fait son boulot.

                            > Je n'ai JAMAIS eu ce genre de probleme avec dpkg

                            Ben utilises Fedora avec les dépôts Fedora Core, Fedora Extras et livna. Tu n'aura jamais ce genre de problème.

                            Tu ne parles pas d'un problème de rpm, mais de compatibilité de dépôt. Problème qui existe aussi bien pour les systèmes à base de dpkg que rpm.
                • [^] # Re: reverser dans debian ?

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

                  > > Ubuntu a été créée pour booster Debian
                  >
                  > Sûrement pas.

                  C'est ce que je pense aussi.

                  Mais visiblement, tu n'as pas vu les talks de Mark Shuttleworth, d'où ton incompréhension du mécontentement de beaucoup face à Ubuntu.
                  • [^] # Re: reverser dans debian ?

                    Posté par . Évalué à 2.

                    > Mais visiblement, tu n'as pas vu les talks de Mark Shuttleworth, d'où ton incompréhension du mécontentement de beaucoup face à Ubuntu.

                    J'ai bien compris ton commentaire et ton "ressentiment". J'ai fait peu cas des "bruits".
                    Les promesses n'engagent que ceux qui les écoutent :-)
        • [^] # Re: reverser dans debian ?

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

          > Oserais je dire que ton commentaire c'est du FUD ?

          Si ça t'amuse, tu peux le dire.

          Mais tu peux aussi être plus intelligent que ça et relire mon commentaire et celui auquel je répond. Vu que tu es parti pour troller et que pour un bon troll, il ne faut pas lire les messages auxquels on répond, je vais te le refaire ici : Le commentaire demandait si il y avait déjà eu du code de Canonical intégré dans Debian. Je répondais que oui, avec un argument étayant mon propos.

          Mais toi, tu as vu un post avec le mot "ubuntu" dedans, et sans lire plus loin, tu en as déduit que j'étais en train de démontrer que Canonical était une boite de sauveurs de l'humanité (il se trouve justement que ça n'est pas franchement le cas, j'ai déjà détaillé mes mesaventures avec Canonical ici).

          Sinon, pas très scientifique ta méthode. On s'en fout de savoir combien de paquets ont reçu des contributions. Ce qui compte, c'est la masse totale de travail apportée, compter des dizaines de contributions sur un paquet majeur au même titre qu'un patch d'une ligne dans un paquet pas important, je trouve pas ça très pertinent. Déjà, Ubuntu, c'est 1 CD, les paquets extérieurs étant « universe » qui _est_ justement Debian. Donc, il y a un peu moins de 10% du code de Debian auquel Canonical est potentiellement amené à contribuer (je ne sais pas en nombre de paquets). Ensuite, considérer qu'il n'y a eu contribution que si le mot "patch" apparait dans la même ligne que le mot ubuntu dans le changelog, hmmm, comme qui dirait, c'est toi qui parlais de FUD ?

          $ zgrep -i ubuntu xorg/changelog.gz | wc -l
          31

          Mais en suivant ta méthode,

          $ zgrep -i ubuntu xorg/changelog.gz | grep patch
          $

          Damned, que de bons arguments tu as. Je suis zimpressionné.
          • [^] # Re: reverser dans debian ?

            Posté par . Évalué à 4.

            J'ai du mal à te suivre, j'ai l'impression que tu mélanges Canonical et la Fondation ubuntu.
            Déjà, Ubuntu, c'est 1 CD, les paquets extérieurs étant « universe » qui _est_ justement Debian. Donc, il y a un peu moins de 10% du code de Debian auquel Canonical est potentiellement amené à contribuer

            Le Universe provient sans doute majoritairement de Debian c'est sûr, mais il y a des gens appelés Master Of The Universe qui packagent des paquets qui n'existent pas dans Debian. Et d'autres de la communauté qui développent des logiciels. On ne peut pas dire que l'Universe n'est le résultat que de Debian non plus.
            Ensuite si Debian est intéressé par du travail fait dans Ubuntu, je ne vois pas ce qu'il l'empêche de se servir. Si il n'y a pas de patch Ubuntu dans Debian, peut être est-ce tout simplement que Debian n'en veut pas.
          • [^] # Re: reverser dans debian ?

            Posté par . Évalué à 5.

            Dites, j'ai le droit de faire une remarque stupide ? Depuis le debut de ce thread, pour savoir si Debian a repris des choses d'Ubuntu, vous verifiez */changelog.gz : Moi je veux bien, hein, mais ca c'est le changelog upstream. Si vous voulez le boulot specifique au packaging, il vaut mieux verifier le changelog.Debian.gz je pense... Apres, la liste contient un *grand* nombre d'entrees qui sont des packages maintenus par un employe canonical, donc adresse en @ubuntu.com ou messages du genre "sync with ubuntu".
        • [^] # Re: reverser dans debian ?

          Posté par . Évalué à 6.

          Je peux jouer à compter aussi ??

          Disclaimer : il se peut qu'il se soit glisser des pointes d'"humour pas drole dans ce message"...

          problème : je suis nul en bash et en plus j'ai chaque fois zero réponse quand je colle les lignes données au dessus et ca me renvoie "gzip: */changelog.gz: No such file or directory"

          c'est pas grave, je vais faire ce que je sais faire, c'est à dire, surfer, lire le web et tout et tout...

          alors une page (totalement au hasard) du "Debian Package Tracking System" http://packages.qa.debian.org/a/amarok.html
          là dedans une petite ligne Patch from ubuntu for version 2:1.4.2-0ubuntu2 qui renvoie vers cette adresse : http://patches.ubuntu.com/a/amarok/amarok_2:1.4.2-0ubuntu2.p(...)

          remontons, remontons, on finit par arriver sur http://patches.ubuntu.com alias Ubuntu's Debian patches repository.
          petit texte que je vous laisse découvrir par vous même qui explique comment ca marche et comment sont nommés les patchs afin que les merges soient facilités (c'est eux qui disent ca comme ca)
          et le fichier qui compte tout seul le nombre de pachs : http://patches.ubuntu.com/PATCHES
          un copier coller dans un vrai éditeur plus tard j'obtient 1794 patchs...

          Ils sont donc bien disponibles, et pas par paquet de 2 ou 3 ... Les gens de Debian n'ont pas été tenu à l'écart puisque tous les patchs sont visibles sur le package tracking systems...
          Maintenant, n'ayant pas les capacités de juger, je fais confiance aux mainteneurs de chez debian pour savoir si je les retrouve un jour sur ma machine :)

Suivre le flux des commentaires

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