Vídeo-tutoriais Linux 2
Olá a todos,
hoje estive pensando em fazer vídeo-tutoriais de linux( como a Nixie do post anterior ), mas como não queria reinventar a roda, resolvi ver se já existia algo do gênero na internet 
. Encontrei algumas videoaulas de nível iniciante do Ronaldo no youtube, e estou disponibilizando todas aqui. O conteúdo é de boa qualidade, ele gagueja um pouco, mas nada que atrapalhe o material.
videos aula linux no youtube
Aula 1 http://www.youtube.com/watch?v=Cd_Rwth0BGA
aula 2 http://www.youtube.com/watch?v=_05H5QEWlT8
aula 3 http://www.youtube.com/watch?v=VAOBePJyrbk
aula 4 http://www.youtube.com/watch?v=KAzKZbVDSRY
aula 5 http://www.youtube.com/watch?v=CfS4sYCe8sw
aula 6 http://www.youtube.com/watch?v=ATkKCzCO6LU
aula 7 http://www.youtube.com/watch?v=GGenTiEmI9o
aula 8 http://www.youtube.com/watch?v=GiTyK72YZXk
aula 9 http://www.youtube.com/watch?v=uHOaqRPAic4
aula 10 http://www.youtube.com/watch?v=CfNp7AmY1eI
aula 11 http://www.youtube.com/watch?v=7rX-jh8s2j0
aula 12 http://www.youtube.com/watch?v=nvyv1RLScko
aula 13 http://www.youtube.com/watch?v=P_Jk_vvGPP8
aula 14 http://www.youtube.com/watch?v=DK2KtfzSVyM
aula 15 http://www.youtube.com/watch?v=fRN2-8MX5cM
aula 16 http://www.youtube.com/watch?v=72JZxVNrdAQ
video-tutoriais linux
Me lembro de quando começei a ter contato com linux, tudo era dificil e obscuro, não havia muitos materiais de pesquisa e nem sempre a documentação tinha tudo o que precisavamos saber. Hoje encontrei Nixie, que sempre posta alguns video-tutoriais sobre linux e games, enfim, muito atrativa 
LPI parte 4 – processo de boot ( teórico )
Antigamente, para autoinicializar um computador, era preciso alimentar uma fita de papel que continha um programa de boot ou carregar manualmente um programa de boot utilizando os controles de endereço do painel frontal/dados/controle. Os computadores atuais são equipados com recursos que simplificam o processo de boot, embora não necessariamente o deixem mais simples.
Vamos começar com uma visualização de alto nível de boot do Linux para que se tenha uma visão geral. Em seguida, revisaremos o que ocorre separadamente em cada uma das etapas. As referências de origem durante esse processo o ajudarão a navegar pela árvore de kernel e a entender melhor esse processo.
Visão Geral
A Figura 1 mostra uma visualização estratégica.
Figura 1. Visualização Estratégica do Processo de Inicialização do Linux
Quando um sistema efetua boot pela primeira vez, o processador executa um código em um local conhecido. Em um Computador Pessoal (PC), esse local é o Sistema Básico de Entrada/Saída (BIOS), que está armazenado na memória flash, na placa-mãe. A Unidade Central de Processamento (CPU) em um sistema embarcado solicita ao vetor de reconfiguração que inicie um programa em um endereço conhecido em flash/ROM. Nos dois casos, o resultado é o mesmo. Como os PCs oferecem bastante flexibilidade, o BIOS precisa determinar quais dispositivos são candidatos ao boot. Examinaremos isso posteriormente com mais detalhes.
Quando um dispositivo de boot é encontrado, o loader de boot de primeiro estágio é carregado na RAM e executado. Esse loader de boot tem menos de 512 bytes (um único setor), e sua tarefa é carregar o loader de boot de segundo estágio.
Quando o loader de boot de segundo estágio está na RAM e em execução, uma tela inicial é geralmente exibida e o Linux e o disco RAM inicial opcional (sistema de arquivo raiz temporário) são carregados na memória. Quando as imagens são carregadas, o loader de boot de segundo estágio passa o controle para a imagem do kernel e o kernel é descompactado e inicializado. Neste estágio, o loader de boot de segundo estágio verifica o hardware do sistema, enumera os dispositivos de hardware anexados, monta o dispositivo raiz e, em seguida, carrega os módulos de kernel necessários. Ao ser concluído, o primeiro programa de espaço de usuário (init) inicia e a inicialização do sistema de alto nível é executada.
Em resumo, é assim que funciona o boot do Linux. Agora vamos prosseguir e explorar alguns dos detalhes do processo de boot do Linux.
Inicialização do Sistema
O estágio de inicialização do sistema depende do hardware no qual o Linux está efetuando boot. Em uma plataforma integrada, um ambiente de autoinicialização é utilizado quando o sistema é ligado ou reconfigurado. Como exemplos, temos U-Boot, RedBoot e MicroMonitor da Lucent. As plataformas integradas normalmente vêm de fábrica com um monitor de boot. Esses programas residem em uma região especial da memória flash no hardware de destino e fornecem os meios para fazer download de uma imagem do kernel Linux na memória flash e, em seguida, executá-la. Além da capacidade de armazenar e executar boot em uma imagem do Linux, esses monitores de inicialização executam alguns níveis de teste do sistema e a inicialização do hardware. Em um destino embarcado, esses monitores de inicialização costumam abranger os loaders de boot de primeiro e de segundo estágios.
Extraindo o MBR
Para ver o conteúdo de seu MBR, utilize o comando:
# dd if=/dev/hda of=mbr.bin bs=512 count=1
# od -xa mbr.bin
O comando dd, que precisa ser executado a partir da raiz, lê os primeiros 512 bytes de /dev/hda (a primeira unidade Integrated Drive Electronics ou IDE) e os grava no arquivo mbr.bin. O comando od imprime o arquivo binário nos formatos hex e ASCII.
Em um PC, o processo de inicialização do Linux começa no BIOS, em 0xFFFF0. A primeira etapa do BIOS é Power-On Self Test (POST). A tarefa do POST é executar uma verificação do hardware. A segunda etapa do BIOS é enumerar e inicializar o dispositivo local.
Dados os diferentes usos das funções do BIOS, temos duas partes: o código POST e os serviços de tempo de execução. Depois de concluído, o POST é apagado da memória, mas os serviços de tempo de execução do BIOS permanecem e ficam disponíveis ao sistema operacional de destino.
Para inicializar um sistema operacional, o tempo de execução do BIOS procura por dispositivos ativos e inicializáveis na ordem de preferência definida pelas configurações de Complementary Metal Oxide Semiconductor (CMOS). Um dispositivo de boot pode ser um disco flexível, um CD-ROM, uma partição de um disco rígido, um dispositivo na rede ou até mesmo um memory stick flash USB.
Normalmente, o Linux tem boot executado a partir de um disco rígido, onde Master Boot Record (MBR) contém o loader de boot primário. O MBR é um setor de 512 bytes, localizado no primeiro setor do disco (setor 1 do cilindro 0, cabeçote 0). Depois que o MBR é carregado na RAM, os campos do BIOS o controlam.
Loader de Boot de Estágio 1
O loader de boot primário, que reside no MBR, é uma imagem de 512 bytes contendo o código do programa e uma pequena tabela de partição (consulte a Figura 2). Os primeiros 446 bytes são o loader de boot primário, que contém o código executável e um texto de mensagem de erro. Os 64 bytes seguintes formam a tabela de partição, que contém um registro para cada uma das quatro partições (cada uma com 16 bytes). O MBR termina com dois bytes, que são definidos como o número mágico (0xAA55). O número mágico funciona como verificação de validação do MBR.
Figura 2. Anatomia do MBR
A função do loader de boot primário é encontrar e carregar o loader de boot secundário (estágio 2). Isso é feito consultando a tabela particionada de uma partição ativa. Ao localizar uma partição ativa, ele faz uma varredura das partições restantes na tabela, a fim de certificar-se de que todas estão inativas. Quando isso é verificado, o registro de boot da partição ativa é lido a partir do dispositivo para a RAM e executado.
Loader de Boot de Estágio 2
O loader de boot secundário, ou de segundo estágio, pode ser chamado de loader de kernel. Neste estágio, sua tarefa é carregar o kernel Linux e o disco RAM inicial opcional.
Loaders de Boot de Estágio GRUB
O diretório /boot/grub contém os loaders de bootstage1, stage1.5, e stage2, bem como diversos loaders alternativos (por exemplo, os CR-ROMs usamiso9660_stage_1_5).
Os loaders de boot de primeiro e segundo estágios combinados são chamados de Linux Loader (LILO) ou GRand Unified Bootloader (GRUB) no ambiente x86 do PC. Como o LILO apresenta algumas desvantagens que foram corrigidas no GRUB, vejamos o GRUB. (Consulte muitos recursos adicionais sobre GRUB, LILO e tópicos relacionados na seção Recursos, mais adiante neste artigo.)
O ponto alto do GRUB é que ele inclui o conhecimento dos sistemas de arquivo Linux. Em vez de utilizar setores brutos no disco, como o LILO faz, o GRUB pode carregar um kernel Linux a partir de um sistema de arquivos ext2 ou ext3. Isso é feito transformando o loader de boot de dois estágios em um de três estágios. O estágio 1 executa boot em um loader de boot de estágio intermediário (1,5), que compreende o sistema de arquivos específico, contendo a imagem do kernel Linux. Como exemplos, temos reiserfs_stage1_5 (para carregar a partir de um sistema de arquivos com registro de mudanças Reiser) ou e2fs_stage1_5 (para carregar a partir de um sistema de arquivos ext2 ou ext3). Quando o loader de boot do estágio intermediário estiver carregado e em execução, o loader de boot do estágio 2 poderá ser carregado.
Quando o estágio 2 estiver carregado, o GRUB poderá, mediante solicitação, exibir uma lista dos kernels disponíveis (definidos em /etc/grub.conf, com soft links de /etc/grub/menu.lst e /etc/grub.conf). É possível selecionar um kernel e até aditá-lo com parâmetros adicionais de kernel. Opcionalmente, é possível utilizar shell de linha de comandos para obter um maior controle manual sobre o processo de boot.
Com o loader de boot de segundo estágio na memória, o sistema de arquivos é consultado e a imagem de kernel padrão e a imagem initrd são carregadas na memória. Com as imagens prontas, o loader de boot de estágio 2 chama a imagem de kernel.
Kernel
Boot Manual no GRUB
A partir da linha de comandos do GRUB, é possível executar boot em um kernel específico com uma imagem initrd nomeada, como a seguir:
| grub> kernel /bzImage-2.6.14.2 [Linux-bzImage, setup=0x1400, size=0x29672e]
grub> initrd /initrd-2.6.14.2.img [Linux-initrd @ 0x5f13000, 0xcc199 bytes] grub> boot Descompactando Linux… Ok, executando boot no kernel. |
Se não souber o nome do kernel que será executado o boot, aperte a barra (/) e pressione a tecla Tab. O GRUB exibirá a lista de kernels e imagens initrd.
Com a imagem de kernel na memória e o controle fornecido no loader de boot de estágio 2, o estágio do kernel começa. A imagem do kernel não é bem um kernel executável, mas uma imagem de kernel compactada. Em geral é uma zImage (imagem compactada, com menos de 512KB) ou uma bzImage (imagem compactada grande, com mais de 512KB), previamente compactada com zlib. No início dessa imagem de kernel há uma rotina que executa uma quantidade mínima de configurações de hardware e, em seguida, descompacta o kernel contido na imagem de kernel, deixando-o com bastante memória. Se houver uma imagem de disco RAM inicial, essa rotina vai para a memória e a usa futuramente. A rotina chama então o kernel e a execução de seu boot é iniciada.
Quando bzImage (para uma imagem i386) é chamada, você inicia em ./arch/i386/boot/head.S na rotina de montagem start(consulte a Figura 3 para o fluxo principal). Essa rotina efetua algumas configurações básicas de hardware e chama a rotinastartup_32 em ./arch/i386/boot/compressed/head.S. Essa rotina configura um ambiente básico (pilha, etc.) e limpa o Block Started by Symbol (BSS). Em seguida, o kernel é descompactado por meio de uma chamada à uma função C, denominadadecompress_kernel (localizada em ./arch/i386/boot/compressed/misc.c). Quando o kernel é descompactado na memória, ele é chamado. Esta é ainda outra função startup_32, mas essa função está em ./arch/i386/kernel/head.S.
Na nova função startup_32 (também denominada swapper ou processo 0), as tabelas de páginas são inicializadas e a paginação de memória é ativada. É detectado o tipo de CPU, junto com qualquer Unidade Opcional de Ponto Flutuante (FPU), e são armazenados para uso futuro. A função start_kernel é então chamada (init/main.c), o levando ao kernel Linux que especificamente não faz parte da arquitetura. Isto é, basicamente, a função main do kernel Linux.
Figura 3. As Funções Principais Fluem para o Boot do Kernel i386 Linux
Ao chamar start_kernel, uma lista grande de funções de inicialização é chamada para configurar interrupções, executar configuração de memória adicional e carregar o disco RAM inicial. Ao final, faz-se uma chamada para kernel_thread (emarch/i386/kernel/process.c) para iniciar a função init, que é o primeiro processo de espaço do usuário. Por fim, a tarefa ociosa é iniciada e o planejador agora pode assumir o controle (depois da chamada para cpu_idle). Com as interrupções ativadas, o planejador antecipado assume periodicamente o controle para fornecer várias tarefas.
Durante a inicialização do kernel, o disco RAM inicial (initrd) que havia sido carregado na memória no loader de boot de estágio 2 é copiado na RAM e montado. Essa série initrd atua como um sistema de arquivos raiz temporário na RAM e permite que o kernel execute boot totalmente, sem precisar montar nenhum disco físico. Como os módulos necessários para fazer interface com os periféricos podem fazer parte de initrd, o kernel pode ser muito pequeno, mas ainda oferecer suporte a um grande número de configurações possível de hardware. Depois que o kernel executa boot, o sistema de arquivos raiz é dinamizado (por meio de pivot_root), no qual o sistema de arquivos raiz initrd é desmontado e o sistema de arquivos raiz real é montado.
Saída decompress_kernel
A função decompress_kernel é onde você vê as mensagens de descompactação usuais emitidas para o monitor:
| Descompactando Linux… Ok, executando boot no kernel. |
Ao ligar o computador, e o mesmo efetuar o POST
A função initrd permite criar um pequeno kernel de Linux com drivers compilados como módulos carregáveis. Esses módulos carregáveis possibilitam que o kernel tenha meios de acesso aos discos e aos sistemas de arquivos desses discos, bem como aos drivers de outros recursos de hardware. Como o sistema de arquivos raiz é um sistema de arquivos em um disco, a funçãoinitrd fornece um meio de efetuar a autoinicialização para obter acesso ao disco e montar o sistema de arquivos raiz real. Em um destino embarcado sem um disco rígido, initrd pode ser o sistema de arquivos raiz final ou esse sistema de arquivos raiz final pode ser montado por meio do Network File System (NFS).
Init
Após executar boot e inicializado, o kernel inicia o aplicativo do primeiro espaço do usuário. Ele é o primeiro programa chamado, compilado com a biblioteca C padrão. Até este momento no processo, nenhum aplicativo C padrão foi executado.
Em um sistema Linux de desktop, o primeiro aplicativo iniciado geralmente é /sbin/init. Mas isso não precisa ser assim. Os sistemas embarcados raramente exigem a inicialização extensiva fornecida por init (como configurado por /etc/inittab). Em muitos casos, é possível chamar um simples script de shell que inicie os aplicativos embarcados necessários.
Resumo
Assim como o próprio Linux, o processo de inicialização do Linux é bastante flexível, suportando um grande número de processadores e plataformas de hardware. No início, o loader de boot loadlin oferecia uma maneira simples de inicializar o Linux, de forma simples. O loader de boot LILO expandia as capacidades de inicialização, mas não percebia que nenhum sistema de arquivos estava faltando. A mais recente geração de loaders de boot, como o GRUB, permite que o Linux inicialize a partir de uma variedade de sistemas de arquivos (do Minix ao Reiser).
Extraído na integra do site: http://www.ibm.com/developerworks/br/library/l-linuxboot/index.html
de M. Tim Jones
LPI parte 3
Olá a todos,
Continuando com os estudos, estudarei agora o primeiro tópico solicitado, que é Arquitetura do Sistema.
Dentro deste tópico, começarei com o primeiro assunto que é ”determinar e alterar configurações de hardware”
olhando o site da lpi, eles mencionam as seguintes areas de conhecimento:
- Habilitar e desabilitar periféricos (Enable and disable integrated peripherals. )
- Configurar sistemas com ou sem periféricos externos, como teclados (Configure systems with or without external peripherals such as keyboards.)
- Saber a diferença entre os tipos de dispositivos de armazenamento (Differentiate between the various types of mass storage devices. )
- Configurar corretamente os ID para diferentes dispositivos, especialmente os de incialização (Set the correct hardware ID for different devices, especially the boot device.)
- Saber a diferença entre dispositivos hotplug e coldplug ( Know the differences between coldplug and hotplug devices. )
- Determinar os recursos de hardware para os dispositivos ( Determine hardware resources for devices.)
- Tools and utilities to list various hardware information (e.g. lsusb, lspci, etc.) ( comandos )
- Ferramentas e utilitários para manipular dispositivos USB ( Tools and utilities to manipulate USB devices )
- conceitos de sysfs, udev, hald e dbus (Conceptual understanding of sysfs, udev, hald, dbus )
O linux trabalha da seguinte forma, o Kernel ( que é o coração do sistema ) controla todo o hardware, para fazer interface com os programas/usuário. Ele controla o hardware através de módulos ( em uma analogia com o windows, são os drivers ).
para verificar o hardware que usa o barramento pci instalado na sua maquina, basta rodar o comando lspci:
alan@SLVDSKCSS1000:~$ lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 661FX/M661FX/M661MX Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS AGP Port (virtual PCI-to-PCI bridge)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] (rev 36)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC’97 Sound Controller (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
00:05.0 IDE interface: Silicon Integrated Systems [SiS] RAID bus controller 180 SATA/PATA [SiS] (rev 01)
00:0b.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter
Só para compreendermos melhor, a primeira coluna mostra o barramento pci, a 2ª mostra o tipo ( usb,pci,ide etc ) a 3ª mostra o nome e o fabricante e a ultima a revisão.
se quizer mais detalhes use a opção -v ( verbose)
Para conhecer detalhes do lspci, e outros comandos no linux, você pode usar as “man pages” e/ou as “info pages” digitando $man nome_do_programa ou info nome_do_programa
outro comando é o lsusb, ele tem o mesmo proposito do lspci, mas ele lista somente os dispositivos conectados as portas usb.
alan@SLVDSKCSS1000:~$ lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Para utilizar todos os recursos do lsusb seu kernel precisa ser versão 2.3.15 ou superior porque é necessário suporte a interface /proc/bus/usb. Para ver sua versão do kernel digite o comando: uname -a
Conforme mostrado acima, temos o nome do modulo, o tamanho do mesmo em bytes, e o processo que está usando aquele módulo.
para carregarmos módulos, usamos o comando modprobe:
root@SLVDSKCSS1000:~# modprobe -v sis900
insmod /lib/modules/2.6.31-15-generic/kernel/drivers/net/mii.ko
insmod /lib/modules/2.6.31-15-generic/kernel/drivers/net/sis900.ko
Acima, habilitei o módulo da minha placa de rede, o parametro -v ( verbose ) serve para mostrar detalhes do que está ocorrendo, e no final vem o nome do módulo.
para desabilitarmos módulos podemos usar o modprobe -r ( remove ) ou o comando rmmod, os dois fazem a mesma coisa.
Para que alguns módulos funcionem, estes dependem que outros modulos estejam levantados, por exemplo, a placa de som precisa além do módulo da placa em si do soundcore (módulo de som). O melhor do modprobe é que ele resolve essas dependencias automaticamente para você, ou seja, se você pedir para levantar o módulo da placa de som e o soundcore não estiver levantado, o modprobe levanta o soundcore automaticamente.
Outro comando que é usado em conjunto com o modprobe é o depmod, ele cria ou atualiza o arquivo modules.dep, que é o que contém informações de dependências de módulos usados pelo modprobe.
Outro item importante, é o diretório /proc , é nesse diretório que o kernel guarda as informações sobre o hardware, como DMA, endereços de E/S e IRQs
para que possamos visualizar o conteúdo, basta executar um cat nos arquivos especificos que queremos consultar.
root@SLVDSKCSS1000:~# cat /proc/dma
3: parport0
4: cascade
root@SLVDSKCSS1000:~# cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0073 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : 0000:00:02.5
root@SLVDSKCSS1000:/home/alan# cat /proc/interrupts
CPU0
0: 49 IO-APIC-edge timer
1: 10946 IO-APIC-edge i8042
3: 2 IO-APIC-edge
4: 2 IO-APIC-edge
7: 0 IO-APIC-edge parport0
8: 0 IO-APIC-edge rtc0
9: 0 IO-APIC-fasteoi acpi
12: 1014500 IO-APIC-edge i8042
14: 0 IO-APIC-edge pata_sis
15: 0 IO-APIC-edge pata_sis
17: 65073 IO-APIC-fasteoi sata_sis
18: 1002 IO-APIC-fasteoi SiS SI7012
19: 1446350 IO-APIC-fasteoi nvidia, eth0
20: 0 IO-APIC-fasteoi ohci_hcd:usb2
21: 0 IO-APIC-fasteoi ohci_hcd:usb3
22: 0 IO-APIC-fasteoi ohci_hcd:usb4
23: 564048 IO-APIC-fasteoi ehci_hcd:usb1
No exemplo acima, podemos ver que as interrupções 14 e 15 estão sendo usadas para controlar o disco rigido ( ata ) e a IRQ 19 está controlando tanto o video quanto a rede ( nvidia e a placa de rede eth0 )
O diretório /sys , assim como o /proc é um diretório virtual e possui informações sobre os dispositivos plug and play. Ao entrar nele nos deparamos com vários diretórios neles estão os dispositivos do sistemas e podemos configurá-los por alí. O nome dos diretórios que representam os dispositivos são estranhos, como 000:00:02.0 mas você pode usar o comando lspci -v para confrontar esse código e identificar corretamente qual dispositivo ele representa.
O diretório /dev contém os arquivos de dispositivos. Ele pode ser do tipo devfs ou udev. Este último é o formato mais atual e é suportado a partir do kernel 2.6.15 e deve substituir totalmente o devfs. A principal diferença entre os dois é que o udev não ocupa espaço no HD por ser montado na memória RAM ao contrário do devfs.
O Linux trabalha com dispositivos (falando em hardware) como arquivos. Ou seja, para cada dispositivo que eu tenho na máquina tenho um arquivo dispositivo para ele em /dev. Esses arquivos não são armazenados no HD, mas sim “links” para dispositivos de hardware. Por exemplo, todos os arquivos gravados no arquivo /dev/dsp serão reproduzidos pela placa de som. Esta organização é para facilitar a vida dos programadores, que podem acessar o hardware do micro simplesmente fazendo seus programas lerem e gravarem em arquivos.
em breve posto os conceitos de udev, hald e dbus.
SYSFS – O sistema de arquivos sysfs é considerado uma fusão dos sistemas de arquivos proc, devfs, e devpty. O sistema de arquivos sysfs enumera os dispositivos e barramentos conectados a um sistema em uma hierarquia que pode ser acessada do “espaço de usuário” ( ou seja, sem ser o root ). O sysfs é projetado para lidar com opções específicas de dispositivos e drivers que anteriormente eram mantidas no /proc/, e trazia a inclusão dinâmica de dispositivos oferecida anterioemente pelo devfs.
DBUS - É um sistema de comunicação entre processos numa mesma máquina. Todo sistema operacional que se preze dispõe de recursos de IPC (inter-process comunication), contudo D-Bus foi criado visando facilitar e estabelecer um padrão para a comunicação entre aplicações do desktop. Diferente de outros métodos de IPC ou das conexões TCP, que transportam dados como fluxos indistintos de bits, D-Bus transporta mensagens contendo dados de tipos bem definidos.
Um uso interessante do D-Bus é um plugin para o Rhythmbox que sempre que uma música começa a tocar, ele atualiza minha mensagem de status no GAJIM para uma frase como “Ouvindo Banda Tal, Música Tal”. Isso funciona porque o GAJIM disponibiliza serviços de mudança de mensagem de status na SessionBus.
UDEV - é um gerenciador dinâmico de dispositivos para o Linux 2.6. A sua função principal é o gerenciamentos de nós de dispositivo no diretório /dev. Ele é o sucessor do DEVFS e do hotplug. Ele cria ou remove nós de dispositivo que estão presentes no diretório /dev
HALD – ( hardware abstraction layer daemon ) é um serviço que gerencia o banco de dados de dispositivos que estão conectados ao sistema em tempo real. o serviço utiliza o DBUS para operar os dispositivos. Por exemplo, quando você conecta o pendrive no micro, o dbus inicia o disposivo e já monta ele automaticamente para uso.
Com isso finalizo o primeiro tópico da lpi 101.1 , os itens do site que não mencionei, não o fiz porque são muito básicos em configuração de computadores e se você que me lê não diferenciar um disco master de slave e configurações na bios sugiro que estude esses itens antes de continuar.
No próximo post falaremos sobre inicialização do linux ( tópico 101.2 )
fontes:
inté
escada piano
Engraçado como o comportamento das pessoas pode mudar, ao experimentar algo novo e divertido . Confesso que perderia um tempo pra subir essas escadas
fonte: Gizmodo
Monitor Transparente
Impressionante como os avanços tecnológicos estão mudando a forma como vemos o mundo hoje em dia. Abaixo temos um protótipo da Samsung de um monitor transparente, feito com a tecnologia OLED. Na hora lembrei de quando via Dragon ball e os caras tinham uns visores que já usavam a falada “realidade aumentada“
LPI parte 2
Olá novamente!
No meu ultimo post apenas descrevi o conteúdo solicitado para a primeira prova da Certificação LPI 101.
Analisando os itens solicitados, e os seus respectivos pesos, podemos perceber que o mais importante, e também o mais pedido, é o domínio na linha de comando e as ferramentas que são padrão no GNU/linux.
Os tópicos abaixo são os mais importantes ( peso 4 )
103.1: Trabalhando com a Linha de Comando.
103.3: Gerenciamento Basico de Arquivos
103.4: Usando streams, pipes e redirects
103.5: Criando, monitorando e matando processos
Será nesses caras que dedicarei mais o meu tempo, mesmo porque, são os mais utilizados no dia-a-dia.
Seguido desses itens, outros que também são cobrados, mas com uma menor intensidade são os abaixo ( peso 3 ):
101.2: inicialição do sistema
101.3: alterando os Runlevels ( niveis de execução ) Desligando e reinicializando o sistema
102.4: Usando o Gerenciador de pacotes Debian ( Use Debian package management )
102.5: Usando o Gerenciador de Pacotes YUM e RPM
103.2: Processando Texto Usando Filtros
103.8: executando operações de Edição de texto basicas no VI
104.5: Gerenciando Permissões de Arquivo e propriedade ( ownership )
abaixo os itens de peso 2:
101.1: Determinar e alterar configurações de Hardware
102.1: Design do HD e layout de partições ( *Design hard disk layout )
102.2: Instalando um Gerenciador de Boot
103.7: Procurar em arquivos de texto usando Expressões regulares
104.1: Criando partições e Sistemas de Arquivos
104.2: Mantendo a integridade do sistema de arquivos
104.6: Criando e modificando hardlinks e softlinks.
104.7: Encontrando arquivos de sistemas e colocando no lugar certo.
os itens de peso 1, apenas comentarei, e me atentarei a detalhes que achar importante em algum deles.
A forma como desenvolverei meu estudo será linearmente, ou seja, estudarei os itens conforme eles aparecem no site do LPI, com o unico detalhe de dar mais atenção aos itens conforme marcados acima.
Tópico 101: Arquitetura do Sistema
Tópico 102: Instalação do Linux e Gerenciamento de pacotes
Topico 103: GNU e os comandos Unix
Topico 104: Dispositivos, Sistemas de Arquivos Linux, e Hierarquia Padrão de Sistema de Arquivos ( Filesystem Hierarchy Standard )
No próximo post começo o primeiro item, “Arquitetura do Sistema”.
LPI parte 1
Saudações
Neste segundo post, estarei esclarecendo algumas diretivas no preparo para a prova, como por exemplo, a forma como organizarei os estudos e os metodos para melhor aproveitamento tanto do tempo quanto do material que usarei neste periodo.
A principio, estarei usando somente materiais encontrados na internet, pois acredito que esta é a fonte mais atualizada e em sintonia com os requisitos da prova da LPI.
Vou começar praticamente igual a forma de estudo usada pelo Hebert Moroni, em seu blog: blog do moroni
gostei muito do metodo de estudo proposto por ele, e tentarei seguir conforme demonstrado no blog dele.
Primeiro é necessário acessar o site da LPI e verificar o que é pedido na prova.
http://www.lpibrasil.com.br/ site nacional ou
http://www.lpi.org/ site oficial ( inglês )
como meu objetivo é a primeira certificação, ( LPI 101, 102 ) vamos ver quais são os requisitos pedidos para tirar esta certificação.
O link direto para os objetivos da prova é este:
https://www.lpi.org/eng/certification/the_lpic_program/lpic_1/exam_101_detailed_objectives
A prova é estruturada de acordo com a importância de cada assunto solicitado, sendo enumerados de 1 até 4 ( quanto maior o número, maior a importância do tópico )
Traduzindo os principais tópicos e seus respectivos pesos são:
Tópico 101: Arquitetura do Sistema
101.1: Determinar e alterar configurações de Hardware
peso: 2
101.2: inicialição do sistema
peso: 3
101.3: alterando os Runlevels ( niveis de execução ) Desligando e reinicializando o sistema
peso: 3
Tópico 102: Instalação do Linux e Gerenciamento de pacotes
102.1: Design do HD e layout de partições ( *Design hard disk layout )
peso: 2
102.2: Instalando um Gerenciador de Boot
peso: 2
102.3: Gerenciamento de bibliotecas compartilhadas ( Manage shared libraries )
peso: 1
102.4: Usando o Gerenciador de pacotes Debian ( Use Debian package management )
peso: 3
102.5: Usando o Gerenciador de Pacotes YUM e RPM
peso: 3
Topico 103: GNU e os comandos Unix
103.1: Trabalhando com a Linha de Comando.
Peso: 4
103.2: Processando Texto Usando Filtros
peso: 3
103.3: Gerenciamento Basico de Arquivos
peso: 4
103.4: Usando streams, pipes e redirects
peso: 4
103.5: Criando, monitorando e matando processos
peso: 4
103.6: modificando a prioridade de execução dos processos
peso: 2
103.7: Procurar em arquivos de texto usando Expressões regulares
peso: 2
103.8: executando operações de Edição de texto basicas no VI
peso: 3
Topico 104: Dispositivos, Sistemas de Arquivos Linux, e Hierarquia Padrão de Sistema de Arquivos ( Filesystem Hierarchy Standard )
104.1: Criando partições e Sistemas de Arquivos
peso: 2
104.2: Mantendo a integridade do sistema de arquivos
peso: 2
104.3: Montando e Desmontando Sistema de Arquivos.
Peso: 3
104.4: Gerenciando Quotas de disco.
Peso: 1
104.5: Gerenciando Permissões de Arquivo e propriedade ( ownership )
peso: 3
104.6: Criando e modificando hardlinks e softlinks.
Peso: 2
104.7: Encontrando arquivos de sistemas e colocando no lugar certo.
Peso: 2
São no total 4 areas de conhecimento principais, somando no total 23 itens ( ou conceitos ) que precisamos dominar para passar no exame. No próximo post, irei detalhar cada uma delas e definirei melhor um plano de estudos.
Até a próxima.
Iniciando!
Sejam bem vindos!
Após ver alguns amigos publicarem blogs sobre assuntos diversos, resolvi criar meu próprio blog para organizar meus estudos ( meu objetivo atual é a certificação linux LPI 101, 102), e também colocar algumas curiosidades que geralmente vejo durante o meu dia-a-dia 
