Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de fabiensk :
- [12/04@17:53] Marre du matériel défaillant
- [05/04@19:54] linuxfr, privoxy et boucle infinie
- [26/03@22:08] Recherche de CMS pour base de connaissance sur intranet
> Lire le journal (11 commentaires, moyenne: 1,2).
Re: Rapidité de patch et packages
La plupart des distribs offrent un nouveau paquet dès lors que les failles importantes sont découvertes et qu'un correctif est dispo.
A priori, à moins d'être admin à plein temps, les gens de la distrib vont faire le paquet plus vite. Et si l'on est admin à plein temps et que l'on doit faire les paquets, pourquoi ne pas directement contribuer aux paquets des distribs (debian en particulier, qui permet cela), plutot que faire son paquet de coté ?
-
[^]Re: Rapidité de patch et packages
Posté par Tennis Prono (page perso, ) le 19/05/2003 à 14:04. (lien). Évalué à 1.Si j'ai bien compris, tu confirmes que le délai "de 50 jours pour des distribs dont je ne peux pas dire le nom" est du FUD total :-)
--
Pas de bureau 3d libre sans drivers libres!-
[^]Re: Rapidité de patch et packages
Posté par sobek () le 19/05/2003 à 14:14. (lien). Évalué à 1.Bien sûr. Enfin, au moins en ce qui concerne les principales applications.
Maintenant, il y a sans doute de petits programme, gérés par une ou deux personnes tout au plus et pour lesquelles la correction d'un débordement de buffert peut prendre plus de temps.
De toute façon, tant que les pontes de M$ compareront pour ce genre de statistique un OS, certe évolué, d'un coté et une distrib complète (parfois 7 CDs) de l'autre, ce genre de FUD ne peut pas être pris au sérieux... Allez, dites-moi que ce n'est pas possible... Si ?
:-)-
[^]Re: Rapidité de patch et packages
Posté par Tennis Prono (page perso, ) le 19/05/2003 à 21:03. (lien). Évalué à 1.Là ils parlaient surtout de programme comme apache, sendmail, bind, proftpd...
--
Pas de bureau 3d libre sans drivers libres!
-
-
[^]Re: Rapidité de patch et packages
Posté par Pascal Terjan (Jabber id, page perso, ) le 19/05/2003 à 14:38. (lien). Évalué à 1.Heu il se peut qu'il y ait des distribs pourries aussi hein.
Parmi les centaines de distribs il doit y en avoir des pas trop maintenues.
-
Re: Rapidité de patch et packages
C'est pour cela que je disais dernièrement que pour moi le mécanisme des ports BSD était plus efficace que le système des paquets type rpm ou même deb. Ils permettent en effet (enfin, c'est mon avis) une très bonne gestion des configurations mixtes installation par ports / compilations à la main.
Gentoo c'est récemment (tout est relatif) inspiré de ce mécanisme et c'est tant mieux pour Linux...
Re: Rapidité de patch et packages
Cela signifie-t-il qu'il faut oublier les systèmes de packages ? Pour info si tu utilises le système de gestion de packages RPM, tu peux utiliser checkinstall pour garder la cohérence de la base rpm tout en utilisant des programmes que tu compile -au lieu de make install, en root, tu tape checkinstall, cela t'installera le packet, créera les paquets rpm et src.rpm -le programme te propose un nom en fonction du nom du répertoire mére des sources -tu peux modifier pour que cela remplace bien le programme déjà installer- et si tu a bien penser lors du configure de mettre --prefix=/le/rep/qui/va/ien (en général /usr au lieu de /usr/local par défaut, car les paquets rpm de distrib se mettent plutôt dans usr- tu as rapidement la mise à jour, en onservant l'homogénéité de ta base RPM, et de plus tu peux envoyer les rpm et src.rpm généré à ta distrib pour qu'ils le mettent à jour plusrapidement, c ceux que je fais -sauf pour des progs pas forcément intéressant pur bcp de monde-
-
[^]Re: Rapidité de patch et packages
Posté par kaouete (page perso, ) le 19/05/2003 à 15:47. (lien). Évalué à 1.oui, et il existe le meme genre d'outils sous debian. De plus, il y a une source debian specialement dediée a ce genre de mis a jour, (security.debian.org . .. pour woody et testing)tandis qu'en sid, le packet est directement mis a jour dedans, le jour meme ou la faille a ete decouverte (pour les grosses qui risquent de toucher du monde hin :)
-
[^]Re: Rapidité de patch et packages
Posté par imalip (page perso, ) le 19/05/2003 à 17:09. (lien). Évalué à 1.Hmmmm..... Pour autant que je sache, security est en principe seulement destine a la stable. Bien sur, si les versions "stable" et "testing" sont les meme, la mise a jour sur security se fera... De toute facon, en cas d'alerte de securite, il suffit de regarder la page idoine sur debian.og pour etre informe de son impact sur les differents niveaux de release.
--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
Probléme de mises à jour
En fait, je me demande comment font les industriels pour par craquer avec leur mise a jour de serveur.
Un particulier en a rien a foutre, mais pour un industriel serieux, le moindre chagement de soft sur un serveur entraine un serie de test+validation. Mais comment font-ils?
\_°< C01N C01N ! >°_/
-
[^]Re: Probléme de mises à jour
Posté par Éric (Jabber id, page perso, ) le 19/05/2003 à 22:16. (lien). Évalué à 1.> Mais comment font-ils?
Ils délèguent la phase de test+validation à une boite externe dans laquelle ils ont confiance.
Ca ne les empeche pas de le faire aussi chez eux, mais en tres rapide.
Et la boite externe en question c'est probablement souvent ... l'éditeur du logiciel (ou de la distrib).
Apres vient peut etre la réflexion qu'il vaut mieux risquer un bug hypotétique qu'une faille de sécu réelle et connue
Cette page a été générée par Templeet en 0.0713s (dont 0.0067 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.