Mostrando postagens com marcador daemons. Mostrar todas as postagens
Mostrando postagens com marcador daemons. Mostrar todas as postagens

airyxOS: Um clone do macOS?

airyxOS: Um clone do macOS?

airyxOS: Um clone do macOS?

 Na Segunda Feira eu fiz uma live tratando de um suposto clone do MacOSX que recebeu o nome de airyxOS. Então nesta live tratamos o que esse sistema operacional realmente é, sua proposta, seu design como modelo de kernel, sistemas de arquivos que possui suporte, init system utilizado pelo sistema, GUI, como rodará as aplicações do MacOSX, arquitecturas que possui suporte, se está funcionando e muito mais. Valeu a pena fazer esta live.




Wayland receberá proxy transparente para as suas aplicações

Wayland receberá proxy transparente para as suas aplicações
Wayland receberá proxy transparente para as suas aplicações
 No Google Summer of Code foi anunciado o desenvolvimento da ferramenta Waypipe, um proxy transparente para as aplicações do Wayland que pode ser utilizada de forma parecida com o ssh-X. Porém, diferente do protocolo X, somente parte dos dados são necessários ser transferidos para exibir uma aplicação ao invés de todo o montante de dados.

curso-linux-da-migração-a-administração-do-sistema-operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Ainda há trabalhos sendo realizados como correção de bugs, limpeza de código, adição de melhor suporte ao procolo e tentativa de implementar novos recursos. Esse novo recurso promete evitar que erros que ocorrem no X11 (como quando o ssh tunel quebrar, o Waypipe pausa o conexão do serviço no compositor Wayland até que um novo transporte seja fornecido). Para jogos online é uma boa ideia utilizar o Waypipe em compressão de vídeo para tornar o processo mais rápido (podendo até dobrar a quantidade de FPS e reduzir o uso de banda).


 Além de jogos, foram testados os programas Alacritty (com winit), kitty (com GLFW), Termite (com GTK3), weston-terminal (GTK3), Konsole (com Qt5) Firefox (a maior parte do GTK3 e que está recebendo correções de bugs devido uma quebra), SuperTux (com SDL2), SuperTuxKart (sem toolkit) e o VLC (a maior parte em Qt5 e que deu uma quebrada ao commitar um xdg_surface).

Todos os detalhes do Waypipe podem ser conferidos clicando aqui.
https://mstoeckl.com/notes/gsoc/blog.html
https://lists.freedesktop.org/archives/wayland-devel/2019-June/040687.html
https://gitlab.freedesktop.org/mstoeckl/waypipe/

Lançado Weston 6.0.91

Lançado Weston 6.0.91
Lançado Weston 6.0.91
 Weston é uma ferramenta que faz parte do Wayland que permite a execução como cliente X ou sob o Linux KMS com alguns demo clients. O Weston é um compositor minimo e rápido adequado para muitos embarcados e móveis.
curso-linux-da-migração-a-administração-do-sistema-operacional
CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.
 Esse é um lançamento alfa do weston 7.0 que traz vários novos o recursos e correções como escopos de debugs internos e framework de logs; melhorias na documentação, suporte a HDCP e  novo plugin PipeWire. Foram o total de 201 mudanças que podem ser conferidas logo abaixo:
Link para a versão 6.0.91.


A tragédia do systemd

systemd
systemd comentado por Beno Rice do FreeBSD
 O systemd já causa discórdia entre desenvolvedores, projetos, profissionais e usuários de Linux ( e sem necessidade, diga-se de passagem). Agora, vamos tratar desse init system de acordo com a visão de um desenvolvedor do FreeBSD. E que comecem os rumores.



CURSO DE SHELL SCRIPT DO MATEUS MÜLLER
Foi uma live muito boa onde debatemos a sua origem, de onde foi inspirado, fatos históricos, vantagens e desvantagens e o erro cometido tanto pela comunidade Linux quanto a comunidade FreeBSD.


 Mas essa não é a primeira vez que debato sobre o systemd e init systems tanto no canal e no blog. Confiram também os artigos abaixo:

Bug no systemd de novo?

Bug no systemd
Algo errado não está certo. Deu uma falha no engano.
 Bom, encontrados três bugs no systemd-journald que permitem até mesmo escalar privilégio de usuário administrador, alvoroço é o que não faltou entre a galera.


 Como as distribuições Fedora 28-29, SUSE Linux Enterprise e OpenSUSE não foram afetadas pelos dois primeiros bugs por terem compilado o systemd utilizando a opção -fstack-clash-protection do GCC e o terceiro bug já havia sido corrigido em 2018, no o vídeo (que eu gravei no 15 de Janeiro de madrugada) eu já previa que todas as outras distribuições iriam aplicar a mesma técnica para sanar os problemas.

 Dito e feito. No dia 15 de Janeiro de 2019, já começaram a ser lançadas novas atualizações do systemd e há previsões para mais.

Disponível utmps-0.0.2.0


 Está disponível a versão 0.0.2.0 do utmps. utmps é uma implementação segura de conta de usuário, utilizando uma daemon como única autoridade para gerenciar os dados utmp e wtmp data; programas rodando funções utmp são apenas clientes para essa daemon.

 Essa versão trás uma importante correção de bug no utmps-wtmpd, bem como um novo recurso no utmps-utmpd (membros do grupo utmp podem agora escrever no arquivo utmp, como oposto a somente o root).
 O utmps está sob licença ISC, que é uma espécie de BSD. Baixem e confiram. Bug-reports são sempre bem vindos pela comunidade.

Thunderbolt - a nova interface de conexão de periféricos do Linux

USB Type-C connector on a Thunderbolt 3 cable
Conector USB Tiype C em um cabo Thunderbolt 3
Thunderbolt é a nova interface que irá realização conexão de periféricos no Linux e que é desenvolvida pela Intel. Essa nova interface permitirá que o dispositivo tenha acesso direto a DMA sem a necessidade da intervenção do sistema operacional ou até mesmo do processador. Isso faz com que seu acesso seja mais rápido e ofereça mais segurança ao sistema.
Logo do Thunderbolt
Logo do Thunderbolt
Isso ocorre adotando um esquema (a partir da 3ª versão) de 5 níveis diferentes que é configurado pelo firmware do sistema:
  1. none: Segurança desabilitada, todos os dispositivos funcionarão completamente na conexão.
  2. dponly: Passará somente a display-port stream pelo dispositivo conectado.
  3. user: O dispositivo conectado precisa ser manualmente autorizado pelo usuário.
  4. secure: Como 'user', mas em conjunto com uma chave secreta para verificar sua identidade.
  5. usbonly: Um túnel PCIe é criado para uma controladora USB em um thunderbolt dock; nenhum outro túnel downstream PCIe é autorizado (requer o kernel 4.17 em diante e hardware mais recente).
Apesar de mencionado o kernel 4.17 em diante, O Thunderbolt faz uso da interface do sysfs que foi introduzido no kernel 4.13 adicionando mais segurança ao userspace (além de vários outros recursos) e já podíamos ver o Thunderbolto no kernel 4.14.

Pseudo file system sysfs a partir do kernel 4.13 e que é utilizado pelo Thunderbolt
Pseudo file system sysfs a partir do kernel 4.13 e que é utilizado pelo Thunderbolt
Segunda coisa interessante é a adoção do Ninja Build para compilá-lo ao invés do make (sim, acho muito mais interessante) e que já fez parte aqui do blog e do canal como uma das ferramentas muito além do GNU.

Agora, indo para a parte que a galera mimimi vai chorar. O Thunderbolt será (digamos) parte integrante do systemd (que comece o choro já que é livre). O núcleo do Thunderbolt é o boltd e utilizaremos o comando boltctl para controlá-lo:
Comando boltctl como front end da daemon boltd do Thunderbolt.
Comando boltctl como front end da daemon boltd do Thunderbolt.

Lançado s6 2.7.2.0, s6-portable-utils-2.2.1.2 e s6-linux-utils-2.5.0.0

Você deve estar se perguntando o que é s6 (pronuncia-se ssix) afinal de contas? Como mencionei no ultimo vídeo que existem vários, mas VÁRIOS init systems, s6 é um deles e que inclusive não mencionei no vídeo.

s6 é desenvolvido pela skarnet com o intuito de prover um conjunto independente de diferentes ferramentas para Unixes (tal como Linux) que podem ser utilizada com ou sem framework, e que podem ser agrupadas para atingir funcionalidade poderosa com um monte pequeno de código. Existe a versão específica para Linux chamada s6-linux-init e essa não é a unica ferramenta fornecida pela Skarnet, mas focando no assunto (que é init system), no mesmo vídeo eu menciono mais algumas que estão disponíveis para Linux (e convenhamos, esse Neymar só não é mais feio por falta de espaço)


Essa semana foi lançada a versão 7.2.0 do s6 (que mantes comparatibilidade com a versão 2.7.0.0 da skalibs), a versão 2.2.1.2 do s6-portable-utils e a versão 2.5.0.0 do s6-linux-utils. Honestamente não tenho interesse em debater o que há de novo nos novos lançamento, mas eles podem ser conferidos nos links abaixo:

Phoronix mente a respeito do systemd possuir um milhão de linhas de código?


No dia 02/01/2017 o site Phoronix publicou que o systemd VIOLOU o total um milhão de linhas de código. SIM! escreveu VIOLOU (BREACHED) e não OBTEVE ou ALCANÇOU (REACHED). Ok,pode ter sido somente um erro de digitação.

systemd é um init system que foi desenvolvido inicialmente por Lennart para substituir a mais conhecida SystemV e hoje conta com uma boa equipe envolvendo comunidades como Debian, Arch Linux entre outras.

Para saber mais sobre o que é init system, confiram o vídeo abaixo:


Neste artigo descreve a quantidade de commits no git, que foi o ponto mais baixo desde 2012 e no final disponibilizam um link (só que do próprio Phoronix) com mais detalhes de estatísticas de código (apesar de eu gostar do Phoronix, odeio quando os sites fazem isso).

Lennart respondeu comentando em seu perfil pessoal no G+ (OK, eu não vou disponibilizar o perfil do cara porque muitos o atacam) respondendo aos detalhes:
Uh, então Phoronix está sendo Phoronix, e reporta noticia bastante enganosa. Deixe-me colocar rapidamente algumas coisas diretas: antes de tudo, "um milhão de linhas de código" é realmente enganoso, assim como aparentam ser brutas de aquivos gerenciados pelo git. Desde que nós carregamos grande montante de documentações as linhas de código vigentes são muito menores. utilizar uma ferramenta como "sloccount" para contagem de linhas de código revela que o systemd atualmente carrega ~342K linhas de código, das quais 318K são apropriados códigos C. Que na verdade não é tanto assim. Para colocar as coisas em perspectiva, como um exemplo o wpa_supplicant sozinho possui ~451K de linhas de código, das quais ~351K são apropriados código C. Acho que desde que a supostamente enorme arvore do systemd com todos os seus componentes, tais quais resolved, networkd, timesyncd, nspawn, journald, e assim por diante sozinho atinge 75% do tamanho da base de código de você $#$#%$ o subsystem wifi, eu acho que nós estamos bem, você não?
Quero dizer, com certeza, maçãs, laranjas e coisas, mas ainda…
(e sim, mesmo coisas tais quais projetos supostamente "inclinarem-se" como a uclibc pesarem 329K de linhas de código já…)
Viram como transmitir informações reais é uma responsabilidade muito grande? Sempre se questionem e corram atras para certificarem das informações. O link para o artigo está logo abaixo:

Resumo do Tux 24/09/2016




Beleza cambada? Bora para mais um resumo do Tux desta semana?

 Domingo eu disponibilizei o vídeo sobre LPI por se tratar de uma certificação muito importante para nós.



Terça feira pela manhã eu postei o artigo no blog Resenha nerd sobre o trailer do filme russo Guardians que espero com ansiedade (pena que é somente para fevereiro do ano que vem e nem sei se virá para o Brasil).  Criei um blog de assuntos nerds, que são coisas que eu gosto, mas como mencionei no vídeo "Falar de BSD? É... Por hora não." pretendi deixar separado para não misturar as coisas. Quando tiver um assunto de coisas nerds, deixarei por lá. Beleza?
E a noite postei o vídeo "O que são runlevels?" conforme mencionei que iria tratar em um vídeo aparte:


 E bom, essa semana foi somente isso. Eu espero que tenham gostado =)

O que são runlevels?

O-que-sao-runlvels
O que são runlvels?
Beleza cambada?
Para quem ainda não assistiu, ontem eu postei um vídeo ensinando sobre o que são runlevels que, conforme havia mencionado no vídeo "O que é daemon init?",  iria tratar em um vídeo aparte para que servem, como conferi-los e como utilizá-los.


 O interessante foi ver nos comentários do pessoal que até mesmo nisso, as distribuições se diferem tanto na forma quando constroem o uso de runlevel quando qual o runlevel iniciam. Algumas inicam no 2, outras no 5 e assim elas se diferenciam até mesmo em qual runlevel elas iniciam e utilizam como padrão.
Bem conforme mencionei no vídeo "Não viva de boatos (quebra de paradigmas - 2ª parte: Linux vs BSD)" em que é difícil afirmar Linux como se fosse de uma forma geral, como se todas as distribuições fossem iguais.

Daemons, daemons e mais daemons (init)

Daemons, daemons e mais daemons (init)

Daemons, daemons e mais daemons (init).


    No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init (ou init systems) diferentes disponíveis. porém mencionei somente as (digamos) mais populares como a BSD, SystemV (ou simplesmente sysvinit que introduziu o conceito de runlevels (especificação declarativa de serviço de sistema). O holandês Miquel van Smoorenburg é o autor da versão do sysvinit para Linux. Miquel fez também o primeiro port Debian para a arquitetura Alpha e tem como simbolo um Tux bebinho de tudo).

Tux de Miguel Van Smoorenburg

O launchd do Mac OS X, o OpenRC originado no Gentoo, o Upstart originado no Ubuntu e o systemd originado no Fedora. O vídeo pode ser conferido logo abaixo:


    Então por que não debater sobre outros init systems diferentes? Vale começar pelo NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da SystemV.

    O Solaris possui o SMF (Service Management Facility = Facilidade de Gerenciamento de Serviço que também é baseada na SysVinit). Eu não sei hoje, talvez esse não seja mais o init do Solaris, mas ele é fortemente utilizado no IllumOS e no OpenIndiana. Agora, vamos a mais um monte de outros init systems.
    É um init system alternativo que incorpora as ideias da sysVinit, do simpleinit, do daemontools e do make que visa cuidar de processo paralelo (assim como o systemd e o launchd), dependências, roll-back, pipelines, melhorias no signaling e desmontar filesystems no desligamento (assim como o systemd possui recurso parecido). Falando em desmontar no desligamento, no dia 20 de agosto foi adicionado ao Systemd a ferramenta para montar filesystems. O interessante é que o Depinit possui comando parecido com o systemctl do systemd chamado depinctl. O Depinit, está sob licença GPLv2 e ainda está em fase experimental sendo disponível para Linux e FreeBSD. Sua ultima versão foi lançada em maio de 2014 (a versão 0.1.4).

InitNG 

    Tem como objetivo iniciar os processos em paralelo para reduzir o tempo de boot (assim como o systemd e o launchd... Mas já foi dito isso). Algo que foi inspirado no Mac OS X Tiger. Nele tudo é chamado em uma única ferramenta para gerenciar ciclo de vida ao invés de chamar múltiplos scripts que duplicam comportamentos similares. Li a algum tempo atras que a daemon InitNG tornou o Linux mais rápido (notaram como até mesmo a daemon init ou as outras daemons influenciam no desempenho do sistema operacional e não somente um filesystem? O InitNG está sob licença GPLv3 e recebeu uma pequena atualização há dois anos.

Runit 

    É um init Unix de esquema Cross-platform com supervisão de serviço operando em três estágios obtidos em /etc/runit. Ela está disponível para Linux, FreeBSD, Mac OS X e Solaris e pode ser facilmente adaptada para outros Unixes. Os direitos autorais são reservados ao desenvolvedor da daemon. Hoje essa daemon é adotada pela distribuição Void Linux e tendo também suporte do Busybox.


eINIT 

    É uma alternativa a implementação do /sbin/init para Linux e FreeBSD, mas parece que anda em decadência. Apesar disso, é um bom init para dispositivos embarcados e é bem modular. possui runlevels nomeados modes que é descrito em um arquivo XML a parece-se um pouco com a runlevel do Gentoo.

Pardus 

    É a daemon init da distribuição Turka chamada Pardus. É uma versão paga do Linux pelo que me lembro de ter visto anos atrás. É difícil conseguir informações nesse site desde que não possui versão inglesa (parece que os caras não querem mais nenhum outro país por lá rsrs. Essa seria uma boa distribuição para entrar para os "50 lugares onde Linux está rodando e você nem faz ideia), mas essa init trabalha com um subsistema init chamada Mudur que é escrito em python e um sistema de gerenciamento de configuração chamado Çomar.

Epcoh 

    É um init system para Linux na versão do kernel 2.6. Foi projetado tendo como foco a facilidade na configuração e a não intromissão, ser pequeno para funcionar tanto em distribuições grandes e minimas. Esse init não possui dependências externas além da biblioteca C, dos pthreads do kernel e sugerido um /bin/sh funcional. Ele possui um sistema de logs para boot, runlevels em ASCII, um único arquivo de configuração conveniente; recursos automáticos como hostname e montagem do sistema de arquivos virtual (como o /proc) e vários outros recursos. Vale a pena conhecer esse init system:

minit

    É uma daemon (ainda em versão beta) feita pelo alemão Felix von Leitner, mesmo criador da dietlibc e do embutils. Além de visar ser minuscula (característica típica do Felix e que faz isso muito bem) também visa corrigir alguns erros cometidos pelos init systems tradicionais no Linux. Se quiser saber mais sobre a diet libc e do embutils, assista o vídeo abaixo:


 
Como descrito  no documento de sua palestra na Linux Kongress de 2004 que:
  • O processo de boot das tipicas distribuições Linux é muito sofrido
  • Se um boot script falhar, todo o processo de boot é interrompido
  • Se um serviço for interrompido via o comando kill, ele não é automaticamente reiniciado (se tornando um processo zumbi)
  • O script de shutdown não sabe qual o PID da daemon (modos de falhas horriveis onde você acidentalmente mata o processo errado)
  • E a falta de flexibilidade (iniciar mais um ou um serviço a menos?).
 No minit, cada serviço possui seu próprio diretório dentro de /etc/minit contendo dependências e dentre outros recursos. Dentre os problemas a serem solucionados pelo minit estava o de reduzir o período de downtime (que é também uma das ideias do systemd).

sinit (11/05/2022)

 sinit (suckless_init) é um init system baseado no minimal init (clique aqui para conferir) criado por Rich Felker (criador da bliblioteca Musl muito abordada aqui no blog). Foi criado com a intenção de integra-la ao Busybox em um experimento (confira aqui). O sinit está sob a MIT/X Consortium License e existe um manual introdutório ao sinit que pode ser conferido aqui.

jinit

    também desenvolvida na Alemanha, trabalha utilizando seu próprio filesystem baseado em esquema de serviço e é escrita em C++. Ainda não é muito bem testada.

    Existe também por exemplo a Twsinit que é desenvolvido em Assembly, é bem pequena (exige somente coisa de 8k de memória) e ser uma substituição das atuais; a do Fedora chamada FCNewInit a Serel que também foca em acelerar o boot.

    Moral da história é que acelerar o boot, reduzir o shutdown melhorando assim o uptime e solucionar os problemas gerados pelos scripts já é um desejo antigo. A maioria das aqui mencionadas focaram esforços para poder trazer essas soluções. Criticar o systemd então se torna somente uma questão de birra.

    Bom, acho que está bom o tamanho da lista. Vale mencionar (mais uma vez, assim como mencionado no vídeo "O caso Systemd") que do Systemd surgiu o fork UselessD, mas que não conseguiram atingir o seu objetivo proposto.


busybox remove suporte ao Systemd:


Fico por aqui, espero ter agregado  mais conhecimento,forte abraço e falow.

utilizando o comando invoke-rc.d



 Bom dia cambada! E para começar o dia, fica a dica que dei ontem sobre o comando invoke-rc.d. O invoke-rc.d é um comando que eu gosto muito e, com a introdução do systemctl, serve como uma base para facilitar o aprendizado por seguirem quase a mesma lógica. Alias, pelo fato de o systemctl seguir a mesma lógica do invoke-rc.d e do service, eu acabei me adaptando facilmente ao systemctl. Bastou inverter as opções e está tudo certo.

 O invoke-rc.d ainda está presente em muitas distribuições permitindo-lhe operar o sistema através dele, mas eu particularmente já ando operando  através do systemctl para já estar pronto para o futuro (que já está acontecendo).

 Confiram o vídeo abaixo para conhecer o invoke-rc.d:


Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (10) Andriod (15) android (7) artigo (5) aws (1) bc (18) benchmark (5) BSDs (27) btrfs (31) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (26) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (82) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (87) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (21) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (6) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (78) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (102) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (62) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (5) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (149) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (83) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (61) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (12) RISCV (11) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (23) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (84) terminal de comandos (12) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (14) zsh (2)