En Soft-Libre han preparado un montaje con los temas disponibles para darle a tu navegador la «marca de fábrica» de tu distro favorita. Tanto si usas OpenSUSE, Mandriva, Ubuntu o Fedora, puedes personalizar Firefox como recién salido de la factoría.

Firefox 3.6 disponible, ¡descárgalo ya!
Descarga ya Firefox 3.6
Firefox 3.6 Final!
Firefox 3.6 disponible para descargar
Firefox 3.6 Final disponible (y tema �Avatar Personas’ que está bien majo)
Firefox 3.6 Final
Bájalo mientras está caliente: Disponible Firefox 3.6!
Upgrade Firefox 3.6
Convierte Firefox 3.6 en Firefox 4
Firefox 3.6 con el aspecto gráfico de Firefox 4.0
[Corto] Firefox 3.6
Firefox 3.6 disponible para descarga

Gregg Keizer

Mozilla ha realizado algunos cambios en su programa de desarrollo para Firefox, y planean dejar caer el lanzamiento de Firefox 3.7 de su calendario y en su lugar centrarse en ir liberando cambios incrementales sobre la versión actual a lo largo del año, según recientes declaraciones de un ejecutivo de la compañía.

En lugar de añadir características a Firefox en una o dos grandes actualizaciones anuales, Mozilla insertará silenciosamente nuevas funcionalidades a través de sus habituales actualizaciones de seguridad, las cuales aparecen cada cuatro o seis semanas, todo según Mike Beltzner director de Firefox.

Eso significa que Firefox 3.7, inicialmente prevista para ser liberada la segunda mitad de este año, sería dejada caer del calendario de desarrollo, según Beltzner. La siguiente versión después de Firefox 3.6 será la aún sin nombre 4.0 al final de este año o a comienzos de 2011.

El año pasado Mozilla hubo afirmado que lanzaría un par de grandes actualizaciones etiquetadas 3.6 y 3.7, llevando sobre cuatro o cinco meses cada una salir al mercado. Estas llamadas entonces actualizaciones menores serían seguidas por una gran actualización etiquetada 4.0, lista para ser lanzada la segunda mitad de 2010.

Pero aparentemente Mozilla ha cambiado sus intenciones.

Visto en Macworld vía Punto Libre. Captura de Tecnone.

Un primer consejo es, desde luego, desactivar las extensiones mientras no las estás necesitando. Firebug, por ejemplo, es, desde luego, una aplicación killer para desarrolladores web que hace imprescindible a Firefox. Pero ralentiza el uso del navegador, y es raro que la necesites más que un par de ocasiones al mes —a no ser, por supuesto, que seas un profesional en el tema—. Lo dicho para Firebug vale para muchas otras extensiones complejas. Yo, por ejemplo, hoy por hoy sólo necesito Google Gears para subir clips a YouTube. El resto del tiempo está desactivada.

Por lo demás hay una serie de parámetros que es posible optimizar, y se listan debajo. Puedes, por supuesto, visitar about:config y configurarlas una por una. O puedes llevar ese código a prefs.js. La sugerencia es, desde luego, llevar esas opciones a un fichero user.js en el directorio de configuración de Firefox, junto al citado prefs.js. El fichero user.js es así portable de máquina en máquina. En mi caso, estas opciones están en todas las máquinas donde uso Firefox.

user_pref("network.http.pipelining", true);
user_pref("network.http.proxy.pipelining", true);
user_pref("network.http.pipelining.maxrequests", 30);
user_pref("nglayout.initialpaint.delay", 0);
user_pref("config.trim_on_minimize", true);
user_pref("browser.cache.memory.capacity", 27648);
user_pref("browser.cache.memory.enable", true);
user_pref("network.prefetch-next", false);
user_pref("network.http.max-connections", 60);
user_pref("network.http.max-connections-per-server", 32);
user_pref("network.http.max-persistent-connections-per-proxy", 16);
user_pref("network.http.max-persistent-connections-per-server", 16);
user_pref("network.dns.disableIPv6", true);
user_pref("content.notify.backoffcount", 5);
user_pref("ui.submenuDelay", 0);
user_pref("plugin.expose_full_path", true);
user_pref("browser.sessionhistory.max_total_viewers", 2);
user_pref("browser.sessionhistory.max_entries", 10);

• El pipelining en las conexiones HTTP 1.1 reduce la carga de red y el tiempo de carga de las páginas sobre conexiones cuando la latencia es demasiado elevada. Teóricamente no todos los servidores lo soportan y podrían comportarse incorrectamente si reciben peticiones de este tipo, de ahí que muchos aconsejen no activarlo. Yo no he encontrado problemas y sí una mejora clara en el rendimiento. 30 es una buena cifra para el máximo número de este tipo de peticiones concurrentes.
• Tiene sentido visualizar la página ya según empieza a ser cargada, de ahí que se elimine cualquier intervalo antes de empezar a hacerlo.
• Mejora también el rendimiento permitir que la aplicación haga swap una vez minimizada. De esta forma se libera memoria que hace más agil el uso de tu sistema operativo.
• Almacenar en una cache imágenes, elementos de interfaz de usuario o páginas seguras acelera el rendimiento. ¡Piensa en la diferencia que supondría tener que decodificar estas últimas cada vez que son cargadas!
• Una opción polémica es la de permitir la precarga de las páginas tras los enlaces que componen una página. Yo voto por liberar a la CPU de la tarea de precargar enlaces que probablemente no van a ser seguidos.
• El ADSL y en general toda banda ancha permite un número mayor de conexiones HTTP concurrentes que las que permitían las conexiones por módem. Aumentar ese valor hoy por hoy mejora el rendimiento en todos los casos.
• Mientras IPv6 no exista, desactivarlo también mejora el rendimiento.
• Posiblemente sea sólo psicológico, pero eliminar el retardo con el que se abren las opciones del menú de la aplicación repercute en la sensación de un mejor rendimiento.
• Por último, es improbable que te interesen páginas más allá de las diez últimas visitadas. Se libera así memoria y mejora el rendimiento de la aplicación y del sistema operativo.

Haz la prueba y deja un comentario. ¿Notas la mejora en el rendimiento? Yo desde luego que sí. ¿Algún truco más?

Ah, el usuario de Ubuntu dispone por supuesto de Firefox tal cual. El usuario de Debian puede aplicar exactamente las mismas opciones en Iceweasel.

Captura de Pentadact.

Tal y como Greg Maxwell apuntó recientemente, parece que Theora puede ya competir con otros formatos utiliados para distribuir contenidos de vídeo online. Ha comparado la salida generada por el mecanismo de codificación de YouTube con salida generada por el nuevo codificador Theora —en el momento de escribir esto libtheora 1.1alpha2 es la última versión—. El resultado, a grandes rasgos, es que Theora ofrece un rendimiento similar al de cualquier otro codificador utilizado actualmente en YouTube. Esto quiere decir que los servicios de streaming pueden ya utilizar tecnología abierta sin penalización en bitrate o calidad comparando con sus configuraciones actuales.

Esto no quiere decir que H.264 como formato deje de ser el líder en rendimiento. Lo que quiere decir es que H.264 —aka. MPEG-4 o DivX— cuando se utiliza en un sistema donde debe primar lo económico procesando además grandes cantidades de contenido —necesitando de ahí ofrecer un balance aceptable entre calidad y velocidad de codificación— no es el líder en rendimiento que se cree habitualmente. Un formato menos sofisticado con un codificador inteligente puede ofrecer una solución razonable cuando hay que considerar eficacia en la compresión, velocidad y costes de licencias.

La comparativa de Greg utilizaba contenidos generados por ordenador. La mía intenta dar otro punto de vista con contenidos «normales».

La fuente del vídeo para mi pequeño experimento es una entrevista con Fred von Lohmann sobre industrias de medios y DRM. Se trata de «un tío hablando» así que de lejos es el material más sofisticado con el que poner a prueba un codificador. Pero por lo mismo no creo que ninguno de los codificadores probados encuentre que se trata de material especialmente fácil o difícil, así que me parece un trato justo. Además, «tíos hablando» es de lo que más te encuentras en las plataformas de streaming.

El contenido original era un MPEG-2 a 1440×1080. Lo desentrelacé y lo escalé a 1280×720, y volví a codificarlo a MPEG-2 con mencoder. El resultado es este fichero.

Lo subí a YouTube y luego lo descargué usando una extensión para Firefox llamada DownloadHelper. Luego codifiqué el fichero de entrada con Theora a la misma resolución y bitrate usando ffmpeg2theora y la revisión SVN 16142 de Thusnelda, el nuevo codificador Theora. Opté por establecer la frecuencia de marcos a 170 —comparando con los 250 de la comparativa de Greg— y usé el modo de codificación gestionado por bitrate, lo que quiere decir que el resultado no es VBR sino ABR. Esto tiene cierto impacto en la calidad pero asegura que no hay picos de bitrate, algo deseable cuando preparas material para streaming.

Las líneas de comandos ffmpeg2theora usadas son:

  ffmpeg2theora -K 170 -V 465 -a 0 -x 480 -y 270 input.mpg
  

y

  ffmpeg2theora -K 170 -V 2050 -a 0 input.mpg
  

El parámetro -a 0 en ambos casos devuelve audio Vorbis a aprox. 64 Kbps, lo que considero adecuado para lo que necesito dado el buen rendimiento de Vorbis. Para un bitrate combinado de audio y vídeo de aprox. 500 a 530 Kbps nunca elegiría un bitrate de audio mayor que ese. Y para contenido en alta definición a 2 Mbps no hay en realidad diferencia por unos cuantos Kbps de más en el audio. De todas formas me aseguré de que el tamaño del fichero de salida fuese similar al del descargado de YouTube.

Sobre elegir la frecuencia de marcos a 170 —son 6,8 segundos—. En la actualidad el codificador Thusnelda, en fase alfa, directamente acopla la gestión de bitrate a la frecuencia de marcos. Cuando haya una API que permita ajustar ambos parámetros por separado los valores más típicos pasarían a ser de 3 a 5 segundos para la frecuencia de marcos y posiblemente 8 a 10 segundos para la ventana de gestión de bitrate, para estar mejor adecuados a los buffers en el lado de cliente.

Resultados

En las siguientes secciones las capturas de pantalla son del marco 300 en los vídeos. Parece haber un desplazamiento de un marco entre la codificación de YouTube y la mía —a pesar de usar la misma entrada—. El marco 301 de YouTube coincide con mi marco 300 en la salida de Theora, así que cojo ese marco 301 del fichero de YouTube.

480×270

YouTube ~529 Kbps combinado, H.264, descargar (~33,5 MB)

Theora, descargar (~33,2 MB)

A mis ojos ambas codificaciones parecen la misma aunque —quizás de forma inesperada— Theora parece conservar más detalle en la cara, la camisa y el pelo. En esta sencilla prueba con esta configuración declaro ganador a Theora sobre el H.264 de YouTube.

1280×720

—Las capturas de pantalla son demasiado grandes para ponerlas aquí.—

YouTube ~2135 Kbps combinado, H.264, descargar (~134,9 MB)
Theora, descargar (~133,9 MB)

Mucho mejor dado que ambas codificaciones parecen iguales y uno tiene que mirar con cuidado —¡utiliza para esto los vídeos, no las capturas de pantalla!— para notar alguna diferencia. Yo diría que la codificación H.264 de YouTube me presenta algo más de detalle en la camisa, así que ante mis hojos puede que el H.264 de YouTube sea algo mejor que Theora en este caso. Otros a los que he preguntado no han sido capaces de ver diferencias. No importa en realidad.

Mi conclusión personal resulta ser la misma que la de Greg. Es posible ya utilizar Theora para ofrecer streaming en la red sin inflar el bitrate ni reducir dramáticamente la calidad comparando con el formato de codificación H.264 que usan los servicios más populares.

Recuerda que mi comparativa no es científica en forma alguna. Pero espero que de un punto de vista válido si estás pensando en qué configuración de streaming ofrecer.

Visto en Xiph.org.

La idea no es nueva, la descubro en el blog de Stefano Forenza y me permito compartirla. La instalación es posible dado que Ascender, el creador de las fuentes para Android, ha decidido hacerlas disponibles. Dice la nota de prensa de Ascender:

«La familia Droid de fuentes consta de Droid Sans, Droid Sans Mono y Droid Serif. Cada una cubre un extenso conjunto de caracteres incluyendo Europa Occidental, Europa Central y del Este, Báltico, Cirílico, Griego y Turco. La fuente normal Droid incluye también soporte para Chino Simplificado y Tradicional, Japonés y Coreano, GB2312, Big 5, JIS 0208 y KSC 5601 respectivamente. Droid ha sido diseñada por Steve Matteson de Ascender y facilita una calidad óptima y toda la comodidad para su uso en un terminal móvil tanto si es utilizada en menús de aplicaciones, exploradores web o cualquier otro texto en pantalla.»

Las buenas noticias son que las fuentes ya están disponibles en los repositorios oficiales de Jaunty, y que no hay motivo alguno para no instalar el paquete en una versión anterior de Ubuntu como Intrepid, aunque en este caso el método será más complicado. Esto por supuesto no quiere decir que sea buena idea generalmente instalar paquetes de Jaunty en Intrepid, sólo que en este caso no habrá ningún problema con dependencia alguna.

1. Método fácil

¿Estás en Jaunty? Sencillo. Asegúrate primero de tener habilitados los repositorios Universe.

  $ sudo apt-get install ttf-droid
  

2. Método complicado

Si estás en Intrepid, antes que nada descuelga el teléfono y encierra a los niños en el garaje. Ahora descarga el paquete ttf-droid —gracias a Simon Ochsenreither por empaquetar las fuentes— y haz doble clic para instalarlo o utiliza desde una terminal:

  $ sudo dpkg -i ttf-droid_1.00~b112+dfsg-0ubuntu1_all.deb
  

Para activar las fuentes utiliza Sistema, Preferencias, Apariencia y selecciona las nuevas fuentes.

Hecho. Disfruta las diferencias y cuenta en los comentarios si te gusta el cambio. Mira debajo cómo se compara Droid Sans Mono con el Monospace habitual.

¿Cómo integrar mejor con Firefox?

En lugar de cambiar las fuentes en el panel de control, es posible incorporar el siguiente contenido al propio .fonts.conf en la propia carpeta personal así:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- ~/.fonts.conf for per-user font configuration -->
<fontconfig>
  <alias>
    <family>serif</family>
    <prefer>
      <family>Droid Serif</family>
    </prefer>
  </alias>
  <alias>
    <family>sans-serif</family>
      <prefer>
        <family>Droid Sans</family>
      </prefer>
  </alias>
  <alias>
    <family>monospace</family>
    <prefer>
      <family>Droid Sans Mono</family>
     </prefer>
  </alias>
</fontconfig>

De esta forma cualquier petición de las fuentes estándar para cada tipo serif, sans-serif o monospace será traducida por una petición a la correspondiente fuente en Droid. Esto permite una integración mejor con muchas aplicaciones, por ejemplo con la fuente que va a utilizar Firefox para visualizar las páginas. No es buena idea si eres desarrollador web porque en tal caso querrás ver las páginas tal y como la gente las ve realmente.

Alguien sugiere malvadamente que Droid le da a Gnome un aspecto así como tirando a KDE. ¿Qué opinas?

Más sobre Ubuntu Linux en el Planet.

En muchas cosas. En la vida, la cultura, los sistemas políticos o las motocicletas. Pero por supuesto también en los sistemas operativos y las aplicaciones que corren en ellos. En todas estas cosas, la evolución es casi siempre mejor que la revolución.

Escritorio y servidor, son lo mismo. En realidad los usuarios, en casa y en la oficina, no queremos cambiar nada lo suficientemente grande para ser desesperadamente difícil manejarlo. Lo que queremos son mejoras. Limar las preocupaciones. Queremos que tras cada actualización las cosas sean un poquito mejores. Es como funciona la evolución en todas partes, lo que se va viendo como mejor, va cambiando con el tiempo.

Y queremos que las actualizaciones sean algo que puedas hacer en tu tiempo de trabajo sin mayor preocupación, sin inquietudes. Especialmente en un contexto corporativo. El cambio en forma de evolución entre versiones de software no implica gastos indirectos en la planificación, supone requisitos para pruebas menos rigurosos y en general menos preocupaciones para todos. Las actualizaciones deberían ser regulares, parches posiblemente agrupados en service packs pero no descabelladas nuevas características ideadas por viles departamentos de marketing.

En resumen, nos gustan los ciclos de desarrollo como los de Ubuntu y OpenOffice, o Firefox, o —como hacen ahora— KDE. Todos preferiríamos esto, incluso los que seguimos atados a viejos sistemas heredados que no acostumbran a comportarse tan amablemente.

Esas nuevas versiones de software o de sistemas operativos, en forma de grandes pasos adelante, sugieren una mentalidad caduca, la de los viejos sistemas propietarios heredados. Los que nos hemos movido al nuevo modelo no necesitamos que nos «vendan» las actualizaciones porque no tenemos que pagar por ellas. Los cambios incrementales casi siempre nos resultan más cómodos a todos los implicados.

Es el motivo por el que el software libre resulta más amigable para la gente, y también para las organizaciones, independientemente de su paradigma de desarrollo.

Visto en OA – Ubuntu.

La decisión de Microsoft de limitar Windows 7 Starter Edition a la ejecución de sólo tres aplicaciones simultáneas se ha interpretado como un intento de subir el precio de los netbooks.

La compañía anunció la pasada semana que lanzaría Windows 7 Starter Edition como una opción de bajo coste diseñada específicamente para netbooks. Sin embargo, la decisión de la compañía de imponer un límite de tres aplicaciones simultáneas podría forzar a los fabricantes a incorporar la opción más cara Home Premium.

La regla de las tres aplicaciones incluye a las que corren de fondo, lo que significa p.ej. que un usuario corriendo Windows Messenger y Skype podría utilizar sólo una aplicación más en esa máquina. Se excluyen las aplicaciones antivirus de la cuenta.

Microsoft afirma que la restricción ha sido diseñada para asegurarse de que los usuarios obtienen el mejor rendimiento posible del hardware limitado de los netbooks. Se admite sin embargo que su decisión podría animar a los fabricantes a instalar la versión Home Premium sin restricciones.

«Es la decisión de los OEMs elegir entre la Starter Edition o la Home Premium» dijo Laurence Painell, jefe de producto Windows a PC Pro.

«Obviamente recomendamos a cualquiera en el Reino Unido utilizar Home Premium, dado que aquí los netbooks tienen mejores especificaciones. Pero dejamos que ellos decidan».

PC Pro ha instalado Windows 7 Ultimate en dos modelos diferentes de netbook, y ha encontrado que el rendimiento no se ve aparentemente afectado por el hecho de ejecutar múltiples aplicaciones. Fueron incluso capaces de ejecutar paquetes avanzados con comodidad, como el Windows Media Center.

Microsoft niega estar imponiendo una limitacion arbitraria en su Starter Edition para forzar a los fabricantes a adoptar el más caro Home Premium. «Necesitamos dejar claro que hay una diferencia entre Starter Edition y Home Premium y también de que los OEMs tengan clara la elección y permitirles hacerla» afirma Painell.

«Esperamos que los OEMs elijan Starter Edition para sus equipos más básicos y Premium para los de mejores especificaciones».

La compañía afirma que la mayor parte de los usuarios no se verán afectados por el límite de tres aplicaciones. «Hemos realizado un estudio que sugiere que el consumidor medio suele utilizar como máximo dos aplicaciones— reclama Painell. «Esperamos que el límite de tres aplicaciones no afecte a demasiada gente».

No obstante, la propia Microsoft reveló en la Professional Developers Conference del año pasado que el 70% de los usuarios de Windows mantiene entre ocho y quince ventanas abiertas al mismo tiempo. «Pero eso tiene en cuenta a todos los usuarios» dice Painell. «También a los del mundo de la empresa y los negocios, un segmento completamente distinto».

Incluso si los fabricantes deciden optar por la restrictiva Starter Edition para ahorrar costes, los usuarios podrán después actualizarse a Home Premium simplemente comprando una clave para su netbook.

Microsoft, actualmente investigada en los Estados Unidos por confundir a los consumidores con su campaña de pegatinas Vista Capable, afirma estar trabajando con los fabricantes para que el límite de las tres aplicaciones esté perfectamente claro para los compradores en el momento de la compra.

«Está muy claro en las características diferenciadoras que facilitamos que sólo soportamos hasta tres aplicaciones simultáneas» dice Painell. «Queremos estar seguro de que el mensaje les queda claro a nuestros socios y trabajaremos con ellos para que su publicidad sea la correcta para el público general».

Starter Edition ya incorporaba un límite de tres aplicaciones simultáneas en Windows Vista, pero esa versión no llegó a estar disponible para su venta en Europa.

Visto en Windows 7 a non-Starter on netbooks publicado en PC Pro.

Algunos nos dicen que deberíamos haber utilizado una versión descargada desde Mozilla y compilada por nosotros. No estamos de acuerdo, dado que la mayor parte de los usuarios de Linux utilizan software de su gestor de paquetes, y no se bajan otro tipo de cosas de la red. Otros nos han dicho que hubieramos debido probar también Opera. Por último hay quien nos cita que los drivers nVidia, AMD o Intel son los que ralentizan Linux.

De cualquier forma, pensamos en realizar un par de pruebas benchmark rápidas adicionales para ver si podíamos eliminar alguna de esas variantes. No tenemos tiempo para una suite completa desde cero, así que hemos realizado sólo unas pocas pruebas rápidas para ver qué encontramos.

Lo que necesitas saber es:

• Estas pruebas fueron ejecutadas en el mismo ordenador utilizado para las anteriores, con su misma instalación de Fedora 10
• Hemos probado con Mozilla Firefox para Linux tal cual es posible descargarlo desde Mozilla
• Hemos probado también Mozilla Firefox para Windows tal cual es posible descargarlo desde Mozilla, pero corriendo sobre WINE en Fedora.
• Hemos instalado y probado Opera 9.63 para Fedora 10, tal cual es posible descargarlo desde Opera.com. Nota: Sólo hemos encontrado binarios para i386 en el sitio de Opera, y esto no es óptimo, así que si alguien nos dice dónde descargar binarios para i686 de Opera para Fedora 10, actualizaremos con gusto el artículo.
• Hemos ejecutado el benchmark Google V8, como otras veces.

Para ser muy claros: Hemos tomado el Firefox de Windows y lo hemos corrido en Fedora Linux utilizando el WINE 1.1.12 de su gestor de paquetes. Con esta información, así es como quedan los resultados.

Como conclusión: Firefox de Mozilla o de Fedora tienen diferencias de velocidad insignificantes, pero Firefox para Windows corriendo en WINE es más rápido que el Firefox nativo. Opera queda por detrás, pero nos inclinamos a pensar que sus números serían mejores con un binario más optimizado.

¿Cuál es la moraleja? Esperamos comentaristas afirmando que el motivo es claramente un fallo de los drivers de nVidia, ATI o cualquier otro. Vamos, chicas, probadlo por vosotras mismas. Si usas Linux, instala WINE, prueba el Firefox de Windows y saca tus propias conclusiones.

Visto en Browser benchmarks 2: even Wine beats Linux Firefox publicado en TuxRadar vía Slashdot.

Los estándares web abiertos han evolucionado considerablemente con los años, y la compatibilidad entre navegadores es mejor que nunca, pero un área importante donde los estándares aún están poniéndose al día es el streaming de vídeo. Los plug-ins propietarios se utilizan extensívamente para reproducir el contenido de los sitios más populares. Esto crea riesgos de bloqueo importantes y les da a los vendedores de software propietario como Adobe demasiado control sobre el medio.

Aunque alternativas como el Silverlight de Microsoft están empezando a cambiar las reglas y a forzar a Adobe a abrirse, aún no hay una alternativa basada en estándares independientemente comercialmente y lo suficientemente viable como para desplazar el equilibrio hacia el usuario y romper los muros que limitan aún cómo se experimentan los contenidos de vídeo en la red. Mozilla y la Wikimedia Foundation han lanzado una iniciatova para ayudar a mejorar la calidad de las tecnologías de vídeo abiertas y basadas en los estándares.

Mozilla ha donado 100.000 dólares a la Wikimedia Foundation con la idea de ayudar al desarrollo del contenedor Ogg y de los codecs de medios Theora y Vorbis. Estos codecs abiertos no están protegidos por patentes, lo que significa que pueden ser libremente implementados y utilizados sin la necesidad de pagar royalties o licencias a los propietarios de dichas patentes. Esto diferencia a Ogg Theora del resto de los formatos más utilizados hoy en día.

Las mejoras en el desarrollo de Ogg estarán coordinados por la Wikimedia Foundation. La organización utiliza Ogg para la práctica totalidad de sus medios, lo que les hace los mayores impulsores de los formatos de medios abiertos en la Internet. En una sentencia publicada en el sitio web de la organización, el director Erik Möller expresa su apoyo por la iniciativa y explica que los formatos abiertos son necesarios para garantizar la disponibilidad de contenidos libres en formatos no restringidos.

«Los estándares abiertos para audio y vídeo son importantes porque pueden ser utilizados por cualquiera para cualquier propósito sin royalties y pueden ser inspeccionados y mejorados por la comunidad. Hoy en día, el vídeo y el audio en la red son dominados por tecnologías propietarias, muy frecuentemente codecs protegidos por patentes proporcionados en reproductores de código cerrado» escribe Möller. «Wikimedia y Mozilla quieren ayudar a construir una web donde vídeo y audio son ciudadanos de primera; fáciles de usar y de manipular por cualquiera, sin esquemas de royalties restrictivos o cualquier otra barrera a la participación».

Mozilla integra soporte para el formato Ogg directamente en Firefox 3.1, así que la siguiente versión del popular navegador abierto será capaz de reproducir medios Ogg sin necesidad de plug-ins ni software externo. El formato Ogg vendrá soportado por la implementación del elemento de vídeo HTML 5, lo que permitirá que el vídeo se intercale sin problemas con el contenido HTML convencional y que se manipule utilizando DOM. Mozilla ha demostrado recientemente el elemento de vídeo siendo utilizado para streaming. Opera está también integrando el soporte a vídeo basado en estándares en su navegación y dispone ya de una implementación funcional de Ogg para HTML 5.

Aunque la tecnología empieza a implantarse, llevará tiempo que el estándar se soporte lo suficientemente como para intimidar a los sitios que ya difunden medios. La falta de soporte a DRM inherente en una implementación abierta impedirá también la adopción por parte de los principales creadores de contenidos. Las soluciones basadas en estándares podrían no poder desplazar a Flash nunca, pero los primeros pasos para que exista la posibilidad ya han sido dados.

Visto en Mozilla contributes $100,000 to fund Ogg development publicado en Ars Technica.