Debian envisage un support partiel des architectures les moins utilisées

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
15
mar.
2005
Debian
Lors d'une réunion des responsables de publication ("Release Managers") de Debian à propos de Sarge, la version en test, il a été aussi question du plan de sortie pour la Debian suivante : Etch.
Apparemment, l'équipe de publication et les administrateurs des serveurs FTP sont tombés d'accord sur le fait qu'il n'est plus possible de continuer à coordonner les sorties pour autant d'architectures.
À partir de Etch donc, certaines architectures ne seront disponibles qu'en unstable, dont il sera pris des "instantanés" (snapshots) régulièrement. C'est donc un changement majeur pour Debian, qui fixe des règles strictes pour qu'une architecture soit supportée à 100 % :

- Elle doit remplir les critères pour les nouvelles architectures (voir ci-dessous)

- On doit pouvoir encore acheter du matériel de cette architecture,

- Il doit y avoir n+1 systèmes de compilation, avec n le nombre nécessaire pour tenir la charge dûe au volume de paquets uploadés

- Cette valeur de n n'a pas nécessairement besoin d'être strictement supérieure à 2

- Cette architecture doit avoir compilé avec succès 98% des sources Debian (sans les paquets spécifiques à une architecture)

- L'architecture doit avoir un installeur qui fonctionne

- L'Équipe Sécurité doit être d'accord pour fournir un support à long terme de cette architecture,

- Les Administrateurs Système Debian doivent être d'accord pour supporter des machines de cette architecture,

- L'Équipe de Publication (Release Team) a droit de véto sur l'ajout d'une architecture si elle pense qu'elle peut trop retarder une sortie

- Il doit y avoir une machine de cette architecture accessible aux développeurs Debian.

Les règles suivantes seront appliquées pour déterminer si une nouvelle architecture sera inclue dans Debian :
- Il doit y avoir une base d'utilisateurs suffisante pour justifier l'ajout sur tous les miroirs, critère défini par au moins 10% des téléchargement sur un échantillon des miroirs,

- L'architecture doit être librement utilisable (sans accord de non-divulgation (NDA)),

- L'architecture doit pouvoir faire tourner le système de compilation 24h sur 24 et 7 jours sur 7 (sans planter),

- L'architecture doit avoir un système de compilation qui fonctionne,

- Le port doit avoir au moins les fonctionnalités de base d'UNIX, par exemple la résolution de nom et le filtrage de paquets (firewalling),

- Les paquets binaires doivent pouvoir être construits depuis des sources Debian non modifiées (nécessaire pour des raisons de licences entre autres),

- Les binaires de ces architectures doivent avoir été signés par des développeurs Debian officiels,

- L'architecture doit pouvoir compiler au moins 50% des sources Debian (sans les paquets spécifiques à certaines architectures)

- Au moins 5 développeurs à travailler sur le port, doivent envoyer des demandes signées d'addition

- Il faut prouver qu'il y aura au moins 50 utilisateurs.


Avec ces critères les architectures qui resteront supportées à 100% après la sortie de Sarge seront i386, powerpc, ia64 et amd64 (4/11)

Cette annonce a été approuvée par : Steve Langasek (Release Manager), Colin Watson (Release Manager), Andreas Barth (Release Assistant), Joey Hess (Release Assistant), Frank Lichtenheld (Release Assistant), James Troup (ftpmaster), Ryan Murray (ftpmaster), Anthony Towns (ftpmaster), Andreas Schuldei (candidat DPL), Angus Lees (candidat DPL), Branden Robinson (candidat DPL), Jonathan Walther (candidat DPL).

Des personnes on déjà fait part de leur accord ou leur désaccord avec cette annonce sur leurs blogs : Andrew Pollock est pour, mais Steve Kemp, Norbert Tretkowski et Wouter Verhelst sont contre.

Il faut noter que cette proposition doit encore être soumise à un vote pour devenir officielle.

Aller plus loin

  • # Très Bien

    Posté par  . Évalué à 10.

    C'est une excellente décision, j'adore les machines exotiques, mais pénaliser de manière importane des dizaines de millions d'utilisateurs pour une amélioration finalement peu évidente pour quelques dizaines....ça ne pouvait pas continuer comme ça.

    • [^] # Re: Très Bien

      Posté par  . Évalué à 3.

      À mon avis ça ne passera pas le vote.

      • [^] # Re: Très Bien

        Posté par  . Évalué à 10.

        Hmm... faut voir. Perso, si j'étais à l'heure actuelle développeur Debian, je voterai pour.

        Est il logique de retarder une sortie stable d'une excellent distribution ad vitam eternam pour les quelques plateformes exotiques ?

        Qui a vraiment envie de faire tourner du Debian sur un AS400 ? Ceux qui ont un parc de machine déjà constitué. Qui ira acheter de l'AS400 spécifiquement pour faire tourner du Debian là où une architecture à base de i386, amd64 ou ia64 sera beaucoup plus compétitive.

        Cibler les 4 architectures principales avec les mêmes critères de qualité, et de liberté, en gardant l'esprit 100% non commercial (pas comme Mandrake qui ne propose pas d'iso pour la version amd64 sans être membre du club quoi) de Debian serait un excellent choix.

        Il faut savoir évoluer, se remettre en question... Même si Debian n'a aucune dead-line imposée par des intérêts commerciaux, il est quand même utile qu'elle tienne la dragée aux autres distros en terme de sortie de releases stables.

        • [^] # Re: Très Bien

          Posté par  . Évalué à 8.

          Ouais j'suis assez d'accord, s'occuper des architectures "phares" ou "populaires" afin de sortir des release plus vite, tout en s'occupant des autres mais dans une autre vitesse, tout doit se décider en fonction du nombre d'utilisateurs et/ou des fréquences de téléchargements de paquets.

          Pour les architecures exotiques, il reste SID qui couplé avec apt-listbugs permet quand même de garder une machine à peu près utilisable.

          Je serais ravi de voir etch sortir rapidement grâce à cette nouvelle politique tout en gardant les qualités de debian qu'on lui connait :-)

          dabowl_75

    • [^] # Re: Très Bien

      Posté par  . Évalué à -10.

      > mais pénaliser de manière importane des dizaines de millions d'utilisateurs

      Parce qu'il y a autant d'utilisateur de Debian ? de surcroit voulant utiliser une "stable" toujours en retard de plusieurs métros ?

      Bougez pas, je ->[]

      • [^] # Re: Très Bien

        Posté par  . Évalué à 9.

        Pourquoi crois tu qu'elle est si en retard ?

        Car les paquets de unstable ne passe en testing que quand çà compile avec succès sur toutes les plateformes, qu'il n'y a pas de bug grave et qu'il y a moins ou autant de bug que le paquet actuel dans testing.

        Tu multiplies çà avec les interdépendances par paquet et tu comprends pourquoi celà peux prendre du temps.

        C'est aussi grâce / à cause de ce process qualité que la stable sort tardivement, mais là tu peux être sûr qu'elle est très très stable.

  • # Youpi

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

    C'est l'assurance d'avoir Xorg 6.7.0 avant 10 ans ;)
    Dommage, je suis passé à Ubuntu...

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

    • [^] # Re: Youpi

      Posté par  . Évalué à 0.

      ...Mais Ubuntu elle reste sur Debian

      • [^] # Re: Youpi

        Posté par  . Évalué à -5.

        T'es sûr ?
        Mandrake était sur RedHat, et maintenant ?

        • [^] # Re: Youpi

          Posté par  . Évalué à 3.

          Ubuntu reste basé sur debian.
          Après chaque sortie de version stable (de ubuntu), ils sync avec debiand sid.

          • [^] # Re: Youpi

            Posté par  . Évalué à -5.

            Ubuntu est un joli concept, en effet les paquets sont récents etc..

            MAIS, j'ai un collègue qui l'a installé recemment et il me la fait tester, et bien avec une commande j'ai réussi à la planter --->reboot hardware obligatoire

            bon ok, la commande c'était "glxgears" et bien sûr X.org est encore un peu jeune pour exploiter correctement le DRI, bien que X.org soit un fork de XFree 4.4 (si je dis pas de bêtise), et que XFree 4.4 exploite très bien le DRI (je l'utilise actuellement), bon encore ok ubuntu est une version bêta.

            Bref, à part avoir des paquets plus récents et un super système d'installation, je vois pas ce qu'elle a en plus (à vous de me le dire), de plus je ne pense pas que ubuntu puisse prendre de l'avance sur debian sur la stabilité des paquets, sur les versions je veux bien (encore que en SID ça va), l'une dépend de l'autre mais l'autre ne dépend pas de l'une --> pas de commutativité ici :-)

            bref, je troll pas sur ubuntu parce que c'est un initiative qui mérite le respect, en plus le logo est pas mal, il fait plus moderne que celui de debian

            enfin en tout cas, j'suis bien avec ma SID et elle est super stable, faut juste faire gaffe aux upgrade qui casse tout parfois et surtout aux bug --> apt-listbugs est NOTRE amis !

            debianement vôtre

            dabowl_75

            • [^] # Re: Youpi

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

              Xorg est un fork de XFree86 4.3.99.1[1-9] (la derniere version avant le changement de licence). Le XFree86 dans debian est un 4.3.0 (bien) patché de tout les cotés.

              Pour ton histoire de glxgear, c'est pas vraiment facile... Car ca dépend de l'agp, du dri, de la carte, de l'acpi, et d'X. Tu peux dire que debian marche mieu que Ubuntu dans ce cas si tu fais le teste avec exactement le même hardware. Perso, j'utilise le Xorg d'ubuntu sur mon portable, et ca marche tres bien.

              Sinon, ubuntu a gnome et X en plus récent que debian en gros. Le travail de ubuntu est normalement passé à debian directement par les developpeurs ubuntu (qui sont souvent aussi developpeur Debian ou Gnome en fait).

              Pour les avantages, je les connais pas vraiment, mais il parrait que pmount viens d'ubuntu, et, combiné avec gnome-volume-manager, ca marche vachement bien.

              Sinon, perso, j'utilise testing avec les applis que j'ai besoin de vraiment récent en unstable (rien en ce moment il me semble) et comme ca, j'ai des applis récente sans me prendre la tete avec apt-listbugs ;-)

            • [^] # Re: Youpi

              Posté par  . Évalué à 6.

              Ce que tu dis est relativement absurde, la version stable de la Ubuntu est sous Xfree et glxgears marche très bien merci pour lui, donc dire que tu fais planter une version de développement ça apporte quoi?

            • [^] # Re: Youpi

              Posté par  . Évalué à 5.

              Et bien la différence principale pour moi est d'avoir pu l'installer :D en ayant tout mon matériel reconnu dès l'install (wifi and co).
              Pour un nouveau sous Linux c'est déjà pas mal.

              J'apprécie la simplicité de l'installation due en grande partie à l'absence de choix. Avoir le choix entre plusieurs logiciels est une bonne chose si on sait ce que l'on veut, maintenant quand on y connait rien soit on y va au hasard, soit on installe tout... je préfère un choix cohérent que je peux modifier après à grands coups d'apt-get / synaptic.

              Ce qui me plait avec ubuntu c'est qu'elle est proche d'une Fedora ou d'une Mandrake pour son coté utilisable à l'issu d'une phase courte d'installation réalisable par monsieur tout le monde tout en ouvrant les portes d'une debian. Evidemment il manque une installation à clics et autres écrans d'accueil graphiques pour faire grand publique (mais je m'en fous ;) ).

              Ubuntu n'aurait pas le même intérêt à mes yeux s'il n'y avait pas debian derrière, je préfère rendre à César ce qui lui appartient. Ubuntu n'est qu'une mise en forme de Debian avec quelques avantages dus aux paquets récents.

              Un dernier avantage qui n'existera plus d'ici peu : quand on cherche un tuto pour ubuntu, on est sur qu'il n'a pas 15 versions de logiciel de retard :D

            • [^] # Re: Youpi

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

              1/ Faire planter une version unstable, comme déjà dit, ne devrait pas influer ton jugement sur une distrib.
              2/ à part avoir des paquets plus récents et un super système d'installation, je vois pas ce qu'elle a en plus : des paquets plus récents et un super système d'install ;)
              3/ l'une dépend de l'autre mais l'autre ne dépend pas de l'une : FAUX pour plusieurs raisons ->
              1 - http://www.ubuntulinux.org/ubuntu/relationship/document_view(...)

              2 - Et c'est là que j'aimerais insister. Il semble que beaucoup de personnes ne comprennent pas l'intérêt même du libre. De n'importe quelle manière, un projet influe sur les autres par le fait même d'être libre. Exemple : bien qu'elle ne soit pas passée à apt, la distrib Mandrake utilise maintenant un système de gestion de paquets qui ressemble quand même beaucoup à apt, qui est un des points forts de Debian. D'un autre côté, les installeurs évolués de Debian qui, heureusement, ont bien évolué depuis la Potato, par exemple, ont été boostés par d'autres distribs (Progeny ?).
              Il n'y a pas de conccurrence (au sens où on l'entend en général) entre les projets libres par le fait qu'ils sont libres.
              C'est d'autant plus vrai dans le cas de distribs comme Ubuntu et Debian.

              Donc, traiter de "voleurs" les développeurs Ubuntu c'est :
              1/ faux,
              2/ ignorer complètement l'intérêt du libre

              "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

              • [^] # Re: Youpi

                Posté par  . Évalué à 2.


                1/ Faire planter une version unstable, comme déjà dit, ne devrait pas influer ton jugement sur une distrib.


                Si on joue sur les mots, non.
                Unstable = Instable, forcément faut pas s'attendre à des miracles
                Sauf qu'içi dans le monde de Debian, on s'permet de juger un paquet tiers "d'instable" car celui-ci n'a pas encore été utilisé/validé.

                Xorg a été validé par un nombre non négligeable d'utilisateur/Distro, alors que doit-il encore prouver à Debian? Ceci étant, ça ne me dérange pas qu'ils prennent des lustres à incorporer un paquet.

                Comme je l'ai déjà dit, ils doivent surtour revoir le nom de leur Branches.

                Non-testé, Non-Certifié <-- voyez une équivoque?

          • [^] # Re: Youpi

            Posté par  . Évalué à -10.

            Je me fais moinsser chaque fois je dis du mal de ubuntu.
            S'ils sync avec debian sid, qu'apportent-ils de plus à part quelques petites mise en formes ?
            Regarde leur site web page d'accueil, il n'y a même pas un mot "debian", des voleurs.

            • [^] # Re: Youpi

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

              Les "voleurs" comme tu dis ont probablement plus contribué a gnome et debian ces derniers mois que tu ne le feras dans toute ta vie...

            • [^] # Re: Youpi

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

              <i>il n'y a même pas un mot "debian", des voleurs</i>

              Je ne connais pas le nombre de développeurs ubuntu et leur organisation interne mais un certain nombre d'entre eux sont/étaient des développeurs debian ... Il suffit juste de suivre les 2 proets en parallèle pour comprendre qu'ubuntu n'a en soi-même rien 'volé' à debian!

              <i>qu'apportent-ils de plus à part quelques petites mise en formes ?</i>

              Regarde, par exemple, l'évolution du tou de sécurité trouvé sur mailman il n'y a pas très longtemps sur les listes debian-security-announce et ubuntu-security-announce, il y en a surement d'autres aussi, je te laisse chercher :)

  • # Nuance !

    Posté par  . Évalué à 2.

    Quelques développeurs Debian proposent que le projet supporte moins d'architectures.

    • [^] # Re: Nuance !

      Posté par  . Évalué à 10.

      Parmi eux, 5 des 6 candidats DPL, donc probablement le futur DPL (bon d'accord, c'est un titre honorifique), les release managers, ftpmasters... De quoi soutenir la proposition.
      L'actuel DPL avait quelques objections.

      • [^] # Re: Nuance !

        Posté par  . Évalué à 2.

        Pas seulement honorifique. P.ex., il peut engager quelque menue monnaie (pour des confs. p.ex.).

  • # Cela me rapelle en attendant Godot .... Woody !!

    Posté par  . Évalué à 5.

    Je ne veut pas etre mechant , mais cette decision est une tentative qui va surement rate de rapprocher la sortie de Debian Stable.

    Sauf erreur la sortie de woody fut retardee et retardee et encore retardee. Les responsables de l'epoque avait promit qie pour Sarge cela ne se produirait plus. Et que voyons-nous... Pour Sarge c'est encore pire.....

    • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

      Posté par  . Évalué à 7.

      > mais cette decision est une tentative qui va surement rate de rapprocher la sortie de Debian Stable.

      Ca n'entrera en application que pour etch. Sarge n'est pas concernée.

      • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

        Posté par  . Évalué à 4.

        Quand Woody se faisait attendre, des responsables de l'epoque avait propose des solutions pour que Sarge ne sorte pas avec un immense retard. Des propositions des idees pour la prochaine stable (cad pour Sarge que nous attendons actuellement) etaient legions. Aucune ne fut appliquées et nous voyons le resultat .......

        Maitenent pour "accelerer" la sortie de etch (la prochaine prochaine stable) certains font des propositions.....

        • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

          Posté par  . Évalué à 10.

          Maitenent pour "accelerer" la sortie de etch (la prochaine prochaine stable) certains font des propositions.....

          Ils ont plutôt intéret.

          Durée (en mois) entre deux distributions Debian :
          hamm -> slink : 7.5
          slink -> potato : 17
          potato -> woody : 23
          woody -> sarge : 32+

          • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

            Posté par  . Évalué à 9.

            Il faut quand même replacer les choses dans leur contexte, à l'époque de hamm (juillet 98) il y avait beaucoup moins de projets qu'aujourd'hui donc beaucoup moins d'applications au sein de la distrib, ce qui permettait de pouvoir sortir des versions stables plus vite même s'il y avait beaucoup d'architectures.

            Ce n'est donc pas étonnant que les durées d'attente de versions stables soient de plus en plus longues, il faut donc que debian change un peu sa politique ça me parait obligatoire.

            Sinon qu'est-ce qui va se passer ?

            Les gens diront, "ouais mais debian ils sont en retard par rapport à machin"

            Et nous linuxiens nous répondront, "Pfff, tu parles en sid il y a tout ce qu'il faut pour peu que tu maîtrises ton système espèce de newbie"

            Et la finalité sera que debian restera cantonnée aux passionés comme nous, et nous serons frustrés de voir qu'en entreprise il y a du chapeau rouge et que pour se faire embaucher il faut maîtriser chapeau rouge, bon j'extrapole un peu mais en gros c'est ça.

            dabowl_75

            • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

              Posté par  . Évalué à 3.

              Il faut quand même replacer les choses dans leur contexte, à l'époque de hamm (juillet 98) il y avait beaucoup moins de projets qu'aujourd'hui donc beaucoup moins d'applications au sein de la distrib, ce qui permettait de pouvoir sortir des versions stables plus vite même s'il y avait beaucoup d'architectures.

              Certes mais il y'a beaucoup plus de développeurs Debian aujourd'hui qu'en 98. Le logiciel libre en général a gagné en popularité depuis.
              Logiquement, Debian devrait pouvoir monter en charge pour accompagner la croissance du nombre de logiciels.

              il faut donc que debian change un peu sa politique ça me parait obligatoire.

              A noter que sur les 6 candidats au rôle de Project Leader chez Debian, 5 sont en faveur d'un intervalle de temps régulier.
              Ils ne sont pas tous d'accord sur l'intervalle en question (ca va de 6 mois à 2 ans et demi) mais c'est déjà un début.

            • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

              Posté par  . Évalué à 7.


              Les gens diront, "ouais mais debian ils sont en retard par rapport à machin"

              Et nous linuxiens nous répondront, "Pfff, tu parles en sid il y a tout ce qu'il faut pour peu que tu maîtrises ton système espèce de newbie"

              Et la finalité sera que debian restera cantonnée aux passionés comme nous, et nous serons frustrés de voir qu'en entreprise il y a du chapeau rouge et que pour se faire embaucher il faut maîtriser chapeau rouge, bon j'extrapole un peu mais en gros c'est ça.

              Y pas besoin de parler au futur , c'est malheuresement déjà le cas :/

              • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

                Posté par  . Évalué à 1.

                Non seulement c'est le cas effectivement, mais plus ça va plus le fossé se creuse.

                On peut en revanche se rassurer sur un point, debian-user-french est très active et les réponses données sont de bonne facture. Depuis que j'y suis inscrit je n'ai fait que progresser et pas seulement sur les aspects techniques mais aussi sur la façon d'aborder le système, rechercher l'information au bon endroit, être bien précis dans ces demandes, etc...

                Là où je bosse, il y a des admins chapeau rouge (non débiannistes) et bah rien que là on constate clairement leur façon de bosser qui diffère complètement, j'ai même l'impression qu'ils utilisent linux comme un produit propriétaire (j'en ai honte pour eux mais je leur jette pas la pierre), bon je ne suis pas irréprochable non plus car j'administre aussi quelques machines qui tournent avec un unix proprio et des fois le support m'est d'un grand secours :/

                hacmp c de la ...

                dabowl_75

                • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

                  Posté par  . Évalué à 2.

                  Il y a 3 mois, j’ai eu a choisir une distribution pour faire tourner asterisk (Logiciel de Central téléphonique sous linux). Ceci se déroulait dans le cadre des recherches de pré industrialisation de switch industriel de mon employeur.

                  Des collègues utilisant asterisk me recommandèrent d’utiliser Fedora Core 2. Sur cette distribution se laisse compiler asterisk sans problème.

                  Comme cette distribution devait tourner sous VirtualPC, je préférait une distribution légère et debian en tant que serveur a priori pas mal. Après une recherche sur leur site je pouvais en plus constater que le logiciel asterisk existait sous forme de paquet dans sa dernière version pour testing (Sarge). A l’époque on parlait de la sortie imminente de Sarge. A la fin du projet (en Avril) je pouvais espérer que Sarge serait stable…..
                  Maintenant je suis bien obliger de constater que je me suis lourdement tromper. Sarge n’est pas près d’être stable et pour une utilisation professionnelle donc à éviter.
                  Mon chef m’a d’ailleurs fait savoir qu’il va falloir supprimer ce bêta de ma machine…

                  • [^] # Re: Cela me rapelle en attendant Godot .... Woody !!

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

                    Pff n'importe quoi, certe elle n'est pas certifiée stable...

                    Mais je peut te garantir que je l'utilise en prod sur des serveurs webs et j'ai pas de soucis (mise a part une mise a jours foireuse a cause d'un changement de script de démarage et de variable non protégées pour courrier-imap et courrier-imap-ssl)

                    Parfois faut savoir forcer la main...

  • # utilisateurs debian ?

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

    + de 10% des téléchargements et plus de 50 utilisateurs. Alors de deux choses l'une, soit 50 utilisateurs arrivent à générer 10% du traffic sur les mirroirs de Debian à eux seuls (et alors on ferait mieux de les bannir plutot que de supporter leur architecture), soit ils estiment le nombre d'utilisateurs de Debian à grosso modo 500 personnes.

    Comme je suis certain que ce n'est ni l'un ni l'autre, quelqu'un pourrait-il m'expliquer la subtilité ?

    • [^] # Re: utilisateurs debian ?

      Posté par  . Évalué à 7.


      Also, since the original purpose of the SCC proposal was to reduce the size
      of the archive that mirrors had to carry, the list of release candidate
      architectures will be further split, with only the most popular ones
      distributed via ftp.debian.org itself. The criterion for being distributed
      from ftp.debian.org (and its mirrors) is roughly:

      - there must be a sufficient user base to justify inclusion on all
      mirrors, defined as 10% of downloads over a sampled set of mirrors



      la barre des 10% c'est pour pouvoir etre hébergé sur le site principal (ftp.debian.org). C'est juste un point annexe, portant sur l'hébergement des repository, et non sur le maintient de l'architecture dans la branche stable de Debian.

  • # Snapshot

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

    Ils fairaient mieux de gérer deux branches une en snapshot comme Gnome, et une super stable pour les admins parano.

    Par contre c'est une bonne idée, le choses exotiques comme m68k et autre MIPS ne doivent pas ralentir les archis plus populaires (x86, AMD64, IA64, PPC et PPC64)

    • [^] # Re: Snapshot

      Posté par  . Évalué à 3.

      Je ne suis qu'un utilisateur d'architecture i386 et amd64 donc je devrais me réjouir d'une telle nouvelle (en théorie une encore plus grande réactivité pour la version stable...).
      MAis hélas je ne peux que me dire qu'il s'agit d'un raisonnement purement comptable (en temps en énergie). Je comprends bien le pourquoi du comment mais dommage : en effet qu'elle plaisir que de voir une distribution couvrir une grande majorité de plates-formes...
      Et même si cela sert à peut de gens, l'idéologie qui pouvait y être associée était (est pour l'instant encore) intéressante : l'harmonie dans une entreprise permet sous certaines réserves un gain de productivité intéressant.

      Enfin merci pour le travail incroyable de toute l'équipe de Debian.

      • [^] # Re: Snapshot

        Posté par  . Évalué à 10.

        en effet qu'elle plaisir que de voir une distribution couvrir une grande majorité de plates-formes

        c'est peut être joli mais c'est intenable. C'est bien de supporter de nombreuses architectures mais quand il y a des bugs bloquants qui empêchent de sortir une distro et personne pour les corriger parmi les 3 pelés qui s'intéressent à l'architecture XYZ c'est nettement moins drole.

        Il y a beaucoup de bonnes intentions mais qui sont rarement suivies d'actes. On a le même problème pour la gestion des paquets. On va passer énormement de gens enthousiastes qui proposent d'empaqueter des logiciels mais qui se lassent très vite et abandonnent leur paquets au bout de deux mois. C'est pour celà que Debian demande à ce qu'il y ait plusieurs responsables de façon à maximiser les chances de voir un paquets survivre.

        Et même si cela sert à peut de gens, l'idéologie qui pouvait y être associée était (est pour l'instant encore) intéressante

        Ca sert à peu de gens mais surtout il n'y pas grand monde pour maintenir. Supporter une architecture qui ne sert qu'à 10 péquins n'est pas gênant si ces 10 personnes sont tous mainteneurs et très réactifs. Mais si on a quelques utilisateurs et pas de mainteneurs on est mal. L'idéologie pourquoi pas mais quand ça met en péril tout le projet on la range dans le tiroir.

      • [^] # Re: Snapshot

        Posté par  . Évalué à 1.

        Oui m'enfin çà rejoint ce que j'avais omis de dire dans un commentaire plus haut.

        Les plateformes i368, ia64 et amd64 étant plus économique de l'AS400, même si une entreprise possède des trucs exotiques, elle peux envisager une revente de son matériel qui de plus est peux être amorti pour investir sur des plateformes meilleur marché et très performante malgrè tout.

        Il peux un peu se concevoir d'adapter son architecture pour faire tourner un OS souhaité. Si je veux tout monter sur MaOS, il est logique que j'achète du Mac, si je veux un Unix libre en la personne de Linux, il peux être logique d'avoir des plateformes populaires.

    • [^] # Re: Snapshot

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

      Ah???
      Si on suis ton raisonnement, on devrait stopper tout port sous Linux de n'importe quel logiciel, et developper uniquement pour Windows.
      Ou du moins toujours sortir la version Windows d'un logiciel avant la sortie Linux : ben oui, Windows c'est 98% de la population, les 2% Linux ne sont pas assez suffisant...

      Donc : tu es bien illogique dans ton raisonnement...

      • [^] # Re: Snapshot

        Posté par  . Évalué à -1.

        C'est simplifier à l'extrême çà.

        Windows ==> pas libre, j'en veux pas
        Linux ==> libre, j'en veux

        Si Windows était entièrement libre (et gratuit pour certains), très stable, çà serait une plateforme séduisante pour nous geeks, hormis que çà n'est pas du Unix quoi...

        Tant que Windows reste un OS propriétaire, cher, peu sécurisé, pas toujours super stable, avec des politiques commerciales visant à empêcher une version desktop d'être utilisé en serveur car bridée au niveau de la couche TCP/IP... il y a de l'avenir pour le développement Linux ;o))

    • [^] # Re: Snapshot

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

      Ils fairaient mieux de gérer deux branches une en snapshot comme Gnome, et une super stable pour les admins parano.

      Ils en gèrent déjà trois...

  • # Pas grave ...

    Posté par  . Évalué à 9.

    Pour les architectures exotiques, il y a NetBSD ...

    • [^] # Re: Pas grave ...

      Posté par  . Évalué à 2.

      Ou LFS / Gentoo ?

      • [^] # Re: Pas grave ...

        Posté par  . Évalué à 5.

        Le support de Gentoo sur des architectures exotiques, c'est pas encore ca (quoi que 13 ca commence à faire pas mal)...
        Surtout qu'en général il s'agit de machines de faible puissance. Donc il va falloir sortir le cross-compiling et ca commence à faire très compliqué ;)

        • [^] # Re: Pas grave ...

          Posté par  . Évalué à 0.

          Cross compiling c'est bien le fait de compiler sur une machine un binaire destiné à une autre ?
          ex : un serveur 486 ou pentium trop poussif pour recompiler son noyau , on lui recompile sur le beau pentium 4 du salon mais avec l'option " attention je te compile pas pour moi , mais pour un 486 " , pour eviter d'attendre 3 plombes ?

          • [^] # Re: Pas grave ...

            Posté par  . Évalué à 3.

            C plus ou - ca, si ce n'est que tu peux compiler un noyau pour sparc64 a partir d'un i386, voirze même compiler ton GNU/Linux-i386 a partir d'un Solaris-Sparc64. Et là c'est pas si simple que ça.

            Plus d'infos ici : http://www.airs.com/ian/configure/configure_5.html(...)
            Un exemple ici: http://www.laria.u-picardie.fr/~cerin/=deust/cross.pdf(...)

          • [^] # Re: Pas grave ...

            Posté par  . Évalué à 9.

            Disons que ce que tu décris là n'est que la partie "simple" de la compilation croisée : tu compiles d'un x86 vers un autre x86, tu te contentes juste de dégager toutes les optimisations qui ne sont pas communes aux deux machines. Dans le cadre de Gentoo, il suffit dans ce cas de modifier son make.conf. Rien de bien méchant.

            Les compilations croisées qui posent problème (et qui méritent véritablement qu'on les qualifie de "croisées") sont celles qui compilent pour une architecture donnée depuis une autre. Par exemple, si tu compiles du code PPC depuis ton Athlon, tu réalises une compilation croisée. Et ça demande bien plus qu'un simple changement de CFLAGS: il faut installer un GCC qui tourne sur Athlon mais qui génère du code PPC, des binutils pour aller avec, modifier ton environnement de compilation pour qu'il utilise ce GCC avec ces binutils, etc.

            (Notons que la compilation croisée peut, au lieu de viser une architecture matérielle différente, se contenter de cibler une plateforme logicielle incompatible. Comme par exemple XMinGW, qui permet de compiler des binaires win32 depuis un ix86 sous Linux.)

            J'ai vu qu'il existait un paquet "crossdev" dans Portage, censé simplifier ce genre d'acrobatie. Il faudrait que je jette un oeil.

            • [^] # Re: Pas grave ...

              Posté par  . Évalué à 5.

              > J'ai vu qu'il existait un paquet "crossdev" dans Portage, censé
              > simplifier ce genre d'acrobatie. Il faudrait que je jette un oeil.

              Oui, ça facilite bien la création d'une toolchain. En gros, ça permet d'automatiser les étapes décrites ici :
              http://dev.gentoo.org/~vapier/CROSS-COMPILE-HOWTO(...)

              Y'a une ML gentoo-embedded@ aussi si ça t'intérresse, où ont lieu la plupart des discussions sur les histoires de cross-compilation.

            • [^] # Re: Pas grave ...

              Posté par  . Évalué à 6.

              Les compilations croisées qui posent problème (et qui méritent véritablement qu'on les qualifie de "croisées") sont celles qui compilent pour une architecture donnée depuis une autre.

              À vrai dire, ces compilations croisées ne posent pas forcément trop de problèmes. En particulier les logiciels basés sur autoconf/automake se cross-compilent comme des lettres à la poste. Idem pour le kernel linux. Ou le système de base de NetBSD et d'OpenBSD.

              Ça se corse quand une phase de la compilation necessite l'execution (sur la plateforme source) de binaires (ABI cible) produits dans une phase précédente de la compilation.

              Par exemple lors du 'make' de python, on compile d'abord un interpreteur minimal qui est ensuite executé pour compiler les extensions binaires. Ça n'est pas possible si l'interpreteur binaire produit n'est pas executable sur la plateforme où l'on compile.

              Même genre de problématiques pour les logiciels utilisant gtk-config, qmake, swig etc.

              Bref il est complétement inenvisageable de cross compiler la debian pour les architectures rares.

              • [^] # Re: Pas grave ...

                Posté par  . Évalué à 1.

                Dans les cas que tu cites il ne serait pas possible de compiler le compilo minimal dans l'architecture de compilation, avec une adaptation de l'automake par exemple dans une cross-conpilation ?

                c'est peux être naïf comme question mais a priori je vois pas d'énorme objections a faire ca.

                • [^] # Re: Pas grave ...

                  Posté par  . Évalué à 3.

                  C'est faisable (et d'ailleur, c'est souvent ce que fait le framework OpenEmbedded dans ce genre de cas). Mais :

                  1- ça exige généralement d'énormes patches sur les Makefiles (pas faciles à maintenir).
                  2- ça peut produire un résultat non fonctionnel: ces outils qui s'éxecutent en cours de route servent notamment à invoquer les bonnes options (CFLAGS/CXXFLAGS adéquats, paths, -L../-l../-I.. etc.) pour le reste de la compil. Et il n'est pas rare que ces options diffèrent entre l'hôte et la cible :(
                  3- ça peut rendre la compilation difficile à automatiser.
                  4- il est parfois difficile d'avoir sur l'hote source une config logicielle équivalente à celle de la cible. Surtout si la cible est un appareil embarqué, avec, typiquement, utilisation d'un framebuffer spécial, ou de nanox (vs outils linkés sur X windows sur l'hote), ou toute autre différence matérielle ; ce qui agrave les problèmes listés en "2-" (c'est du vécu ;).

  • # C'est pas traumatisant

    Posté par  . Évalué à 10.

    Personnellement, j'utilise debian sur une SparcStation. Je pense que la majorité des gens qui utilisent debian sur ce genre de machines, ils l'utilisent en testing ou instable. C'est rarement utilisé comme serveur critique (enfin, je pense).

    Pour ce qui ont à la fois une architecture exotique ET un serveur critique dessus, il va falloir se rabattre sur les BSD. Mais je pense que debian y perdra beaucoup moins qu'en sortant des ultra-stables plus régulièrement.

    Bref je suis pour!

  • # Oui mais non ...

    Posté par  . Évalué à 2.

    Euh ... je suis d'accord sur le principe, mais bon moi j'utilise Debian sur Sparc. Donc si cette architecture est plus supporté sa m'arrange pas trops :(

    Pajou

    • [^] # Re: Oui mais non ...

      Posté par  . Évalué à 5.

      relis le sujet de la dépêche,

      "Debian envisage un support partiel des architectures les moins utilisées"
      ^^^^

      Pourquoi ne pas regrouper les architectures les plus exotiques ?

      Du style on aurait Debian GNU/Linux d'un côté et Debian-exotic GNU/Linux de l'autre ?

      Bon ok --> [*] génial il fait beau, je vais en profiter !

      dabowl_75

      • [^] # Re: Oui mais non ...

        Posté par  . Évalué à -3.

        Excellente idée ! Et on n'a qu'à l'appeler Debian-Kiwi GNU/Linux. Et pourquoi ne pas créer la société Debian Banana pour la soutenir, et installer son siège social à Bruxelles, au coeur de la Banana Republic ?

        • [^] # Re: Oui mais non ...

          Posté par  . Évalué à 1.

          Serait-il envisageable d'imaginer que le release management de Debian soit architecture specifique.
          C'est à dire ne pas attendre que toutes les architecture soit prète pour les sortir en stable quand une archi est prètes elle sort, et les autres suivront.

          Cela permetera de sortir rapidement les archi très utilisé et après sa sortie de permètre aus DD de se concentres sur les autres archi.

          Qu'en pensez-vous?

          • [^] # Re: Oui mais non ...

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

            Et si des packages ont besoin d'être patchés pour tourner sur SPARC, qu'est-ce que tu en fais ? Tu backporte pour les autres archis et tu fais des mises à jour ? (pour un patch qui ne sert à rien pour l'archi et ne peut que potentiellement ajouter des bugs...)

            Ce que tu proposes risque de se terminer en forks de Debian, un par archi.

    • [^] # Re: Oui mais non ...

      Posté par  . Évalué à 3.

      La proposition indique que les architectures non séléctionnées ne seront plus "releasées" ; mais elles pourront rester dans sid (avec des snapshots de temps en temps).
      Donc ces archis ne sont pas vraiment abandonnées.

  • # NetBSD

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

    Une petite question : comment NetBSD, avec une équipe a priori plus réduite, arrive à sortir régulièrement des versions (au moins aussi vite que Debian) et à simultanément supporter autant de plateformes?

    Est-ce au détriment de la qualité? De la stabilité?

    Un avis?

    • [^] # Re: NetBSD

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

      Du nombre de packages.
      Le nombre d'applis dans NetBSD est negligeable devant le nombre fourni par Debian.

      • [^] # Re: NetBSD

        Posté par  . Évalué à 6.

        La moitié c'est négligeable ? grosso modo 5000 contre 10000.

        Tout en se rappelant quand dans la liste des devels debian nous avons 1500 personnes alors que chez Net dans les 250 avec bien sur des gens qui font des choses negligeables comme developper un noyau, les outils systèmes, le support des archis et deux trois autres broutilles.

    • [^] # Re: NetBSD

      Posté par  . Évalué à 4.

      NetBsd supporte un TRES grand nombre d'architectures mais a compare al folies de grandeurs de Debian "peu" de Paquets (2 ou 3 CDs sauf erreur....). En clair ils ont les pieds sur terre....

      • [^] # Re: NetBSD

        Posté par  . Évalué à 3.

        la folies des grandeurs de Debian

        Beaucoup de choses sont documentes chez Debian, mais j'arrive toujours pas a trouver la doc qui stipule que Debian doit contenir un grand nombre de paquets.

        Par contre je retrouve souvent le principe de "L'utilisateur reclame un paquet, on fournit a l'utilisateur le paquet".

        En clair ils ont les pieds sur terre....
        Ou alors ils ont pas eu le temps d'en faire plus.

    • [^] # Re: NetBSD

      Posté par  . Évalué à 7.

      une réponse :
      https://linuxfr.org/comments/546955.html#546955(...)
      http://linuxfr.org/comments/546955.html#546955(...)

      en même temps il me semble que NetBSD, comme tous les BSD, ne propose que le kernel et les outils userland.
      tout le reste se trouve dans les ports ( cad 90% des softs non ?) qui ne sont pas maintenus par le team NetBSD (pas de correctifs de sécu et autres).

      • [^] # Re: NetBSD

        Posté par  . Évalué à 7.

        NetBSD avec toutes ses qualités n'est pas comparable à une ditrib' Debian, y'a qu'à regarder du côté des packages comme certains le font judicieusement remarquer.

        NetBSD sur DreamCast c'est bien, mais il s'agit plus d'une démo technique que d'une archi supportée réellement.

      • [^] # Re: NetBSD

        Posté par  . Évalué à 5.

        NetBSD, comme tous les BSD, ne propose que le kernel et les outils userland. tout le reste se trouve dans les ports ( cad 90% des softs non ?) qui ne sont pas maintenus par le team NetBSD (pas de correctifs de sécu et autres)

        DTÉ ! (désinformation trollistique éhontée ;)

        Le userland est copieusement fournis et souvent suffisant. Les sources du système de base (kernel + userland) sont relues et auditées en permanence par les mainteneurs (ce qui n'est le cas des sources d'aucune distrib linux à ma connaissance).

        Et bien sûr, les ports & packages sont maintenus (et les correctifs sont distribués).

        Et ce sur les 3 *BSD bien entendu.

    • [^] # Re: NetBSD

      Posté par  . Évalué à -1.

      Bah l'iso standard d'un NetBSD fait 100 Mo, et y'a 7*650 Mo chez Debian...C'est pas le même boulot.

      • [^] # Re: NetBSD

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

        l'iso de 100Mo de NetBSD ne contient pas les packages alors que les 7CD de Débian les contiennent. Bref c'est une comparaison idiote : avec un seul CD de débian tu installes la distrib et dans les 2 cas il suffit d'une disquette de 1.44Mo pour installer le système.

        Bref ça veut rien dire ce que tu dis.

        • [^] # Re: NetBSD

          Posté par  . Évalué à 2.

          Je pense que debian n'est plus installable à partir d'une disquette..

        • [^] # Re: NetBSD

          Posté par  . Évalué à 1.

          Ma comparaison n'est pas idiote, c'est toi qui dit n'importe quoi, le système de port de NetBSD n'a rien à voir avec le fonctionnement de Debian.
          Les 100 Mo contiennent TOUS les packages dont le core team NetBSD assure la fonctionnement, la stabilité, la compatibilité, etc... alors que Debian assure cela pour ces 7 CDs, même si personne n'est forcé de tous les installer en entier!!

  • # Un mouvement naturel?

    Posté par  . Évalué à 5.

    En tout cas en ce qui concerne les ibm390, ça semble logique vu que les boîtes ayant ce genre d'équippement ont plutôt tendance à prendre des distros ayant un support pro et supportées aussi par IBM, genre SuSE ou RedHat...

    Les Alphas c'est un peu triste, mais bon, c'est mort de chez mort comme bécanes...

    Les Sparcs? Ben oui, ça c'est un peu plus embêtant.

    Mais bon, maintenir tous ces systèmes mineurs, ça coûte... c'est pas parceque l'on est dans le monde du logiciel libre qu'on ne peut être pragmatique.

    • [^] # Re: Un mouvement naturel?

      Posté par  . Évalué à 4.

      Et mon m68k qui tourne depuis 1994...

      Objectivement, même si je sais que la sarge serai la dernière stable pour mon m68k, si ça peut aider à releaser un peu plus vite, c'est pas plus mal (j'ai un serveur mail de prod en testing). Par contre, c'est ce qui à l'époque m'avait choisir debian, le nombre d'architectures supportées en // (actuellement, j'utilise 4 architectures en stable/testing/unstable : i386, m68k, ppc et amd64)

      Je sais aussi que pas mal de "geeks" utilisent des debian sur des vieilles machines, car celles dernières consomment moins et/ou pour des restrictions budgétaires, ou tout simplement pour le fun (ça ne me dérange pas qu'ils mette 10-12 heures à compiler son noyeau). Etre pragmatique, c'est bien, mais il y aura toujours un minimum de casse !

      Maintenant, si ça me dérange trop, ce sera NetBSD pour les non supportés, dommage...

      Ton idée de mouvement naturel me rappelle un peu la loi de Darwin, et une certaine tendance de l'informatique actuelle (on à des machines puissantes, alors on code comme des gruiks, et on ne supporte plus les vieilles) --> Les plus puissants mangenat les plus faibles.

      Forcément, ça coute, mais même si je serai un peu décu, je remercierai debian d'avoir supporté mon petit m68k aussi longtemps (peu l'ont fait)

      • [^] # Re: Un mouvement naturel?

        Posté par  . Évalué à 2.

        Ton idée de mouvement naturel me rappelle un peu la loi de Darwin, et une certaine tendance de l'informatique actuelle (on à des machines puissantes, alors on code comme des gruiks, et on ne supporte plus les vieilles) --> Les plus puissants mangenat les plus faibles.

        Je pense que tu déformes mes propos. Je pense que une distro debian m68k a encore sa place, mais je pense que ça ne doit plus être synchrone avec les versions pour des architectures actuelles. Le truc c'est que toutes ces petites architectures retardent l'évolution de Debian parcequ'elles font partie officiellement de Debian et que donc il faut que tout soit synchrone. En retirant ces éléments de la version officielle, Debian va pouvoir avancer plus vite que si il devait attendre tout le monde à chaque pas (surtout que les équippes des mainteneurs de ces architectures fondent de plus en plus avec le temps, et ont elles-mêmes moins de temps).

        Et puis, rien n'empèche les développeurs de ces architectures mineures de faire un fork avec Debian et de continuer à supporter leur architecture préférée à leur rythme, avec leur propre cahier des charges et leurs propres objectifs.

  • # ca devait arrivé

    Posté par  . Évalué à 4.

    C'est une décision censée, c'est le principe même des OS libres appliqué à une distrib';
    Brûler une pourcentage important de son énérgie pour inclure des architectures peu utilisées n'est pas tenable.
    Il reste encore netBSD pour les archis exotiques ou moins répandu;
    Tant qu'on arrive à trouver Unix à son pied ça va.

  • # Pourquoi pas

    Posté par  . Évalué à 10.

    Je suis personnellement utilisateur de Debian sur Sparc, donc je préférerais que le support soit maintenu mais la décision n'est pas illogique.

    Ce que je retiens, c'est que par exemple beaucoup de problèmes viennent des mises à jour kernel, or la plupart des gens qui utilisent Debian sur des archis particulières compilent leur noyau. Ensuite voir que les autres problèmes surgissent par exemple du support gtk+2... Qui utilisent Gnome 2.10 ou KDE 3.4 sur une archi ARM ou MIPS ?

    Ma conclusion serait qu'il est peut-être plus logique de faire de release d'un coeur d'applications plus ciblées : une espèce de Debian-server contenant les logiciels les plus répandus. Comme d'autres je pense que maintenir 14 CDs de programmes sans bugs est une gageur inutile. On parle de NetBSD, ils ont bien compris que pour tenir beaucoup d'architectures il etait impossible de maintenir beaucoup de paquets. Avoir l'installateur, un kernel stable et un socle de logiciels seraient parfaits.

    Petite aparté, c'est incroyable de voir les réactions que provoque Debian : trolls à tout va, critiques acerbes, jugements baclés... Comme toute distrib, elle a ses défauts, ses avantages : vous aimez vous l'utilisez, vous n'aimez pas vous ne l'utilisez pas, point. L'évangélisation forcée et la descente gratuite sont aussi ridicules.

    --
    Thomas

    • [^] # Re: Pourquoi pas

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

      Afin de connaître les logiciels les plus utilisés, pour savoir comment réduire cette architecture, un système d'envoi anonyme des paquets installés/utilisés sur une machine ne serait pas mal du tout pour se faire une idée.

      J'avais cru voir cela du temps de Potato (à moins que ce soit dans Woody), mais si mes souvenirs sont bons cela ne concernait que le système, sans forcément un échange via EMail avec l'extérieur.

      En clair, impliquer les utilisateurs Debian pour leur demander ce qu'ils attendent en matières de paquets.

      Personnellement, si Debian ne me permettait pas de faire aux petits oignons (en gros, installer la doc' si je le désire, ou tel ou tel paquet finement), cela ferait une éternité que je serais passé sur NetBSD/OpenBSD, qui, sur les architectures serveurs mono-processeurs que j'utilise comblent le défaut que je voie en Debian : la vitesse de sortie des releases stables....

      • [^] # Re: Pourquoi pas

        Posté par  . Évalué à 7.

        Ca existe déjà : http://popcon.debian.org/.(...)

        Les chiffres se passent de commentaires... Mais je ne suis pas forcément d'accord avec ta conclusion : la loi de la majorité ne doit pas tout gouverner. Par contre il pourrait être logique d'opérer des traitements différents aux paquets installé par 90% des utilisateurs par rapport à ceux installés par 2 ou 3 personnes.

        --
        Thomas

        • [^] # Re: Pourquoi pas

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

          Je savais bien qu'il y avait un truc du genre ;-).

          Pour moi le traitement différent devrait être : cycle de sortie de releases plus court pour les paquets utilisés en grande majorité, et plus long pour les autres.

          • [^] # Re: Pourquoi pas

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

            S'il ils passent a la trappe les trucs exotique/non utilisé/inutile, à la majorité de la population unixienne, il vont arreter Hurd :) ?

            A j'ai pas dit que HURD était inutile......
            Un troll ? nan ......
            (tramo inside)

        • [^] # Re: Pourquoi pas

          Posté par  . Évalué à 3.

          popcon sert aussi à placer les paquets sur les CD : les plus fréquents sur les premiers, ce qui fait que 1 ou 2 CD (au max 3) sont suffisants pour une installation « classique ».

    • [^] # Re: Pourquoi pas

      Posté par  . Évalué à -7.

      Je suis personnellement utilisateur de Debian sur Sparc, donc je préférerais que le support soit maintenu mais la décision n'est pas illogique.

      D'un autre côté, ceux qui ont une vraie machine performante utilisent un vrai OS: NetBSD. Debian c'est juste un jouet. valable pour les soit disant ordinateurs i386.

      • [^] # Re: Pourquoi pas

        Posté par  . Évalué à 2.

        Heu ca veut dire quoi pr toi vraie machine performante ?
        Parce qu'il y'aurait de fausse machine performante ou de vraies machines pas performante ?

      • [^] # Re: Pourquoi pas

        Posté par  . Évalué à -2.

        Vu les performance de NetBSD, il faut une "vraie machine performante" sinon ça rame trop.

  • # On prend les mêmes et on recommence .....

    Posté par  . Évalué à 4.

    A chaque "retard" de sortie d'une Debian Stable c'est la même chose. Certains developpeurs ont des idees pour que cela ne se reproduise plus.
    Toutes les idees se basent sur un meme principe :
    Il faut limiter la portée de la distribution (Architectures, types des packets....). Seulement voila les volontaires de Debian n'aiment pas etre limités....
    Resultat : La Distribution est de plus en plus grande et supportent de plus en plus d'architectures. Ce qui en soit n'est pas plus mal mais comme l'intervalle entre 2 stables est de plus en plus grands et surtout imprevisible...., l'utilisation dans le monde professionnel sera de plus en plus problematique....

    • [^] # Re: On prend les mêmes et on recommence .....

      Posté par  . Évalué à 4.

      C'est marrant cette idée que "le monde professionnel" souhaiterait des releases plus fréquente... Je constate plutôt l'inverse car chaque nouvelle release a un coût énorme pour une entreprise.
      Donc mis à part les entreprises qui ont des informaticiens attitrées ou qui ont un gros budget r&d, ça ne tient pas... Et pour ceux-là, il y a testing, unstable et experimental.
      Généralement le fait de vouloir tout changer sans arrêt c'est plutôt un argument commercial, hors particulièrement en informatique, tout le monde sait qu'il ne faut pas toucher ce qui marche !

      • [^] # Re: On prend les mêmes et on recommence .....

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

        D'un autre côté, toucher ce qui marche s'il ne faut pas, il est parfois difficile de se passer des derniers outils "stables" offerts dans certains domaines, surtout dans le monde réseau/sécurité.

        Un exemple tout bête : l'exim fourni avec Woody est tellement vieux que plus supporté du tout par ses créateurs. Donc, même au niveau de la sécurité ce n'est pas trop cela....

        • [^] # Re: On prend les mêmes et on recommence .....

          Posté par  . Évalué à 3.

          Pour quelques applis spécifiques il reste beaucoup moins couteux de faire quelques backports que de changer l'intégralité.

          Ce qui serait appréciable à la rigueur c'est de certifier certains backports, ça tombe bien c'est justement le cas pour ton exemple d'exim il me semble...

          Sinon, c'est le rôle des (nombreuses) distributions dérivées, c'est fait pour, il ne faut pas tout mélanger à mon avis.

        • [^] # Re: On prend les mêmes et on recommence ..... backport fixes

          Posté par  . Évalué à 2.

          l'exim fourni avec Woody est tellement vieux que plus supporté du tout par ses créateurs. Donc, même au niveau de la sécurité ce n'est pas trop cela....
          Le principe de stable est justement que les bugs importants (dont ceux de sécurité) sont corrigés sans passer à la version upstream supérieure. Afin que ces correctifs perturbent le moins possible les machines de prod.
          Ca s'appelle les "backport bugfixes". Et c'est bien-sûr valable aussi pour exim.
          L'essentiel pour une machine de prod est que tous les gros bugs connus soient corrigés proprements. Et je crois qu'ils le sont dans stable à l'heure actuelle.

          PS: y'a pas beaucoup de script kiddies qui s'attaquent à des machines sans failles connues.

      • [^] # Re: On prend les mêmes et on recommence .....

        Posté par  . Évalué à 1.

        Je pense qu'il faut aussi distinguer le type d'utilisation serveur ou desktop.

        En utilisation serveur je ne connais personne dans mon entourage qui se soit amusé à mettre du testing ou unstable en prod.

        Avoir la dernière version de XOrg ou Gnome c'est pas le souci de ceux qui ont des machines de prod... Le temps entre 2 releases n'est pas genant, et au contraire ces admins là sont plutôt heureux de savoir que leur système stable n'a pas besoin de mise à jour.

        • [^] # Re: On prend les mêmes et on recommence .....

          Posté par  . Évalué à 10.

          Les admins de serveurs mails sous debian seraient contents d'avoir des antispams et antivirus à jour.

          Les admins d'applis web, d'avoir les versions récentes (enfin pas celles d'il y a 5 ans) des interpréteteurs php/python/perl/java (et que les developpeurs leur demandent de remplacer à la main)...

          Les admins de serveurs de fichiers en entreprise ne seraient pas contre le fait de pouvoir causer aux windows sortis il y a moins de 5 ans ...

          etc.

          Si les admins n'utilisent pas sarge ou sid, c'est parcequ'elles sont instables et trop mouvantes, pas parcequ'ils n'ont pas besoin de paquetages modernes.

          Et d'autres distributions GNU/Linux comme d'autres systèmes d'exploitation (Solaris, *BSD notamment) ont prouvés qu'il nétait pas nécessaire d'avoir de vieux logiciels pour être stable. Le problème de délais chez debian est -amha- un pb d'organisation sociale plus qu'autre chose.

          • [^] # Re: On prend les mêmes et on recommence .....

            Posté par  . Évalué à 4.

            >> Si les admins n'utilisent pas sarge ou sid, c'est parcequ'elles sont instables et trop mouvantes, pas parcequ'ils n'ont pas besoin de paquetages modernes.

            Pas tant que ça non plus. Au taf on utilise quasiment que Testing, en faisant attention lors des upgrades, qui sont effectuées grosso modo toutes les semaines. Lorsqu'on apprend l'existence d'une faille, soit on corrige nous meme soit on récupère le nouveau paquet s'il est déjà sorti. Bien sur on préfèrerait un système de versionning qui colle plus à nos besoins, pas forcément time-based mais au moins quelquechose comme le fait RedHat. Globalement on reste très partisan de Debian sur les serveurs, surtout pour la qualité des paquets et des outils mis à notre disposition.

          • [^] # Re: On prend les mêmes et on recommence .....

            Posté par  . Évalué à 0.

            Avec ton exemple il y a eu migration des applis des développeurs, donc migration des desktops clients, formation des utilisateurs et enfin migration des serveurs et formation des admins... Ensuite baisse de rendement drastique pendant quelques mois le temps de stabiliser tout ce petit monde.

            Tu te rends compte du coût de l'opération ? Je ne connais pas beaucoup d'entreprises qui ont les moyens et l'envie de l'assumer tous les ans ! Surtout que ce genre de migration prend généralement plusieurs mois. Que les développements eux même ont pris plusieurs mois, voir années (et donc ne tournerons pas sur le même système au début qu'à la fin !)

            Par contre je ne compte plus le nombre d'entreprises qui ont encore de nombreux serveurs NT4 et postes 95-98...

            Il ne faut donc pas généraliser par rapport à quelques cas personnels. Les délais entre les releases ne sont pas un problème pour tout le monde, et en particulier dans les entreprises autres qu'informatiques.

            Il y a par ex un groupe d'entreprises utilisatrices de python qui cherche à stabiliser beaucoup plus longtemps les versions de python.

            • [^] # Re: On prend les mêmes et on recommence .....

              Posté par  . Évalué à 2.

              Par contre je ne compte plus le nombre d'entreprises qui ont encore de nombreux serveurs NT4 et postes 95-98...

              C'est rendu possible parceque ms fournis du support et des maj sur les anciennes versions de windows (enfin, les "relativement anciennes", pour nt4/win98 je ne sait pas).

              Quand les anciennes versions sont maintenues longtemps (au moins en ce qui concerne les mises à jours de sécu, et c'est le cas pour certaines distribs, comme red hat, pour netbsd, pour solaris etc.) l'ensemble des utilisateurs n'est pas pénalisé par les quelques déploiment tellements bordéliques qu'ils sont inupgradables. (nb: amha si l'upgrade est un vrai probleme, les admins concernés devraient se poser des questions, ou les devs si le frein est l'upgrade des compilos/interpreteurs: cf. les questions de portabilité).

              Sans desavouer les points forts de debian, il faut reconnaitre qu'ils pourraient faire mieux sur ce point (les mises à jour de la distrib). Et les problèmes de déploiment sont une mauvaise excuse.

  • # i386, i686 ...

    Posté par  . Évalué à 0.

    Avec ces critères les architectures qui resteront supportées à 100% après la sortie de Sarge seront i386, powerpc, ia64 et amd64 (4/11)


    Avec seulement cette listes d'architectures, sa pourrait permettre d'offrir une version i386 "optimisé pour les x86 actuelles", avec "x86 actuelles" définit comme la base commune majoritaire des pc encore en vie. Toutefois, le 32bits aura probablement disparu lorsque que Etch sortira (en supposant une durée de vie moyenne de 3.5 ans pour un pc). Ce qui résoudra de facto le problème, au moins temporairement.

    • [^] # Re: i386, i686 ...

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

      D'un autre côté, je ne sais pas si c'est une position d'avenir pour Debian, mais en tout cas, ce qui m'a fait préférer Debian à bcp d'autres distributions Linux c'est le fait que je ne me pose pas de question lors de l'installation : en gros, je sais que je peux l'installer sur le "vieux" 486 12 MO de RAM qui traîne à la maison comme sur le dernier P4 du boulot, et ainsi ne pas passer mon temps à apprendre 10 distributions, chacune pour son usage propre, et capitaliser mes connaissances sur une distrib' au lieu de m'éparpiller (certes, c'est bien de connaîtres 10 distribs', mais le temps manque souvent).

      Si je sais configurer Postfix pour une babasse Debian de faible puissance, je sais aussi le configurer pour une grosse, ou du moins partir d'une config' existante sans avoir à me taper 10 pages de manuel et autres FAQ/Howto/Readme pour connaîtres toutes les subtilités de la version livrée avec ma distrib'. C'est particulièrement intéressant en environnement hétérogène (pas forcément i486/P4, mais aussi P4/PowerPC).

      Le plus petit dénominateur commun en archi i386 c'est pas mal je trouve, quitte à proposer qqs. paquets où cela fait réellement la différence dans l'esprit de ce que propose Christian Marillat par exemple avec ses paquets backportés pour Woody pour le multimédia.

      • [^] # Re: i386, i686 ...

        Posté par  . Évalué à 3.

        Je ne sais pas si c'est de la malchance. Mais j'ai aujourd'hui 3 ordinateurs, un 486 au placard qui devrait encore marché, un athlon (3,5 ans) qui ne marche plus, et un sempron (c'est le moins cher) tous neuf. J'ai l'impression que le parc informatique va se réduire à quelques vieilleries increvable type 486 et des pc flambant neuf à changer tous les 3 ans (soit la garantie standard de 3ans pour les processeurs et les CM ...). Utiliser un pc de 5 ans n'a probablement pas de sens économique pour l'industrie. D'où la question sur l'utilité de l'architecture i386 par rapport à i686 par exemple.

        • [^] # Re: i386, i686 ...

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

          Je ne pensais pas forcément à recycler des vieilles bécanes, mais plutôt à des machines de type "embedded", dans le genre Soekris.

        • [^] # Re: i386, i686 ...

          Posté par  . Évalué à 2.

          Utiliser un pc de 5 ans n'a probablement pas de sens économique pour l'industrie.

          Personnellement je fait de la recherche pour une industrie et je peu vous dire que les vieux pc sont trés utilisé chez nous . Elle sont d'autant de router economique. l'achat de 10aine de routeur cisco etant un peu couteux pour finalement bcp de chose inutile.

          Sinon je comprend que la suppression du support "totale" sur certaine plate-forme peu choquer. Mais deja il faut bien comprendre qu'il ne s'agit pas de la supprimer. les correctif avancerons a leur rythme sans toute fois empeché le reste d'avancer. Personnellement je ne voit pas le probleme.
          L'utilisation de c architecture exotique n'est rarement critique et par consequent l'utilisé en unstable ne devrai pas géner outre mesure...

      • [^] # Re: i386, i686 ...

        Posté par  . Évalué à 7.

        en gros, je sais que je peux l'installer sur le "vieux" 486 12 MO de RAM qui traîne à la maison

        En dehors de quelques geeks qui utilise encore des 486? Utiliser une vieille machine pour des taches annexes, j'en suis revenu. C'est inutilisable. Au moindre problème il est plus simple de remplacer la machine que de chercher du matériel antique dans toutes les boutiques d'occase.

        Avec quelques copains on avait récupéré un lot de 486 il y quelques temps et on leur avait trouvé des tâches à la hauteur de leurs "performances". Mais ce genre de matériel ayant déjà bien vécu les pannes à répétitions se sont multipliées. Par exemple une machine servait de DNS sauf que quand elle est morte ça a un peu emmerdé tout le monde. Idem pour le machine qui hébergeait le serveur NIS. On a pas l'air con avec un 486 mort et personne qui peut se logger en attendant un GA (gentil admin). Sans parler de la passerelle... SSH utilise des clés RSA. Et un 486 pour calculer du RSA....

        Bref, je revends au maximum mes vieux trucs. Chez moi j'ai un PC pas trop vieux qui traine mais je ne l'allume jamais. Il est bruillant et tout ce que je peux faire dessus, je peux le faire beaucoup plus rapidement sur le nouveau. J'en aurais bien fait un serveur ou un PC de salon mais le bruit...

        • [^] # Re: i386, i686 ...

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

          Voir ma réponse au dessus : dans le domaine de l'embarqué, entre autres, le 486 est une Rolls, voire une limite quand on commence à causer de rapport puissance/consommation & échauffement.

          Certes on peut classer ceux qui font de l'embarqué dans le camp des "Powers Users", mais quand un client me demande de lui concevoir un firewall pas très cher sur base Linux dans une Soekris (exemple entre autres), je suis bien content de pouvoir faire appel à Debian et de ne pas perdre x heures à tenter d'y faire tenir une Gentoo dessus, ou une Slack, ou ....

  • # PPC64

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

    >> Avec ces critères les architectures qui resteront supportées à 100% après la sortie de Sarge seront i386, powerpc, ia64 et amd64 (4/11)

    autrement dit les possesseurs d'X86 pourront choisir entre l'ISA 32 bits (i386) et l'ISA 64 bits (amd64) alors que les joyeux et nombreux acheteurs de PowerMacs devront utiliser une distro basé sur l'ISA 32 bits powerpc et ne pourront pas exploiter pleinement leur archi PPC64 !
    Je signale aux décideurs Debian que tous les Macs vont passer progressivement sur PPC64 et qu'IBM vend aussi des serveurs à base de PPC64.
    Rien que les Powermacs cela représente déja des centaines de milliers de machines et quand les PowerBooks basculeront cela représentera des millions de machines !
    Il faut absolument avoir un port PPC64 !

    • [^] # Re: PPC64

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

      ( /s/ Il faut absolument / Ca serait sympa qu'il fasse / ) un port PPC64 !

      >cela représentera des millions de machines !
      des millions de machines qui tourneront sous OS X surtout....

    • [^] # Re: PPC64

      Posté par  . Évalué à 3.

      y a vraiement un avantage a passer en mode 64bits sur PPC ?
      C'est pas comme pour les sparc ou c'est plus lent qu'en 32 bits (le kernel est bien en 64 bits, mais pas les appli)
      Y a t il vraiement pas de kernel 64bits dans la branche PPC ?

      • [^] # Re: PPC64

        Posté par  . Évalué à 4.

        Apple eux-même n'ont pas (encore) de version 64 bits de l'OS complet.

        http://developer.apple.com/macosx/tiger/64bit.html(...)
        « It is important to note that in the Tiger release, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory. »

        Avant de se précipiter sur une version 64 bits il serait bien de donner des chiffres d'améliorations des performances et de coût suplémentaire en RAM.

        Par exemple la discussion i686/i383 revient régulièrement sur la liste debian-devel et à part quelques rares programmes (calculs crypto par exemple) le gain est nul ou presque. Et d'ailleur le paquet libssl0.9.7 contient déjà des version pour i386, i486, i586 et i686. Faites un dpkg -L libssl0.9.7 pour voir :

        /.
        /usr
        /usr/lib
        /usr/lib/libcrypto.so.0.9.7
        /usr/lib/libssl.so.0.9.7
        /usr/lib/i486
        /usr/lib/i486/libcrypto.so.0.9.7
        /usr/lib/i486/libssl.so.0.9.7
        /usr/lib/i586
        /usr/lib/i586/libcrypto.so.0.9.7
        /usr/lib/i586/libssl.so.0.9.7
        /usr/lib/i686
        /usr/lib/i686/cmov
        /usr/lib/i686/cmov/libcrypto.so.0.9.7
        /usr/lib/i686/cmov/libssl.so.0.9.7
        /usr/share
        /usr/share/doc
        /usr/share/doc/libssl0.9.7
        /usr/share/doc/libssl0.9.7/copyright
        /usr/share/doc/libssl0.9.7/changelog.gz
        /usr/share/doc/libssl0.9.7/changelog.Debian.gz


        L'idéal est d'avoir du code 32 bits et du code 64 bits en même temps sur la même machine. Par exemple voir http://people.debian.org/~taggart/multiarch/(...) et en particulier http://www.linuxbase.org/~taggart/multiarch.html(...)

        • [^] # Re: PPC64

          Posté par  . Évalué à 2.

          > Apple eux-même n'ont pas (encore) de version 64 bits de l'OS complet.

          Tu me fais peur la... le 64 bits du G5, c'est donc "inutile" jusqu'à encore aujourd'hui ? (j'ai bien lu que ça marchait en partie quand même).

    • [^] # Re: PPC64

      Posté par  . Évalué à 5.

      C'est quand même bien Debian, tu pose une question et, paf, le même jour tu as une réponse.

      http://lists.debian.org/debian-project/2005/03/msg00102.html(...)

      To: debian-project@lists.debian.org
      Subject: 64 bit PowerPC porting machine available
      From: Martin Michlmayr - Debian Project Leader <leader@debian.org>
      Date: Tue, 15 Mar 2005 20:24:18 +0000

      The University of Augsburg and IBM have provided some of our
      developers with access to three POWER based machines (OpenPower 720
      [1]) to help with Debian's port to 64 bit PowerPC. We have also been
      given a G5 on loan which can be used for debian-installer, glibc and
      other work. The G5 is currently with Jeff Bailey.

      A selected number of (powerpc, d-i, glibc, gcc) developers have gained
      access to the POWER systems already. Bastian Blank announced some
      success with powerpc64 support for glibc today [2]. If you are
      interested in working on the powerpc64, please contact me and I'll see
      if I can arrange an account for you. There'll probably be more
      general access in the future.

      [1] http://www-1.ibm.com/servers/eserver/openpower/hardware/720.html(...)
      [2] http://lists.debian.org/debian-glibc/2005/03/msg00088.html(...)
      --
      Martin Michlmayr
      leader@debian.org

      Conclusion : le portage PPC64 est en cours et je pense qu'un coup de main ne sera pas de trop.

  • # c'est pas tout mais

    Posté par  . Évalué à 2.

    c'est pour quand la sarge alors ?

    • [^] # Re: c'est pas tout mais

      Posté par  . Évalué à 5.

      Au pire pour fin 2004.

      • [^] # Re: c'est pas tout mais

        Posté par  . Évalué à -1.

        et après c'est moi qu'on moinsse pour une question naïve (mais qui me paraît quand même pertinente) :)

        • [^] # Re: c'est pas tout mais

          Posté par  . Évalué à 10.

          > une question naïve

          Question naïve mais réponse impossible. La première rc de Sarge date de juin 2004. Plus de 8 mois !
          Petit historique :
          http://linuxfr.org/2003/08/19/13677.html(...) : La prochaine version stable de Debian pour décembre ? (2003!)
          http://www.debianplanet.org/node.php?id=1131(...) : Release Update: Sarge in September?
          http://www.debianplanet.org/node.php?id=1039(...) : GNOME 2.4 in Sarge
          http://www.debianplanet.org/node.php?id=1068(...) : GNOME 2.6 in Sarge?

          Et maintenant il y a Gnome 2.8 dans Sarge. Va savoir s'il n'y aura pas Gnome 2.10 ou KDE 3.4 ou supérieur à ce traintrain. Dans ce bordel où il y a de quoi se pisser dessus de rire, comment connaitre la date de sortie ?

          • [^] # Re: c'est pas tout mais

            Posté par  . Évalué à 3.

            Ils avancent :D En même temps que l'annonce de la mise à part de certaines archis, ils disent qu'il ne peuvent pas donner de date mais qu'ils n'ont jamais été aussi proche :D

            "While this does not yet give us a timeline with fixed dates
            for the freeze and the release, this is noteworthy enough in itself that
            we wanted to share the news immediately."

            • [^] # Re: c'est pas tout mais

              Posté par  . Évalué à 2.

              C'est sûr, de jour en jour ils sont plus proches! Le jour ou le contraire sera vrai, les lois du temps auront un sérieux problème.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

          • [^] # Re: c'est pas tout mais

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

            Pour la woody, c'était à peu pres un an apres le début du freeze... qui n'a toujours pas eu lieu completement pour la sarge.

          • [^] # Re: c'est pas tout mais

            Posté par  . Évalué à 2.

            La première rc de Sarge date de juin 2004. Plus de 8 mois !

            C'etait la premiere rc de l'installeur, pas de la distrib.

            • [^] # Re: c'est pas tout mais

              Posté par  . Évalué à 1.

              Quand j'ai downloadé à cette époque, c'était bien sarge-rc1 et pas debian-installer-rc1.
              Néanmoins, t'as peut-être raison car j'ai jamais vu d'annonce pour sarge-rc2 ou sarge-beta3, ...

    • [^] # Re: c'est pas tout mais

      Posté par  . Évalué à 3.

      Ca fait longtemps qu'elle est sortie, je m'en sert tous les jours ;-)

      • [^] # Re: c'est pas tout mais

        Posté par  . Évalué à 10.

        ta phrase pourrait avoir plein de sens possibles dont pas mal dans des domaines non informatiques

  • # Cotisons nous!

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

    On achete un vieil ordi avec une architecture obsolete et on l'offre à un LUG qui a plus de 50 utilisateurs.
    On trouve des bounties pour des developpeurs prets à faire le support de cette archi.
    Et hop!

    Et pourquoi ne pas faire une appli (si elle n'existe pas encore) qui pose comme question à l'admin sont architecture lors de l'install et qui envoit (avec son accord) l'info à debian afin qu'on évalue plus ou moins le nombre de machines de telle ou telle archi ?

    • [^] # Re: Cotisons nous!

      Posté par  . Évalué à 2.

      Il y a un point qui a été mal traduit et devient un contre sens dans la version française. Le texte original est:

      - the release architecture must have N+1 buildds where N is the number
      required to keep up with the volume of uploaded packages

      - the value of N above must not be > 2

      Ce qui veut dire qu'il faut qu'au plus deux machines de ton architecture obsolète arrivent à suivre la charge d'un buildd. Ça limite pas mal l'ancienneté de l'architecture.

Suivre le flux des commentaires

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