Search raisama.net:
raisama.netThis is a personal blog. You may find content in english and in portuguese here.
Este é um blog pessoal. Há conteúdo em português e em inglês.
Eduardo Habkost, software developer.
Os slides da palestra estão em: http://raisama.net/talks/ovirt-2009/slides.pdf.
Para visualização online, também estão disponíveis no Slideshare.
Comente!Vou tentar fazer um rant curto.
Durante o FISL 10, me convenci que os palestrantes e voluntários (isso inclui a mim) são trouxas que tem apenas uma função: aumentar o público do evento para ajudar no sucesso das campanhas políticas promovidas pelos seus organizadores.
O evento não foi completamente ruim. O conteúdo das palestras técnicas estava excelente. O ponto é que ficou claro pra mim que a qualidade das palestras é apenas um efeito colateral. Os voluntários e palestrantes ajudam a montar o FISL, mas os “donos” do FISL não são eles.
Os donos do FISL são os que recebem o dinheiro de empresas privadas e estatais, mas não têm interesse algum em demonstrar para onde o dinheiro vai. São eles que definem o discurso utilizado, qual o conteúdo do site do evento, o que dizem os releases para a imprensa. Os donos do FISL são quem define se vão fechar o evento para o PT fazer campanha política, e se software livre será associado a anti-capitalismo e anti-copyright.
Eu não sou ingênuo para esperar que política fique totalmente de fora de qualquer grupo que reúna mais que 6 pessoas. Política é um efeito colateral difícil de evitar. A questão é se a política é apenas um efeito colateral chato (como eu imaginava que seria) ou um fim (como se demonstrou ser).
[Update 02/07/2009 18:40: muita gente parece ter lido só o último parágrafo do post e não entendeu a minha crítica. Eu não estou reclamando da grade do FISL. Eu estou reclamando do uso do evento para promoção de campanhas políticas que não dizem respeito a software livre. Eu não estou reclamando do tema política, eu estou reclamando do uso político do evento. Estou reclamando do uso do público e dos voluntários do FISL como massa de manobra (eu odeio essa expressão, mas não encontrei outra melhor).]
103 comentáriosUpdate 2009-05-06 02:08: Há mais detalhes sobre o que descobri após investigar mais na área de comentários. O filtro da GVT está parecendo mais alguma tentativa (incômoda e intrusiva, mas que talvez funcione) de fazer um cache transparente, que um bloqueio.
Recentemente estou tendo problemas estranhos com torrents na minha conexão da GVT. Se eu tento baixar um torrent do The Pirate Bay, como por exemplo este, eu vejo o seguinte erro:
ERROR: [00:10:23] bad data from tracker - invalid peer list
Mas se eu testar isso a partir de outras redes, ou usar Tor para conectar ao tracker, tudo funciona como deveria. Alguém mais usando GVT com esse problema?
Investigando mais, consegui notar que a resposta recebida quando tento contactar o tracker é totalmente truncada:
Fora da rede da GVT (ou usando Tor, o resultado é o mesmo):
Feed RSS$ curl -4 -v 'http://vip.tracker.thepiratebay.org:80/announce?info_hash=Q%F7%9F%1D%9F%82%7C%CFO%3D%FB%EC%C0%2B%96F%EC%3D%CF%EB&peer_id=-lt0C40-%FBIg%EB%D3%FD%BFF%026%D68&key=7f3ccebc&compact=1&port=23541&uploaded=0&downloaded=0&left=842513832&event=started' | hexdump -C
* About to connect() to vip.tracker.thepiratebay.org port 80
* Trying 91.191.138.3... connected
* Connected to vip.tracker.thepiratebay.org (91.191.138.3) port 80
> GET /announce?info_hash=Q%F7%9F%1D%9F%82%7C%CFO%3D%FB%EC%C0%2B%96F%EC%3D%CF%EB&peer_id=-lt0C40-%FBIg%EB%D3%FD%BFF%026%D68&key=7f3ccebc&compact=1&port=23541&uploaded=0&downloaded=0&left=842513832&event=started HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5
> Host: vip.tracker.thepiratebay.org
> Accept: */*
>
< HTTP/1.0 200 OK
< Content-Type: text/plain
< Content-Length: 399
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 399 100 399 0 0 1169 0 --:--:-- --:--:-- --:--:-- 0Closing connection #0
00000000 64 38 3a 63 6f 6d 70 6c 65 74 65 69 34 38 65 31 |d8:completei48e1|
00000010 30 3a 64 6f 77 6e 6c 6f 61 64 65 64 69 33 31 37 |0:downloadedi317|
00000020 37 65 31 30 3a 69 6e 63 6f 6d 70 6c 65 74 65 69 |7e10:incompletei|
00000030 34 39 65 38 3a 69 6e 74 65 72 76 61 6c 69 31 38 |49e8:intervali18|
00000040 30 39 65 31 32 3a 6d 69 6e 20 69 6e 74 65 72 76 |09e12:min interv|
00000050 61 6c 69 39 30 34 65 35 3a 70 65 65 72 73 33 30 |ali904e5:peers30|
00000060 30 3a 45 b4 0e c2 f7 70 46 69 89 40 25 e3 47 6e |0:E....pFi.@%.Gn|
[...]
00000180 80 2c c1 1b 55 16 7f ca c9 0d 07 6d e8 f4 65 |.,..U......m..e|
0000018f
E usando a conexão da GVT:
$ curl -4 -v 'http://vip.tracker.thepiratebay.org:80/announce?info_hash=Q%F7%9F%1D%9F%82%7C%CFO%3D%FB%EC%C0%2B%96F%EC%3D%CF%EB&peer_id=-lt0C40-%FBIg%EB%D3%FD%BFF%026%D68&key=7f3ccebc&compact=1&port=23541&uploaded=0&downloaded=0&left=842513832&event=started' | hexdump -C
* About to connect() to vip.tracker.thepiratebay.org port 80 (#0)
* Trying 91.191.138.5... connected
* Connected to vip.tracker.thepiratebay.org (91.191.138.5) port 80 (#0)
> GET /announce?info_hash=Q%F7%9F%1D%9F%82%7C%CFO%3D%FB%EC%C0%2B%96F%EC%3D%CF%EB&peer_id=-lt0C40-%FBIg%EB%D3%FD%BFF%026%D68&key=7f3ccebc&compact=1&port=23541&uploaded=0&downloaded=0&left=842513832&event=started HTTP/1.1
> User-Agent: curl/7.19.4 (i386-redhat-linux-gnu) libcurl/7.19.4 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18
> Host: vip.tracker.thepiratebay.org
> Accept: */*
>
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0< HTTP/1.1 200 OK
< Content-Length: 43
<
{ [data not shown]
0 43 0 43 0 0 138 0 --:--:-- --:--:-- --:--:-- 1162* Connection #0 to host vip.tracker.thepiratebay.org left intact
* Closing connection #0
00000000 64 38 3a 69 6e 74 65 72 76 61 6c 69 36 30 65 35 |d8:intervali60e5|
00000010 3a 70 65 65 72 73 36 3a bd 72 e5 8d 41 f2 37 3a |:peers6:.r..A.7:|
00000020 70 72 69 76 61 74 65 69 31 65 65 |privatei1ee|
0000002b
20 comentários
Eu já havia anunciado em outros lugares antes, mas não havia feito o anúncio oficial aqui no blog: a comunidade Linux Kernel Newbies Brasil está de volta! Há várias maneiras de participar:
Se você tem dúvidas, envie para o forum do site ou para a lista de e-mail, ou pergunte no canal de IRC. Todas as dúvidas são bem vindas: das mais básicas às mais avançadas.
Se você tem experiência, participe do forum, da lista de e-mail e do canal de IRC. Ou, se gosta de escrever, você pode criar uma conta no site, e escrever ou traduzir material. Cada usuário registrado possui uma área pessoal no site, onde pode criar conteúdo que pode ser promovido para a página principal.
Comente!I’ve spent last night trying to find out how to handle some bad blocks reported by smartd, on the hard disk of a old laptop. The Bad block HOWTO for smartmoontools has lots of useful information, but too many calculations to be done by hand. To ease on the task, I’ve written a script to help on the task. The script simply does the calculations described on the HOWTO and shows you the result.
This is a sample run:
# ./lba2fs.py /dev/sda 11475078 # SMART says LBA 11475078 is bad lba2fs, by Eduardo Habkost <ehabkost@raisama.net> If you want to know what to do with the output of this program, check: http://smartmontools.sourceforge.net/badblockhowto.html [/dev/sda sector 11475078] Press Return to automatically probe, or enter command: cmd> I think I've found: partition table Checking the partition list... /dev/sda2 sector 11073453 [/dev/sda2 sector 11073453] Press Return to automatically probe, or enter command: cmd> I think I've found: LVM volume Checking the PE where the block is located pe_start: 384 sectors PE: 168 Checking on which LV the PE is located Found PE range on map (LV) Checking maps of LV... /dev/VolGroup00/LogVol00 sector 11073069 [/dev/VolGroup00/LogVol00 sector 11073069] Press Return to automatically probe, or enter command: cmd> I think I've found: ext3 filesystem Checking ext2 fs block... Block size: 4096 Block: 1384133 debugfs 1.41.4 (27-Jan-2009) GOOD: ext2fs block 1384133 at /dev/VolGroup00/LogVol00, not in use You can zero the block running the following command, but: 1) Don't do that if the device is in use (e.g. filesystem mounted) 2) *You will lose data* that is stored on the block. It looks like It is safe to do that on this block, but be careful. Are your backups up to date? 8) dd if=/dev/zero of=/dev/VolGroup00/LogVol00 bs=4096 count=1 seek=1384133 I recommend doing a read-test on the block first, to see if an I/O error is returned. Use the 'read' command for that. [ext2fs block 1384133 at /dev/VolGroup00/LogVol00, not in use] Press Return to automatically probe, or enter command: cmd>
As you can see above, fortunately on my case the bad block was unused on the ext2 filesystem, and I could safely write to it to force the drive to reallocate the bad sector, and the I/O errors are gone.
The script just try to read from the devices, with no code to write to them, so it should be always safe to run it. However, be very careful when using the numbers calculated by it to write to a disk sector. Always keep your backups up to date.
Comente!