Já faz tempo que estou querendo escrever um pouco sobre o pf-kernel e acho que finalmente chegou esse momento. Talvez a idéia dramática de fatalidade, derivado do fato de que estou assistindo o filme 2012, tenha me levado a escrever sobre isso logo.
Sempre existiram variações do kernel do Linux, desde seu surgimento. As versões de Andrew Morton eram famosas por incluir algumas vantagens como melhor preempção e gerenciamento de memória se comparado com o kernel padrão, por exemplo. Mas isso era no passado. Nos tempos atuais de Linux, alguns kernels modificados para melhoria de resposta em tempo real são os mais famosos, justamente por existir dentro de distribuições como Debian e Ubuntu, bastando usar o gerenciador de pacotes para instalar e testar. Nesse panorama, sem muito alarde, surgiu um novo fork do kernel Linux: o pf-kernel.
Apesar da associação de pf-kernel com o packetfilter dos BSDs, na verdade o pf é uma referência ao apelido do autor, post-factum. O pf-kernel é um kernel padrão Linux modificado da seguinte forma:
A maioria são patches para melhorar o tempo de resposta do sistema (preempção), mas não somente com alteração no escalonador, mas por melhorias inclusive nas respostas de I/O, além de TuxOnIce, uma forma nova hibernar o Linux, com várias vantagens em relação ao sistema padrão, como o retorno mais rápido. Infelizmente no meu caso tive problemas do TuxOnIce com o meu filesystem, XFS. Mas de resto, gostei de usar o pf-3.2, ficando com uptime além de 100 dias graças a ele. Eu não conhecia o pf-kernel, só tinha ouvido falar por cima, mas uma sugestão no twitter, do @cleitonflima, me fez experimentar e gostar muito dessa árvore de kernel. Posteriormente encontrei um artigo sobre o mesmo:
Fazendo o pinguim voar: o pf-kernel
Apesar da riqueza de dados sobre pf-kernel nesse artigo, não há tanta informação assim sobre o mesmo. Então não consegui confirmar o que o artigo diz sobre os patches, além das informações que cada patch já traz. Aliás as melhorias, no meu processador Intel Core I3, só foram percebidas com carga alta, ou seja, load average acima de 4. Abaixo disso, que é o normal do sistema, não percebi nenhum ganho. Mas com o sistema sobrecarregado, consegui continuar ouvido música sem interrupções, o que não acontece com o kernel padrão.
E fui brindado com um kernel mais estável que o kernel padrão também. Tive problemas com o kernel 3.2.0, e com o pf-kernel-3.2.5, mas a versão pf-kernel-3.2.7 funcionou muito bem (com exceção do problema do filesystem XFS). Agora estou criando coragem pra compilar uma versão mais recente do pf-kernel, que suporte mais de 100 dias de uptime, mas não acho que terei problemas.
Pra quem tem uma máquina mais antiga, da geração Core Duo ou até anterior, é bem provável que os benefícios do pf-kernel sejam mais bem notados. Para agraciados donos de CPUs mais modernas, como a última geração dos Core-i7, talvez nem seja perceptível, mas é sempre interessante testar as alternativa ao kernel padrão e saber que elas existem.
Fazia anos que não participava de um FISL, Fórum Internacional de Software Livre. Acho que uns 9 ou 10 anos. Esse ano consegui me programar melhor e participar do evento, ficando junto com o pessoal da caravana do Espírito Santo.
Diferente dos FISLs do passado, o desse ano foi totalmente dominado pelo Ubuntu. De laptops nos estandes a desktops pra apresentação. Há quem possa reclamar da "ubuntização" do evento, mas sob meu ponto de vista, isso é ótimo. O último FISL que fui, por volta de uma década atrás, era dominada pelo Windows. Faziamos movimentos de "libertação dos desktops" e "install fests" para migrar tais computadores, com Debian. Era uma batalha. Vejo hoje que realmente vencemos e isso é lindo de se ver. Mas uma coisa realmente mudou em relação ao uso dos computadores: a maioria era usado somente para acessar o FaceBook. Isso foi colocado em algumas palestras, que pra maioria das pessoas a Internet estava se tornando o FaceBook. Esse foi o lado triste do evento.
Outra mudança sensível foi em relação à qualidade das palestras. No passado, o FISL era entupido de políticos mostrando cases de "adoção de software livre na administração pública", que nada mais eram que uma mostra ruim de como foram adotados aplicativos de office através do OpenOffice. Beiravam ao ridículo. Felizmente não vi nada disso esse ano, talvez pela oferta abundante de palestras de alto nível.
E como sempre o contato com o pessoal que só conhecemos remotamente. Foi muito divertido e enriquecedor dividir um quarto de hostel, o hostel Casa Azul, com o pessoal do Espírito Santo, assim como re-encontrar velhos amigos no evento (e notar que não sou o único ficando velho). Isso fez valer toda a viagem e o cansaço de 4 dias ininterruptos de palestras, além de ajudar a ficar acordado durante todo esse tempo.
Essas são as fotos que fiz durante o evento, publicada num velho companheiro de fotos e eventos, o Flickr. Mas também publiquei no FaceBook :-p
UPDATE: 2021-12-23 atualizado pra usar o formato exportado do Flickr em javascript ao invés do formato em flash.
E minha alegria realmente chegou ao fim nos 110 dias de uptime. Dessa vez o culpado foi o filesystem, XFS, que começou a cuspir vários erros como esses:
XFS (sda1): xlog_space_left: head behind tail
tail_cycle = 252, tail_bytes = 8731136
GH cycle = 252, GH bytes = 8731128
XFS (sda1): xlog_space_left: head behind tail
tail_cycle = 252, tail_bytes = 8731136
GH cycle = 252, GH bytes = 8731128
XFS (sda8): xlog_space_left: head behind tail
tail_cycle = 1212, tail_bytes = 8328704
GH cycle = 1212, GH bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
tail_cycle = 1212, tail_bytes = 8328704
GH cycle = 1212, GH bytes = 8328696
XFS (sda8): xlog_space_left: head behind tail
tail_cycle = 1212, tail_bytes = 8356864
GH cycle = 1212, GH bytes = 8356856
XFS (sda8): xlog_space_left: head behind tail
tail_cycle = 1212, tail_bytes = 8356864
GH cycle = 1212, GH bytes = 8356856
XFS (dm-0): xlog_space_left: head behind tail
tail_cycle = 350, tail_bytes = 158558208
GH cycle = 350, GH bytes = 158558200
XFS (dm-0): xlog_space_left: head behind tail
tail_cycle = 350, tail_bytes = 158558208
GH cycle = 350, GH bytes = 158558200
XFS (sda1): xlog_space_left: head behind tail
tail_cycle = 252, tail_bytes = 8787968
GH cycle = 252, GH bytes = 8787960
Isso em todas as partições. Tentei forçar um "init 1" pra single mode e "desmontar/montar" as partições, mas as mesmas não permitiam isso. Como encontrei referências bem ruins sobre esse comportamente, dizendo que poderia levar à perda de dados, eu preferi fazer o reboot do sistema.
A lista da SGI, criadora do XFS, foi essencial pra decidir o que fazer. Só espero que o problema não se repita nos meus próximos 100 dias de uptime.
11:55:20 up 100 days, 0 min, 43 users, load average: 1.22, 0.83, 0.84
Finalmente meu laptop, de uso diário e pessoal, quebrou a barreira dos 100 dias de uptime. E o que isso quer dizer? Nada, e ao mesmo tempo, várias coisas. Mas significa que estou trabalhando sem interrupções por 100 dias.
Fazia tempo que eu não tinha um uptime maior que 30 dias, quanto mais de 100. O problema não era específico, mas um conjunto deles. O que mais afetava o tempo em que a máquina funcionava sem interrupções (leia-se travamentos) era o driver de vídeo Intel. Invariavelmente o Xorg apresentava um crash por conta dos efeitos 3D do KDE com o plasma-desktop. Tentei de tudo, inclusive desabilitar os efeitos e até mesmo parar de usar o KDE, mas o crash de xorg sempre me encontrava.
Contudo vários esforços ocorreram em várias frentes e paralelamente, como sempre acontece no mundo do software livre. A equipe do Xorg melhorou o driver Intel, o KDE, com o lançamento do 4.7, criou uma forma de contornar esse crash, deixando o ambiente plasma muito mais estável e, por fim, a equipe de kernel trabalhou na melhoria do driver framebuffer e DRM pra Intel.
Esse conjunto de melhorias deram um resultado excelente, visível pelo tempo em que o laptop está funcionando sem parar. E olhe que o uso é intenso. Faço desde desenvolvimento de software até apresentações pra clientes, inclusive utilizando 2 monitores (em geral uma televisão). Tive alguns problemas nesse percurso, como uma sobrecarga no xorg, que levou o KDE a cair, mas nada que um reinício do serviço gráfico não pudesse resolver, sem precisar rebootar o laptop.
Em geral tenho trabalhado de forma consistente, fechando e abrindo o laptop, sem reiniciar o trabalho que tinha parado anteriormente. Isso garante um ganho de produtividade muito bom, pois já vejo em que ponto eu estava da última vez e continuo dali pra frente. Nada de reabrir documentos e procurar onde foi a última linha editada, nada de reabrir ambientes de desenvolvimento, nada de reiniciar minhas conexões SSH pra máquinas em que trabalho via VPN, já que faço isso automaticamente via script, que só detectam a queda do link e reiniciam a conexão. Fecho o laptop na sexta-feira e reabro na segunda, como se tivesse parado pra um café.
Então quando se vê um uptime alto, não estamos falando somente de tempo se desligar a máquina mas a produtividade que isso proporciona. Claro que existe um lado egocêntrico de falar no tempo sem desligar ou sem reboot, que vem da cultura de sysadmin, onde o maior uptime significa (ou ao menos significava) um servidor bem ajustado e configurado, mas isso é quase insignificante em relação ao benefício do trabalho ininterrupto.
E você? Já chegou aos 100 dias ou isso ainda é um fardo pra sua produtividade?
Aos poucos estou arrumando o site. Muitos dos plugins antigos pararam de funcionar, como as tags "{mosimage}" e "{denvideo}", sem muito jeito de arrumar em curto prazo. São os efeitos colaterais do upgrade que infelizmente não dava pra adiar mais.
Perdi a parte de estatísticas uma vez que o Joomlastats só suporta a antiga versão 1.5. Mais um que entra em "perdas e danos". Ainda não achei um substituto a altura, mas vou continuar procurando...
Depois de empurrar esse upgrade por um longo tempo (acho que mais de 6 meses), finalmente tomei coragem e aproveitei o feriado de corpus christi chuvoso que São Pedro, esse fanfarrão, preparou para todos nós e mandei ver.
Como não tenho acesso shell ao provedor de hospedagem, mas somente interface web via plesk, tive de fazer um dump do BD e cópia do conteúdo para o desktop que tenho. Feito o upgrade lá, copiar tudo novamente de volta pro site. Trabalho dobrado e cuidado pra não apagar o que não devia. Mas deu certo (até agora parece tudo ok).
Infelizmente nem tudo é alegria. Preciso ainda ver se todos os artigos mais antigos estão corretos e se a indexação do site continua funcionando como anteriormente, principalmente pras buscas do google. Fora que formatação foi perdida, estatísticas, plugins, etc. Dá uma limpada no ambiente, mas preciso refazer o caminho das pedras do site.
Então, mãos à obra!
Essa é uma apresentação que fiz na iMasters em abril último, no evento 7Masters sobre python.
Não é um curso de python, nem nada próximo disso, mas apenas uma visão de que telecom é na verdade um grande TI, com aplicações que todos nós já conhecemos bem.
Era uma apresentação que deveria levar 7 minutos. Gastei 20.
UPDATE: 2021-12-23 troquei o arquivo embedded de flash pra um gif animado uma vez que nenhum browser sério ainda suporta swf.
Quem acessou essa página (ou site) deve ter notado falhas constantes. Não sei dizer se é por causa de ataques DDoS ou mesmo se é alguma falha de sistema ou de hardware, uma vez que não administro o sistema, que fica num provedor de um amigo.
Olhei a estatística de acessos, que conta os acessos válidos (não mostraria um DDos), e não existe nenhum crescimento de tráfego que devesse impactar na performance. Mas algo está ruim.
Então aumentei o tempo de cache das páginas (sem consultar o BD) de 3 minutos para 15. Espero que isso melhore no tempo de resposta do site como um todo.
Depois de anos usando meu roteador wireless Netgear WGR614v7, os recentes problemas do Net Virtua o levaram ao uso excessivo de CPU e um eventual defeito de uso: simplesmente morreu. Não liga mais.
Então reativei meu D-Link DI-524, um roteador wireless que eu deixava de backup e para uso em outros eventos como treinamentos e até mesmo churrascos.
Pra minha infeliz surpresa, descobri que não conseguia mais configurar WPA-PSK no D-Link (sempre o deixava em rede aberta). Simplesmente a configuração, feita via web browser, não é salva tanto no Firefox quanto no Chrome.
Uma pequena pesquisa no Google mostra rapidamente que a situação é "lugar comum" de quem tem esse equipamento. O chineses que desenvolveram a GUI web só se preocuparam em dar suporte ao Internet Explorer, esqueçendo padrões e não melhorando seu suporte com o tempo.
Pra fugir do uso de um Windows, e do Internet Explorer, abri o código fonte da página e verifiquei os parâmetros pra configurar o uso de WPA-PSK. Apesar de utilizar um método POST, funciona perfeitamente com um GET, sendo possível abrir um browser, conectar-se na página do modem (que exige login e senha) e modificar pela URL sua configuração.
A URL fica da seguinte forma:
http://192.168.0.1/h_wireless.cgi?wirelessESSID=MinhaRede&wpapsk1=senhasecreta&
wpapsk2=senhasecreta&channel=8&apply=1
Onde:
Feito isso, o DI-524 já sai funcionando corretamente. E com menor uso de CPU se comparado ao NetGear, que demorava uns 40 minutos pra pegar endereço IP por DHCP no Net Virtua, enquanto que o D-Link só leva uns 5.
Sobre o problema do Net Virtua, é comum a rede inteira fica aberta com um imenso \20 em bridge. Com isso temos 4094 possíveis endereços de máquinas numa mesma rede, todos jogando tráfego de broadcast, criando um uso intenso de CPU por justamente existir mais tráfego em camada de enlace (L2 do modelo RM-OSI), de frames, que na camada de rede (L3).
Mas com certeza vou investir algum dinheiro pra comprar um roteador compatível com open-wrt ou dd-wrt.
Não é de hoje que me deparo com esses erros de unicode em python.
Em algumas funções que uso, principalmente as que lêem de timeline de redes sociais, tenho problemas com caracteres. Dessa vez eu estava fazendo um programa que lê a timeline da rede social da empresa, que é baseada num produto lixo da Microsoft, o ShamePoint, digo, SharePoint, que publica a API de mensagens no formato RSS. A função é pra gerar um gráfico de mensagens a cada 5 minutos para verificar o andamento da rede social (que passou do momento de hype). Então como o ShamePoint é limitado em suas funções, resolvi fazer um "tracking" de posts através de uma função com um hash MD5 da mensagem postada.
A idéia não é muito complexa, mas eis que fazendo o hash eu achei um:
helio@shibboleet:pynet$ ./mynet_tag_posts.py
Getting posts
Reading output and rss
Traceback (most recent call last):
File "./mynet_tag_posts.py", line 106, in
main()
File "./mynet_tag_posts.py", line 103, in main
RSS = RSS_parser(XML)
File "./mynet_tag_posts.py", line 60, in RSS_parser
key = md5sum(rss.summary_detail.value)
File "./mynet_tag_posts.py", line 19, in md5sum
m.update(msg)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xc5' in position 96: ordinal not in range(128)
E a função de hash MD5, a md5sum(), é super simples:
def md5sum(msg):
m = hashlib.md5()
m.update(msg)
return m.hexdigest()
Só que mensagens com caracteres não ASCII, como em português ou suéco, simplesmente matam o processamento do MD5.
Em outros scripts eu contornei isso fazendo uma análise por caractere e substituindo todo aquele que tivesse valor maior que 128 por seu semelhante não acentuado na tabela ASCII. Trabalho tosco, mas funcional.
Dessa vez resolvi procurar como corrigir isso. E pra sempre. Procurei na documentação do python sobre tratamento de unicode.
E não é que achei a solução do jeito mais simples e pythonista possível? Basta forçar um atributo de formato de caractere no texto, como texto.encode(formato). No caso, mudei a função para essa abaixo, usando formato de caracteres "utf-8":
def md5sum(msg):
m = hashlib.md5()
msg = msg.encode('utf-8')
m.update(msg)
return m.hexdigest()
E o problema foi resolvido. Sem mais chororo de formatos iso-8859-1 e utf-8.
Hoje pela manhã (ou quase isso), fui surpreendido pelo mau funcionamento da minha placa de rede cabeada, uma placa gigabit. Não é uma placa que eu tenha escolhido, pois faz parte do notebook, um Sony Vaio VPC-S110GB.
Como a placa não tem led de indicação de funcionamento, eu só consegui identificar que não estava operando pela mensagem abaixo:
root@shibboleet:~# dmesg | grep -i eth
[45263.845838] ADDRCONF(NETDEV_UP): eth0: link is not ready
Após algumas tentativas infrutíferas de colocar e tirar o cabo (acabei até quebro o clipezinho que segura o cabo), dei uma olhada como estava a camada de enlace ethernet.
root@shibboleet:~# mii-tool eth0
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
SIOCGMIIREG on eth0 failed: Input/output error
eth0: negotiated 1000baseT-HD flow-control, link ok
Esse "Input/output error" já me deu uma dica que algo tinha acontecido com o driver da placa. Como estou usando um kernel-pf, e compilado por mim, esse tipo de erro pode mesmo surgir. Claro que existe a possibilidade de ser um defeito da placa, mas prefiro acreditar que o erro é meu, pois esse eu consigo consertar.
Então dei uma olhada na placa de rede.
root@shibboleet:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:be:65:5a:ab
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:4294957164 errors:4294906502 dropped:4294947030 overruns:4294957163 frame:4294967295
TX packets:4294957163 errors:4294926764 dropped:0 overruns:4294957163 carrier:4294967295
collisions:4294916631 txqueuelen:1000
RX bytes:4294957164 (4.2 GB) TX bytes:4294957163 (4.2 GB)
Interrupt:43
É notável a quantidade de colisões na placa, além de erros, que mostram que realmente alguma coisa não estava certa.
Em outros sistemas (nem preciso mencionar), a única solução seria a de... rebootar. Mas como é um Linux, com kernel modular, bastou fazer o seguinte:
root@shibboleet:~# ifconfig eth0 down
root@shibboleet:~# rmmod atl1c
root@shibboleet:~# modprobe atl1c
root@shibboleet:~# ifconfig eth0 up
Em seguinda, testando o meio físico...
root@shibboleet:~# mii-tool eth0
eth0: negotiated 1000baseT-FD flow-control, link ok
E nada de reboot. Nada como usar unix. Pode não ser perfeito, mas também não é windows.
Que o mundo corporativo é cheio de antas, todo mundo já sabe. Não é de hoje que as tirinhas do Dilbert contam as coisas mais bizarras e estúpidas desses ambientes hostis.
Mas eu cansei. Não do mundo corporativo, pois ele ainda paga meu salário, mas das antas que por lá habitam e simplesmente compram "soluções Microsoft" que só funcionam com... Windows! É incrível a falta de tato e conhecimento das pessoas de alto escalão que definem o que será utilizado por T.I. na empresa. Simplesmente incrível.
Então resolvi iniciar uma pequena campanha, pra ajudar esse povo todo entender que padrões são bons, e que soluções com padrões, seja Microsoft, seja IBM, seja Oracle, ou seja mesmo um software livre, permitem que QUALQUER sistema conecte e funcione, não forçando o usuário a nenhuma restrição de sistema operacional ou navegador Internet específico.
É um grito na multidão. Mas temos de começar a gritar.
Gosto do jogo UFOAI, de UFO Alien Invasion. É um jogo de estratégia que joguei pela primeira vez nos tempos do DOS e do "Windows 3.11 for Workgroups". Nessa época era um outro jogo, pago, e que se chamava X-Com Unknown Enemy, ou algo assim. Com o avanço dos sistemas, computadores, e jogos, obviamente ficou obsoleto e esquecido. Então alguns fãns resolveram fazer uma versão opensource do jogo, e claro, com esteróides.
O jogo exige OpenGL pra rodar, pois usa massivamente o "quake engine" pra renderizar os ambientes. E é fantástico, e difícil, pois tem uma inteligência artificial aprimorada, que faz com que seus soldados saiam correndo de medo no meio de algumas batalhas.
Fazia tempo que não jogava, mesmo porque jogo mais em console que no PC, mas essa semana resolvi brincar um pouco. Eis que descubro um problema de OpenGL no meu laptop:
helio@shibboleet:~$ ufo +set vid_ref sdl
---- filesystem initialization -----
Adding game dir: /usr/share/games/ufoai/base
Added packfile /usr/share/games/ufoai/base/0base.pk3 (9 files)
Added packfile /usr/share/games/ufoai/base/0maps.pk3 (544 files)
Added packfile /usr/share/games/ufoai/base/0materials.pk3 (45 files)
Added packfile /usr/share/games/ufoai/base/0media.pk3 (10 files)
Added packfile /usr/share/games/ufoai/base/0models.pk3 (2015 files)
Added packfile /usr/share/games/ufoai/base/0music.pk3 (49 files)
Added packfile /usr/share/games/ufoai/base/0pics.pk3 (2114 files)
Added packfile /usr/share/games/ufoai/base/0shaders.pk3 (26 files)
Added packfile /usr/share/games/ufoai/base/0snd.pk3 (266 files)
Added packfile /usr/share/games/ufoai/base/0ufos.pk3 (97 files)
Adding game dir: ./base
Added packfile ./base/0base.pk3 (9 files)
Added packfile ./base/0maps.pk3 (544 files)
Added packfile ./base/0materials.pk3 (45 files)
Added packfile ./base/0media.pk3 (10 files)
Added packfile ./base/0models.pk3 (2015 files)
Added packfile ./base/0music.pk3 (49 files)
Added packfile ./base/0pics.pk3 (2114 files)
Added packfile ./base/0shaders.pk3 (26 files)
Added packfile ./base/0snd.pk3 (266 files)
Added packfile ./base/0ufos.pk3 (97 files)
Adding game dir: /home/helio/.ufoai/2.3.1/base
using /home/helio/.ufoai/2.3.1/base for writing
executing default.cfg
couldn't execute config.cfg
----- network initialization -------
libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3 initialized.
------ server initialization -------
added 7 maps to the mapcycle
----- console initialization -------
Console initialized.
------- video initialization -------
SDL version: 1.2.14
I: desktop depth: 32bpp
I: video memory: 0
I: Available resolutions: 1366x1792 1366x768 1360x768 1024x768 800x600 640x480 (6)
I: video driver: x11
I: setting mode -1
I: set swap control to 0
X Error of failed request: GLXUnsupportedPrivateRequest
Major opcode of failed request: 155 (GLX)
Minor opcode of failed request: 16 (X_GLXVendorPrivate)
Serial number of failed request: 25
Current serial number in output stream: 26
Tentei forçar o sistema a inicializar sem o uso de OpenGL, com o parâmetro "+set vid_ref sdl", mas nem isso resolveu. Como não existe nada mais sagrado ao homem que seus jogos eletrônicos, resolvi consertar o problema. Ou ao menos tentar.
Page 22 of 35
