Como o Nitrux está mudando o cenário tradicional do Linux [entrevista]

27 de dezembro de 2019

Você deve ter ouvido falar do Nitrux Linux. Ele foi apresentado no It’s FOSS alguns anos atrás.

Muitas pessoas consideraram isso apenas mais uma distribuição baseada no Ubuntu com uma pequena mudança de tema. Isso é tão errado!

Nesta entrevista com o fundador do Nitrux Uri Herrera, você aprenderá por que o Nitrux não é apenas mais uma distribuição Linux e como ele está adicionando uma nova dimensão ao cenário do Linux com ferramentas inovadoras como o gerenciador de sistema operacional ZNX, MAUI para desenvolver rapidamente aplicativos de desktop e móveis e muito mais.

Inscreva-se no nosso canal no YouTube para mais vídeos sobre Linux IF: Poucas pessoas sabem sobre a origem do projeto Nitrux. Você poderia fornecer detalhes sobre como você mudou de uma empresa de design para uma empresa de hardware para uma distribuição Linux?

Uri Herrera: Nitrux foi fundada em 2012 por mim (Uri Herrera) como Nitrux S.A. no México. Na época, eu estava na faculdade estudando Design Gráfico, então a maioria dos primeiros trabalhos estava relacionado a isso. Eu criei o tema do ícone Nitrux, o tema do ícone Compass, o tema do ícone Flattr, o tema do ícone ZERO, o tema do ícone Dots, um pacote de temas para o KDE 4 chamado Nitrux KDE Suite, alguns temas GTK inspirados no MIUI 4 junto com muitos maquetes para aplicativos de GUI e outros pacotes que expandiram os temas de ícones, todos eles estão disponíveis em DeviantArt.

Em 2013 conheci Haashir Mohammed, que se juntou a mim, e ele criou muitos aplicativos baseados na web para Nitrux como Typer.IM, nDisk e Muire. Typer.IM era um serviço de mensagens instantâneas com compartilhamento de arquivos P2P e usava WebRTC para chamadas de áudio e vídeo. nDisk era um serviço de armazenamento em nuvem e você podia acessá-lo com WebDav de seu desktop. Muire era um construtor de sites como o Weebly, e você podia criar, salvar e exportar os sites que criou nele.

Ao longo de 2013 e 2014, decidimos entrar no negócio de hardware. Fizemos o protótipo de um computador de fator de forma pequeno que rodaria uma distribuição Linux, portanto Nitrux OS (que chamamos de Nitrux) originou-se desta decisão. Originalmente, chamamos este pequeno computador de QtBox porque pretendíamos usar o Plasma 4 em nossa distribuição. Ainda assim, mais tarde mudamos para NXQ para evitar problemas com o nome e também porque estava fortemente vinculado à nossa marca (NX). Em 2014 também fui convidado para ingressar no recém-formado KDE VDG, essa foi minha primeira contribuição para um projeto maior fora do Nitrux, então, após aceitar, criei o tema do ícone Breeze e o novo logotipo do Plasma. Em 2015, depois de participar de uma reunião do KDE em Randa, Suíça, também atualizei o tema Breeze Plasma, que está em uso desde então.

Decidimos então lançar o Nitrux para x64 em 2015; no entanto, devido a mudanças no Ubuntu (nas quais o Nitrux foi baseado), interrompemos o desenvolvimento dessa versão por causa de um problema grave que tivemos com o systemd e o NetworkManager. Poucos meses depois, decidimos descontinuar o NXQ e suspender quaisquer planos para um novo modelo que estava em andamento devido ao aumento repentino na popularidade de mini-pcs Android semelhantes.

Somente em 2017, dois anos após o desenvolvimento do Nitrux OS ser interrompido, o Nitrux OS foi ressuscitado. A Nitrux S.A. também foi reestruturada com um nome diferente, Nitrux Latinoamericana S.C.

Um novo desenvolvedor, Alexis Zubieta, juntou-se a mim e, juntos, definimos novos objetivos, uma nova visão e uma intenção original para a distribuição que projetamos e desenvolvemos Nomad Desktop, que chamamos de camada de personalização para Plasma 5. Mais tarde naquele ano, começamos a trabalhar em uma loja de software para Nitrux OS chamada NX Software Center, inicialmente usando Snaps (não havia interface gráfica para Snaps na época no desktop, o nosso era o primeiro) e adicionando suporte para AppImages e, finalmente, transição completa para usar apenas AppImages.

// <! [CDATA [janela.__ Mirage2 = {petok: 4b9699b6cbe4acece04fbb1022ae21a1ee009321-1611937823-1800}; //]]>! [Nomad Desktop]() Nomad Desktop Nomad Desktop No início de 2018 Haashir havia deixado a Nitrux para continuar com seus estudos, então Alexis e eu procuramos por mais desenvolvedores, o primeiro a entrar foi Luis Lavaire e depois Camilo Higuita. Em meados de 2018, outro desenvolvedor, Anupam Basak, se juntou a nós. Ao longo de 2018, começamos a desenvolver o MauiKit e o ZNX (capitalizados como znx). No final de 2018, começamos a distribuir ambos com o Nitrux OS utilizando ZNX pela primeira vez na versão 1.1.0 e a inclusão de aplicativos MauiKit ou Maui Apps no Plasma Mobile após o Akademy 2018.

Em 2019, apresentamos o VMetal algumas semanas antes de participar do Akademy 2019.

IF: Conte-nos algo sobre a distribuição Nitrux Linux? Em que se baseia?

Nitrux Linux em 2017 Uri: A resposta curta é que o Nitrux é construído usando fontes do Ubuntu, já que utilizamos algumas de suas ferramentas em nossas imagens ISO como Casper ou initramfs-tools. Ainda assim, não é baseado no Ubuntu de forma significativa como era o caso nos anos anteriores.

A resposta longa é que não é baseado nisso, pois fizemos muitas modificações e pretendemos muito mais, por exemplo, no Nitrux, o gerenciador de pacotes não é parte integrante da distribuição e da experiência do usuário pretendida. Na verdade, no build de desenvolvimento do Nitrux (que eventualmente se torna a nova versão Stable), nem o APT e o dpkg estão presentes, já que a ideia é usar o AppImages para gerenciar software e o ZNX para manipular o sistema operacional. Incluímos o Homebrew como um meio de preencher a lacuna em que um programa pode não estar disponível como AppImage, mas o Homebrew apenas gerencia o software que instala e nada mais.

Outro exemplo de porque o Nitrux não é Ubuntu é que, por exemplo, você poderia potencialmente ter um AppImage para usar o Pacman no Nitrux, e isso, é claro, não significaria que o Nitrux é baseado no Arch. Além disso, pretendemos remover o Systemd e (mais tarde) alterar o FHS no Nitrux. Temos até um ISO do Nitrux totalmente funcional que não usa Systemd ou tem APT ou dpkg, e há apenas um problema que está nos impedindo de lançá-lo.

Em outras palavras, você não pode adicionar um PPA ou repositório ao Ubuntu e transformá-lo em Nitrux. Você pode adicionar nossa arte (que também fizemos do zero), mas isso não é o Nitrux, é uma parte dele (uma parte superficial), mas não é isso. Colocando de outra forma, poderíamos ter usado LFS ou Gentoo, e ainda teríamos feito as mesmas mudanças, ainda teríamos desenvolvido as mesmas ferramentas, nosso mesmo software, etc. A forma como o vemos, por exemplo, é que não achamos que devemos nos concentrar em coisas como ter que compilar tudo para tornar nossa distribuição digna de ser autodenominada independente, quando podemos concentrar esse tempo e esforço em outras coisas mais focadas no usuário. Embora tenhamos nossa infraestrutura, ferramentas e use um CI para gerar as coisas que precisamos, como AppImages e nossas ISOs.

Então, como dizemos, se você espera que o Nitrux seja apenas um tema do Ubuntu +, não é isso que você receberá. Não é isso que estamos fazendo ou pretendemos fazer.

IF: O que o fez criar "outra distribuição Linux"? O que é único no Nitrux Linux?

Uri: Nitrux é uma distribuição exclusiva no contexto de como os sistemas Linux de desktop tradicionais funcionam. O Nitrux não foi construído em torno da ideia de usar um gerenciador de pacotes, seja APT, Pacman, DNF, Zypper, etc., mas em vez de usar um formato de aplicativo portátil. A razão para isso é que queremos que o Nitrux seja um sistema convergente, não se limitando apenas a um desktop ou telefone, mas que também seja usado para outros dispositivos embarcados; IoT, TVs, Infotainment, Appliances, etc. O uso do ZNX é justamente para ter um método de gerenciar o sistema operacional de forma eficiente e não lidar com pacotes, mesmo com AppImages.

Na realidade, a forma como o Nitrux funciona está mais relacionada a um sistema operacional móvel como o Android, por exemplo, com o Android, você instala aplicativos usando um APK, o arquivo APK contém o programa e suas dependências nele, não há necessidade de instalar outro APK muito menos usar um gerenciador de pacotes. Você obtém o arquivo APK, instala-o e executa o programa, e essa é a mesma ideia com um AppImage; você obtém o AppImage, concede a ele permissões executáveis e o executa.

Quando se trata de gerenciar o sistema operacional, quando um dispositivo Android recebe uma atualização, geralmente é com o mecanismo OTA integrado, o fabricante lança uma atualização, o telefone verifica se há atualização, baixa e instala reiniciando e entrando no modo de recuperação e atualizando a imagem do sistema. Com o Nitrux, a distribuição é compactada em um ISO (semelhante ao arquivo system.img do Android). O ZNX então realiza uma atualização transacional do ISO; não há nenhum gerenciador de pacotes envolvido neste processo (e também não há reinicialização para recuperação). Você também poderia, de forma literal, copiar e colar diferentes arquivos ISO do Nitrux, e você teria uma versão nova ou antiga da distribuição.

Como as ROMs do Android, onde o sistema operacional está contido em um único arquivo (system.img), o Nitrux também é independente como um único arquivo (ISO).

Outro recurso do Nitrux é o VMetal. VMetal é, como seu nome sugere, um recurso de virtualização integrado ao Nitrux. VMetal funciona utilizando as seguintes tecnologias: QEMU, KVM, VFIO, extensões de virtualização de CPU como Intel VT-d, VT-x ou AMD-V, e Vi e um IOMMU.

Com o Nitrux, preferimos manter as coisas simples. O sistema operacional é um único arquivo (ISO); novos programas são adicionados em um único arquivo (AppImage), os sistemas operacionais que o VMetal usa são arquivos individuais (arquivos IMG brutos).

Então temos MauiKit em que os aplicativos são convergentes por design, uma base de código que funciona em Linux, Android, Plasma Mobile, Windows. Atualmente, temos 7 aplicativos construídos com MauiKit: Index, VVave, Nota, Station, Buho, Pix e Dialer. Todos eles veem o desenvolvimento ativo e a estrutura e os aplicativos estão hospedados em https://invent.kde.org, pois alguns deles estão incluídos no Plasma Mobile por padrão. Muitas melhorias vieram do feedback que recebemos de usuários que testam os aplicativos. Temos um grupo público onde os usuários podem participar para dar feedback aqui.

Portanto, é tudo uma questão de portabilidade.

IF: Conte-nos mais sobre o ZNX? Apesar de um conceito interessante, por que não se tornou mais popular?

Uri: ZNX é um gerenciador de sistema operacional. Ele gerencia o tempo de vida dos sistemas operacionais implantados com ele. ZNX não é um instalador, um contêiner, um programa para flashear USBs (não é um substituto para ‘dd’ ou qualquer coisa semelhante) ou software de virtualização. O que o ZNX faz são instalações frugais. Uma instalação frugal ocupa apenas uma pasta em uma partição, e o resto da partição pode ser usado para qualquer outra coisa. Outras distribuições Linux, por exemplo. Enquanto isso, as distribuições tradicionais do Linux fazem uma instalação completa. A instalação completa é onde o Linux ocupa uma partição inteira e nessa partição você verá as pastas/bin,/sbin,/opt,/etc /,/sys,/proc,/tmp,/dev,/usr,/run,/lib e mais.

Por exemplo, gerenciadores de pacotes que funcionam usando binários pré-compilados instalam software extraindo um arquivo (deb, rpm, tar, etc.) e colocando o conteúdo desse arquivo nos caminhos correspondentes no sistema de arquivos e mantendo um índice de onde estão arquivos são localizados, os gerenciadores de pacotes baseados na fonte também fazem isso, com exceção de extrair um arquivo. Um instalador como Ubiquity, Calamares (KPM Core), Anaconda e todos os outros instaladores funcionam da mesma forma, eles extraem o conteúdo do arquivo SquashFS dentro do ISO e colocam o conteúdo em uma partição do dispositivo de armazenamento.

Portanto, nesse aspecto, o ZNX é semelhante ao AppImage. Para instalar um AppImage, você não usa um gerenciador de pacotes; o AppImage não é extraído, basta executá-lo. O mesmo com o ZNX, é por isso que não nos referimos ao ZNX instalando um sistema operacional; em vez disso, usamos a palavra implantar. Como o ZNX não extrai o arquivo SquashFS do ISO, ele inicializa o ISO diretamente, e os dados são preservados no dispositivo de armazenamento usando OverlayFS. O ZNX então copia apenas o ISO para um diretório no dispositivo de armazenamento (STORE).

Mais uma vez, em comparação com o Android, quando o usuário redefine um dispositivo para a fábrica, os dados do usuário são apagados. Mesmo assim, o SO não é reinstalado em nenhum momento, o ZNX também faz isso, ele pode remover os dados do usuário da sobreposição, reiniciando assim o SO sem a necessidade de reinstalar o SO. No entanto, ao contrário do Android, onde não existe uma maneira simples de fazer o downgrade, o ZNX permite que o usuário reverta para uma versão anterior do sistema operacional. Quando se trata de atualizações, o ZNX as faz de forma transacional, realizando atualizações delta nos arquivos ISO, de forma que tempo e largura de banda sejam economizados.

O ZNX também pode restaurar a partição ESP e também alavanca qualquer gerenciamento de bootloader. Se um ISO estiver no diretório STORE, ele aparecerá automaticamente no menu de inicialização do ZNX; se não for, não vai. O ZNX também é independente do init e usa o GRUB para inicializar ISOs.

O ZNX é, na realidade, bastante direto.

![ZNX]() ZNX

Acredito que uma das razões pelas quais o ZNX não se tornou mais popular é porque todos estão tão acostumados com o conceito de gerenciadores de pacotes e instaladores que ZNX é estranho para eles. O ZNX é para os instaladores de SO o que AppImage é para os gerenciadores de pacotes. Tem havido casos em que as pessoas chamam o ZNX de sistema de inicialização proprietário quando isso é simplesmente errado. Pode ser que o ZNX seja uma mudança tão radical de como as distribuições Linux tradicionais funcionam, especialmente no desktop que a ideia por trás dele não é compreendida, embora estejamos usando um modelo já existente (e funcional).

Muitas pessoas também parecem pensar que, por causa de como o Nitrux é especializado em AppImages, o ZNX não permitiria que eles usassem um gerenciador de pacotes se outra distribuição além de nós o usasse. Isso também está incorreto, já que temos ISOs de elementaryOS e KDE Neon que podem ser implantados com ZNX onde o gerenciador de pacotes é perfeitamente funcional e, além de não ter um instalador, não há diferença em comparação a instalá-los usando seus instaladores.

Outra razão pela qual o ZNX não é popular é que eu acredito que o ZNX faz suas operações de forma automatizada, por exemplo, o particionamento não é feito pelo usuário, mas pelo ZNX, não há criação de usuário, seleção de idioma, seleção de teclado, fuso horário seleção como um instalador tradicionalmente lida com isso. Principalmente porque, novamente, como no Android, toda essa configuração é feita de dentro do sistema operacional inicializado e nunca durante a instalação, porque não há instalação. Então, mais uma vez, uma mudança bastante significativa em como as distribuições Linux para desktop tradicionais funcionam.

Derivado dessas mudanças significativas que o ZNX traz para a mesa é que todos esperam instalar sistemas operacionais em uma configuração multi-boot tradicional, por exemplo, uma partição para Ubuntu, outra para Fedora, outra para openSUSE, outra para Arch e assim por diante. O que não é o caso do ZNX, já que a ideia é que você tenha apenas uma partição onde cada arquivo ISO (ou seja, cada SO) está localizado e selecione qual delas inicializar no menu de inicialização do ZNX. Portanto, uma partição, com cada sistema operacional em um diretório separado dentro de STORE, com seus dados dentro de sua estrutura de diretório correspondente, neste aspecto o ZNX é um pouco semelhante ao gerenciador de pacotes Nix em como o Nix armazena os dados de cada programa em sua estrutura de diretório.

O único requisito difícil que o ZNX tem atualmente é que os arquivos ISO devem suportar EFI, e a única limitação é a falta de suporte para inicialização segura. Ainda assim, estamos totalmente abertos a qualquer pessoa que contribua com código que habilite o suporte a BIOS legada e a inicialização segura.

O ZNX não é nem um pouco difícil de usar. Ainda assim, seria benéfico ter uma GUI melhor, então pode ser que pessoas novas achem difícil por causa disso, embora a GUI do ZNX exista, é por isso que estamos trabalhando para integrá-la em nosso centro de software.

Algumas pessoas também pareciam pensar que o ZNX era uma alternativa ao Docker; nesse, não tenho certeza por quê? Suponho que de nós usar o termo implantar.

Certamente o ZNX teve problemas, principalmente porque o AppImage não estava funcionando como esperado, pois é assim que o distribuímos. No entanto, já corrigimos quase todos esses problemas e funciona em todos os lugares onde testamos.

Recentemente, também divulgamos que o motivo pelo qual sempre dissemos que nosso ISO não podia ser transferido para um USB não era um problema relacionado ao ZNX, mas sim a um componente de nossas ferramentas, o mkiso. Usamos mkiso para gerar nossos arquivos ISO; infelizmente, o mkiso criou arquivos ISO que não inicializavam em computadores que não eram UEFI classe 3 (Intel 6ª geração + ou AMD Ryzen +). O ZNX, entretanto, permitiria que o ISO inicializasse em computadores mais antigos, desde que eles suportassem EFI (chipsets Intel 2ª. Gen + ou AMD série PII/800). Desde então, corrigimos o mkiso, e nossos arquivos ISO agora podem inicializar em computadores EFI mais antigos quando transferidos para um USB. Talvez este seja o motivo pelo qual algumas pessoas também pensaram que o ZNX era como um substituto ‘dd’ ou algo como Etcher. Certamente, você pode implantar um sistema operacional em um USB com ZNX, e seria um USB inicializável a este respeito, é semelhante a programas como MultiBootUSB ou YUMI, com a exceção de que os dados do usuário são armazenados diretamente no dispositivo usando OverlayFS em vez de usar um arquivo como fazem, significando que você não está limitado ao armazenamento alocado para o arquivo persistente, mas ao espaço livre geral do dispositivo de armazenamento.

Em suma, é uma mistura de confusão e mal-entendidos que acredito ser a razão pela qual o ZNX não é popular.

Que tipo de base de usuários você está almejando com o Nitrux?

Pretendemos atingir usuários que foram consideravelmente expostos à maneira como os sistemas operacionais móveis se comportam e funcionam.

Você tem um grande foco no AppImage. Por quê então?***

AppImage fornece uma maneira simples de obter software. Baixe e execute-o. Como antes, é exatamente assim que você obtém aplicativos em sistemas operacionais móveis. Essa facilidade de uso é o que esperamos. Não há dúvida de que Flatpak e Snapcraft são mais populares; eles têm o apoio de duas grandes empresas e comunidades, portanto, é invariavelmente uma batalha difícil.

O AppImage também é independente do init, o que é muito importante para nós, pois não temos intenções de continuar usando o Systemd, o que significa que nem Flatpak ou Snaps estarão disponíveis no Nitrux, não que estejam em nossos ISOs atuais. Ele não precisa ou usa daemons para funcionar, AppImages não depende de outros AppImages para funcionar, nenhum tempo de execução é necessário e não está vinculado ao sistema init como mencionado.

Muitas pessoas também parecem pensar que falta ao AppImages um recurso sandbox, integração com a área de trabalho ou mesmo a capacidade de atualizá-los. Isso está incorreto, AppImages pode ser colocado em sandbox com Firejail (programa SUID que reduz o risco de violações de segurança ao restringir o ambiente de execução de aplicativos não confiáveis usando namespaces Linux). A integração com o desktop pode ser feita com vários programas como AppImage Daemon, AppImage Launcher ou AppImage Desktop Integration (desenvolvido por nós). Por último, AppImages pode ser atualizado usando AppImageUpdate, que atualizará os arquivos usando atualizações delta transacionais (como o ZNX faz), todas as quais incluímos por padrão.

Acho que a única desvantagem é o tamanho dos arquivos em alguns casos, mas também é um caso de onde o AppImage deve ser executado ?. Por exemplo, um roteador não teria centenas de GBs de armazenamento ou mesmo dezenas, mas, ao mesmo tempo, não há razão real para ter um AppImage de desktop como o LibreOffice.

Ainda assim, isso não é um problema em qualquer computador desktop ou laptop razoavelmente moderno, que provavelmente terá centenas, senão milhares de GBs ou mesmo na maioria dos telefones onde o armazenamento interno está chegando a centenas e aqueles que suportam cartões SD também têm acesso para centenas de GBs.

Por falar nisso, um AppImage realmente pretende incluir o que o programa precisa para ser executado, e não se espera que esteja no sistema operacional de destino. Por exemplo, o AppImage de Index (gerenciador de arquivos Maui) tem apenas 50 MBs porque deve ser executado em uma área de trabalho completa (área de trabalho como no tipo de sistema, não como no formato) OS, enquanto se AppImage fosse destinado para ser executado em um servidor, ele teria que ser muito maior, já que o sistema operacional do servidor não teria nenhum software gráfico, para começar.

Ao mesmo tempo, o fato de AppImage incluir tudo o que precisa é o que o faz funcionar não apenas em uma distribuição Linux específica, mas em muitas outras.

Com certeza, obter um arquivo aleatório da Internet pode não parecer uma boa ideia, mas há esforços sendo feitos para fornecer um armazenamento centralizado para AppImages, como AppImageHub.com.

SE: Vejo um acesso pago ao baixar o Nitrux. Por que é que? Qual (outro) modelo de negócios você tem?

A razão é relativamente simples, a Nitrux é uma empresa, não uma organização sem fins lucrativos, e as empresas precisam gerar receita para crescer e continuar o desenvolvimento. Como em qualquer empreendimento comercial, há despesas, embora desenvolvamos software livre e de código aberto. Desde o pagamento de nossos servidores até nossos salários e despesas de viagem para participar de eventos relacionados a FOSS. Portanto, somos francos sobre isso.

Não colocamos anúncios em nosso site ou sistema operacional e não enviamos e-mails de marketing, não coletamos dados do usuário, não incluímos software de terceiros, não importunamos os usuários com chaves de licença, não cobramos dos usuários pelo suporte do Nitrux. Além disso, 99% do nosso trabalho está disponível na forma de código-fonte ou distribuído como um AppImage sem nenhum custo em nossa organização GitHub, ou é hospedado na infraestrutura KDE, como é o caso do MauiKit e do Maui Apps. Também contribuímos com o upstream, como fazemos com o KDE com Kirigami e AppImage (nosso ex-desenvolvedor, Alexis Zubieta, desenvolveu libappimage durante seu tempo com Nitrux e atualmente faz parte da equipe que desenvolve AppImage e todos os seus softwares relacionados).

Eu diria que algumas pessoas, no entanto, parecem pensar que porque estamos fazendo uma distribuição Linux ou porque desenvolvemos software livre e de código aberto, não deveríamos ter que cobrar pelo nosso trabalho porque ninguém mais o faz, ou pior , que não podemos. Nem o FSF nem o OSI proíbem a comercialização de FOSS, então é um argumento inválido, precisamente porque o F em FOSS não significa Grátis (custo zero); na realidade, significa liberdade e nosso software está em conformidade com isso. Não é uma maioria, mas acontece.

Com toda a certeza, entendemos que nem todos podem pagar, por isso oferecemos as compilações Development e Minimal sem nenhum custo, além da fonte.

Ao pagar para baixar a ISO, os usuários estão contribuindo para pagar nossos salários e nossa capacidade de contratar mais pessoas e criar mais software e continuar a aperfeiçoar o que temos.

Além de pagar pelo acesso ao download do Stable ISO, também aceitamos doações através do PayPal ou com criptografia, e também temos páginas do Patreon e do Liberapay.

IF: Você está procurando voluntários, desenvolvedores ou apoio financeiro de qualquer tipo? Alguma mensagem para os leitores?

Uri: Sempre estamos. Se alguém quiser ajudar, ajuda é mais que bem-vinda. Atualmente, não temos nenhuma posição em aberto, pois acabamos de contratar um novo desenvolvedor, mas, felizmente, podemos pagar outro no futuro.

A Nitrux atualmente é composta por 4 membros que logo serão 5:

  • Uri Herrera (eu)
  • Luis Lavaire
  • Camilo Higuita
  • Anupam Basak
  • Ademir Tejada (novo)

Todos nós trabalhamos em tempo integral, pois desenvolver todo o nosso software é nosso trabalho, mas trabalhamos remotamente, pois estamos todos em países diferentes.

Estamos em busca de apoio financeiro, gostei de ter mencionado que aplicamos esse dinheiro diretamente no desenvolvimento de tudo o que fazemos.

Tudo o que posso solicitar dos leitores de FOSS é que experimentem o Nitrux e relatem problemas; é assim que podemos melhorá-lo.

Se você quiser se manter atualizado sobre o que fazemos, siga-nos nas redes sociais como Twitter, Instagram e Telegram. Você também deve ler nosso blog para atualizações mais detalhadas. Claro, você está convidado a contribuir em nosso repositório GitHub.

Confira também a versão original desse post em inglês
Esse post foi originalmente escrito por Abhishek Prakash e publicado no site itsfoss.com. Tradução sujeita a revisão.

How Nitrux is Changing the Traditional Linux Scenario [Interview]

Propaganda
Blog Comments powered by Disqus.
Propaganda