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

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

Continuando con esta serie de historias sobre como llegamos hasta Linux, vamos a ocuparnos del software y sus licencias

. Habíamos visto como en los 60, la necesidad de competir de igual a igual a la URSS llevó a los Estados Unidos a buscar la cooperación interuniversitaria creando una red que uniera a los diferentes centros de investigación, y, como los desarrolladores de dicha red crearon una metodología de trabajo que después adoptarían las comunidades de proyectos de software libre. Gracias a esa metodología en los 70 se desarrolló un protocolo común para todos los tipos de conexiones.

Hoy es imposible encontrar un lugar donde no haya una computadora. Pero, en los comienzos era algo parecido a lo que hoy sería un avión de pasajeros. El propio Thomas Watson, fundador de IBM había dicho en 1949

Yo creo que hay un mercado mundial tal vez para 5 computadoras.

Para rentabilizar la investigación, desarrollo y producción de estos equipos fue necesario buscar formas alternativas de comercialización. Para aquellas empresas que no se podían permitir comprar o alquilar un equipo, surgió la opción de alquilar el tiempo de uso y proporcionar los conocimientos técnicos

Bajo esta metodología los clientes entregaban a las empresas de informática los datos que era necesario procesar y las instrucciones sobre cómo hacerlo y recibían el resultado en forma impresa varios días después. Originalmente el procesamiento se hacía de a uno en uno. El llamado procesamiento por lotes.

Cómo llegamos hasta Linux. Compartiendo software y hardware

A fines de la década del 50 se inventó el primer sistema de tiempo compartido que permitía a una computadora hacer otra tarea mientras esperaba la respuesta de una impresora u otro dispositivo conectado. Esto disminuyó considerablemente los tiempos de procesamiento.

Pronto, las empresas que habían comprado o alquilado una computadora descubrieron que ellos también podían alquilar sus equipos durante el tiempo no utilizado. Esto era tan rentable que no solo amortizaba el costo de compra si no que resultaba una buena fuente de ingresos.

A los ingresos por el uso del ordenador y asesoramiento técnico se fueron sumando otros. Cuando fue posible acceder a las computadoras en forma remota se agregó el alquiler de espacio para el almacenamiento de datos, las líneas telefónicas especiales para mantener un enlace directo, y de las terminales que permitían el acceso.

Algunos clientes necesitaban un software no estándar para el procesamiento de datos. Ese programa podía ser desarrollado por el propio cliente o por la empresa que proveía el servicio. Algunas de estas descubrieron que un programa desarrollado por un cliente podía adaptarse sin problemas a las necesidades de otros clientes. A cambio del pago de una regalía al desarrollador original comenzaron a ofrecerlo como un servicio adicional. Habían nacido las licencias de software.

Para entender el cambio de paradigma que significó este concepto, tenemos que recordar que los principales fabricantes de computadoras habían sido antes fabricantes de maquinaria de oficina que eran fundamentalmente mecánicas. La idea que podía comercializarse algo intangible nunca había pasado por su cabeza. Por otra parte, las grandes desarrolladoras de software fueron las universidades estadounidenses, en aquel momento más interesadas en compartir conocimientos que en generar divisas.

A medida que la provisión de software mediante licencias fue convirtiéndose en un negocio, quienes ganaban plata con él comenzaron a sentirse molestos con las fabricantes de hardware y su costumbre de proveerlo en forma gratuita. Incluso el gobierno norteamericano calificó esta práctica de anticompetitiva en un juicio antimonopólico contra IBM.

Cuatro años más tarde, en 1974, Estados Unidos incluyó al software como sujeto de derecho de autor ya que era “la creación original de un autor”.

Para esa época AT&T (una empresa que va a tener un par de artículos para ella sola) comenzó a distribuir las primeras versiones de su sistema operativo Unix en forma gratuita a gobiernos y universidades, pero sin autorizar la redistribución en forma original o con modificaciones.

Una década después, cuando ya tenía el mercado cautivo, comenzó a cobrar por las actualizaciones.

Y eso nos deja en la puerta de la historia del señor de barba y la impresora, que quedará para un próximo artículo.

Prometo que cuando termine esta parte de la serie, voy a cumplir mi palabra de incluir la bibliografía.

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

Durante esta semana, Intel ha lanzado oficialmente su producto más nuevo. En esta ocasión no estamos hablando de un procesador ni nada de hardware, sino de un sistema operativo en el que llevan tiempo trabajando y que lleva el nombre de mOS. Está basado en el kernel de Linux, pero en uno modificado por la propia compañía para que funcione en el ecosistema HPC.

HPC son las siglas de «High Performance Computing», por lo que mOS, que no hay que confundir con el macOS de Apple, es un sistema operativo centrado en los centros de datos y la computación de alto rendimiento. Por lo que parece, mOS aún está dando sus primeros pasos en cuanto a investigación, pero ya podría usarse en superordenadores como los ASCI Red o IBM Blue Gene. El objetivo de la compañía famosa por sus procesadores es desarrollar una versión estable para el superordenador Aurora cuando esté listo.

mOS, sistema operativo Linux con un kernel modificado por Intel

El sistema operativo seguirá basado en extensiones de Linux, usando la v0.8 más actualizada el kernel Linux 5.4 LTS, pero tiene su propio núcleo ligero LWK, el kernel gestiona un pequeño número de núcleos de la CPU para asegurarse de la compatibilidad y el LWK kernel gestiona el resto del sistema, algo así como el Multi-OS. Por otra parte, es digno de mención que el mOS de Intel está creado mirando al futuro, con aplicaciones 5G, por lo que cuando el 5G se extienda y las aplicaciones se desarrollen, los superordenadores podrán venderse mucho más pronto, por lo que Intel va un paso por delante en este sentido.

En cualquier caso y aunque la noticia guarda una estrecha relación con Linux, en un principio no estamos hablando de una distribución destinada al usuario medio, pero es interesante ver como las grandes compañías siguen apostando por Linux en proyectos de este tipo.

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

Dos semanas después de la v5.14, y sin modificar ni un ápice su calendario, WineHQ ha lanzado una nueva versión de su software que nos permite ejecutar aplicaciones de Windows en Linux y otros sistemas operativos. Lo que hay disponible desde ayer viernes es WINE 5.15, lo que no tenemos que olvidar que es una nueva versión de desarrollo y no una versión oficial y estable. Esta semana han destacado 5 novedades, además de su habitual «corrección de errores varios».

Pero que sólo destaquen 5+1 novedades no significa que no hayan introducido cambios. De hecho, lo interesante del artículo, al que podéis acceder desde este enlace y como siempre, aparece si miramos más abajo, en donde detallan 27 correcciones y 275 cambios, lo que es algo menos que los 302 de la semana pasada y mucho menos que los más de 400 que han introducido en otras ocasiones. A continuación tenéis la lista de novedades más destacadas que han llegado junto a WINE 5.15.

Novedades más destacadas de WINE 5.15

• Implementación inicial de las bibliotecas del motor XACT.
• Inicios de una biblioteca matemática en MSVCRT basada en Musl.
• Aún más reestructuración del soporte de la consola.
• Mejoras en el rendimiento de Direct Input.
• Correcciones de manejo de excepciones en x86-64.
• Varias correcciones de errores.

Los usuarios interesados ya pueden instalar WINE 5.14 desde su código fuente, disponible en este y este otro enlace, o a partir de los binarios que se pueden descargar desde aquí. En el enlace desde donde podemos descargar los binarios también hay información para añadir el repositorio oficial del proyecto para recibir esta y otras actualizaciones futuras tan pronto en cuanto las tengan listas a sistemas como Ubuntu/Debian o Fedora, pero también para Android y macOS.

La próxima versión de desarrollo será WINE 5.16 y, si no hay sorpresas, algo que parece imposible que pase en la agenda de WineHQ, llegará el próximo 28 de agosto. Entre las mejoras, se espera que sigan trabajando en las dos cosas que han empezado esta semana, es decir, en la implementación de las bibliotecas del motor XACT y en la biblioteca matemática en MSVCRT basada en Musl, además de introducir cientos de pequeños cambios como es habitual.

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

A veces, cuando se adquieren ciertos productos de hardware y usas GNU/Linux, no cuentas con todas las funciones con las que cuentan los usuarios de Windows, especialmente cuando se refiere a técnicas como modding, software para overclocking, etc. Pero no siempre es así, y cada vez existen más proyectos que pretenden hacer que estas diferencias se disipen y que los usuarios de Linux puedan disfrutar en plenitud de todo. Y es el caso del que hoy te voy a hablar, y que seguro que te gusta si tienes un AMD Ryzen con un ventilador AMD Wraith Prism RGB.

Pues bien, si ese es el caso y no puedes controlar los LEDs de colores de este ventilador, eso se ha acabado. Ahora podrás hacerlo desde tu distro favorita con este software. Y es que cuando algunos proveedores oficiales no se preocupan por la plataforma, la comunidad responde con proyectos como Wraith Master para AMD.

Es un proyecto similar a CM-RGB, que seguro que conoces. Pero Wraith Master proporciona una interfaz de usuario con funciones completas, así como una aplicación para línea de comandos con la que poder controlar los LEDs de colores de este producto de refrigeración de AMD.

Aunque está en una etapa muy temprana de desarrollo, pero ha recibido su versión 1.1 recientemente, con lo que hace a Wraith Master algo mejor y lo encamina en la buena dirección. En este caso, vas a encontrar algunas novedades.

Además, la interfaz de usuario de este programa tiene un poco más de trabajo para mejorar la experiencia de usuario y viene con un gran número de bugs solucionados. Al igual que la herramienta equivalente para Windows, la herramienta Wraith Master para Linux necesitará que el ventilador esté conectado con el cable USB interno para comunicarse con él y poder controlarlo. De lo contrario, no funcionaría…

Para saber más sobre el proyecto y comenzar a usarlo, puedes acceder a esta página de GitLab.

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