Elmord's Magic Valley

Posts com a tag: `life`

Blergh

2013-03-29 02:03 -0300. Tags: about, life, mind, rant, em-portugues

[Este post foi engolido por um tigre. (31/03/2013)]

inf.ufrgs.br, PHP, e outros infortúnios

2013-03-10 22:26 -0300. Tags: comp, life, php, rant, em-portugues

Com este post tenho o objetivo único e exclusivo de reclamar da vida. É improvável que haja qualquer informação proveitosa contida aqui. You have been warned.

Quando eu entrei para a Inf, ~~os Sioux possuíam o mundo~~ as páginas pessoais dos alunos eram contidas no diretório home de seus usuários (especificamente, em ~/public_html). O camarada podia acessar a portal.inf.ufrgs.br por SSH e editar as páginas remotamente com o Vim. Outra vantagem é que se podia rodar scripts remotamente para gerar páginas ou fazer algum procedimento de manutenção. Bem, mais ou menos. O home da portal é montado sem permissão de execução, o que significa que só dá para rodar os binários que já estão lá (e.g., bash, perl), e para poder rodar os scripts que eu tinha no ~/bin sem ter que digitar bash nome-do-script toda vez eu tinha que fazer uma gambiarra no ~/.bashrc para criar uma função com o mesmo nome do script para cada script presente no ~/bin. Mas ok, dava pra tolerar.

Em algum momento da história do mundo, as páginas pessoais foram levadas para um servidor separado, "por motivos de segurança". Conseqüentemente, não dava mais para alterar as páginas via portal. Montar o diretório das páginas por sshfs? Claro que não, a portal não tem sshfs e não executa binários do home. Solicitar à administração da rede para instalarem o sshfs na portal? Não faremos isso, por motivos de segurança. Well, dá pra montar o sshfs usando a máquina de casa, e se divertir com a latência do 3G. Heh.

Um dia me contaram que dava para acessar a portal, e de lá se logar nas máquinas dos laboratórios da graduação, de onde se pode rodar sshfs e tudo o mais que se queira. Hmm, boa! O camarada tem que se logar três vezes (uma na portal, uma nos labs, e uma no sshfs), mas ainda vale a pena. Se o 3G cai meu Vim fica parado lá me esperando e eu não corro o risco de ter salvo meio arquivo no home.

No semestre passado, atualizaram o OS das máquinas dos labs, e agora não é mais possível fazer o login remoto. Yay! Bom, sobrou o sshfs de casa. Felizmente, agora o meu 3G é um pouquinho melhor, com uma latência normalmente abaixo do 1 segundo (vs. os 4 da Tim), e a coisa é pelo menos utilizável.

O servidor das páginas pessoais também monta os homes sem permissão de execução, o que significa que só dá para usar as linguagens de script que já estão lá, i.e., PHP. PHP é uma linguagem/implementação notavelmente medonha, mas ok, é o que temos. Eu quero um blog, e eu quero agora, e eu quero escrever meus posts no Vim e salvar um txt somewhere para postá-los e ser feliz. Let's do it.

O PHP tem uma (so-called) "feature" chamada "magic quotes". A idéia é: programadores são incompetentes e esquecem de escapar as aspas antes de montar uma query de SQL, então vamos escapar automaticamente qualquer entrada que venha de um formulário. (A noção de montar queries de SQL na mão e escapar strings na mão é uma coisa que strikes me as fundamentally wrong, but I digress.) Acontece que o PHP só faz isso se ele estiver configurado para fazer isso no php.ini. E como (pelo que eu entendo) ele faz o escaping antes de rodar o script, o script não tem a oportunidade de desativar as magic quotes. Conclusão? Eu tenho uma função no blog cujo único propósito é receber uma string e remover os escapes se as magic quotes estiverem ativas, ou retornar a string intacta caso contrário. Lindo, hein?

E as closures. Em JavaScript (é, eu vou usar JavaScript, outra linguagem linda, como exemplo, mas acho que assim será mais compreensível do que o Common Lisp que eu ia usar) podemos fazer coisas do tipo:

function menores_que(n, lista) {
    return lista.filter(function(x) { return x<n; });
}

menores_que(5, [2,3,5,7,11]);   // Retorna [2,3].

Aqui, passamos uma função anônima para o método filter, que seleciona os elementos da lista que satisfazem o predicado passado como argumento. (Esse método só existe no JavaScript da Mozilla, eu acho.) Note que a subfunção usa o n definido fora dela. Em PHP 5.3 foi introduzida uma feature similar. Porém, na versão PHP, você tem que declarar explicitamente quais variáveis externas serão capturadas pela closure. WTF? Isso é tão ridículo que não sei quem mais poderia ter a mesma idéia. Oh, well. (Pelo menos em C++11 há a opção de dizer "captura tudo e não enche".)

Ok, ok. Eu sobrevivi. 753 linhas de PHP. Até que ficou pequeninho para a quantidade de coisas que o blog faz. O problema é que o código ficou todo gambiarrento, e sempre que eu vou adicionar uma feature é um trabalho medonho, e sempre que eu penso em reescrever do zero (coisa que uma hora ou outra eu vou acabar fazendo, já que eu não consigo ficar cinco minutos editando o código atual sem ranger os dentes) eu lembro que terei que fazer isso em PHP (o que produzirá uma quantidade equiparável de ranger de dentes) e abandono a idéia. Mas terá que ser feito, porque PHP é a única coisa que roda na Inf (e muitos outros lugares). Very well. (Actually, not.)

A última coisa que eu quis adicionar no blog foi uma feature de "Comentários recentes" na barra lateral. A idéia original era simplíssima: quando um leitor posta um comentário, além de criar o arquivinho de comentário no diretório apropriado, criamos também um symlink para o arquivinho em um diretório recent_comments da vida. Se o número de links exceder uma quantidade x, removem-se os links mais antigos. Simples, hã? Só que se eu tento usar a função symlink(), ela simplesmente retorna FALSE e nada acontece. What gives?

Acontece que o tal do Suhosin bloqueia a função symlink() do PHP se a opção base_opendir do PHP estiver ativada. Essa opção serve para limitar de que diretórios os scripts podem abrir arquivos. A idéia é que se o usuário puder usar a symlink(), ele poderia em tese despistar a base_opendir criando um link no diretório local para um lugar de onde o script não teria acesso (e.g., /etc/passwd). Porque o PHP não poderia primeiro resolver o symlink e depois testar se o arquivo está dentro dos diretórios permitidos antes de abri-lo, right? Nem a symlink() poderia verificar se o alvo do link está dentro dos diretórios permitidos e criar ou não o link dependendo do caso, right?

Acontece que aparentemete o PHP verifica o caminho resolvido antes de abrir o arquivo. You see, embora o PHP não possa criar symlinks, eu mesmo posso, por sshfs. Quer dizer que qualquer vulnerabilidade que links arbitrários pudessem causar ainda poderiam ser provocadas por mim. Mas eu testei criar um symlink local para o /etc/passwd, e o PHP se recusa a abri-lo, alegando violação da base_opendir. Quer dizer que mesmo que a symlink() estivesse ativa ainda não haveria vulnerabilidade. Mas ela não está, e isso impede gratuitamente minha implementação simples da feature de comentários recentes. Eu poderia entrar em contato com a administração da rede da Inf e pedir para eles habilitarem a feature. Eu não farei isso por duas razões: (1) a admrede vai me dizer que não vai habilitar nada "por motivos de segurança"; (2) um dos princípios por trás deste blog system é rodar em qualquer lugar que tenha um servidor com PHP, sem depender nem de bibliotecas non-standard nem da boa-vontade de sysadmins, e como o symlink() desativado é o padrão do Suhosin, não posso contar com a utilizabilidade dessa função. Tudo bem, o Unix original não tinha symlinks. Vamos brincar de anos setenta.

8 comentários / comments

Irrealis

2013-02-12 07:10 -0200. Tags: life, mind, em-portugues

It's time to start living in the indicative.

Comentários / Comments

Divagações sobre a vadiagem, dominação mundial, e outras pertinências

2013-02-05 01:43 -0200. Tags: life, mind, comp, wrong, em-portugues

A situação ao final de julho do ano passado era a seguinte: depois de muitos semestres com uma quantidade apreciável de disciplinas menos-que-maravilhosas, eu teria um semestre com apenas 10 créditos de cadeiras, uma monitoria mui pouco time-consuming, morando sozinho, sem ninguém para me perturbar, ridiculamente próximo da universidade. Eu teria uma quantidade de tempo livre sem precedentes desde o início da faculdade. Eu poderia me dedicar a desenvolver a linguagem de programação perfeita. Eu poderia estudar todas as línguas que quisesse. Eu poderia aprender a tocar a shakuhachi que estava pegando pó há um ano e meio. Eu poderia me dedicar a fazer o que quer que fosse.

Foi um dos semestres mais improdutivos dos últimos cinco anos.

Não que eu não tenha feito nada. Eu li uma quantidade praticamente nociva de blogs e papers e manuais e artigos da Wikipédia nesse período. Mas eu não produzi muita coisa nesse período: foi muito mais input do que output.

A moral da história é que muitas vezes a desculpa de não fazer as coisas por "não ter tempo" é um fraude. Ok, há pessoas que trabalham quarenta mil horas por semana e estudam e realmente não têm tempo de fazer mais muita coisa. Mas esse nunca foi o meu caso. Com exceção de uns poucos períodos em que o curso estava meio demás e eu tinha trabalho da bolsa para fazer, eu sempre tive um bocado de tempo livre, e se não o aproveitei direito foi por vadiagem, ou falta de motivação.

Na verdade eu andei fantasticamente desmotivado de fazer qualquer coisa nos últimos tempos, por mil motivos (sic), e por motivo nenhum. Não tenho bons conselhos a oferecer em termos de motivação. O que eu sei é que: (1) é incrivelmente fácil postergar indefinidamente, especialmente quando se tem alguma outra atividade que não exija esforço para consumir o tempo com; e (2) a Internet provê uma fonte infinita de atividades que não exigem esforço. Assim, limitar o tempo que se consome na Internet parece uma boa estratégia para levar uma vida mais produtiva. (No geral, as pessoas não gostam de ficar muito tempo sem fazer nada; normalmente elas acham alguma distração para ocupar seu tempo com. Elimine as distrações e o que sobra é o trabalho a ser feito.)

Nem todo o tempo que eu perco na Internet é totalmente inútil; pelo contrário, muito desse tempo eu passo lendo material técnico sobre coisas que me interessam e que são relevantes para o que eu gostaria de desenvolver. E aí reside um perigo, porque é muito fácil nesse caso justificar o tempo que se consome lendo ao invés de produzindo. Acontece que essa tal de humanidade já fez muita coisa, e se o camarada for parar para pesquisar tudo o que existe de "prior art" antes de fazer algo, vai acabar não fazendo nada. Pesquisar o que existe é importante (e freqüentemente muito interessante), mas uma hora a gente tem que parar de ler e pôr a mão na massa.

Outra fonte de postergação indefinida em desenvolvimento de software (pelo menos para mim) é se perder em questões de design e nunca decidir nada. (Heh.) Para projetos suficientemente grandes (e.g., linguagens de programação e respectivas implementações, sistemas operacionais), design é um problema tão grande ou maior do que implementação, pois há uma quantidade enorme de decisões de design a se tomar e possibilidades a explorar; decidir o que exatamente o software deve fazer, quais são seus objetivos, são as questões difíceis. Mas embora pensar com calma sobre design seja importante (afinal o objetivo é criar uma linguagem (por exemplo) que ofereça alguma vantagem significativa sobre o que existe), para sairmos do lugar, em algum momento temos fixar certas decisões (para valores suficientemente fluídos de 'fixar'), mesmo que não tenhamos certeza de que seja a solução ótima (ou que tenhamos certeza de que não é, mas não temos nada melhor no momento), e partir para a implementação. Assim, temos um produto concreto para experimentar e para nos guiar no processo de decisão. Em todo caso, produzimos alguma coisa, que se não é ideal, com alguma sorte é pelo menos um avanço em algum aspecto em relação ao que existe.

And now for something slightly different

Tendo tratado a questão da inércia, falemos da dominação mundial.

Em algum ponto de suas vidas, algumas pessoas têm o seguinte pensamento: "Os ambientes computacionais modernos estão completamente errados. Se eu fosse começar tudo do zero, eu faria tudo diferente. Hmm, começar do zero...", e começam a arquitetar como seria o sistema ideal e todas as features legais que ele teria. Algumas se arriscam a levar o projeto adiante. Afinal, não pode ser tão complicado criar um sistema operacional, não é mesmo?

Normalmente esses projetos não acabam bem.

A insistência em construir as coisas do zero, embora tenha seu apelo, tem um custo (freqüentemente subestimado) muito maior do que o benefício. Mesmo que seja viável escrever um sistema operacional inteiro "from the ground up", com todos os detalhes exatamente corretos, o tempo que se perde implementando funcionalidades básicas do sistema (gerência de hardware, alocação de memória, agendamento de tarefas, e uma miríade de outras coisas) é tempo que poderia estar sendo usado para implementar as features que realmente interessam, e que poderiam ser implementadas sobre um sistema operacional existente. Mesmo features que "contradizem" o sistema operacional existente muitas vezes podem ser implementadas com uma pequena dose de gambiarra. Quer um mecanismo de segurança baseado em capabilities, ao invés das permissões tradicionais do Unix? Coloque um servidor de capabilities e autenticação a rodar como root, rode as aplicações clientes com um usuário não-privilegiado, e faça o daemon transferir file descriptors para os programas não-privilegiados segundo as permissões dos programas. Deselegante? Mais complexo do que o necessário? Talvez, mas é fantasticamente mais rápido de desenvolver do que criar um sistema operacional do zero só para experimentar com segurança por capabilities. De brinde, você pode continuar executando suas aplicações convencionais em paralelo com o seu sistema alternativo. Na pior das hipóteses, você pode alterar o kernel ou criar um módulo para o kernel para conseguir o que quer, o que ainda há de ser mais produtivo do que começar do zero. Depois que você estiver com seu sistema funcionando sobre o outro (i.e., depois que você descobrir o que exatamente você quer que o sistema faça), você pode começar a pensar em substituir a camada de baixo por algo mais puro e ideal. Da mesma forma, se você estiver desenvolvendo uma linguagem de programação compilada, provavelmente é melhor aproveitar a infraestrutura de um compilador existente (e.g., fazendo seu compilador gerar C ou bytecode LLVM) do que gerar assembly na mão. Ou se você pretende criar uma interface gráfica, use o X (e algum toolkit gráfico pré-existente, se possível). Em suma: dê preferência por construir sobre frameworks existentes, e foque nos aspectos realmente inovadores do projeto.

Se a idéia de construir sobre as bases tortas dos sistemas existentes lhe desagrada, lembre-se de que mesmo eliminando o sistema operacional, você ainda terá que construir sobre as bases tortas das arquiteturas existentes. Não seria ótimo se a arquitetura oferecesse suporte a capabilities em hardware, ou alguma ajuda com tipagem dinâmica e verificação de limites de vetor? Ou se simplesmente o conjunto de instruções fosse minimamente ortogonal, e não a bagunça que são o x86 e x86_64? A moral da história é que, sendo economicamente inviável para nós reles mortais criar uma arquitetura nova e mandar fabricar (e convencer o mundo a comprá-la), teremos que lidar com a sujeira das arquiteturas presentes; e se vamos lidar com alguma sujeira, podemos igualmente lidar com a sujeira de um sistema operacional existente, o que dá muito menos trabalho (em tese).

(Curiosamente, há (pelo menos) um projeto ~~lunático~~ de sistema operacional que, embora hesitante a princípio, levou a decisão da "pureza" às conseqüências lógicas e virou um projeto de arquitetura, implementado em FPGA. O autor do projeto tem ciência de o quão imprática é a idéia, mas não está nem aí.)

Meu último conselho para dominar o mundo: não queira demais. Ou melhor, queira, mas dê um passo de cada vez. Se você tentar iniciar o projeto de um sistema que resolve todos os problemas do mundo, é possível que você sequer termine de projetar e comece a desenvolver o sistema, ou comece a desenvolver mas não saiba como seguir adiante. Defina subprojetos com ambições menores, e resolva um, ou alguns, problemas de cada vez; assim você terá foco o suficiente para poder saber o que fazer. Use o Grande Objetivo Final como guia para saber para onde ir, e não como uma especificação cujos itens devem ser todos satisfeitos de uma vez, e caminhe gradativamente em direção a ele. Talvez você nunca o atinja, mas pelo menos você está andando para a frente.

3 comentários / comments

Machina necat

2013-01-14 01:53 -0200. Tags: life, about, em-portugues

A dor nos meus olhos e nas juntas dos meus dedos sugere que eu deveria aproveitar a rara oportunidade que as férias me proporcionam de me manter longe de computadores e me manter longe de computadores.

Vejo vocês em um futuro indeterminado.

1 comentário / comment

Qué voy a ser, je ne sais plus

2013-01-11 04:03 -0200. Tags: life, rant, academia, em-portugues

(For your enlightening. Midnight rant follows.)

Tendo terminado hoje a "prova" de Tópicos X (embora ainda não a tenha enviado), termina para mim para todos os fins práticos o semestre de 2012/2. Tópicos Especiais em Computação X, a.k.a. Grandes Desafios da Computação, é uma cadeira de 2 créditos que visa apresentar diversas áreas de pesquisa em Ciência da Computação. A maior parte das aulas consiste de uma palestra dada por um professor sobre sua área de pesquisa, no que ela consiste e quais são os desafios atuais que ela tem para resolver, além de dar uma idéia de como funciona a pós-graduação. Em uma dessas aulas, um professor mencionou (com uma certa ênfase) que a pós-graduação "não é mais do mesmo", que a dinâmica das aulas é diferente, que os alunos têm um papel muito mais ativo do que na graduação.

A primeira reação que eu tive diante disso foi uma boa dose de descrença. Talvez alguns professores dêem boas aulas, e os alunos desempenhe um papel mais ativo e autônomo, mas desconfio seriamente que com muitos professores a coisa não seja bem assim.

By the way, quem falou em autônomo? Isso aí brotou da minha cabecinha não-categorial. Só porque os alunos são mais ativos, não quer dizer que eles tenham algum poder de decisão sobre o que aprendem. Disse ainda o camarada palestrante que como não há cadeiras obrigatórias no mestrado, o aluno pode escolher fazer cadeiras apenas nas áreas que lhe interessam. Porém, no caso das cadeiras eletivas da graduação, os fatos de (1) haver um número mínimo de créditos eletivos obrigatórios, (2) não haver cadeiras suficientes em determinados tópicos, e (3) diversas cadeiras existirem apenas "para inglês ver", não sendo oferecidas em nenhum semestre na prática, significam que no geral é inviável fazer todas as eletivas em assuntos de interesse, e não vejo por que isso seria diferente no mestrado.

O segundo pensamento que me ocorreu é, se o mestrado é toda essa maravilha, por que diabos a graduação não é? É para filtrar dos reles mortais os poucos que têm saco de aturar a graduação inteira e ainda têm ânimo de continuar na academia? É por falta de professores (assumindo que uma melhoria exigisse turmas menores, como são no mestrado, proposição da qual eu duvido)? Porque "sempre foi assim"? Porque no final das contas o objetivo da graduação é produzir um diploma que dá ao camarada o direito de ser empregado em lugares que pagam melhor, e não adquirir e construir conhecimento? Todas as alternativas acima?

É nessas horas que eu me pergunto se vale a pena seguir a vida acadêmica. Meu objetivo inicial, logo que eu entrei nesse curso, era me tornar professor e viver uma vida feliz e contente dando aula e fazendo pesquisa. O curso começou a ficar menos-que-excelente pelo terceiro semestre, e lá pelo sexto ou sétimo eu já estava de saco cheio o suficiente para ter vontade de largar a faculdade. Muita gente que eu conheço encheu o saco bem antes; o que me sustentou nesse tempo foi primariamente o fato de que eu me interesso realmente muito por Ciência da Computação, e leio sobre coisas que me interessam fora do curso, o que mantém meu "amor à arte" firme e forte, apesar do curso. Felizmente a parte mais maçante do curso já se foi, e agora só me restam 6 créditos eletivos por fazer (ou 8, se o professor de Tópicos X não gostar das minhas respostas, já que a prova não é lá muito objetiva*) e o TCC (que é trabalhoso, mas pelo menos eu arranjei um assunto que me interessa para fazer ele sobre (e que venha o monstro da gramática me devorar)).

Como se não bastassem os horrores da graduação para desmotivar o sujeito, eu vejo por aí coisas do tipo:

Basically everyone who gets tenure, including me, finds him/herself continuing to get busier every year. Not only do the demands on our time increase, but we can no longer fall back on the convenient selfish excuse “sorry—can’t possibly do that time consuming task while I’m on the tenure track.” The constantly overloaded TODO list gets old, and it also makes it hard to get actual research done. It’s no coincidence that a lot of tenured professors rely on students to do all of the technical work associated with their research programs. Untenured professors not only have more time to do research but also may be reluctant to risk their careers by putting students on too many critical paths.
– Life After Tenure (ênfase minha)

Mais de uma vez eu já li ou ouvi relatos de que os encargos administrativos de um professor tomam tempo suficiente para atapalhar a "pesquisa de verdade". E aí reside um baita de um problema, porque se eu tiver que escolher entre ser professor e desenvolver software, eu prefiro desenvolver software. Na minha concepção inicial do universo, eu não teria que escolher, mas parece que minhas suposições podem estar erradas. Je ne sais plus.

* Appendix A: De como eu saí da Letras

(Não, isso não tem nada a ver com o resto do post.)

Para quem não sabe, antes de entrar para a Ciência da Computação (em 2009) eu cursei um semestre e meio de Letras. Os motivos para isso foram meu interesse por lingüística e a ausência de um curso específico de lingüística em uma faculdade próxima (a faculdade mais próxima com um curso de Lingüística é a Unicamp), o fato de que eu estava de saco cheio de computadores (primariamente porque eu tinha zilhões de problemas com computadores na época, primariamente porque eu tinha uma máquina extremamente capenga, mas também porque viviam me alugando para resolver problemas), e o fato de que eu estava de saco cheio de matemática (graças a um curso de iniciação científica oferecido pelo IMPA para os primeiros dez bilhões de colocados na Olimpíada Brasileira de Matemática das Escolas Públicas, o qual eu abandonei depois de três meses, embora eu estivesse sendo pago para participar). Quaisquer que tenham sido os motivos, eu tomei a decisão de fazer o curso de "Letras – Tradutor Português e Japonês" (porque foi a língua que me pareceu lingüisticamente mais interessante, e não porque eu gosto de animê e mangá, como aparentemente era o caso de todos os outros (cerca de oito) alunos).

Embora algumas cadeiras fossem insuportáveis (e.g., Leitura e Produção Textual), algumas cadeiras eram muito legais (Conceitos Básicos de Lingüística, Japonês I), e embora historicamente eu detestasse de coração o estudo de literatura que se faz no ensino fundamental/médio, até as cadeiras de literatura estavam interessantes.

Até que chegou a primeira prova de Literatura Brasileira A. Eu fiz a bendita prova e tirei um C. Nesse momento eu contemplei a prova, mirei as respostas, e me dei conta de que eu não fazia a menor idéia de por que eu tinha tirado um C, ou o que eu poderia ter respondido diferente para tirar uma nota melhor. Nesse momento eu me dei conta de que se eu não era capaz de determinar o que estava "errado" na prova, meu desempenho no resto do curso provavelmente seria a mesma coisa, já que responder "certo" parecia exigir uma habilidade mágica que não só eu não tinha, como sequer compreendia a natureza da mesma. Nesse momento eu tive um profundo insight: "Que diabos eu estou fazendo aqui?!"

(Fora que o conteúdo de lingüística do curso é um quase nada.)

E foi assim que eu não fiz a segunda prova de Literatura Brasileira A (embora tenha ido às aulas), terminei as outras cadeiras decentemente, no semestre seguinte peguei apenas quatro cadeiras (incluindo uma eletiva, nenhuma relacionada a literatura), larguei todas em setembro para me mudar temporariamente para a casa da minha mãe e estudar para o vestibular, e no ano seguinte entrei para a Ciência da Computação, onde, se muitas das cadeiras são terrivelmente maçantes, pelo menos os critérios de avaliação são largamente objetivos.

Post scriptum

O vídeo linkado diz "que voy a hacer" ao invés de "qué voy a ser". Nunca tinha me ocorrido essa interpretação (acentuação notwithstanding). Mas camarada Google diz:

"que voy a ser" manu chao: 929 000 resultados
"que voy hacer" manu chao: 50 500 resultados
"que voy a hacer" manu chao: 18 500 resultados

E no entanto os primeiros sites retornados por uma pesquisa por manu chao me gustas tu lyrics favorecem o "que voy a hacer". E agora?

9 comentários / comments