Oui ils se la pètent.
C'est vrai que ça doit leur procurer beaucoup de plaisir de packager les logiciels à leur manière : tel bout de logiciel dans contrib ou non-free, tel autre dans main. Non, vraiment, je crois que tu as raison : ils ont du temps à perdre. Tant qu'à maintenir un paquet, autant que se soit le plus difficilement possible.

[ Répondre ]

Je m'inquiète pour Debian, elle est en train d'avoir une renommée d'intrégriste du libre, alors qu'elle ne fait que faire ce que les autres distros devraient faire.

Pas plus tard qu'aujourd'hui je n'ai pas pu accéder au man de gcc, parce que la GFDL ne respecte pas les chartes debian.
Ça commence à faire beaucoup, ça et l'histoire de icedove & iceweasel.
Alors oui c'est sûr la FSF ne va pas faire de procès à debian, même si elle garde la doc de gcc telle qu'elle, mais quand on veut du libre, il faut le faire strictement. Et comme debian est la seule à respecter vraiment le libre, elle passe pour une intégriste, d'où les réactions de 'buzz'.

[ Répondre ]

Je voudrais recentrer un peu mon journal.
La question principale que je me pose c'est : les distributions sont-elles sûres ?

(si oui ben ce journal est inutile désolé)

Je ne parle pas seulement des grosses distributions. J'ai l'impression que la sécurité est un frein à la création, par ex. si je décide de créer une nouvelle distribution, je pourrais toujours me débrouiller, si je fais des erreurs ce n'est pas très important, sauf au niveau de la sécurité (à moins d'avoir une distro qui n'a pas de version stable, toujours les derniers logiciels).
Moi ce que j'aimerais c'est décharger au maximum le poids que représente la préoccupation des failles.

[ Répondre ]

Non désolé.

[ Répondre ]

N'importe quoi pour la bonne raison que les patchs de sécurité *DOIVENT* être en updstream pour que tout le monde en profite.

Oui, mais si un logiciel est assez vieux (2 ans) est-ce que les développeurs upstream vont continuer à apporter des patchs (et surtout auditer le code pour trouver les failles) ?

Et ça c'est le ponpon

Je ne comprends pas ce que tu veux dire. Le truc ici, c'est de ne pas refaire le travail qui est fait en upstream, on peut imaginer au pif de choisir de maintenir le 2.6.11, 2.6.13, 2.6.15 ? à ben non là on va faire une entorse, vu que le 2.6.16 est maintenu pour un bon moment, 2.6.18.

En fait je ne pense pas vraiment aux grosses distrib qui ont les moyens de backporter et de suivre la sécurité, plutôt les "petites".
À la limite, pour les grosses disto, on peut imaginer qu'elles continuent comme elles ont toujours fait (en participant ou non), ensuite :
- elles peuvent très bien maintenir leurs versions + une version du "site", ce qui ne devraient pas prendre beaucoup plus de temps, d'une façon officielle ou non, et les clients choisissent ensuite leur version
- si au moment où elles passent en version stable leur version d'un logiciel est la même que celle du site, alors c'est tout bénèf pour elles. Sinon bah elles font comme d'hab.

Mais en fait si je me pose cette question c'est surtout par rapport aux alertes de sécurités, il me semble que ces alertes ne fournissent pas toujours le patch et ne concernent pas les versions trop anciennes non ?

Il y a autre chose aussi dont je n'ai pas parlé. Les distributions qui ont un long cycle, peuvent dire : "bon voilà nous on va maintenir le logiciel Y version X pendant tant de temps, donc si ça vous intéresse on va bosser dessus", et ainsi faire profiter les autres, qui à leur tour peuvent participer.

Enfin, ce que je veux dire, c'est qu'on peut imaginer des tas de choses, si une version du site va devenir trop vieille pour être maintenu, et qu'une distribution l'utilise toujours et est prête à la maintenir, ben ok on continue.

[ Répondre ]

Idem. Mais c'est pas spécifique à Debian : http://www.freedesktop.org/wiki/Software/gtk-qt

[ Répondre ]

Et il n'existe toujours pas sous linux de plateforme aussi cohérente et etendue que le sont .NET et Java.

Le triplet C, gcc,*utils /o\

[ Répondre ]

Est-ce que les développeurs linux peuvent récupérer ce travail ?

[ Répondre ]

Je crois que c'est grub-install /dev/hda

[ Répondre ]

Moi je trouve que le modèle économique de Mandriva est un des plus logiques, même si elle a peut être des difficultés.
Par contre l'offre proposée ne me paraît pas très clair, c'est assez difficile de trouver de la documentation (du moins à l'époque où j'étais sous Mandrake) et le site ne fait pas assez communautaire.
Ce qui "m'énerve" (en fait ça m'énerve pas, je ne trouve pas le mot), c'est les habitués de mandrake qui affirme que tout est clair, car sur ce point là, ils ne peuvent pas se mettre à la place d'un newbie. Alors peut être que le newbie est débile, mais peut être qu'il n'a pas tout à fait tort non plus.

[ Répondre ]

J'aimerais bien leur demander s'ils comptent faire de la « vraie » interopérabilité :
- spécifications des .doc
- spécifications de leurs différents systèmes de fichiers
- reconnaissance d'autres OS lors de l'installation de Windows
- etc...
(Ils font peut être déjà tout ça mais dans ce cas je ne vois pas ce qu'on leur reproche).

[ Répondre ]

de paquets vers la futur stable. Oui c'est ce que j'ai dit, j'ai oublié de préciser qu'ils étaient les seuls à pouvoir modifier les paquets *gelés* désolé.

[ Répondre ]

j'aimerai qu'on m'explique, parce que je comprend pas comment 2 (juste 2) dev vont pouvoir automagiquement régler plus de 300 bugs bloquant pour la release ? j'aimerai bien qu'on m'explique la méthode parce que ça pourrait intéresser beaucoup de monde. Je trouve que Dunc-Tank manque de transparence sur ce point.

Ben disons que le travail des mainteneurs ne change pas beaucoup pendant le passage de testing à stable. Je cite une courte phrase du livre de Raphaël Hertzog (j'espère que je vais pas aller en prison pour ça) :
Le Release Manager aura préalablement prononcé une période de freeze (gel), où il devra approuver chaque mise à jour de testing. Le but est d'empêcher toute nouvelle version (et ses nouveaux bogues) et de n'approuver que des mises à jours correctives.
Puis il explique que le release manager est le seul à pouvoir modifier les paquets.

Avec le nombre de paquets dans Debian, ça représente quand même du boulot.

[ Répondre ]

C'est intéressant ce que dit Mr. Mark. Ce qu'il faut retenir de ce blog ce n'est pas qu'Ubuntu ne pourrait pas exister sans Debian.

En gros il explique que Debian a de multiple buts, ou plutôt qu'elle n'a pas de but précis (faut il faire une distrib très stable orientée serveur ou plutôt orientée utilisateur). Ce qui au final attise les tensions entre développeurs et empêche de se concentrer uniquement sur la technique, contrairement à Ubuntu qui sait parfaitement où elle va.

PS : Je crois que le blog de Matthew Garret dont fait allusion Mark Shutt* est :
http://mjg59.livejournal.com/66647.html

[ Répondre ]

hum pardon je suis à côté de la plaque /o\

[ Répondre ]

sous debian :

ciol13@debian:~$ make -v
GNU Make 3.80

c'est pas gmake ?

[ Répondre ]