A Motoko é um conjunto de ferramentas que permitem que você instale, remova, crie e distribua pacotes no seu sistema.
O meu objetivo é oferecer um gerenciador de pacotes que siga, de fato, o modelo de gerenciamento de pacotes SRV4, mas que ao mesmo tempo não seja resultado de turd polishing de código com mais de 20 anos -- no caso, o código das pkgtools originais da Sun que fora liberado junto com o OpenSolaris nas quebradas de 2005.
Além disso, eu quero fazer algo decente do zero assim como quero aprender Go de verdade -- no caso, desde manipulação de texto-puro até manipular arquivos e permissões no file system.
"SVR4" é um acrônimo para "System V, revision 4", que foi uma versão do UNIX lançada em 1987, oriunda de trabalho da AT&T e da Sun Microsystems em conjunto.
Mesmo sendo considerado o "estopim para a insanidade" do UNIX, pelo menos uma coisa positiva ele trouxe que, no caso, foram as melhorias para as pkgtools dos BSDs(carece de fontes exatas), dando origem ao que se conhece como "SVR4 pkgtools".
Estou me baseando em diversos documentos (que podem ser encontrados em docs/references/), mas de todos o que mais está sendo consultado é o "Application Packaging Developer's Guide" da Sun Microsystems, publicado em Fevereiro de 2000 (805-6338.pdf); em segundo lugar vêm as manpages do illumos (illumos.org/man/).
- fidelidade às pkgtools SVR4 originais, inclusive a nível de usabilidade;
- ao mesmo tempo que haja fidelidade, não deve-se haver cumplicidade com erros: ou seja, se algo existir nas pkgtools originais mas que possa ser substituído sem perdas significativas por algo melhor e mais simples, será;
- cortar dependência o máximo possível com o Shell e com ferramentas no
$PATH; - manter a base de código legível e fácil de fazer hacks/manutenção;
mk(plan9port) como build system.
- resolução de dependências;
- download da rede;
- compressão nativa;
- suporte para outras línguas além do inglês em mensagens na tela (isso pode mudar);
Essas coisas devem ficar a cargo de uma abstração, não da Motoko. - links simbólicos.
As pkgtools do Slackware, mesmo sendo incrivelmente boas para algo feito em uma linguagem para meros hacks e estando numa licença extremamente liberal, ainda pecam em vários sentidos ao meu ver.
Um deles é também seu calcanhar de Aquiles, que é sua dependência completa no GNU Bourne-Again Shell, além da ilegibilidade do código por conta de hacks combinada com a simples falta de semancol em algumas partes.
Sobre as pkgtools originais, que a Sun liberou em 2000, simplesmente não vale a pena usar.
Vários recursos foram cortados no port do Heirloom por serem "Solaris only", além da base de código ser realmente antiga, depender do Shell para coisas que poderiam ser feitas direto em C e muito provavelmente conter vários problemas de segurança.
Ah, eu falei do fato de usarem SQL só para armazenarem coisas como a lista de pacotes? Pois então.
É algo não só extremamente antigo, mas também "gordo" (e extremamente difícil de compilar, coisa que se deve agradecer aos hacks feitos pelo Gunnar Ritcher ao invés de se portabilizar de fato; o que não é bem culpa dele, para ser justo).
Mesmo eu não sendo exatamente um bom programador, eu acredito que eu vá conseguir fazer algo mais simples e eficiente usando uma linguagem moderna.
E sobre outras ferramentas de gerenciamento de pacotes consideradas "kiss", eu não acho que são sérias, até porque a maioria surgiu em distribuições edgy/meme -- como por exemplo o Ataraxia Linux, onde tudo parece mais um gigantesco shitpost influenciável do 4chan/Reddit do que uma comunidade séria (o que se bobear é a verdade mesmo).
Então é, eu não confiaria em usar no meu sistema para mês seguinte a comunidade decidir que a piadoca perdeu a graça e apagarem todos os repositórios feito loucos.
No exato momento em que estou escrevendo esse README, ainda ninguém -- afinal, nem está pronto ainda. 🤣
Estou criando-o para o Copacabana Linux, mas meu objetivo é que qualquer um possa usar.
Talvez até mesmo o pessoal do Musl LFS, que ainda está preso às pkgtools do Slackware levemente modificadas, acabe utilizando -- e eu ficaria extremamente feliz se o fizessem. 😃
Talvez quem me acompanhe há mais tempo, no caso desde final de 2019 e início de 2020, se pergunte sobre o Otto/otto-pkg.
Eu sinceramente desisti de fazê-lo no estado atual, está simplesmente impraticável -- e se você ficou aguando o meu chope com "brincadeiras" e está lendo isso, eu lhe dou os parabéns por ter conseguido o que queria; agora você pode tentar arrumar um emprego decente e sair da casa da sua mamãe.
Ao longo dos meses em que tentei fazê-lo, em Shell, eu cometi vários erros.
Entre eles, além da influenciabilidade e de usar uma linguagem inflexível para 90% do que eu queria fazer originalmente, foi a falta de planejamento.
Não se tinha uma ideia de fato estabelecida, ia-se adicionando o que "caia na telha" e acabou que... tem-se tudo, menos o principal; além de conflitos muitas vezes desnecessários entre eu e o Caio Yoshimura (segundo desenvolvedor) por pura imaturidade e falta de semancol de ambas as partes.
Ao menos, no meio disso tudo, o Otto em Shell deixou heranças -- que não são crédito unicamente meu.
Entre essas heranças, posso citar o client de torrent pico-torrent, criado pelo Jazz_Man, um hacker e velho amigo meu que não vejo há quase um ano.
Outra seriam as bibliotecas para scripts em Shell, entre elas a posix-alt.shi, que foi criada por mim e pelo Caio na época em que "caímos no meme" do POSIX.
E, por último e mais importante, o aprendizado.
Não, mas nem por um decreto.
O Otto nunca deveria ter sido pensado para ser um gerenciador de pacotes completo, mas sim como uma abstração para algo menor.
Esta é a filosofia UNIX e esta deve ser seguida de verdade para não acontecer novamente o que aconteceu com o Otto escrito em Shell Script.
O Otto em Shell? Este sim morreu, mas deixou herança.
O Otto enquanto ideia? Vivo, tão vivo como nunca.
Irei reescrevê-lo? Sim, mas não tão cedo.
Recentemente estive conversando com meu amigo Vitor Almeida, que mantém o website do projeto, e chegamos à conclusão de que precisamos manter um padrão no projeto em si.
Decidi pôr a Motoko dentro desses padrões para não acontecer o que acontecia constantemente no Otto e em projetos amadores, que é um programador atropelar o outro, commits se perderem etc.
Essa parte possivelmente vai ser bem dividida numa documentação posteriormente, mas por hora vou deixar no README.
Especificação Conventional Commits 1.0.0:
https://www.conventionalcommits.org/pt-br/v1.0.0/
- acme/acme2k (9fans.github.io/plan9port);
- Vi Improved (vim.org).
Possivelmente...
Nota [1]: estarei escrevendo o README primariamente em português, minha língua nativa, para posteriormente traduzir para inglês. Por eu não ter começado a escrever o projeto ainda, eu preciso ter o maior fluxo criativo possível, então por hora vai ficar em "tuga" mesmo.
Nota [2]: a única afiliação entre mim, os estúdios Xebec e Ken Akamatsu é que sou um grande fã de suas obras. E a única forma que eu encontrei para mostrar minha gratidão foi nomear um de meus projetos com o mesmo nome de uma das personagens de sua comédia romântica Love Hina.