{"id":38908,"date":"2019-10-31T22:26:41","date_gmt":"2019-10-31T19:26:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/budushhee-uzhe-zdes-ili-kodim-pryamo-v-brauzere\/"},"modified":"2019-10-31T22:26:41","modified_gmt":"2019-10-31T19:26:41","slug":"budushhee-uzhe-zdes-ili-kodim-pryamo-v-brauzere","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/budushhee-uzhe-zdes-ili-kodim-pryamo-v-brauzere","title":{"rendered":"O futuro j\u00e1 chegou ou estamos programando direto no navegador","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vou contar sobre uma situa\u00e7\u00e3o curiosa que aconteceu comigo e sobre como se tornar um contribuinte em um projeto conhecido.
\n<\/a><\/noindex>
\nN\u00e3o faz muito tempo que estive envolvido com uma ideia: carregar o Linux diretamente do UEFI...
\nA ideia n\u00e3o \u00e9 nova e h\u00e1 uma quantidade consider\u00e1vel de manuais sobre esse tema. Um deles pode ser consultado aqui<\/a><\/noindex><\/p>\n

Na verdade, minhas antigas tentativas de resolver essa quest\u00e3o resultaram em um projeto bem estruturado uma solu\u00e7\u00e3o<\/a><\/noindex>. A solu\u00e7\u00e3o \u00e9 totalmente funcional e eu a utilizo em parte das minhas m\u00e1quinas dom\u00e9sticas. Um pouco mais detalhadamente, essa solu\u00e7\u00e3o est\u00e1 descrita aqui<\/a><\/noindex>.<\/p>\n

A ess\u00eancia do UEFI-Boot \u00e9 que a ESP (Parti\u00e7\u00e3o de Sistema EFI) se combina com o diret\u00f3rio \/boot. Ou seja, todos os n\u00facleos e as imagens de inicializa\u00e7\u00e3o (initrd) s\u00e3o colocados na mesma parti\u00e7\u00e3o a partir da qual o UEFI pode executar arquivos execut\u00e1veis e, em particular, iniciar gerenciadores de inicializa\u00e7\u00e3o do sistema. Por\u00e9m, o pr\u00f3prio n\u00facleo do Linux j\u00e1 \u00e9 compilado com a op\u00e7\u00e3o UEFISTUB em muitas distribui\u00e7\u00f5es, o que permite que o pr\u00f3prio n\u00facleo inicie a partir do UEFI.<\/p>\n

H\u00e1 um inconveniente nessa solu\u00e7\u00e3o \u2014 a parti\u00e7\u00e3o ESP \u00e9 formatada em FAT32, onde n\u00e3o \u00e9 poss\u00edvel criar links duros (que o sistema cria regularmente ao atualizar o initrd). E n\u00e3o h\u00e1 nada de particularmente criminoso nisso, mas receber avisos do sistema durante a atualiza\u00e7\u00e3o dos componentes do n\u00facleo n\u00e3o \u00e9 muito agrad\u00e1vel...<\/p>\n

H\u00e1 outro caminho. <\/p>\n

O gerenciador de inicializa\u00e7\u00e3o UEFI (aquele onde \u00e9 necess\u00e1rio adicionar o carregador do sistema operacional) consegue, al\u00e9m de carregadores\/n\u00facleos Linux, carregar tamb\u00e9m drivers. Portanto, voc\u00ea pode carregar o driver do sistema de arquivos onde est\u00e1 seu \/boot e carregar o n\u00facleo diretamente a partir da\u00ed usando o UEFI. O driver, naturalmente, deve ser colocado na parti\u00e7\u00e3o ESP. Isso \u00e9 aproximadamente o que fazem gerenciadores como o GRUB. Mas a sacada \u00e9 que todas as fun\u00e7\u00f5es frequentemente usadas do GRUB j\u00e1 est\u00e3o no UEFI. Ou melhor, em seu gerenciador de inicializa\u00e7\u00e3o. E se quisermos ser mais detalhistas, o gerenciador de inicializa\u00e7\u00e3o UEFI tem at\u00e9 mais recursos em certas quest\u00f5es. <\/p>\n

Parece ser uma solu\u00e7\u00e3o bonita, mas h\u00e1 um \"MAS\" (ou melhor, havia, mas falarei sobre isso depois). O fato \u00e9 que o sistema de drivers UEFI \u00e9 relativamente simples. N\u00e3o existe um conceito de montagem de sistema de arquivos ou de vincula\u00e7\u00e3o de driver a um dispositivo espec\u00edfico. H\u00e1 uma chamada de sistema com um nome condicional Map (em ingl\u00eas) que pega cada driver em ordem e tenta vincul\u00e1-lo a todos os dispositivos que, de alguma forma, se encaixam. E se o driver conseguir se conectar ao dispositivo, ent\u00e3o \u00e9 criado um mapeamento \u2014 uma entrada de liga\u00e7\u00e3o. Assim, na confus\u00e3o com todos os outros, o novo driver deve ser inicializado. E tudo o que \u00e9 necess\u00e1rio \u2014 na entrada de inicializa\u00e7\u00e3o do driver, configurar um bit (LOAD_OPTION_FORCE_RECONNECT) como 1 e o UEFI far\u00e1 esse remapeamento global ap\u00f3s o carregamento.<\/p>\n

S\u00f3 que fazer isso n\u00e3o \u00e9 t\u00e3o simples. A ferramenta padr\u00e3o efibootmgr (com a qual se configura o gerenciador de inicializa\u00e7\u00e3o UEFI) n\u00e3o sabe (ou melhor, n\u00e3o sabia) como configurar esse bit. Era necess\u00e1rio configur\u00e1-lo manualmente atrav\u00e9s de um procedimento bastante complexo e perigoso. <\/p>\n

E mais uma vez, ao tentar fazer isso manualmente, n\u00e3o aguentei e criei uma issue no GitHub<\/a><\/noindex> pedindo aos desenvolvedores que adicionassem essa funcionalidade.<\/p>\n

Se passaram alguns dias, mas ningu\u00e9m prestou aten\u00e7\u00e3o ao meu pedido. E, por curiosidade, fui dar uma olhada no c\u00f3digo-fonte... forklei, e pensei em como adicionar esse recurso \"na unha\"... \"Na unha\" porque n\u00e3o utilizei nada espec\u00edfico e editei o c\u00f3digo-fonte direto no navegador.<\/p>\n

Eu conhe\u00e7o C (a linguagem de programa\u00e7\u00e3o) de maneira muito superficial, mas rascunhei uma solu\u00e7\u00e3o (principalmente copiando e colando)... e ent\u00e3o pensei \u2014 e mesmo que haja uma por\u00e7\u00e3o de erros (minhas tentativas anteriores de corrigir o c\u00f3digo C de outra pessoa s\u00f3 compilavam na d\u00e9cima tentativa) vou criar um Pull Request. E assim, fiz isso.<\/a><\/noindex>.<\/p>\n

E ao fazer isso, descobri que havia um Travis CI implementado para verificar os pull requests. E ele me informou todos os meus erros. Bem, se os erros s\u00e3o conhecidos \u2014 por que n\u00e3o corrigir: novamente direto no navegador, e na quarta tentativa o c\u00f3digo foi compilado (um feito para mim).<\/p>\n

E assim, sem sair do navegador, criei um Pull Request totalmente real para uma ferramenta que \u00e9 usada praticamente em todas as distribui\u00e7\u00f5es modernas do Linux.<\/p>\n

Fiquei surpreso ao perceber que, sem conhecer a l\u00edngua e sem configurar nada (s\u00e3o necess\u00e1rias v\u00e1rias bibliotecas para a compila\u00e7\u00e3o), e sem nunca ter executado o compilador, consegui \"programar\" uma funcionalidade \u00fatil e funcional diretamente no navegador.<\/p>\n

No entanto, meu pedido ficou sem resposta desde 19 de mar\u00e7o de 2019, e eu j\u00e1 havia come\u00e7ado a esquec\u00ea-lo. <\/p>\n

Mas ontem, esse pedido foi adicionado ao master. <\/p>\n

\nSobre o que trata minha hist\u00f3ria? Trata-se do fato de que, com as tecnologias atuais, j\u00e1 \u00e9 poss\u00edvel escrever c\u00f3digo real no navegador, sem precisar instalar ferramentas de desenvolvimento e depend\u00eancias localmente.<\/p>\n

Vale a pena mencionar que este \u00e9 meu segundo pull request em utilit\u00e1rios conhecidos (pelo menos em c\u00edrculos restritos). Da \u00faltima vez, meu pedido para corrigir a exibi\u00e7\u00e3o de alguns campos na interface web do SyncThing resultou em uma corre\u00e7\u00e3o de apenas uma linha em um ambiente que eu n\u00e3o conhecia.<\/p>\n

Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

Devo continuar escrevendo ou n\u00e3o?<\/h2>\n