Richard Stallman dimite del MIT y la Free Software Foundation tras sus declaraciones sobre asalto sensual y pronografía infantil

[Benditaliquidez]

Le debe de costar mucho trabajo a Stallman crear un nuevo proyecto y llevarse a todo el que vale la pena con él de calle...

Lo mejor de todo es que no tiene ni que seleccionar a la gente que quiera seguir con él, tras todo el follón que le han montado solo el que vale la pena y se la sudan esas payasadas vaya a irse con él.

 

[kunk]

Tu mismo ....

Lo que si te puedo llegar a admitir es que haya proyectos opensource que están más maduros y otros menos -en función del tiempo que lleven abiertos, de la complejidad del proyecto, y de la pasta que pongan sobre la mesa sus sponsors y promotores- de modo que hay software que directamente es mejor no usar (por el momento). Pero, vamos, que usar ese software es como si usas una software comercial versión beta: úsalo bajo tu propio riesgo. Si te compensa arriesgarte lo usas, y si no, pues no

 

[Sennaquerib]

Por eso la vieja guardia hizo un fork

Welcome to devuan.org | Devuan GNU+Linux Free Operating System

No dejéis de darle una oportunidad los que sigáis con GNU/Linux y echéis de menos la vieja Debian.

No lo conocía. Gracias por citarlo. Le daré un vistazo.

 

[kunk]

No debería.

 

[MagicPep]

el gandul del Stallmann a cumplir su sueño ... hacer el vago por el resto de sus dias

 

[reconvertido]

Boeing 737.
No es eso, pero similar.

 

[reconvertido]

Por eso la vieja guardia hizo un fork

Welcome to devuan.org | Devuan GNU+Linux Free Operating System

No dejéis de darle una oportunidad los que sigáis con GNU/Linux y echéis de menos la vieja Debian.

Gracias por citar a Devuan.

Ya lo conocía, pero no lo había probado.

Quizás sea hora de probarlo.

 

[Profesor.Poopsnagle]

El vídeo es bueno. Se ve a Torvalds delante de un montón de americanos, que ya han sucumbido a la corrección política y al NWO, que le preguntan como manginas si no se considera... lo que en España rápido llamarían un "muy de derechas".

Y todo porque ante un mal código, dijo que los culpables "are so braindead that they ought to have starved to death" (son tan iluso que si les dejan solos, se debían morir de hambre por no encontrar comida). Una respuesta ingeniosa y del carácter que tenían los hackers de antaño.

Un poco parecido a Burbuja (o FC) en su momento. Los sitios de encuentro en Internet hace 30 años solo tenían a auténticos hackers. Nos conocíamos casi todos. Y todo éramos así de "bordes" en nuestro ingenio cabrón.

Luego se abrió Internet al IRC, los primeros chats, los primeros usuarios en España, los primeros que no eran informáticos... Y se llevaron la sorpresa de la bordería de los informáticos. El lema por entonces era "don't spoonfeed the noob" (no se lo des mascado a los novatos).

Luego vinieros los foros. Forocoches al principio era... una gaiada. En 2003/2004 la gente era modosita. Hasta que lo azotamos los "trolls" y lo convertimos en algo más a la antigua usanza. Mientras duró.

En el punto en el que estamos ahora, con las "redes sociales", o el nuevo Forocoches, hay usuarios que hasta son tertulianos de Tele5 (vamos, nivel de auténticos iluso que difícilmente sabrían encontrar comida por sí mismos). Y ahí ya no se consienten ni las trolleadas, ni las borderías, ni el lenguaje no inclusivo, ni el machismo... ni nada que no les salga de la berenjena a la "masa".

Y esto es porque el bichito de la Religión Progre, está ya inoculada en todos nosotros. La corrección política es la decadencia de Occidente. Y va a destruir todo lo que toque. En un mundo de idiotas lobotomizados, no hay sitio para el ingenio. La ironía cabrona del troll requiere de ingenio. Tanto para soltarlas como para recibirlas. Y la inteligencia es el objetivo a abatir con la globalización.

Hay que luchar contra la estupidización de la sociedad de la única manera posible. Rebelándonos y siendo todo lo políticamente incorrectos que podamos. En todo sitio donde podamos. ¡Somos la Resistencia!

 

[reconvertido]

Puede ser código propietario y dentro tener copy&paste
La GPL lo impide.
Eso es ilegal.
ES ROBAR.

o usar una lib open source que tiene un agujero como una casa.
O usar una lib PROPIETARIA que tiene un agujero como una casa.
Arreglado para tí.
Por cierto, open source puede ser propietario.
Windows es Open Source para gobiernos y grandes empresas.
Y sigue siendo código propietario.

Open Source es hez comparado con Free Software.
Dejad de confundirlo de manera deliberada.

 

[patilltoes]

Lo de systemd es para flipar. Ha sido incluso más desastroso que PulseAudio, y la gente ha pasado de estar emocionada por renovar el init a querer volver a sysvinit. El problema es que ya no se puede.

No sé ni en qué estado se encuentra el asunto, eso da una idea de mi desconexión. Que fuese el mismo iluso que diseñó PulseAudio daba muy mala espina, la verdad.

Cuando lo dejé (2014-15?) systemd se iba a comer a logind, el sistema de logs, udev y unas veinte cosas importantes más. La excusa de "todo es modular y puedes no incluirlo" no me colaba ni en aquella epoca. La intención era absorber todo el sistema y a soltar.

A mí por transfondo, sysadmin en otras épocas, me gustaba de Linux que era un UNIX para jugar (con sus historias) y que seguía más o menos la filosofía KISS y demás (modularidad, etc). En ese debate se vio que iba a evolucionar a una hez abstrusa documentada como el trastero. Justo ese año me desligué de la informática y de Linux. Si hago mis chorradas a nivel amateur prefiero algún BSD, mejor documentación, más coherente y es un UNIX a nivel de filosofía de diseño.
Vídeo cachondo

 

[jimmyjump]

No sé ni en qué estado se encuentra el asunto, eso da una idea de mi desconexión. Que fuese el mismo iluso que diseñó PulseAudio daba muy mala espina, la verdad.

Cuando lo dejé (2014-15?) systemd se iba a comer a logind, el sistema de logs, udev y unas veinte cosas importantes más. La excusa de "todo es modular y puedes no incluirlo" no me colaba ni en aquella epoca. La intención era absorber todo el sistema y a soltar.

A mí por transfondo, sysadmin en otras épocas, me gustaba de Linux que era un UNIX para jugar (con sus historias) y que seguía más o menos la filosofía KISS y demás (modularidad, etc). En ese debate se vio que iba a evolucionar a una hez abstrusa documentada como el trastero. Justo ese año me desligué de la informática y de Linux. Si hago mis chorradas a nivel amateur prefiero algún BSD, mejor documentación, más coherente y es un UNIX a nivel de filosofía de diseño.
Vídeo cachondo

Hace unos meses systemd superó el 1,2 millones de lineas de código. Para que te hagas una idea del problema

No paran de añadirle código y cada vez hay más y más bugs y agujeros de seguridad. Se le ha ido tanto la pinza que ahora mismo es una especie de protokernel dentro del kernel, y por mucho que la carga sea paralela, es tan inmenso que carga más lento que winDOS

En esta conferencia

un desarrollador de toda la vida de bsd explica que poettering se basó en la gestión de servicios de MacOS como inspiración para su posterior desarrollo

Lo grave es que el muy petulante, ante las criticas de que no es posix, dice que eso se la pela.

Cada vez la gente es menos optimista con este tema, y hasta Torvalds dijo que creía que ya no podía confiar en el init

Para mi Linux está muerto, entre systemd y la deriva progre que ha tomado

 

[jimmyjump]

@patilltoes acabo de acordarme de este artículo que explica a la perfección el problema de systemd

System es un componente crítico de muchos sistemas GNU/Linux. Yo lo detesto.
Voy a explicar los por qué, pero primero algunas definiciones:

• Un programa es una secuencia de instrucciones para una computadora.
• Un proceso es una instancia en particular de un programa en ejecución. Los procesos son, aproximadamente, a los programas, lo que los vuelos son a las aerolíneas. En muchos sistemas, los procesos tienen un número, llamado identificador de proceso, o PID.
• Un malo es un programa que generalmente debe iniciar automáticamente, y se ejecuta de forma continua. No interactúa directamente con el usuario, pero espera por algún suceso y luego actúa en tal evento. Por ejemplo, puede estar esperando por una hora específica para realizar alguna tarea programada, por una conexión, o un archivo o mensaje escrito en algún lugar específico. A veces se encargan del mantenimiento del sistema, limpieza, o tareas de servicio.

Cuando se inicia un sistema Unix, el primer programa que se carga en memoria y se ejecuta se denomina "init". Lo que significa inicialización; y, como su nombre lo indica, su propósito es comenzar a ejecutar los programas necesarios para que el sistema se inicie y los usuarios puedan loguearse. De hecho, en el kernel hay una directiva hardcodeada para buscar y ejecutar un programa llamado "/sbin/init", y apagar el sistema cuando ese programa finaliza su ejecución.
Init es el último proceso en terminar cuando el sistema se apaga, y es responsable por notificar al resto de los procesos que es hora de apagarse, y terminar de manera forzosa cualquier rezagado. Cuando init en sí termina, el sistema lo hace por completo. ESTO ES IMPORTANTE.
Init tiene otro trabajo, que consiste en mantener la tabla de procesos limpia. Cualquier proceso puede crear una copia de sí mismo (llamado "fork" en la terminología Unix); es el paso previo a cargar otro programa en memoria. Un proceso que ha finalizado su ejecución puede despachar un código de estado al proceso que lo creó; éste (llamado padre) generalmente "espera" el código de estado del proceso creado (llamado hijo). ¿Pero qué pasa si el proceso padre muere antes que el hijo? Lo que sucede es que init está diseñado para ser el padre adoptivo de estos proceso "huérfanos", y espera, y descarta, cualquier código de estado que pueda ser retornado por el huérfano al finalizar. Esto previene los llamados "procesos zombies" (slots en la tabla de procesos llenos con códigos de estado que no poseen programas en ejecución asociados). Estos son indeseados debido a que ocupan lugares en la tabla de procesos (nota del traductor: una estructura de datos en el espacio de memoria del kernel) que pueden ser utilizados por otros programas.
Por ende es importante que init se ejecute bien y no crashee (nota del traductor: es lo que hace que GNU/Linux sea tan estable, ¿cuántas veces han intentado, sin éxito, terminar un proceso en un sistema Windows?).
En el diseño de sistemas Unix, es un principio generalmente entendido que una gran tarea no sea realizada por un gran programa, sino más bien por una colección de pequeños programas, cada uno atacando un componente específico y bien definido de la tarea. Se conoce como "haz una cosa, y hazla bien" y es un principio para escribir un programa Unix. Una razón importante para este razonamiento es que un pequeño programa tiene pocos lugares donde un bug se pueda ocultar, en comparación con un programa de gran tamaño.
Hasta hace poco, el programa tradicional de inicio era SysVInit. Su nombre se debe a que supuestamente era compatible con el sistema de inicio del sistema AT&T Unix System V. Generalmente utiliza un conjunto de shell scripts para levantar el sistema. La principal alternativa a SysVInit era BSD init, que corre un único script para levantar todo el sistema.
Algunos sistemas Linux desarrollaron SysVInit "estilo BSD", lo que significa que en vez de una complicada maraña de scripts, hay sólo uno, al igual que los sistemas BSD. Este único shell script en un init estilo BSD a menudo incorpora otros subscripts que setean varios parámetros de configuración; pero incluso con este cambio es bastante más simple que con los scripts estilo System V.
Entonces la mayoría de las implementaciones de SysVInit fueron un desorden. Por ejemplo Canonical, distribuidor del popular Ubuntu, en vez de usar un proceso de inicio estilo BSD, o intentar corregir los defectos del procedimiento de init, lo que decidió fue reemplazarlo con una nueva implementación.
Reemplazar a init es divertido, y es algo que cualquier nerd experto en Unix alguna vez debe intentar. Escribir tus propias utilidades de sistema, incluyendo init, puede ser un proceso muy educativo cuando se trata de entender como un sistema funciona en un nivel fundamental. Y si querés hacer algo loco, se puede inclusive bootear emacs como init e iniciar directo en el editor de texto. Tal sistema sería probablemente poco estable y no recomendado para uso a largo plazo, pero es divertido.
Sin embargo, otro principio de diseño de los sistemas Unix es, si no está roto, no lo arregles. Para sistemas en producción realmente vas a querer dejar tranquilo todo aquello que funcione bien; y el SysVInit que viene con Linux es lo suficientemente simple, bien entendido, y lo suficientemente probado como para no meterte con él cuando se trata de hacer verdadero trabajo.
Pero ese principio nunca detuvo a Canonical. A ellos les encanta meterse donde no corresponde. Upstart es un desastre. En lugar de un script tiene desparramo total de archivos de configuración. En lugar de simplemente correr un programa para iniciar los demonios que necesita levantar, tiene lo que se llama "inicio basado en eventos", en el cual cada programa iniciado o finalizado dispara un evento, que los archivos de configuración mapean en acciones (generalmente iniciando o deteniendo otros programas). Es muy sofisticado y difícil de administrar.
Algunas cargas de trabajo (por ejemplo en servidores de aplicación críticos) tienen necesidades de gestión de procesos realmente sofisticadas. Los procesos pueden caer en cualquier momento, y es necesario otros procesos para monitorear los procesos que trabajan y reiniciarlos a medida que sea necesario si fallan. Si un proceso depende de un proceso que falló, también debe ser detenido y así sucesivamente. Es perfectamente legítimo escribir un programa monitor que siga el curso de todas estas dependencias y tome acciones apropiadas. PERO NO DEBE REEMPLAZAR A INIT. Escribí el programa, hacelo subordinado a init, y luego agregalo al script de inicio de init. El trabajo de init es servir como proceso primordial, iniciando el resto de los procesos necesarios para tener el sistema funcionando, y luego hacer la plancha hasta que sea hora de apagar el sistema. Si se agrega toda esta basura al init (toda esta complejidad e inteligencia) y alguna parte se rompe, causando que init finalice o algo, ¿qué se obtiene? Un sistema inestable. Pues, si init muere, el resto de los procesos también.
Init se debe mantener simple y menso. NO existe razón alguna para pensar lo contrario.
Eso es Upstart, que es lo suficientemente malo. Ahora sigamos con SystemD, que toma todo lo malo anteriormente mencionado y le agrega más formas de hacerlo incorrecto. SystemD fue originalmente escrito por un tipo con el Rowlingesco nombre de Lennart Poettering para Red Hat, y es un total desastre. El problema con SystemD es que no sólo es un reemplazo para init; si hay un malo corriendo en un sistema Linux, SystemD probablemente quiera reemplazarlo. Reemplazó a udev, el manejador de nodos de dispositivos. Reemplazó inetd, el super-servidor de servicios de Internet. Recientemente ganó la funcionalidad de cron, el malo que corre tareas programadas. Tiene su propio sistema de logging, y debido a que no es más en archivos de texto plano, su propio servidor HTTP para poder leer los logs. Reemplazó a ConsoleKit. No sé qué carajo se supone que haga ConsoleKit, pero los entornos de escritorio lo utilizan. Si tu configuración de escritorio depende de ConsoleKit, ahora depende de SystemD.
Algunos de estos no están en PID 1 sino en pequeños demonios fuertemente acoplados a SystemD. Pero PID 1 ya hace demasiado. Configura las interfaces de red, monta los sistemas de archivos, configura el hostname, abre y escucha en sockets para iniciar demonios a demanda, corre tareas cron, construye y verifica y orquesta un grafo de dependencias para determinar qué demonios iniciar y cuando, y más. Depende en dbus por el amor de Dios (y expone una interfaz a dbus en tiempo de ejecución). Toda esta hez conviviendo en PID 1, más el hecho de que tenés todos estos demonios fuertemente acoplados hace que, un usuario de muchos años con cabeza Unix, vomite. ASÍ NO SE HACEN LAS COSAS EN UNIX. Sólo porque pongas las cosas en diferentes archivos fuente .c no hace que seas modular, o desacoplado, o que hayas seguido al filosofía Unix. Init debe depender en MUY POCO y debe hacer MUY POCO. Simplemente porque ES LO PRIMERO QUE SE INICIA Y LO ULTIMO QUE SE DETIENE. Init debe lograr iniciar el sistema cuando casi nada más (sacando el kernel y libc) esté disponible, y debe PERMANECER en ejecución tanto tiempo como se espera que el sistema funcione (¡lo que puede ser años sin reiniciar o apagarse!). Cuanto más dependas en librerías y otras hezs, más librerías y más hezs vas a necesitar para levantar el sistema (lo que no te podés permitir si tenés un pequeño volumen o initramfs para bootear). Cuanta más inteligencia tengas en las librerías de init, mayor es la chance de que pueda ocurrir un crash de init (y por lo tanto de sistema). No me importa cuan inteligente seas. MAS CÓDIGO = ESTADÍSTICAMENTE MAS BUGS. MENOS CÓDIGO = ESTADÍSTICAMENTE MENOS BUGS. Voy a confiar siempre en el init que tenga menos código SIEMPRE.
El resultado de todo esto es lo siguiente:
SYSTEMD ES EL OPUESTO EXACTO DE LO QUE UN BUEN INIT DEBE SER.
De hecho, se siente como una invasión. Se siente como si un día nos hubiésemos despertado y toda la infraestructura de nuestros sistemas Linux hubiese sido reemplazada por el capricho de un par de desarrolladores (Poettering y Kay Sievers). Esto es justamente el caso si tenés Fedora o Arch; ya que se te instaló SystemD con una de las actualizaciones automáticas. Lennart Poettering no encaja con el resto de la comunidad Linux, y no parece que conociera los principios fundamentales de los sistemas Unix antes de comenzar a escribir SystemD. El sólo decidió que las partes críticas de los sistemas Linux de todo el mundo necesitaban ser reemplazadas con su código. ¿Por qué? Porque sí. Por eso. Hay mucho repruebo por culpa de este sujeto en Internet, y la mayoría injustificado. Es un sujeto inteligente, y SystemD es bastante estable para toda la sofisticación que tiene. Pero si rompés los principios Unix, y tratas de pasar por encima de la comunidad para empujar a tu fuertemente acoplado monstruo en los sistemas de los demás, es esperable que suceda alguna reacción.
Lennart creó un blog llamado "Los 30 grandes mitos acerca de SystemD" en el cual se refiere a estas preocupaciones. Es un intento justo como refutación pero desafortunadamente Lennart, PERDISTE. PERDISTE CUANDO DECIDISTE QUE PID 1 DEBA HACER UN MONTÓN.
¿Es SysVInit una hez? A menos que lo hagas estilo BSD, sí. ¿Es SystemD mejor en algunos aspectos? Sí. SystemD posee algunas ventajas (al permitir el monitoreo y control sofisticado de procesos, inicio de demonios en paralelo para acelerar el boot time, etc).
Primero de todo, nadie con una workstation de escritorio o inclusive una laptop le importa un carajo el tiempo de booteo. La mayoría de las personas o dejan sus máquinas encendidas o las suspenden cuando no las utilizan, lo que significa que en la mayoría de los casos, si la máquina inicia en 5 o 30 segundos se trata de una micro-optimización. Especialmente cuando se compara con los varios minutos que tarda en iniciar un sistema Windows para poder ser utilizado; e incluso hoy las versiones actuales de Windows fueron ayudadas más por la proliferación de discos de estado sólido que por una mejora en su proceso de inicio. Para el caso de los servidores (nota del traductor: donde Linux pisa fuerte ya que las desktops son IRRELEVANTES), el tiempo de booteo es mucho menos que un problema; ya que tardan muchísimo mas en inicializar todas sus super-especializadas placas RAID e interfaces de hardware de red que lo que tarda en iniciar el sistema operativo.
(Un hecho curioso, una vez tuve que optimizar el proceso de inicio de una plataforma robótica embebida con Linux. Una de las opciones que consideré fue reemplazar init con un pequeño binario que sólo iniciaba los servicios requeridos por la plataforma. Estaba tratando de resolver el mismo problema que Lennart, y AUN ASÍ saqué conclusiones totalmente opuestas a las que él hizo para SystemD).
Mis máquinas Slackware con SysVInit demoran aproximadamente 30 segundos en levantar; y la mayor parte del tiempo lo gasta el kernel detectando hardware. El tiempo de booteo de init demora 4 segundos o algo así. Ayud que los scripts de inicio de Slackware son estilo BSD. En cambio mi workstation con Arch corriendo SystemD no logra un tiempo de boot apreciablemente inferior.
Segundo, a NADIE le importa un sorete que su shell tenga PID bajo cuando se loguea por primera vez. No importa un carajo.
Pero incluso si quisieras estas ventajas, hay formas de conseguirlas sin HACER hez UNIX. Hay un sistema de inicio llamado ruinit que ofrece muchos de los beneficios de SystemD, pero está construido de manera modular, al estilo Unix.
Ruinit permite control sofisticado de procesos, incluyendo inicio, detención, monitoreo, y reinicio de servicios; y un manejo especial en el caso de caidas de servicios. Puede iniciar servicios en paralelo. Utiliza un directorio repleto de scripts para controlar el inicio, detención, y manejo de errores de un malo; y utiliza pipes en lugar de dbus para exponer su mecanismo de control de procesos al espacio usuario. Las dependencias de servicios son tan simples como iniciar el servicio depend-on en el script de inicio del servicio que posee dependencias.
Esta simplicidad es lo que hace a Unix hermoso, y hace que ruinit sea armonioso con el ecosistema Unix existente. Ruinit corre en Linux y BSD, y está disponible como paquete para diferentes variedades de ambos. Puede correr como PID 1 o se puede evitar el uso de el malo init de ruinit, y ganar todos los beneficios de ruinit utilizando el resto del mismo junto con tu propio malo init. En particular, ruinit se integra bien con SysVInit. "sv", el iniciador del servicio ruinit, puede simplemente ser symlinkeado bajo /et/init.d/ con un nombre diferente, y si detecta que está siendo iniciado de esta forma se comportará como un script SysVInit para iniciar el servicio ruinit con ese nombre.
Mi sistema personal no utiliza ruinit. Un script de inicio estilo BSD es suficiente. ¿Pero si estuviese corriendo una granja de servidores? Seguro le prestaría atención a ruinit. Pero he abandonado Arch, una merecidamente popular y bien respetada distribución Linux, debido a que Arch cambió a SystemD (y también por la tendencia de Arch a romper todo en momentos inapropiados). Volví a Slackware, que sigue usando la misma simple y elegante configuración de init estilo BSD que tenía en 1995, cuando comencé a utilizarlo. Y, para ser honesto, no podría ser más feliz. Mi vida es más fácil.
Resumiendo, a la hez con la hostil toma de posesión de SystemD. Linux es, primero y antes que nada, un Unix; y voy a pelear por preservar el legado de la simplicidad y elegancia que conlleva. Al menos en las máquinas que administro. Podés correr lo que se te cante; después de todo vivimos en un país libre... y se trata de software libre.

wizardofbits.tumblr.com/post/45232318557

 

[Salamander]

Puede ser código propietario y dentro tener copy&paste
La GPL lo impide.
Eso es ilegal.
ES ROBAR.

Hay licencias que lo permiten, como la LGPL

Por qué en su próxima biblioteca no debería utilizar la Licencia Pública General Reducida de GNU - Proyecto GNU - Free Software Foundation

o usar una lib open source que tiene un agujero como una casa.
O usar una lib PROPIETARIA que tiene un agujero como una casa.
Arreglado para tí.
Por cierto, open source puede ser propietario.
Windows es Open Source para gobiernos y grandes empresas.
Y sigue siendo código propietario.

Open Source es hez comparado con Free Software.
Dejad de confundirlo de manera deliberada.

Open Source es lo que crearon los malos para dinamitar el software libre, y hay que decir que han tenido bastante éxito, casi todo el mundo usa el término sin hacer distinción entre abierto y libre.

Por qué el «código abierto» pierde de vista lo esencial del software libre - Proyecto GNU - Free Software Foundation