o Unix é um fascinante sistema operacional. Originalmente concebido no Bell Labs no final dos anos 1960, foi suportado pela frustração com o sistema operacional conhecido como “Multics” (multiplexed information and computing service). O Unix já tem mais de 50 anos (!) and the Linux implementation powers huge swathes of the Internet.
So-why is Unix so popular?
In my mind, Unix’s success comes from the philosophical approach to development. A filosofia UNIX é documentada por Doug McIlroy no Bell System Technical Journal in 1978:
1. Fazer cada programa fazer uma coisa bem. Para fazer um novo trabalho, construir de novo, em vez de complicar programas antigos, adicionando novos “recursos”.
2. Espere que a saída de cada programa se torne a entrada para outro, ainda desconhecido, programa. Não confunda informações estranhas. Evite os formatos stringentemente colunares ou binários de entrada. Não insista na entrada interativa.
3. Projetar e construir software, até mesmo sistemas operacionais, para ser experimentado cedo, idealmente dentro de semanas. Não hesite em deitar fora as partes desajeitadas e reconstruí-las.
4. Use ferramentas em preferência a ajuda não especializada para aliviar uma tarefa de programação, mesmo se você tem que desviar para construir as ferramentas e esperar jogar alguns deles para fora depois de terminar de usá-los.
isto foi há mais de 40 anos, e captura sólidos( princípio de responsabilidade única, aberto / fechado), microservícios, condutas funcionais, ágeis e o espírito dos DevOps!
para mais detalhes sobre a filosofia Unix, leia este livro (disponível gratuitamente aqui, mas compre uma cópia para apoiar o autor!).
vejamos alguns exemplos da filosofia Unix em ação.
faça cada programa fazer uma coisa bem. Para fazer um novo trabalho, construir de novo, em vez de complicar programas antigos, adicionando novos “recursos”.
cat faz exactamente uma coisa. Ele combina arquivos e exibe-os na saída padrão. É tudo o que faz. Não faz paginação. Não oferece funcionalidade de pesquisa. Faz exactamente o que diz na lata e nada mais.
tr é semelhante. Ele faz “substituição textual” pela leitura de entrada, fazendo quaisquer traduções e escrita para saída.
tr -d aeiouAEIOU < file # Display file without vowels
tr eao 340 < file # Partially leet speak file
true e false são talvez os melhores exemplos de fazer uma coisa bem. true não faz nada, com sucesso! Não faz nada.
false && echo Hi # does nothing
true && echi Hi # Prints Hi
composição
“espere que a saída de cada programa se torne a entrada para outro”
em Unix, a maioria das operações tem a capacidade de ler e escrever para a saída padrão em um formato textual bem entendido. Com alguns comandos, como |, > e < podemos alimentar a saída de um programa para outro. Vejamos alguns exemplos:
neste exemplo, nós usamos cat para a saída do conteúdo de um arquivo e alimentar a saída em wc quem pode contar o número de linhas em um arquivo.
cat foo.txt | wc -l
neste exemplo, usamos history para encontrar os nossos comandos mais frequentemente utilizados, combinando-os com cut, sort, uniq and head.
history | cut -f5 -d" " | sort -rn | uniq -c | sort -rn | head
xargs é o derradeiro canivete suíço que lhe permite construir comandos a partir da saída padrão. Vamos usá-lo para apagar tudo “.ficheiros tmp” no directório actual, depois de usar find para os localizar.
find -type f *.tmp | xargs rm
tudo é um ficheiro
no UNIX tudo é um ficheiro (ou mais precisamente, tudo é um fluxo de bytes). Isto significa que as mesmas APIs/comandos podem ser usados para ler uma unidade de CD-ROM, gravar um ‘socket’ de rede ou descobrir informações de CPU.
por exemplo, todo o sistema de arquivos /proc no Linux não é realmente arquivos — é uma visão dinâmica da informação que é exposta como um monte de descritores de arquivos.Alguns exemplos:
cat /proc/cpuinfo # Displays your CPU info exposed as a filefoo > /dev/null # Redirect output into a file called
# null (which discards everything)od -vAn -N1 -td1 < /dev/urandom # Display a random 1 byte number
# (via https://unix.stackexchange.com/a/268960
Automação
muito antes de “automatizar-todas-as-coisas”, Unix estava lá, errr, automatizando todas as coisas
cron (mais aqui) foi automatizar todas as coisas para a última com mais de 40 anos. As tarefas Cron são scripts programados que podem ser executados em horários fixos ou em intervalos fixos.
cada usuário em um sistema Unix tem um conjunto de tarefas agendadas, visíveis usando o comando crontab. O arquivo está em um formato muito simples que dá a data e hora do script que corre.
o comando at é uma alternativa mais amigável, aqui está um exemplo de disparar um comando a 1145 em 31 de Janeiro (a partir daqui).
echo "cc -o foo foo.c" | at 1145 jan 31
Puppet, Chef, CFEngine, an possible-todas estas ferramentas DevOps e nascido e criado em sistemas baseados no Unix.