(sudo) rm -rf /

Bom, quem usa linux já ouviu falar (e talvez até tenha ficado um pouco curioso) sobre os efeitos do "rm -rf /" em modo root... os geeks de plantão sabem, mas em todo o caso, "rm -rf /" conhecido por touch of death é um comando que simplesmente diz para o linux remover todos os arquivos começando pelo raiz e descendo nos subdiretórios recursivamente. Como o linux depois que carrega um programa em memória deixa o executável dele liberado (o Windows 98 não deixa remover um arquivo que está em execução, os XP, 2000 e Vista eu não testei como se comportam), esse comando vai
se remover, vai remover o shell, vai remover todo o sistema.

Confesso que quando ouvi falar desse cara, fiquei com uma pequena curiosidade para saber o que aconeteceria... mas nunca achei que o esforço fosse compensar a curiosidade. Até que... algum desocupadodesbravador resolveu publicar um vídeo com os efeitos do rm -rf /



Bom saber que o gatinho sobreviveu!

Bom, depois de umas férias não tecnológicas (6 dias sem internet e praticamente sem celular), a contagem de mortos e feridos ficou em 69 emails, 28 spams, 298 feeds e 12 comics não lidos... e como não acho que vou conseguir zerar esses contadores hoje, e vou para mais um recesso tecnológico até o próximo ano agora (tô me sentindo muito radical! e reusando descaradamente todas as piadas já batidas, gastas e desbotadas de final de ano!), acho que a situação tende a piorar!

Anyway, como não devo postar mais nada e nem entrar no MSN, feliz 2008!!!

Achmed

Me falaram desse vídeo um tempo atrás, vi ele ontem. Muito bom! Vale a pena gastar os 11 minutos assistindo :).



Allah dammed! I kill you!

Enfeite de Natal geek

Eu não ia fazer 2 posts no mesmo dia, mas isso me chamou a atenção...



A explicação tá em ingles, mas mesmo que não entenda, a imagem já é interessante. Basicamente, o cara usou LEDs e um ventilador (com um pequeno toque de microcontrolador) para fazer um enfeite de natal. O microcontrolador fica acionadno os LEDs numa determinada seqüência enquanto a hélice do ventilador está girando, causando um efeito interessante...

Tentar lembrar de fazer algo assim no próximo natal ;)

Bug do ano 2038 e segundo bissexto

Pra começar o post, vi uma tirinha do LibMan e APIBoy, com uma pequena referência ao bug do ano 2038. Bug do ano 2038?! Isso que eu chamaria de evolução no planejamento de software. Eu ainda não consigo nem saber que features vão ser implementadas no TAF no próximo ano, e já tem gente sabendo que bugs vão existir em 2038! Bom, parando com a brincadeira. Quem não conhecia e ainda não seguiu o link para o segundo guru da internet (wikipedia), o bug do ano 2038 é basicamente um problema para quem usa representação de datas estilo POSIX (e quem não usa???), onde a data é representada pelo número de segundos passados desde o início da era, no caso, 1-Jan-1970. O problema é que esse valor é representado por um inteiro sinalizado de 32 bits. Mas por que usar uma representação de datas usando inteiros de 32 bits e com sinal? Primeiro, lá em 1985, mais ou menos quando o POSIX foi lançado, acho que parecia bastante lógico que 2147483647 de segundos no futuro nenhum daqueles computadores estariam em uso, então, pra que se preocupar? Afinal, no ano 2000 já teríamos carros voadores, computadores com uma inteligência praticamente humana, no melhor estilo HAL, ponte aérea (??) entre a Terra e Marte, etc, não havia a menor chance de ainda usarmos os obseletos computadores de 32 bits - que ainda nem existiam. Mas tudo bem, podiam ter pelo menos colocado um unsigned na frente do time_t, né? Não exatamente. E como ficariam as datas antes de 1970? Certo, a decisão de usar signed int parece bem razoável. Então, assim como em 2000, os sistemas que usam datas vão entrar em colapso, certo? Bom, mais ou menos. É possível que se nada for feito, o segundo seguinte a data 03:14:07 de 19-Jan-2038 será 13-Dez-1901, 20:45:42. Ei, mas já estamos colocando processadores 64 bits agora, até 2038 ninguém mais vai usar 32 bits, certo? Eu espero que sim, mas existem algumas indicações contrárias. Já com o negócio do bug do ano 2000, vários sistemas extremamente legados, ainda em Cobol e fortran, ainda estavam em utilização, e recodificar alguns bugs pode não ser uma opção adotada por algumas empresas, para reduzir o custo. Além disso, temos os vários sistemas embutidos (ou embarcados - esse último parece ser o termo mais utilizado, mas tem algo nele que eu não gosto. Pessoal da área de embedded systems, qual o certo?) que provavelmente não usam 64 bits, e muito provavelmente vão continuar em operação até além de 2038. Só espero que os sistemas que controlam aviões, satélites, e outras coisas grandes que correm um risco de cair nas nossas cabeças não sofram nenhum efeito colateral sério por causa desse bug, assim como sistemas de monitoração de usinas nucleares e outras coisas que possam fazer um "grande boom". E também, mudar para 64 bits não resolve o problema, só posterga para 4 de dezembro de 292.277.026.596 as 15:30:08, mas aí acho que podemos deixar para as futuras gerações resolverem, ou postergarem ainda mais usando 128 bits ;).

Bom, e o que isso tudo tem relacionado com segundos bissextos? Nada, na verdade, exceto que a contagem de segundos na data POSIX não leva em consideração os segundos bissextos. Eu só achei um termo novo e resolvi comentar :D. Já é de conhecimento natural que a cada 4 anos temos um ano bissexto, que inclui um dia extra em Fevereiro. Essa acho que é uma das maiores gambiarras da humanidade. Ao invés de fracionar as unidades de tempo de forma a todo ano ficar bem alinhado, a preguiça imperou e inventaram esse negócio de incluir um dia a mais em alguns anos para "limpar" a imprecisão. Bom, é da natureza humana ir pelo lado mais fácil, por isso, eu simplesmente critiquei a solução e nem procurei saber se existe alguma forma de fazer um fracionamento exato ;). Mas parece que mesmo a divisão do dia em 86400 segundos não é lá muito preciso. Na verdade, dessa vez a culpa é da própria Terra. A cada século, o dia solar (que não respeita nossos relógios) fica 1,7 milissegundos maior, ou seja, daqui a 6 séculos, nossos dias terão 1 segundo a mais. Mas, a nossa divisão de datas continua 1 dia * 24 horas * 60 minutos * 60 segundos, sem espaço para esse segundo adicional, então fizeram esse negócio de segundo bissexto. Em alguns anos específicos é inserido 1 segundo a mais, sincronizado mundialmente. Normalmente, esse segundo adicional é colocado no dia 30-Junho ou 31-Dezembro. No caso, quando o relógio em UTC chegar a 31-Dez, 23:59:59, ao invés de mudar para 01-Jan, 0:00:00, ele primeiro vai para 31-Dez, 23:59:60, e depois para 0:00:00. Esse ajuste é feito simultaneamente em todo o mundo, por um sistema de difusão, ou seja, aqui no Brasil o ajuste é feito as 21:59:59, considerando o horário de verão. Agora eu me pergunto, será que meu relógio de pulso se ajusta automaticamente em relação a segundos bissextos? Se não, acho que descobri porque em 2005 ele estava errado em 1 segundo.

Só pra constar, os últimos 10 anos que sofreram ajuste de segundo bissexto foram: 2005, 1998, 1997, 1995, 1994, 1993, 1992, 1990, 1989, 1987.

Computadores a luz!

Apesar de muita gente ainda usar no dia-a-dia luz como sinônimo de energia elétrica (quem nunca ouviu a célebre frase "faltou luz" quando o fornecimento de energia elétrica é interrompido durante o dia, as vezes com certa abundância de luz solar?), a "luz" nesse caso é luz mesmo, fótons e cia.

A IBM está anunciando um modulador eletro-óptico de silício Mach-Zehnder (do inglês silicon Mach-Zehnder electro-optic modulator), que basicamente converte pulsos elétricos em ondas luminozas. A principal vantagem é transmissão de dados sem fio dentro de um processador, reduzindo custo de produção - bom, depende de quanto custar esse modulador, na verdade - e principalmente, como não haverá resistência na transmissão elétrica, as perdas com transmissão de dados reduzem bastante, e o consumo de energia reduz também. Fala-se em 4 mil núcleos de processamento em um notebook - imagino que com a duração de 2 ou mais horas de bateria. Até agora, estão falando apenas em usar essa tecnologia dentro do processador. Todos os barramentos externos aparentemente continuam usando o bom e velho sinal TTL ou CMOS.

Estava pensando, quanto tempo até tornarem toda a comunicação interna de um PC baseada em luz? Quer dizer, parece meio estranho o caminho que a coisa vai tomar.
Um sinal elétrico de algum periférico ou placa PCI e afins chega até o processador, é convertido em luz, o processador reage ao estímulo, bota no barramento de saída, o sinal é demodulado pra sinal elétrico novamente, vai para algum periférico. Até entendo a comunicação com HDs, leitores de CDs, etc ser baseada em pulsos elétricos por uma questão de alinhamento e simplicidade para montar (bom, mais ou menos, não seria possível usar fibra-óptica?), mas a comunicação processador-memória, barramento-processador, barramento-memória, basicamente toda a comunicação interna de uma placa mãe poderia ser totalmente baseada nessa tecnologia, não? De qualquer forma, acho que o negócio agora é esperar isso ficar barato suficiente para chegar até nossas casas. Enquanto isso, vou ficar pensando no problema "o que fazer com o poder computacional de 4 mil cores?" (um passo mais próximo de dominar o mundo, mwahahahaha!)



Fonte: Meio Bit

10 dicas para reduzir o esgotamento mental

Pra quem não conhece, o lifehacker é um site muito bom sobre produtividade, e outras dicas em geral. Já passaram por lá assuntos sobre como melhorar a qualidade do sono, técnicas de "GTD" (Getting Things Done), eficiência, dentre outras coisas boas. Dessa vez um artigo (em inglês) bastante interessante sobre brain drain (algo parecido com esgotamento mental) surgiu lá.

O brain drain é algo que eu "experimento" algumas vezes durante o mês. Normalmente acontece quando a pessoa está muito ocupada por um tempo bastante longo. As vezes no trabalho isso acaba acontecendo comigo, e com o mestrado ainda tem um agravante. Infelizmente não descobriram ainda a bolha de tempo, uma cápsula (?!) usando algumas caracteristicas da malha do espaço-tempo, e alguns fundamentos da mecânica quântica e teoria da relatividade geral onde alguém entraria, passaria tempo suficiente para fazer tudo que precisa, e quando saísse teriam passados apenas alguns minutos ou segundos no "mundo real". Claro, teria o efeito colateral que você envelheceria muito mais rápido se usar muito essa bolha, mas acho que se pesar bem as coisas, valeria a pena. A gente pode sonhar, não? De qualquer forma, sem essa bolha, as vezes nos sentimos "pressionados" a fazer 1 semana de trabalho em 1 dia, e isso acaba levando ao brain drain. Não sei as conseqüncias disso a longo prazo, mas quando eu percebo os sintomas de brain drain normalmente percebo que minha produtividade cai bastante, eu me irrito bem mais fácil com as pessoas, entre algumas outras coisas desagradáveis. No artigo comentam que isso pode levar ao stress!

Se você já tem problemas com brain drain, o artigo é bastante interessante. Nele são dadas 10 dicas de como voltar ao normal quando você percebe que está chegando perto do esgotamento. Vou resumir elas aqui.

1. Meditação - ficar uns 20 minutos deixando o cérebro em stand by, somente observando os pensamentos que tendem a aparecer, sem focar em nenhum deles. Isso é bem mais fácil dito do que feito, é verdade, mas mesmo que você não consiga um estado meditativo 100% eficiente, já vale a pena, pode acreditar.


2. Dar uma caminhada - o efeito aqui é basicamente tirar o foco do cérebro para alguma outra função, deixando ele relexar um pouco.


3. Ouvir música clássica - bom, quem não gosta acho que não vai ter benefício nenhum, mas quem gosta sabe do "poder" relaxante de Mozart, Beethoven, Bach e cia.


4. Ler algo interessante - apesar de parecer contraditório, ler pode mesmo relaxar o cérebro, desde que não seja algo técnico ;)


5. Reiniciar o cérebro com uma caffeine nap - Essa eu confesso que nunca testei. Mas parece que alguns estudantes desesperados por projetos de mestrado fizeram alguns estudos em universidades e chegaram a conclusão que tomar uma xícara de café e logo em seguida tirar uma soneca de 10-15 min liga o "turbo" do cérebro.


6. Ver um filme - se você conseguir umas 2h para ir ver algum filme...


7. Ouvir CDs motivacionais - Esse parece meio estranho também, mas esses CDs costumam por o cérebro em um modo robótico em que ele se preocupa basicamente em pegar as informações prontas, então menos trabalho para ele ;)


8. Praticar algum esporte - a técnica basicamente é mover a fadiga do cérebro pro corpo. Essa eu tenho experiência. Diversas vezes que eu saí do trabalho com vários sintomas de fadiga mental jgoar o voleizinho sagrado resolveu o problema muito bem.


9. Divide et impera - pra que fazer tudo de uma vez? Divide o problema em partes e resolve cada uma de maneira simples...


10. Jogar algum jogo - sim, jogadores viciados, não é esporte mesmo, é dar atenção ao Wii, ao
    PS 3, Xbox, PC, PS 2, etc. Pronto, agora ganhei uma desculpa pra passar mais horas jogando no PC :D. Quem não é muito fã desse tipo de jogo, no artigo falam que Sudoku (pronúncia normal é algo parecido com suudóku - diz a wikipedia ;)) ou palavras cruzadas são excelentes também para reduzir a fadiga.

Espero que as dicas ajudem alguém ;).

Boa sorte!

Piadinha boa para variar um pouco

Um casal tinha dois filhos, que eram terríveis. Os pais sabiam que, se
houvesse alguma travessura onde moravam, eles com certeza estariam
envolvidos. A mãe dos garotos ficou sabendo que o novo padre da cidade
tinha tido bastante sucesso em disciplinar crianças. Então ela pediu a
ele, que falasse com os meninos. O padre concordou, mas pediu para vê-los
separadamente.A mãe mandou o filho  mais novo.
O padre, um homem alto com uma voz de trovão, sentou o garoto e
perguntou-lhe austeramente:
- Onde está Deus?
O garoto abriu a boca, mas não conseguiu
emitir nenhum som. Ficou sentado, com a boca aberta e os olhos
arregalados. Então, o padre repetiu a pergunta num tom ainda mais severo:
o garoto não conseguia emitir nenhuma resposta. O padre levantou ainda
mais a voz, e com o dedo no rosto do garoto berrou:
- ONDE ESTÁ DEUS?
O garoto saiu correndo da igreja direto pra casa e trancou-se no quarto.
Quando o irmão mais velho o encontrou, perguntou:
O que aconteceu?
O irmão mais novo, ainda tentando recuperar o fôlego, respondeu:
- Cara, desta vez tamo fudido. Deus sumiu, e acham que foi a gente.

Piada enviada pelo mestre João Amorim

--
Otavio Pereira
otaviofp@gmail.com
---------------------------
Programmer (def): An organism that converts caffeine into software.
"Why are we all forced to go to work at the same time? Who arbitrarily decided that 8 AM was a good time for everyone to go to work?" (Dilbert)

To final or not to final? That is the question...

Essa frase Shakespeareana provavelmente já rendeu mais trocadilhos do que qualquer outra frase na história da humanidade. Mas é incrível a quantidade de situações que ela se aplica, não? De qualquer forma, o motivo do post não é discutir Shakespeare, mas sim a palavra chave final do Java.

A maioria dos desenvolvedores em Java estão bastante acostumados em ver esse carinha associado com sua quase comanheira de longa data static para formar constantes. Constantes em Java além de permitir algum grau a mais de manutenção e prevenção de bugs ajudam o compilador a fazer algumas pequenas otimizações. Como assim "constantes ajudam na manutenção e prevenção de bugs"? Simples, vamos supor que precisamos desenvolver uma classe com diversas funções de manipulação de circunferências. Nessa classe provavelmente vamos usar uma porção de vezes a constante matemática PI. Se a cada vez que fôssemos usá-la fosse necessário escrever o literal 3.14159 aumentamos muito o risco de usar valores diferentes de PI em métodos diferentes. Imagine que um desenvolvedor novato precisou codificar o método para calcular a área do circunfência, e usou 3.1415 como valor de PI, e um outro desenvolvedor fez um método para calcular o perímetro da circunfêrencia e usou o valor de PI como 3.14, afinal ele é um desenvolvedor mais experiente e sabe que 2 casas de precisão são suficientes para o projeto (!?). Alguém que fosse usar as 2 funções em momentos diferentes poderia ter resultados diferentes. Já temos a "precisão" característica do ponto flutuante, e ainda introduzimos uma variação nos próprios valores usados nos cálculos. Nada bom pode sair disso. A solução aqui é bastante trivial: definir uma constante final static PI, e usá-la ao invés do valor hardcoded de pi. Na verdade, uma solução melhor é usar a constante PI da classe Math do Java ;). Mas esse tipo de coisa não prejudica a performance? Não, pois o compilador do Java na primeira passada da compilação (são 3, acho) ele troca as referências das constantes de tipos primitivos e Strings pelos valores declarados, então o efeito no código é o mesmo de ter os valores hardcoded. Mas por que só primitivos e String? As demais variáveis são referências, o código ficaria incorreto:

private static final Pessoa GERENTE = new Pessoa("Gerente");

...
public void desenvolvedorFezMerda(Pessoa desenvolvedor) {
GERENTE.mata(desenvolvedor);
}

public void desenvolvedorEntregouAntesDoPrazo(Pessoa desenvolvedor) {
GERENTE.parabeniza(desenvolvedor);
}
}


Se o compilador substituísse a refeência da constante GERENTE, os 2 métodos usariam uma instância diferente da classe Pessoa, o que não estaria de acordo com a lógica do código fonte.

Mas essa característica de inline de constantes pode trazer alguns problemas para desenvolvedores descuidados. Suponha que você colocou uma constante public static final int MAX_VALUE = 100 numa classe de sua biblioteca. Alguma aplicação externa faz uso de sua biblioteca e em certo momento faz uma comparação (value > MAX_VALUE). Como Murphy ainda impera na informática, algum tempo depois que o código entrar em produção vai surgir a necessidade de um value maior que 100 ser usado em uma condição válida. Solução óbvia: redefine o valor da constante MAX_VALUE (supondo que não há nenhuma outra lógica que impeça isso), recompila a biblioteca, troca o JAR na aplicação do cliente e voilà, tudo pronto, certo? Errado. No momento que a aplicação foi compilada o Java trocou MAX_VALUE por 100, então a alteração não faz efeito sem uma recompilação da aplicação.

Mas o uso do final não é restrito a membros static nas classes para evitar coisas hardcoded simplesmente. Na verdade, o final pode aparecer praticamente em qualquer lugar, e em alguns lugares ele deve aparecer. Um pouco sobre a biografia do final:

final, s.m.: Texto da família palavras-chave, do gênero Java. Pode ser visto habitando classes não abstratas, métodos, parâmetros e variáveis locais em códigos Java.

Na verdade, o final tem várias aplicações em um código Java. Declarar uma classe como final é equivalente a dizer ao compilador que a classe está completa e não pode dar origem a subclasses. Exemplos de uso seriam para classes utilitárias, onde gerar subclasses pode levar a sobreescrição de métodos importantes, ou classes singleton, etc. De uma forma genérica, todas as classes que definem apenas construtores private são automaticamente final. Eu particularmente não recordo de algum caso em que o uso do final fosse importante em alguma classe. Talvez classes que validam restrições de segurança devem fazer bom uso desse cara, para evitar que algum código malicioso troque em tempo de execução uma instância de um autenticador de login, por exemplo. Algo bastante óbvio que surge da característica do final é que não é possível declarar uma classe simultaneamente abstract e final, pois o último modificador não permite a geração de subclasses e o primeiro exige que uma subclasse complete alguns métodos não definidos.

Um outro lugar onde é possível usar o final é na declaração de métodos. Tornar um método final é equivalente a dizer para o Java que nenhuma subclasse pode redefinir aquele método. Essa restrição é garantida tanto em tempo de compilação através de erros, quanto de execução através de um VerifyError.

Existe uma pequena discussão sobre o uso do final nesses casos, pois em geral é bastante difíci prever quando alguma classe precisará ser extendida. Eu mesmo ao longo do desenvolvimento de software vi alguns casos em que uma classe não foi pensada para gerar subclasses e em algum momento na manutenção do sistema uma subclasse foi necessária. Então a recomendação que eu deixo é somente usar o final em classes ou métodos se houver uma razão no design do sistema para isso.

Agora o uso do final nos pontos que me deixaram mais curioso sobre ele e me levaram a esse post. Uso de final em variáveis, parâmetros e atributos de classe é útil? Bom, pra tentar responder essa pergunta eu fui atrás de algumas fontes, e acabei cruzando com um livro do O'Relly, "Hardcore Java". A julgar pelo conteúdo, parece um livro muito bom. Consegui acesso ao 2o capítulo do livro em PDF, não tenho certeza se a lincesa me permite linkar aqui, então vou deixar o link de fora, mas uma busca no google deve trazer a referência ;). Ele dedicou 31 páginas falando os diversos usos do final. Em geral, ele recomenda usar o final em todas as variáveis, atributos e parâmetros, principalmente pelos benefícios que o uso traz em relação a manutenção de código. Achei alguns exemplos forçados, mas tem algum fundo de verdade. Já vi alguns casos de código em que variáveis de nomes semelhantes são usadas ao longo de um método e fica bastante simples atribuir o valor na variável errada. Um ponto a favor do final para esses casos: ele forçaria um erro de lógica a aparecer durante a compilação - ou da edição, se estiver usando uma boa IDE. Sem dúvida, detectar e corrigir um erro nessa fase é bem mais barato do que durante os testes, ou, de acordo com Murphy, quando os clientes começarem a gritar pedindo uma correção para o problema do relatório X estar dizendo que o salário do faxineiro é negativo. Praticamente só esse argumento (de detectar o problema antes, e não o salário) já me deixou com uma coceira para ligar todas as opções de inserção de final do Eclipse (nesse post). Até então eu liguei apenas para ele inserir nos atributos private. Mas vamos lá, um pouco mais de desconfiança e vamos ver se há mais benefícios. Indo na especificação da linguagem Java, há razoavelmente bastante referências ao final, mas nenhuma dizendo claramente as vantagens de usá-lo. Então uma pequena busca no google, e alguns foruns mais tarde, a conclusão que parece óbvia. Tanto os compiladores quanto a própria JVM podem se valer da informação de algo ser final para aplicar otimizações. Uma variável ser declarada como final pode fazer ela ir parar em uma área especial da heap, fazendo o acesso ser ligeiramente mais rápido. Observe o "pode" nessa frase. Eu fiz alguns testes com os compiladores do Java 6 e do Eclipse e o bytecode gerado com e sem final foi o mesmo. Nem sequer uma indicação de se a variável é final ou não. Vi algumas referências de fontes "confiáveis" (leia: posts em foruns) de que a máquina virtual consegue otimizar essas coisas. Mas procurando um pouco mais, fiu atras da especificação da máquina virtual, e no bytecode só é anotado se um atributo é final, e não se uma variável ou parâmetro é. Dessa forma, acho que do ponto de vista de otimização de código, não tem diferença nenhuma para a máquina virtual. O HotSpot(tm) vai identificar os pontos de otimização de variáveis e parâmetros por conta própria mesmo, sem ajuda do compilador.

Bom, eu vou procurar usar o final em todos os cantos mais por precaução contra atribuições em lugares errados, de qualquer forma.

Simulador de corrida

Muito empenho do cara, mas se ele gosta de jogos de corrida como eu, aposto que valeu a pena! Ele só precisa trocar o conta giros pra não ficar tanto tempo em "over rev" (não sei como dizer isso em português :( ) ;)

Mas ficou simplesmente muito bom, não reparei se a temperatura do motor tá mostrando direito, mas pisca alerta, indicador de combustível - com direito a luz piscando na reserva, temperatura deve estar funcionando também ;)

Cheguei nesse video por esse post do MeioBit. O jogo é Live For Speed. Não fucei muito, mas não é open source. Imagino como ele fez para conseguir essa interação com o jogo.

Quanto tempo será até encontrarmos um negócio desse pra vender?

Sobre as cotas na universidade

A algum tempo uma amiga minha passou um link para a relação candidato/vaga do vestibular da UFSC esse ano. Considerando o sistema de cotas, vários cursos estavam com uma relação < 1, aliás, acho que eram poucos os que estavam acima disso. E hoje ela passsou um link para esta notícia.

Para quem está com preguiça de ler a notícia, um magistrado aqui de Santa Catarina decidiu em favor de um candidato que ele poderia concorrer a todas as vagas para o curso de Geografia.

Um dos pontos que eu achei interessante é que "A supressão de vagas ao ‘não-negro’ viola o princípio constitucional da igualdade, sem que haja real fator para privilegiar o denominado ‘negro’, em detrimento do denominado ‘não-negro’". Eu não sou a favor de quotas para negros. Para mim, é uma forma "legalizada" de discriminação. Não somos todos iguais perante a constituição? Por que então alguns são favorecidos com um número especial de vagas? Fazendo isso só vai diminuir a qualidade do ensino superior no Brasil. Não que eu ache que negros não possuem condições de disputar vagas, muito pelo contrário, acho que eles têm capacidade tanto quanto os demais. A questão é que o sistema de quotas diminui a concorrência, fazendo com que os auto declarados negros concorram por uma quantidade de vagas, alguns por vagas de escolas públicas, e os demais no pacote "dos discriminados" (sim, os demais são os discriminados, pois só eles não ganharam vagas especiais!). Alguns candidatos que antes não passariam agora vão passar, pois parte da concorrência migrou para outras categorias. Claro que eu ainda posso queimar a língua (ou nesse caso, os dedos) e ver que os candidatos que entraram com cotas todos atingiram média de classificação no sistema de "balaio único", mas nesse caso, para que as cotas então?

Outro ponto que discordo são as vagas para escola pública. Certo, essas não são tão racistas ou discriminatórias quanto as vagas para negros. Um professor que eu tive na graduação comentou uma vez que o vestibular hoje está servindo como um alarme, que está disparando avisando que tem algo muito errado com o sistema de ensino no Brasil, e que a solução adotada para que esse alarme pare de incomodar foi desligar o alarme, e não consertar a raiz do problema. Parece fazer sentido, afinal, é o que todo mundo faz quando o alarme do carro dispara, certo? Só desliga, e se ele disparar de novo, aí sim vai ver o que está errado. Perfeitamente lógico. Não vai tocar a segunda vez caso tivesse um ladrão para roubar o carro. Ou porque o som já foi da primeira, ou porque o carro resolveu passear com o ladrão. Espero que o alarme do vestibular dispare novamente logo.

Enquanto isso, professores da graduação, boa sorte!

Mestre do Universo

Sério, me identifiquei muito nesse comic:



Fonte: PHD Comics!

Pra quem não conhece o PHD Comics, é um excelente comic sobre a vida de um pós granduando (e em partes de um graduando), e também uma excelente fonte de procrastinação, seguindo o lema "se nós não estamos trabalhando, por que você deveria estar?". Brincadeiras a parte, muitas tirinhas boas sairam lá, como o princípio da relevância, campo de negação (estou com muita preguiça de achar os links), etc.

Não sei se os programadores menos nerds que eu (de acordo com alguns, isso é a maioria dos programadores) também sentem isso, mas essa tirinha é uma descrição muito boa de como eu me sinto quando estou programando. Cada bug detonado, cada problema de design resolvido, cada solução nova representado na forma de um pedaço de software faz eu me sentir como o mestre de um universo, um universo só meu e bem pequeno, mas ainda assim que eu sou o mestre, um deus.

Há algum tempo eu usava na minha assinatura de email a seguinte frase:

"The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." (Joseph Weizenbaum, Computer Power and Human Reason)

Sempre gostei dela, mas ela foi substituida por uma do Scot Adams (criador do Dilbert) que tem um senso de humor um pouco mais apurado ;).

Um pouco mais sobre comics, não sei se outras pessoas também fazem esse tipo de maluquice ou se sou só eu, mas sempre acho um ou mais personagens nos comics que eu acompanho com o qual eu me identifico. Por exemplo, no Dilbert, me identifico com o próprio Dilbert, com o Dogbert (bom, quem não tem um desejo secreto de dominar o mundo?) e com o Wally e sua difícil tarefa de levar litros e litros de cafeína para o banheiro. Outro personagem com o qual me identifico bastante (e nesse me identificam com ele também) é o Garfield. Dizem que é por causa do estilo de humor (sínico eu? Capaz), mas talvez seja só porque eu como pouco, e gosto de lasagna. Mas nem sou laranja e nem gordo (eu acho). No PHD Comics eu me identifico bastante com a Cecília, a nerd que falou do código nessa tirinha que eu coloquei aí.

Bom, é isso. De pensar que antes de decidir montar o blog eu comentei com a Tetê (a segunda culpada por vocês lerem esse monte de besteira) que eu achava que não teria assunto suficiente pra escrever aqui. Incrível como é fácil escrever bobagem :D.

Chega por hoje, que esse sábado de manhã eu estou pensando sério em aproveitar um voleizinho na praida :D

PS: Preciso acertar o layout do site, tá complicado inserir esses comics :S