[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]On Tue, 2004-02-24 at 09:22, Sandino Araico Sanchez wrote: > Leonel Nunez wrote: > > > > >>>>>lo mismo con php si estoy > >>>>>desarrollando para php 4.2.2 no me obliguen a brincar a la 5.0 > >>>>> > >>>>> > >>>>> > >>4.2.2 y 5 están en diferentes slots. Pero es estúpido estar usando PHP > >>4.2.2 cuando esa versión ya no es mantenida porque la actual es 4.3.4 y > >>es completamente compatible con todas las anteriores hasta 4.0. > >> > >> > >> > > > >de plano > > > > > > > >>>>>con > >>>>>todos sus cambios que obligan a modificar codigo y probar la estabilidad > >>>>>de los paquetes nuevos. > >>>>> > >>>>> > >>>>> > >>los cambios de PHP 4.2.2 a 4.3.4 no te obligan de ninguna manera a > >>cambiar tu código, sólamente tienes que tener tu php.ini bién > >>configurado con register_globals activado y no hay ningún problema. Todo > >>programador de PHP que visite www.php.net seguido lo sabría. > >> > >> > >> > > > >claro ! pero que tan seguro es ? > > > > > Si tu aplicación es crítica tienes servidores de prestaging donde > pruebas todo lo que se pueda romper y un protocolo de pruebas que un > tercero fue desarrollando en paralelo con tu aplicación, así que > cualquier cambi es seguro... > Si tu aplicación es normal pues nada más debes tener cuidado con los > avisos de actualización de configuraciones que venían en On por default > y ahora vienen en Off. > > >no seria recomendable cambiar de global a $_GLOBALS ? y que implica ? > > > > > Siempre es mejor estar al día y CVS es tu amigo. > Claro > >cambios en tu sistema desarrollado > > > >Cuanto cuesta ese cambio ? > > > > > Depende de qué tan modular sea tu sistema unos cuentos de dólares o > decenas de miles > > >Cuando digo sistema no es una paginita de 10 scripts son aplicaciones > >grandes no juguetes. no nukes. > > > > > Si, unos cientos de dólares, programas tus módulos exprofeso para que > sean mantenibles. > > >Ve el costo beneficio de estar moviendo y moviendo tu aplicacion. > > > > > > > > > >>Estabilidad si, pero no al costo de la obsolecencia. > >> > >> > > > >Define obsolecencia ? y los paquetes VIEJOS no necesariamente son > >obsoletos. > > > Cuando un paquete viejo ya nadie lo mantiene y hay una versión nueva o > un paquete distinto con la funcionalidad que necesitas el paquete viejo > es obsoleto. > > > > > > >>>veamos : > >>> > >>>tengo muchas versiones de perl a que padre a que chido. Inutil > >>>totalmente PARA MIS PROPOSITOS. > >>> > >>> > >>> > >>> > >>Para mis propósitos es estúpido tener un Perl 5.6 cuando Perl 5.8 es > >>compatible hacia atrás y me permite usar módulos nuevos que tienen > >>dependencia de 5.8. > >> > >> > > > > > >Aaaa bendita estupides que no tengo que reinstalar perl 5.8 y sus > >dependencias en todos mis servidores. si con 5.6 funciona , no es > >obsoleto y esta chido > > > >Claro tambien uso perl 5.8 y mis aplicaciones corren desde 5.6 a 5.8 > >sin modificaciones pero mi plataforma de produccion es Debian y debian > >trae 5.6 asi que solo > > > >Instalo en mis servers y no tengo que reinstalar y reinstalar y > >reinstalar por estar "on the edge" > > > Yo también he tenido servidores con Linux PPP 6.4 corriendo un liveice > última versión las 24 horas pero ese no es un uso general.... > > > > >Seria bueno que comentaras tus experiencias con aplicaciones y > >servidores criticos asi como tu metodo de actualizar tus aplicaciones > >cuando migras de version de paquete > > > > > > > 1. Machupichu y TV con Linux PPP 6.4 > 1.1 Edité /etc/redhat-release > 1.2 Cerré todos los servicios > 1.3 Instalé Red Carpet 1 > 1.4 Actualicé paquetes > 1.5 Recompilé OpenSSL y OpenSSH y los instalé en /usr/local > 1.6 Desinstalé el OpenSSH y el OpenSSL originales > 1.7 Reinstalé el OpenSSH y OpenSSL nuevos > 1.8 Instalé Liveice y lo heché a volar > 1.9 No volví a visitar esas máquina más que para hacer > actualizaciones de OpenSSH, OpenSSL o con Red Carpet > 1.10 La última vez que las vi llevaban unos 2 años trabajando > solitas sin parar > 1.11 Siguen con Linux PPP 6.4 > > 2. Huitzilopochtli con Red Hat 7.1 > 2.1 Recompilé el kernel > 2.2 Copié el directorio /usr/local del servidor anterior > 2.3 Copié los sitios y las basews de datos del servidor anterior > 2.4 Desde el DNS moví los sitios al servidor nuevo, nadie se enteró, > la operación no se interrumpió > 2.5 Lo usé durante varios meses > 2.6 Instalé Red Carpet > 2.7 Usé Red Carpet variuos meses para instalar paquetes > 2.8 Actualicé a Red Hat 7.2 con Red Carpet (Cero downtime) > 2.8.1 Instalé el paquete redhat-release de Red Hat 7.2 > 2.8.2 Suscribí mi Red Carpet al nuevo canal redhat-7.2 > 2.8.3 Actualicé Glibc > 2.8.4 Actualicé el resto de los paquetes en grupos de 20 > 2.8.5 Reinicié Sendmail y teapop > 2.8.6 Todo lo demás siguió corriendo como si nada > 2.8.7 Para OpenSSH y OpenSSL instalé los paquetes a pata con rpm > -Uvh --justdb > 2.9 Actualicé a Red Hat 7.3 con Red Carpet (cero downtime) > 2.10 Todo ese tiempo actualicé mis paquetes de /usr/local a pata > desde código fuente (última versión estable) > > 3. Guadalupe Reyes con Red Hat 7.3 > 3.1 Parecido a Huitzilopochtli pero usé Red Carpet 2 para actualizar > a Red Hat 8.0 > 3.2 Luego actualicé a Red Hat 9 > 3.3 Sólamente tuve que reiniciar Sendmail, Teapop, Bind y Samba > Y tu experiencia con aplicaciones desarrolladas por ti ? Entiendase aplicaciones no scriptcillos mi punto toda esta discucion ha sido en relacion a: DESARROLLO DE APLICACIONES. No al uso de linux como servidor > > > > > >>>Mi aplicacion necesita las caracteristicas de PERL 5.6.1 no de 5.8.3 > >>> > >>> > >>> > >>> > >>Tu aplicación tiene un espantoso problema de portabilidad. > >> > >> > >> > > > >No mi chato estas pero mal mal desarrolle para perl 5.6.1 y esta > >probado que funciona con 5.8.3 asi para que migrar TODOS los servers y > >no son menos de 5. > > > Entonces contradices eso de que necesita las características de Perl > 5.6.1 y no de 5.8.3 porque ambos te sirven. > es muy distinto si funciona en ambos porque no tengo nada especifico a 5.8 > > > >>Porque eres un irresponsable que ya no quiere mantener sus propias > >>aplicaciones. > >> > >> > >> > > > > > >Entiende ! POR CAMBIOS DE VERSIONES EN LOS PAQUETES > > > >Porque trabajar en algo que no es necesario ? No me pagan por eso. > > > >Es mas irresponsable poner en produccion cosas que no han sido probadas > > > >Por ejemplo > > > >YO No recomiendo AUN el kernel 2.6 porque ? no por flojera ni > >irresponsabilidad > > > ¿Y conoces alguna distro que lo recomiende para producción? al kernel 2.6 No veo ninguna distro que lo recomiende si fedora lo va a traer pero a fedora no la recomiendo para server Debian Sid lo trae y tampoco lo recomiendo para servidor en produccion > > > > >Es un kernel muy muy nuevo y si en mi casa jala bien no lo recomiendo > >para produccion > > > >presisamente por RESPONSABILIDAD. > > > Habría algunos casos en que yo podría recomendar Linux 2.6 para > producción, pero son muy específicos y los contaría con los dedos de mi > mano izquierda. > > >>>Los que han desarrollado aplicaciones criticas saben a lo que me > >>>refiero. > >>> > >>> > >>> > >>> > >>> > >>Para eso existen dos inventos: > >>1. Prestaging > >>y > >>2. Protocolo de validación > >> > >>Y los que han desarrollado aplicaciones críticas saben que deben tener > >>contempladoa procedimientos de actualización, de migración y de > >>contingencia. > >> > >> > >> > > > > > > > >Eso lo tengo previsto y no le saco al jale. > > > Por fin decídete, ¿actualizas o no actualizas? > Actualizo cuando es necesario. > > > > > > > > > > -- ,''`. Leonel Nunez : :' : http://enelserver.com `. `' DEBIAN GNU/LINUX `- A REAL FREE OS _______________________________________________ Ayuda mailing list Ayuda en linux org mx Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/