Estudo que coletou dados da Itália, Alemanha, França e Austria conclui que os nivicolous hominis, também conhecidos por “homens de neve”, correm sério perigo de extinção.

Cientistas afirmam que o homem de neve sobrevive apenas em altitudes entre 200 e 800 metros de altura e que, portanto, estão se extinguindo justamente onde a maioria das crianças Suiças vive.

Depois dos ursos polares, chegou a vez dos ambientalistas se preocuparem com mais esta rara espécie que tantos sonhos cultivou no ocidente.
Confira texto completo aqui.

Eis que apareceu o “bug do milênio” das bombas de combustível de Nova Iorque. Pra quem não se lembra, havia um temor generalizado dos registradores de datas nos computadores, de relógios, fornos microondas a mainframes e supercomputadores, não conseguirem registrar um número maior que 1999.

Acontece que algumas bombas de combustível não conseguem registrar os preços de gasolina de George W. Bush! “Nunca antes na história daquele país” o galão de gasolina custou mais que U$ 4,00 - então muitos donos de postos não sabiam que suas bombas só registravam até 4,00 dólares por galão.

Resultado: os postos de gasolina estão configurando as bombas para registrar metade do preço, quando os Novaiorquinos chegam ao caixa pagam o dobro do valor mostrado na bomba….

Confira aqui reportagem do New York Times (em inglês)

Atualização 17:37hs
Acabo de voltar do Detran, no SIA(Brasilia). Na minha senha lía-se 15:58hs, fúi atendido às 16:57, cerca de uma hora de espera. Quando chegou minha vez perceberam que haviam me dado uma senha preferencial, para idosos e gestantes…. A atendente viu que eu não tentei tirar vantagem nenhuma e que tinha visto minha espera, então ela muito gentilmente me concedeu a vez. (Detalhe: Se eu tivesse 70 anos teria esperado 1 hora.)

Mais cedo fiz a fila do BRB para pagar as multas e impostos do carro para circular em 2008…paguei mais de um mês de meu trabalho para eles. Um mês são 8,3% do ano, ou seja, entreguei mais 8,3% de Imposto de Renda anual hoje no caixa do Detran.

Conclusão: o sistema do Detran estava fora do ar, não comunicava com a Secretaria de Fazenda, portanto não puderam emitir meu documento IPVA 2008 do carro. Mandaram eu esperar em casa, virá pelo correio. Em total coerência com o sistema tributário do Brasil : paguei e não levei.

Este ano o IPTU veio absurdamente alto. Eu não estou conseguindo pagar e talvez tenha que vender o carro pra aguentar as contas. Só a taxa de limpeza urbana foi 1/3 do IPTU. Venham ver a limpeza urbana aqui da rua pra vocês verem se vale sequer 1% do que pagamos. Quem faz a limpeza de verdade aqui somos nós, os condôminos.

Os impostos dos carros agora incluem a presença permanente das multas traiçoeiras de 47 km/h e 67 km/h. Para dirigir é preciso pagar IPVA, seguro, licenciamento e multas. São 4 impostos que pagamos para ter o direito a dirigir. Isso sem falar no imposto que você já paga na gasolina e na compra do automóvel.

Agora há pouco passamos pela época do imposto de renda, todo ano levamos a mordida do leão. Funcionários públicos que já pagaram imposto retido na fonte, normalmente pagam de novo.

Eu não sou tributarista, mas sei que existem uns 200 outros impostos por aí. Todos eles nasceram com algum propósito, algo tipo “este é pra pagar pela infraestrutura”, “este é pra saúde”. Mentira. Não é pra saúde coisa nenhuma. É pra encher os bolsos e é pra não ter que cortar custos e ter o trabalho de se tornar mais eficiente.

Nós Brasileiros somos condenados à assistir pessoas que não valem um centavo roubando bilhões.

Essa carga tributária é assalto à mão armada. Chega de impostos!

Essa importância que se tem dado ao email só pode ser distração pras massas ou falta de conhecimento de quem acusa com base nessas mensagens.

Estava assistindo o noticiário e percebí que, de alguns dias pra cá, o email tem sido peça chave de alguns casos que tiveram bastante cobertura jornalística.

O primeiro deles trata do tal dossiê da Casa Civil. Email de fulano que foi pra ciclano no dia tal, à tal hora.

Outro caso é o das Farc, de que um susposto email de não sei quem implica o Hugo Chavez em não sei o que.

O email é um artefato digital que foi pensado para servir como conduto de mensagens entre professores, pesquisadores e amigos. O email é uma forma de aproximar as pessoas, é uma excelente ferramenta de comunicação. Quando as mensagens começavam a circular, a Internet não passava de algumas centenas de computadores ligados em rede. Eram tão poucos que os nomes de todos eram mantidos em apenas um arquivo de texto em cada máquina participante da rede. E os computadores eram do tamanho de uma geladeira, era possível saber, com relativa precisão, quem enviou e de onde. As pessoas eram literalmente conhecidas pelo primeiro nome(antes do @).

Hoje tem um computador em cada aparelho celular, alguns operam com chips e outros podem ser praticamente anônimos, e o sistema de email continua sendo o mesmo de 40 anos atrás.

O email é um meio de comunicação no qual a identidade do remetente não é irrefutável, o destino tampouco, não tem qualquer método de autenticação ou autorização, e pode ser construido com apenas um editor de textos comúm. Não é preciso conhecimento técnico para isso, basta pegar uma mensagem recebida, abrí-la no Bloco de Notas e alterar os dados nela contidos para reenviá-la se passando por qualquer identidade.

Por esse motivo, ele pode ser construido por qualquer pessoa para incriminar qualquer outra, em qualquer crime ou suspeita.

Portanto fica aí a dica : jamais aceite um email como prova de qualquer coisa, não faça comércio eletrônico através dele, nem aceite como documento ou garantia de uma transação.

E desconfie de qualquer notícia que utilize uma mensagem de email como indício de qualquer coisa mais séria.

Tem 25 horas que estou tentando descobrir por que o servidor Apache decidiu gerar falhas de segmentação e derrubar o serviço aparentemente sem motivos. Ontem, na maior tranquilidade, atualizei a minha biblioteca CPAN, rodei a rotina de sempre:
# cpan
cpan> install Bundle::CPAN
cpan> install Bundle::LWP
cpan> install DBI
cpan> install DBD::mysql
cpan> install Apache::SessionX

E por aí vai….são 20 módulos que atualizo sempre.

O que me passou desapercebido foi o upgrade do driver MySQL do 4.006 para 4.007. O próprio número de versão, lá na casa dos milésimos, indica uma versão de atualização simples, que não deveria causar maiores transtornos. Eu não poderia estar mais errado.

Logo que atualizei, reiniciei o Apache para reler as bibliotecas do Perl. Como atualizei centenas de módulos(nos Bundle::CPAN e Bundle::LWP), não desconfiei do DBD::mysql de início.

Verificava o log do httpd pai, e, desde ontem de manhã, eis o que encontrava:
[Tue May 27 06:01:16 2008] [notice] child pid 14013 exit signal Segmentation fault (11)
[Tue May 27 06:01:47 2008] [notice] child pid 13698 exit signal Segmentation fault (11)
[Tue May 27 06:02:04 2008] [notice] child pid 13678 exit signal Segmentation fault (11)
[Tue May 27 06:56:07 2008] [notice] child pid 13999 exit signal Segmentation fault (11)
[Tue May 27 06:57:28 2008] [notice] child pid 14000 exit signal Segmentation fault (11)
[Tue May 27 06:58:10 2008] [notice] child pid 14004 exit signal Segmentation fault (11)
[Tue May 27 06:59:48 2008] [notice] child pid 14008 exit signal Segmentation fault (11)
[Tue May 27 07:00:17 2008] [notice] child pid 14002 exit signal Segmentation fault (11)

Esses aí já são de hoje, à partir de 6 AM…. (Vida de programador não é mole…mais uma noite virada….)

Então comecei a luta pra encontrar a biblioteca que causava o SEGFAULT. Baixei o MySQL novo e compilei, em seguida recompilei o Apache com mod_perl 1.29 para buscar a nova versão de libmysqlclient.so.16 ao invés de .so.15, reinstalei o DBD::mysql para linkar com a nova versão, porém as falhas de segmentação continuavam. Volto tudo atrás, retorno ao MySQL 5.0.51a e reinstalo as bibliotecas. Recompilo o PHP para linkar com as .so.15 e também o DBD::mysql. Só nisso se foram 40 minutos, e a cada erro me custava quase uma hora.

Em seguida baixei o Apache 1.3.41, recompilei e nada de solucionar….
Recompilei o Apache com e sem o mod_gzip.c e nada…
Instalei o Apache com e sem o PHP 5.2.4 e nada….
Recompilei com e sem o mod_ssl e nada…
Atualizei as versões das bibliotecas linkadas ao PHP, Freetype, GD….nada…

Começou a bater o desespero….nunca tinha visto um caso desses. Cismei que era sistema de arquivos corrompido, me deu frio na barriga de pensar em atualizar a libc com apenas acesso SSH remoto….um erro e já era. Não arrisquei. Dei um reboot e torcí pra não ser problema de disco….

Coloquei um ping para monitorar quando o servidor voltasse à vida….em alguns instantes tenho o retorno:

64 bytes from ……

Maravilha…o reboot funcionou. Verifico os logs do Apache e os Segmentation Fault continuam lá….

Já eram 5 AM quando decidí começar tudo do zero, a lógica diz que se eu não errar nada no caminho então a pane é de hardware. Não deu pra consertar do modo rápido, então vamos pela força bruta!

Aumentei o nível de debug do Apache sem qualquer resultado, até que cheguei à conclusão que seria inevitável enfiar a mão na massa e ir atrás do stack trace do httpd até achar a chamada que estava acessando memória não autorizada. Lá vamos nós….

Primeiro precisamos compilar o Apache com os símbolos para debug. Só há vantagem em tirar os símbolos de binários compilados se você quiser ocultar o sistema de engenheiros reversos ou tornar o binário alguns bytes menor. No caso do Apache não estamos preocupados com isso, e hoje em dia esbanjamos discos rígidos de 1 Terabyte. Então precisamos adicionar a flag -g ao gcc e recompilar tudo….

# cd apache_1.3.41
# vi configure
Vá até as cercanias da linha 282:
:282
Antes da linha “for var in CFLAGS LDFLAGS LIBS INCLUDES DEPS; do”
Adicione
CFLAGS=-g

Rode o
# ./configure

No meu caso eu utilizo o Makefile.PL do mod_perl assim:

# cd ../mod_perl-1.29/
# perl Makefile.PL USE_APACI=1 APACHE_SRC=../apache_1.3.41/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACI_ARGS=’–prefix=/usr/local/apache/ –activate-module=src/modules/php5/libphp5.a –enable-module=so –enable-module=ssl –enable-module=rewrite’

Compilar:
# make
# make install

OK, 2 minutos depois e temos um novo httpd em /usr/local/apache/bin/httpd

Agora que temos um httpd recheado de símbolos, vamos dizer ao Apache onde jogar os core dumps.

Edite o seu httpd.conf:
# vi /usr/local/apache/conf/httpd.conf

Adicione :
# 2008-05-27 problema com segmentation fault
CoreDumpDirectory /usr/local/apache/coredump/

Salve(no vi é com :wq!) e reinicie o Apache

# /usr/local/apache/bin/apachectl restart

( Veja a linha antes de CoreDumpDirectory, a deixei lá de propósito. É sempre bom comentar as alterações para, no futuro, você lembrar que nesse dia você apanhou um bocado ;). Falando sério: hoje você lembra por que editou o httpd.conf, mas daqui a 6 meses você talvez fique na dúvida de por que a diretiva de core dumps está alí. Por via das dúvidas, comente seus arquivos de configuração. Eu utilizo sempre o mesmo formato de datas aaaa-mm-dd para poder fazer buscas no futuro por anos ou meses aproximados. )

Agora aguarde o servidor cair! No meu caso foi quase instantâneo. Vou até o diretório de core dumps e não encontro qualquer arquivo core apesar das falhas repetidas do servidor…. São os efeitos da falta de sono, esquecí de permitir os core dumps aumentando o ulimit -c. Como ulimit -c 0 os core dumps ficam desligados….

# ulimit -c 10240

Damos um ulimit de 10 MBytes para tamanho máximo de arquivos core. Agora reiniciamos o Apache, e não demora encontro lá os arquivos core.nnnn. Vamos examinar o core.1035 para ver onde foi a pane:

# gdb ../bin/httpd -c core.1035
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i686-pc-linux-gnu”…

[... um apanhado de saída, até chegar em ....]

Program terminated with signal 11, Segmentation fault.
[New process 1045]
#0 0×084b739c in Perl_av_undef ()

OK, o que será que houve em Perl_av_undef() ??? Esse tempo todo desconfiando do MySQL e o culpado era o núcleo do Perl ???!

A julgar pelo nome, Perl_av_undef() parece ser uma rotina de limpeza(undef) de arrays(AV = Array Value). Sem mais chutes pesquiso no Google e descubro que não se trata de um bug do Perl e sim de uma limitação imposta pelo sistema através do ulimit. Quando o Perl tenta limpar uma estrutura de dados complexa, arrays de arrayrefs contendo referências a objetos ou hashrefs, por exemplo, ele pode gerar uma grande quantidade de chamadas recursivas. A recursividade é uma ferramenta poderosa, mas que às vezes deve ser substituída por outras técnicas para poupar a pilha. A recursividade é quase sempre uma saída elegante, porém nem sempre a mais eficiente. A cada chamada o Perl empilha mais valores na stack, eventualmente estourando a pilha e causando uma Segmentation Fault(sinal 11). Quem derruba o programa é o próprio kernel, e isso não é um bug, é uma característica de sistemas que impedem processos de levarem a máquina toda consigo no caso de perda de controle.

Então vamos verificar o tamanho atual da pilha. Vamos aproveitar e verificar outros valores-limite para sabermos em que chão estamos pisando.

#ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 16253
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 16253
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Temos uma pilha de 10 MBytes, o que nem sempre é suficiente. Vamos exagerar um pouco para testar nossa tese, se aumentarmos para 100 MBytes teremos a chance de ver se os core dumps deixam de acontecer.

# ulimit -s 102400

Verificamos se deu certo com:

# ulimit -s
102400

OK, temos 100 MB autorizados pro Perl fazer a festa na pilha. Vamos reiniciar o Apache e ver se funciona.

# /usr/local/apache/bin/apachectl stop
# /usr/local/apache/bin/apachectl start

Prefiro o stop e start explícitos quando estou testando, para eliminar a possibilidade de alguma memória permanecer alocada do processo anterior. Pode ser só paranóia, mas vamos adiante. Temos que aguardar alguns instantes para testar a estabilidade do novo ambiente que demos ao Apache.

OK, após 5 minutos verifico que os Segmentation Faults continuam acontecendo…só que, conforme veremos, desta vez o culpado não é mais o Perl_av_undef()

Vamos examinar um dos novos arquivo core.nnnn para tentar descobrir quem é o culpado desta vez.

# gdb /usr/local/apache/bin/httpd -c core.1047
[... cortado ...]
Program terminated with signal 11, Segmentation fault.
[New process 1047]
#0 0×00b9e46b in mysql_ping () from /usr/local/mysql//lib/mysql/libmysqlclient.so.15

Opa! mysql_ping() ….estamos voltando ao principal suspeito, desde o início o servidor caía perto de alguma chamada ao MySQL no código Perl. Vamos ver o que ocorre logo antes do mysql_ping() usando o comando where do gdb.

(gdb) where
#0 0×00b9e46b in mysql_ping () from /usr/local/mysql//lib/mysql/libmysqlclient.so.15
#1 0×004d99f2 in XS_DBD__mysql__db_ping (cv=0×94d2680) at mysql.xs:519
#2 0×001edbf4 in XS_DBI_dispatch () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/DBI/DBI.so
#3 0×084bfa43 in Perl_pp_entersub ()
#4 0×084be32e in Perl_runops_standard ()
#5 0×084ba15d in Perl_call_sv ()
#6 0×0043ae8f in EMBPERL2_CallStoredCV () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#7 0×00453cf0 in embperl_Execute () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#8 0×0045a008 in ProviderEpRun_GetContentIndex () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#9 0×0045891a in Cache_GetContentIndex () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#10 0×00434a63 in ProcessFile () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#11 0×004355da in embperl_RunRequest () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#12 0×00435b8c in embperl_ExecuteRequest () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#13 0×0043233f in XS_Embperl__Req_ExecuteRequest () from /usr/lib/perl5/site_perl/5.10.0/i686-linux/auto/Embperl/Embperl.so
#14 0×084bfa43 in Perl_pp_entersub ()
#15 0×084be32e in Perl_runops_standard ()
#16 0×084ba15d in Perl_call_sv ()
#17 0×08371d3b in perl_call_handler (sv=0×96a8d20, r=0×9541c14, args=0×0) at mod_perl.c:1668
#18 0×083723f9 in perl_run_stacked_handlers (hook=0×85ef03b “PerlHandler”, r=0×9541c14, handlers=0×96a8cb0)
at mod_perl.c:1381
#19 0×08373861 in perl_handler (r=0×9541c14) at mod_perl.c:904
#20 0×08395497 in ap_invoke_handler (r=0×9541c14) at http_config.c:476
#21 0×083acd2f in process_request_internal (r=0×9541c14) at http_request.c:1299
#22 0×083ad1a0 in ap_internal_redirect (new_uri=0×951427c “/index.html”, r=0×9512ae4)
at http_request.c:1440
#23 0×00386fe4 in mod_gzip_redir1_handler () from /usr/local/apache/modules/mod_gzip.so
#24 0×00385219 in mod_gzip_handler () from /usr/local/apache/modules/mod_gzip.so
#25 0×08395497 in ap_invoke_handler (r=0×9512ae4) at http_config.c:476
#26 0×083acd2f in process_request_internal (r=0×9512ae4) at http_request.c:1299
#27 0×083acd8c in ap_process_request (r=0×9512ae4) at http_request.c:1315
#28 0×083a2ef6 in child_main (child_num_arg=12) at http_main.c:4971
#29 0×083a3227 in make_child (s=0×87be05c, slot=12, now=1211894763) at http_main.c:5150
#30 0×083a32c2 in startup_children (number_to_start=23) at http_main.c:5178
#31 0×083a3a66 in standalone_main (argc=3, argv=0xbfe95934) at http_main.c:5525
#32 0×083a434f in main (argc=3, argv=0xbfe95934) at http_main.c:5883

Lendo de baixo pra cima, o where nos dá um trace de pilha completo desde a função main() até o mysql_ping().

Sem mais demora, jogo a consulta no Google e o resultado é que mais alguém acaba de ter o mesmo problema há apenas 1 semana!

E o culpado é???? O DBD::mysql v. 4.007, que foi um dos primeiros módulos que atualizamos no servidor de produção ainda ontem! Confira o report do bug MySQL clicando aqui.

Solução: regredir para a versão 4.006. Como fazer isso se o CPAN sempre busca a última versão? É simples.

Vá até a página do DBD::mysql no endereço http://search.cpan.org/dist/DBD-mysql/.

Na caixa “Other Releases” escolha a versão anterior(4.006) e clique em Goto.

Quando a página recarregar, o link Download apontará para a versão escolhida. Baixe-a, extraia com

# tar xzvf DBD-mysql-4.006.tar.gz
# cd DBD-mysql-4.006
# perl Makefile.PL
# make
# make install
Reinicie o Apache para ler o DBD::mysql antigo
# /usr/local/apache/bin/apachectl restart

E, pelo menos até o momento, os problemas de segmentação acabaram.

Conclusões

1) Os módulos de um servidor que se propõe a ser padrão industrial tem que ser melhor testados. O bug é crasso, é primário. O módulo tenta executar um mysql_ping() e derruba o processo todo. A MySQL, recém comprada pela Sun, vai ter que efetuar um controle de qualidade mais eficiente.

2) O apache 1.3 está sendo lentamente abandonado, porém ele poderia ter um sistema de gerenciamento de erros mais “civilizado”. Ninguém tem o luxo de passar 20 horas no GNU Debugger verificando stack traces, recompilando programas gigantescos e tentando montar quebra-cabeças.

3) Não confie cegamente em updates. Efetue um update de cada vez e teste o sistema novamente. Se eu tivesse testado o sistema após o update do DBD::mysql, ao invés de atualizar o CPAN todo, eu saberia que o culpado era o DBD::mysql. Nunca tinha tido problemas com um módulo do CPAN, por isso deduzí logo se tratar de algum conflito de bibliotecas compartilhadas.

4) Aumente a pilha para processos que irão rodar durante longos períodos. Apenas 10 MB de pilha para servidores Apache, MySQL ou Oracle é muito pouco. Vimos que o DBD::mysql não era o único culpado pelos Segmentation Faults do Apache. Aumentei o ulimit da pilha para 204800 KBytes(200 Megas) para garantir.

5) Problemas entrelaçados, como a stack pequena e o bug do MySQL combinados, podem causar muita confusão. Quem imaginaria que os 2 ocorreriam ao mesmo tempo e se manifestariam da mesma forma?! As mensagens no log são idênticas, não há diferença. Se não tivesse me dado o trabalho de compilar o Apache com símbolos e estudado o stack trace no gdb, eu pensaria que os primeiros core eram problema do MySQL. Aliás, durante boa parte da resolução do problema eu achava que as bibliotecas MySQL eram as únicas culpadas.

Já faz 1 hora e 30 minutos que restabelecí o serviço e não vejo qualquer SEGFAULT registrado. Agora vem a parte difícil, explicar pra minha chefe tudo isso…..

A Traveler acaba de lançar um serviço grátis feito especialmente para blogueiros e webmasters : o Nomezin.

Conforme o próprio nome sugere, o Nomezin lhe permite criar endereços curtos e fáceis de lembrar para seu blog ou site, sendo possível acessá-lo através desse novo endereço(”o Nomezin”) sempre que precisar.

É muito comúm que endereços WWW muito longos sejam quebrados em alguns sistemas de email. Com o Nomezin você cria um “alias” para seu nome com apenas alguns caracteres e envia esse novo endereço ao invés do anterior. O Nomezin faz o resto pra você.

Confira um exemplo:

O seguinte endereço: http://traveler.com.br/?ad=2342&csum=df89fg89d78g7sd89f7897bn890n89asdf45sfg65456x&v=1

Fica assim http://cuidamos.de/voce

Blogueiros e webmasters não deixem de conferir!

Inspirado pelo GP de Mônaco, fúi procurar vídeos da F1 no YouTube. Depois de ver alguns tive a certeza de que há algo de errado com a F1 de hoje em dia. Todo mundo da Fórmula 1 está de cara emburrada, parece que tá tudo nos contratos e no dinheiro e não há mais espírito esportivo alí. Foi bom ver a festa do Hamilton no final, porque a cara do Massa e do Kubica no pódio parecia de velório.

Parei quando encontrei esse vídeo aí embaixo. O homi não mede pra falar… Vale uma boa risada, e vá ser azedo assim lá na…..

Você talvez ache o titulo provocativo. Afinal de contas, o iPhone é o que há. Um telefone espetacular, rápido, com design lindo e um sistema operacional Unix top de linha. Acontece que a Apple negligenciou os desenvolvedores de software para o iPhone, e isso é um erro fatal para qualquer plataforma, por melhor que seja. Além do mais, o lançamento do iPhone no Brasil foi um desastre. Esperaram até que o aparelho ficasse obsoleto para lançá-lo num dos países com maior número de celulares do mundo, além de uma das maiores populações de usuários de internet. Enfim, se a Apple não melhorar, eles conseguirão repetir um erro do passado: ter a melhor tecnologia e jogá-la fora por egocentrismo do Steve Jobs e miopía de mercado.

iPhone chega ao Brasil obsoleto

O site Gizmodo.com anuncia que a Apple confirmou para dia 9 de Junho o lançamento do “iPhone 2″ com tecnologia celular de 3a geração. Segundo a mesma fonte, o lançamento será em escala mundial.

Ou será que vamos ficar esperando aqui até a Claro ou TIM decidirem trazer o aparelho?

O “iPhone 1.0″ no Brasil foi a história de sucesso mais atrapalhada que já vimos de tempos pra cá. O iPhone não foi lançado aqui mas todo mundo(menos eu) já tem um. Nenhuma operadora suportava o iPhone, mas todo mundo destravou o seu. Não existiam lojas oficiais do iPhone, mas todo mundo comprou em algum lugar!

Ninguém soube me explicar ao certo a miopía da Apple com relação ao Brasil. Qual o problema deles com o Brasil? Anunciaram que a Claro ainda vai trazer o iPhone 2G ao Brasil, mas eles já anunciaram a versão 3G?

No Mercado Livre.com, ao procurar pelo iPhone, você encontra nada menos que 899 resultados.

Ou seja, o iPhone já corre solto no mercado Brasileiro enquanto que a Apple ainda está tentando fechar negócio com um distribuidor nacional. Só podemos concluir que a pesquisa de mercado da Apple com relação ao Brasil estava completamente errada.

O iPhone pode falir pelos mesmos erros que a Apple cometeu no passado. Acredite se puder.

Além do erro de marketing no Brasil, na minha opinião, a Apple cometeu 2 erros enormes estratégicos com o iPhone. E, pelo visto, não tem a menor intenção de corrigí-los. São 2 erros que a história não perdoa: fechar a plataforma de desenvolvimento com sua tecnologia, e utilizar uma linguagem de desenvolvimento exótica que ninguém usa. O sucesso de longo prazo de todas as tecnologias depende da base de desenvolvedores que se forma em torno delas. Os desenvolvedores não aparecem muito no marketing, mas são eles que criam os jogos para os consoles de videogames, são eles que criam os aplicativos que nos prendem à determinada tecnologia, são eles que perpetuam uma tecnologia nos foruns, nos grupos de discussão e nos CPD’s do mundo afora.

Erro 1: prender a plataforma de desenvolvimento a hardware e software proprietário

Fizeram uma baita festa, bem ao estilo Steve Jobs. Anunciaram o SDK para o iPhone e eu fúi um dos primeiros a me cadastrar para baixá-lo. Maravilha, 180 MB de download depois descubro que o SDK só roda em MacOS X. Fecharam o desenvolvimento de software para o iPhone à sua plataforma. Se você quiser desenvolver pro iPhone em outro sistema, como Linux, terá que usar uma gambiarra distribuída à parte. Da Apple você não terá suporte. 89% dos computadores do mundo rodam Windows, e a Apple lançou um treco que só roda em MacOS X. Ou seja, você pode usar o iPhone no Windows mas para desenvolver programas pra ele você tem que comprar um computador Apple.

Exemplos de fracassos do passado: Atari e….adivinhem….Apple! A Atari tentou forçar os desenvolvedores de jogos a usar sistemas Atari para o desenvolvimento. Fracassaram. Enquanto isso a Nintendo abriu para todo mundo e a Atari acabou. A Apple tentou forçar todo mundo a usar o Macintosh para tudo, fechou o hardware e o desenvolvimento de software. Resultado? IBM e Bill Gates abriram o IBM PC para todo mundo e o Macintosh sumiu. O Macintosh só sobreviveu esses anos todos graças ao nicho de mercado de design e ilhas de edição de vídeo. Só com o iPod a Apple ganharia outra chance, quase 20 anos depois. Do iPod veio o iPhone, e justamente quando tem a melhor chance de se dar bem, a Apple comete exatamente o mesmo erro de novo.

Erro 2: ceder ao egocentrismo de Steve Jobs e usar uma linguagem de programação que ninguém quer

Para piorar, ainda querem obrigar todo mundo a aprender a linguagem Objective C que absolutamente ninguém quer aprender(nem deve). É uma aberração da linguagem C, acrescida de uma gambiarra para suportar objetos. O mercado hoje tem milhões de programadores Java, mas a Apple não quis Java. Tem milhões de desenvolvedores C dispostos a trabalhar até de graça(Linux, Apache, etc). Pois sim. A Apple escolheu a linguagem Objective C como padrão oficial do iPhone. Sabem quem é que vai comprar livros de Objective C para programar iPhone quando existem tantas linguagens bem difundidas? Ninguém.

Conclusão: Google(gPhone) recebe um passe de ouro, sozinho, na pequena área da Apple

Previsão do Blog do Zé: Se o Google tiver visão estratégica, como sabemos que tem, o Android vai “traçar” o iPhone.

A Google vai lançar uma versão em linguagens que todo mundo usa(Python, Perl, C e Java) e o SDK do Android já funciona em qualquer plataforma popular(Windows, Mac e Linux), em qualquer tipo de hardware. O Android(SDK do gPhone) foi lançado com antecedência para gerar uma base de desenvolvedores treinada. Quando o gPhone chegar ao mercado haverão milhares de programadores já treinados, usando qualquer plataforma e qualquer linguagem de programação para criar aplicativos gPhone.

Com o atual sucesso do iPhone você talvez não acredite que seja possível derrotá-lo. Mas a história mostra o contrário. Erros que a Apple cometeu no passado podem impedir o sucesso do iPhone. Podem ter certeza que, se a Apple não abrir sua plataforma de desenvolvimento, o iPhone vai ser mais uma excelente tecnologia que faliu por não enxergar que os desenvolvedores é que fazem uma tecnologia se perpetuar. Por isso é que o OS/2 da IBM sumiu e o Unix continua aí 40 anos depois : a IBM fechou o OS/2, e hackers de todo o mundo abriram o Unix.

Se a Apple não mudar sua postura arrogante com os desenvolvedores de software, podem escrever a previsão do Blog do Zé: o iPhone subiu no telhado. Preparem-se pro Android.

O que significam essas nuvens 30 minutos antes do terremoto? Mensagem divina? Teste nuclear mal sucedido?

Alguns comentaristas de um fórum na Internet acreditam que isto explica as luzes(não achei versão em português).

Outros acham que se trata de um fenômeno especial de refração de luz entre gotas d’agua, científicamente conhecido por “arco iris”.

Seja o que for, da próxima vez que você ver nuvens coloridas, saia debaixo de concreto, corra para o meio de um campo e fique lá por, no mínimo, 45 minutos.