Portada
mis comunidades
otras secciones
#3:
#2 El javascript puede obtener información del lado del CLIENTE y enviarla a un SERVIDOR.
Los de la FSF piden que todo lo que se ejecute en el lado del CLIENTE sea SOFTWARE LIBRE ya que el CLIENTE (perdón, el usuario) tiene derecho a saber exactamente qué ejecuta su ordenador.
He usado las mayúsculas por miedo a que no me entendieras si no lo hacía, no sé en qué dialecto te expresas que es necesario usar palabras en mayúsculas para que te entiendan pero por si acaso lo he imitado.
Los de la FSF piden que todo lo que se ejecute en el lado del CLIENTE sea SOFTWARE LIBRE ya que el CLIENTE (perdón, el usuario) tiene derecho a saber exactamente qué ejecuta su ordenador.
He usado las mayúsculas por miedo a que no me entendieras si no lo hacía, no sé en qué dialecto te expresas que es necesario usar palabras en mayúsculas para que te entiendan pero por si acaso lo he imitado.
#12:
1) Las librerías JavaScript de Google están liberadas con Apache License y por tanto SON "software" libre.
http://code.google.com/intl/es/closure/library/
http://closure-library.googlecode.com/svn/trunk/LICENSE
http://www.apache.org/licenses/GPL-compatibility.html
Pero siempre ha de haber desinformados que piensan que si no es GPL no es libre.
2) Si uno es extremadamente purista (tipo Stallman), GMail ofrece bien visible la opción de ser usado únicamente con HTML sin JavaScript. Voilà, ya tienes tu GMail libre.
Por todo ello, y con todos los respetos, este artículo me parece un lloro innecesario.
http://code.google.com/intl/es/closure/library/
http://closure-library.googlecode.com/svn/trunk/LICENSE
http://www.apache.org/licenses/GPL-compatibility.html
Pero siempre ha de haber desinformados que piensan que si no es GPL no es libre.
2) Si uno es extremadamente purista (tipo Stallman), GMail ofrece bien visible la opción de ser usado únicamente con HTML sin JavaScript. Voilà, ya tienes tu GMail libre.
Por todo ello, y con todos los respetos, este artículo me parece un lloro innecesario.
Comentarios
1) Las librerías JavaScript de Google están liberadas con Apache License y por tanto SON "software" libre.
http://code.google.com/intl/es/closure/library/
http://closure-library.googlecode.com/svn/trunk/LICENSE
http://www.apache.org/licenses/GPL-compatibility.html
Pero siempre ha de haber desinformados que piensan que si no es GPL no es libre.
2) Si uno es extremadamente purista (tipo Stallman), GMail ofrece bien visible la opción de ser usado únicamente con HTML sin JavaScript. Voilà, ya tienes tu GMail libre.
Por todo ello, y con todos los respetos, este artículo me parece un lloro innecesario.
#12 Amén
Me he leído la noticia un par de veces y sigo sin entender qué quiere la FSF. Por una parte comentan que Google tiene que hacer el código JS libre (que choca con lo que comenta #12 y el hecho de que para ejecutarlo el cliente/usuario siempre tiene el código, como comenta #4). Por otra parte, hablan de la gran cantidad de hack de Gmail hechos vía JS con Greasemonkey.
Si de lo que vienen a quejarse es que el código JS no se entiende ("Gmai's JavaScript is non trivial"), lo van a tener crudo. El tamaño del código JS es una parte a considerar en el tiempo de carga de la página, así que para "míles de líneas", si mis variables se llaman a y b en vez de alpha y bravo me ahorro 4 bytes por referencia. Menor tamaño, mayor velocidad de carga.
No sé, sigo sin ver a dónde quieren llegar. ¿Seguro que no es un April fool?
#17 Según su funcionalidad, los bloques javascript se clasificarían entre triviales y no triviales. Proponen un criterio para esta clasificación.
En caso de que fueran no triviales, la FSF explica que los sitios podrían respetar la libertad del usuario ofreciendo la descarga de la versión no ofuscada del código, así como que los navegadores tengan la posibilidad de ejecutar otra versión local del bloque javascript en lugar del que ofrece la página web.
#18 ¿Crees que los demás no lo hemos leído sólo porque tú no comprendes que no tiene sentido?
#19 Si quieres más razones por las cuales tu idea no tiene sentido las hay, pero éstas ya son suficientemente contundentes:
Incluso sin tener en cuenta las razones de eficiencia que explica #17, la separación de código entre "trivial" y "no trivial" es una idea absolutamente ridícula. ¿Cuál es el criterio, quién lo establece y cómo demonios esperan hacer la separación? No tiene sentido, cualquier programador se mearía de risa. De entrada tendría cojones tener que diseñar los módulos pensando no en la funcionalidad sino en la complejidad del código (la cual habría que adivinar previamente, por supuesto).
Si pretendes tener todo GMail metido en GreaseMonkey vete despidiendo, porque GreaseMonkey sólo sirve para hacer apaños y parchear páginas. Tener aplicaciones "web" enteras con JavaScript local requiere cambiar el funcionamiento de los navegadores actuales e incluso complementar el protocolo HTTP. Para empezar, ¿cómo adivina el aplicativo remoto qué librerías JavaScript necesita ese usuario concreto y cuáles ya tiene en local? Los navegadores actuales ni siquiera tienen forma de discriminar que no se ejecute un "script" remoto si existe en local.
Si algo tienen de bueno los servicios "web" es que no requieren instalación y que siempre estás ejecutando la versión más perfeccionada. Tener el código en local es una regresión al "software" mantenido por el usuario (que como todos sabemos no hace mantenimiento de su "software"), al infierno de la distribución de parches, a que diferentes usuarios tengan diferentes versiones en funcionamiento (en muchos casos obsoletas), y ya ni te cuento si los usuarios utilizan librerías modificadas por ellos mismos. Si tú quieres usar una aplicación tan poco fiable como el monstruo de Frankenstein adelante, pero no creo que el aberrante purismo de la FSF sea suficiente para apoyar tal idea.
Por otra parte, te avanzo que una de las primeras modificaciones que implementaría la gente serían "scripts" para enviar vía Ajax el contenido de tu correo a un servidor atacante y así capturar todos tus datos, comunicaciones personales, contraseñas, números de cuenta, etc. Sin que te enteraras siquiera. Poder modificar un código libre no significa necesariamente mayor seguridad, porque el usuario nunca comprueba el código, simplemente se fía de que "alguien" lo comprueba (cosa que casi nunca es cierta). En definitiva, GMail estaría totalmente abierto a los virus.
Si yo fuese una empresa (pongamos Google), jamás ofrecería un producto del cual no puedo garantizar el correcto funcionamiento del 100% de su código. Y menos aún tratándose de un producto estratégico.
#20 Lo siento no tengo tiempo para enseñarte. Aprende inglés y leete el articulo y los links que contiene, de nada.
#21 Querrás decir que no tienes tiempo para aprender lo que los demás ya sabemos, porque es evidente que no tienes ni puñetera idea de las implicaciones de tu propuesta. Ni te las has planteado siquiera, visto el calibre de la chorrada que sueltas en #19.
Por cierto, gracias por el tono chulillo, así dejas bien claro que sólo eres un mísero "troll" y no mereces más consideración. Se agradece el ahorro de tiempo.
#22 Estás haciendo el ridículo, la propuesta no es mía. Está desarrollada en el artículo de la FSF que no has leído y del cual llevas todo el rato hablando de manera ignorante y prepotente (típico de los trolls).
#23 Como está claro que tú no has leído el artículo al que repetitiva y estúpidamente remites a los demás, te traigo aquí el ruego de la FSF, a ver si así aún tienes cojones de inventarte que dice lo que tú quieres que diga:
"If you use Gmail, please ask Google to take the next step towards making Gmail free software friendly by releasing the JavaScript for Gmail under a free software license".
Como puedes ver:
a) El artículo no menciona por ninguna parte chorradas como distinguir entre código trivial y código complejo, ni tampoco discriminar entre librerías remotas y locales. ESAS gilipolleces son tu propuesta, y te las has inventado por pura ignorancia y contra toda realidad tecnológica.
b) El artículo comete la cagada de ignorar maniqueamente que la mayoría de código de Google ya está licenciado como "software" libre, así como que ya existen multitud de formas libres de usar GMail. Pero claro, hay que quejarse, que sin publicidad no hay subvenciones.
De nada, bonito.
#24 Bueno pues eso, cuando salgas de la fase anal te lees el articulo en cuestión y verás lo patético que eres.
#1, #4, #12 RTFA
"solicita a Google que dea el siguiente paso"
Lo siento pero no podía dejarlo pasar...
"Cuando visitas un sitio web como Gmail, tu navegador se descarga y ejecuta varios miles de líneas de código JavaScript"
Cualquier mierda de web hoy en día tiene Javascript en cantidad. Que hacemos, lo desactivamos?
#1 verdad verdadera
Que tontería pero si el javascript que se ejecuta en el cliente es interpretado, y siempre es accesible con cualquier depurador tipo firebug, aunque no fuera si quiera software libre.
¡Vaya lio! ¿Alguno sabe cual es el peligro real de este código javascript? Mientras no me perjudique, por mi pueden poner millones de lineas.
El JavaScript se utiliza para ejecutar aplicaciones del lado del CLIENTE, no del SERVIDOR.
#2 El javascript puede obtener información del lado del CLIENTE y enviarla a un SERVIDOR.
Los de la FSF piden que todo lo que se ejecute en el lado del CLIENTE sea SOFTWARE LIBRE ya que el CLIENTE (perdón, el usuario) tiene derecho a saber exactamente qué ejecuta su ordenador.
He usado las mayúsculas por miedo a que no me entendieras si no lo hacía, no sé en qué dialecto te expresas que es necesario usar palabras en mayúsculas para que te entiendan pero por si acaso lo he imitado.
Gmail no está escrito en Javascript , sino en Java. Lo escriben en Java usando GWT, y GWT lo "compila" a javascript.
#3 Entra a Gmail con Firefox, pulsa control + U y voila, ya puedes ver qué se está ejecutando en tu ordenador, aunque no esté licenciado con la GPL.
#4 Me he expresado mal, lo que pide la FSF no es solo ver lo que se ejecuta sino poder modificarlo a tu antojo.
No veo como sería aplicable a Gmail que ofrece un servicio directamente desde su web, pero supongo que se podría llegar a diferenciar la parte web de la ejecución del cliente.
#3 ¿cómo que tienes derecho a ver mi código? eso será si yo quiero. si no quieres ejecutar algo que no sabes lo que es, no lo ejecutes. de todas formas, sabes cuál es el servidor al que se envían cosas, con algún plugin puedes ver qué se envía, y también sabes que no se puede envíar ese archivo de texto donde guardas tus datos bancarios ni otros datos del mundo exterior al navegador.
#4 "The Closure Library is server-agnostic, and is intended for use with the Closure Compiler. At Google, it's used in Gmail, Docs, Sites, Books, Reader, Blogger, Calendar, Picasa Web Albums, and more."
closure library es javascript.
#7 ¿cómo que tienes derecho a ver mi código?
Estaba reproduciendo la petición de la Free Software Foundation, que como comprenderás defienden el Software Libre en todos los ámbitos.
Tu tienes derecho a cerrar tu código para que tus usuarios no puedan verlo pero entonces no te extrañe que la FSF critique tu actitud, estás aplicando criterios opuestos a sus directrices.
#10 por supuesto, no digo que no critiquen esta actitud, están en todo su derecho. pero no existe el derecho a ver mi código. se puede decir que es deseable o incluso que es una concesión que debe exigir el usuario, pero no es un derecho.
#3 Gracias por la obviedad y por darme la razón, amigo hacker, que no es otra que JavaScript se ejecuta en CLIENTE.
Este es el típico caso en que la FSF por radical mea fuera del tiesto pero es que precisamente la FSF está para defender ese extremo. Alguien lo tiene que hacer.