Desenvolvimento de apps para Linux

• Há demanda por novos softwares no Linux para desktop e mobile, mas as lojas de apps e repositórios têm poucos aplicativos, então a mensagem é focar no desenvolvimento de apps em vez de criar novas distribuições
• Mesmo apps que nascem de uma necessidade pessoal, quando desenvolvidos abertamente, podem virar material de aprendizado e comunidade, levando à expansão do ecossistema Linux
• A diversidade de centenas de distribuições é um desafio, mas com sistemas de empacotamento e distribuição bem documentados é possível entregar apps a usuários de vários ambientes
• GNOME, KDE Frameworks, elementary OS, Electron e Ubuntu Touch oferecem caminhos de desenvolvimento diferentes, com Gtk, Qt, Vala, JavaScript·HTML·CSS e QML
• Existem meios de distribuição como AppCenter, AppImage, Flatpak, Open Build Service e Snapcraft, além de possibilidades de monetização por meio de apps e serviços pagos e lojas baseadas em apoio financeiro

---

Por que o Linux precisa de mais apps

• Usuários de Linux em desktop e mobile têm demanda por novos softwares
• As lojas de apps e repositórios do Linux têm menos aplicativos do que plataformas proprietárias
• Para entusiastas de tecnologia, a recomendação é usar paixão e criatividade em novos aplicativos para usuários de Linux, em vez de criar ainda mais distribuições Linux
• A mensagem central é: “parem de criar distribuições Linux e criem aplicativos”

O efeito do desenvolvimento de apps no ecossistema

• Se você tem uma ideia de app que precisa pessoalmente, é possível que outros usuários com necessidades parecidas também tenham
• Ao criar um aplicativo publicamente, desenvolvedores mais novos também podem aprender e começar, o que ajuda a próxima geração de desenvolvimento de apps para Linux
• Desenvolver aplicativos é um trabalho criativo, e a sensação de realização ao concluir um projeto também pode ser uma recompensa
• O desenvolvimento de apps ajuda a formar comunidade, e a comunidade Linux muitas vezes quer ajudar desenvolvedores a ter sucesso
• Habilidade em desenvolvimento de software é uma competência valorizada, e há muitos recursos gratuitos de aprendizado
• A ideia de que usuários de Linux não apoiam financeiramente desenvolvedores é um equívoco; apps e serviços pagos populares podem criar novas fontes de renda

Trabalhando para várias distribuições Linux

• Ao contrário de outras plataformas, o Linux tem uma variedade enorme de alvos, com centenas de distribuições
• Depois de publicado uma vez, um aplicativo em geral pode funcionar em vários ambientes
• Existem sistemas de empacotamento e distribuição bem documentados para que desenvolvedores entreguem apps aos usuários
• Cada framework de desenvolvimento e cada distribuição Linux tem um caminho recomendado para entregar apps aos usuários
• Quando estiver pronto para compartilhar seu app, é possível consultar na documentação de desenvolvimento os guias de empacotamento recomendados

Caminhos para começar a desenvolver

• GNOME

  • O projeto GNOME cria o desktop GNOME Shell e oferece suporte ao desenvolvimento com Gjs e Gtk
  • No Gtk, é possível usar linguagens populares como Python, C, C++, Rust e JavaScript
  • GNOME Developer Center

• KDE Frameworks

  • O KDE oferece o desktop Plasma e ferramentas e frameworks para criação de aplicativos
  • O KDE Frameworks tem sido usado no desenvolvimento de vários aplicativos para desktop
  • Usa principalmente o toolkit Qt e a linguagem de programação C++
  • KDE Frameworks Getting Started

• elementary OS

  • O elementary OS se propõe a ser um sistema operacional rápido, aberto e que respeita a privacidade, como alternativa ao Windows e macOS
  • Os desenvolvedores constroem um desktop e um ecossistema para criação de apps
  • O guia para desenvolvedores recomenda Vala e Gtk
  • elementary OS Developer Guide

• Electron

  • O Electron permite criar apps desktop multiplataforma com JavaScript, HTML e CSS
  • Desenvolvedores podem usar a enorme biblioteca de módulos do node para criar apps baseados em tecnologias web
  • Electron Documentation

• Ubuntu Touch

  • O Ubuntu Touch é um sistema operacional open source projetado para funcionar em vários dispositivos, como celulares, tablets e PCs
  • Apps nativos do Ubuntu Touch são feitos em QML ou HTML, e o comportamento é definido com JavaScript, C++, Python, Rust e Go
  • Ubuntu Touch Documentation

Opiniões de desenvolvedores sobre o ecossistema de apps no Linux

• Neil McGovern, da GNOME Foundation, diz que é preciso um ecossistema de apps próspero para levar o Linux ao grande público, e que todos deveriam poder desenvolver para Linux para aproximar o objetivo de um desktop aberto
• Aleix Pol, da KDE e.V., diz que grandes apps são necessários para fazer do Linux o sistema operacional que as pessoas querem usar, e que as ferramentas de desenvolvimento permitem criar o que se imagina
• Daniel Foré, fundador do elementary, acredita que há oportunidade não só de criar ótimos apps para Linux desktop, mas também de construir APIs de plataforma e influenciar a direção do desktop
• Jan Sprinz, membro do conselho da UBports Foundation, diz que desenvolver apps para Linux é algo totalmente diferente de ecossistemas fechados, e que mesmo competindo tecnicamente, todos colaboram por uma visão maior

Como compartilhar e distribuir apps

• AppCenter

  • É uma loja de apps aberta no modelo pay-what-you-want para desenvolvedores independentes, além de um serviço de build
  • O AppCenter Dashboard integra com o GitHub e oferece suporte a releases e rastreamento de issues
  • AppCenter Dashboard

• AppImage

  • É possível distribuir aplicativos desktop Linux no formato AppImage para alcançar usuários de distribuições Linux em geral
  • A proposta é empacotar uma vez e rodar em qualquer lugar
  • AppImage Packaging Guide

• Flatpak

  • É um framework para distribuir aplicativos de desktop Linux
  • Foi criado por desenvolvedores com longa experiência no desktop Linux e é mantido como um projeto open source independente
  • Flatpak Documentation

• Open Build Service

  • O openSUSE Build Service é a instância pública do Open Build Service
  • É usado no desenvolvimento da distribuição openSUSE e também para fornecer, a partir do mesmo código-fonte, pacotes para várias distribuições como Fedora, Debian, Ubuntu e SUSE Linux Enterprise
  • openSUSE Build Service Help

• Snapcraft

  • O Snapcraft é uma ferramenta de linha de comando para criar snaps
  • Snaps são pacotes de apps para desktop, nuvem e IoT, apresentados como fáceis de instalar, seguros, multiplataforma e sem dependências
  • Snapcraft Documentation

[GN⁺]

Opiniões no Hacker News

• Acho que a premissa está errada pelo fato de o Linux ainda não ter um conjunto de frameworks centrais com ABI estável
  Plataformas concorrentes têm muito mais frameworks básicos, como CoreImage, CoreAudio, CodeML, SceneKit e AppKit, e eles quebram com menos frequência
  snap e flatpak no Linux também são interessantes, mas parecem mais uma forma de contornar o problema via infraestrutura e gerenciamento de pacotes, em vez de resolvê-lo nos próprios frameworks e linguagens de programação que pedem para você usar ao criar apps

  • A comunidade de entusiastas de Linux tende a se opor ativamente a esse caminho. Isso porque quer tornar tudo modular e montar as peças conforme uma aplicação específica
    No Linux também existem conjuntos que são padrões de fato, mas eles mudam e são descontinuados, então são menos estáveis. Ainda assim, é melhor do que parece à primeira vista, e Snaps podem mitigar parte dos problemas
    Só que, se as pessoas escolherem distribuições que não têm esses padrões, no momento em que você não oferecer suporte a todo tipo de configuração peculiar, perde metade dos usuários potenciais
  • Li em algum lugar que hoje o alvo mais estável no Linux é Win32 via Wine ou Proton
  • O núcleo disso eram os frameworks do GNOME ou do KDE e os padrões FreeDesktop; pelo menos esse era o plano 20 anos atrás
    Mas, como o texto diz, a maioria continuou focada em criar distribuições, e naturalmente fica difícil surgir uma única stack que acompanhe todas as inúmeras distribuições peculiares
    No fim, o Google pegou o kernel Linux e colocou por cima dois conjuntos de frameworks centrais baseados em Java e JavaScript; para o consumidor comum, essas distribuições Linux foram as vencedoras
  • Acho que a principal responsabilidade é dos desenvolvedores da glibc. Coisas como abuso de nomes de versão e a adição recente de novos tipos de relocação ELF tornam dolorosa a distribuição de binários de jogos entre várias distribuições
    Em geral, desenvolvedores de jogos compilam em uma distribuição grande e recente e publicam no Steam; se essa distribuição tiver glibc 2.36, muitas vezes o binário também acaba levando nomes de versão que exigem glibc 2.36 ou superior
    No fim, é preciso usar a diretiva symver do binutils gas para forçar nomes de versão compatíveis com uma glibc razoavelmente antiga. Pessoalmente, vejo 5 anos, talvez 7 a 8 anos, como um critério razoável: https://sourceware.org/glibc/wiki/Glibc%20Timeline
    Desenvolvedores de jogos comuns quase não sabem desse problema e, mesmo sabendo, não fariam um trabalho tão doloroso por 1% do mercado. No caso de libgcc e C++, também é preciso linkar libstdc++ estaticamente para evitar esse problema de ABI
    Ainda assim, a engine Godot fornece um contêiner de build que leva isso em conta, e a Unity também parece bem resolvida nesse aspecto. Não sei quanto à UT5.x
    Por outro lado, há engines que não estão preparadas, como jogos baseados em Electron. Se não houver uma versão do GTK+ adequada à distribuição, como Enlightenment, Qt, X11 puro ou Wayland, pode ser que não rode
    Também não é fácil empacotar corretamente todo o engine Google Blink para distribuição binária visando uma ampla variedade de distribuições ELF/Linux
    ELF/Linux, de modo geral, é hostil à distribuição somente em binário por causa de quebras de ABI, especialmente em SDKs e bibliotecas centrais
    Se binários de jogos já são difíceis nesse nível, apps devem ser ainda mais. Dá para imaginar os desenvolvedores acabando por dizer: “não me importa; instalem e usem apenas Microsoft SUSE GNU/Linux, o resto não tem suporte”
  • Se o Linux tivesse a amplitude de frameworks que o macOS oferece, eu já teria feito meus projetos pessoais mirando Linux há muito tempo
    É incrível ter tantas ferramentas prontas para usar sem precisar se preocupar muito com período de suporte, qual fork é melhor ou se combina bem com outras bibliotecas de terceiros. Isso reduz muito o atrito e deixa você simplesmente criar
    Os ecossistemas KDE Qt e GNOME/GTK são os que chegam mais perto, mas ainda não estão nesse nível

• Talvez eu não conheça o padrão que determina quando acrescentar dev e version aos nomes dos pacotes, ou o que significam esses 1 ou 0 arbitrários no fim, mas acho que a primeira distribuição Linux com regras consistentes de nomes de pacotes vai conquistar corações
  libgnutls-dev
libgtk-3-0
libwayland-server0
libxcb1
libx11-6
libffi-dev
libncurses5-dev

  • -dev contém os headers, então é relativamente fácil
    Os números indicam a versão quando é possível instalar várias versões ao mesmo tempo. Mas pode haver exceções, como em xcb1, em que isso faz parte do nome da biblioteca
    Por exemplo, em algum momento talvez fosse possível instalar libgtk-3-0 e libgtk-2-$something ao mesmo tempo. É bem provável que tenham mantido o nome para que, mesmo depois de remover libgtk-2, referências a libgtk-3-0 em tutoriais antigos não quebrassem
    Também não sei bem o que significa o 0 no fim de libwayland-server0. Vejo em /var/lib a mesma biblioteca com vários sufixos .$number, mas nunca fui investigar exatamente que problema isso resolve
  • Separar binários e código-fonte é uma convenção do Debian. Se você só vai usar a biblioteca, o pacote sem -dev basta; se vai desenvolver com essa biblioteca, também precisa do -dev, que instala os headers
    O 1 ou 0 no fim não é nada especial, é apenas parte do nome ou da versão do pacote
  • No Arch e nas distribuições derivadas dele, em geral isso não existe
    Mas -dev significa coisas necessárias apenas quando se vai desenvolver tendo aquela biblioteca como alvo
    O número é o número da versão principal, ou seja, o número de compatibilidade. Graças a isso, várias versões principais exigidas por pacotes diferentes podem ser instaladas juntas facilmente, sem conflito
  • Se você está compilando um programa, instale o pacote -dev. Normalmente não é preciso se preocupar diretamente com pacotes -dev numerados; se necessário, o pacote sem número deveria encaminhar isso
    Durante a compilação, fica registrado qual sufixo numérico, isto é, qual versão da ABI, foi usado. Isso deve corresponder ao sufixo .so.N, mas você não procura diretamente desse jeito
    Esse método permite instalar várias cópias incompatíveis de uma biblioteca e fazer com que a correta seja usada. As distribuições normalmente limpam as antigas a cada grande release
    Na instalação, as dependências registradas durante a compilação deveriam ser usadas automaticamente
  • Existe o GoboLinux e, do meu ponto de vista, ele resolve tudo sem ser tão complexo quanto o Nix. Mas ninguém deu bola

• Este é um dos maiores problemas que seguram a plataforma Linux como um todo. Costumam citar isso como vantagem, mas não vejo assim
  Desenvolvedores apresentam a abundância de opções como uma vantagem do Linux, mas para muitos usuários isso vira o paradoxo da escolha e os faz voltar para a plataforma que já usavam
  No macOS e no Windows há menos opções, mas as opções disponíveis são muito mais polidas e menos fragmentadas
  Por exemplo, de quantos gerenciadores de janelas em mosaico precisamos? Não daria para escolher o melhor gerenciador de janelas em mosaico e criar docks e applets melhores? E apps e launchers integrados ao paradigma de gerenciador de janelas em mosaico?
  Em vez disso, muitas vezes acabamos com 10 gerenciadores de janelas em mosaico e gambiarras pela metade por cima deles

  • As pessoas não escolhem analisando exaustivamente todas as opções. Elas olham para um pequeno conjunto de candidatos e escolhem um com base em popularidade ou acessibilidade
    Um ecossistema bem-sucedido faz com que escolher uma opção bem visível ainda leve a um resultado bom o bastante
    O aumento no número de distribuições Linux, na maior parte, são pequenas diferenças que não reduzem uma adequação significativa, e só é visto como problema pela minoria minúscula que nunca teve dificuldade para escolher uma distribuição
    Por outro lado, em casos como o Wayland, a infraestrutura interna e o hardware de repente passam a importar, e é preciso entender um pouco da estrutura interna para escolher uma combinação utilizável, então isso vira um problema real
    Comparar Mac ou Windows com Linux também não faz muito sentido. Para 95% dos consumidores, o sistema operacional é uma característica fixa ou uma função do computador, não um produto separado
    Se o pacote como um todo fizer sentido, eles podem comprar um computador com aquele sistema operacional instalado, mas não vão tentar instalá-lo separadamente no seu aparelho com Windows ou Mac
    Pessoas com conhecimento técnico suficiente para ficarem satisfeitas provavelmente não vão se confundir muito só porque surgiram mais três derivadas do Ubuntu e duas do Arch
  • Criar um gerenciador de janelas em mosaico é divertido. Fazer software em colaboração não é apenas um meio para obter algum resultado, mas também um fim em si mesmo
    Tornar-se desenvolvedor de código aberto significa poder definir por conta própria os objetivos e os meios, uma liberdade que muitas vezes não existe no desenvolvimento de software comercial
    As arestas aparecem, mas o efeito IKEA entra em ação e você acaba gostando
  • Esse problema é algo que as distribuições devem resolver. Quem não quer muitas opções pode usar uma distribuição que tome muitas decisões por você, sem precisar pressionar para eliminar opções do ecossistema inteiro
    Se todo mundo usa o mesmo software, vira uma monocultura mais vulnerável a ataques. Um dos motivos pelos quais o Windows foi muito visado por vírus é que o alvo era grande e consistente
    Se você invadisse a máquina Windows de um usuário comum, conseguiria invadir as demais de forma parecida. Mirando Linux, isso é muito mais difícil
    Além disso, é software livre. Se você não está pagando alguém para fazer, na maior parte é trabalho voluntário, e não podemos dizer aos outros onde gastar seu tempo de voluntariado
    Se há tantos grupos assim e mesmo assim ninguém quer entrar, também precisamos olhar para as estruturas sociais dominantes. Talvez um ponto de partida seja eliminar códigos de conduta que permitam punir até comportamentos fora do projeto
  • Acho que há mais launchers e docks do que gerenciadores de janelas em mosaico
    E também não sei bem o que ainda precisa melhorar. Coisas como Ulauncher ou Albert são muito mais poderosas do que o que é possível em outras plataformas, e não sei como tornar a UI melhor
  • Deve haver tantos gerenciadores de janelas em mosaico quanto as pessoas quiserem criar

• É bom que haja mais software. Mas, antes de criar algo do zero, talvez valha a pena contribuir para algo que já existe, ou escolher um projeto abandonado, ou que precise de ajustes para compilar e rodar em compiladores e hardware atuais
  Também fico curioso se existe em algum lugar um banco de dados de projetos dormentes ou mortos que valem a pena ressuscitar

  • Algo já existente pode não ter sido feito da forma que eu tenho como objetivo
    Outro projeto pode ser liderado por alguém difícil de conviver, ou ter uma comunidade que não aceita sugestões e patches
    Processos sociais e bloqueios podem fazer a pessoa perder a motivação para contribuir. Nem todo mundo consegue ser um jogador de equipe otimista e sem personalidade
    Para mim, é melhor começar do zero. Porque posso controlar todas as variáveis, não preciso mexer na infraestrutura social e técnica existente, não preciso convencer alguém de que minhas ideias são boas e não quero gastar mais tempo com discussões e debates do que com código
    A experiência de desenvolvimento solo é melhor. Porque não fico preso a política e processos sociais, e tentar ser um jogador de equipe só me trouxe sofrimento
  • Na maioria das áreas há tentativas de baixo nível demais, e, se esse esforço fosse concentrado nos poucos principais projetos, poderiam sair alguns apps excelentes
    Colaborar pode parecer oneroso e difícil, mas no fim é algo que entrega resultado, e é um tempo melhor empregado do que o gasto em projetos que serão abandonados
  • Fico curioso se algum dos principais repositórios de pacotes Linux coleta estatísticas que permitam buscar apps muito usados, mas sem manutenção ou com recursos incompletos

• Há muitas reclamações de que faltam ferramentas para criar apps compatíveis com vários sistemas operacionais, mas não concordo. Basta olhar para soluções que não são Electron
  O Telegram usa Qt para distribuir apps nativos de bom desempenho nos três sistemas operacionais
  O Flutter compila para código nativo nos três sistemas operacionais e em mobile
  O Kirigami é um framework QtQuick que permite criar apps executáveis tanto para mobile quanto para desktop
  É só criar o app. Não há motivo para usar isso como desculpa para culpar o Linux

  • O Flutter se comporta de forma ligeiramente diferente em cada plataforma, gerando uma experiência sutilmente ruim em todas elas. Kirigami ou Qt Quick também são difíceis de considerar opções realmente viáveis
    No Windows, macOS e mobile, quase não há comunidade ou projetos sérios. Não estou tentando diminuir o lado do KDE, mas essa é a realidade
    A licença do Qt Quick também não é simples no iOS ou, no caminho comercial, sai muito cara
    Por outro lado, grandes empresas investem no Electron e entregam ferramentas de nível de produção muito polidas, há uma comunidade enorme e um ecossistema de bibliotecas, e ele também não exige uma linguagem pouco familiar como Dart
    O Telegram realmente faz um esforço além. O cliente é excelente
  • O app do Telegram baseado em Qt também roda bem no macOS, mas a maioria dos usuários Apple escolhe o cliente Swift/Cocoa para macOS e iOS[0]
    [0]: https://github.com/overtake/TelegramSwift

• O problema é que o software OSS nem tenta direito competir com o mercado
  As pessoas que usam software OSS aceitam como algo natural que a UX vai ser insuficiente, e muitas vezes isso acontece mesmo
  O software proprietário comum se adapta para melhorar a experiência do usuário final porque existe o risco de o usuário não pagar, mas no OSS normalmente esse risco não existe. O open source também precisa ficar exposto ao risco vindo do usuário final
  Tentei mudar isso com o Notes[1], mas percebi que é difícil viver só de anúncios. Também coloquei pagamento por recursos premium como Kanban, mas o app é FOSS completo, então qualquer um pode compilá-lo facilmente a partir do código-fonte
  No meu próximo app[2], penso em mantê-lo como código fechado antes do lançamento. Não posso assumir o risco de meu esforço não ser recompensado
  Acredito que, se eu puder cobrar, vou conseguir investir mais em apps focados em UX no Linux, então isso também ajudará a comunidade Linux. Talvez eu abra partes como open source, e talvez, em um futuro distante, abra tudo
  [1] https://github.com/nuttyartist/notes
  [2] https://www.get-plume.com

  • Há uma grande interseção entre usuários de Linux e pessoas que valorizam a liberdade. Para muita gente, um app de notas que não seja open source nem sequer é uma opção desde o início, por causa de lock-in de fornecedor e questões de privacidade
    Por isso, se você não tornar o programa open source, é bem possível que perca mais do que se o tornar open source e assumir o risco de algumas pessoas não pagarem
    Acho que há muito mais gente disposta a pagar para usar open source do que gente disposta a usar software proprietário
    O fato de ser open source não significa que você precise distribuir o código para todo mundo; se estiver cobrando, pode entregar o código-fonte só aos usuários pagantes. Porém, eles terão o direito de modificar e redistribuir
    Se a pessoa não se importa com open source, pode usar Notion ou Evernote. Se estiver procurando um app de notas open source moderno, recomendo o Logseq
  • Parece que você está tomando a decisão certa. Ganhar dinheiro em nível de sustento com open source é extremamente difícil, e a escala é várias ordens de grandeza menor do que a de quem vive de software comercial
  • Entendo a frustração, mas também há contraexemplos. Não é minha intenção desmerecer
    Primeiro, o Notes parece bastante parecido com o Standard Notes. Se você criou o Notes usando OSS copyleft, acho difícil reclamar, a menos que pague royalties pelo trabalho de outros programadores incluído nele
    Segundo, provavelmente sou um usuário atípico. Uso Linux há mais de 20 anos, mas não consigo escrever direito nem um script Bash nem uma linha de Perl
    Mas justamente por não saber programar e por ser grato pelo trabalho dos outros e pela liberdade que ele proporciona, gastei muito mais dinheiro com software do que indivíduos normalmente gastam em outras plataformas
    Apoio vários projetos e serviços, como Kaisen e Debian, os utilitários essenciais da FSF e Emacs, KDE, Firefox da Mozilla, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek e envs.net
    Em alguns pago anualmente, em outros mensalmente, e em outros paguei só uma vez
    Quando o Standard Notes foi lançado, também paguei uma assinatura de 7 anos, mas depois de uns dois meses de uso não fiquei satisfeito e parei. Há coisas que uso bastante, como o Alacritty, mas para as quais não consegui encontrar um meio de doar, e tento minimizar esses casos
  • Pessoalmente, acho que o KDE está muito à frente do macOS e do Windows
    Na verdade, sinto que o macOS tem um dos piores gerenciadores de janelas entre as plataformas populares. Ele é bonito e fácil de usar, mas, para fazer qualquer coisa além do básico, você precisa de feitiços mágicos que não são descobertos naturalmente
    Claro, cada um tem seu gosto
  • Tenho alguns pensamentos. Mesmo acompanhando bastante essa área, nunca tinha ouvido falar desse app, e a concorrência é extremamente acirrada
    Cliquei para ver o preço premium; em termos anuais era razoável, mas só aparecia a opção de assinatura mensal, então achei difícil
    Nesse tipo de app, é mais provável que eu faça uma doação do que pague por uma versão premium. O Obsidian conseguiu fazer esse modelo funcionar bem
    Não acho que acesso antecipado a recursos tenha muito valor, mas muita gente pagou para apoiar o trabalho
    Também acho que uma estrutura com um grande ecossistema open source em torno de um produto central fechado cria motivos para as pessoas pagarem

• Acho que teria sido bom se o texto trouxesse alguns exemplos
  Não me vem facilmente à cabeça alguém que esteja criando uma distribuição quando, na verdade, deveria estar criando uma aplicação. Forçando um pouco, talvez o LinuxCNC? Mas ele tem requisitos específicos de kernel, então talvez uma distribuição customizada faça mais sentido

  • Ambientes de desktop são, na prática, aplicações que podem ser instaladas facilmente com um ou dois cliques ou comandos
    Não entendo muito bem quando uma distribuição derivada de outra derivada é distribuída apenas por incluir um ambiente de desktop diferente

• Em vez de “pare de criar distribuições Linux e crie aplicações”, acho melhor parar de ouvir pessoas que querem dizer o que se deve ou não fazer

  • Esse tom também me incomodou
    Ainda assim, a mensagem e as informações em si são boas
    Pessoalmente, eu teria dito algo como “usuários de Linux não querem mais distribuições. Querem software”. Pelo menos eu penso assim
  • Também é preciso parar de ouvir as pessoas que dizem para parar de ouvir pessoas que querem dizer o que se deve ou não fazer. Nem tudo é relativo; existem escolhas boas e escolhas ruins

• Recentemente migrei do Mac para o Linux, porque queria usar um equipamento usado de bom desempenho como minha máquina do dia a dia
  Eu já tinha instalado Linux em várias máquinas antes, mas desta vez não era só um hobby
  O Ubuntu dá bom suporte ao meu hardware e aos periféricos, mas a loja de apps parece inacabada e meio encaixada à força. Ainda assim, quase tudo funciona como esperado
  Quero conferir também Mint, Debian e Arch, mas fico cauteloso porque parece haver muito software escrito com Ubuntu em mente

  • O Linux Mint é baseado no Ubuntu, então consegue usar pacotes do Ubuntu sem problema. Na prática, dá para vê-lo como um Ubuntu melhor
    Também existe uma versão do Mint baseada em Debian, mas ela é mais uma salvaguarda para não depender de forma crítica do lado do Ubuntu
    Hoje em dia, mesmo usando uma distribuição mais incomum, isso não costuma ser um grande problema. Se o gerenciador de pacotes padrão não oferecer o app desejado, dá para usar AppImage, Flatpak ou Snap
  • Entre o que foi escrito para Ubuntu, quase nada deixaria de rodar no Arch ou na maioria das distribuições modernas
    Quando usava Arch, precisei me acostumar com as suposições que as pessoas fazem tendo o Ubuntu como referência, mas na maioria dos casos era só corrigir arquivos de configuração ou definir variáveis de ambiente
    Essas são habilidades úteis e transferíveis para outros lugares
  • Também vale muito a pena experimentar o Fedora
    Acho que eu gostaria de ter experimentado antes

• Fico pensando por que alguém faria isso. É mais difícil, e usuários de Linux não pagam por coisas que não valem a pena pagar

  • Porque o mundo se beneficia quando há mais software livre/gratuito de qualidade