Articles précédents : Articles
- [60] Maui X-Stream aurait volé du code sous GPL et se serait approprié le copyright de PearPC
- [102] Vers une licence libre européenne promue par la commission ?
- [32] Kicad : une suite GPL de CAO électronique multi-plateforme
- [69] Changement dans la numérotation du noyau Linux
- [102] Le Danemark s'opposera au passage en point A
- [22] Adobe se lance dans l'Open Source !
- [22] IBM, Linux et l'Open Source
- [78] Stallman souhaite plus d'efforts pour un BIOS libre
- [80] La TNT est arrivée en France depuis le 28 février
- [145] La Commission refuse une nouvelle première lecture
Liens connexes
- L'annonce sur debian-devel-announce (887 hits)
- Réaction de Wouter Verhelst (657 hits)
- Réaction de Norbert Tretkowski (594 hits)
- Réaction d'Andrew Pollock (583 hits)
- Réaction de Steve Kemp (657 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Debian envisage un support partiel des architectures les moins utilisées
Posté par Aurélien Bompard (Jabber id, page perso, ). Modéré le 15 mars 2005.
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.
![[en]](../../../images/en.png)
L'annonce sur debian-devel-announce (887 hits)-
Réaction de Wouter Verhelst (657 hits)
-
Réaction de Norbert Tretkowski (594 hits)
-
Réaction d'Andrew Pollock (583 hits)
-
Réaction de Steve Kemp (657 hits)
> Lire la dépêche (132 commentaires, moyenne: 3,1).
- 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.
Très Bien
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 nigaiden () le 15/03/2005 à 08:33. (lien). Évalué à 3.À mon avis ça ne passera pas le vote.
-
[^]Re: Très Bien
Posté par nooky59 () le 15/03/2005 à 09:16. (lien). É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 Dabowl_94 () le 15/03/2005 à 09:43. (lien). É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 :-)
-
-
-
[+] [^]Re: Très Bien
Posté par sobek () le 15/03/2005 à 09:38. (lien). É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 nooky59 () le 15/03/2005 à 13:16. (lien). É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
C'est l'assurance d'avoir Xorg 6.7.0 avant 10 ans ;)
Dommage, je suis passé à Ubuntu...
-
[^]Re: Youpi
Posté par Gabriel () le 15/03/2005 à 09:40. (lien). Évalué à 0....Mais Ubuntu elle reste sur Debian
--
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying-
[+] [^]Re: Youpi
Posté par bz31 (page perso, ) le 15/03/2005 à 10:01. (lien). Évalué à -5.T'es sûr ?
Mandrake était sur RedHat, et maintenant ?-
[^]Re: Youpi
Posté par Mickaël L () le 15/03/2005 à 10:37. (lien). É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 Dabowl_94 () le 15/03/2005 à 16:17. (lien). É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-
[^]Re: Youpi
Posté par TeXitoi (Jabber id, page perso, ) le 15/03/2005 à 16:41. (lien). É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
-
[^]Re: Youpi
Posté par SF () le 15/03/2005 à 17:01. (lien). É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 Jean Parpaillon (Jabber id, page perso, ) le 16/03/2005 à 10:56. (lien). É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-
[^]Re: Youpi
Posté par GhZaaark3 () le 17/03/2005 à 17:38. (lien). É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?--
moué...
-
-
-
[+] [^]Re: Youpi
Posté par bz31 (page perso, ) le 15/03/2005 à 20:13. (lien). É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 Mathieu Pillard (page perso, ) le 15/03/2005 à 20:35. (lien). É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 Mathieu Pillard (page perso, ) le 15/03/2005 à 20:39. (lien). Évalué à 5.Et comme c'est mon jour de bonté, jte refile ce lien: http://www.ubuntulinux.org/ubuntu/relationship/document_view.(...)
Tu n'as pas pu le manquer lors de ta visite sur le site d'ubuntu, vu qu'il est bien placé a gauche dans le menu quand tu vas sur "About ubuntu" et que j'ai pas mis 30 secondes pour le trouver...-
[+] [^]Re: Youpi
Posté par bz31 (page perso, ) le 15/03/2005 à 21:13. (lien). Évalué à -10.J'ai dis "page d'accueil".
-
[+] [^]Re: Youpi
Posté par bz31 (page perso, ) le 16/03/2005 à 15:29. (lien). Évalué à -10.Ca me fait plaisir d'être moinssé au top négatif.
-
-
-
-
[^]Re: Youpi
Posté par beny (page perso, ) le 15/03/2005 à 21:18. (lien). É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 :)-
[^]Re: Youpi
Posté par Florimond Simonklein (page perso, ) le 17/03/2005 à 09:41. (lien). Évalué à 3.Ubuntu, peut-être pas, mais certains développeurs peut-être.
http://www.inittab.de/blog/2005/02/12#20050212_ubuntu-gives-back(...)-
[^]Re: Youpi
Posté par Mathieu Pillard (page perso, ) le 21/03/2005 à 16:06. (lien). Évalué à 2.C'est un peu tard, mais pour rajouter de l'eau au moulin, il y a: http://people.ubuntu.com/~scott/patches/(...)
C'est plutot interessant, peut etre pas 100% complet, mais en gros, c'est sensé lister les modifs entre debian et ubuntu au niveau des paquets venant de debian...
-
-
-
-
-
-
Nuance !
Quelques développeurs Debian proposent que le projet supporte moins d'architectures.
-
[^]Re: Nuance !
Posté par Mickaël L () le 15/03/2005 à 09:15. (lien). É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 Sylvain Sauvage () le 16/03/2005 à 13:57. (lien). É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 !!
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.....
Slackware depuis 1996
-
[^]Re: Cela me rapelle en attendant Godot .... Woody !!
Posté par Mickaël L () le 15/03/2005 à 09:17. (lien). É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 Unixfix le Gaulois () le 15/03/2005 à 10:00. (lien). É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.....
--
Slackware depuis 1996-
[^]Re: Cela me rapelle en attendant Godot .... Woody !!
Posté par Emmanuel Seyman () le 15/03/2005 à 14:48. (lien). É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 Dabowl_94 () le 15/03/2005 à 16:36. (lien). É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.-
[^]Re: Cela me rapelle en attendant Godot .... Woody !!
Posté par Emmanuel Seyman () le 15/03/2005 à 16:57. (lien). É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 PasChauve PasOunet () le 16/03/2005 à 09:58. (lien). É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 Dabowl_94 () le 17/03/2005 à 09:38. (lien). É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 ...-
[^]Re: Cela me rapelle en attendant Godot .... Woody !!
Posté par Unixfix le Gaulois () le 17/03/2005 à 10:15. (lien). É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…--
Slackware depuis 1996-
[+] [^]Re: Cela me rapelle en attendant Godot .... Woody !!
Posté par Raphaël Gertz (page perso, ) le 18/03/2005 à 15:23. (lien). É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 ?
+ 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 THE_ALF_ () le 15/03/2005 à 09:17. (lien). É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.--
L'univers de propensions qui est le notre est intrinsèquement créatif (K. Popper).
Snapshot
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 ppb () le 15/03/2005 à 09:58. (lien). É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 Croconux () le 15/03/2005 à 10:43. (lien). É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 nooky59 () le 15/03/2005 à 13:22. (lien). É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 Zenitram (page perso, ) le 15/03/2005 à 10:34. (lien). É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 nooky59 () le 15/03/2005 à 13:25. (lien). É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 Benjamin François (page perso, ) le 15/03/2005 à 15:13. (lien). É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 ...
Pour les architectures exotiques, il y a NetBSD ...
-
[^]Re: Pas grave ...
-
[^]Re: Pas grave ...
Posté par Tristram () le 15/03/2005 à 09:50. (lien). É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 Thy (page perso, ) le 15/03/2005 à 10:24. (lien). É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 totof2000 () le 15/03/2005 à 10:32. (lien). É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 Larry Cow () le 15/03/2005 à 10:38. (lien). É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 tgl () le 15/03/2005 à 12:43. (lien). É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 herodiade () le 15/03/2005 à 21:29. (lien). É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 Thomas Douillard () le 16/03/2005 à 20:25. (lien). É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 herodiade () le 17/03/2005 à 15:21. (lien). É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
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 ...
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 Dabowl_94 () le 15/03/2005 à 10:17. (lien). É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 !-
[+] [^]Re: Oui mais non ...
Posté par bmc () le 15/03/2005 à 10:25. (lien). É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 bigben (page perso, ) le 15/03/2005 à 12:06. (lien). É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 Aurélien Bompard (Jabber id, page perso, ) le 15/03/2005 à 12:43. (lien). É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 ...
NetBSD
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 Pascal Terjan (Jabber id, page perso, ) le 15/03/2005 à 10:14. (lien). Évalué à 7.Du nombre de packages.
Le nombre d'applis dans NetBSD est negligeable devant le nombre fourni par Debian.-
[^]Re: NetBSD
Posté par cykl (Jabber id, ) le 15/03/2005 à 20:33. (lien). É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 Unixfix le Gaulois () le 15/03/2005 à 10:14. (lien). É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....
--
Slackware depuis 1996-
[^]Re: NetBSD
Posté par mdlh () le 15/03/2005 à 23:17. (lien). É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 symoon (page perso, ) le 15/03/2005 à 10:14. (lien). É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 eddine () le 15/03/2005 à 10:22. (lien). É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 herodiade () le 15/03/2005 à 21:38. (lien). É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 gallenza () le 15/03/2005 à 15:49. (lien). É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 PsychoFox () le 16/03/2005 à 08:03. (lien). É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 Mickaël L () le 16/03/2005 à 08:41. (lien). Évalué à 2.Je pense que debian n'est plus installable à partir d'une disquette..
-
[^]Re: NetBSD
Posté par PsychoFox () le 16/03/2005 à 10:10. (lien). Évalué à 6.ça me ferait mal ;)
Il ne suffit pas de penser, il faudrait peut-être vérifier :
disquettes de boot avec le nouvel installeur pour la Sarge
http://ftp.debian.org/debian/dists/testing/main/installer-i386/rc2/(...)
En alternative, on peut aussi graver un iso de 34.9 Mo (l'équivalent du D de 100Mo de NetBSD, sauf que celui de NetBSD n'est pas limité à une architecture).
Encore heureux qu'on puisse le faire.
-
-
[^]Re: NetBSD
Posté par gallenza () le 16/03/2005 à 14:16. (lien). É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?
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 demik () le 15/03/2005 à 12:44. (lien). É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 ragoutoutou () le 15/03/2005 à 15:48. (lien). É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é
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
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 Sylvain Briole (page perso, ) le 15/03/2005 à 11:16. (lien). É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 Thomas Hervé () le 15/03/2005 à 11:33. (lien). É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 Sylvain Briole (page perso, ) le 15/03/2005 à 11:52. (lien). É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 pix (page perso, ) le 15/03/2005 à 12:18. (lien). É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)--
La hiérarchie, c'est comme les étagères : plus c'est haut, moins ça sert.
-
-
[^]Re: Pourquoi pas
Posté par Sylvain Sauvage () le 16/03/2005 à 14:28. (lien). É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 totof2000 () le 15/03/2005 à 12:55. (lien). É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
-
On prend les mêmes et on recommence .....
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....
Slackware depuis 1996
-
[^]Re: On prend les mêmes et on recommence .....
Posté par wilk (Jabber id, page perso, ) le 15/03/2005 à 16:27. (lien). É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 Sylvain Briole (page perso, ) le 15/03/2005 à 16:44. (lien). É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 wilk (Jabber id, page perso, ) le 15/03/2005 à 17:15. (lien). É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 free2.org (page perso, ) le 15/03/2005 à 20:19. (lien). É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 eddine () le 15/03/2005 à 16:58. (lien). É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 herodiade () le 15/03/2005 à 22:18. (lien). É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 Arachne (page perso, ) le 16/03/2005 à 09:35. (lien). É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 wilk (Jabber id, page perso, ) le 16/03/2005 à 10:14. (lien). É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
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.