entrevista-sobre-hyperbolabsd: update
This commit is contained in:
parent
67cc5fecb2
commit
a633e6acb1
@ -20,271 +20,377 @@ entrevisté a André, cofundador de Hyperbola.
|
|||||||
|
|
||||||
### ¿Por qué Hyperbola GNU/Linux-libre se convirtirá en HyperbolaBSD?
|
### ¿Por qué Hyperbola GNU/Linux-libre se convirtirá en HyperbolaBSD?
|
||||||
|
|
||||||
###### *It's FOSS:* en su anuncio, declara que el kernel Linux "avanza rápidamente por un camino inestable". ¿Podría explicar qué quiere decir con eso?
|
**It's FOSS,**
|
||||||
|
|
||||||
***André:*** En primer lugar, incluye la adaptación de funciones DRM
|
###### En su anuncio, declara que el kernel Linux "avanza rápidamente por un camino inestable". ¿Podría explicar qué quiere decir con eso?
|
||||||
como [HDCP](https://patchwork.kernel.org/patch/10084131/)
|
|
||||||
(Protección de contenido digital de alto ancho de banda).
|
|
||||||
Actualmente hay una opción para deshabilitarlo en el momento de la
|
|
||||||
compilación, sin embargo, no existe una política que nos garantice
|
|
||||||
que será opcional para siempre.
|
|
||||||
|
|
||||||
Históricamente, algunas características comenzaron como opcionales
|
**André Silva,**
|
||||||
hasta que alcanzaron la funcionalidad total. Luego se volvieron
|
|
||||||
forzados y difíciles de arreglar. Incluso si esto no sucede en el
|
|
||||||
caso de HDCP, seguimos siendo cautelosos acerca de tales
|
|
||||||
implementaciones.
|
|
||||||
|
|
||||||
Otra de las razones es que el kernel Linux ya no se está endureciendo
|
>En primer lugar, incluye la adaptación de funciones
|
||||||
adecuadamente. [Grsecurity](https://grsecurity.net/) dejó de ofrecer
|
>DRM como [HDCP](https://patchwork.kernel.org/patch/10084131/)
|
||||||
parches públicos hace varios años, y dependíamos de eso para la
|
>(Protección de contenido digital de alto ancho de banda).
|
||||||
seguridad de nuestro sistema. Aún si podríamos usar sus parches para
|
>Actualmente hay una opción para deshabilitarlo en el momento de la
|
||||||
una suscripción muy costosa, la suscripción finalizaría si
|
>compilación, sin embargo, no existe una política que nos garantice
|
||||||
decidiéramos hacer públicos esos parches.
|
>que será opcional para siempre.
|
||||||
|
|
||||||
Dichas restricciones van en contra de los principios de FSDG que
|
<!--- -->
|
||||||
requieren que proporcionemos código fuente completo, desbloqueado y
|
|
||||||
sin restricciones a nuestros usuarios.
|
|
||||||
|
|
||||||
[KSPP](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)
|
>Históricamente, algunas características comenzaron como opcionales
|
||||||
es un proyecto que tenía la intención de subir Grsec al kernel,
|
>hasta que alcanzaron la funcionalidad total. Luego se volvieron
|
||||||
pero hasta ahora no ha llegado a alcanzar el nivel de endurecimiento
|
>forzados y difíciles de arreglar. Incluso si esto no sucede en el
|
||||||
del kernel de Grsec/PaX. Tampoco ha habido muchos desarrollos recientes,
|
>caso de HDCP, seguimos siendo cautelosos acerca de tales
|
||||||
lo que nos lleva a creer que ahora es un proyecto inactivo en su mayor
|
>implementaciones.
|
||||||
parte.
|
|
||||||
|
|
||||||
Por último, el interés en [permitir que los módulos de Rust](https://lwn.net/Articles/797828/)
|
<!--- -->
|
||||||
ingresen al kernel es un problema para nosotros, debido a las
|
|
||||||
restricciones de marcas registradas de Rust que nos impiden aplicar
|
|
||||||
parches en nuestra distribución sin permiso expreso. Aplicamos
|
|
||||||
parches para eliminar software no libre, archivos sin licencia y
|
|
||||||
mejoras a la privacidad del usuario donde sea aplicable. También
|
|
||||||
esperamos que nuestros usuarios puedan reutilizar nuestro código
|
|
||||||
sin restricciones o permisos adicionales requeridos.
|
|
||||||
|
|
||||||
Esto también se debe en parte a que utilizamos UXP, un motor de
|
>Otra de las razones es que el kernel Linux ya no se está endureciendo
|
||||||
navegador totalmente libre y un kit de herramientas de aplicación
|
>adecuadamente. [Grsecurity](https://grsecurity.net/) dejó de ofrecer
|
||||||
sin Rust, para nuestras aplicaciones de correo y navegador.
|
>parches públicos hace varios años, y dependíamos de eso para la
|
||||||
|
>seguridad de nuestro sistema. Aún si podríamos usar sus parches para
|
||||||
|
>una suscripción muy costosa, la suscripción finalizaría si
|
||||||
|
>decidiéramos hacer públicos esos parches.
|
||||||
|
|
||||||
Debido a estas restricciones, y la preocupación de que en algún
|
<!--- -->
|
||||||
momento se convierta en una dependencia forzada del tiempo de
|
|
||||||
compilación del kernel, necesitábamos otra opción.
|
|
||||||
|
|
||||||
###### *It's FOSS:* También dijo en el anuncio que estaría bifurcando el kernel de OpenBSD. ¿Por qué elegiste OpenBSD sobre FreeBSD, el kernel DragonflyBSD o el kernel MidnightBSD?
|
>Dichas restricciones van en contra de los principios de FSDG que
|
||||||
|
>requieren que proporcionemos código fuente completo, desbloqueado y
|
||||||
|
>sin restricciones a nuestros usuarios.
|
||||||
|
|
||||||
***André:*** [OpenBSD](https://www.openbsd.org/) fue elegido como
|
<!--- -->
|
||||||
nuestra base para el hard-forking porque es un sistema que
|
|
||||||
siempre ha tenido en cuenta el código de calidad y la seguridad.
|
|
||||||
|
|
||||||
Algunas de sus ideas que nos interesaron enormemente fueron las
|
>[KSPP](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)
|
||||||
nuevas llamadas al sistema, incluidas pledge y unveil, que agrega
|
>es un proyecto que tenía la intención de subir Grsec al kernel,
|
||||||
un endurecimiento adicional al espacio del usuario y la eliminación
|
>pero hasta ahora no ha llegado a alcanzar el nivel de endurecimiento
|
||||||
de la herramienta de aplicación de políticas del sistema systrace.
|
>del kernel de Grsec/PaX. Tampoco ha habido muchos desarrollos recientes,
|
||||||
|
>lo que nos lleva a creer que ahora es un proyecto inactivo en su mayor
|
||||||
|
>parte.
|
||||||
|
|
||||||
También son conocidos por [Xenocara](https://www.xenocara.org/)
|
<!--- -->
|
||||||
y [LibreSSL](https://www.libressl.org/), los cuales ya
|
|
||||||
habíamos estado usando después de portarlos a GNU/Linux-libre.
|
|
||||||
Los encontramos bien escritos y generalmente más estables que
|
|
||||||
Xorg/OpenSSL respectivamente.
|
|
||||||
|
|
||||||
Ninguna de las otras implementaciones de BSD que conocemos tiene
|
>Por último, el interés en [permitir que los módulos de Rust](https://lwn.net/Articles/797828/)
|
||||||
ese nivel de seguridad. También sabíamos que [LibertyBSD](https://libertybsd.net/)
|
>ingresen al kernel es un problema para nosotros, debido a las
|
||||||
ha estado trabajando para liberar el kernel de OpenBSD, lo
|
>restricciones de marcas registradas de Rust que nos impiden aplicar
|
||||||
que nos permitió usar sus parches para comenzar el
|
>parches en nuestra distribución sin permiso expreso. Aplicamos
|
||||||
desarrollo inicial.
|
>parches para eliminar software no libre, archivos sin licencia y
|
||||||
|
>mejoras a la privacidad del usuario donde sea aplicable. También
|
||||||
|
>esperamos que nuestros usuarios puedan reutilizar nuestro código
|
||||||
|
>sin restricciones o permisos adicionales requeridos.
|
||||||
|
|
||||||
###### *It's FOSS:* ¿Por qué bifurcar el kernel en primer lugar? ¿Cómo mantendrá actualizado el nuevo kernel con soporte de hardware más nuevo?
|
<!--- -->
|
||||||
|
|
||||||
***André:*** El kernel es una de las partes más importantes de
|
>Esto también se debe en parte a que utilizamos UXP, un motor de
|
||||||
cualquier sistema operativo, y consideramos que es fundamental
|
>navegador totalmente libre y un kit de herramientas de aplicación
|
||||||
comenzar con una base firme para avanzar.
|
>sin Rust, para nuestras aplicaciones de correo y navegador.
|
||||||
|
|
||||||
Para la primera versión, planeamos mantenernos sincronizados
|
<!--- -->
|
||||||
con OpenBSD donde sea posible. En futuras versiones, podemos adaptar
|
|
||||||
el código de otros BSD e incluso el kernel Linux donde sea necesario
|
|
||||||
para mantenernos al día con el soporte y las características
|
|
||||||
del hardware.
|
|
||||||
|
|
||||||
Estamos trabajando en coordinación con [Libreware Group](https://en.libreware.info/)
|
>Debido a estas restricciones, y la preocupación de que en algún
|
||||||
(nuestro representante para actividades comerciales) y
|
>momento se convierta en una dependencia forzada del tiempo de
|
||||||
tenemos planes de abrir nuestra fundación pronto.
|
>compilación del kernel, necesitábamos otra opción.
|
||||||
|
|
||||||
Esto ayudará a mantener el desarrollo, contratar futuros desarrolladores
|
**It's FOSS,**
|
||||||
y alentar a los nuevos entusiastas a obtener soporte y código de hardware
|
|
||||||
más nuevos. Sabemos que el desbloqueo no es suficiente porque es
|
|
||||||
una mitigación, no una solución para nosotros. Entonces, por esa
|
|
||||||
razón, necesitamos mejorar nuestra estructura y pasar a la siguiente
|
|
||||||
etapa de desarrollo de nuestros proyectos.
|
|
||||||
|
|
||||||
###### *It's FOSS:* Usted declara que planea reemplazar las partes del kernel de OpenBSD y el espacio de usuario que no son compatibles con GPL o que no son libres con los que sí lo son. ¿Qué porcentaje del código cae en la zona no GPL?
|
###### También dijo en el anuncio que estaría bifurcando el kernel de OpenBSD. ¿Por qué elegiste OpenBSD sobre FreeBSD, el kernel DragonflyBSD o el kernel MidnightBSD?
|
||||||
|
|
||||||
***André:*** Es alrededor del 20% en el núcleo de OpenBSD y el espacio de usuario.
|
**André Silva,**
|
||||||
|
|
||||||
En su mayoría, las partes con licencia no compatibles con GPL están bajo la
|
>[OpenBSD](https://www.openbsd.org/) fue elegido como
|
||||||
licencia BSD original, a veces llamada la "licencia BSD de 4 cláusulas"
|
>nuestra base para el hard-forking porque es un sistema que
|
||||||
que contiene una falla grave: la cláusula "obnoxious BSD advertising".
|
>siempre ha tenido en cuenta el código de calidad y la seguridad.
|
||||||
No es fatal, pero nos causa problemas prácticos porque genera
|
|
||||||
incompatibilidad con nuestro código y desarrollo futuro bajo GPLv3 y LGPLv3.
|
|
||||||
|
|
||||||
Los archivos no libres en OpenBSD incluyen archivos sin un encabezado
|
<!--- -->
|
||||||
de licencia apropiado, o sin una licencia en la carpeta que contiene
|
|
||||||
un componente en particular.
|
|
||||||
|
|
||||||
Si esos archivos no contienen una licencia para dar a los usuarios las
|
>Algunas de sus ideas que nos interesaron enormemente fueron las
|
||||||
cuatro libertades esenciales o si no se ha agregado explícitamente en el
|
>nuevas llamadas al sistema, incluidas pledge y unveil, que agrega
|
||||||
dominio público, no es software libre. Algunos desarrolladores piensan
|
>un endurecimiento adicional al espacio del usuario y la eliminación
|
||||||
que el código sin licencia está automáticamente en el dominio público.
|
>de la herramienta de aplicación de políticas del sistema systrace.
|
||||||
Eso no es cierto según la ley de derechos de autor de hoy; más bien,
|
|
||||||
todos los trabajos con derechos de autor tienen derechos de autor
|
|
||||||
por defecto.
|
|
||||||
|
|
||||||
Los blobs de firmware no libres en OpenBSD incluyen varios firmwares
|
<!--- -->
|
||||||
de hardware. Estos blobs de firmware también se producen en el kernel
|
|
||||||
de Linux y han sido eliminados manualmente por el Linux-libre project
|
|
||||||
durante años después de cada nueva versión del kernel.
|
|
||||||
|
|
||||||
Por lo general, tienen la forma de un binario codificado hexadecimal
|
>También son conocidos por [Xenocara](https://www.xenocara.org/)
|
||||||
y se proporcionan a los desarrolladores del kernel sin fuente para
|
>y [LibreSSL](https://www.libressl.org/), los cuales ya
|
||||||
proporcionar soporte para hardware de diseño exclusivo. Estos blobs
|
>habíamos estado usando después de portarlos a GNU/Linux-libre.
|
||||||
pueden contener vulnerabilidades o puertas traseras además de violar
|
>Los encontramos bien escritos y generalmente más estables que
|
||||||
su libertad, pero nadie lo sabría ya que el código fuente no está
|
>Xorg/OpenSSL respectivamente.
|
||||||
disponible para ellos. Deben eliminarse para respetar la
|
|
||||||
libertad del usuario.
|
|
||||||
|
|
||||||
###### *It's FOSS:* Estaba hablando con alguien sobre HyperbolaBSD y mencionaron [HardenedBSD](https://hardenedbsd.org/). ¿Has considerado HardenedBSD?
|
<!--- -->
|
||||||
|
|
||||||
**André:** Hemos investigado HardenedBSD, pero fue bifurcado de FreeBSD.
|
>Ninguna de las otras implementaciones de BSD que conocemos tiene
|
||||||
FreeBSD tiene una base de código mucho más grande. Si bien
|
>ese nivel de seguridad. También sabíamos que [LibertyBSD](https://libertybsd.net/)
|
||||||
HardenedBSD es probablemente un buen proyecto, requeriría mucho
|
>ha estado trabajando para liberar el kernel de OpenBSD, lo
|
||||||
más esfuerzo para desbloquear y verificar las licencias de
|
>que nos permitió usar sus parches para comenzar el
|
||||||
todos los archivos.
|
>desarrollo inicial.
|
||||||
|
|
||||||
Decidimos usar OpenBSD como base para bifurcar en lugar de
|
**It's FOSS,**
|
||||||
FreeBSD debido a su compromiso anterior con la calidad
|
|
||||||
del código, la seguridad y el minimalismo.
|
|
||||||
|
|
||||||
###### *It's FOSS:* Usted mencionó UXP (o [plataforma XUL unificada](http://thereisonlyxul.org/)). Parece que está utilizando el [fork de Moonchild de la base de código pre-Servo Mozilla](https://github.com/MoonchildProductions/UXP) para escribir un conjunto de aplicaciones para la web. ¿Es por el tamaño de la misma?
|
###### ¿Por qué bifurcar el kernel en primer lugar? ¿Cómo mantendrá actualizado el nuevo kernel con soporte de hardware más nuevo?
|
||||||
|
|
||||||
**André:** sí. Nuestra decisión de usar UXP fue por varias razones.
|
**André Silva,**
|
||||||
Ya estuvimos renombrando Firefox como Iceweasel durante varios
|
|
||||||
años para eliminar DRM, deshabilitar la telemetría y aplicar
|
|
||||||
opciones de privacidad preestablecidas. Sin embargo, se hizo cada
|
|
||||||
vez más difícil para nosotros mantenerlo cuando Mozilla seguía
|
|
||||||
agregando anti-funciones, eliminando la personalización del usuario
|
|
||||||
y rompiendo rápidamente nuestros parches de cambio de marca y privacidad.
|
|
||||||
|
|
||||||
Después de FF52, todas las extensiones XUL se eliminaron a favor
|
>El kernel es una de las partes más importantes de
|
||||||
de WebExt y Rust se hizo dependencia en el momento de la compilación.
|
>cualquier sistema operativo, y consideramos que es fundamental
|
||||||
Mantenemos varios complementos XUL para mejorar la privacidad/seguridad
|
>comenzar con una base firme para avanzar.
|
||||||
del usuario que ya no funcionaría en el nuevo motor.
|
|
||||||
También nos preocupaba que los complementos limitados de WebExt
|
|
||||||
presentaran problemas de privacidad adicionales. Por ejemplo:
|
|
||||||
cada complemento WebExt instalado contiene un UUID que se puede
|
|
||||||
utilizar para identificar de forma única y precisa a los usuarios
|
|
||||||
(consulte Bugzilla [1372288](https://bugzilla.mozilla.org/show_bug.cgi?id=1372288)).
|
|
||||||
|
|
||||||
Después de un poco de investigación, descubrimos UXP y que
|
<!--- -->
|
||||||
regularmente se mantenía al día con las correcciones de seguridad
|
|
||||||
sin apresurarse a implementar nuevas funciones. Ya habían
|
|
||||||
deshabilitado la telemetría en el kit de herramientas y siguen
|
|
||||||
comprometidos a eliminarlo de la base de código.
|
|
||||||
|
|
||||||
Sabíamos que esto estaba bien alineado con nuestros objetivos,
|
>Para la primera versión, planeamos mantenernos sincronizados
|
||||||
pero aún necesitábamos aplicar algunos parches para ajustar la
|
>con OpenBSD donde sea posible. En futuras versiones, podemos adaptar
|
||||||
configuración de privacidad y eliminar DRM. Por lo tanto,
|
>el código de otros BSD e incluso el kernel Linux donde sea necesario
|
||||||
comenzamos a escribir nuestras propias aplicaciones en la parte
|
>para mantenernos al día con el soporte y las características
|
||||||
superior del kit de herramientas.
|
>del hardware.
|
||||||
|
|
||||||
Esto nos ha permitido ir mucho más allá del rebranding/deblobbing
|
<!--- -->
|
||||||
básico como lo hacíamos antes y escribir nuestras propias aplicaciones
|
|
||||||
XUL totalmente personalizadas. Actualmente mantenemos
|
|
||||||
[Iceweasel-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp),
|
|
||||||
[Icedove-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:icedove-uxp)
|
|
||||||
e [Iceape-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:iceape-uxp),
|
|
||||||
además de compartir las mejoras del kit de herramientas de regreso a UXP.
|
|
||||||
|
|
||||||
###### *It's FOSS:* En una [publicación del foro](https://forums.hyperbola.info/viewtopic.php?id=315), noté menciones de HyperRC, HyperBLibC e hyperman. ¿Son estos forkso reescrituras de herramientas BSD actuales compatibles con GPL?
|
>Estamos trabajando en coordinación con [Libreware Group](https://en.libreware.info/)
|
||||||
|
>(nuestro representante para actividades comerciales) y
|
||||||
|
>tenemos planes de abrir nuestra fundación pronto.
|
||||||
|
|
||||||
**André:** Son forks de proyectos existentes.
|
<!--- -->
|
||||||
|
|
||||||
Hyperman es un fork de nuestro actual administrador de paquetes, pacman.
|
>Esto ayudará a mantener el desarrollo, contratar futuros desarrolladores
|
||||||
Como pacman no funciona actualmente en BSD, y el soporte mínimo que tenía
|
>y alentar a los nuevos entusiastas a obtener soporte y código de hardware
|
||||||
en el pasado se eliminó en versiones recientes, se requería un fork.
|
>más nuevos. Sabemos que el desbloqueo no es suficiente porque es
|
||||||
Hyperman ya tiene una implementación funcional con el soporte de LibreSSL y BSD.
|
>una mitigación, no una solución para nosotros. Entonces, por esa
|
||||||
|
>razón, necesitamos mejorar nuestra estructura y pasar a la siguiente
|
||||||
|
>etapa de desarrollo de nuestros proyectos.
|
||||||
|
|
||||||
HyperRC será una versión parcheada de OpenRC init. HyperBLibC será un fork de BSD LibC.
|
**It's FOSS,**
|
||||||
|
|
||||||
###### *It's FOSS:* Desde el principio de los tiempos, Linux ha defendido la licencia GPL y BSD ha defendido la licencia BSD. Ahora, está trabajando para escribir un BSD con licencia GPL. ¿Cómo respondería a aquellos en la comunidad BSD que no están de acuerdo con este movimiento?
|
###### Usted declara que planea reemplazar las partes del kernel de OpenBSD y el espacio de usuario que no son compatibles con GPL o que no son libres con los que sí lo son. ¿Qué porcentaje del código cae en la zona no GPL?
|
||||||
|
|
||||||
**André:** Somos conscientes de que hay desacuerdos entre el mundo
|
**André Silva,**
|
||||||
GPL y BSD. Incluso hay desacuerdos sobre llamar a nuestra distribución
|
|
||||||
anterior "GNU/Linux" en lugar de simplemente "Linux", ya que la última
|
|
||||||
definición ignora que el espacio de usuario de GNU fue escrito en 1984,
|
|
||||||
varios años antes de que Linus Torvalds escribiera el kernel Linux.
|
|
||||||
Fueron los dos software diferentes combinados los que formaron un
|
|
||||||
sistema completo.
|
|
||||||
|
|
||||||
Algunas de las principales diferencias con respecto a BSD,
|
>Es alrededor del 20% en el núcleo de OpenBSD y el espacio de usuario.
|
||||||
es que la GPL requiere que nuestro código fuente se haga público,
|
|
||||||
incluidas las versiones futuras, y que solo se pueda usar junto
|
|
||||||
con archivos con licencia compatible. Los sistemas BSD no tienen
|
|
||||||
que compartir su código fuente públicamente, y pueden agruparse
|
|
||||||
con varias licencias y software no libre sin restricciones.
|
|
||||||
|
|
||||||
Dado que apoyamos firmemente el Movimiento de Software Libre y
|
<!--- -->
|
||||||
deseamos que nuestro código futuro permanezca siempre en el
|
|
||||||
espacio público, elegimos la GPL.
|
|
||||||
|
|
||||||
###### *It's FOSS:* Sé que en este momento recién está comenzando el proceso, pero ¿tiene alguna idea de quién podría tener una versión utilizable de HyperbolaBSD disponible?
|
>En su mayoría, las partes con licencia no compatibles con GPL están bajo la
|
||||||
|
>licencia BSD original, a veces llamada la "licencia BSD de 4 cláusulas"
|
||||||
|
>que contiene una falla grave: la cláusula "obnoxious BSD advertising".
|
||||||
|
>No es fatal, pero nos causa problemas prácticos porque genera
|
||||||
|
>incompatibilidad con nuestro código y desarrollo futuro bajo GPLv3 y LGPLv3.
|
||||||
|
|
||||||
**André:** Esperamos tener una versión alfa lista para 2021 (Q3)
|
<!--- -->
|
||||||
para la prueba inicial.
|
|
||||||
|
|
||||||
###### *It's FOSS:* ¿Cuánto tiempo continuará admitiendo la versión actual de Hyperbola para Linux? ¿Será fácil para los usuarios actuales cambiar?
|
>Los archivos no libres en OpenBSD incluyen archivos sin un encabezado
|
||||||
|
>de licencia apropiado, o sin una licencia en la carpeta que contiene
|
||||||
|
>un componente en particular.
|
||||||
|
|
||||||
**André:** Según nuestro anuncio, continuaremos admitiendo
|
<!--- -->
|
||||||
Hyperbola GNU/Linux-libre hasta 2022 (Q4). Esperamos que haya
|
|
||||||
alguna dificultad en la migración debido a los cambios de ABI,
|
|
||||||
pero prepararemos un anuncio e información en nuestro wiki una
|
|
||||||
vez que esté listo.
|
|
||||||
|
|
||||||
###### *It's FOSS:* Si alguien está interesado en ayudarlo a trabajar en HyperbolaBSD, ¿cómo puede hacerlo? ¿Qué tipo de experiencia estarías buscando?
|
>Si esos archivos no contienen una licencia para dar a los usuarios las
|
||||||
|
>cuatro libertades esenciales o si no se ha agregado explícitamente en el
|
||||||
|
>dominio público, no es software libre. Algunos desarrolladores piensan
|
||||||
|
>que el código sin licencia está automáticamente en el dominio público.
|
||||||
|
>Eso no es cierto según la ley de derechos de autor de hoy; más bien,
|
||||||
|
>todos los trabajos con derechos de autor tienen derechos de autor
|
||||||
|
>por defecto.
|
||||||
|
|
||||||
**André:** Cualquiera que esté interesado y pueda aprender es
|
<!--- -->
|
||||||
bienvenido. Necesitamos programadores y usuarios de C que
|
|
||||||
estén interesados en mejorar la seguridad y la privacidad del
|
|
||||||
software. Los desarrolladores deben seguir los principios FSDG
|
|
||||||
de desarrollo de software libre, así como el principio YAGNI,
|
|
||||||
lo que significa que implementaremos nuevas funciones solo
|
|
||||||
cuando las necesitemos.
|
|
||||||
|
|
||||||
Los usuarios pueden bifurcar nuestro repositorio git y
|
>Los blobs de firmware no libres en OpenBSD incluyen varios firmwares
|
||||||
enviarnos parches para su inclusión.
|
>de hardware. Estos blobs de firmware también se producen en el kernel
|
||||||
|
>de Linux y han sido eliminados manualmente por el Linux-libre project
|
||||||
|
>durante años después de cada nueva versión del kernel.
|
||||||
|
|
||||||
###### *It's FOSS:* ¿Tienes algún plan para soportar ZFS? ¿Qué sistemas de archivos admitirán?
|
<!--- -->
|
||||||
|
|
||||||
**André:** El soporte de [ZFS](https://itsfoss.com/what-is-zfs/)
|
>Por lo general, tienen la forma de un binario codificado hexadecimal
|
||||||
no está planeado actualmente, porque usa la Licencia de
|
>y se proporcionan a los desarrolladores del kernel sin fuente para
|
||||||
Desarrollo y Distribución Común, versión 1.0 (CDDL).
|
>proporcionar soporte para hardware de diseño exclusivo. Estos blobs
|
||||||
Esta licencia es incompatible con todas las versiones
|
>pueden contener vulnerabilidades o puertas traseras además de violar
|
||||||
de la GNU General Public License (GPL).
|
>su libertad, pero nadie lo sabría ya que el código fuente no está
|
||||||
|
>disponible para ellos. Deben eliminarse para respetar la
|
||||||
|
>libertad del usuario.
|
||||||
|
|
||||||
Sería posible escribir un nuevo código bajo GPLv3 y
|
**It's FOSS,**
|
||||||
liberarlo con un nuevo nombre (por ejemplo, HyperZFS),
|
|
||||||
sin embargo, no hay una decisión oficial de incluir el
|
|
||||||
código de compatibilidad ZFS en HyperbolaBSD en este momento.
|
|
||||||
|
|
||||||
Tenemos planes de portar BTRFS, JFS2, CHFS de NetBSD, HAMMER/HAMMER2
|
###### Estaba hablando con alguien sobre HyperbolaBSD y mencionaron [HardenedBSD](https://hardenedbsd.org/). ¿Has considerado HardenedBSD?
|
||||||
de DragonFlyBSD y JFFS2 del kernel Linux, todos los cuales tienen
|
|
||||||
licencias compatibles con GPLv3. A largo plazo, también podemos
|
|
||||||
admitir Ext4, F2FS, ReiserFS y Reiser4, pero deberán reescribirse
|
|
||||||
debido a que tienen licencia exclusiva bajo GPLv2, que no permite
|
|
||||||
su uso con GPLv3. Todos estos sistemas de archivos requerirán
|
|
||||||
pruebas de desarrollo y estabilidad, por lo que estarán en versiones
|
|
||||||
posteriores de HyperbolaBSD y no para nuestras versiones
|
|
||||||
estables iniciales.
|
|
||||||
|
|
||||||
Me gustaría agradecer a [André](https://www.hyperbola.info/members/founders/#Emulatorman)
|
**André Silva,**
|
||||||
|
|
||||||
|
>Hemos investigado HardenedBSD, pero fue bifurcado de FreeBSD.
|
||||||
|
>FreeBSD tiene una base de código mucho más grande. Si bien
|
||||||
|
>HardenedBSD es probablemente un buen proyecto, requeriría mucho
|
||||||
|
>más esfuerzo para desbloquear y verificar las licencias de
|
||||||
|
>todos los archivos.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Decidimos usar OpenBSD como base para bifurcar en lugar de
|
||||||
|
>FreeBSD debido a su compromiso anterior con la calidad
|
||||||
|
>del código, la seguridad y el minimalismo.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### Usted mencionó UXP (o [plataforma XUL unificada](http://thereisonlyxul.org/)). Parece que está utilizando el [fork de Moonchild de la base de código pre-Servo Mozilla](https://github.com/MoonchildProductions/UXP) para escribir un conjunto de aplicaciones para la web. ¿Es por el tamaño de la misma?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>Sí. Nuestra decisión de usar UXP fue por varias razones.
|
||||||
|
>Ya estuvimos renombrando Firefox como Iceweasel durante varios
|
||||||
|
>años para eliminar DRM, deshabilitar la telemetría y aplicar
|
||||||
|
>opciones de privacidad preestablecidas. Sin embargo, se hizo cada
|
||||||
|
>vez más difícil para nosotros mantenerlo cuando Mozilla seguía
|
||||||
|
>agregando anti-funciones, eliminando la personalización del usuario
|
||||||
|
>y rompiendo rápidamente nuestros parches de cambio de marca y privacidad.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Después de FF52, todas las extensiones XUL se eliminaron a favor
|
||||||
|
>de WebExt y Rust se hizo dependencia en el momento de la compilación.
|
||||||
|
>Mantenemos varios complementos XUL para mejorar la privacidad/seguridad
|
||||||
|
>del usuario que ya no funcionaría en el nuevo motor.
|
||||||
|
>También nos preocupaba que los complementos limitados de WebExt
|
||||||
|
>presentaran problemas de privacidad adicionales. Por ejemplo:
|
||||||
|
>cada complemento WebExt instalado contiene un UUID que se puede
|
||||||
|
>utilizar para identificar de forma única y precisa a los usuarios
|
||||||
|
>(consulte Bugzilla [1372288](https://bugzilla.mozilla.org/show_bug.cgi?id=1372288)).
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Después de un poco de investigación, descubrimos UXP y que
|
||||||
|
>regularmente se mantiene al día con las correcciones de seguridad
|
||||||
|
>sin apresurarse a implementar nuevas funciones. Ya habían
|
||||||
|
>deshabilitado la telemetría en el kit de herramientas y siguen
|
||||||
|
>comprometidos a eliminarlo de la base de código.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Sabíamos que esto estaba bien alineado con nuestros objetivos,
|
||||||
|
>pero aún necesitábamos aplicar algunos parches para ajustar la
|
||||||
|
>configuración de privacidad y eliminar DRM. Por lo tanto,
|
||||||
|
>comenzamos a escribir nuestras propias aplicaciones en la parte
|
||||||
|
>superior del kit de herramientas.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Esto nos ha permitido ir mucho más allá del rebranding/deblobbing
|
||||||
|
>básico como lo hacíamos antes y escribir nuestras propias aplicaciones
|
||||||
|
>XUL totalmente personalizadas. Actualmente mantenemos
|
||||||
|
>[Iceweasel-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp),
|
||||||
|
>[Icedove-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:icedove-uxp)
|
||||||
|
>e [Iceape-UXP](https://wiki.hyperbola.info/doku.php?id=en:project:iceape-uxp),
|
||||||
|
>además de compartir las mejoras del kit de herramientas de regreso a UXP.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### En una [publicación del foro](https://forums.hyperbola.info/viewtopic.php?id=315), noté menciones de HyperRC, HyperBLibC e hyperman. ¿Son estos forks o reescrituras de herramientas BSD actuales compatibles con GPL?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
> Son forks de proyectos existentes.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Hyperman es un fork de nuestro actual administrador de paquetes, pacman.
|
||||||
|
>Como pacman no funciona actualmente en BSD, y el soporte mínimo que tenía
|
||||||
|
>en el pasado se eliminó en versiones recientes, se requería un fork.
|
||||||
|
>Hyperman ya tiene una implementación funcional con el soporte de LibreSSL y BSD.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>HyperRC será una versión parcheada de OpenRC init. HyperBLibC será un fork de BSD LibC.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### Desde el principio de los tiempos, Linux ha defendido la licencia GPL y BSD ha defendido la licencia BSD. Ahora, está trabajando para escribir un BSD con licencia GPL. ¿Cómo respondería a aquellos en la comunidad BSD que no están de acuerdo con este movimiento?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>Somos conscientes de que hay desacuerdos entre el mundo
|
||||||
|
>GPL y BSD. Incluso hay desacuerdos sobre llamar a nuestra distribución
|
||||||
|
>anterior "GNU/Linux" en lugar de simplemente "Linux", ya que la última
|
||||||
|
>definición ignora que el espacio de usuario de GNU fue escrito en 1984,
|
||||||
|
>varios años antes de que Linus Torvalds escribiera el kernel Linux.
|
||||||
|
>Fueron los dos software diferentes combinados los que formaron un
|
||||||
|
>sistema completo.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Algunas de las principales diferencias con respecto a BSD,
|
||||||
|
>es que la GPL requiere que nuestro código fuente se haga público,
|
||||||
|
>incluidas las versiones futuras, y que solo se pueda usar junto
|
||||||
|
>con archivos con licencia compatible. Los sistemas BSD no tienen
|
||||||
|
>que compartir su código fuente públicamente, y pueden agruparse
|
||||||
|
>con varias licencias y software no libre sin restricciones.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Dado que apoyamos firmemente el Movimiento de Software Libre y
|
||||||
|
>deseamos que nuestro código futuro permanezca siempre en el
|
||||||
|
>espacio público, elegimos la GPL.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### Sé que en este momento recién está comenzando el proceso, pero ¿tiene alguna idea de quién podría tener una versión utilizable de HyperbolaBSD disponible?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>Esperamos tener una versión alfa lista para 2021 (Q3)
|
||||||
|
>para la prueba inicial.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### ¿Cuánto tiempo continuará admitiendo la versión actual de Hyperbola para Linux? ¿Será fácil para los usuarios actuales cambiar?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>Según nuestro anuncio, continuaremos admitiendo
|
||||||
|
>Hyperbola GNU/Linux-libre hasta 2022 (Q4). Esperamos que haya
|
||||||
|
>alguna dificultad en la migración debido a los cambios de ABI,
|
||||||
|
>pero prepararemos un anuncio e información en nuestro wiki una
|
||||||
|
>vez que esté listo.
|
||||||
|
|
||||||
|
**It's FOSS,**
|
||||||
|
|
||||||
|
###### Si alguien está interesado en ayudarlo a trabajar en HyperbolaBSD, ¿cómo puede hacerlo? ¿Qué tipo de experiencia estarías buscando?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>Cualquiera que esté interesado y pueda aprender es
|
||||||
|
>bienvenido. Necesitamos programadores y usuarios de C que
|
||||||
|
>estén interesados en mejorar la seguridad y la privacidad del
|
||||||
|
>software. Los desarrolladores deben seguir los principios FSDG
|
||||||
|
>de desarrollo de software libre, así como el principio YAGNI,
|
||||||
|
>lo que significa que implementaremos nuevas funciones solo
|
||||||
|
>cuando las necesitemos.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Los usuarios pueden bifurcar nuestro repositorio git y
|
||||||
|
>enviarnos parches para su inclusión.
|
||||||
|
|
||||||
|
###### ¿Tienes algún plan para soportar ZFS? ¿Qué sistemas de archivos admitirán?
|
||||||
|
|
||||||
|
**André Silva,**
|
||||||
|
|
||||||
|
>El soporte de [ZFS](https://itsfoss.com/what-is-zfs/)
|
||||||
|
>no está planeado actualmente, porque usa la Licencia de
|
||||||
|
>Desarrollo y Distribución Común, versión 1.0 (CDDL).
|
||||||
|
>Esta licencia es incompatible con todas las versiones
|
||||||
|
>de la GNU General Public License (GPL).
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Sería posible escribir un nuevo código bajo GPLv3 y
|
||||||
|
>liberarlo con un nuevo nombre (por ejemplo, HyperZFS),
|
||||||
|
>sin embargo, no hay una decisión oficial de incluir el
|
||||||
|
>código de compatibilidad ZFS en HyperbolaBSD en este momento.
|
||||||
|
|
||||||
|
<!--- -->
|
||||||
|
|
||||||
|
>Tenemos planes de portar BTRFS, JFS2, CHFS de NetBSD, HAMMER/HAMMER2
|
||||||
|
>de DragonFlyBSD y JFFS2 del kernel Linux, todos los cuales tienen
|
||||||
|
>licencias compatibles con GPLv3. A largo plazo, también podemos
|
||||||
|
>admitir Ext4, F2FS, ReiserFS y Reiser4, pero deberán reescribirse
|
||||||
|
>debido a que tienen licencia exclusiva bajo GPLv2, que no permite
|
||||||
|
>su uso con GPLv3. Todos estos sistemas de archivos requerirán
|
||||||
|
>pruebas de desarrollo y estabilidad, por lo que estarán en versiones
|
||||||
|
>posteriores de HyperbolaBSD y no para nuestras versiones
|
||||||
|
>estables iniciales.
|
||||||
|
|
||||||
|
Me gustaría agradecer a [André Silva](https://www.hyperbola.info/members/founders/#Emulatorman)
|
||||||
por tomarse el tiempo para responder mis preguntas y por revelar
|
por tomarse el tiempo para responder mis preguntas y por revelar
|
||||||
más sobre el futuro de HyperbolaBSD.
|
más sobre el futuro de HyperbolaBSD.
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user