Akraino: ¿qué es este proyecto de código abierto?

Akraino logo

No es la primera vez que se habla de Akraino Project en este blog, pero quizás siga siendo un desconocido para muchos. Por supuesto es un proyecto de código abierto, una pila que está destinada a mejorar el estado de la infraestructura de la nube en el borde para las redes de operadores, proveedores y de IoT. Un proyecto bajo el paraguas de la Linux Foundation, como tantos otros que van complementando ese enorme ecosistema abierto que gana poco a poco terreno en diferentes ámbitos.

Con Akraino se obtiene nuevos niveles de flexibilidad para escalar rápidamente los servicios de la Edge Computing o computación en el borde, así como maximizar las aplicaciones o suscriptores admitidos en cada servidor, y ayudar a garantizar la fiabilidad de los sistemas que están activos en cada momento. Algo vital teniendo en cuenta la enorme importancia de la nube y los dispositivos conectados en la actualidad y en un futuro próximo…

Sobre Akraino

También proporciona potencia de procesamiento más cercana a los dispositivos que están conectados a la nube como clientes para así cumplir con los requisitos de latencia de la aplicación. Es decir:

  • Mayor velocidad y reducción de la latencia en este tipo de sistemas en el borde.
  • Mejora la disponibilidad de los servicios.
  • Reduce los gastos generales de este tipo de implementaciones.
  • Proporciona escalabilidad para ampliaciones.
  • Aborda las necesidades de seguridad de los sistemas actuales, algo clave.
  • Mejora la gestión de fallos.
  • Además, ahora LF ha anunciado el Release 3, con nuevas mejoras al respecto.

La comunidad de desarrolladores del proyecto Akraino se centra para ello en aportar una API para desarrolladores (Edge y Middleware), kits de desarrollo de software (SDK) y trabajan para la interoperabilidad multiplataforma con nubes de terceros.

Si quieres conocer más, te recomiendo leer nuestro artículo sobre el lanzamiento de este proyecto.

from Linux Adictos https://ift.tt/3fZnIHK
via IFTTT

SimulIDE: tu simulador de electrónica favorito… a partir de ahora

SimulIDE

En muchos blogs lo venden como un simulador de Arduino, pero SimulIDE es mucho más que eso. Es un gran programa para los amantes de la electrónica, DIY, y makers, así como para estudiantes. Quizás te suenen programas como los de Crocodile Technology para Windows que te permitían simular circuitos, y que se solían usar en algunas escuelas e institutos en las asignaturas de tecnología. Pues SimulIDE es algo así…

Su interfaz es muy sencilla, tan solo tienes una columna a la izquierda con todos los componentes que puedes ir arrastrando para insertar en el panel de la derecha para crear los circuitos que necesites. Tienes desde componentes electrónicos básicos, como resistencias, transistores, interruptores, fuentes de alimentación, toma de tierra, condensadores, etc., hasta otros complejos como placas de Arduino, pantallas LCD, etc.

Sobre SimulIDE

Pero no solo permite insertarlos sin más como otros programas como Fritzing. En SimulIDE también puedes probarlos. Por ejemplo, montar crear un circuito con puertas lógicas, interruptores y LEDs e interaccionar con los interruptores y demás para ver los LEDs encenderse, etc. Esto es una característica muy práctica que permite probar un circuito digitalmente antes de arriesgarse a hacerlo en la práctica y que no funcione o que algún componente resulte dañado (o simplemente porque no dispongas de esos componentes físicos).

Por supuesto, está disponible para Linux y otras plataformas. En Linux tienes la opción de descargar el paquete tarball (tar.gz) con el binario, o de descargar directamente un paquete universal AppImage al que simplemente le tendrás que dar permiso de ejecución, hacer doble clic sobre él y se abrirá el programa listo para usar…

Así que sin más que decir, si quieres comenzar a usar este fantástico proyecto, puedes descargar el paquete o las fuentes desde la web oficial del proyecto (está en algunas tiendas de apps, pero en versiones algo desfasadas).

from Linux Adictos https://ift.tt/2E8ahYS
via IFTTT

Linux App Summit: lo que necesitas saber sobre el evento

Linux App Summit

Si estás interesado en ayudar a hacer GNU/Linux una gran plataforma para usuarios finales, entonces quizás deberías apuntarte el nombre del evento Linux App Summit y reservar las fechas del 12-14 de noviembre de 2020 en el calendario de tu agenda. Y aunque tenga el lugar marcado (Barcelona, España), el evento será online por los tiempos de pandemia en los que vivimos inmersos.

Si quieres conocer todos los detalles, puedes visitar el sitio oficial de Linux App Summit. Un evento cuyos anfitriones son dos grandes bien conocidos por todos, ya que en él han trabajado KDE y GNOME para prepararlo todo y hacer de Linux un entorno mucho mejor en un futuro.

Creo que nos vamos a tener que ir acostumbrando a los eventos online hasta que no haya una solución para la enfermedad del SARS-CoV-2. Sin una vacuna fiable por el momento, ni tampoco tratamiento, los eventos masivos son un riesgo enorme. Más aún cuando reúnen a gente de multitud de países…

En LAS encontrarás multitud de actividades interesantes, como numerosas e interesantes charlas. Los temas a tratar versan sobre creación, empaquetado, distribución de apps, innovación, monetización en ecosistemas Linux, y mucho más.

Además, han anunciado recientemente que su «call for Talks» está abierto y puedes unirte y aportar ideas hasta el 15 de septiembre. Los elegidos serán anunciados el 1 de octubre de este año.

Animan también a nuevos speakers, y no solo los que ya tengan experiencia en charlas previas. Así que si tienes una buena idea, es lo único que necesitas para unirte a Linux App Summit.

Seas uno de los que hará una de las charlas en este evento online, o simplemente un interesado, recuerda que en noviembre tienes cita para disfrutar desde un lado o desde el otro (o ambos) de todo lo que aquí se va a ofrecer.

from Linux Adictos https://ift.tt/311k23V
via IFTTT

Steam Game Festival: ¿estás preparado para el gaming?

Steam Game Festival

¿Otro? Sí, otro Steam Game Festival 2020. Así que si te gustan los videojuegos, debería ir haciendo hueco en tu disco duro y prepararlo todo para este festival del gaming. Una auténtica maravilla para los gamers. Y es que tras el éxito del evento de junio, se volverá a repetir con una nueva ronda a finales de este año, en octubre.

Así que todos los usuarios del cliente Steam de Valve podrán jugar a través de un montón de demos de videojuegos por tiempo limitado. Diversión gratuita para todos, una gran idea que comenzó en diciembre de 2019 y ha tenido muy buena acogida. En aquel momento se hizo para acompañar a los The Game Awards, pero debido a lo que gusta, se ha seguido repitiendo.

Ahora el grupo de desarrollo Steamworks ha confirmado que las fechas del evento serán del 7 al 13 de octubre. Además, Valve mencionó que pronto abrirían las suscripciones para los desarrolladores que quieran participar en el evento. Una buena oportunidad de mostrar una demo del trabajo y conseguir que muchos jugadores vean su obra.

Estos desarrolladores no cuentan con mucho tiempo, ya que la suscripción solo estará abierta entre el 19 y el 26 de agosto. Además, para que sean títulos elegibles, los videojuegos tienen que tener fecha de lanzamiento establecida entre el 13 de octubre de 2020 y el 1 de mayo de 2021.

Como ocurrió en el último evento Steam Game Festival, en esta ocasión también se contará con transmisiones en vivo, sesiones de preguntas y respuestas, etc.

Y si te interesan este tipo de eventos de entretenimiento para Linux y otras plataformas, debes saber que Valve también anunció más Steam Game Festivals para el futuro. En 2021 también los habrá, pero por el momento hay que esperar a que vayan revelando más detalles. Parece que será ya algo habitual año tras año…

from Linux Adictos https://ift.tt/2Y4YL7w
via IFTTT

Debian cumple 27 años siendo una de las distribuciones más influyentes

Debian cumple 27 años

Si hay que citar las distribuciones Linux más influyentes de la historia, sin dudas no podemos dejar de nombrar a Debian. Hoy 16 de agosto se cumplen 27 años del día en que un estudiante de la Universidad de Purdue, Ian Murdock anunciara su lanzamiento.

27 años de Debian. Así empezó todo

El 16 de agosto de 1993 Ian Murdock publicó el siguiente texto

Compañeros Linuxeros,

Esto es para anunciar la inminente liberación de una nueva versión de Linux a la que llamo Debian Linux. Esta es una versión que he creado prácticamente desde cero; en otras palabras, no hice simplemente algunos cambios a SLS (Softlanding Linux System) y lo llamé un nuevo lanzamiento. Se me ocurrió crearla después de ejecutar SLS y en general estar insatisfecho con gran parte de ella y después de hacer  muchas modificaciones a SLS decidí que sería más fácil empezar desde el principio. El sistema base está ahora virtualmente completo (aunque todavía estoy revisando para asegurarme de que he cogido las fuentes más recientes para todo), y me gustaría tener alguna retroalimentación antes de añadir el material «elegante».

Tengan en cuenta que este lanzamiento aún no está terminado y puede que no lo esté por varias semanas más; sin embargo, pensé en publicar ahora para quizás atraer a algunas personas. Específicamente, estoy buscando:

1) Alguien que eventualmente esté dispuesto a permitirme subir la distribución a su sitio ftp anónimo. Por favor, contácteme. Les advierto que será bastante grande.

2) Comentarios, sugerencias, consejos, etc. de la comunidad Linux. Esta es su oportunidad de sugerir paquetes específicos, series, o cualquier cosa que quieras ver como parte del lanzamiento final.

No crean que porque un paquete esté en SLS necesariamente será incluido en la versión de Debian! Cosas como ls y cat son un hecho, pero si hay algo en SLS sin lo que no podrías vivir, por favor, déjenme saber.

Más adelante establece los objetivos del proyecto

  1. Debian será más elegante y delgado. No más binarios ni páginas de manual múltiples
  2. Debian contendrá lo más actualizado de todo. Será fácil mantener actualizado el sistema con un script de «actualización» en el sistema base que permitirá la integración completa de paquetes de actualización.
  3. Debian contendrá un procedimiento de instalación que no necesitará supervisión; simplemente bastará con instalar el disco base, copiar el resto de los discos de la distribución al disco duro, responder a algunas preguntas sobre los paquetes que quieres o no quieres instalar, y dejar que la máquina instale la distribución mientras haces cosas más interesantes.
  4. Debian contendrá un procedimiento de configuración del sistema que intentará configurar todo, desde fstab a Xconfig.
  5.  Debian hará Linux más fácil para los usuarios que no tienen acceso a Internet. Los usuarios que no tengan conexión a Internet tendrán la opción de recibir paquetes de actualización periódica para aplicar a su sistema. Ellos también tendrán la opción de seleccionar desde una enorme biblioteca de paquetes adicionales que no se incluirán en la base del sistema.
  6. Debian estará documentado extensamente

En el sitio de Debian hay una excelente explicación en español sobre la historia y propósitos del proyecto Debian. Dado que no puedo agregarle nada de valor, lo mejor que puedo hacer es invitarte a que la leas.

Si voy a contar lo que no aparece en la cronología.

En el año 2014 se desató en el seno de la comunidad Debian una de esas discusiones a la que es tan afecta la comunidad del software libre. En este caso, el tema de la discordia fue una encuesta sobre que usar como sistema de inicio. En Linux, el sistema de inicio es el proceso que se inicia inmediatamente después de la carga del kernel y se encarga de iniciar todos los demás procesos que permiten utilizar el sistema operativo.

A muchos desarrolladores les cayo mal que el elegido fuera sistemd, una pieza de software que sus críticos consideran demasiado compleja, poco respetuosa de los principios de diseño generalmente aceptados por la comunidad y que podría convertirse en una opción monopólica.

Es así que varios miembros de la comunidad decidieron escindirse y crear otro proyecto llamado Devuan

Devuan viene en versiones para escritorio (XFCE, MATE, Cinnamon, LQxt y KDE). También cuenta con una versión para servidores y un instalador desde la red.

from Linux Adictos https://ift.tt/30ZiKGI
via IFTTT

La PineTab se retrasa otra semana y se podrá volver a reservar a finales de agosto, entre otras noticias de PINE64

PineTab Reloj de arena

Ya lo dijimos a finales de julio: si compraste una PineTab, ármate de paciencia. En ese momento, PINE64 informó a la comunidad de que merecía la pena retrasar los envíos porque el software original incluía un driver al que ya le quedaba poco tiempo de soporte. Esta vez, el problema es otro, uno de hardware o de diseño: los botones de volumen estaban del revés, por lo que la PineTab retrasará su lanzamiento otra semana.

Lo cierto es que la espera se está haciendo larga, pero los motivos son de peso. El primero nos permitirá disfrutar del driver para el panel LCD durante más tiempo desde el principio. Este segundo tendrá lugar porque habían intercambiado los botones de volumen en el cable flex. Aunque la compañía reconoce que esto podría solucionarse fácilmente con un cambio de software, han decidido hacer las cosas como es debido, porque lo que está bien hecho siempre estará bien hecho.

La PineTab empezaría a enviarse el 28 de agosto aproximadamente

Tras el retraso anterior, la PineTab debía empezar a enviarse el 21 de agosto, pero el problema del cable flex y los botones de volumen hará que sea justo ese día cuando le lleguen las unidades a PINE64. La compañía dice que lo enviara lo más pronto posible, pero también que habrá otra semana de retraso, por lo que los envíos empezarían a realizarse el 28 de agosto aproximadamente.

Otra noticia interesante relacionada a la PineTab es que podrán volver a reservarse a finales de este mes. En cuanto a otras noticias relacionadas a PINE64, este es el resumen de lo sucedido durante este mes:

  • Se acercan reglas nuevas y claras de participación comunitaria.
  • Infracciones de marca y logotipo de PINE64.
  • La producción de Pinebook Pro está a tiempo; la fábrica les entregará PBP el 24 de agosto.
  • El Pinebook Pro está recibiendo soporte de Odin para elementary OS 6.
  • Un vistazo a la estación de acoplamiento Pinebook Pro USB-C; esperando soporte de software.
  • Placas de expansión de expansión RTL-SDR y LoRa para PineTab.
  • Última oportunidad para obtener el postmarketOS CE: agotado en cualquier momento.
  • PinePhone: están en una buena racha y no van a desacelerar (hasta CNY).
  • Mods de hardware de la comunidad PinePhone y proyectos increíbles.
  • Están explorando opciones de teclado para PinePhone.
  • Desarrollos notables del software PinePhone.
  • Pinecil llegará en septiembre; un tipset estará disponible en el lanzamiento.
  • Respuesta positiva de PineCube; disponible en septiembre/principios de octubre.
  • Accesorios PineCube – panel LCD y batería.

Tenéis información más detallada en el boletín de agosto de PINE64 (en inglés).

from Linux Adictos https://ift.tt/3474CgE
via IFTTT

GNOME 3.38 Beta ya disponible, preparando el lanzamiento de septiembre

GNOME 3.38 Beta

Esta semana, los desarrolladores que están detrás de uno de los entornos gráficos más populares de los existentes en Linux han lanzado la v3.36.5 de su escritorio. Esa fue la quinta y penúltima versión de mantenimiento de la serie y llegó para corregir errores en las aplicaciones y el entorno en sí. Hace unas horas, el proyecto ha lanzado GNOME 3.38 Beta, la primera muestra del próximo lanzamiento que ya puede probar cualquier interesado.

Siendo más concretos y fieles a la verdad, lo que han lanzado es GNOME 3.37.90, pero esa es la numeración oficial de la versión del entorno que llegará el 16 de septiembre. Poco después empezarán a incluirla en las diferentes distribuciones Linux, entre las que destaca Ubuntu 20.10 Groovy Gorilla, tanto por ser un sistema operativo muy popular como porque colabora en el desarrollo del escritorio.

Novedades más destacadas de GNOME 3.37.90, AKA 3.38 Beta

  • GNOME Shell:
    • Ahora permite reorganizar elementos en el selector de aplicaciones.
    • La transmisión de pantalla se ha movido a un servicio separado
    • Se han añadido unas «Opciones de arranque» al cuadro de diálogo de reinicio.
    • El comportamiento predeterminado es no instalar actualizaciones con poca batería.
    • Varias correcciones.
  • Mutter
    • Mejoras de screencast.
    • Corrige las sombras de las ventanas XWayland decoradas del lado del servidor
    • Varias mejoras de Wayland.
  • Renovación de la pantalla de bienvenida de la configuración inicial de GNOME.
  • Epiphany, el navegador, ha recibido muchas novedades, como
    • Compatibilidad con servidores de sincronización autohospedados.
    • Un importante rediseño del cuadro de diálogo de preferencias.
    • Base de solicitud de permiso para el manejo de WebRTC.
    • Mejoras de estilo.
    • Bloqueo de ventanas emergentes de forma predeterminada.
  • GSettings-Desktop-Schemas ha habilitado la protección USB de forma predeterminada.
  • Cuadro de diálogo de atajos de teclado para File-Roller junto con nuevos atajos.
  • El administrador de pantalla GDM tiene actualizaciones para su integración systemd.
  • Nuevas funciones de JavaScript para GJS.
  • Glib-Networking tiene correcciones en su back-end OpenSSL.
  • GNOME Boxes ha añadido un editor para la configuración de libvirt VM.
  • La interfaz de usuario adaptable funciona y mejora la navegación con el teclado para GNOME Maps.

Más información y descarga en la nota de su lanzamiento.

from Linux Adictos https://ift.tt/311Pjnt
via IFTTT

MTR: una herramienta de diagnóstico de red para Linux

mtr

Linux-console.net

Si no conocías esta herramienta, hoy te hablamos de MTR (Matt’s TraceRoute). Se trata de una herramienta de línea de comandos multiplataforma (disponible para Linux), escrita en C, libre, y con la que podrás monitorizar ciertos aspectos de tu red y también diagnosticar problemas de conexión. En ella se combinan las funciones de otras dos conocidas herramientas de red, como son traceroute y ping.

Es decir, como si tuvieras esas dos herramientas en una sola, solo que con MTR verás aún más información que con traceroute. De hecho, podrás ver el camino hasta una máquina remota, pero también los porcentajes de respuesta (ping), y tiempos en cada uno de los lagos de red en la ruta trazada entre el sistema remoto y el local.

Cuando se ejecuta MTR, probará la conexión de red desde local al host remoto que hayas especificado. Establecerá primero la dirección de cada salto de red (puentes, enrutadores, puertas de enlace, etc.), y luego hará un ping, es decir, enviará una secuencia de solicitudes ICMP ECHO a cada uno de esos saltos para determinar el tiempo de respuesta. Mientras esto sucede, generará unas estadísticas útiles sobre cada máquina y se actualizarán en tiempo real, mostrando una interesante información en pantalla.

MTR se encuentra en los repos de las distros más conocidas, por tanto, puedes usar el nombre mtr del paquete con tu gestor de paquetes favorito para instalarla. Una vez la tienes instalada, su ejecución es sencilla. Puedes usarla con nombres de dominios de máquinas (google.es, linuxadictos.com,…) o con IPs. Además, cuenta con muchas opciones para modificar su salida y obtener justo lo que buscas.

Por ejemplo, aquí tienes algunas muestras de comandos para que puedas ver la sencillez de uso:


mtr google.es

mtr -n linuxadictos.com

mtr -m 35 168.192.44.4

mtr -r -c 5 test.com > informe.txt



Recuerda que<strong> para salir del modo interactivo</strong> puedes pulsar la tecla Q o Ctrl+C.

Y para <strong>más información</strong> sobre opciones:



man mtr

Más información – MTR

from Linux Adictos https://ift.tt/3kNWsiZ
via IFTTT

Menos diversión, más negocios. El casi fin de la cultura hacker

Menos diversión, más negocios

La década del 80 fue casi el fin de  la «cultura hacker». Lejos del contexto negativo que Hollywood y los medios le darían, ser hacker no significaba acceder sin autorización al sistema o al código de un programa. Para merecer el nombre de tal, uno debía ser capaz de tomar un programa de libre disponibilidad y hacerle mejoras significativas.

Como dijimos en el artículo anterior, era habitual que las empresas les dieran a los hackers de las universidades acceso prioritario a los nuevos equipos incluyendo el código fuente de los programas que los hacían funcionar. De esta forma se garantizaban no solo ponerlos a prueba si no acceder de forma gratuita a las mejoras que estos introducían.

Pero, a medida de que el desarrollo de software comenzó a convertirse en un negocio por si mismo, quienes ganaban dinero con él, empezaron a presionar para que se pudieran trabas a la libre distribución. Esto incluía no solo trabas legales como las licencias, si no también trampas en el código.

Brian Reid era un estudiante de doctorado en la universidad Carnegie Mellon. Reid fue el creador de Scribe, un software que permitía formatear y elegir tipografías para documentos enviados a traves de una red.

Reid no tenía muchas ganas de que otros se beneficiaran de su trabajo, al menos no en forma gratuita. Por eso se lo vendió a una empresa llamada Unilogic. Para que el negocio fuera rentable para los nuevos propietarios incluyó en el programa una subrutina que lo desactivaba a los 90 días. Salvo claro, que se insertara el código que Unilogic proveía a cambio de un pago.

Si la imposibilidad de acceder al código fuente del controlador de la impresora fue lo que colmó la paciencia de Richard Stallman, lo de Reid fue el punto de partida.

Menos diversión, más negocios. Stallman cuenta su experiencia

En una charla dada en 1986 Stallman cuenta cómo vivió lo que pasaba

A principios de los 80, los hackers se dieron cuenta de que había un interés comercial en lo que estaban haciendo. Era posible hacerse rico trabajando en una empresa privada. Todo lo que era necesario era dejar de compartir su trabajo con el resto del mundo…

Esencialmente todos los programadores competentes, excepto yo, en el laboratorio de IA del MIT fueron contratados, y esto causó más que un cambio momentáneo, causó una transformación permanente porque rompió la continuidad de la cultura de los hackers. Los nuevos hackers siempre se sentían atraídos por los viejos hackers; había los ordenadores más divertidos y la gente que hacía las cosas más interesantes, y también un espíritu del que era muy divertido formar parte. Una vez que estas cosas se pierden, no hay nada que haga interesante el lugar a nadie nuevo, así que la gente nueva dejó de llegar. No había nadie en quien pudieran inspirarse, nadie de quien pudieran aprender esas tradiciones. Además, nadie de quien aprender a hacer una buena programación. Con sólo un puñado de profesores y estudiantes graduados, que realmente no saben cómo hacer que un programa funcione.

En los 80, las consolas de videojuegos y las computadoras hogareñas y personales se habían extendido por los hogares y empresas. Miles de títulos se distribuían almacenados en casetes, disquetes y cartuchos. Todos tenían alguna forma de disuadir la libre distribución, ya sea imprimiendo los manuales en colores difíciles de fotocopiar, haciendo campañas publicitarias o insertando algo enel código como en el caso de Scribe insertando bombas de tiempo lógicas.

La cultura hacker, tal cual la entendía Stallman, parecía muerta para siempre a manos de empresas como Microsoft que vendían sus productos bajo licencia. Sin embargo, décadas después la historia volvería a girar la rueda.

Esta serie de artículos comenzó a raíz de un hilo de Stephen Sinofsky, el ex responsable de WIndows y Office. Sinofsky sostiene que Microsoft tuvo que cambiar su actitud con respecto al código abierto debido a que al dejar de distribuirse el software en formato físico, ya no era viable el modelo del cobro de licencias.

Más allá de lo que dijo Sinofsky, tenemos que señalar que gracias a Stallman, una nueva generación de hackers había surgido con los mismos viejos principios de los originales. La programación por amor a la programación y el desafío a hacer mejor lo que otros habían hecho, hicieron posible la aparición de herramientas como las del proyecto GNU, Linux, Python y otras que hoy lideran en campos como la nube o la inteligencia artificial.

from Linux Adictos https://ift.tt/2Y3BnHD
via IFTTT

Stallman y la impresora. El orígen de las licencias libres de software

Stallman y la impresora

Habíamos terminado nuestro artículo anterior en la década del 80 cuando el hardware había dejado de convertirse en algo sin valor comercial para transformarse en un negocio rentable, y, una de las principales proveedoras, la empresa AT&T había comenzado a cobrar por las actualizaciones a un mercado cautivo de gobiernos y universidades.


Aún hoy, cuando el uso de documentos impresos está disminuyendo, las impresoras siguen siendo un dolor de cabeza. Papel atascado, cartuchos de tinta que se acaban con sospechosa celeridad y cuestan más que un riñón, controladores que no funcionan al actualizar el sistema operativo y podríamos seguir la lista.
Cuando esto pasa, la mayoría de nosotros nos limitamos a insultar a las señoras Hewlett y Packard o a desear que el COVID se pegue una vuelta por la sede de Epson, claro que la mayoría de nosotros no somos Richard M Stallman.

Stallman y la impresora. La historia que cambió todo

A principios de los 80, Stallman era un programador veinteañero integrante del Laboratorio de Inteligencia Artificial del Instituto Tecnológico de Massachusetts. Cierto día envió a la impresora láser del laboratorio, un documento de 50 páginas. Cuando lo fue a buscar, varias horas después, encontró que no solo no se había impreso su documento, si no que todavía no se había completado la impresión de un trabajo anterior.

No era la primera vez que la máquina lo obligaba a interrumpir su trabajo, por lo que se sintió tentado a hacer algo al respecto. Dado que no era experto en hardware, debería ingeniárselas para encontrar la solución de otra forma.

Contra lo que podría pensarse, no se trataba de un dispositivo obsoleto. Donada a la universidad por la Xerox Corporation, se trataba de un prototipo de la línea de impresoras que comercializaría la compañía.

Al principio todo había funcionado bien. La máquina imprimía con mayor precisión los gráficos que la que usaban antes y reducía en un 90% los tiempos de impresión. El problema, descubierto más adelante, eran los atascos frecuentes de papel.

La impresora era un diseño derivado de una fotocopiadora, es decir de un equipo que tiene un operador al lado cuando se lo hace funcionar. En el caso de la fotocopiadora, los atascos de papel no es un problema demasiado grave. Pero, para una impresora que opera en forma automática y remota constituía un inconveniente grave. A esto hay que sumarle que la impresora tenía que atender la demanda de varios usuarios.

Stallman había solucionado el problema con la impresora anterior creando un software que la monitoreaba periódicamente e informaba a cada usuario con un trabajo de impresión en espera cuando había un problema. Dado que ninguno de ellos sabía si otro había recibido la notificación, era seguro que alguien iba a ir a arreglarla.

Al tratar de hacer lo mismo con el modelo de Xerox, Stallman se encontró con que en lugar de proporcionar el código fuente bien documentado, la empresa había entregado el software de la impresora en paquetes precompilados.

Stallman aprovechó un viaje a la universidad Carnegie Mellon para hablar con un colega que trabajaba como desarrollador de productos de Xerox para pedir una copia del código fuente que le fue negada.

Hoy por hoy, el pedido de Stallman nos puede parecer fuera de lugar, pero en los 80 la norma de poner restricciones a la distribución del software era algo nuevo. Uno de los motivos por los que las empresas donaban hardware a los laboratorios de investigación informática era porque sabían que los programadores iban a desarrollar mejoras que las empresas podrían trasladar sin cargo a los clientes. De hecho, a nadie le importaba que otros tomaran un software sin permiso y les hiciera mejoras. Bastaba con que esas mejoras también estuvieran disponibles para todo el mundo.

De todas formas, tengamos en claro que lo de la impresora fue el último de una serie de acontecimientos que darían un giro a la vida profesional de Stallman. Él ya había empezado a darse cuenta del fin del paradigma que había guiado el desarrollo del software desde la Segunda Guerra Mundial, la libre disponibilidad del código fuente.

Sin poder soportar la idea de que alguna vez fuera él quien se viera obligado a negar el código fuente a otra persona, decidió que había llegado el momento de hacer algo.

Pero, eso será motivo de otro post.

from Linux Adictos https://ift.tt/31ZmF5u
via IFTTT