Python tiene sus pros y sus contras, pero, no obstante, se usa mucho. Por ejemplo, Python se usa con frecuencia en tareas de procesamiento de datos, incluso cuando hay lenguajes m\u00e1s apropiados para elegir.<\/p>\n
\u00bfPor qu\u00e9? Bueno, Python es relativamente f\u00e1cil de aprender. Alguien con experiencia en ciencias puede aprender Python mucho m\u00e1s r\u00e1pido que, digamos, C. Sin embargo, la accesibilidad inherente de Python tambi\u00e9n crea un par de problemas.<\/p>\n
Cada vez que se actualiza Python, significa una gran carga de trabajo de refactorizaci\u00f3n, que a menudo se trata mal, o no se trata en absoluto. Eso conduce a un bajo rendimiento y vulnerabilidades de seguridad. Pero tal vez haya una mejor manera: una herramienta para mantener sus tareas de Python funcionando sin problemas y de forma segura d\u00eda tras d\u00eda. Vamos a ver.<\/p>\n
Es lento, pero hace el trabajo<\/strong><\/h2>\nPython no es el lenguaje m\u00e1s r\u00e1pido que existe, pero a pesar de sus desventajas comparativas, a menudo ver\u00e1 que se usa para operaciones intensivas de procesamiento de datos. Piense en el aprendizaje autom\u00e1tico, la visi\u00f3n artificial o incluso en las matem\u00e1ticas puras en los sistemas inform\u00e1ticos de alto rendimiento (HPC).<\/p>\n
Entonces, a pesar de su reputaci\u00f3n de rendimiento, las cargas de trabajo muy dif\u00edciles se manejan com\u00fanmente con el c\u00f3digo Python, simplemente porque es muy pr\u00e1ctico de usar. Si tiene experiencia en ciencias o matem\u00e1ticas, puede aprender Python con relativa facilidad y producir su propio c\u00f3digo que har\u00e1 el trabajo.<\/p>\n
Pero, como suele ser el caso, algo que es accesible tambi\u00e9n puede crear muchos riesgos. Los programadores sin experiencia que escriben c\u00f3digo Python pueden tener problemas con tareas que los programadores m\u00e1s experimentados dan por hecho.<\/p>\n
La refactorizaci\u00f3n es una molestia\u2026 y un riesgo<\/strong><\/h2>\nComo todos los lenguajes de programaci\u00f3n, Python pasa por actualizaciones frecuentes. El cambio de Python 2.7 a Python 3.0, por ejemplo, trajo un mont\u00f3n de funciones y mejoras. Tambi\u00e9n significa que cualquier cosa escrita para Python 2.7 debe “refactorizarse” para Python 3.0 debido a los cambios en el funcionamiento de Python.<\/p>\n
La refactorizaci\u00f3n se refiere a la forma en que los programadores ajustan una base de c\u00f3digo para responder a los cambios ambientales, como un cambio en la versi\u00f3n del lenguaje, o simplemente para mejorar el c\u00f3digo existente de alguna forma. Sin la refactorizaci\u00f3n, un cambio de Python 2.7 a Python 3.0 a menudo significa que el c\u00f3digo de Python 2.7 ya no funciona tan bien, o incluso deja de funcionar.<\/p>\n
Y aqu\u00ed est\u00e1 el problema: es posible que los usuarios que escribieron el c\u00f3digo original de Python no tengan la experiencia para refactorizar. Despu\u00e9s de todo, a menudo son cient\u00edficos y no programadores experimentados. Cuando los programadores sin experiencia intentan ajustar el c\u00f3digo, existe un riesgo real de que el rendimiento se degrade y de que aparezcan errores, a veces solo visibles cuando aparece un caso extremo. Los errores peque\u00f1os se convierten en una preocupaci\u00f3n importante cuando el c\u00f3digo de Python se usa para fines cr\u00edticos las 24 horas del d\u00eda, los 7 d\u00edas de la semana, como el an\u00e1lisis cient\u00edfico.<\/p>\n
La refactorizaci\u00f3n tambi\u00e9n puede conducir a una degradaci\u00f3n inesperada del rendimiento. Incluso si solo se trata de un impacto del 5 % en el rendimiento, una actualizaci\u00f3n de c\u00f3digo mal ejecutada puede crear r\u00e1pidamente facturas mucho m\u00e1s altas en costosas plataformas HPC de pago por uso.<\/p>\n
\u00bfApegarse al viejo Python? Ese es un riesgo a\u00fan mayor.<\/strong><\/h2>\nSi piensa en el arduo trabajo y los riesgos que implica ajustar el c\u00f3digo, no sorprende que los usuarios a menudo opten por apegarse a las versiones anteriores de Python. Ejecutar el c\u00f3digo existente en una versi\u00f3n desactualizada de Python evita muchos desaf\u00edos porque no necesita refactorizar: est\u00e1 manteniendo su c\u00f3digo tal como estaba.<\/p>\n
Por lo general, los proveedores de software har\u00e1n exactamente eso: solo actualizar\u00e1n su software para que coincida con una nueva versi\u00f3n de Python cuando lancen una nueva versi\u00f3n del producto de software. Si compr\u00f3 una versi\u00f3n espec\u00edfica, que se ejecuta en, por ejemplo, Python 2.7, est\u00e1 atascado y necesita continuar ejecutando Python 2.7 sin importar qu\u00e9.<\/p>\n
No parece un gran problema, pero confiar en bloques de construcci\u00f3n obsoletos y sin soporte para su computaci\u00f3n es una pesadilla para DevSecOps. Aparecer\u00e1n nuevas vulnerabilidades y los parches necesarios simplemente no llegar\u00e1n. Confiar en versiones antiguas de lenguajes de programaci\u00f3n, por lo tanto, introduce grandes riesgos en su entorno inform\u00e1tico.<\/p>\n
Hay pocas opciones en \u00e9l, \u00bfo s\u00ed?<\/strong><\/h2>\nLo m\u00e1s responsable es actualizar la versi\u00f3n de Python cuando sea necesario y editar el c\u00f3digo que se ejecuta en ella, pero no hay una forma indolora de hacerlo. Siendo realistas, debido a la falta de recursos, la refactorizaci\u00f3n a menudo no se realiza, con consecuencias potencialmente costosas.<\/p>\n
Hay una gran necesidad de un mejor enfoque, y esto es lo que es interesante. La situaci\u00f3n que acabamos de describir en torno a las versiones de Python se ve con frecuencia en el mundo de la inform\u00e1tica. Por ejemplo, es com\u00fan que las organizaciones ejecuten versiones del sistema operativo Linux que ya no est\u00e1n cubiertas por el soporte oficial del proveedor, asumiendo el riesgo de que las vulnerabilidades de seguridad no se corrijan. solo para asegurarse de que las aplicaciones cr\u00edticas no se rompan<\/em>.<\/p>\nEse es un problema para las actualizaciones de idioma, as\u00ed como tambi\u00e9n para otras piezas de la infraestructura de TI. Pero, en los \u00faltimos a\u00f1os, las soluciones de parches avanzadas permiten a las empresas extender el ciclo de vida de soporte habitual para m\u00faltiples componentes, desde sistemas operativos completos hasta bibliotecas compartidas cr\u00edticas espec\u00edficas. Aqu\u00ed en TuxCare, hemos desarrollado varias soluciones que extienden la operaci\u00f3n segura del software antiguo m\u00e1s all\u00e1 del final de la vida \u00fatil del proveedor.<\/p>\n
Ejecuci\u00f3n de aplicaciones antiguas de Python de forma segura<\/strong><\/h2>\n\u00bfQu\u00e9 pasar\u00eda si se pudiera hacer lo mismo con las versiones de idiomas? Bueno, ahora puede esperar ejecutar su antiguo c\u00f3digo de Python en una versi\u00f3n antigua de Python, pero sin los riesgos que implica. No hay construcciones de lenguaje en desuso, ni tampoco vulnerabilidades.<\/p>\n
En otras palabras, el soporte de ciclo de vida extendido para versiones de lenguaje, como Python, se est\u00e1 convirtiendo en una realidad. Pronto podr\u00e1 mantener su c\u00f3digo de Python seguro y protegido sin la necesidad de volver a escribir una sola l\u00ednea de c\u00f3digo, simplemente obteniendo soporte de ciclo de vida extendido para Python, lo que le brinda la misma protecci\u00f3n de seguridad que una actualizaci\u00f3n de la versi\u00f3n completa.<\/p>\n
Programado para implementarse a precios accesibles, el soporte de ciclo de vida extendido de Python de TuxCare ayudar\u00e1 a su organizaci\u00f3n a lidiar con las preguntas dif\u00edciles sobre las cargas de trabajo antiguas de Python. Est\u00e9 atento a nuestro anuncio, que llegar\u00e1 pronto. <\/p>\n
<\/p>\n<\/div>\n
Como todos los lenguajes de programaci\u00f3n, Python pasa por actualizaciones frecuentes. El cambio de Python 2.7 a Python 3.0, por ejemplo, trajo un mont\u00f3n de funciones y mejoras. Tambi\u00e9n significa que cualquier cosa escrita para Python 2.7 debe “refactorizarse” para Python 3.0 debido a los cambios en el funcionamiento de Python.<\/p>\n
La refactorizaci\u00f3n se refiere a la forma en que los programadores ajustan una base de c\u00f3digo para responder a los cambios ambientales, como un cambio en la versi\u00f3n del lenguaje, o simplemente para mejorar el c\u00f3digo existente de alguna forma. Sin la refactorizaci\u00f3n, un cambio de Python 2.7 a Python 3.0 a menudo significa que el c\u00f3digo de Python 2.7 ya no funciona tan bien, o incluso deja de funcionar.<\/p>\n
Y aqu\u00ed est\u00e1 el problema: es posible que los usuarios que escribieron el c\u00f3digo original de Python no tengan la experiencia para refactorizar. Despu\u00e9s de todo, a menudo son cient\u00edficos y no programadores experimentados. Cuando los programadores sin experiencia intentan ajustar el c\u00f3digo, existe un riesgo real de que el rendimiento se degrade y de que aparezcan errores, a veces solo visibles cuando aparece un caso extremo. Los errores peque\u00f1os se convierten en una preocupaci\u00f3n importante cuando el c\u00f3digo de Python se usa para fines cr\u00edticos las 24 horas del d\u00eda, los 7 d\u00edas de la semana, como el an\u00e1lisis cient\u00edfico.<\/p>\n
La refactorizaci\u00f3n tambi\u00e9n puede conducir a una degradaci\u00f3n inesperada del rendimiento. Incluso si solo se trata de un impacto del 5 % en el rendimiento, una actualizaci\u00f3n de c\u00f3digo mal ejecutada puede crear r\u00e1pidamente facturas mucho m\u00e1s altas en costosas plataformas HPC de pago por uso.<\/p>\n
\u00bfApegarse al viejo Python? Ese es un riesgo a\u00fan mayor.<\/strong><\/h2>\nSi piensa en el arduo trabajo y los riesgos que implica ajustar el c\u00f3digo, no sorprende que los usuarios a menudo opten por apegarse a las versiones anteriores de Python. Ejecutar el c\u00f3digo existente en una versi\u00f3n desactualizada de Python evita muchos desaf\u00edos porque no necesita refactorizar: est\u00e1 manteniendo su c\u00f3digo tal como estaba.<\/p>\n
Por lo general, los proveedores de software har\u00e1n exactamente eso: solo actualizar\u00e1n su software para que coincida con una nueva versi\u00f3n de Python cuando lancen una nueva versi\u00f3n del producto de software. Si compr\u00f3 una versi\u00f3n espec\u00edfica, que se ejecuta en, por ejemplo, Python 2.7, est\u00e1 atascado y necesita continuar ejecutando Python 2.7 sin importar qu\u00e9.<\/p>\n
No parece un gran problema, pero confiar en bloques de construcci\u00f3n obsoletos y sin soporte para su computaci\u00f3n es una pesadilla para DevSecOps. Aparecer\u00e1n nuevas vulnerabilidades y los parches necesarios simplemente no llegar\u00e1n. Confiar en versiones antiguas de lenguajes de programaci\u00f3n, por lo tanto, introduce grandes riesgos en su entorno inform\u00e1tico.<\/p>\n
Hay pocas opciones en \u00e9l, \u00bfo s\u00ed?<\/strong><\/h2>\nLo m\u00e1s responsable es actualizar la versi\u00f3n de Python cuando sea necesario y editar el c\u00f3digo que se ejecuta en ella, pero no hay una forma indolora de hacerlo. Siendo realistas, debido a la falta de recursos, la refactorizaci\u00f3n a menudo no se realiza, con consecuencias potencialmente costosas.<\/p>\n
Hay una gran necesidad de un mejor enfoque, y esto es lo que es interesante. La situaci\u00f3n que acabamos de describir en torno a las versiones de Python se ve con frecuencia en el mundo de la inform\u00e1tica. Por ejemplo, es com\u00fan que las organizaciones ejecuten versiones del sistema operativo Linux que ya no est\u00e1n cubiertas por el soporte oficial del proveedor, asumiendo el riesgo de que las vulnerabilidades de seguridad no se corrijan. solo para asegurarse de que las aplicaciones cr\u00edticas no se rompan<\/em>.<\/p>\nEse es un problema para las actualizaciones de idioma, as\u00ed como tambi\u00e9n para otras piezas de la infraestructura de TI. Pero, en los \u00faltimos a\u00f1os, las soluciones de parches avanzadas permiten a las empresas extender el ciclo de vida de soporte habitual para m\u00faltiples componentes, desde sistemas operativos completos hasta bibliotecas compartidas cr\u00edticas espec\u00edficas. Aqu\u00ed en TuxCare, hemos desarrollado varias soluciones que extienden la operaci\u00f3n segura del software antiguo m\u00e1s all\u00e1 del final de la vida \u00fatil del proveedor.<\/p>\n
Ejecuci\u00f3n de aplicaciones antiguas de Python de forma segura<\/strong><\/h2>\n\u00bfQu\u00e9 pasar\u00eda si se pudiera hacer lo mismo con las versiones de idiomas? Bueno, ahora puede esperar ejecutar su antiguo c\u00f3digo de Python en una versi\u00f3n antigua de Python, pero sin los riesgos que implica. No hay construcciones de lenguaje en desuso, ni tampoco vulnerabilidades.<\/p>\n
En otras palabras, el soporte de ciclo de vida extendido para versiones de lenguaje, como Python, se est\u00e1 convirtiendo en una realidad. Pronto podr\u00e1 mantener su c\u00f3digo de Python seguro y protegido sin la necesidad de volver a escribir una sola l\u00ednea de c\u00f3digo, simplemente obteniendo soporte de ciclo de vida extendido para Python, lo que le brinda la misma protecci\u00f3n de seguridad que una actualizaci\u00f3n de la versi\u00f3n completa.<\/p>\n
Programado para implementarse a precios accesibles, el soporte de ciclo de vida extendido de Python de TuxCare ayudar\u00e1 a su organizaci\u00f3n a lidiar con las preguntas dif\u00edciles sobre las cargas de trabajo antiguas de Python. Est\u00e9 atento a nuestro anuncio, que llegar\u00e1 pronto. <\/p>\n
<\/p>\n<\/div>\n
Lo m\u00e1s responsable es actualizar la versi\u00f3n de Python cuando sea necesario y editar el c\u00f3digo que se ejecuta en ella, pero no hay una forma indolora de hacerlo. Siendo realistas, debido a la falta de recursos, la refactorizaci\u00f3n a menudo no se realiza, con consecuencias potencialmente costosas.<\/p>\n
Hay una gran necesidad de un mejor enfoque, y esto es lo que es interesante. La situaci\u00f3n que acabamos de describir en torno a las versiones de Python se ve con frecuencia en el mundo de la inform\u00e1tica. Por ejemplo, es com\u00fan que las organizaciones ejecuten versiones del sistema operativo Linux que ya no est\u00e1n cubiertas por el soporte oficial del proveedor, asumiendo el riesgo de que las vulnerabilidades de seguridad no se corrijan. solo para asegurarse de que las aplicaciones cr\u00edticas no se rompan<\/em>.<\/p>\n Ese es un problema para las actualizaciones de idioma, as\u00ed como tambi\u00e9n para otras piezas de la infraestructura de TI. Pero, en los \u00faltimos a\u00f1os, las soluciones de parches avanzadas permiten a las empresas extender el ciclo de vida de soporte habitual para m\u00faltiples componentes, desde sistemas operativos completos hasta bibliotecas compartidas cr\u00edticas espec\u00edficas. Aqu\u00ed en TuxCare, hemos desarrollado varias soluciones que extienden la operaci\u00f3n segura del software antiguo m\u00e1s all\u00e1 del final de la vida \u00fatil del proveedor.<\/p>\n \u00bfQu\u00e9 pasar\u00eda si se pudiera hacer lo mismo con las versiones de idiomas? Bueno, ahora puede esperar ejecutar su antiguo c\u00f3digo de Python en una versi\u00f3n antigua de Python, pero sin los riesgos que implica. No hay construcciones de lenguaje en desuso, ni tampoco vulnerabilidades.<\/p>\n En otras palabras, el soporte de ciclo de vida extendido para versiones de lenguaje, como Python, se est\u00e1 convirtiendo en una realidad. Pronto podr\u00e1 mantener su c\u00f3digo de Python seguro y protegido sin la necesidad de volver a escribir una sola l\u00ednea de c\u00f3digo, simplemente obteniendo soporte de ciclo de vida extendido para Python, lo que le brinda la misma protecci\u00f3n de seguridad que una actualizaci\u00f3n de la versi\u00f3n completa.<\/p>\n Programado para implementarse a precios accesibles, el soporte de ciclo de vida extendido de Python de TuxCare ayudar\u00e1 a su organizaci\u00f3n a lidiar con las preguntas dif\u00edciles sobre las cargas de trabajo antiguas de Python. Est\u00e9 atento a nuestro anuncio, que llegar\u00e1 pronto. <\/p>\n <\/p>\n<\/div>\nEjecuci\u00f3n de aplicaciones antiguas de Python de forma segura<\/strong><\/h2>\n