... e la se foi meu limite do CC :P
Sério... essas promoções me deixam pobre =/
*TUDO* esta com um desconto de 10% a 75%.
O que eu ja comprei até agora:
FlatOut 1, 2 e Ultimate Carnage == 18 dólares.
Dawn of War Complete Pack = 30 dólares(custa 70 normalmente... =X)
UT3 = 10 dólares\o/
Mass Effect = 27 dólares
Portal = 5 dólares
Total: 90 dólares aproximadamente =X
E ainda tem outros 3 que estou pensando em comprar:
Stalker Clear Sky a 18 dólares, desconto de 50% em relação ao preço normal!
Quake Wars = 15 dólares.
Frontlines = 23 dólares.
World in Conflict = 23 dólares.
Eu até pensei no Crysis Pack (54 dólares) e no Far Cry 2 (38 dólares)... mas calma... estes estão mais caros (e nem valem *tanto* a pena assim comparados com os preços aqui no Brasil) e provavelmente não terei tempo para jogar tanta coisa assim :P
Para quem quiser o Team Fortress 2 e/ou o CS:Source, ótima hora, os dois estão apenas 10 dólares! =]
Para mais informações e destaque, visitem o site do Steam aqui:
http://store.steampowered.com/holidaysale
(Não, não estou ganhando nada por isso :P)
sábado, 27 de dezembro de 2008
Hacking Exposed: Computer Forensics
Yep... consegui terminar de ler mais um livro antes de acabar o ano :P
Este não será uma resenha nem um resumo muito longo... porque estou meio que desapontado com o livro.
Ok, o livro foi publicado no final de Nov de 2004. Acho que livros de segurança, hoje, estão ficando desatualizados muito rapidamente. Mas não foi isso que me incomodou, pois seria o mesmo caso do livro de Buffer Overflow, que apesar de não ser nenhum espetáculo, acabei aprendendo umas coisas bem legais.
O site do livro, por exemplo, nem existe mais. Acho isso um vacilo muito grande por parte da editora e dos autores.
Os 3 primeiros capítulos formas a parte 1 - e introdutória - do livro.
O primeiro capítulo, diz o que é uma análise forense, os passos normalmente tomados, tudo que tem de ser feito, desde o registro (para documentação posterior), coleta das evidências e finalmente a análise... bem básico.
O segundo capítulo explica coisas básicas como o que é a BIOS, tipos de mídia: hds, cds, disquete, fitas, etc... Até tem umas coisinhas interessantes... mas nada que realmente seja ligado a segurança, está mais para "conhecimentos gerais".
Capítulo 3 discute o que deve ser e como de ver um laboratório de investigação forense. Até aqui está bem interessante... mas bem básico. Ele fala sobre toda a segurança que você precisa ter, para não deixar pessoas não autorizadas entrarem por exemplo.
Agora começamos a parte 2.
O capítulo 4, trata da coleta da evidência.
O capítulo 5, fala sobre investigação remota.
Fala sobre como devem ser feitos, explicam algumas coisas... falam que deve ser feito o hash dos arquivos coletados, blablabla...
No mais, demonstra como fazer tudo utilizando ferramentas, tipo EnCase e algumas outras. (Quase sempre comerciais)
Parte 3:
Capítulo 6: Forense em ambiente Windows
Capítulo 7: Forense em ambiente Linux
Capítulo 8: Forense em ambiente MacOS
A parte mais interessante dos 3 capítulos é quando são discutidos os sistemas de arquivos mais utilizados nos 3 SOs.
Tirando isso, é somente mais uma longa sequencia de "como fazer isso usando a ferramenta XXX"... e normalmente a ferramenta é a EnCase.
Capítulo 9: Técnicas anti-forenses.
Aqui pode ser interessante para os investigadores terem uma noção de problemas que podem ter... como criptografia, estenografia, limpeza de disco (gravando bytes aleatórios diversas vezes por todo o disco)...
Capítulo 10: Análise em Storage em empresas.
Basicamente fala sobre RAID e fitas.
Capítulo 11: Análise de e-mail:
Fala sobre como abrir arquivos .pst (outlook), .dbx (outlook express), formato padrão de mailbox do unix, Netscape/Mozilla e AOL (WTF?!), Hotmail e Yahoo!.
No final, 2 páginas sobre cabeçalhos de e-mail... muito básico.
Capítulo 12: Rastreando as atividades dos usuários.
Fala sobre cookies e o cache dos browsers. E sobre meta-dados em documentos office.
[Aqui eu ja estava de saco cheio e comecei a ler as coisas com leitura dinâmica... ou seja... 4 pagina no tempo de 1]
Capítulo 13: Análise de PDAs e Celulares.
Esse é o capítulo "ultra novidade" deste livro... e a idéia é boa! Quem hoje não tem um celular que lava, passa e cozinha? (Só não liga quando é preciso :P).
Mas novamente é somente um "how-to" de ferramentas... PDA/Cell Seizure da Paraben e da EnCase. Desculpem... mas fiquei completamente de saco cheio.
A última parte, tenta mostrar tipos de relatórios (internos, para a justiça, etc...) e depois como o sistema de justiça dos EUA funciona. Interessante... pelo menos eles não falaram mais da EnCase aqui.
Depois temos os apêndices:
Apêndice A: Alguns formulários e checklists, para serem usados ou servirem como base para criação de outros.
Apêndice B: Consequências legais. Basicamente descreve um caso que foi a justiça.
Apêndice C: Fala sobre as leis (dos EUA) sobre o tratamento de evidências.
Apêndice D: RegExp básico em 4 páginas.
Apêndice E: Ferramentas que deverias estar no toolkit de um investigados. Diversas ferramentas... algumas livres, outras comerciais...
E pronto, é isso.
Se alguém ainda não entendeu minha frustração com o livro eu posso resumir em 1 linha:
O livro poderia se chamar "EnCase for Dummies" ;)
Infelizmente o modo do livro ser escrito, que em 90% é apenas "fazendo isso com *essa* ferramenta" me desmotivou muito a ler.
Apenas segui em frente pois queria acabar ele de uma vez.
Não recomendo o livro mesmo...
Este não será uma resenha nem um resumo muito longo... porque estou meio que desapontado com o livro.
Ok, o livro foi publicado no final de Nov de 2004. Acho que livros de segurança, hoje, estão ficando desatualizados muito rapidamente. Mas não foi isso que me incomodou, pois seria o mesmo caso do livro de Buffer Overflow, que apesar de não ser nenhum espetáculo, acabei aprendendo umas coisas bem legais.
O site do livro, por exemplo, nem existe mais. Acho isso um vacilo muito grande por parte da editora e dos autores.
Os 3 primeiros capítulos formas a parte 1 - e introdutória - do livro.
O primeiro capítulo, diz o que é uma análise forense, os passos normalmente tomados, tudo que tem de ser feito, desde o registro (para documentação posterior), coleta das evidências e finalmente a análise... bem básico.
O segundo capítulo explica coisas básicas como o que é a BIOS, tipos de mídia: hds, cds, disquete, fitas, etc... Até tem umas coisinhas interessantes... mas nada que realmente seja ligado a segurança, está mais para "conhecimentos gerais".
Capítulo 3 discute o que deve ser e como de ver um laboratório de investigação forense. Até aqui está bem interessante... mas bem básico. Ele fala sobre toda a segurança que você precisa ter, para não deixar pessoas não autorizadas entrarem por exemplo.
Agora começamos a parte 2.
O capítulo 4, trata da coleta da evidência.
O capítulo 5, fala sobre investigação remota.
Fala sobre como devem ser feitos, explicam algumas coisas... falam que deve ser feito o hash dos arquivos coletados, blablabla...
No mais, demonstra como fazer tudo utilizando ferramentas, tipo EnCase e algumas outras. (Quase sempre comerciais)
Parte 3:
Capítulo 6: Forense em ambiente Windows
Capítulo 7: Forense em ambiente Linux
Capítulo 8: Forense em ambiente MacOS
A parte mais interessante dos 3 capítulos é quando são discutidos os sistemas de arquivos mais utilizados nos 3 SOs.
Tirando isso, é somente mais uma longa sequencia de "como fazer isso usando a ferramenta XXX"... e normalmente a ferramenta é a EnCase.
Capítulo 9: Técnicas anti-forenses.
Aqui pode ser interessante para os investigadores terem uma noção de problemas que podem ter... como criptografia, estenografia, limpeza de disco (gravando bytes aleatórios diversas vezes por todo o disco)...
Capítulo 10: Análise em Storage em empresas.
Basicamente fala sobre RAID e fitas.
Capítulo 11: Análise de e-mail:
Fala sobre como abrir arquivos .pst (outlook), .dbx (outlook express), formato padrão de mailbox do unix, Netscape/Mozilla e AOL (WTF?!), Hotmail e Yahoo!.
No final, 2 páginas sobre cabeçalhos de e-mail... muito básico.
Capítulo 12: Rastreando as atividades dos usuários.
Fala sobre cookies e o cache dos browsers. E sobre meta-dados em documentos office.
[Aqui eu ja estava de saco cheio e comecei a ler as coisas com leitura dinâmica... ou seja... 4 pagina no tempo de 1]
Capítulo 13: Análise de PDAs e Celulares.
Esse é o capítulo "ultra novidade" deste livro... e a idéia é boa! Quem hoje não tem um celular que lava, passa e cozinha? (Só não liga quando é preciso :P).
Mas novamente é somente um "how-to" de ferramentas... PDA/Cell Seizure da Paraben e da EnCase. Desculpem... mas fiquei completamente de saco cheio.
A última parte, tenta mostrar tipos de relatórios (internos, para a justiça, etc...) e depois como o sistema de justiça dos EUA funciona. Interessante... pelo menos eles não falaram mais da EnCase aqui.
Depois temos os apêndices:
Apêndice A: Alguns formulários e checklists, para serem usados ou servirem como base para criação de outros.
Apêndice B: Consequências legais. Basicamente descreve um caso que foi a justiça.
Apêndice C: Fala sobre as leis (dos EUA) sobre o tratamento de evidências.
Apêndice D: RegExp básico em 4 páginas.
Apêndice E: Ferramentas que deverias estar no toolkit de um investigados. Diversas ferramentas... algumas livres, outras comerciais...
E pronto, é isso.
Se alguém ainda não entendeu minha frustração com o livro eu posso resumir em 1 linha:
O livro poderia se chamar "EnCase for Dummies" ;)
Infelizmente o modo do livro ser escrito, que em 90% é apenas "fazendo isso com *essa* ferramenta" me desmotivou muito a ler.
Apenas segui em frente pois queria acabar ele de uma vez.
Não recomendo o livro mesmo...
quinta-feira, 25 de dezembro de 2008
Lembrem: SEMPRE salvem seus jogos!
E não confiem no AutoSave -_-'
Ja é a segunda vez que acontece...
A 1 mês atrás foi com o Fallout 3.
Estava lá eu, n00b, jogando feliz meu Fallout 3 novo... bem no início em Megaton, quando sem querer eu aperto 'E' numa parada na Church of Atom que seria considerado crime.
Puta que pariu! Veio a cidade inteira atras de mim, até a porra da velha que não fazia porra nenhuma queria me dar umas paneladas! -_-'
Eu poderia tentar matar todo mundo (improvável)...
Mas pô... eu queria fazer as quests da cidade caramba.
Foi sem querer CARALHO! Não dava pra me dar uma multa? 50 flexões e 200 abdominais?
Holy shit...
Depois fui dar loadgame... e descobri que:
a) Meu savegame estava *beeem* velho.
b) O autosave, salvou depois que eu fiz a merda -_-'
WTF essa porra de autosave?!
Ok, passado o trauma do Fallout 3 e sempre salvando...
Nesta segunda comprei o Stalker (o primeiro... Shadow of Chernobyl) por 5 dolares no Steam! Whohoooooooooooo!
Vamos jogar...
Estou eu la n00bzão no jogo como sempre...
Ai depois de fazer uns 3 ou 4 jobs eu abro meu inventário e vejo la um daqueles bagulhos radioativos que você pode equipar e te da um boost na resistência a alguma coisa.
Po, ai o jogo me avisa que maneiro, aquilo gera uma radioatividade nociva pro seu corpo e vc tem que tomar um remedinho lá pra ficar tudo nos trinks... beleza... desequipo a parada e volto pro inventário, pq como em todo jogo que sou n00b leio a descrição de cada item até do "pão fresquinho" que achei num defunto.
Quando começa um beep-beep... ai... eu saio do inventário, vejo a porra da barrinha da vida com menos de 1 px cheio e ai morro e me vem um GAME OVER na cara -_-'
OMFG!!!!!!!!!! Puta que pariu!!!!
Tipo.... WTF MAN!?
Ok, ok... aceitei minha n00bice e fui dar load no save game.
Well... meu ultimo save game foi antes de completar esses 3 ou 4 jobs do jogo.
Ai caralho...
Ok, tinha um savegame la chamado "all" que é o que vai salvando pra você enquanto você ainda não tem um save específico do seu jogo.
Eu entendi que essa joça salvava sozinha... alem disso, volta e meia aparece um disquete piscando no canto inferior direito da tela. Se isso não for indicação de auto-save, é sacanagem!
Enfim... mefu de novo, la vou eu fazer os 4 jobs de novo... sorte que estou relativamente bem no início. E agora lembrando de salvar depois de cada passo, cada tiro disparado...
E sempre uns 10 saves diferentes... vai que eu me arrependo de algo que fiz né...
Ja é a segunda vez que acontece...
A 1 mês atrás foi com o Fallout 3.
Estava lá eu, n00b, jogando feliz meu Fallout 3 novo... bem no início em Megaton, quando sem querer eu aperto 'E' numa parada na Church of Atom que seria considerado crime.
Puta que pariu! Veio a cidade inteira atras de mim, até a porra da velha que não fazia porra nenhuma queria me dar umas paneladas! -_-'
Eu poderia tentar matar todo mundo (improvável)...
Mas pô... eu queria fazer as quests da cidade caramba.
Foi sem querer CARALHO! Não dava pra me dar uma multa? 50 flexões e 200 abdominais?
Holy shit...
Depois fui dar loadgame... e descobri que:
a) Meu savegame estava *beeem* velho.
b) O autosave, salvou depois que eu fiz a merda -_-'
WTF essa porra de autosave?!
Ok, passado o trauma do Fallout 3 e sempre salvando...
Nesta segunda comprei o Stalker (o primeiro... Shadow of Chernobyl) por 5 dolares no Steam! Whohoooooooooooo!
Vamos jogar...
Estou eu la n00bzão no jogo como sempre...
Ai depois de fazer uns 3 ou 4 jobs eu abro meu inventário e vejo la um daqueles bagulhos radioativos que você pode equipar e te da um boost na resistência a alguma coisa.
Po, ai o jogo me avisa que maneiro, aquilo gera uma radioatividade nociva pro seu corpo e vc tem que tomar um remedinho lá pra ficar tudo nos trinks... beleza... desequipo a parada e volto pro inventário, pq como em todo jogo que sou n00b leio a descrição de cada item até do "pão fresquinho" que achei num defunto.
Quando começa um beep-beep... ai... eu saio do inventário, vejo a porra da barrinha da vida com menos de 1 px cheio e ai morro e me vem um GAME OVER na cara -_-'
OMFG!!!!!!!!!! Puta que pariu!!!!
Tipo.... WTF MAN!?
Ok, ok... aceitei minha n00bice e fui dar load no save game.
Well... meu ultimo save game foi antes de completar esses 3 ou 4 jobs do jogo.
Ai caralho...
Ok, tinha um savegame la chamado "all" que é o que vai salvando pra você enquanto você ainda não tem um save específico do seu jogo.
Eu entendi que essa joça salvava sozinha... alem disso, volta e meia aparece um disquete piscando no canto inferior direito da tela. Se isso não for indicação de auto-save, é sacanagem!
Enfim... mefu de novo, la vou eu fazer os 4 jobs de novo... sorte que estou relativamente bem no início. E agora lembrando de salvar depois de cada passo, cada tiro disparado...
E sempre uns 10 saves diferentes... vai que eu me arrependo de algo que fiz né...
Feliz natal! Ho-ho-ho!
Eu tenho estado meio sumido... mas é apenas por preguiça de postar aqui mesmo :P
A 2 semanas atrás estava correndo para terminar os últimos trabalhos da faculdade (mesmo com o período letivo acadêmico ja tendo encerrado :P) e uma última prova no dia 18...
Depois fiz uma viagem a Arraial do Cabo, que simplesmente pode ser descrita como "fodapracaralho", com amigos que também são "fodapracaralho" =]
Afinal, sem eles não haveria tanta graça... assim como não teríamos coisas como competição de comer sopa (com handcap :P) e "hipertensão? créééééu!" :P
Vamos ver se dessa vez eu coloco as fotos aqui no blog :P
Voltando... ontem eu fiz um pouquinho de grind e upei pro lvl 21... não sei ainda onde vou distribuir minhas skill points. Tenho que pensar direito, porque do jeito que sou n00b nesse jogo, só vou upar de novo daqui a uns 365 dias =]
Tenho feito basicamente ficar lendo random coisas na internet e olhando o Bugzilla do Gentoo :P
Dei uma parada nos livros que eu estava lendo... fico basicamente jogando TF2/CS:S/Outro jogos aqui.
Falando em jogos... estou aqui sentado esperando a Valve começar a promoção de natal no Steam :P
E falando em livros... essa alta do dólar ta me fudendo aspira... é desanimador comprar livros a 2.40, depois de ter comprado a 1.60~1.70 =/
Vale notar que ontem saiu o Linux 2.6.28 (e dessa vez eu não vou fazer resumo - sry - quem quiser dar uma olhada, a página do KernelNewbies ta bem legal). Com isso a janela de merge foi aberta... o Ingo acordou cedo hoje e ja começou a mandar uns changesets gigantes por exemplo...
Saiu o GIT 1.6.1 também.
(Só to falando o que chega até minha inbox :P)
Bem, acho que é isso. Até o final do ano eu vou fazer um diff com relação ao post das coisas que eu queria ter feito este ano e vamos ver como eu me saí :P
A 2 semanas atrás estava correndo para terminar os últimos trabalhos da faculdade (mesmo com o período letivo acadêmico ja tendo encerrado :P) e uma última prova no dia 18...
Depois fiz uma viagem a Arraial do Cabo, que simplesmente pode ser descrita como "fodapracaralho", com amigos que também são "fodapracaralho" =]
Afinal, sem eles não haveria tanta graça... assim como não teríamos coisas como competição de comer sopa (com handcap :P) e "hipertensão? créééééu!" :P
Vamos ver se dessa vez eu coloco as fotos aqui no blog :P
Voltando... ontem eu fiz um pouquinho de grind e upei pro lvl 21... não sei ainda onde vou distribuir minhas skill points. Tenho que pensar direito, porque do jeito que sou n00b nesse jogo, só vou upar de novo daqui a uns 365 dias =]
Tenho feito basicamente ficar lendo random coisas na internet e olhando o Bugzilla do Gentoo :P
Dei uma parada nos livros que eu estava lendo... fico basicamente jogando TF2/CS:S/Outro jogos aqui.
Falando em jogos... estou aqui sentado esperando a Valve começar a promoção de natal no Steam :P
E falando em livros... essa alta do dólar ta me fudendo aspira... é desanimador comprar livros a 2.40, depois de ter comprado a 1.60~1.70 =/
Vale notar que ontem saiu o Linux 2.6.28 (e dessa vez eu não vou fazer resumo - sry - quem quiser dar uma olhada, a página do KernelNewbies ta bem legal). Com isso a janela de merge foi aberta... o Ingo acordou cedo hoje e ja começou a mandar uns changesets gigantes por exemplo...
Saiu o GIT 1.6.1 também.
(Só to falando o que chega até minha inbox :P)
Bem, acho que é isso. Até o final do ano eu vou fazer um diff com relação ao post das coisas que eu queria ter feito este ano e vamos ver como eu me saí :P
quinta-feira, 4 de dezembro de 2008
Meu primeiro bugreport no Bugzilla do Gentoo *___*
Sempre dizem que o bom filho a casa torna (ou retorna, não sei :P).
Então, aqui vou eu =D
E hoje, enviei meu primeiro bug-report ao bugzilla do gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=249878
Basicamente foi um repasse de uma falha que vi na Secunia.
Uma falha no rsyslog que afetas as duas versões que estão na árvore do portage, tanto a 3.18.4 (v-3 stable) quanto a 3.21.6 (v-3 beta).
Foram lançadas as versões 3.20.1 e 3.21.8 que corrigiram um bug de bypass descrito aqui:
http://www.rsyslog.com/Article322.phtml
Logo em seguida, estas duas versões foram retiradas do ar, e foram colocadas 2 outras a 3.20.2 e a 3.21.9 que corrigiam um DoS.
Aqui esta o anúncio da 3.20.2:
http://www.rsyslog.com/Article324.phtml
E aqui o da 3.21.9:
http://www.rsyslog.com/Article327.phtml
Foi bem legal reportar o bug, e o Stupendoussteve do canal #gentoo-security me ajudou pra caramba... espero que ninguém que siga a security@gentoo.org fique *muito* puto por 1 ou 2 edits a mais que tive que fazer :P
Na verdade eu voltei a acompanhar o bugzilla mais por causa do KernelTeam do Gentoo... estão precisando mais de gente do que o SecurityTeam. Mas nada impede que eu tente ajudar os dois e foi um bom para me acostumar com o funcionamento do Bugzilla =D
Será que o primeiro bug report, a gente nunca esquece? :P
Então, aqui vou eu =D
E hoje, enviei meu primeiro bug-report ao bugzilla do gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=249878
Basicamente foi um repasse de uma falha que vi na Secunia.
Uma falha no rsyslog que afetas as duas versões que estão na árvore do portage, tanto a 3.18.4 (v-3 stable) quanto a 3.21.6 (v-3 beta).
Foram lançadas as versões 3.20.1 e 3.21.8 que corrigiram um bug de bypass descrito aqui:
http://www.rsyslog.com/Article322.phtml
Logo em seguida, estas duas versões foram retiradas do ar, e foram colocadas 2 outras a 3.20.2 e a 3.21.9 que corrigiam um DoS.
Aqui esta o anúncio da 3.20.2:
http://www.rsyslog.com/Article324.phtml
E aqui o da 3.21.9:
http://www.rsyslog.com/Article327.phtml
Foi bem legal reportar o bug, e o Stupendoussteve do canal #gentoo-security me ajudou pra caramba... espero que ninguém que siga a security@gentoo.org fique *muito* puto por 1 ou 2 edits a mais que tive que fazer :P
Na verdade eu voltei a acompanhar o bugzilla mais por causa do KernelTeam do Gentoo... estão precisando mais de gente do que o SecurityTeam. Mas nada impede que eu tente ajudar os dois e foi um bom para me acostumar com o funcionamento do Bugzilla =D
Será que o primeiro bug report, a gente nunca esquece? :P
Calendários do Advento Natalino
Perl-Mode-On ;)
Muito legal essa idéia e tem *muitas* dicas boas!
Aqui vai o e-mail original enviado pelo Breno para a lista RioPM:
"O calendário Perl do advento natalino é uma tradição na comunidade
desde o ano 2000. A idéia é apresentar um módulo bacana (para qualquer
definição de "bacana") do CPAN em cada dia de dezembro que antecede o
Natal.
O desse ano já está no ar!
http://perladvent.pm.org/2008/
O dia 1 fala do ToolSet, um módulo que agrega todos os seus módulos
mais usados em um único import, evitando assim o "ctrl-c/ctrl-v".
Dia 2 fala de um módulo que eu particularmente acho o maior barato, o
Math::Prime::TiedArray, que cria um array virtual com todos os números
primos.Todos?! Todos. Afinal, é um array virtual, ele computa o número
primo que ocupa a posição desejada conforme a demanda ;-)
Fiquem atentos ao site oficial do calendário! Quem tiver curiosidade é
só olhar o histórico para os outros anos, e se vc acha que seu [insira
módulo xodó aqui] está sendo injustiçado por não ter sido apresentado
até hoje, escreva para eles! O pessoal do calendário está sempre atrás
de idéias (e escritores!!!!!)
Finalmente, mas não menos importante, já saiu também o calendário
Catalyst do advento natalino, que desde 2005 complementa o calendário
do Perl com dicas e módulos específicos para o Catalyst!
http://www.catalystframework.org/calendar/2008/
O dia 1 apresenta as estatísticas da pesquisa de Catalyst (que
circulou inclusive pela lista, infelizmente apenas 2 brasileiros
responderam).
Dia 2 mostra as diferentes formas de se implantar o Catalyst em
servidores Web (servidor built-in, mod_perl, fastcgi, etc)
O dia 3 apresenta um módulo bonitão que já mencionei por aqui, o
Chart::Clicker, e como usá-lo junto com o Catalyst para exibir páginas
com gráficos informativos.
Como sempre, é possível ver calendários de anos anteriores, e eles
também adoram voluntários!
[]s, e boas festas ;-)
-b"
Muito legal essa idéia e tem *muitas* dicas boas!
Aqui vai o e-mail original enviado pelo Breno para a lista RioPM:
"O calendário Perl do advento natalino é uma tradição na comunidade
desde o ano 2000. A idéia é apresentar um módulo bacana (para qualquer
definição de "bacana") do CPAN em cada dia de dezembro que antecede o
Natal.
O desse ano já está no ar!
http://perladvent.pm.org/2008/
O dia 1 fala do ToolSet, um módulo que agrega todos os seus módulos
mais usados em um único import, evitando assim o "ctrl-c/ctrl-v".
Dia 2 fala de um módulo que eu particularmente acho o maior barato, o
Math::Prime::TiedArray, que cria um array virtual com todos os números
primos.Todos?! Todos. Afinal, é um array virtual, ele computa o número
primo que ocupa a posição desejada conforme a demanda ;-)
Fiquem atentos ao site oficial do calendário! Quem tiver curiosidade é
só olhar o histórico para os outros anos, e se vc acha que seu [insira
módulo xodó aqui] está sendo injustiçado por não ter sido apresentado
até hoje, escreva para eles! O pessoal do calendário está sempre atrás
de idéias (e escritores!!!!!)
Finalmente, mas não menos importante, já saiu também o calendário
Catalyst do advento natalino, que desde 2005 complementa o calendário
do Perl com dicas e módulos específicos para o Catalyst!
http://www.catalystframework.org/calendar/2008/
O dia 1 apresenta as estatísticas da pesquisa de Catalyst (que
circulou inclusive pela lista, infelizmente apenas 2 brasileiros
responderam).
Dia 2 mostra as diferentes formas de se implantar o Catalyst em
servidores Web (servidor built-in, mod_perl, fastcgi, etc)
O dia 3 apresenta um módulo bonitão que já mencionei por aqui, o
Chart::Clicker, e como usá-lo junto com o Catalyst para exibir páginas
com gráficos informativos.
Como sempre, é possível ver calendários de anos anteriores, e eles
também adoram voluntários!
[]s, e boas festas ;-)
-b"
domingo, 30 de novembro de 2008
GCC -Wpadded e alinhamento de dados em uma struct
Estou lendo a documentação do GCC (sim... só por esporte) sobre as opções de warning e entre umas e outras que quero testar (mas tenho que antes ler sobre as outras flags). Então agora vou falar sobre a -Wpadded.
Basicamente, ela diz ao GCC para imprimir warnings quando for necessário fazer padding para ajustar o alinhamento de alguma struct.
(Para dúvidas do que seria o alinhamento na memória: http://en.wikipedia.org/wiki/Data_structure_alignment)
Por exemplo:
Quando compilo com -Wpadded, ele avisa:
$ gcc -o struct_align.o struct_align.c -Wpadded
struct_align.c:4: warning: padding struct to align ‘res’
struct_align.c:6: warning: padding struct size to alignment boundary
Ou seja... ele teve que fazer um padding (basicamente, encher com 0 ou porcarias que não serão utilizadas) a região entre bchar[2] e res, para poder deixar res alinhado.
E novamente, teve que fazer um padding no final, para deixar a struct toda (o final dela) alinhada.
Para comprovar isto, vamos ver que através do sizeof() vamos pegar o tamanho dos dados:
Epa!
A struct era para ter 1 int, 2 vetores de 2 chars cada e 1 double.
Logo o total deveria ser 1x4 + 2x2x1 + 1x8 = 16 bytes.
Mas por que essa joça ficou ocupando 20 bytes? Exatamente por causa do padding.
Vamos criar um mapa de como a struct deveria ficar na memória, se não houvesse o padding:
(Vamos supor que nossa memória começa no 0x0000)
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0006 - res
0x000E - bcode[0]
0x000F - bcode[1]
Ou seja, num diagrama ficaria algo assim:
Eu tentei fazer o diagrama de modo a simplificar, com cada linha contendo 4 bytes, ou seja 32 bits... o tamanho de uma palavra de dados de um processador de 32 bits (ou um de 64 operando em modo de 32 ;).
Mas como dito antes (veja o link para a wikipedia mais acima), os dados devem estar alinhados na struct, de acordo com o maior (que ocupa mais espaço) tipo de dados utilizado na struct, então o GCC insere um padding, logo ficamos assim:
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0008 - res
0x0010 - bcode[0]
0x0011 - bcode[1]
E assim no diagrama:
Até aqui temos 18 bytes utilizados (16 que queremos e 2 de padding).
Então, o GCC preenche os 2 bytes finais também (ver OBS1 no final):
Logo, temos uma estrutura que utiliza 20 bytes, quando realmente desejamos utilizar 16... isso é um overhead de 25%!
Para corrigir este tipo de problema é simples, vamos agrupar os dados que estão quebrando o alinhamento, ou seja, nesse caso vamos deixar os dois vetores de char juntos:
Poderíamos também ter movido o bcode[] para antes do res... os dois modos irão arrumar o alinhamento da struct e com isso ela passará a ocupar os 16 bytes que desejávamos. Porém eu pessoalmente acho melhor colocar todos os char[] no final, pois se desejarmos alterar o tamanho de algum deles, não teremos que nos preocupar em reorganizar tudo.
Bem... espero que tenham gostado... e pensar que escrevi isso tudo, pois só queria comentar sobre a opção -Wpadded que não é ativada pelo -Wall nem pelo -Wextra :P
Para quem quiser, estou disponibilizando um fonte (struct_align.c) aqui:
http://www.dcc.ufrj.br/~brunobuss/code/struct_align.c
Todas os testes foram feitos com a seguinte versão do GCC:
$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
OBS1:
Naquele caso, o gcc preencheu o final da struct, pois na mesma tínhamos dados que eram alinhados em 4 bytes (ou múltiplos de 4 bytes), em um caso de uma struct do tipo:
O GCC não irá incluir nenhum padding, pois não será necessário alinhar a estrutura. Logo esta struct irá ocupar 9 bytes como esperado.
Porem, caso tenhamos:
O GCC irá fazer padding no final da struct para alinha-la com o short, ou seja... caso o tamanho de b, não seja múltiplo de 2 (short == 2 bytes), então o GCC irá colocar um byte a mais para o alinhamento.
Basicamente, ela diz ao GCC para imprimir warnings quando for necessário fazer padding para ajustar o alinhamento de alguma struct.
(Para dúvidas do que seria o alinhamento na memória: http://en.wikipedia.org/wiki/Data_structure_alignment)
Por exemplo:
typedef struct _mystruct{
int tam;
char bchar[2];
double res;
char bcode[2];
} mystruct;Quando compilo com -Wpadded, ele avisa:
$ gcc -o struct_align.o struct_align.c -Wpadded
struct_align.c:4: warning: padding struct to align ‘res’
struct_align.c:6: warning: padding struct size to alignment boundary
Ou seja... ele teve que fazer um padding (basicamente, encher com 0 ou porcarias que não serão utilizadas) a região entre bchar[2] e res, para poder deixar res alinhado.
E novamente, teve que fazer um padding no final, para deixar a struct toda (o final dela) alinhada.
Para comprovar isto, vamos ver que através do sizeof() vamos pegar o tamanho dos dados:
Sizes:
-int = 4
-char = 1
-double = 8
-mystruct = 20
Epa!
A struct era para ter 1 int, 2 vetores de 2 chars cada e 1 double.
Logo o total deveria ser 1x4 + 2x2x1 + 1x8 = 16 bytes.
Mas por que essa joça ficou ocupando 20 bytes? Exatamente por causa do padding.
Vamos criar um mapa de como a struct deveria ficar na memória, se não houvesse o padding:
(Vamos supor que nossa memória começa no 0x0000)
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0006 - res
0x000E - bcode[0]
0x000F - bcode[1]
Ou seja, num diagrama ficaria algo assim:
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | res | res |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | bcode[0] | bcode[1] |
|----------------------------------------------------|
| 0x0010 | ........................................ |
|----------------------------------------------------|
Eu tentei fazer o diagrama de modo a simplificar, com cada linha contendo 4 bytes, ou seja 32 bits... o tamanho de uma palavra de dados de um processador de 32 bits (ou um de 64 operando em modo de 32 ;).
Mas como dito antes (veja o link para a wikipedia mais acima), os dados devem estar alinhados na struct, de acordo com o maior (que ocupa mais espaço) tipo de dados utilizado na struct, então o GCC insere um padding, logo ficamos assim:
0x0000 - tam
0x0004 - bchar[0]
0x0005 - bchar[1]
0x0008 - res
0x0010 - bcode[0]
0x0011 - bcode[1]
E assim no diagrama:
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | res | res |
|----------------------------------------------------|
| 0x0010 | bcode[0] | bcode[1] | ............... |
|----------------------------------------------------|
Até aqui temos 18 bytes utilizados (16 que queremos e 2 de padding).
Então, o GCC preenche os 2 bytes finais também (ver OBS1 no final):
|----------------------------------------------------|
| END | BYTE0 | BYTE1 | BYTE2 | BYTE3 |
|----------------------------------------------------|
| 0x0000 | tam | tam | tam | tam |
|----------------------------------------------------|
| 0x0004 | bchar[0] | bchar[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0008 | res | res | res | res |
|----------------------------------------------------|
| 0x000C | res | res | res | res |
|----------------------------------------------------|
| 0x0010 | bcode[0] | bcode[1] | PAD | PAD |
|----------------------------------------------------|
| 0x0014 | ....................................... |
|----------------------------------------------------|
Logo, temos uma estrutura que utiliza 20 bytes, quando realmente desejamos utilizar 16... isso é um overhead de 25%!
Para corrigir este tipo de problema é simples, vamos agrupar os dados que estão quebrando o alinhamento, ou seja, nesse caso vamos deixar os dois vetores de char juntos:
typedef struct _mystruct_fixed{
int tam;
double res;
char bchar[2];
char bcode[2];
} mystruct_fixed;
Poderíamos também ter movido o bcode[] para antes do res... os dois modos irão arrumar o alinhamento da struct e com isso ela passará a ocupar os 16 bytes que desejávamos. Porém eu pessoalmente acho melhor colocar todos os char[] no final, pois se desejarmos alterar o tamanho de algum deles, não teremos que nos preocupar em reorganizar tudo.
Bem... espero que tenham gostado... e pensar que escrevi isso tudo, pois só queria comentar sobre a opção -Wpadded que não é ativada pelo -Wall nem pelo -Wextra :P
Para quem quiser, estou disponibilizando um fonte (struct_align.c) aqui:
http://www.dcc.ufrj.br/~brunobuss/code/struct_align.c
Todas os testes foram feitos com a seguinte versão do GCC:
$ gcc --version
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
OBS1:
Naquele caso, o gcc preencheu o final da struct, pois na mesma tínhamos dados que eram alinhados em 4 bytes (ou múltiplos de 4 bytes), em um caso de uma struct do tipo:
typedef struct _mycharstruct{
char bchar[5];
char bcode[4];
} mycharstruct;
O GCC não irá incluir nenhum padding, pois não será necessário alinhar a estrutura. Logo esta struct irá ocupar 9 bytes como esperado.
Porem, caso tenhamos:
typedef struct _myshortcharstruct{
short a;
char b[1];
} myshortcharstruct;
O GCC irá fazer padding no final da struct para alinha-la com o short, ou seja... caso o tamanho de b, não seja múltiplo de 2 (short == 2 bytes), então o GCC irá colocar um byte a mais para o alinhamento.
Assinar:
Postagens (Atom)
