Steampunk theme for Maemo/N900

blog entry posted by lalo (Lalo Martins) on 2010-09-20 23:23:00

Tags:

So, this post is here mostly for the benefit of web searchers :-) I googled for a steampunk widget theme for my N900 and found nothing. I tried “steampunk theme n900”, then replaced n900 with maemo, hildon, freemantle... nothing.

Then I tried a few promising-sounding ones and, by trial and error and luck, finally got to IivilSteel Black And Gold, which just rocks.

So if you got here while searching for the same thing, now you know.

(I guess now I need to go make a tag icon for steampunk... maybe one for the n900 too)

Por que eu não vou comprar um iPad (e acho que você também não devia)

blog entry posted by lalo (Lalo Martins) on 2010-04-02 16:14:00

Tags:

Por Cory Doctorow, tradução Lalo Martins. Artigo original

Já estou há dez anos com o Boing Boing, achando coisas legais que as pessoas fizeram e escrevendo sobre elas. A maioria das coisas realmente empolgantes não vieram de grandes corporações com orçamentos enormes, mas sim de amadores experimentalistas. Essas pessoas conseguiram criar coisas e colocá-las nos olhos do público e até vendê-las sem ter que se submeter aos caprichos de uma empresa solitária que se declarou guardiã de seu telefone e outra tecnologia pessoal.

Danny O'Brien explicou de uma maneira excelente por que estou completamente desinteressado em comprar um iPad — parece o retorno da grande “revolução” do CD-ROM, em que o pessoal do “conteúdo” proclamou que ia recriar a mídia com produtos caros (pra produzir e pra comprar). Eu fui um programador de CD-ROM no começo de minha carreira, e passei por essa mesma empolgação, também, e acompanhei a época até o fim pra ver o quão errado estava, como plataformas abertas e amadores com espírito experimental eventualmente derrotariam os profissionais gastadores e habilidosos.

Me lembro dos primeiros dias da web — e os últimos do CD-ROM — quando havia esse consenso que a web e os PCs eram muito geek e difíceis e imprevisíveis para “minha mãe” (é impressionante como tanta gente da área de tecnologia tem uma opinião incrivelmente desfavorável de suas mães). Se eu tivesse uma ação da AOL pra cada vez que alguém me disse que a web iria morrer porque a AOL era tão simples e a web estava cheia de lixo, eu teria um monte de ações da AOL.

E elas não valeriam muito.

Os que já estão no poder dão péssimos revolucionários

Contar com quem já está no poder para produzir suas revoluções não é uma boa estratégia. Eles tendem a pegar todas as características que tornam seus produtos legais, e tentar usar a tecnologia para cobrar extra por elas, ou proibí-las completamente.

Quer dizer, olha a aplicação da Marvel (só dá uma olhada). Eu fui um gibizeiro enquanto criança, e sou um gibizeiro adulto, e o lance dos gibis pra mim era compartilhá-los. Se já houve um meio de comunicação que contava com a molecada trocando suas compras uns com os outros pra criar uma audiência, era os quadrinhos. E o mercado de usados para gibis! Era — e é — enorme, e vital. Eu não consigo contar quantas vezes fui mergulhar nas prateleiras e pilhas de gibis usados em um sebo enorme e com vago cheiro de mofo, pra achar edições antigas que perdi, ou experimentar novos títulos gastando menos. (É parte de uma tradição de várias gerações em minha família — o pai de minha mãe costumava levá-la, com os irmãos, à Dragon Lady Comics, na Queen Street em Toronto, todo final de semana, para trocar os gibis velhos por créditos e comprar outros novos.)

E o que a Marvel faz para “melhorar” os quadrinhos? Tiram o direito de dar, vender, ou emprestar seus gibis. Que melhoria. É assim que se pega a experiência prazerosa, maravilhosa, compartilhadora e criadora de laços que era a leitura de quadrinhos, e a transforma em uma atividade passiva, solitária, que isola, em vez de unir. Boa, Misney.

Infantilizando o hardware

Aí tem o dispositivo em si: dá pra ver que um monte de reflexão e esperteza foram colocadas no design. Mas também há um desprezo palpável pelo proprietário. Eu acredito — realmente acredito — nas instigantes palavras do Maker Manifesto: se você não pode abrir, não é seu. Parafusos, não cola. O Apple ][+ original vinha com diagramas das placas de circuito, e deu origem a toda uma geração de fuçadores de hardware e software que viraram o mundo de cabeça pra baixo, pra melhor. Se você queria que seus filhos crescessem confiantes, empreendedores, e firmemente do lado que acredita que você deve estar sempre mexendo no mundo para melhorá-lo, você comprava um Apple ][+.

Mas com o iPad, parece que o consumidor modelo da Apple é aquele mesmo estereótipo de mãe tecnófoba, tímida, cabeça-de-vento que aparece em um bilhão de versões do tema “isso é complicado demais pra minha mãe” (ouça os comentaristas exortarem as virtudes do iPad e meça quanto demora pra explicarem que aqui, finalmente, está algo que não é complicado demais para suas pobres mães).

O modelo de interação com o iPad é ser um “consumidor”, o que William Gibson memoravelmente descreveu como “algo do tamanho de um bebê hipopótamo, da cor de uma batata cozida de uma semana, que vive sozinho, no escuro, em um trailer tamanho duplo nos arredores de Topeka. É coberto de olhos e sua constantemente. O suor escorre nos olhos e os faz arder. Não tem boca... nem genitais, e só pode expressar seus extremos mudos de raiva assassina e desejo infantil mudando o canal em um controle remoto universal.”

A maneira como você melhora seu iPad não é descobrindo como ele funciona e fazendo funcionar melhor. A maneira como você melhora seu iPad é comprando iApps. Comprar um iPad para seus filhos não é uma maneira de dar partida na idéia que o mundo é seu para desmontar e montar de novo; é uma maneira de dizer a seus descendentes que até trocar as baterias é algo que você tem que deixar para os profissionais.

O artigo de Dale Doherty sobre o Hypercard e sua influência sobre uma geração de jovens fuçadores é uma leitura obrigatória sobre isso. Eu comecei como um programador para Hypercard, e foi a introdução gentil e intuitiva à idéia de refazer o mundo que me fez considerar uma carreira com computadores.

Wal-Martizatização do canal de software

E vamos dar uma olhada na iStore. Para uma empresa cujo CEO diz odiar o DRM, a Apple fez do DRM seu alfa e ômega. Tendo entrado em parceria com as duas indústrias que mais acreditam que você não deve poder modificar seu hardware, carregar seu próprio software nele, escrever software pra ele, mudar instruções mandadas pela nave-mãe (a indústria de entretenimento e as operadoras telefônicas), a Apple definiu seu negócio sobre esses princípios. Usa DRM para controlar o que roda em seus dispositivos, o que significa que os clientes da Apple não podem levar seu “iConteúdo” com eles pra dispositivos competidores, e desenvolvedores não podem vender em seus próprios termos.

A exclusividade da iStore não torna a vida melhor para os clientes ou desenvolvedores. Como adulto, eu quero poder escolher de quem compro coisas, e em quem confio para avaliá-las. Não quero meu universo de aplicações restrito a coisas que o Comitê de Cupertino decide permitir em sua plataforma. E como dono de direitos autorais e criador, não quero um único canal estilo Wal-Mart, que controla o acesso à minha audiência e dita que material eu posso ou não posso criar. A última vez que postei sobre isso, recebi uma carreira de desculpas para os termos contratuais abusivos da Apple, mas o melhor foi, “Você achava que o acesso a uma plataforma onde você pode fazer uma fortuna viria sem compromissos?” Eu li isso na voz do Don Corleone, e soou certinho. É claro que eu acredito em um mercado onde a competição pode acontecer sem me ajoelhar diante de uma empresa que ergueu uma ponte levadiça entre eu e meu público!

O jornalismo está procurando um papai

Eu acho que a imprensa está maravilhada com o iPad porque a Apple faz um bom espetáculo, e porque todo mundo na terra do jornalismo está esperando uma figura paterna que vai prometer que a audiência vai voltar a pagar pelo que eles fazem. A razão que as pessoas pararam de pagar por muito do “conteúdo” não é que podem obtê-lo de graça; é que podem obter montes de outras coisas de graça, também. A plataforma aberta permitiu uma explosão de material novo, parte tosco, parte tão bem-feito quanto o dos profissionais, a maioria direcionado a um público mais estreito que os meios tradicionais eram capazes. O Rupert Murdoch pode armar o barraco que quiser sobre tirar seu conteúdo do Google, mas eu digo, vá em frente, Rupert. Nós vamos sentir falta de sua fração de uma fração de uma fração de um por cento da Web tão pouco que mal vamos perceber, e não vamos ter a menor dificuldade em achar material pra preencher esse espaço.

Assim como a imprensa de gadgets está cheia de dispositivos que os bloggers de gadgets precisam (e em que ninguém mais está interessado), a imprensa mainstream está cheia de estórias que confirmam o consenso da mídia. Os impérios de ontem fazem algo sagrado e vital e principalmente adulto, e outros adultos eventualmente vão aparecer pra nos tirar do playground infantil que é a web selvagem, com seu conteúdo amador e falta de canais proprietários onde acordos exclusivos podem ser feitos. Vamos voltar aos espaços cercados que melhor retornam o investimento a investidores que não atualizam seus portfolios desde antes do surgimento do eTrade.

Mas a verdadeira economia da publicação no iPad conta uma estória diferente: mesmo vendas fabulosas no iPad não vai fazer muito pra estancar o sangramento da mídia impressa tradicional. Otimismo fantasioso e nostalgia pelos bons e velhos tempos não vai trazer os clientes de volta.

Aparelhos vêm e vão embora

Aparelhos vêm e vão embora. O iPad que você compra hoje vai ser e-lixo em um ano ou dois (menos, se você decidir não pagar pra trocarem a bateria pra você). A questão real não é as capacidades da peça de plástico que você desembrulha hoje, mas a infraestrutura técnica e social que a acompanha.

Se você quer viver em um universo criativo onde qualquer um com uma idéia legal pode torná-la real e te dar uma cópia para usar em seu hardware, o iPad não é pra você.

Se você quer viver em um mundo justo onde você fica com as coisas que compra (e pode dar pra outros), o iPad não é para você.

Se você quer escrever código para uma plataforma onde a única coisa que determina se você vai ter sucesso é sua audiência gostar ou não, o iPad não é para você.

This work is licensed under a Creative Commons License permitting non-commercial sharing with attribution. Originally published on Boing Boing. Written by Cory Doctorow.

Esta obra é licenciada sob uma licença Creative Commons que permite compartilhamento não-comercial com atribuição. Publicada originalmente em Boing Boing. Escrita por Cory Doctorow.

kill -FKOFFDAMMIT 25208

blog entry posted by lalo (Lalo Martins) on 2008-11-09 05:23:00

Tags:

You know, we (Unix-y people) need a new signal, stronger than SIGKILL. As satisfying as it can be to type “killall -KILL firefox” (we just know that's the actual reason you still love the command line), there are a number of situations where that will still not get rid of the damn process; for example, if it's in the middle of some syscalls, specially nfs (grr!) or swapping (which is precisely when you need to kill it). So I'd like to propose a new signal which, let's say, waits for half a second, and if the process really doesn't respond, then gets rid of it for good, regardless of what else it was doing. In the middle of your quality toilet time, with pants down and all? Who cares, just get out. (If the process does respond, then I suppose do a -TERM... or rather, the other way around; send a -TERM, wait half a second, and if nothing seems to be happening, then bring out the ultraviolence?)

Here's a list of suggested names for the new signal.

and my personal favourite:

XML considered harmful, or,

blog entry posted by lalo (Lalo Martins) on 2008-10-25 15:37:00

Tags:

I have, on a number of occasions, stated that XML is harmful, and should be taken out and shot. So here I am today, to explain why I think that, and offer alternatives.

Not good for humans

The main problem is, of course, that XML was never intended for humans. It's not designed so that we can efficiently write it, read it, understand it at a glance, or maintain it. But many tools that use XML today tend to forget that, leading to hours of wasted time and lots of frustration. (XML for configuration files, anyone? Zope's ZCML and .Net's configs and all those Java frameworks?)

Then, of course, that's not XML's fault; it was never designed to succeed at that task. The fault lies with developers who misuse it. Well, yes and no. The reason people misuse it is because it's overhyped; XML is the new peanut butter (or garlic butter, according to Pete Abrams) — adding it to anything makes it taste better and sell more. (I don't even like peanut butter.)

Not good for machines

What it was designed for is communication between programs; an unified, extensible format for data transmission. By having libraries to handle it in most languages and environments, you'd make it easy for developers to deal with it, and as a consequence, to make their programs communicate.

However, after roughly ten years of working with it, it is my informed opinion that XML fails at that, too. I'm not saying it got supplanted by better technology which we invented later. It did, to be fair. But what I'm saying is that it was wrong from the beginning. And if it's not good for us and it's not good for our programs, why are we still using it? (Peanut butter, I know.)

So let's try to break out of the hype and prove that it's bad for our programs.

The perceived problem with XML can be summarised in one sentence: XML is costly to parse. But that's too superficial; let's go deeper, look at the specifics, and the flaws in philosophy/design that lead to this perception.

Parsing XML: layers

I usually tell my co-workers that there's two “layers” to parsing XML. While that is true, it's only true in the context of our data; if I were to make that statement more generic, I'd say: there's always at least two “layers” to parsing XML.

The first, the “bottom” layer if you want, is syntactic parsing. This means reading XML itself: tags, entities, attributes, comments, CDATA, PCDATA, white space, the works. The input to syntactic parsing is a string or stream of bytes; the “output” is an API — SAX, DOM, ElementTree, you name it.

On the opposite end of the stack, the “top” layer so to speak, is semantic parsing, or extracting the data you're actually interested in. The “input” here is a generic API; in the typical case of two layers, the API from syntactic parsing. The “output” is a domain-specific API or, more commonly, a collection of structured data (usually objects, nowadays).

An example where you may have more than two layers is when you're using something else built on top of XML; the most common case being feeds. So at the bottom layer something will parse XML, then another chunk of code will parse that as RSS or Atom, and then your semantic layer will actually extract the data. At work, we initially made our data available as RDF; so we had a second, “middle” layer (we actually used a JavaScript RDF library) which would parse the RDF, and then we did our semantic parsing by using the RDF library's API. That made our code a lot simpler, but it also made it a lot slower; so we later switched to ignoring the RDF and simply treating it as XML. (Even later, we switched to a JSON format.)

Syntactic parsing: too much structure

Syntactic parsing is what XML is supposedly “all about”; the point being, you don't see it. In our case, at work, it's done by the browser (which gives us DOM with a touch of XPath). In pretty much any other case, it will still be done by your environment (the browser, in our case; JBoss and .Net are other examples), or by a standard library.

Well, that's great, right?

It is, yeah. But it hides the fact that those libraries (even if it's “hidden” in the environment, it's still at some level done by a library) tend to be huge and ridiculously complex. The XML syntax is designed to cover an enormous universe of cases that your program will concretely never encounter, and yet, you have to pay the complexity cost for them.

Semantic parsing: not enough structure

XML shines on xHTML: a markup language for text, where you have arbitrary streams of text sparkled with special instructions about it. Some of those “instructions” are really containers, which have more text and instructions. XML does that really well.

It shines a little less on something like SVG, where it represents arbitrary streams of heterogeneous objects. Some of those contain other objects, and XML does help there.

But the truth is that, for representing your program's data? It probably sucks. Its model is very different from the object model of most (all?) popular languages and frameworks today. In the end, we find ourselves designing our data structures as many as three times: once in the language in which we're actually writing it, one in a relational database, and one in XML. The mappings between them are often poor, since the semantics of the three models are so poorly matched.

Sadly, it would be relatively trivial to pick a lowest-common-denominator model that would fit all of today's popular languages. But XML didn't even try.

That's not the whole of my objection, though. Due to the MASSIVE FAIL in the syntactic layer, we get a semantic layer that's only marginally simpler than it would be to parse a DSL (domain-specific language); maybe less simple, if you use a good library for your DSL. There are about half a dozen XML APIs in wide use; smart people are frequently getting annoyed at the ones already there and coming up with a new, better one. And although a modern offering like, say, ElementTree can be light-years ahead of SAX or DOM, it can't help being clumsy and feeling unnatural to the language; at the bottom line, what it's doing is dressing up a rotting corpse.

Conclusion

Here's a better phrasing then, for the problem of XML as I see it:

XML has too much structure where it doesn't help, and not enough where it matters. One of the reasons I love JSON is that it's not designed to mark-up text, or to transfer “streams of data”; it's designed to transfer objects (JSON means “JavaScript Object Notation”), which means it maps nicely to my code on both ends, whether that code is JavaScript, Python, C++, or even C. (It maps nicely to Java as well, but who cares.)

Alternatives (existing and ideal)

Right now, for real-life code, most places where you're using (or thinking of using) XML would probably be better served with JSON. A few more complex cases may justify a DSL, but I would hesitate a lot before going down that route.

Ideally, I'd like to propose a new format; an “active” derivative of JSON, inspired by the modern practise of “JSON with callback”. Essentially, I'd like to replace JSON's “flat” object notation ({'attr1': 'value', 'attr2': 'value'}) with something which looks like a Python constructor (MyClass(attr1='value', attr2='value')). The pseudo-classes (or pseudo-functions if you're looking at it from C) would play the role that tag names play in XML elements, which would make it even more straightforward to map this data to actual objects on each end.

This would, of course, lose the benefit that “JSON with callback” can simply be executed in a browser. But then again, “JSON with callback” is not formally correct JSON anyway, so we already sacrificed some portability for that ability. “Real” JSON is usually converted to “JSON with callback” by a simple routine on the server side. A similar transformation could convert the format I'm proposing into JavaScript; the fragment above would become: MyClass({attr1: 'value', attr2: 'value'}).

Billy's old car

blog entry posted by lalo (Lalo Martins) on 2008-02-05 11:01:00

Tags:

Billy has a broken car. It's broken mostly because he doesn't know how to run it, of course; and more importantly, because it's making Billy rivers of money even though it's broken, so there's no incentive to learn to run it right.

Then Jerry drives by with an incredibly shaggy, shitty car, with a few nice accessories.

Billy immediately thinks: I'll buy Jerry's car, and use the parts to make mine less broken!

Of course, Billy still not knowing what to do with a car, it will remain broken, or best case, be fixed for a short time before he breaks it again. And it will still be hugely profitable. So to be honest, I see nothing wrong with Billy's logic.

Yeah, there's a reasonable chance it will make zero difference to Billy's car in the long run. But it will make people talk about Billy even more, which of course, puts more money on his pocket. Maybe even more than he's offering.

older posts