Rodrigo Fuentealba escribió: > Es por parte del desarrollo donde podría venir el "problema" (no es un > problema como tal, es más esfuerzo no más, y eso se nota). Por > ejemplo, ¿cuántas veces habrá ocurrido que "tal versión de tal > programa incorporado requiere tal biblioteca, pero en el repositorio > viene tal biblioteca que es anterior y que no funciona con este otro > programita por acá"?.
Por lo que entiendo, el tuyo es un planteamiento totalmente hipotético sin mayor asidero en la realidad. ¿Es así? Esta pregunta que planteas no tiene mayor importancia, porque lo que hace Debian es entregar un paquete para cada versión de la biblioteca. Así, si el programa X necesita "libfoo 4" y el programa Y necesita "libfoo 5", entonces X depende del paquete libfoo4, e Y depende de libfoo5. Ambos paquetes son distintos y separados, y se pueden instalar y desinstalar separadamente. De hecho, cuando sale una nueva versión de X, que ha sido actualizado para usar la libfoo5, entonces aptitude es suficientemente inteligente como para darse cuenta que ya no queda nada que use libfoo4 y la desinstala automáticamente. > Siendo tal la cantidad de paquetes y de desarrolladores detrás de > Debian, es un gasto enorme que todos sigan un lineamiento específico y > hay mayor cantidad de potenciales errores. No me queda claro si en esta oración hay realmente contenido. ¿Es ambiguo a propósito, o te falta especificar más la idea? > Es más fácil que haya cuatro o cinco faltas de ortografía en cien > palabras que en diez, asímismo es más fácil que haya cuatro o cinco > fallas de seguridad en 20000 paquetes que en 1200. No niego que Debian > se ha manejado bien en ese aspecto, pero ofrecer soporte a semejante > monstruo es como llevarse a una vaca en taxi: pocos se atreverían. Ahora estás hablando de fallas de seguridad, pero no era eso lo que habías planteado inicialmente. No digo que Debian esté libre de problemas de seguridad, ni que tenga el mejor tiempo de respuesta respecto a la publicación de paquetes con los hoyos corregidos, pero si quieres hacer ese argumento por favor no lo mezcles con lo de la actualizabilidad. La analogía con la vaca en taxi es bastante rebuscada por lo demás :-) ¿Tú dices que Redhat es como llevarse un cordero en taxi, en cambio Debian es como llevarse una vaca en taxi? Creo que para cualquiera de las dos operaciones habría que tener mucho coraje. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J "Puedes elegir el color de tu auto -- siempre y cuando sea negro." (Henry Ford) From [EMAIL PROTECTED] Sat Aug 25 19:14:14 2007 From: [EMAIL PROTECTED] (Jens Hardings) Date: Sat Aug 25 19:24:25 2007 Subject: CLCERT In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Fri, 2007-08-24 at 17:37 -0400, Daemon wrote: > Que lata, a propósito de todo la bulla que se armó con el "acuerdo" > entre Micro$oft y el gobierno, ahora me entero de que el CLCERT > también firmó un acuerdo de "cooperación" con Micro$oft...un acuerdo > con una entidad dedicada a la seguridad..con un SO inseguro por > naturaleza (si se que depende en gran medida del Sysadmin pero.....), > tal vez Jens nos pueda explicar en que consiste este acuerdo y el por > que de amarrarse de esta manera....cuando aprenderemos....no lo sé Contesto solamente porque salí aludido: no tengo relación alguna con el ClCERT más que participar como profesor en el diplomado de seguridad que organiza. Sí conozco bien a los responsables del ClCERT y se merecen mi mayor respeto. Sé que lo pensaron muy bien antes de firmar el acuerdo, sobre todo porque siempre es posible que se generen suspicacias. Pero tal como dice Alvaro, el acuerdo no es exclusivo ni genera amarres. Saludos, -- Jens
