Transcribo la entrevista que fue realizada por el divulgador del software libre de la India, Abhishek Prakash del portal It’s Foss a la cara más visible del proyecto Nitrux, el compañero mexicano Uri Herrera aunque el trabajo no cae solamente en Uri, y en realidad son un grupo de entusiastas del software libre en general y las herramientas Qt en particular que son los que desarrollan Nitrux así como una serie de herramientas y aplicaciones de la casa. Nitrux es una distribución única y diferente al resto por algunas particularidades: Tiene su propio escritorio, sólo usa paquetes AppImages y pronto dejará systemd.
Abhishek: Pocas personas saben sobre el origen del proyecto Nitrux. ¿Podría darnos detalles sobre cómo se cambió de una compañía de diseño gráfico a una compañía de hardware y a una distribución Linux?
Uri Herrera: Nitrux fue fundada en 2012 por mí (Uri Herrera) como Nitrux S.A. en México. En ese momento, yo estaba en la universidad estudiando diseño gráfico, así que la mayor parte del trabajo inicial estaba relacionado con eso. Creé el tema de iconos de Nitrux, el tema de iconos Compass, el tema de iconos Flattr, el tema de iconos ZERO, el tema de iconos Dots, un paquete de temas para KDE 4 llamado Nitrux KDE Suite, un par de temas de GTK inspirados en MIUI 4 junto con muchas maquetas para aplicaciones de interfaz gráfica, y otros paquetes que se expandieron en los temas de iconos, todos ellos están disponibles en DeviantArt.
En 2013 conocí a Haashir Mohammed, quien se unió a mí, y él creó muchas aplicaciones basadas en la web para Nitrux como Typer.IM, nDisk y Muire. Typer.IM era un servicio de mensajería instantánea con intercambio de archivos p2p y utilizaba WebRTC para llamadas, tanto de audio como de video. nDisk era un servicio de almacenamiento en la nube, y podías acceder a él con WebDav desde tu escritorio. Muire era un constructor de sitios web como Weebly, y podías crear, guardar y exportar los sitios web que creaba en él.
Durante 2013 y 2014, decidimos entrar en el negocio del hardware. Hicimos un prototipo de una pequeña computadora de factor de forma que ejecutaría una distribución de Linux, por lo que el sistema operativo Nitrux (al que nos referimos como Nitrux) se originó a partir de esta decisión. Originalmente llamamos a este pequeño ordenador QtBox porque teníamos la intención de utilizar Plasma 4 en nuestra distribución. Sin embargo, más tarde lo cambiamos a NXQ para evitar cualquier problema con el nombre y también porque se unía estrechamente a nuestra marca (NX). En 2014 fui invitado a unirme a la recién formada KDE VDG también, esta fue mi primera contribución a un proyecto más grande fuera de Nitrux, así que después de aceptar, creé el tema del icono Breeze y el nuevo logo de Plasma. En 2015, después de asistir a una reunión de KDE en Randa, Suiza, también actualicé el tema de Plasma Breeze, que ha estado en uso desde entonces.
Decidimos entonces liberar Nitrux para x64 en 2015; sin embargo, debido a los cambios en Ubuntu (en el que se basaba Nitrux) detuvimos el desarrollo de esa versión por un grave problema que tuvimos con systemd y NetworkManager. Unos meses después decidimos descontinuar el NXQ y detener cualquier plan para un nuevo modelo que se estaba trabajando debido al repentino aumento de la popularidad de mini-pcs similares para Android.
No fue hasta 2017, dos años después de que se detuvo el desarrollo de Nitrux OS, que Nitrux OS resucitó. Nitrux S.A. también fue reestructurado bajo un nombre diferente, Nitrux Latinoamericana S.C.
Un nuevo desarrollador, Alexis Zubieta, se unió a mí, y juntos, establecimos nuevas metas, una nueva visión, y una intención original para la distribución, diseñamos y desarrollamos Nomad Desktop, al que nos referimos como una capa de personalización para Plasma 5. Más tarde ese año, comenzamos a trabajar en una tienda de software para Nitrux OS llamada NX Software Center, inicialmente usando Snaps (no había un frontend gráfico para Snaps en ese momento en el escritorio, el nuestro fue el primero) luego agregando soporte para AppImages y finalmente haciendo una transición completa para usar solamente AppImages.
A principios de 2018 Haashir había dejado Nitrux para continuar con sus estudios, así que Alexis y yo buscamos más desarrolladores, el primero en unirse fue Luis Lavaire y luego Camilo Higuita. A mediados de 2018, se nos unió otro desarrollador, Anupam Basak. A lo largo de 2018 comenzamos a desarrollar MauiKit y ZNX (con mayúsculas). A finales de 2018, comenzamos a distribuir ambos con el sistema operativo Nitrux utilizando ZNX por primera vez en la versión 1.1.0 y la inclusión de aplicaciones MauiKit o Maui Apps en Plasma Mobile después de la Academia 2018.
En 2019 presentamos VMetal un par de semanas antes de asistir a la Akademy 2019.
Abhishek: Cuéntanos algo sobre la distribución de Nitrux Linux? ¿En qué se basa?
Uri: La respuesta corta es que Nitrux está construido usando fuentes de Ubuntu, ya que utilizamos algunas de sus herramientas en nuestras imágenes ISO como Casper o initramfs-tools. Aún así, no está basado en Ubuntu de ninguna manera significativa como fue el caso en años anteriores.
La respuesta larga es que no está basado en él, ya que hemos hecho muchas modificaciones e intentamos hacer muchas más, por ejemplo, en Nitrux, el gestor de paquetes no es una parte integral de la distribución y la experiencia de usuario prevista. De hecho, en Development build de Nitrux (que eventualmente se convierte en la nueva versión estable), ni APT ni dpkg están presentes ya que la idea es usar AppImages para gestionar el software y ZNX para manipular el sistema operativo. Incluimos Homebrew como un medio para llenar el hueco donde un programa puede no estar disponible como AppImage, pero Homebrew sólo gestiona el software que instala y nada más.
Otro ejemplo de por qué Nitrux no es Ubuntu es que, por ejemplo, podrías tener una AppImage para usar Pacman en Nitrux, y eso, por supuesto, no significa que Nitrux esté basado en Arch. Además, tenemos la intención de eliminar Systemd y (más adelante) cambiar el FHS en Nitrux. Incluso tenemos una ISO de Nitrux completamente funcional que no usa Systemd o tiene APT o dpkg, y sólo hay un problema que nos impide liberarlo.
En otras palabras, no se puede añadir un PPA o un repositorio a Ubuntu y convertirlo en Nitrux. Puede añadir nuestro trabajo artístico (que también hicimos desde cero), pero eso no es Nitrux, es una parte de él (una parte superficial), pero no es eso. Para decirlo de otra manera, podríamos haber usado LFS o Gentoo, y aún así habríamos hecho los mismos cambios, habríamos desarrollado las mismas herramientas, nuestro mismo software, etc. La forma en que lo vemos, por ejemplo, es que no creemos que debamos centrarnos en cosas como tener que compilar todo para que nuestra distribución “merezca” llamarse “independiente” cuando podemos centrar ese tiempo y esfuerzo en otras cosas más centradas en el usuario. Aunque sí tenemos nuestra infraestructura, herramientas y usamos una IC para generar las cosas que necesitamos, como las AppImages y nuestras ISOs.
Así que como decimos, “si esperas que Nitrux sea “sólo” un tema de Ubuntu, eso no es en absoluto lo que es. Eso no es lo que estamos haciendo o pretendemos hacer”.
Abhishek: ¿Qué te hizo crear “otra distribución de Linux”? ¿Qué es lo que hace único a Nitrux Linux?
Uri: Nitrux es una distribución única en el contexto de cómo funcionan los sistemas Linux de escritorio tradicionales. Nitrux no se construyó alrededor de la idea de usar un gestor de paquetes, ya sea APT, Pacman, DNF, Zypper, etc., sino en lugar de usar un formato de aplicación portable. La razón de esto es que queremos que Nitrux sea un sistema convergente, no limitado sólo a un escritorio o un teléfono, sino que también se utiliza para otros dispositivos embebidos; IO, TVs, Infotainment, Electrodomésticos, etc. El uso de ZNX es precisamente para tener un método de manejar eficientemente el sistema operativo y no tratar con ningún paquete, lo mismo con AppImages.
En realidad, la forma en que Nitrux funciona está más relacionada con un sistema operativo móvil como Android, por ejemplo, con Android se instalan aplicaciones usando un APK, el archivo APK tiene el programa, y sus dependencias en él no hay necesidad de instalar otro APK y mucho menos de usar un gestor de paquetes. Se obtiene el archivo APK, se instala y se ejecuta el programa, y es la misma idea con un AppImage; se obtiene el AppImage, se le dan permisos de ejecución y se ejecuta.
Cuando se trata de administrar el sistema operativo, cuando un dispositivo Android recibe una actualización suele ser con el mecanismo OTA incorporado, el fabricante publica una actualización, el teléfono comprueba si esta actualización la descarga e instala reiniciando y entrando en modo de recuperación y actualizando la imagen del sistema. Con Nitrux, la distribución está empaquetada en una ISO (similar al archivo system.img de Android). ZNX entonces realiza una actualización transaccional a la ISO; no hay ningún gestor de paquetes involucrado en este proceso (y tampoco se reinicia para la recuperación). También podría, de forma literal, copiar y pegar diferentes archivos ISO de Nitrux, y tendría una nueva o antigua versión de la distribución.
Al igual que las ROMs de Android, donde el SO está contenido en un único archivo (system.img), Nitrux también es autocontenido como un único archivo (ISO).
Otra característica de Nitrux es VMetal. VMetal es, como su nombre lo sugiere, una característica de virtualización incorporada en Nitrux. VMetal funciona utilizando las siguientes tecnologías: QEMU, KVM, VFIO, extensiones de virtualización de CPU como Intel VT-d, VT-x o AMD-V, y Vi y un IOMMU.
Con Nitrux, preferimos mantenerlo simple. El SO es un único archivo (ISO); los nuevos programas se añaden en un único archivo (AppImage), los SO que utiliza VMetal son archivos individuales (archivos IMG sin procesar).
Luego tenemos MauiKit en el que las aplicaciones son convergentes por diseño, un código base que funciona en Linux, Android, Plasma Mobile, Windows. Actualmente tenemos 7 aplicaciones construidas con MauiKit: Index, VVave, Nota, Station, Buho, Pix y Dialer. Todas ellas ven el desarrollo activo y el framework y las aplicaciones están alojadas en https://invent.kde.org ya que algunas de ellas están incluidas en Plasma Mobile por defecto. Muchas mejoras provienen de los comentarios que recibimos de los usuarios que prueban las aplicaciones. Tenemos un grupo público donde los usuarios pueden unirse para dar su opinión aquí.
Así que todo se trata de la portabilidad.
Abhishek: Cuéntanos más sobre ZNX. A pesar de que es un concepto interesante, ¿por qué no se ha hecho más popular?
Uri: ZNX es un gestor de sistemas operativos. Gestiona la vida útil de los sistemas operativos que se despliegan con él. ZNX no es un instalador, un contenedor, un programa para flashear USBs (no es un reemplazo de ‘dd’ o algo similar), o un software de virtualización. Lo que ZNX hace son instalaciones frugales. “Una instalación frugal sólo ocupa una carpeta en una partición, y el resto de la partición puede ser usada para cualquier otra cosa. Otras distribuciones de Linux, por ejemplo”. Mientras tanto, las distribuciones tradicionales de Linux hacen una instalación completa, “Una instalación completa es cuando Linux ocupa una partición entera, y en esa partición verás las carpetas /bin, /sbin, /opt, /etc/, /sys, /proc, /tmp, /dev, /usr, /run, /lib, y más”.
Por ejemplo, los gestores de paquetes que trabajan con binarios precompilados instalan software extrayendo un archivo (deb, rpm, tar, etc.) y colocando el contenido de ese archivo en las rutas correspondientes del sistema de archivos y manteniendo un índice de dónde se encuentran esos archivos, los gestores de paquetes basados en el código fuente también lo hacen con la excepción de extraer un archivo. Un instalador como Ubiquity, Calamares (KPM Core), Anaconda, y cualquier otro instalador funciona de la misma manera, extraen los contenidos del archivo SquashFS dentro de la ISO y colocan los contenidos en una partición del dispositivo de almacenamiento.
Por lo tanto, en este sentido, ZNX es similar a AppImage. Para instalar AppImage, no se usa un gestor de paquetes; AppImage no se extrae, simplemente se ejecuta. Lo mismo con ZNX, por eso no nos referimos a ZNX “instalando” un sistema operativo, sino que usamos la palabra “deploy”. Debido a que ZNX no está extrayendo el archivo SquashFS de la ISO, está arrancando la ISO directamente, y los datos son preservados en el dispositivo de almacenamiento usando OverlayFS. ZNX entonces solo copia la ISO a un directorio en el dispositivo de almacenamiento (STORE).
Una vez más, en comparación con Android, cuando el usuario reinicia un dispositivo a la fábrica, los datos del usuario se borran. Aún así, el sistema operativo no se reinstala en ningún momento, ZNX también lo hace, puede eliminar los datos del usuario de la superposición, restableciendo así el sistema operativo sin necesidad de reinstalar el sistema operativo. Sin embargo, a diferencia de Android, donde no hay una forma sencilla de bajar de categoría, ZNX permite al usuario volver a una versión previa del SO. Cuando se trata de actualizaciones, ZNX las hace de forma transaccional, realizando actualizaciones delta en los archivos ISO, por lo que se ahorra tiempo y ancho de banda.
ZNX también puede restaurar la partición ESP, y también aprovecha cualquier gestión del cargador de arranque. Si una ISO está en el directorio STORE, aparecerá automáticamente en el menú de arranque de ZNX; si no lo está, no lo hará. ZNX también es independiente de la inicialización y usa GRUB para arrancar las ISOs.
ZNX es, en realidad, bastante sencillo.
Creo que una de las razones por las que ZNX no se ha hecho más popular es que, debido a que todo el mundo está tan acostumbrado al concepto de los gestores de paquetes e instaladores, ZNX es ajeno a ellos. ZNX es para los instaladores del sistema operativo lo que AppImage es para los gestores de paquetes. Ha habido casos en los que la gente incluso llamaría a ZNX un “sistema de arranque propietario” cuando eso es simplemente incorrecto. Puede ser que ZNX sea tan radicalmente diferente de cómo funcionan las distribuciones tradicionales de Linux, especialmente en el escritorio, que la idea que hay detrás de él no se entienda aunque estemos usando un modelo ya existente (y funcional).
Mucha gente también parece pensar que debido a la forma en que Nitrux se especializa en las AppImages, ZNX no les permitiría usar un gestor de paquetes si otra distribución que no fuéramos nosotros lo usara. Eso también es incorrecto, ya que tenemos ISOs de elementary OS y KDE Neon que pueden ser desplegadas con ZNX donde el gestor de paquetes es perfectamente funcional, y aparte de no tener un instalador, no hay ninguna diferencia en comparación con instalarlos usando sus instaladores.
Otra razón por la que creo que ZNX no es popular es que ZNX hace sus operaciones de forma automatizada, por ejemplo, el particionado no es manejado por el usuario sino por ZNX, no hay creación de usuario, selección de idioma, selección de teclado, selección de zona horaria, ya que un instalador tradicionalmente se encarga de esto. Más que nada porque, como en Android, toda esa configuración se hace desde el sistema operativo arrancado y nunca durante la instalación porque no hay instalación. Así que, una vez más, una desviación significativa de cómo funcionan las distribuciones tradicionales de Linux para escritorio.
Derivado de estos cambios significativos que ZNX trae a la mesa es que todo el mundo espera instalar los sistemas operativos en una configuración tradicional de arranque múltiple, por ejemplo, una partición para Ubuntu, otra para Fedora, otra para openSUSE, otra para Arch, y así sucesivamente. Lo cual no es el caso de ZNX, ya que la idea es que sólo se tiene una partición donde se encuentra cada fichero ISO (es decir, cada SO) y luego se selecciona cuál se arranca en el menú de arranque de ZNX. Así pues, una partición, con cada SO en un directorio separado dentro de STORE, con sus datos dentro de su correspondiente estructura de directorios, en este sentido ZNX es algo similar al gestor de paquetes Nix en cuanto a la forma en que Nix almacena los datos de cada programa en su estructura de directorios.
El único requisito que ZNX tiene actualmente es que los archivos ISO deben soportar EFI, y la única limitación es la falta de soporte para Secure Boot. Aún así, estamos completamente abiertos a que cualquiera contribuya con código que permita el soporte de BIOS Legacy y el soporte de Secure Boot.
ZNX no es un reto para usar en absoluto. Aún así, se beneficiaría de tener una mejor GUI, por lo que puede ser demasiado que la gente nueva lo encuentre difícil debido a eso, aunque la GUI de ZNX existe, es por eso que estamos trabajando en integrarlo en nuestro centro de software en su lugar.
Algunas personas también parecen pensar que ZNX es una alternativa a Docker; en ese caso, no estoy seguro de por qué. Supongo que por el hecho de que usemos el término “deploy” (desplegar).
Ciertamente, ZNX ha tenido problemas, principalmente que el AppImage no funcionaba como se esperaba, ya que así es como lo distribuimos. Sin embargo, ya hemos arreglado casi todos esos problemas, y funciona en todos los lugares donde hemos hecho pruebas.
Recientemente también revelamos que la razón por la que siempre dijimos que nuestra ISO no podía ser flasheada a un USB no era un problema relacionado en absoluto con ZNX sino con un componente de nuestra herramienta, mkiso. Usamos mkiso para generar nuestros archivos ISO; desafortunadamente, mkiso hizo archivos ISO que no arrancarían en ordenadores que no fueran UEFI clase 3 (Intel 6ª gen.+ o AMD Ryzen+). ZNX, sin embargo, permitiría que la ISO arrancara en ordenadores más antiguos siempre y cuando soportaran EFI (chipsets Intel 2ª. gen+ o AMD PII/800). Desde entonces hemos arreglado mkiso, y nuestros archivos ISO pueden ahora arrancar en ordenadores EFI más antiguos cuando se flashean a un USB. Quizás esta fue la razón por la que algunas personas también pensaron que ZNX era como un reemplazo de ‘dd’ o algo así como Etcher. Seguramente, puedes desplegar un SO a un USB con ZNX, y sería un USB arrancable en este sentido es similar a programas como MultiBootUSB o YUMI con la excepción de que los datos de usuario se almacenan directamente en el dispositivo usando OverlayFS en lugar de usar un archivo como lo hacen, lo que significa que no estás limitado al almacenamiento asignado al archivo persistente sino al espacio libre total del dispositivo de almacenamiento.
Todo esto es una mezcla de confusión y malentendidos que creo que es la razón por la que ZNX no es popular.
Abhishek: ¿A qué tipo de base de usuarios se dirige con Nitrux?
Pretendemos apuntar a usuarios que han estado considerablemente expuestos a la forma en que los sistemas operativos móviles se comportan y trabajan.
Abhishek: Tienes un fuerte enfoque en AppImage. ¿Por qué?
AppImage proporciona una forma sencilla de obtener software. Descárguelo y ejecútelo. Al igual que antes, así es precisamente como se obtienen aplicaciones en los sistemas operativos móviles. Esa facilidad de uso es lo que esperamos. No hay duda de que Flatpak y Snapcraft son más populares; cuentan con el respaldo de dos grandes empresas y comunidades, por lo que es invariablemente una batalla difícil.
AppImage también es independiente de init, lo cual es muy importante para nosotros ya que no tenemos intenciones de seguir usando Systemd, lo que significa que ni Flatpak ni Snaps estarán disponibles en Nitrux, no que lo estén en nuestras ISO actuales. No necesita ni usa demonios para funcionar, las AppImages no dependen de otras AppImages para funcionar, tampoco se requieren tiempos de ejecución, y no está atado al sistema init como se ha mencionado.
Mucha gente parece pensar también que AppImages carece de una característica de sandboxing, de integración con el escritorio, o incluso de la capacidad de actualizarlas. Esto es incorrecto, AppImages puede ser almacenado en un sandbox con Firejail (programa SUID que reduce el riesgo de violaciones de seguridad al restringir el entorno de ejecución de aplicaciones no confiables que utilizan espacios de nombres Linux). La integración con el escritorio se puede hacer con múltiples programas como AppImage Daemon, AppImage Launcher, o AppImage Desktop Integration (desarrollado por nosotros). Por último, AppImages puede ser actualizado usando AppImageUpdate, que actualizará los archivos usando actualizaciones transaccionales, delta (como lo hace ZNX), todas las cuales incluimos, por defecto.
Creo que el único “inconveniente” es el tamaño de los archivos en algunos casos, pero también es un caso en el que se pretende que AppImage se ejecute. Por ejemplo, un router no tendría cientos de GB de almacenamiento o incluso docenas, pero al mismo tiempo, no hay ninguna razón real para tener una AppImage de escritorio en él como LibreOffice.
Aún así, eso no es un problema en cualquier ordenador de sobremesa o portátil razonablemente moderno, que es muy probable que tenga cientos si no miles de GB o incluso en la mayoría de los teléfonos en los que el almacenamiento interno llega a los cientos y los que soportan tarjetas SD también tienen acceso a cientos de GB.
En este sentido, una AppImage está pensada para incluir lo que el programa necesita para poder ejecutarse, y que no se espera que esté en el sistema operativo de destino. Por ejemplo, el AppImage de Index (gestor de archivos Maui) es tan pequeño como 50 MBs porque está pensado para ser ejecutado en un SO de escritorio completo (escritorio como en el tipo de sistema no como en el factor de forma) mientras que si el AppImage estuviera pensado para ser ejecutado en un servidor tendría que ser mucho más grande ya que el SO del servidor no tendría ningún software gráfico, para empezar.
Al mismo tiempo, el hecho de que AppImage incluya todo lo que necesita es lo que hace que funcione no sólo en una distribución Linux en particular sino en muchas más.
Seguramente, obtener un archivo aleatorio de Internet puede no parecer una buena idea, pero se están haciendo esfuerzos para proporcionar un almacén centralizado para AppImages como AppImageHub.com.
Abhishek: Veo un paywall mientras descargo Nitrux. ¿A qué se debe esto? ¿Qué (otro) modelo de negocio tienen?
Uri: La razón es relativamente simple, Nitrux es un negocio, no una organización sin fines de lucro, y las empresas necesitan generar ingresos para crecer y seguir desarrollándose. Como con cualquier esfuerzo comercial, hay gastos, aunque desarrollamos software libre y de código abierto. Desde el pago de nuestros servidores hasta nuestros salarios y gastos de viaje para asistir a eventos relacionados con el software libre. Por lo tanto, somos francos al respecto.
No ponemos anuncios en nuestra página web ni en nuestro sistema operativo, ni enviamos correos electrónicos de marketing, no recogemos datos de los usuarios, no incluimos software de terceros, no regañamos a los usuarios con las claves de licencia, no cobramos a los usuarios por el soporte de Nitrux. Además, el 99% de nuestro trabajo está disponible en forma de código fuente o distribuido como una AppImage sin costo alguno en nuestra organización GitHub, o está alojado en la infraestructura de KDE como es el caso de MauiKit y las Maui Apps. También contribuimos con el upstream, como lo hacemos con KDE con Kirigami y AppImage (nuestro antiguo desarrollador, Alexis Zubieta desarrolló libappimage durante su tiempo con Nitrux y actualmente forma parte del equipo que desarrolla AppImage y todo su software relacionado).
Yo diría que algunas personas, sin embargo, parecen pensar que porque estamos haciendo una distribución de Linux o porque desarrollamos software libre y de código abierto no deberíamos tener que cobrar dinero por nuestro trabajo porque nadie más lo hace, o peor aún, que no podemos. Ni la FSF ni la OSI prohíben la comercialización del FOSS, por lo que es un argumento inválido, precisamente porque la F en FOSS no significa gratis; en realidad, significa libertad y nuestro software se ajusta a eso.
Con toda certeza, entendemos que no todo el mundo puede permitirse el lujo de pagar, por lo que ofrecemos el desarrollo y las construcciones mínimas sin coste alguno, además de la fuente.
Al pagar para descargar la ISO, los usuarios contribuyen a pagar nuestros salarios y nuestra capacidad de contratar más gente y crear más software y seguir puliendo el que tenemos.
Además de pagar por el acceso a la descarga de la ISO Estable, también aceptamos donaciones a través de PayPal o con criptografía, y también tenemos una página de Patreon y Liberapay.
Abhishek: ¿Está buscando voluntarios, desarrolladores o apoyo financiero de cualquier tipo? ¿Algún mensaje para los lectores?
Uri: Siempre lo hacemos. Si alguien quiere ayudar, la ayuda es más que bienvenida. Actualmente no tenemos ningún puesto vacante, ya que acabamos de contratar a un nuevo desarrollador, pero esperamos poder permitirnos otro en el futuro.
Nitrux se compone actualmente de 4 miembros que pronto serán 5:
- Uri Herrera (yo)
- Luis Lavaire
- Camilo Higuita
- Anupam Basak
- Ademir Tejada (nuevo)
Todos trabajamos a tiempo completo ya que el desarrollo de todo nuestro software es nuestro trabajo, pero trabajamos a distancia ya que todos estamos en países diferentes.
Estamos buscando apoyo financiero, como mencioné, ponemos ese dinero directamente en el desarrollo de todo lo que hacemos.
Todo lo que puedo pedir a los lectores de It’s FOSS es que prueben Nitrux e informen de los problemas; así es como podemos mejorarlo.
Si desea estar al día de lo que hacemos, síganos en los medios sociales como Twitter, Instagram y Telegram. También debería leer nuestro blog para obtener actualizaciones más detalladas. Por supuesto, eres bienvenido a contribuir en nuestro repositorio GitHub.
Imagen portada: Página oficial de Nitrux
