Category Archives: Administração de sistemas

Instalando o flash no Chromium e no firefox no Ubuntu

O problema

Well, não gosto do ubuntu, mas recentemente eu me deparei com um problema em um computador com ubuntu.

Como todos devem saber, o suporte ao flash usando uma determinada API foi descontinuado(que é a NPAPI), e com isso o firefox e o chromium não tem mais suporte ao flash. O chrome não sofre com isso porque convenientemente ele vem com uma versão do flash embarcado no navegador, que usa uma outra API(que é a PPAPI).

A solução

Dito o problema, como resolver isso é muito simples, só usar o novo plugin do flash para a API nova.

Basicamente, para instalar o flash para o firefox e o chromium no ubuntu, é só executar:


sudo apt-get install pepperflashplugin-nonfree && sudo update-pepperflashplugin-nonfree --install
sudo add-apt-repository ppa:nilarimogard/webupd8 && sudo apt-get update && sudo apt-get install freshplayerplugin

Comentários sobre

A solução é para o ubuntu, mas pode facilmente adaptada para outras distribuições.

É uma bosta essas coisas, e quem sofre é usuario, mas fazer o que né. Só fica o desejo que esse povo deixe as coisas mais claras no futuro, principalmente para os usuários finais ai.

Advertisements

Sistema Operacional miniOS-0.02: Configuração do Ambiente

Ola terráqueos. Voltei.

Estou continuando a serie de posts sobre como fazer um sistema operacional, fazendo o meu proprio sistema.

Agora vou tratar da configuração do ambiente, ou em outras palavras, deixar as ferramentas que não são de desenvolvimento ajustadas para facilitar. Basicamente vamos falar do diretório /tools do nosso projeto.

Quando essa parte do tutorial estiver publicada no meu blog, você já poderão conferir no repositório os fontes dos arquivos.


/tools/boot_qemu.sh

Primeiramente, vamos falar sobre esse arquivo, que vai ser o script que vai ajudar a inicializar o nosso kernel.

Para testar o kernel, eu optei por usar o qemu, que é um emulador de maquinas bem completo e com suporte a virtualização, ou seja, podemos também usar o kernel um uma maquina virtualizada com pouco esforço.

Não vou explicar o script, acho que isso não é necessário, mas a função básica é verificar se o qemu de 32 bits esta disponível no sistema, se não estiver, usar o comando padrão. Depois, se a variável de ambiente estiver sem nenhum valor, ele procurar a imagem do kernel com o nome padrão(“miniOS”) e inicializa o sistema. Como vamos precisar por questões de debug saber o conteúdo dos registradores, esse script vai esperar um tempo para que a maquina levante o sistema e vai mostrar o conteúdo dos registradores.

O objetivo vai se rodar esse comando depois de construir o “executável” do sistema, dentro do diretório central do código fonte.

Originalmente, no tutorial do Bran e em outros, se usa um “emulador” antigo mas que funcionava bem legal, que era o bochs. O bochs é funcional e foi muito usado durante muito tempo, mas ele sempre foi mais difícil de usar, além de ter alguns “bugs” que não me pareciam muito fáceis de lidar… Por isso resolvi usar uma ferramenta mais fácil e moderna, por isso o qemu ;).

Para quem quer usar uma interface, eu recomendo o aqemu. Ele tem a opção de colocar um kernel para dar boot, e fica mais pratico. Não vou abordar isso, tanto porque acho o script mais fácil ^^.

Como sempre, o código agora já esta no repositório.


O caso do lavabit, e porque não se deve confiar na liberdade nos EUA

http://lavabit.com/

Certo, vi isso hoje, mas acessem o link acima para entender toda a historia melhor, mas seque um resumo.

Existia uma companhia chamada lavabit que era dos EUA e tinha como proposta armazenar de forma segura dados de clientes.

O governo processou a companhia de uma forma que o dono ficasse totalmente sem defesa, deixando apenas duas alternativas: ou ele encerrava as operações ou ele entregava o acesso a todos os dados dos seus clientes, mesmo sem ser preciso ou encorajado pela lei.

Como ele era uma empresa seria, ele resolveu fechar as portas. E apesar de não poder fazer outra coisa e ter sua esperança na liberdade dos EUA abalado, ele ainda juntou paciência dele e fez o relato acima do link. Muito interessante de acompanhar.

Continue reading


LibreSSL e porque o openssl ainda é perigoso

Certo, em épocas de heartbleed e coisas do tipo, começamos a perceber que existem alguns problemas com algumas implementações não tão modernas

Mais especificamente com o OpenSSL, recentemente na tentativa de evitar outros erros futuros, pessoas começaram a olhar e relatar problemas adicionais com o openSSL. Devido a vários problemas, foi resolvido criar um fork do projeto chamado “libreSSL“.

Realmente não gosto muito da ideia de se fazer um fork de forma desnecessária, mas procurando sobre o assunto, encontrei esses slides que justificam o clone:

http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html

Recentemente soltei um twett sobre um post falando sobre a baixa qualidade em códigos científicos. Acho que esse é um caso de grande parte das coisas que são motivos do clone até.

Ah, também acho interessante que o projeto é vinculado ao openBSD, mas ainda assim ele é portável. Quer dizer, acho que a maior parte das coisas feitas no openBSD são portáveis mesmo.

UPDATE:

Um link muito útil que o Dielson colocou para entender o Heartbleed:

http://www.dwheeler.com/essays/heartbleed.html


O mais simples, funcional e disponivel servidor de arquivos HTTP

Precisava de um servidor HTTP para servir arquivos em uma pasta entre computadores.

Obviamente, eu já fiz um servidor em C++ para isso, mas esse servidor é meu, eu tinha que baixar, compilar e fazer muitas coisas que podiam não estar disponíveis no momento.

Procurando uma solução para esse problema, eu encontrei algumas soluções boas, mas, a melhor foi baseada em python:

python2 -m SimpleHTTPServer

Ou:

python3 -m http.server

Lembre de rodar esse comando dentro da pasta que você quer servir.


Apresentação SIASE

Apresentei um mini-curso no SIASE(não sei o link do site…), e minha apresentação foi essa aqui.

Estou postando porque disse que ia colocar o link da apresentação no meu blog, e para falar um pouco sobre a minha impressão.

Bom, o evento pecou um pouco em organização, mas as palestras foram interessantes e as ideias boas. Realmente esse tipo de evento é o que precisa ser feito periodicamente.

Com relação a cidade, Santana(que coincidentemente é a cidade onde meu pai nasceu), tive uma boa impressão. Como em 2 lugares excelentes, um chamado capim verde e o outro Xonkantes, algo assim, que realmente foram muito bons.

A hospedagem que ficamos foi muito boa também, ótima vista, bem localizada, e com um bom preço. O quarto tinha ar-condicionado também, que devido ao calor da cidade era bem necessário…

Também fui na casa de um parente de uma amiga, e tenho a dizer que o povo de lá é legal.

Ou seja, foi uma boa viagem, um bom mini-curso, pena que não consegui descansar o tempo necessário lá, porque não fui a passeio também né? 😉


DIY: Como construir o seu próprio arcade parte 01

A algum tempo, eu pensei em fazer um arcade, só que meio que desisti porque não tenho tempo e espaço para um arcade.

Mas, aparentemente alguns amigos meus estão se reunindo para essa empreitada, o que torna bem mais fácil de fazer, e legal também!

Como eu sou um quase freak de planejamentos, traçar um plano para um projeto é sempre um bom começo na minha mente, nem que para que no final ele seja todo desfeito…. Durante a minha pesquisas, eu consegui montar um padrão do que fazer para montar um arcade funcional em casa emulando jogos ou uma replica ou um arcade original.

Porque não faço um trull arcade Jamma from Hell of seven kings replica? Simples, eles são mais chatos de fazer, caros, e além de tudo, mais difícil de manter, mas pouca coisa muda, a não ser a dificuldade de conseguir e montar as coisas, então serve também essas dicas que eu vou dar.

Então vamos as minhas considerações, espero que seja útil, e qualquer coisa que eu esqueci me lembrem ai para que o meu arcade também saia descente.

O tipo

Existem vários tipos de console, e aqui decidimos o tipo que vamos fazer. Essa é a primeira e fundamental parte do projeto, porque facilita ou não algumas etapas, apesar de todo mundo normalmente escolher um arcade tradicional.

Quanto aos tipo, temos:

  • Tradicional: Visual clássico, normal de fazer, difícil de transportar e mais difícil de alocar em casa.
  • Mini/Nano arcade: Visual parecido com o clássico, um pouco mais fácil de fazer, normal para transportar e um pouco mais fácil de guardar.
  • Cocktail: Tem um pouco visual clássico, mais difícil de fazer, difícil de transportar e mais fácil de alocar em casa, fazendo um sucesso em festas também ;).
  • Portable arcade: tem zero de visual clássico, mas para jogadores a fim do jogo, extremamente fácil de fazer, extremamente fácil de transportar e fácil de guardar.

O nano e o mini são iguais, a única questão mesmo é o tamanho e que no caso do nano é mais difícil ter mais jogadores do que um no mesmo arcade…

Poderia explicar o que é cada um, mas imagens são melhores:

Arcade tradicional

Arcade tradicional

Mini arcade

Mini arcade

arcade cocktail

arcade cocktail

portable arcade

portable arcade

Espaço

Essa é a parte mais fácil de se pensar.

Existem 2 momentos a se pensar durante todo o processo, os 2 muito importantes mas não interferem no resto.

Primeiro, onde vai ser montado.

Precisa de um espaço bem maior do que final, além de material e onde trabalhar para fazer o seu arcade. Se você optar por construir tudo do zero, esse espaço ter que lidar com madeira, porque cedo ou tarde você vai ter que fazer alguma alteração na estrutura da carcaça do arcade.

Segundo, o lugar onde vai ficar.

Pode parecer simples, mas tem que ser lembrado que o arcade precisa conseguir entrar no local… Sem contar em sair também, inclusive de onde ele estará sendo montado.

Inclusive, pensando em facilitar o transporte, coloque alças, entradas na carcaça para melhor forma de levantar, ou coisas assim, se alguém pensar em mais algo diz ae.

Fim

E basicamente isso ai que eu lembro e pesquisei. Não existem muitas dicas aqui, é mais a parte que você tem que pensar no básico mesmo.

Próximo post vou falar sobre a carcaça, algumas dicas uteis que eu pesquisei, o que é legar ter, e algumas considerações que eu não coloquei em pratica. Acho legal começar pela carcaça para que o visual do arcade fique bonito, por isso é bom cuidar dessa parte externa antes.

Lembrando que eu ainda não fiz nada, qualquer duvida ou dica eu gostaria de comentassem ai!


Erro screen “Cannot open your terminal ‘/dev/pts/0’ – please check”

Quem nunca passou por esse erro no screen?

"Cannot open your terminal '/dev/pts/0' - please check"

Normalmente, isso ocorre quando você vira um outro usuário na maquina, simplificando, por causa das permissões do terminal que você esta.

Para resolver isso, eu encontrei uma ótima dica, basta fazer:

script /dev/null

E depois executar o comando do screen normalmente.


Sistema Operacional miniOS-0.01: Estrutura de diretórios

Voltei! Dessa vez, para começar e por enquanto, um post mais fácil, pelo menos. Vamos falar sobre a estrutura de diretórios do projeto de um sistema operacional, e o que temos que ter e onde, além de algumas dificuldades que já começou a aparecer.

Certo, vamos mostrar a estrutura de diretórios no geral, e depois eu vou explicar o porque de cada pasta é importante e para que serve, além de levantar umas ideias gerais sobre o futuro do que vai conter em cada uma das pastas.


/src/
/src/compiler/CC
/src/kernel/boot/
/src/kernel/kpp/
/src/kernel/fs/
/src/kernel/arch/
/src/kernel/arch/ISA/
/src/kernel/arch/ISA/PLATFORM
/src/libc/
/tools/

/tools

Esse diretório é o que temos um carinho especial. Aqui vamos colocar as ferramentas que vão nos ajudar a desenvolver nosso sistema operacional, vão facilitar o desenvolvimento, na verdade.

Também vamos colocar alguns programas não relacionados com o kernel em si, pelo menos porque vão ser códigos tão pequenos que não precisam criar repositórios a parte para eles, sendo mas simples deixar ai mesmo.

/src

Aqui vai ficar os códigos relacionados ao kernel, diretamente ao que vai entrar no kernel. Provavelmente, tudo o que vai ser compilado e construido dentro do kernel vai ficar em alguma pasta por aqui.

Na verdade, os códigos não vão ficar aqui, mas em pastas separadas pelas suas funções, como explicado abaixo.

/src/compiler/

Aqui começamos a entrar em detalhes interessantes. Vamos começar com um pequeno conto, o de como um programa normal funciona.

Quando você inicia um programa, você já começa com a sua função main(), certo? Mas quem iniciou as suas variáveis globais? E quem configurou algumas funções? Quem criou os arquivos stdin, stdout e stderr?

Você pode argumentar que tudo isso é função das variáveis globais(por exemplo, stdin, stdout e por ai vai…), mas, isso ainda tem funções especificas que você tem que saber sobre o ambiente para funcionar. Esse tipo de função é de códigos específicos do compilador! No futuro, esses códigos que vamos precisar, vão estar nesse diretório. A medida que precisarmos, eu vou explicando o porque, para que e como vamos precisar disso, então relaxe por enquanto e aceite que precisamos.

Uma coisa a mais a se considerar é que existem vários compiladores, então para cada compilador eu vou precisar de algum código especifico. Essa parte não tem jeito, muita coisa pode ser reusada, mas infelizmente normalmente os codigos são diferentes um dos outros. Para manter separado, vamos criar um diretório também para cada compilador, como por exemplo:


/src/compiler/gcc

Para cada compilador, um diretório. O como vamos usar assim, mais para frente a gente fala(próximo post?).

/src/kernel/

Vamos colocar aqui os códigos especificamente feitos para o kernel. Aqui vai ficar a lógica do kernel e coisas que tem a ver com arquitetura.

/src/kernel/boot/

Precisamos de alguns códigos para inicializar o kernel. Aqui é que ficam esses códigos, aqui é a cola entre o gerenciador de boot e o seu kernel, digamos que a interface, a passagem.

Não confundir com o gerenciadores de boot, que inicializa e carrega o kernel. Isso não é trabalho de um kernel, e não vamos fazer um, então deixa essa parte quieto.

/src/kernel/kpp/

Não podemos contar com nada, ou com muito pouco pelo menos, no desenvolvimento de um kernel. Isso quer dizer que não podemos usar as bibliotecas padrões que normalmente usamos, e isso quer dizer que vamos precisar reimplementar algumas coisas.

Para todas essas coisas que iremos reimplementar de algoritmos básicos(como vector, lista, etc…), vamos colocar nesse diretório.

Sobre o nome do diretório, é as iniciais de kernel plus plus, meio sem sentido mais com sentido…

/src/kernel/fs/

Nada de novo aqui, apenas vai ser o diretório com códigos relacionados ao sistema de arquivo.

Mais no futuro a gente resolve o que vai colocar aqui, principalmente porque não sabemos ainda como vai ser a cara de como lidar com sistema de arquivos.

/src/kernel/arch/

Com certeza vamos precisar utilizar algum código que seja especifico para alguma plataforma, e nesse diretório é que vamos colocar esses códigos que vão depender de alguma arquitetura.

O objetivo é que todos os códigos que dependam de alguma plataforma fiquem aqui, basicamente como eu quero isolar o código em ASM também, gostaria que todos os códigos ficasse aqui.

Mas não é sempre que podemos isolar o código ASM do código em C/C++. Existem alguns códigos de inicialização e alguns outros códigos que precisam ser escritos em ASM para serem mais portáveis ou funcionarem como você quer.

/src/kernel/arch/ISA

Dentro dos códigos mais específicos e em ASM da arquitetura, ainda temos códigos que dependem das informações especificas da ISA da maquina. Essas declarações e códigos vão ficar aqui.

Aqui vai ficar uma parte um pouco chata do trabalho já que também vamos lidar possivelmente com C, que é construir alguns tipos da ISA. pode ser que usemos algumas soluções mais com cara de C++, mas vai ser difícil…

Também temos que ter uma forma de escolher a ISA em que nosso sistema estará compilando. Isso vai fazer parte do sistema de build.

Uma coisa importante a se ressaltar é que o nome “ISA” no nome da pasta vai ser substituído pelo nome da ISA que você esta implementando, porque você pode ter varias implementações. Por exemplo, se você estiver implementando a ISA da arquitetura x86, a pasta seria:


/src/kernel/arch/x86

Isso tudo porque depois vamos usar isso para identificar e configurar a plataforma para onde vamos gerar o nosso kernel.

/src/kernel/arch/ISA/PLATFORM

Aqui ficaram códigos ainda mais específicos das plataformas, como na ISA, só que menos genéricos ainda e mais dependentes do hardware.

É meio difícil de explicar, e fica meio nebulosa a fronteira entre os códigos da ISA e os da plataforma, mas acho que é legal criar essa divisão para aproveitar códigos usados entre plataformas. Talvez seja trabalho demais para pouca coisa também, mas nesse momento não estou ligando para isso.

Assim como no caso da ISA, se estivermos por exemplo implementado a plataforma i386 da ISA x86, faríamos:


/src/kernel/arch/x86/i386

/src/libc/

Uma das piores coisas de se contruir um sistema operacional é que você não tem acesso a praticamente nenhuma ferramente pronta. Isso quer dizer que você mal pode contar com o seu compilador, imagine as bibliotecas basicas de C ou C++.

Para facilitar esse trabalho, de reimplementar todas as bibliotecas, você pode portar algumas bibliotecas. Como a biblioteca basica de C é muito importante, é aqui que teremos os ports de algumas bibliotecas para o nosso sistema.

Porque uma pasta só para isso? Porque o ideal é que possamos trocar a implementação de forma mais fácil, então aqui dentro terremos varias opções que poderão ser escolhidas pelo sistema de build do nosso kernel.

Fim!

Bom, basicamente seria isso ai, essa vai ser a estrutura de diretórios que já adianta alguma coisa para saber o que vamos fazer.

Entrei em vários pontos aqui, mas não falei como eles serão resolvidos, algumas partes porque eu realmente vou explicar melhor isso no futuro, outras porque ainda quero descobrir a melhor forma de resolver.

Mas o mais importante é, se alguem ler isso aqui e alguma duvida surgir, perguntem aqui nos comentários, que eu vou aprimorando cada vez mais o post e também vou tentando responder as duvidas. Tentem não ser tão ansiosos e se concentrar no post de agora!


O melhor editor de Markdown inserível em páginas

Recentemente eu precisei editar mais coisas em Markdown do que o normal e de forma que eu pudesse corrigir a ortografia. Como o meu vim não esta com o corretor ortográfico funcionando de forma satisfatória(tem que instalar o dicionário de pt_BR…), eu pensei em tentar encontrar algum editor on-line para usar o firefox como corretor ortográfico.

Foi ai que eu encontrei o Epic Editor.

Esse editor é de código aberto, serviu para o que eu queria(as caixas de texto são mais simples e adaptáveis que os outros…) e eu posso usar em qualquer lugar(usar embed). Muito bom, tudo em JavaScript e com processamento em client side.


%d bloggers like this: