Próximas Tecnologias do Sistema GNU/Linux

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).

[ Hits: 9.997 ]

Por: Vinícius dos Santos Oliveira em 19/02/2014 | Blog: https://vinipsmaker.github.io/


Tudo é Um e Um é Tudo



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.
Linux: Próximas Tecnologias do Sistema GNU/Linux

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).
Linux: Próximas Tecnologias do Sistema GNU/Linux

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.
Linux: Próximas Tecnologias do Sistema GNU/Linux

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 (?):

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):

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. :)
   

Páginas do artigo
   1. Tudo é Um e Um é Tudo
Outros artigos deste autor

GNU Emacs, o primeiro GNU

Tratamento de exceções na linguagem C

História da informática: Um pouco de datas e especificações

Aplicativos web em C++ usando o Tufão

Entendendo os codecs, os containers formats e por que o Ogg é tão bom

Leitura recomendada

Creative Commons

Quero facilidade!

Cego guiando cego

Eu gostava do MS-DOS

Um mês de Arch Linux: Resultado obtido

  
Comentários
[1] Comentário enviado por sammuca em 20/02/2014 - 19:46h

Eu gostei do seu artigo Vinis gostaria mais se houvesse uma rápida explicação sobre sobe as tecnologias citadas, para que lego como eu posa aprende mais sobe universo dos desenvolvedores e da computação. É claro que um e outro deu para capitar no ar mas alguns ficarão muito difícil de entende uma rápida descrição sobre eles seria muito útil para pessoas como eu querem aprende e conhecer mais afundo computação.

[2] Comentário enviado por vinipsmaker em 20/02/2014 - 20:02h

@sammuca:

Quais os itens que você acha que precisam de um texto melhor?

O motivo de eu finalmente ter escrito o texto foi a ideia de condensá-lo, mas posso escrever futuros textos independentes e focados em um item só.

[3] Comentário enviado por sammuca em 20/02/2014 - 20:51h


[2] Comentário enviado por vinipsmaker em 20/02/2014 - 20:02h:

@sammuca:

Quais os itens que você acha que precisam de um texto melhor?

O motivo de eu finalmente ter escrito o texto foi a ideia de condensá-lo, mas posso escrever futuros textos independentes e focados em um item só.


os itens que na minha opião precissão de uma melhor exclarecimento é systemd,PackageKit, waylend que não ficou muito claro papel de e papel do Weston no ambiente gráfico e para pessoas que não sabem o que sistema de qrquivo, que não meu caso, os Btrfs e F2FS meio confuços

[4] Comentário enviado por vinipsmaker em 20/02/2014 - 21:16h


[3] Comentário enviado por sammuca em 20/02/2014 - 20:51h:
os itens que na minha opião precissão de uma melhor exclarecimento é systemd,PackageKit, waylend que não ficou muito claro papel de e papel do Weston no ambiente gráfico e para pessoas que não sabem o que sistema de qrquivo, que não meu caso, os Btrfs e F2FS meio confuços


Sobre systemd e wayland, eles são sistemas que merecem, cada um, seu próprio artigo. Acho que vou colocar mais artigos lá na fila de espera, mas não sei quando vou ter tempo de reunir as várias referências e pesquisas para juntar em um bom artigo.

###

Sobre o PackageKit, posso tentar explicar aqui nesse comentário mesmo (até porque não tenho interesse em fazer um artigo só para falar dele):

Quando você está usando o Debian, você usa a interface gráfica/programa synaptic para gerenciar pacotes.

Quando você está usando o Ubuntu, usa o Ubuntu Software Center (apesar de que podia usar o Synaptic também, porque Ubuntu ainda é Debian).

Quando você usa openSUSE, usa o YaST.

E assim por diante. Cada distribuição cria sua própria interface gráfica.

O problema *não* é a desunificação. O problema é que não dá para fazer uma interface gráfica que funcionem em várias distribuições diferentes. No GNU/Linux temos vários ambientes de trabalho (a coisa que gerencia a interface gráfica e as janelas) e cada usuário escolhe o que lhe atende melhor. Às vezes esses ambientes de trabalhos chamam a atenção do usuário por justamente caminhar em uma direção muito diferente (ser controlado somente via teclado, ou somente via mouse, ou ainda ser otimizado para interfaces de tablets, ...) e eles se beneficiariam de ter uma interface gráfica própria para instalar programas, que se ajustasse melhor ao resto do ambiente. Bom, sem o PackageKit (ou outra camada substituta), fica inviável fazer uma interface gráfica que funcionem no openSUSE, ArchLinux, Fedora, Ubuntu, Debian, ... e nas várias distribuições GNU/Linux das quais desfrutamos. Essa é a função do PackageKit. Já imaginou clicar em um link no firefox e o gerenciador de pacotes abrir perguntando se você gostaria de instalar um jogo do site que você estava acessando? O firefox e qualquer outro aplicativo pode fazer uso do PackageKit também.

[5] Comentário enviado por Fabio_Farias em 21/02/2014 - 10:35h

Em matéria de sistema de arquivos existem outros dois já disponíveis para Linux (pelo menos nos repositórios do openSUSE já estão). São eles: NilFS2 e ExoFS.

[6] Comentário enviado por vinipsmaker em 22/02/2014 - 00:14h


[5] Comentário enviado por Fabio_Farias em 21/02/2014 - 10:35h:

Em matéria de sistema de arquivos existem outros dois já disponíveis para Linux (pelo menos nos repositórios do openSUSE já estão). São eles: NilFS2 e ExoFS.


@Fabio_Farias, o Linux é bem flexível em relação a sistemas de arquivos.

Eu já trabalhei em um lugar onde tinha um cluster que mantinha um sistema de arquivos em rede chamado Lustre. Eles montaram um RAID em software, para fazer os muitos e muitos HDs serem vistos como um único HD (na verdade em alguns grupos para adicionar redundância), daí usando essa técnica eles instruíam o Lustre a guardar os metadados dos arquivos nos SSDs e os dados brutos nos HDs, mas o sistema fazia a escrita em paralelo. No final de tudo, acabava que escrever em rede (lá eles usavam InfiniBand para montar a rede), acabava sendo um processo mais rápido que escrever no próprio HD!!!

E também tem um dispositivo embarcado que possuo e roda Linux, onde a memória flash não é acessada através do tradicional FTL (FLash Translation Layer) que faz os sistemas operacionais enxergarem a memória como se fosse um HD. Nesse ambiente, o Linux usa uma abstração especial, chamada MTD, para a qual existem sistemas de arquivos capazes de explorar as características de memórias flash.

No artigo eu acabei citando o Btrfs e o F2FS, porque acho que eles são os mais direcionados aos usuários e que provavelmente irão se tornar o padrão nos instaladores das suas distribuições preferidas, pois cobrem uma área grande o bastante para os dispositivos comuns que temos acesso. O btrfs, por exemplo, vai ser adotado como padrão na próxima versão do OpenSUSE, pelo que indicam algumas notícias circulando na net. E para o F2FS, que é direcionado para pen drives e cartões de memória, estão planejando até drivers para Windows, pensando na portabilidade.

Mas esses dois, NilFS2 e ExoFS, eu não acompanho muito. Quais informações você teria para compartilhar conosco?
=P

[7] Comentário enviado por Fabio_Farias em 23/02/2014 - 09:36h

O pouco que sei sobre esses sistemas de arquivos obtive a partir desse link: http://www.ibm.com/developerworks/br/linux/library/l-nilfs-exofs/


[8] Comentário enviado por vinipsmaker em 23/02/2014 - 14:19h

@Fabio_Farias, valeu pelo link.
:D

[9] Comentário enviado por vinipsmaker em 15/03/2014 - 18:00h

Pequeno UPDATE para informar que testei o Weston novamente e as aplicações SDL2 já funcionam muito bem (mas sem decorações de janela) com a última versão e aplicações que usam EFL, o toolkit do Enlightenment, também funcionam muito bem, apesar de que a única aplicação usando esse toolkit que eu tenho é o Terminology.

[10] Comentário enviado por albfneto em 16/03/2014 - 23:18h

ótimo artigo!

de fato, Systemd já está sendo adotado por várias Distros, por exemplo, sabayon, openSUSE etc...

PackageKit é uma espécie de instalador Universal. Por exemplo, o instalador de pacotes do entropy, do sabayon, usa packagekit.

PackageKit é muito versátil, tanto vai bem com DEB, como com RPM e mesmo linux de compilação, como gentoo, pode usá-lo.

sobre substituir o chroot, seria uma mão na roda para iniciantes.

O Chroot é crítico, e se o usuário Iniciante errá-lo, detona com o linux já instalado no HDD dele.

[11] Comentário enviado por vinipsmaker em 17/03/2014 - 19:19h

@albfneto, vê esse ascii cast mostrando um container sendo iniciado através do LXC: https://asciinema.org/a/7831

Como o namespace de PIDs é diferente, você pode dá init no ambiente convidado, um recurso bem poderoso.

E indo para o lado fácil, tem o systemd-nspawn, que é uma ferramenta interessante para iniciantes: https://asciinema.org/a/2734

[12] Comentário enviado por vinipsmaker em 19/03/2014 - 13:24h

Outro UPDATE: Próxima versão do OpenSUSE vai usar o Btrfs por padrão: http://www.phoronix.com/scan.php?page=news_item&px=MTYzNjA

[13] Comentário enviado por Fabio_Farias em 19/03/2014 - 16:20h


[12] Comentário enviado por vinipsmaker em 19/03/2014 - 13:24h:

Outro UPDATE: Próxima versão do OpenSUSE vai usar o Btrfs por padrão: http://www.phoronix.com/scan.php?page=news_item&px=MTYzNjA


Interessante notícia. Estou usando o Btrfs desde a versão 12.3 e o mesmo se apresenta bem estável, suportando quedas de energia e desligamentos incorretos. No início apresentava-se um pouco lento em relação ao Ext4. No entanto , agora o desempenho é bom. E desde a versão 12.3 eu o uso sem a necessidade do diretório /boot ficar em partição separada formatada em Ext4.

No SuSE Linux Enterprise Server e Desktop ele já é padrão desde o ultimo lançamento desses sistemas. Aposta da Novell que pulou do Ext3 direto para o Btrfs como padrão de sistema de arquivos. O Ext4 aparece como opção mas o Btrfs é padrão nesses sistemas.

Mas a próxima versão do openSUSE só sairá em Novembro deste ano, ou seja, ainda demorará um pouco mas é perfeitamente possível usar o Btrfs desde já.




[14] Comentário enviado por Fabio_Farias em 19/03/2014 - 16:30h

Olha aí mais novidades no openSUSE: https://news.opensuse.org/2014/03/19/development-for-13-2-kicks-off/

[15] Comentário enviado por vinipsmaker em 05/06/2014 - 17:21h


[7] Comentário enviado por Fabio_Farias em 23/02/2014 - 09:36h:

O pouco que sei sobre esses sistemas de arquivos obtive a partir desse link: http://www.ibm.com/developerworks/br/linux/library/l-nilfs-exofs/



@Fabio_Farias:

Terminei de ler agora o link. Não entra muito em detalhes de qualquer coisa, mas é legal que dá uma boa visão de médio nível, e tem umas referências externas para quem quiser ver a fundo.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts