fabim escreveu:Caras uma coisa que eu tenho visto , e nao entendido.
O pessoal mistifica muito as coisas.
Quando eu mechia com pic, o junior me explicou sobre o arm etc. eu achei ele louco de dizer que arm era mais facil que pic.......
Comecei a usar, e mecher, e em pouco tempo eu ja tava com target pra pegar projetos de nivel médio, e hoje alto pelo uso continuo.
MAS e SOMENTE MAS.
Eu consegui aprender sobre o arm pois achei a ponta do novelo e fui desenrolando.
Agora o linux, as informações que eu achei na net sao da mesma coisa, mais de forma muito diferente e nenhuma bate com a outra.
Eu estou sugerindo uma criação de uma discução que irá iniciar de um ponto comun e os esperientes e nao esperientes começarão a fazer algo numa plataforma comun, sobre algo comum, e de uma questao comum.
Minha sugestao seria pelo começo do inicio.
Linux ja sabemos todos quem fez, o que é, etc///
como eu falei, vc precisa ler o livro do minix!
e precisa largar essa coisas de pic, arm e processadores pequenos. vc tem que ler algo sobre processadores de verdade, desenvolvidos para computacao barra pesada! nao precisa ir no fundo do poco e ler sobre powerpc e x86, afinal existia computacao pesada na decada de 80: 386 e 68030 te dizem tudo que vc precisa saber sobre processadores de verdade! lah tem sobre caches, sobre mmu, sobre seguranca, etc.
Mas como é organizado ?
a essencia do negocio eh que o linux eh um unix. entao vc tem que entender o que eh um unix e como funciona. o conceito eh antigo, da decada de 70, e a ideia era um sistema operacional capaz de compartilhar um computador para varias pessoas. obviamente, para isso ser possivel, o sistema operacional precisa fatiar o tempo de processador entre diversas aplicacoes, de modo que os usuarios nao percebam que estao compartilhando a mesma maquina.
os detalhes funcionais vc encontra no livro do minix, que detalha bem o que seria um unix.
mas a grosso modo de um lado vc tem um kernel que toma conta do escalonamento de processos, device drivers e memoria. do outro lado vc tem as aplicacoes, que usam as funcionalidades supridas pelo kernel. em um processador de verdade, como um mero 680x0, existe uma divisao de hardware chamada modo supervisor e modo usuario. o kernel roda em modo supervisor e possui privilegios de acessar todo o sistema, enquanto que as aplicacoes rodam em modo usuario e nao possuem privilegios.
em um sistema com o hardware bem construido, apenas o kernel pode acessar os perifericos. e em sistema que possuem unidade de paginacao, eh possivel granularizar os acessos a memoria e perifericos na forma de paginas, alem de permitir o tratamento de paginas inexistentes, o que nos remete ao conceito de maquina virtual e memoria virtual.
no caso do linux, temos um kernel (que eh o linux propriamente dito) e temos os aplicativos. tudo, desde o shell ao compilador, passando pela interface grafica e pelos servicos de rede, eh aplicativo, pq a ideia eh justamente ter um kernel leve e agil, que cuide apenas de memoria, perifericos e comunicacao entre aplicativos. essa eh a filosofia do unix e vc encontra isso nao apenas no linux, mas tb em qq bsd ou unix-like por aih.
Pra que servem as pastas ?
primeiro que nao sao pastas... sao diretorios!

os diretorios no linux sao variados pq seguem estilos variados de unixes. existem alguns linux que sao bsd-like, outros que sao solaris-like, etc. e obviamente essa gente nao pensa pequeno! em uma maquina intel tipica vc consegue colocar na boa 50 usuarios online na mesma maquina. em maquinas unix grandes, vc pode passar de 1000 usuarios na boa. entao como organiza isso?
em primeiro lugar, as pessoas costumam dividir os discos em particoes. tem uma particao para a maquina bootar e, depois que ela boota, vc monta outras particoes. entao eh comum colocar no / apenas o essencial para a maquina bootar. mas mesmo o essencial eh muito mais do que um windows tipico vai ver na vida, pois lembre-se que estamos falando em colocar no ar uma maquina para 1000 usuarios... entao costuma-se espalhar as coisas em diretorios que tem suas finalidades (explico abaixo).
depois q a maquina boota, ela pode montar discos extras via rede ou local. no unix nao existe letra para identificar discos, ao inves disso os discos aparecem como diretorios na arvore de diretorios e vc nem identifica a diferenca, pq eh feito para ser transparente para os usuarios.
O que tem nas pastas ?
entao, um unix tipico devora mainframes no cafeh da manha e costuma ter uma administracao complexa. jah vi em maquinas grandes usarem powerpcs como coprocessadores de gerenciamento apenas para fazer os processadores maiores conseguirem bootar, o que mostra que nao deve ser facil fazer uma maquina multiprocessada subir!

para subir, a maquina precisa do basico:
/bin - comandos basicos e essenciais, como shell, awk, cp, ls, test, ln, dd, rm, etc.
/dev - mapeamento dos devices para os aplicativos, como discos, seriais, video, etc.
/etc - configuracoes basicas e essenciais como hosts, passwd, fstab, etc
/lib - bibliotecas basicas e essenciais, como libm, libc, libcrypt, etc
/tmp - espaco para arquivos temporarios de uso geral
/sbin - comandos essenciais de supervisao, como mount, umount, fsck, route, ifconfig, etc
qdo a maquina sobe, normalmente ela roda um programa chamado /sbin/init. esse em geral eh o primeiro processo e ele governa o que vai rodar depois, o que normalmente varia conforme o estilo, mas que em geral eh um script de inicializacao single-user e multi-user.
o script de inicializacao single-user em geral monta os outros discos nos seguintes diretorios:
/var - espaco para arquivos de spool em geral, como smtp, pop3, etc
/home - espaco para arquivos de usuarios (cada usuario tem um diretorio dentro do /home)
/usr - comandos nao tao basicos ou essenciais, como lpr, gzip, gcc, apache, diff, etc
o /usr normalmente tem uma arvore interna variada, que vc imagina que espelha em parte o /:
/usr/bin - comandos gerais (em um unix tipico vc encontra mais de 1500 comandos aqui)
/usr/sbin/ - comandos gerais para administracao (em um unix tipico vc encontra 250 comandos aqui)
/usr/lib/ - bibliotecas gerais (diretorios e diretorios com biblioteca para tudo que vc imaginar no universo!)
quando vc sobe isso, o init em geral roda um equivalente a um ou mais scripts multi-user, que eh quando sobem os servicos. entre os servicos estao atender redes e fornecer formas dos usuarios logarem, abrindo telas de login ou servicos como telnet e ssh. quando vc loga neles, vc eh remetido a um shell, onde pode digitar comandos e chamar aplicacoes.
as vezes vc tem o /usr/local, que espelha o / e /usr:
/usr/local/bin
/usr/local/sbin
/usr/local/lib
nem precisa explicar q eh um padrao que se repete. mas pq ter a mesma coisa em diretorios diferentes?
pense em uma situacao padronizada onde vc tem 1000 servidores. cada um deles tem que bootar, seja da rede, seja do disco local. entao tem o / com a configuracao particular da maquina no /etc. daih sobe a rede com os parametros que ali estao. e entao as 1000 maquinas podem montar o /usr, /home e /var via rede. mas digamos que dessas 1000 maquinas, tem 100 q tem algo em particular. vc pode montar o /usr/local diferente nelas e ter aplicacoes diferentes.
por exemplo, no /bin vc tem awk que eh um tool essencial, no /usr/bin vc tem o gcc, que eh um tool nao tao essencial e no /usr/local/bin vc tem o iverilog, q eh um tool mais particular. eh uma forma de organizar... nada impede de colocar o iverilog no /usr/bin, mas colocar no /bin seria algo extremamente feio e pouco elegante quando se fala em unix!

aqui tem uma recomendacao bacana, mas nao eh uma regra:
http://en.wikipedia.org/wiki/Filesystem ... y_Standardeh questao de vivencia... depois de um tempo qq unix da face da terra parece igual ao outro, embora normalmente cada um tenha sua particularidade.
Criar drives de acesso ao processador algo a ser usado. Como funciona ? ja existe algo pronto do fabricante ? Comandos ? Como aprender a estrutura de um drive ?
normalmente o fabricante do chip possui os drivers para o principal. se vc tem uma interface SPI, possivelmente existe um device driver para a SPI. mas nao quer dizer q o device driver para a SPI acesse qq tipo de dispositivo pendurado na SPI! quer dizer q talvez vc tenha que fazer um device driver que usa o driver da SPI existente como meio de acesso.
eh soh pensar no conceito de stack de protocolos. se vc tem que acessar a porta 80, vc nao vai criar do zero a stack inteira com tcp, ip, mac, etc. mas no caso do linux pode ter um problema: as vezes as interfaces de acesso variam e vc vai ter q se virar com a documentacao que existe, ou seja, vai ter q ver como os outros fazem!

passar por cima do kernel eh possivel, mas nao uma boa opcao. em processadores com divisao entre kernel e user space, nao eh simples. e como jah mencionei milhares de vezes, se vc fizer uma simbiose com o kernel, vc consegue device drivers muito preemptivos e eficientes, principalmente se for algo network centric:
http://www.asm51.eng.br/phpbb/viewtopic.php?t=11223
Shell ? ESSO ? o que é ? como funciona ? onde fica e como se conversa com ele ?
como eu falei, o shell eh a aplicacao que permite vc chamar outras aplicacoes. geralmente fica no /bin/sh, mas podem existir varios shells. tem gente que gosta de C, entao tem o csh, tem gente que gosta de outras notacoes. o /bin/sh, em geral, tem uma notacao meio requerida pq precisa interpretar scripts na maquina. um exemplo de script simples:
#!/bin/sh
export IP_GW= 192.168.0.2
export IP_SRC=192.168.0.1
export IP_DST=192.168.1.0/24
/sbin/ipfw add 1 pass icmp from any to any
/sbin/ipfw add 2 pass ip from $IP_SRC to $IP_DST
/sbin/ipfw add 3 deny ip from any to any
/sbin/route add default $IP_GW
em essencia, eh um arquivo de lote. mas o shell permite outras falcatruas no gerenciamento de processos, por exemplo:
mkfifo fofo
cat arquivo > fofo &
e o cat foi para background e parou escrevendo em um fifo. daih vc roda:
cat fofo
e ele comeca a cuspir pela fifo o que o outro comando em background esta rodando. se o arquivo for meio grande, vc pode parar a execucao com control+z e entao rodar um ps -ef, o que vai mostrar os pids dos arquivos. vc pode puxar o primeiro para frente com fg 1 ou o segundo com fg 2 o entao matar eles com o comando kill. eh evidente que isso eh uma mao na roda no que diz respeito a administracao remota!

daria para passar a semana escrevendo dicas de shell aqui, mas nao dah meo... imagina que um unix tipico tem 1500 comandos e um bombado ateh o talo pode passar na boa de 10 mil comandos! e 90% disso eh feito em C, o que significa que a galera escreve codigo demais! hehehe
Servidor de janelas e gui ? Um misterio fascinante e macabro ao mesmo tempo, tem como aprender algo mais no utero da coisa ?
interface grafica eh coisa do passado!

mas se interessar, tem um tutorial que eu escrevi na epoca em que eu era otario e mexia com essas coisas idiotas:
http://xstep.sourceforge.net/xstep-3.5. ... index.html isso ja irá dar um passo gigantesco para todos, a ponto de a maioria aqui aprender muito e quem sabe formar uma comunidade e fazer uma distribuição fazendo assim, um **** aprendizado !!!!!!
Se a maioria concordar, tenho certeza que vai ser um **** investimento, pois o futuro tende a isto!!!!
na verdade isso eh realidade faz tempo... soh nao dah para falar para os veios do forum que eles tem um ataque!
