Resolvi fazer este artigo para quem está curioso sobre as próximas tecnologias do sistema GNU/Linux que, provavelmente, estarão em seu Desktop dentro de alguns anos (ou alguns meses, para quem usa Arch Linux).

Minha última atividade aqui, no Viva o Linux, tem alguns meses (talvez anos) e eu tinha um artigo em construção, no qual o objetivo era apostar quais seriam as próximas tecnologias e, no futuro, descobrir se eu tinha acertado. Mas, fui acumulando preguiça de desenvolver um artigo longo e valioso, e tive a ideia de condensar o artigo.

PackageKit

Desde muito tempo que o GNU/Linux é materializado em diversas distribuições voltadas para grupos de usuários específicos e, um dos fatores mais importantes para o desenvolvimento e manutenção de uma distribuição, costuma ser o gerenciador de pacotes.

Uma causa que contribui ainda mais para a fragmentação de esforços, entre essas distribuições, é o uso de formatos de pacotes diferentes. Quer instalar algum software? No Debian, vocês usa apt-get, no Fedora, você usa yum e no Arch Linux, você usa pacman.

Cada um desses gerenciadores de pacotes aceita um formato de arquivo diferente, então, para distribuir software pré-compilado, você precisa ter o trabalho múltiplas vezes (ou adotar estratégias diferentes, como delegar o trabalho para os desenvolvedores das distribuições ou fazer uso de um ambiente, como a STEAM_RUNTIME).

Essa fragmentação existe há muito tempo e eu não acredito que ela vá acabar tão cedo (principalmente, porque mesmo que uma cooperação maior aconteça, muitos desenvolvedores adoram o argumento de "Por que eu vou substituir algo que já está funcionando?").

Apesar de parecer ser um problema só para desenvolvedores, e que não afeta o usuário final, você provavelmente utiliza o GNOME, KDE ou algum outro ambiente gráfico que, provavelmente, existe nos repositórios de software das distribuições de outros usuários.

Não seria legal se os desenvolvedores do seu ambiente gráfico desenvolvessem uma interface gráfica legal para instalar, atualizar e remover softwares? Com essa fragmentação, a existência de tal solução é reinventada de novo e de novo, para cada distribuição GNU/Linux, mas há esperança no PackageKit, que não é tão novo assim (mas que tenho a impressão de ser pouco disseminado).
O PackageKit é uma "camada" entre os componentes essenciais da sua distribuição e os aplicativos. Ela deve funcionar da mesma forma em todas as distribuições e cuida da instalação/remoção/atualização de softwares/pacotes.

Vários ambientes gráficos já fornecem programas que fazem uso do PackageKit, e a única coisa que falta para o futuro virar presente, é uma adoção maior.

Btrfs e F2FS

Eu lembro quando fiquei ligeiramente animado no lançamento (estável) do ext4 pela característica de desfragmentação online. O ext3 já fragmentava pouco (em comparação aos sistemas que eu estava acostumado) e agora, eu sequer vou precisar desfragmentar o sistema manualmente.

Até hoje, ele é o sistema de arquivos padrão em meus computadores, mas, outros sistemas que prometem mais, estão em desenvolvimento já há algum tempo e em breve, poderemos compartilhar de ainda mais funcionalidades legais.

O Btrfs, é o sistema ao qual eu fui apresentado como "o sistema que teria a capacidade de ser redimensionado online" (enquanto está sendo usado). Hoje em dia, até o ext3 tem essa capacidade, de acordo com as notas de lançamento do GParted 0.17.0, mas, o Btrfs continua a evoluir e adicionar funcionalidades legais, como compressão transparente (que será de grande utilidade para o meu Desktop, que só tem um HD interno de 20 GB), Snapshots e outros.

Outro sistema de arquivos interessante, é o F2FS, sendo desenvolvido pela Samsung que, pretende fornecer várias (mas não todas) das funcionalidades do Btrfs (compressão, etc), e que leva em conta características de dispositivos de memória Flash. Quando for marcado com a "etiqueta estável", planejo converter o sistema de arquivos de alguns dos meus cartões de memória.

Imagino que novos sistemas de arquivos devam ser desenvolvidos no futuro. Por exemplo, o Btrfs é baseado em uma estrutura de dados B-Tree, mas, recentemente, fiquei ciente de um banco de dados que usa uma estrutura de dados novas, a Fractal Tree, que o ajuda a obter mais desempenho que outros bancos de dados que são baseados em B-Tree.

Mas, esses esforços são eventos que só melhoram a qualidade do sistema operacional, e não é algo que vai exigir esforço da nossa parte diariamente (sistemas de arquivos são tecnologias que demoram a ser desenvolvidas e adotadas).

systemd

systemd é um polêmico sistema de init que está sendo adotado como default em muitas das principais distribuições GNU/Linux (Arch Linux, openSUSE, Fedora, Debian, Ubuntu, etc) e, dessa forma, está unificando os arquivos de configurações importantes (locale é em /etc/default/locale ou /etc/locale.conf? Como habilito sistema X a ser iniciado junto com o sistema?).

Funcionalidades interessantes do systemd, incluem suporte a cgroup (fornece um gerenciamento de processos e recursos mais robusto, flexível, ...), logs menos frágeis (logs não-binários são legais para processar com ferramentas, como grep e sed, mas o systemd já fornece vários filtros poderosos), gerenciamento de dependências com suporte a paralelismo (boots mais rápidos, enquanto permanecem corretos!), ativação por socket, etc.

Para uma lista condensada de suas funcionalidades, recomendo acessar a página no site do Debian, que foi construída enquanto ocorria o debate pelo sistema de init default (?):

• Debate/initsystem/systemd - Debian Wiki

kdbus

E já que eu citei o systemd, vale também citar o kdbus, que é uma tentativa de mover partes da implementação do daemon D-Bus para o kernel.

O D-Bus é o mecanismo de IPC que é responsável por "integrar" os vários componentes da suas aplicações no sistema GNU/Linux. O seu gerenciador de arquivos, que mostra novos dispositivos ao serem inseridos, podem estar fazendo uso da interface (D-Bus) udisks, assim como a notificação no canto da tela, de que um novo contato ficou online usa D-Bus, assim como é possível controlar o seu Media Player favorito através de um Dock/Painel, que você instalou graças a interface (D-Bus) MPRIS... O D-Bus é um componente núcleo bem popular de um ambiente GNU/Linux moderno.

O que acontece com a introdução do kdbus, é que agora, ele está disponível já a partir do momento em que o kernel é carregado, sistemas de segurança mais sofisticados tornam-se possíveis/fáceis (kernel informa pid + starttime + user + ... do processo requisitando alguma ação) e você ganha desempenho (quando as mensagens são grandes o suficiente.

O kdbus até faz uso de um esquema para evitar qualquer cópia das mensagens/requisições na memória RAM). Então, num futuro esperançosamente não tão distante, o seu sistema GNU/Linux vai, não só magicamente, ficar mais rápido após alguma atualização, como também, os desenvolvedores passarão a usar mais e mais o D-Bus, até para tarefas que antes não eram adequadas (distribuir o próprio fluxo de música/áudio entre processos usando D-Bus).

O kdbus não foi a primeira tentativa do time que está por trás da iniciativa, e antes, eles tentaram estender as interfaces de comunicação do kernel (multicast AF_UNIX, AF_DBUS, etc), mas elas foram rejeitadas, e eles decidiram implementar algo específico para D-Bus, em vez de algo mais genérico e útil.

Em seu atual estado, o kdbus pode ser usado em um sistema GNOME completo [Lennart Poettering]. Para quem possuir o interesse de saber mais, é só seguir o Lennart Poettering no Google Plus e procurar o vídeo de uma de suas recentes palestras sobre o tema.

Wayland

Eu já tinha escrito uma dica sobre Wayland aqui no VOL , mas hoje em dia, acho que o modo como escrevi foi um pouco emocional/nobre/filosófico/não-muito-técnico. Há lugares melhores do que meu texto anterior para procurar por aspectos técnicos.

Wayland é o novo sistema gráfico do GNU/Linux que está recebendo, incrementalmente, o apoio de vários desenvolvedores e promete resolver vários dos problemas do X11.

Ele está bem tangível e cada vez mais próximo de estar presente em seu computador. Ao rodar o Weston, um dos poucos ambientes gráficos que conversam Wayland, em meu computador, essa foi a lista de problemas que encontrei:

• Demora um pouco (2s) para Ctrl+Alt+f do Weston para outros Ctrl+Alt+f. Algo negligenciável, que espero que mude, e que não é algo que eu faço o tempo todo (ou sequer toda semana).
• O Weston não reconheceu meu teclado ABNT2, como ABNT2.
• Não consegui rodar aplicações Qt, apesar de que isso, provavelmente, é a falta de uma configure flag nos pacotes do Arch Linux ou, talvez, o suporte ainda não ter sido lançado em uma versão estável.
• Não consegui rodar aplicações SDL, mas, desenvolvedores já anunciaram interesse e há algumas patches/vídeos por aí.
• O Firefox não abre, pois parece referenciar detalhes específico do X, em vez de confiar unicamente no GTK+.
• As janelas em tela cheia travam no método driver (mas funcionam nos outros modos). E por travam, eu quero dizer que o ambiente gráfico inteiro vai abaixo. Teste de uma aplicação do Weston.
• O uso de EGL corrompe o gráfico (mas só da janela que o utiliza).
• Estressar muito a aplicação weston-stacking, faz o Weston travar.

Note que (1) eu não fiz nenhum esforço para fazer meu teste (baixar pacotes experimentais de um repositório Git, ...) e que (2) alguns dos erros são provavelmente erros do Weston e não do Wayland em si.

Também, o Weston é só um ambiente gráfico de teste puramente focado no Wayland, então, as aplicações X (via XWayland) não funcionaram aqui (não sei se precisa fazer alguma coisa para essa funcionalidade ser ativada).

Quando os principais ambientes de trabalhos (KDE, GNOME, Enlightenment, etc) passarem a funcionar sem problemas com o Wayland, eu irei migrar. E acho que a lista de erros acima estará acabada ou contornável (o XWayland permite compatibilidade com aplicações X).

E alguns temem que possa haver uma queda no desempenho pelo fato de o Wayland necessitar de drivers livres. Na verdade, ele requer drivers que usem as modernas tecnologias da camada gráfica do GNU/Linux, que incluem o KMS. O KMS, por problemas de licenciamento, requer um driver livre.

Um link que eu gosto de compartilhar em resposta, é essa notícia antiga do Phoronix.

A notícia citada, tem o seguinte trecho:

"[...] In fact, he says it's one of his goals to see there aren't any performance drops, but the performance of X applications on Wayland may actually yield a performance boost [...]".

Ou seja, a arquitetura do Wayland é superior, e mesmo que você execute aplicações X dentro de um compositor Wayland, você vai ter uma melhora na performance.

Linux Containers

Um container, em uma explicação intuitiva, é uma versão moderna do chroot. Caso você queira usar um sistema Ubuntu dentro do Fedora, pois algum software (ROS, eu estou olhando para você) exige uma instalação do Ubuntu, você tem a opção de sacrificar desempenho e usar uma máquina virtual, ou sacrificar segurança/isolamento por um chroot.

O problema do chroot, é que ele não tem um espaço de PIDs diferentes, então, você não poderia rodar o upstart dentro do containers. Pode não parecer grande coisa, mas, dependendo do que você queira rodar dentro do Ubuntu, vai ter bastante trabalho substituindo as rotinas que levantam os seus serviços, tendo ainda, a possibilidade de quebrar na próxima atualização.

Linux Containers combina o uso de tecnologias do Linux como cgroups, para gerenciar recursos e namespaces para isolar processos.

Os namespaces do Linux, permitem que processos-filhos tenham uma visão diferente do sistema operacional, o que possibilita usos interessantes.

Pode estar parecendo algo técnico e que só um administrador de sistemas utilizaria. E tecnologias de containers, como o Docker, até reforçam essa linha de pensamento, mas, containers dão aos desenvolvedores o potencial de criar sandboxing amigável aos usuários (à lá Symbian, que tem a caixa para marcar "permitir acesso à internet") ou mesmo, a criação de aplicações autocontidas, que vão funcionar por realmente-muito-muito-muito-tempo, sem o impacto na performance que temos com máquinas virtuais e até com uma integração maior com o ambiente hospedeiro.

Esse é um tópico bem grande, então, vou só apontar para um texto que escrevi há um tempo (e recomendar que você pesquise por mais):

• Adeus chroot… seja bem vindo LXC… « Vinipsmaker labs

KLANG

Na mesma linha do sistema de som JACK, que permite o roteamento flexível de fluxos, e na mesma linha do kdbus, que pretende fazer o trabalho bruto no kernel, há o KLANG, um sistema de áudio que parece notícia de primeiro de abril e está envolto em mistérios.

Esse é o item do artigo que mais está no futuro, e não há nada de concreto. :)

• [Phoronix] KLANG: A New Linux Audio System For The Kernel