O que os desenvolvedores devem saber sobre sistemas baseados em UNIX?


8

Estou um pouco surpreso que isso ainda não tenha sido perguntado por ninguém, mas em um nível alto, o que todo desenvolvedor deve saber sobre como trabalhar com sistemas baseados em UNIX?

Minha experiência * nix é muito limitada, porque não tenho absolutamente nenhuma razão para usá-la no Windows para meus próprios fins, mas tenho duas entrevistas em que as empresas idealmente querem alguém com experiência * nix. Não tenho problemas em familiarizá-lo se eles fizerem uma oferta que eu quero aceitar, mas não vale a pena o investimento quando a maioria das minhas ofertas trata de sistemas Windows; espero que isso seja compreensível.

Quais ferramentas devo conhecer? Alguma peculiaridade que eu deveria estar ciente? Existem recursos bons e concisos que podem ser lidos rapidamente para obter um entendimento amplo?


Que tipo de desenvolvimento você está fazendo? Para programação de alto nível, conhecer os comandos básicos no terminal seria uma grande vantagem, além de conhecer talvez um dos principais editores de texto (vi, emacs). Para programação de nível inferior, você precisa saber mais sobre chamadas do sistema, arquivos de cabeçalho específicos do sistema e como o encadeamento é tratado no nível do sistema. Por exemplo, o C ++ multiplataforma possui muitas nuances - agora tenho um sistema que compila em todos os principais sistemas operacionais, exceto no Solaris.
Thomas Owens

Ah desculpa. Estou interessado principalmente em programação de nível inferior, mas conhecer comandos também é útil.
rwar


1
O Unix, principalmente o Linux / FreeBSD / etc, é mais barato que o Windows para executar serviços. Portanto, se você pode entregar o Unix e o Windows, sua empresa é mais competitiva.

Mesmo as meninas sabem que youtube.com/watch?v=dFUlAQZB9Ng
MattyD

Respostas:


8

Além do básico, como usar a linha de comando e assim por diante, acho que o fundamental é entender como o sistema está estruturado.

Eu acho que a maior diferença quando se trata do Windows para o Unix é entender como o sistema se encaixa. O Windows se encaixa por meio da API e dos componentes subjacentes do sistema operacional, como COM. Embora isso muitas vezes seja abstraído do programador, alguém que estiver codificando por um longo tempo saberá sobre o modelo de encadeamento COM, GDI e assim por diante. O Unix se encaixa de uma maneira completamente diferente. O Unix é baseado na idéia de criar componentes pequenos e construir sistemas maiores usando IPC (geralmente através de tubos simples).

Você pede um recurso conciso e, pelo menos para mim, o único ponto de partida para entender como o Unix funciona como um ambiente de programação é o ambiente de programação Unix do livro de Kernighan e Pike . Embora o livro em si pareça um pouco datado, é o exemplo perfeito do que é a filosofia do Unix e como se pode alavancar a "maneira do Unix" ao codificar.

Se você pelo menos folhear suas páginas, entenderá como usar o Unix para ajudá-lo a criar programas melhores. Mesmo que você se identifique como um cara do Windows, o conhecimento que você obterá com isso é mais ou menos universal, como são os padrões de design ou as práticas de engenharia de software.

Se quiser saber mais - talvez para o seu trabalho ou apenas porque você gostou - depois de ler o Ambiente de programação Unix, experimente a Programação avançada no ambiente UNIX (R) de Stevens. Ele complementa bem o livro de Kernighan e Pike e, depois de ambos, você terá coberto a maior parte do que eu espero que um programador do Unix saiba. Também há um livro de Stevens sobre programação em rede, também é recomendado.

Além do Linux, existem dois sistemas operacionais que vale a pena tentar: um é o Plan9 , que de certa forma é um Unix melhor que o Unix, e o outro é o OpenBSD . O OpenBSD é construído por uma equipe pequena, por isso é muito consistente e muito bem documentado, por isso é divertido bisbilhotá-lo.


5

Se uma organização estiver usando sistemas operacionais semelhantes ao Unix, todos os desenvolvedores devem conhecer os comandos básicos do terminal para navegar na estrutura de arquivos, criar novos arquivos e diretórios, excluir arquivos, ferramentas de criação de linha de comando, usar controle de versão na linha de comando e talvez script de shell básico para ajudar a automatizar tarefas repetitivas. Na minha opinião, o poder do terminal e a disponibilidade de ferramentas de linha de comando em sistemas semelhantes ao Unix são uma grande vantagem, juntamente com a facilidade de escrever scripts para automatizar várias tarefas complexas que você pode executar regularmente. base.

Há vários aplicativos de linha de comando com os quais você pode se familiarizar. Ferramentas como cat, grep, head, tail, more, e lessvir a calhar para uma série de tarefas, que vão desde a pesquisa através de arquivos para encontrar correspondências de texto, a leitura através de arquivos de log para ajudar na depuração de aplicativos. A capacidade de usar tubos e alimentar a saída por esses aplicativos também é útil para ajudá-lo a analisar as informações disponíveis.

O conhecimento de um dos principais editores de texto (vi ou emacs) também seria útil. Qual deles você usa é uma opinião pessoal, mas eu recomendaria usar o que sua equipe usa (dessa forma, se você tiver dúvidas, haverá alguém em sua equipe para respondê-las). Nas minhas experiências, muitos desenvolvedores Unix "hardcore" preferem essas ferramentas aos IDEs. Eu prefiro um IDE (mesmo em um ambiente semelhante ao Unix), mas os editores de texto têm suas vantagens ao ler arquivos. Sua natureza de linha de comando facilita a pesquisa em arquivos com as ferramentas mencionadas no último parágrafo e, em seguida, abre todos os arquivos correspondentes em um desses editores.

Além do uso das ferramentas fornecidas com o sistema operacional, você também deve estar ciente das diferenças nas bibliotecas. As bibliotecas que fazem chamadas ao sistema (itens que envolvem threading vêm à mente, como um exemplo específico) provavelmente serão diferentes nos sistemas operacionais. Makefiles que possuem sinalizadores para compilar em uma arquitetura específica ou para um sistema operacional específico também podem apresentar problemas. Saber quais sistemas operacionais são usados ​​facilitaria isso - você pode encontrar referências que abordam como implementar determinadas funções dentro desse sistema operacional. No entanto, isso é algo que eu esperaria que você pudesse pegar no trabalho (especialmente para sistemas operacionais que normalmente são usados ​​em ambientes corporativos e aos quais as pessoas geralmente não têm acesso, como o Solaris).


3

O livro que usei na minha classe UNIX foi o "UNIX para programadores e usuários" da Glass and Ables . Boa introdução sólida aos comandos do sistema, ferramentas de arquivamento e programação, visão geral do sistema e da rede e os vários shells. Bastante curto, bem como novo caro. Vem em um sabor Linux também.

Para mais detalhes: "A interface de programação do Linux" . Não é uma introdução leve, mas se você precisar de um manual de referência para encerrar todos os manuais de programação em nível de sistema nos sistemas da família * nix, eu escolheria isso.


Estou na metade da "Interface de programação Linux" no momento. É uma leitura muito aprofundada, e as informações que ela contém são extremamente benéficas. Ele até fala sobre coisas portáteis e como elas são portáteis, o que também é muito útil.
Michael Trausch 01/08/19

-1

Primeiro de tudo, eu recomendaria instalar o ubuntu , que é um bom ponto de partida, em uma partição no seu computador. Tente brincar um pouco. Como assistir a um vídeo com codecs estranhos ... Então você provavelmente precisará usar o terminal para executar alguns apt-get installcomandos, e bang! você está aprendendo a usar um sistema semelhante ao Unix. É isso aí. Comece a codificar e você sentirá a necessidade de aprender enquanto codifica.

Uma lista rápida que vem à mente:

  1. apt-get - como instalar pacotes
  2. top - processos em execução
  3. ps - lista processos, atalho: ps -fea | grep "process_name"
  4. kill -9 PID - mata um processo
  5. sudo cmd - executa comando com permissões de root
  6. Arquivo vi - abre o editor rápido, o google for vi e aprende como usá-lo
  7. gedit - aprenda como usá-lo e expanda-o com plug-ins (pode muito bem funcionar como um IDE completo)
  8. tail -fn500 file - copia um arquivo e imprime as últimas 500 linhas, muito útil para verificar logs
  9. man cmd - man !!! deveria ter sido o primeiro da lista ... Basicamente, você receberá toda a ajuda necessária sobre um comando chamado cmd
  10. aprenda scripts .sh bash. Pesquise no Google e adicione-o ao seu kit de ferramentas do programador. Um dia você vai usá-lo.
  11. pasta cd - navegação
  12. ls - lista arquivos em um diretório
  13. ll - shorcut para ls -l, lista arquivos com detalhes

Se você deseja realmente saber como um sistema operacional funciona e como os sistemas Unix-like funcionam, dê uma olhada no minix e leia o livro do sistema operacional de Tanenbaum .


2
Dessas, apt-geté provavelmente inútil e geditdeve ser familiar para quem já usou um editor de texto. Toda distribuição Linux (e sistema operacional baseado em Unix) tem uma ferramenta de instalação / atualização diferente, e eu não esperaria que um desenvolvedor tivesse que manter o ambiente, como seria feito pela TI. Além disso, você esqueceu de mencionar emacscomo uma alternativa a vi- qual deles usa depende muito das preferências pessoais (e, na minha opinião, das preferências da equipe).
Thomas Owens

1
sim! emacs! Você deve aprender como usá-lo. Bem, eu estou falando sobre o ubuntu (daí o apt-get) aqui .. E sim, você deve aprender como gerenciar seus pacotes .. Caso contrário, você ficaria preso um dia tentando corrigir alguma dependência e talvez precise de purgealgo .. . Nunca se sabe.
Wleao

Eu gostaria de ter uma equipe de TI para manter meu ambiente de desenvolvimento pronto para ir cada vez = /
wleao

Como eu disse, em qualquer empresa de tamanho decente, nenhum engenheiro de software deve estar instalando software. Se algo precisar ser instalado no sistema, a TI deve lidar com isso.
Thomas Owens

1
@ Thomas, para sistemas de desenvolvimento envolvendo TI geralmente é apenas uma perda de tempo. O sistema de produção é outra questão.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.