Portada
mis comunidades
otras secciones
#1:
Meneo porque esto es la sentencia de muerte para muchas aplicaciones desarrolladas por y para la administración pública. El post al que se hace referencia está en: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free
#28:
#24 Vamos a ver, hablamos de un lenguaje de programación sobre el cual la Administración ha desarrollado una serie de aplicaciones, no de un sistema operativo o de máquinas muy viejas que no puedan hacer determinadas operaciones o soportar una determinada carga de trabajo y deban ser actualizadas.
Está claro que aparecen fallos y las versiones evolucionan. Todo funciona así.
Ahora bien, si hubieran utilizado un lenguaje de programación verdaderamente libre, véase C++, Python, Ruby, PHP... para hacer lo puto mismo en lugar de atarse a tecnologías propietarias dependientes de los deseos de una multinacional (es decir: dependientes de que esa multinacional gane cuantos más millones al año mejor, cosa totalmente lógica) estas historias no pasarían y se podrían gestionar con mayor naturalidad y menor riesgo y menor coste que el de "vamos a morir todos porque Microsoft/Oracle/Apple el año que viene va a dejar de soportar TODO lo que hemos hecho hasta ahora".
Es por eso que precisamente las megaempresas de teleco y de la web tienen por norma general la costumbre de NO usar software privativo (tanto que les gusta el capitalismo y tan bueno y cojonudo que es) y por eso cuando trabajas por ejemplo como ingeniero de sistemas en Ericsson gestionando nodos de comunicaciones móviles que dan servicio a millones de usuarios sólo ves sistemas operativos GPL/BSD y aplicaciones desarrolladas en lenguajes libres. Y es que las empresas, al final, saben cómo hacer para no gastar al año 7 millones de euros en licencias de mierda para usar productos de otras empresas.
Esas empresas, por poner un ejemplo que conozco en primera persona, utilizaron en su día Python 2 para desarrollar sus aplicaciones. Python 3 no es compatible con Python 2, pero Python 2 continúa siendo mantenido y sus errores y fallas de seguridad, cuando los hay, corregidos. Y tu software de hace 10 años continúa siendo válido hoy y lo será dentro de 5 años más. Eso mismo no te lo puedes esperar de Oracle o Microsoft, que vive de cobrarte dinero por usar sus productos y si te mantienes con una sola licencia 20 años, dejan de ingresar pasta y sus acciones bajan. Así que si quieres que tus aplicaciones sigan funcionando, pues renuevas la licencia para poder bajarte los parches de este error, este y este otro. O mejor aún: te compras la licencia nueva para la siguiente versión, porque ese error tan grave no lo vamos a arreglar en la versión que tú usas porque "ha quedado anticuada".
Y sí, por mucho que te vengan los "informáticos" a decirte que "las Cosas Serias ® se hacen con GWuindol y con Oracle", la realidad es que los 100 millones de usuarios de Instagram subiendo fotos como cabrones 24/7 son gestionados por PostgreSQL y por el puto Django (Python), todo sistemas 100% libres. Y sí, Instagram tiene muchísima más carga de trabajo continua de la que jamás tendrá una asquerosa web de la Administración Española para subir tu declaración de la renta. No te hace falta Wuindols, Javas y Oracles porque Ubuntu (y Debian... y RedHat... OpenBSD... y FreeBSD...) Python (y Ruby... y PHP... y Erlang...) y PostgreSQL (y MySQL... y MariaDB...) te hacen exactamente lo puto mismo... gratis y con actualizaciones de por vida.
Está claro que aparecen fallos y las versiones evolucionan. Todo funciona así.
Ahora bien, si hubieran utilizado un lenguaje de programación verdaderamente libre, véase C++, Python, Ruby, PHP... para hacer lo puto mismo en lugar de atarse a tecnologías propietarias dependientes de los deseos de una multinacional (es decir: dependientes de que esa multinacional gane cuantos más millones al año mejor, cosa totalmente lógica) estas historias no pasarían y se podrían gestionar con mayor naturalidad y menor riesgo y menor coste que el de "vamos a morir todos porque Microsoft/Oracle/Apple el año que viene va a dejar de soportar TODO lo que hemos hecho hasta ahora".
Es por eso que precisamente las megaempresas de teleco y de la web tienen por norma general la costumbre de NO usar software privativo (tanto que les gusta el capitalismo y tan bueno y cojonudo que es) y por eso cuando trabajas por ejemplo como ingeniero de sistemas en Ericsson gestionando nodos de comunicaciones móviles que dan servicio a millones de usuarios sólo ves sistemas operativos GPL/BSD y aplicaciones desarrolladas en lenguajes libres. Y es que las empresas, al final, saben cómo hacer para no gastar al año 7 millones de euros en licencias de mierda para usar productos de otras empresas.
Esas empresas, por poner un ejemplo que conozco en primera persona, utilizaron en su día Python 2 para desarrollar sus aplicaciones. Python 3 no es compatible con Python 2, pero Python 2 continúa siendo mantenido y sus errores y fallas de seguridad, cuando los hay, corregidos. Y tu software de hace 10 años continúa siendo válido hoy y lo será dentro de 5 años más. Eso mismo no te lo puedes esperar de Oracle o Microsoft, que vive de cobrarte dinero por usar sus productos y si te mantienes con una sola licencia 20 años, dejan de ingresar pasta y sus acciones bajan. Así que si quieres que tus aplicaciones sigan funcionando, pues renuevas la licencia para poder bajarte los parches de este error, este y este otro. O mejor aún: te compras la licencia nueva para la siguiente versión, porque ese error tan grave no lo vamos a arreglar en la versión que tú usas porque "ha quedado anticuada".
Y sí, por mucho que te vengan los "informáticos" a decirte que "las Cosas Serias ® se hacen con GWuindol y con Oracle", la realidad es que los 100 millones de usuarios de Instagram subiendo fotos como cabrones 24/7 son gestionados por PostgreSQL y por el puto Django (Python), todo sistemas 100% libres. Y sí, Instagram tiene muchísima más carga de trabajo continua de la que jamás tendrá una asquerosa web de la Administración Española para subir tu declaración de la renta. No te hace falta Wuindols, Javas y Oracles porque Ubuntu (y Debian... y RedHat... OpenBSD... y FreeBSD...) Python (y Ruby... y PHP... y Erlang...) y PostgreSQL (y MySQL... y MariaDB...) te hacen exactamente lo puto mismo... gratis y con actualizaciones de por vida.
#53:
A ver, un poco de luz..
- Applet de Java != Aplicación de Java clásica "de escritorio"
- Chrome ya no soporta NPAPI desde el año pasado: http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html
- Firefox hará lo mismo a final de este año: https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
- La culpa de uso de Java en la administración electrónica no tiene nada que ver con cárnicas chapuceras o que les guste java más o menos.
- A día de hoy, no hay nada, repito, nada, salvo un applet de java, o plugin nativo del navegador, que permita acceder a la clave privada de los certificados para realizar firmas en el lado cliente, que es el principal problema para la administración electrónica. Por eso se usa java y no otra cosa. No es un capricho del administrador o de la picadora de carne de turno.
- Si, existe el API WebCryptoAPI de Javascript, pero no permite el acceso a las claves privadas (sólo ofrece primitivas criptográficas) y aunque existe algún borrador que lo propone (Web Crypto Key Discovery), no se prevee que ningún navegador lo implemente a medio plazo.
- La administración lo sabe desde hace tiempo y ya ha desarrollado varias alternativas.
- Applet de Java != Aplicación de Java clásica "de escritorio"
- Chrome ya no soporta NPAPI desde el año pasado: http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html
- Firefox hará lo mismo a final de este año: https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
- La culpa de uso de Java en la administración electrónica no tiene nada que ver con cárnicas chapuceras o que les guste java más o menos.
- A día de hoy, no hay nada, repito, nada, salvo un applet de java, o plugin nativo del navegador, que permita acceder a la clave privada de los certificados para realizar firmas en el lado cliente, que es el principal problema para la administración electrónica. Por eso se usa java y no otra cosa. No es un capricho del administrador o de la picadora de carne de turno.
- Si, existe el API WebCryptoAPI de Javascript, pero no permite el acceso a las claves privadas (sólo ofrece primitivas criptográficas) y aunque existe algún borrador que lo propone (Web Crypto Key Discovery), no se prevee que ningún navegador lo implemente a medio plazo.
- La administración lo sabe desde hace tiempo y ya ha desarrollado varias alternativas.
#6:
#3 Hace un par de años vi equipos en la Administración con Java 5 por culpa de un desarrollo web que necesitaba específicamente dicha versión...
Supongo que se usara Java 1.6 u43 (por ejemplo) durante muchos años, aunque ello implique un fallo de seguridad bien gordo.
Lo de Oracle con Java ha sido tan gordo como para prohibir por Decreto-Ley que se use ningún producto Oracle.
Supongo que se usara Java 1.6 u43 (por ejemplo) durante muchos años, aunque ello implique un fallo de seguridad bien gordo.
Lo de Oracle con Java ha sido tan gordo como para prohibir por Decreto-Ley que se use ningún producto Oracle.
#64:
#28 Pero usted sabrá que java es libre y gratuito (no así la implementación de Oracle, pero si todas las demás.).
Usted también sabrá que los servlets en Java son una tecnología muy probada y funcional y que servidores web como Apache Tomcat son bastante usados en la administración pública.
Usted también sabrá que la gran banca trabaja mayoritariamente con Java, y el mismo ha demostrado ser fiable.
Usted sabrá que aunque haya puesto ejemplos de Python o de PHP (esto lo añado yo) en los grandes portales web por debajo trabajan con compiladores JIT como HHVM (en el caso de Facebook).
Usted sabrá que la crítica es hacia los plugin en Java para el navegador y no a Java en la parte de servidor.
Gracias por atenderme.
Usted también sabrá que los servlets en Java son una tecnología muy probada y funcional y que servidores web como Apache Tomcat son bastante usados en la administración pública.
Usted también sabrá que la gran banca trabaja mayoritariamente con Java, y el mismo ha demostrado ser fiable.
Usted sabrá que aunque haya puesto ejemplos de Python o de PHP (esto lo añado yo) en los grandes portales web por debajo trabajan con compiladores JIT como HHVM (en el caso de Facebook).
Usted sabrá que la crítica es hacia los plugin en Java para el navegador y no a Java en la parte de servidor.
Gracias por atenderme.
#19:
Una nueva patada en los cojones de todos los fanboys del software privativo y cerrado por parte de una gran multinacional del sector.
Ahora que lo cambien a .NET o cualquier otra mierda para comprar licencias y dentro de X años que retiren el soporte y a pagar licencias otra vez y/o a reescribir código desde cero, claro que sí, con dos cojones. Porque el software libre y GPL es to caro, yatusáe miamol, que cuesta mucho "formar" a la gente. Con Microsoft y Oracle vienen ya formados de casa y además es lo que usa tol mundo y los ochocientos-mil-millones en licencias cada 10 años al final salen a cuenta, claro. Mucho mejor que hacer esas aplicaciones web en cualquiera de los lenguajes y frameworks libres GPL o MIT que existen.
Ahora que lo cambien a .NET o cualquier otra mierda para comprar licencias y dentro de X años que retiren el soporte y a pagar licencias otra vez y/o a reescribir código desde cero, claro que sí, con dos cojones. Porque el software libre y GPL es to caro, yatusáe miamol, que cuesta mucho "formar" a la gente. Con Microsoft y Oracle vienen ya formados de casa y además es lo que usa tol mundo y los ochocientos-mil-millones en licencias cada 10 años al final salen a cuenta, claro. Mucho mejor que hacer esas aplicaciones web en cualquiera de los lenguajes y frameworks libres GPL o MIT que existen.
#48:
#28 vamos a ver hasta donde yo se, Java es totalmente libre con su GPL y tal. Otro tema son las implementaciones de la JVM, Compilador pero sigue existiendo OpenJDK, Gcj, etc... Más también hay servidores de aplicaciones libres como JBoss/Wildfly respaldado por RedHat. De hecho la mayor parte del ecosistema de librerías de Java es software libre. Aparte que el ecosistema de la JVM no solamente esta Java, sino que también esta Scala, Clojure, Jython, Rhino, etc...
Otra cosa es que el responsable de turno de la administración, no afronte la realidad y diga, ostia esto que tenemos es obsoleto hay que migrarlo. El problema de la administración no es tecnológico es de no querer hacer las cosas bien. Sin ir más lejos la mayoría de herramientas de Big Data, Spark, Hadoop, Storm corren sobre la JVM con APIs Java/Scala/Clojure donde se ve lo que da de si la plataforma en cuanto a rendimiento y esalabilidad.
Y lo de las actualizaciones de por vida. Es relativo, si Python dejara de tener relevancia (que no dejara de tener a muy largo plazo) pues te tendrás que buscar la vida. O Django o el framework x haga un cambio de versión que sea bastante incompatible con la versión anterior, también existirán problemas para actualizaciones.
Otra cosa es que el responsable de turno de la administración, no afronte la realidad y diga, ostia esto que tenemos es obsoleto hay que migrarlo. El problema de la administración no es tecnológico es de no querer hacer las cosas bien. Sin ir más lejos la mayoría de herramientas de Big Data, Spark, Hadoop, Storm corren sobre la JVM con APIs Java/Scala/Clojure donde se ve lo que da de si la plataforma en cuanto a rendimiento y esalabilidad.
Y lo de las actualizaciones de por vida. Es relativo, si Python dejara de tener relevancia (que no dejara de tener a muy largo plazo) pues te tendrás que buscar la vida. O Django o el framework x haga un cambio de versión que sea bastante incompatible con la versión anterior, también existirán problemas para actualizaciones.
#89:
#86 Caballero, no soy experto en Java, pero tengo de cliente a un importante ministerio Español en Madrid y veo que la mayor parte del trabajo en los servidores se hace con este arcano e incomprensible lenguaje.
Estas personas parecen jubilosas con este lenguaje.
Yo soy un simple administrador de sistemas (Dandy, eso si) metido a emprendedor y programador ocasional (más por Hobby que por otra cosa) en el azaroso lenguaje C, Python y Livecode.
Respecto a lo que usted comenta:
Yo, como Dandy que soy, tengo que dirigirme a todo el mundo con extrema corrección (de usted o de usía).
Gracias por atenderme.
Estas personas parecen jubilosas con este lenguaje.
Yo soy un simple administrador de sistemas (Dandy, eso si) metido a emprendedor y programador ocasional (más por Hobby que por otra cosa) en el azaroso lenguaje C, Python y Livecode.
Respecto a lo que usted comenta:
Yo, como Dandy que soy, tengo que dirigirme a todo el mundo con extrema corrección (de usted o de usía).
Gracias por atenderme.
#47:
#1 Creo que se está estudiando el colocarte el certificado del DNIe en la nube y que cuando quieras hacer algo en la administración utilices tu contraseña y posiblemente te envíen un SMS de confirmación. Algo así como autenticación en dos pasos.
De esta forma dejarían de ser necesarios los lectores de smart cards, los plugins y que los ciudadanos tengan que instalar y configurar nada.
De esta forma dejarían de ser necesarios los lectores de smart cards, los plugins y que los ciudadanos tengan que instalar y configurar nada.
Comentarios
Meneo porque esto es la sentencia de muerte para muchas aplicaciones desarrolladas por y para la administración pública. El post al que se hace referencia está en: https://blogs.oracle.com/java-platform-group/entry/moving_to_a_plugin_free
#1 Mejor, así lo cambian de una vez.
#2 #3 Cuidado, que son capaces de pasarse a ActiveX
#4 Donde esté Flash
#4 Pero si ya lo usa!! Y compatible sólo con IE5 e IE6
#1 ja, iluso, te pedirán que uses Explorer 6 con Java 8u56 aunque lleguemos a 2025.
Y si no te dirán que pases por registro, que eso de la vía telemática es mu complicao
#3 Hace un par de años vi equipos en la Administración con Java 5 por culpa de un desarrollo web que necesitaba específicamente dicha versión...
Supongo que se usara Java 1.6 u43 (por ejemplo) durante muchos años, aunque ello implique un fallo de seguridad bien gordo.
Lo de Oracle con Java ha sido tan gordo como para prohibir por Decreto-Ley que se use ningún producto Oracle.
#6 Hoy mismo (¡hoy!) estoy configurando un equipo de la administración que tiene que llevar java 5 para que funcione una aplicación web de uso interno.
#16 Java 5? Eso no es de hace al menos 15 años? O.o
#48 "Otra cosa es que el responsable de turno de la administración, no afronte la realidad y diga, ostia esto que tenemos es obsoleto hay que migrarlo". Ahí está el problema. Todo el software de la administración se hizo en tiempo de burbuja y se gastaba un montón de pasta en aplicaciones para... comunicarle al ayuntamiento que el estanque del pueblo se quedó sin peces y cosas similares.
Ahora ya no se hacen super proyectos nuevos así que como mucho se mantienen esas aplicaciones del año de la pera. Visual basic 6, Java 5 como dijo #16 , ese es el pan de cada día de la administración.
#6 Es decir, que la administración usa una versión que se queda anticuada... y la culpa es de Oracle. Si las versiones evolucionan es porque lo tienen que hacer, y eso incluye las aplicaciones finales. Es como funciona este mundo. Si no, aun estariamos con MS-DOS.
#24 El problema es que la Administración paga a las empresas externas (a veces recibiendo sobres) si el programa funciona en un navegador determinado, en un sistema operativo determinado y con una versión de Java determinada. Yo entiendo que las aplicaciones web deberían de ser más compatibles, que ahora no lo son.
Oracle tiene multitud de culpas por las que no ha pagado, empezando por no resolver los problemas de seguridad de Java.
#25 una aplicación Java que se ejecuta en el navegador no es una aplicación web.
#25 Oracle tiene problemas de seguridad con Java igual que Microsoft con Windows y Adobe con Flash. Nada nuevo.
#24 Vamos a ver, hablamos de un lenguaje de programación sobre el cual la Administración ha desarrollado una serie de aplicaciones, no de un sistema operativo o de máquinas muy viejas que no puedan hacer determinadas operaciones o soportar una determinada carga de trabajo y deban ser actualizadas.
Está claro que aparecen fallos y las versiones evolucionan. Todo funciona así.
Ahora bien, si hubieran utilizado un lenguaje de programación verdaderamente libre, véase C++, Python, Ruby, PHP... para hacer lo puto mismo en lugar de atarse a tecnologías propietarias dependientes de los deseos de una multinacional (es decir: dependientes de que esa multinacional gane cuantos más millones al año mejor, cosa totalmente lógica) estas historias no pasarían y se podrían gestionar con mayor naturalidad y menor riesgo y menor coste que el de "vamos a morir todos porque Microsoft/Oracle/Apple el año que viene va a dejar de soportar TODO lo que hemos hecho hasta ahora".
Es por eso que precisamente las megaempresas de teleco y de la web tienen por norma general la costumbre de NO usar software privativo (tanto que les gusta el capitalismo y tan bueno y cojonudo que es) y por eso cuando trabajas por ejemplo como ingeniero de sistemas en Ericsson gestionando nodos de comunicaciones móviles que dan servicio a millones de usuarios sólo ves sistemas operativos GPL/BSD y aplicaciones desarrolladas en lenguajes libres. Y es que las empresas, al final, saben cómo hacer para no gastar al año 7 millones de euros en licencias de mierda para usar productos de otras empresas.
Esas empresas, por poner un ejemplo que conozco en primera persona, utilizaron en su día Python 2 para desarrollar sus aplicaciones. Python 3 no es compatible con Python 2, pero Python 2 continúa siendo mantenido y sus errores y fallas de seguridad, cuando los hay, corregidos. Y tu software de hace 10 años continúa siendo válido hoy y lo será dentro de 5 años más. Eso mismo no te lo puedes esperar de Oracle o Microsoft, que vive de cobrarte dinero por usar sus productos y si te mantienes con una sola licencia 20 años, dejan de ingresar pasta y sus acciones bajan. Así que si quieres que tus aplicaciones sigan funcionando, pues renuevas la licencia para poder bajarte los parches de este error, este y este otro. O mejor aún: te compras la licencia nueva para la siguiente versión, porque ese error tan grave no lo vamos a arreglar en la versión que tú usas porque "ha quedado anticuada".
Y sí, por mucho que te vengan los "informáticos" a decirte que "las Cosas Serias ® se hacen con GWuindol y con Oracle", la realidad es que los 100 millones de usuarios de Instagram subiendo fotos como cabrones 24/7 son gestionados por PostgreSQL y por el puto Django (Python), todo sistemas 100% libres. Y sí, Instagram tiene muchísima más carga de trabajo continua de la que jamás tendrá una asquerosa web de la Administración Española para subir tu declaración de la renta. No te hace falta Wuindols, Javas y Oracles porque Ubuntu (y Debian... y RedHat... OpenBSD... y FreeBSD...) Python (y Ruby... y PHP... y Erlang...) y PostgreSQL (y MySQL... y MariaDB...) te hacen exactamente lo puto mismo... gratis y con actualizaciones de por vida.
#28 Menuda chapa para no decir nada relacionado con el tema de dejar de soportar plugins, que es lo de que va la noticia.
#28 Coincido con #46 -- La noticia dice que los browsers dejan de soportar NPAPI, no que Oracle deje de soportar Java. Te recuerdo que Java es libre al igual que C++, Python etc. Puedes bajarte el JDeveloper o el Eclipse y programar en Java y no pagar ni un duro a Oracle. Java no es privativo: https://www.java.com/en/download/faq/distribution.xml
Oracle hace productos, no lenguajes (a excepción de Java y PL/SQL)y me parece muy bien que Instagram use Django, pero Google usa Java en Android y por alguna razón "seria".
No vengo a defender a multinacionales que no necesitan defensa, pero las cosas son como son.
#28 vamos a ver hasta donde yo se, Java es totalmente libre con su GPL y tal. Otro tema son las implementaciones de la JVM, Compilador pero sigue existiendo OpenJDK, Gcj, etc... Más también hay servidores de aplicaciones libres como JBoss/Wildfly respaldado por RedHat. De hecho la mayor parte del ecosistema de librerías de Java es software libre. Aparte que el ecosistema de la JVM no solamente esta Java, sino que también esta Scala, Clojure, Jython, Rhino, etc...
Otra cosa es que el responsable de turno de la administración, no afronte la realidad y diga, ostia esto que tenemos es obsoleto hay que migrarlo. El problema de la administración no es tecnológico es de no querer hacer las cosas bien. Sin ir más lejos la mayoría de herramientas de Big Data, Spark, Hadoop, Storm corren sobre la JVM con APIs Java/Scala/Clojure donde se ve lo que da de si la plataforma en cuanto a rendimiento y esalabilidad.
Y lo de las actualizaciones de por vida. Es relativo, si Python dejara de tener relevancia (que no dejara de tener a muy largo plazo) pues te tendrás que buscar la vida. O Django o el framework x haga un cambio de versión que sea bastante incompatible con la versión anterior, también existirán problemas para actualizaciones.
#28 Python 2 y Python 3 no son muy compatibles entre sí. Por ejemplo.
Aunque Python 2 en un momento u otro puede dejarse de mantener (aunque lo normal es cuando salga la versión 4 de Python).
#51 el cambio de 2 a 3 es tan trivial como inexcusable.
#72 Ni idea. Solo sé que son diferentes. Yo directamente he empezado a aprender Python con Python 3. Aunque, he visto que aún hay muchos manuales con Python 2 y muchas cosas aún se hacen con Python 2.
#72 Hay bastante soporte y herramientas para migrar de 2 a 3. El verdadero problema son los paquetes de terceros a los que no les da la puta gana de pasarlas a la versión 3. Lo ideal sería no depender de esos paquetes de terceros, pero también se trata de no reinventar la rueda. En fin, que es el justo equilibrio de es difícil de mantener.
Yo opté por entrar directamente en Python 3 y me encuentré con paquetes (por ejemplo Google API client para Drive) que solo estaban para 2, me tocó buscarme y hacerme las herramientas para usar las API.
#28 Pero usted sabrá que java es libre y gratuito (no así la implementación de Oracle, pero si todas las demás.).
Usted también sabrá que los servlets en Java son una tecnología muy probada y funcional y que servidores web como Apache Tomcat son bastante usados en la administración pública.
Usted también sabrá que la gran banca trabaja mayoritariamente con Java, y el mismo ha demostrado ser fiable.
Usted sabrá que aunque haya puesto ejemplos de Python o de PHP (esto lo añado yo) en los grandes portales web por debajo trabajan con compiladores JIT como HHVM (en el caso de Facebook).
Usted sabrá que la crítica es hacia los plugin en Java para el navegador y no a Java en la parte de servidor.
Gracias por atenderme.
Para #64. '...Usted también sabrá que la gran banca trabaja mayoritariamente con Java...'
En los paises nórdicos la gran banca está abandonando Java a marchas forzadas. Resultado : Problemas cero con los mayoritariamente incomprensibles runtimes de Java y servicios web 100% funcionales. Y no solo funcionan mejor, las interfaces las han mejorado una barbaridad con las nuevas tecnologias que utilizan.
(CC #28)
#64. Te paso una referencia sobre lo que afirmo en #83, iniciaron los cambios en 2014 :
http://e24.no/digital/dnb/disse-bankene-tilbyr-naa-java-fri-nettbank/23342807
PD. En los paises nórdicos esta superado lo del hablarse de usted. Igualdad de trato lo llaman, incluyendo tutear abiertamente a sus monarquias. Usted sabrá...
#86 Caballero, no soy experto en Java, pero tengo de cliente a un importante ministerio Español en Madrid y veo que la mayor parte del trabajo en los servidores se hace con este arcano e incomprensible lenguaje.
Estas personas parecen jubilosas con este lenguaje.
Yo soy un simple administrador de sistemas (Dandy, eso si) metido a emprendedor y programador ocasional (más por Hobby que por otra cosa) en el azaroso lenguaje C, Python y Livecode.
Respecto a lo que usted comenta:
Yo, como Dandy que soy, tengo que dirigirme a todo el mundo con extrema corrección (de usted o de usía).
Gracias por atenderme.
#28 "actualizaciones de por vida" siempre que el desarrollo se mantenga y siempre que una nueva versión no cree incompatibilidades con anteriores, algo que no es raro.
#28 Ramen, hermano.
Para #28. Así se habla.
#c-28" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2554030/order/28">#28 Yo tengo una aplicación C# que se empezó a desarrollar en el 1.1 de .NET y que ha envejecido sin tocar una línea hasta el 4.5., y lo que le queda. Diría que ya son 10 años. Pero bueno, lo que vosotros digáis, eh.
#96 Una aplicación compilada en 1.1 requiere el framework 1.1 instalado para correr, si no me equivoco.
Sin embargo, los fuentes de esa misma aplicación se pueden recompilar sin cambios en 2.0 y posteriores y correrán por los tiempos de los tiempos en el último framework que saquen. .Net es compatible hacia adelante a nivel de fuentes desde el principio.
Algo cambiaron de 1.1 a 2.0 que hacía a 1.1 incompatible a nivel binario (creo que la ausencia de generics) con lo que sacaron después, pero desde 2.0 en adelante, todo es compatible hacia delante a nivel binario.
#6 culpa a las administraciones y a los genios de las cárnicas que trabajan para ellos.
Cuanto Oracle compró java, ya existían atropellos en la administración.
#6 Continua pasando.
#3 justo iba a comentar esto mismo. En bizkaia y hacienda va a ser un gran fiesta. En lexnet lo mismo. En el resto de comunidades desconozco pero me lo imagino...
#1 #3 #5 Falso, las aplicaciones java podrán ejecutarse con el Java Web Start que ya está incorporado en el Java JRE/JDK, lo que eliminan es el plugin de los navegadores.
A ver si te crees tú que van a quitar de un plumazo el soporte de java y de todo lo que funciona con ello que te recuerdo que oracle vende Weblogic un servidor de aplicaciones Java y no las usa solo la administracion si no TODAS las empresas importantes
Del mismo post que pones tú lo explica
With modern browser vendors working to restrict and reduce plugin support in their products, developers of applications that rely on the Java browser plugin need to consider alternative options such as migrating from Java Applets (which rely on a browser plugin) to the plugin-free Java Web Start technology
#17 La noticia es que quitan el plugin. Las apps podrán bajarse o tirar del java web start, el caso es que quitan la integración de sus apps fuera del navegador, y sinceramente, yo no veo muchos sitios que usen Java Web Start.
Por ejemplo, firmar un documento que estás tramitando en la admon, ahora mismo usas formularios HTML y en el momento que se genera un documento y se quiere firmar, es cuando se ejecuta una applet para hacer la firma en local.
Esto no puedes hacerlo con Web Start, ya que conlleva hacer parte del progreso en el servidor vía navegador y otra parte en ejecución local. Al final, básicamente, tendrías que descargar un PDF para firmarlo con una aplicación que se descarga vía JavaWS. Esto, sinceramente, es un mojón.
#26 Obviamente se tendrán que modificar esas aplicaciones a la larga para que se ejecuten mediante Web Start, pero de ahí a decir que es su sentencia de muerte...
#17 El servidor jee más frecuente en las Administraciones Públicas es Jboss, al menos en la adm.central y muchas CCAA
#49 también hay Websphere y aunque no es un servidor de aplicaciones como tal hay Tomcat
#3 8u56? Eres un adelantado en el tiempo. A nosotros nos piden 6u31
#3 mmn, si te niegas a usarlo, podrias ir al contencioso administrativo (alguien en algun momento le pasará) y argumentar que ya que la empresa no da soporte, no es posible acceder, y por ejemplo, invalidad una convocatoria.
#3 Lo de Java y la administración pública (así como bancos) es un despropósito, dependiendo de la administración hay que instalar una u otra versión especifica para que "malfuncione" su aplicación, complicando la vida de los técnicos.
#1 por fin, ahora mismo es una lotería que funcione bien cuando haces tramites online por culpa del dichoso java. Me ha pasado infinidad de veces hl hacer un tramite, rellenar todos los campos y datos y justo en el último paso no funcionar y borrar todo por problemas de compatibilidad, he tenido que probar con tres navegadores y nunca es seguro que funcione al 100%. Por el contrario aveces funciona bien a la primera.
#8 En realidad yo creo que es por culpa de los dichosos certificados digitales, no de Java. Tengo la desgracia de hacer un montón de trámites administrativos, unos requieren firmar con Java, otros con webs que no tienen applet Java (imagino que en JavaScript), otros firmar un PDF con el Adobe. Y las tres cosas son una lotería que depende de versión del software, versión del sistema operativo, fase de la luna y estado de humor del japonés pequeñito que hay dentro de la CPU. Por otra parte, hay applets Java que no tratan con certificados digitales y funcionan perfectamente independientemente de versiones y demás.
La tecnología de los certificados digitales es como la de los micrófonos de los salones de actos o las cisternas de water. Conocida desde hace tiempo, pero parece que nunca conseguimos dominarla y que sea mínimamente fiable.
#1 Que compilen a javascript en lugar de a java bytecode y que nos dejen vivir tranquilos.
#1 No necesariamente. Lo crítico está en la firma de datos, donde sí se va a dejar de usar Java. Lo que se va a implementar en la mayoría de casos (por ejemplo, con el cliente@firma) son aplicaciones que registran un protocolo del tipo afirma:///[datos] como binario standalone:
http://administracionelectronica.gob.es/ctt/clienteafirma
#1 Creo que se está estudiando el colocarte el certificado del DNIe en la nube y que cuando quieras hacer algo en la administración utilices tu contraseña y posiblemente te envíen un SMS de confirmación. Algo así como autenticación en dos pasos.
De esta forma dejarían de ser necesarios los lectores de smart cards, los plugins y que los ciudadanos tengan que instalar y configurar nada.
#47 Solución cutre a mi entender. Guardar TUS certificados en la nube, y dar TU contraseña para que la app de turno acceda a ellos. La firma debe de ser en local a mi entender.
#78 la nube es un servidor de la policía, la app de turno es una página web institucional.
Por un lafo están dando por muy difícil o imposible un código html5 que permita la firma con el nivel de seguridad que quieren. Por el otro un problema de la aceptación del dnie es que la gente no tiene lector ni los conocimientos para configurarlo ni aún con mucha paciencia y los manuales oficiales que son bastante simples.
Con esto consigues que hasta una abuela pueda usarlo, sólo necesita saber su contraseña.
#78 No tocaría un certificado en esas condiciones ni con un palo. Cualquier día te venden la casa.
#1 La plataforma@Firma entre otros, que quieren sustituir por el sistema Cl@ve. No sabéis el engorro que es el tener que cambiar los sistemas de firma electrónica en la administración pública. No hay standard alguno ni marco común todavía y llevan menos de 5 años dando vueltas con ello si no recuerdo mal.
#1 En la administración pública se conoce el problema desde hace años http://blogs.forja.cenatic.es/clienteafirma/?s=La+dif%C3%ADcil+sustituci%C3%B3n+de+los+Applets+de+Java+&lang=es La cuestión es que sin el apoyo de la industria para desarrollar las APIs necesarias la solución no es sencilla.
#73 Si. Hay que darle caña a esto: https://www.w3.org/TR/WebCryptoAPI/ https://www.chromium.org/blink/webcrypto
#35 Intento explicartelo: los navegadores, los programas con los que ves las páginas webs, como Microsoft Internet Explorer, Mozilla Firefox, Safari en los Mac o Google Chrome, implementaron en los 90 formas de ejecutar otros programas incrustados. Un programa que se ejecuta dentro de otro programa.
Una chapuza.
Y los fabricantes de esas tecnologías chapuza (Microsoft: ActiveX, Adobe: Flash, Sun/Oracle: plugin Java del navegador) tuvieron y tienen tantos quebraderos de cabeza (gastos, en terminología capitalista) para ir parcheando la chapuza que ya están "discontinuando su uso". También en parte por el empuje de tecnologías web puras desde varios frentes, como las empresas de la era 2.0 (que dicho sea de paso se caracteriza por el cambio de usuario consumidor de contenidos a usuario también productor de contenidos): Google, facebook, amazon. Subes tus fotos y videos, escribes, te asocias; y es todo gratis, el producto eres tú.
"este tipo de noticias informáticas en la práctica que significa?" -> Si realizas trámites telemáticos con las administraciones publicas en España es muy probable que te encuentres con uno de estos programitas que se ejecuta en las tripas del otro: las tecnologías web no son capaces de firmar electronicamente un documento. Es nuclear lo que dice #79, que ha recibido su merecido positivo. Que se desarrollen los estándares de la Web que faltan para que no haya ya excusa alguna para abandonar estas chapuzas.
Y si dependes de uno de estos programitas pues es más que fácil que te dejen de funcionar, si es que siguen funcionando.
¿Qué significa? Probablemente no te afecte en lo más mínimo, si no te has encontrado el problema ya. En las webs modernas ya es raro encontrarlos (bueno, menos flash). Tomemos una cervecilla y ya está, si es que lo recomienda, doctor
#91 #61 #45 Muchas gracias. Mi pregunta era más encaminada a si significa, como me ocurrió al pasar de Flash 20 creo que fue, que determinadas webs que utilizaban no se qué método ya no permitían acceder a la cámara y al micrófono, y esto fue literalmente de un día para otro. El problema es que algunos navegadores te fuerzan a utilizar la última versión y en entornos como el mío, fue caótico. Tuve a cientos de trabajadores sin poder ejercer la telemedicina por ese cambio, ya que no puedes controlar que Flash utilizarán los pacientes desde su casa. Por suerte tenemos otras alternativas, pero todas dependen de que el paciente quiera o no quiera utilizar una aplicación o un dispositivo y os puedo decir que la mayoría no quiere salirse de su Edge y poco más.
Lo de que está implementado Java en el navegadores y tal lo conozco pero no se si con esto nuevo hará que forzosamente los aplicativos que utilicen Java certificados en determinada versión dejen de funcionar. Os aseguro que al menos en el entorno sanitario requieren de una versión concreta del plugin de Java para funcionar, sin permitir actualizaciones...espero no tener que volver a montar un equipo de crisis por esto.
Visto desde fuera os puede parecer ridículo, pero el Comité de Crisis Flash (sí, somos bastante burocráticos), a pesar de lo tonto del nombre nos supuso unas pérdidas millonarias...
PS: Nada de cerveza, y menos en horario laboral. Mejor tómate un zumo de uva o leche de almendras, tu salud mental y la calidad del sueño te lo agradecerán
A ver, un poco de luz..
- Applet de Java != Aplicación de Java clásica "de escritorio"
- Chrome ya no soporta NPAPI desde el año pasado: http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html
- Firefox hará lo mismo a final de este año: https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
- La culpa de uso de Java en la administración electrónica no tiene nada que ver con cárnicas chapuceras o que les guste java más o menos.
- A día de hoy, no hay nada, repito, nada, salvo un applet de java, o plugin nativo del navegador, que permita acceder a la clave privada de los certificados para realizar firmas en el lado cliente, que es el principal problema para la administración electrónica. Por eso se usa java y no otra cosa. No es un capricho del administrador o de la picadora de carne de turno.
- Si, existe el API WebCryptoAPI de Javascript, pero no permite el acceso a las claves privadas (sólo ofrece primitivas criptográficas) y aunque existe algún borrador que lo propone (Web Crypto Key Discovery), no se prevee que ningún navegador lo implemente a medio plazo.
- La administración lo sabe desde hace tiempo y ya ha desarrollado varias alternativas.
#53 Por fin alguien que habla con conocimiento.
#53 ¿Podrías decirnos qué alternativas se han desarrollado? Me interesa mucho el tema pero lo desconozco. ¡Gracias!
#80
Un cliente que registra un protocolo en el sistema. De la misma forma que existe http:// o ftp://, este cliente registra el suyo propio, del tipo afirma://, por el que se pasan los datos, y la aplicación los devuelve firmados.
Hay cliente para Windows Phone, iOS, Android, Mac OS X y Linux
http://forja-ctt.administracionelectronica.gob.es/web/proyectos/clienteafirma/pid/1436
#85 Mola. ¡Gracias de nuevo!
#53 Tanto no sabrá la Administración cuando siguen usando sistemas criptográficos, de seguridad, llamémosle como queramos que estan obsoletos o son inseguros. Claro que el problema es cuando los navegadores este año dejen de soportar totalmente (no permitirán excepciones de seguridad) algunos de los tipos y protocolos de cifrado.
Por ejemplo la web del Servicio Estatal Público de Empleo (SEPE) no pasa de un mísero C en el test QUALYS SSL Labs. No soporta TLS 1.2 (ahora el test penaliza mucho esto), sigue usando SHA1 sobre RSA, usa RC4 permitiendo cifrado antiguo, es vulnerable a POODLE,...
Salu2
Una nueva patada en los cojones de todos los fanboys del software privativo y cerrado por parte de una gran multinacional del sector.
Ahora que lo cambien a .NET o cualquier otra mierda para comprar licencias y dentro de X años que retiren el soporte y a pagar licencias otra vez y/o a reescribir código desde cero, claro que sí, con dos cojones. Porque el software libre y GPL es to caro, yatusáe miamol, que cuesta mucho "formar" a la gente. Con Microsoft y Oracle vienen ya formados de casa y además es lo que usa tol mundo y los ochocientos-mil-millones en licencias cada 10 años al final salen a cuenta, claro. Mucho mejor que hacer esas aplicaciones web en cualquiera de los lenguajes y frameworks libres GPL o MIT que existen.
#19 el problema no es el soft libre, el problema es que los corruptos de nuestras administriaciones llevan años recibiendo paguitas de microsoft para que el estado siga malgastando dinero publico en esa empresa y sus productos cuando hay alternativas mucho mas competitivas.
#22 Microsoft, Oracle... todo lo relacionado con el tema funciona a base de comisiones y maletines. En todos los países del mundo.
#19 Una nueva patada en los cojones de todos los fanboys del software privativo y cerrado por parte de una gran multinacional del sector.
Ahora que lo cambien a .NET o cualquier otra mierda para comprar licencias
El problema de uso de Java en la administración no se soluciona cambiando a .NET
#19 .NET es libre también https://github.com/Microsoft/dotnet
#57 Que haya proyectos de código abierto para .NET no lo convierte en una plataforma de desarrollo de cógido abierto.
#57 Eso es el núcleo.
A java le deseo una muerte dolorosa tal como he sufrido en mis carnes tener que programar tan dichoso lenguaje.
#30 pfff no lo veo para tanto... además siempre se cumple el "otro vendrá que bueno me hará".
Java está pensado para no-programadores... está to hecho... solo hay que importar la librería adecuada
#32 Supongo que eso también lo pensarían los que programaban en tarjetas perforadas, cuando empezaron a aparecer lenguajes escritos. No se porque ves un problema que haya librerías. A ti te parece logico que un millon de personas se tengan que programar una librería para si mismo cuando entre todos se podría hacer una con el mismo fin? ¿La comunidad y la colaboración es de malos programadores? Apaga y vamonos.
#88 no sé si me he explicado mal... decían " tal como he sufrido en mis carnes tener que programar tan dichoso lenguaje." Y yo sólo apuntaba que tampoco se sufre tanto programando en java... Personalmente me gusta mucho más C++ como lenguaje, pero la potencia que da java/.net es una maravilla... maven+spring = $deity
Tal y como funcionan los trámites telemáticos en España voy a ir preparando una máquina virtual con windows XP, explorer 6 y Java
#14 La Administración pondrá una en la web. Y enlace al torrent.
#14 Yo me hice en su día con LinuxAE. Y desde entonces, sin problemas...
Distribución Linux para Administración Electrónica en España
http://danielside.nom.es/2013/04/03/distribucion-linux-para-administracion-electronica-en-espana/
También está Cl@ve
Las subcontratadas que hacen sus chapuzas para la administración pública han debido de tener un escalofrío al leer la noticia.
Aunque dudo que cambie nada en ese sentido, ahora las administraciones además de pedir que usemos Windows e Internet Explorer en sus sitios web de mierda, exigirán que usemos versiones antiguas de Java llenas de agujeros se seguridad. Ojalá me equivoque...
#33 Estarán frotándose las manos, pensando en todos los proyectos que va a haber que renovar.
Mucho cuñado echando mierda sobre Java cuando hay magnifico software desarrollado en esa tecnología
Java es mucho más que los applet
#81
por ejemplo?
La mierdurria que hacen en la consultora de turno no cuenta
#95 Por ejemplo:
https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
#95 La mayoria de los proyectos de la ASF son en Java, por ejemplo.
Ya hay una aplicación de firma electrónica sin Java para Windows y para Android, el problema es que no se está desarrollando ninguna alternativa para Linux, Mac, etc... lo bueno del java era que funcionaba en cualquier parte, ahora, o te metes una máquina virtual con Windows, o vas en persona al Registro.
#10 Y eso cuando te dejan registrar y no te dicen «hazlo por internet».
#10 Python es multiplataforma y está correctamente optimizado otros SSOO. Java está optimizado para Windows, lo demás es circunstancial para que sigáis manteniendo ese mantra.
#42 O Go, mismamente.
NPAPI! PAPI chulo, PAPI PAPI PAPI ven a mí, ven a mí
#29 Cada vez que hago ese chiste me miran con cara de "¿este tío de dónde ha salido?"
bam bam bam, another one bites the dust 🎵
Ya podría premiar la Administración a los ciudadanos que usamos el tinglado en GNU/Linux. Acceso de escritura a alguna base de datos de Hacienda o algo así
Qué risas me he echado con vuestros comentarios echando bilis sobre java...
Cómo si esto fuese el fin de Java o de Oracle o algo similar...
Los applets están "deprecated" desde la versión 5 más o menos. La propia Oracle los desaconseja.
Ya era hora. Hace muchos años que Java es un lenguaje de servidores, y bueno, últimamente de Android. Los applets llevan años obsoletos, cosa de la que me alegro. Yo hace mucho tiempo que no instalo en plugin en el navegador.
Señores, la JVM es una tecnología robusta, probada y que funciona bastante bien. El lenguaje Java es feo, pero hay alternativas que generan código que corre e interacciona perfectamento con JVM. Véase Scala.
Ojalá muriese Java en la administración. Ojalá dejasen de hacer las webs de la administración las mismas empresas de puta mierda de siempre e hiciesen webs usables por todo el mundo de forma sencilla.
Que yo con mi obsoleto XP y mi Firefox no pueda ver este vídeo de gatitos
This browser does not support video playback. creo que tiene que ver con el papi ese o npapi y el plugin de quicktime para xp que no existe o está bloqueado por Firefox.Me voy a tener que cambiar de navegador y puede que hasta migre a Ubuntu.
Los plugins NPAPI, flash, java, applets, etc., fueron tecnologías que aparecieron en los 90 para conseguir funcionalidades que los navegadores de la época no tenían. 20 años después los navegadores ya tienen esas funcionalidades por sí mismos e incorporadas a nuevos estándares como html5. No tienen necesidad de seguir soportando plugins externos (y sus vulnerabilidades, sus cuelgues, y su ralentización del propio navegador).
Un chollo para las empresas de IT. Hacen una aplicación, a los 5 años se queda obsoleta esa tecnología y les tienes que pagar otra vez para que hagan otra aplicación igual.
e-obsolescencia programada.
Esta es la renuncia oficial de Oracle a tener Java en los navegadores. Me temo que motor de Java 9 será el menos ejecutado de la historia.
#5 Será el menos ejecutado en cliente... en servidor sigue y probablemente seguirá fuerte. A Oracle nunca le ha interesado el usuario final, que además es el que más problemas da; le interesan los servidores corporativos.
#5 No creo, hay un montón de software que usan Java y que tienen mucho uso; JDownloader, Vuze, Minecraft...
A 2472 gestoras les gusta esto. Un suplicio la web de Hacienda
Firma centralizada ckc
PHP vive.
Me gusta esta web por la diversidad de contenido, aunque flaquee ultimamente... pero para los que somos de otras profesiones, en concreto soy médico, alguien en los primeros comentarios podría objetivamente indicar en este tipo de noticias informáticas en la práctica que significa?
Gracias
#35 Que no recomiendan su uso en navegadores, se vade a dejar de soportar y un montón de aplicaciones web obsoletas no podrán utilizarse (espero).
#35 Que a corto plazo los navegadores no soportarán java, una tecnología de los años 90, y muchas páginas dejarán de funcionar. Entre ellas, muchas de la administración para hacer trámites (electricistas haciendo boletines, tú haciendo la declaración de la renta, etc.).
Para cuando hacen Java obsoleto ?
#76 para nunca.