Retrocomputing, ou bregacomputing

Art. 23. Todo e qualquer computador que entra no território desta República é considerado patrimônio histórico e nunca mais poderá sair, nem ser desligado ou destituído de sua função original, e muito menos desmontado ou ter partes reaproveitadas.

Parágrafo único. Para dar cumprimento total ao artigo, proíbe-se os computadores e softwares de apresentar defeito.

-- Constituição do Chiqueirinho, o "think tank" (haha) do qual originou-se o #d00dz

Em cumprimento a esta lei, não pude recusar a oferta do meu pai: um PC velho. Além do mais, estava sentindo falta de um servidor Linux para fazer algumas brincadeiras sem "poluir" o Mac. Eu poderia rodar o Linux nativamente no Mac, mas... não dá.

Esta máquina é um Pentium IV, 1,7GHz, placa-mãe Asus com chipset SiS, tudão on-board. A única coisa "acima do padrão" para a sua época é a RAM (512MB, que roda o Ubuntu Jaunty confortavelmente).

Para completar, um monitor CRT de 15", que você tem de escolher entre 800x600 a 75Hz, ou estonteantes 1024x768 a 60Hz. Estonteantes no sentido literal! Fora que a curvatura do tubo de imagem é grande mesmo para um CRT. Bruder-compliant.

É incrível como a gente desacostuma rápido. O ruído dos ventiladores da máquina é ensurdecedor. A quantidade de fios na hora de montar a máqiuna também foi assustadora. Ao menos a BIOS é recente o suficiente para funcionar com teclado USB, aí pude usar o teclado do finado Mac Mini. (Teclado e mouse inclusos eram PS/2, Deus me livre!)

Fui olhar o relógio de luz lá fora, está rodando com gosto, em particular quando o monitor está ligado. Uma máquina dessas ligada 24x7 consome algo como 150kWh por mês, ou seja, praticamente dobra a conta de luz de uma família pequena. (Quando os donos de Mac Mini G4 passarem a vendê-los por preços mais racionais no Mercado Livre, provavelmente vou comprar um.)

Para mim esta máquina tem todo o sabor de retrocomputing. Mas pensando melhor, computador com estas características ainda é a "realidade da informática" para muita, muita gente por aí.

Let the Experience begin!

Today the Experience has been started: I don't have a voice-capable cell phone plan anymore. Only SMS and data. All contacts have been notified. Let's see what happens now. My friends are calling me crazy.

But of course I am not *that* crazy. My old cell phone number went to my wife, so anybody that knows the old number can still reach me, and people will keep it around for emergencies. My 3G chip can send and receive SMS, and SMS is 99% of cell phone communication these days. And it can do emergency calls.

It was a tough day to start with pure VoIP telephony. The Internet went down this afternoon, probably a telecom router problem. Since this town I live is very small, the cell phone provider probably relies on landline telecom for TCP/IP, and guess what, 3G went down too. Both came back up in 30 minutes. This night, we had thunderstorms, everything was shot down here, and then my father calls over Skype, with Fring connected via EDGE. And he is deaf. And my son was crying loud because of thunderbolts. Incredibly, he managed to understand what I was saying. The next call over restarted WLAN was much nicer :)

By the way, this week was plagued by Internet problems at all levels: from DSL provider to my corporated VPN to Freenode IRC, everyone goofed up a handful of times. Even my phone plug was loose on socket, what was probably costing me a higher packet loss rate and a DSL reconnection every 12 hours, whose cause I was chasing down this whole week.

As I mentioned in the last post, Skype gateway to POTS is in trouble in Brazil, since Transit Telecom has some problem with cell phone companies and interconnection rates. One says they charge too much, others say Transit is in default. I even got SkypeIn (now called Online Number) but it can not receive calls from Claro phones. Calling from/to fixed landlines, and/or calling from/to distant area cell phones works because in such cases the interconnection is made through other companies.

I must acknowledge my #d00dz friends in this point: telecom regulation in Brazil is a mess. ANATEL should never let this to happen; either they seize the offending telecom's control, or demand the others to lower rates. It is a completely stupid situation, having one POTS terminal not being able to call some POTS number because of misunderstandings between the respective companies.

That SkypeIn problem almost wrecked my plans, but then I remembered by old Vono account that I just created for testing. Vono is a SIP phone service with quasi-POTS quality because it is actually operated by a POTS company (GVT). This worked great right from the start, and worked with every possible client: SIP client applications, bundled SIP support in Nokia phones, and Fring SIP support.

I was going to abandon Fring in favor of using bundled SIP support in N85, but it seems to work only when connected via WLAN. It may be some configuration mistake, but could not make it work over 3G. It autenticated but did not make calls. When I tried to call, it said something like "no connection available". That forced me to use Fring SIP add-on, which has a bigger latency but works over 3G/EDGE.

It may well be that my 3G plan blocks SIP explicitly, or phone being crippled in software not support SIP over 3G. But I still hope to find a solution and use bundled Nokia SIP stack because it is said to be of very high quality, integrates with phone UI nicely (no need to navigate to a background application), and perhaps would consume less battery than Fring.

Running Fring is hard on battery; brand new N85 struggles to stay on 24 hours per charge, and that's with WLAN (which is said to consume less energy than 3G/EDGE). Probably I will need to make an habit of plugging the USB cable (N85 can trickle charge over USB). Actually, it was expected, and I am surprised it goes that far; N95 drains the battery in few hours just by being connected to WLAN.

Of course, "running Fring" is not the real culprit; the problem is the continuous WLAN connection. If a notebook stays up for half an hour longer when WLAN is off, imagine what WLAN does with a poor cell phone.

One nice side-effect of operating connected to network 100% of the time, is that GPS works incredibly fast, even indoors, thanks to A-GPS. (In this afternoon, when Internet was out, GPS took several minutes to lock, as usual.) By the way, N85's Map application is much nicer than N810 counterpart, despite the smaller screen.

N85 camera did a lot better outdoors in daylight, as the photo at the top of the post shows. I put that photo as N85's background image -- and now finally the OLED display can show off. The palm leaf just looks real and alive on N85, while it looks bleached out and dead in Macbook's screen (which has one of the best LCDs around, with LED backlight). OLEDs are really the way to go.

Time to go to bed, and plug the charger on N85 :)

First impressions about N85; and The Great Experience

Yes, I have bought a Nokia N85, right after that post that complains loudly about Nokia. Why? There are three strong reasons and one rather weak reason:

1) In terms of raw features, N85 is equivalent to the newest iPhone 3GS. The 3GS will cost around R$ 3k in Brazil, and it is not even available yet. I can stand Symbian in exchange of portable photo and video capability.

2) It runs Python.

3) I believe firmly that we must eat our own dog's food. If I want Python (and potentially other interpreted languages) running on mobile devices, I must vote with my wallet in the ones that actually do it. There is no point in complaining about PyS60 non-commitment from Nokia if I don't use it at all.

4) Maybe Nokia listens to me and offers a Linux image to run in N85 in the future :)

N85 has a nice format and grip. It is thinner than N95, does away with all sharp edges, and the slide mechanics seem to be better and have lower tolerances. The keys are way better than N95, too. GPS works very well, resolving position in a few seconds if you are in the reach of a cell tower (A-GPS). The UI seems to be twice as fast as N95, except in effects where the 3D acceleration in N95 lends a hand. Signal reception is *way* better than N95.

The highest point of N85 is certainly the OLED display, something that is going to take over LCD along time. It does not seem to be better in color correction than LCD, the only visible gain is the "perfect" black, particularly beautiful in a dark environment. And choosing a darker theme means less battery consumption.

N85 camera seems to be not as good as N95's. I took some photos in low-light condition and they look noisy and blurred. I must test it in daylight conditions, but I don't have much hope. Photography quality is directly proportional to lens size; N85 lens is much smaller than N95's, so a drop in quality is unavoidable.

And there are those details that put Apple apart from the rest, besides UI and operating system concerns. N85 manual is thick and unreadable (too good it is unnecessary). The headphones that come with N85 have too short wires, and left/right wires are asymetrical. It felt strange for a device that wants to double as a music player. I understood the intention (coupling earphone+microphone) but but did not like it anyway :)

Now, about the Great Experience.

I have a 3G plan that does not allow voice calls, only SMS. I am using this plan on N85. It's running Fring, and I have a Skype account with online number ("SkypeIn").

Given that

1) I'd need to pay a fine to cancel my 3G data plan and upgrade it to voice+data. And I am too cheap to do that; I prefer to wait until next January to do the upgrade without paying any fine.

2) Almost 100% of "synchronous" communication is SMS these days, including with wife, parents etc.

3) I don't want to carry 2 cell phones around

4) I can always carry a prepaid SIM and a credit code in my wallet, just in case I absolutely need to make a regular voice call;

5) Most of the time, the cell phone can stay connected to WiFi instead of 3G;

6) I am an enthusiast of network technologies, and again I believe we must eat our own dog's food;

7) When I go to countryside and 3G data ceases to work, voice signal is unavailable as well, and SMS/IM will deliver as soon as connection is available again.

So, I decided to turn off my old number and keep only the 3G data plan. My contacts are going to receive a SMS about the new numbers anytime soon. And let's see what happens.

Right now I remembered that we have this Vono service, a SIP phone offered by GVT Telecom. Since N85 seems to be capable of handling SIP directly (without Fring), it is worth testing.

Surpresas com IPv6, parte 2

Como bom nerd brasileiro, botei a culpa na telecom antes de esgotar o checklist local. O problema era óbvio: o NAT do Linux não reescreve o endereço de origem do pacote IP automaticamente. Teria sido necessário usar uma regrinha PREROUTING também para pacotes "saindo", não só para os pacotes "entrando".

Bem, eu tirei a dúvida do jeito difícil: liguei o Mac direto no modem ADSL, configurei o PPPoE, e aí o 6to4 funcionou. O Mac torna fácil fazer isto, exceto por um detalhe não documentado: é preciso desligar o IPv6 na interface "real" para a interface virtual 6to4 fazer efeito. A presença da interface virtual 6to4 deveria fazer isso automaticamente. Mas tudo bem, 6to4 não foi feito para usar no host mesmo.

Outro detalhe é que a latência pingando ipv6.google.com é menor usando o túnel da Go6 do que usando 6to4. Então o negócio vai ser usar túnel mesmo.

Estou sonhando ou o quê?

Já que o 6to4 não funcionou nem com banda de música (aparentemente a Brt^WOi quebrou o serviço, o 192.88.99.1 pinga mas não devolve nada no protocolo 41) tentei um tunel gratuito da Go6, antiga Freenet6, e...

/Users/epx $ ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2001:5c0:1103:7e00:223:6cff:fe8e:2b1d --> 2001:4860:0:2001::68
16 bytes from 2001:4860:0:2001::68, icmp_seq=0 hlim=54 time=184.492 ms
16 bytes from 2001:4860:0:2001::68, icmp_seq=1 hlim=54 time=182.359 ms
16 bytes from 2001:4860:0:2001::68, icmp_seq=2 hlim=54 time=184.486 ms

/Users/epx $ ping google.com
PING google.com (74.125.45.100): 56 data bytes
64 bytes from 74.125.45.100: icmp_seq=0 ttl=54 time=195.283 ms
64 bytes from 74.125.45.100: icmp_seq=1 ttl=54 time=197.479 ms
64 bytes from 74.125.45.100: icmp_seq=2 ttl=54 time=199.438 ms

Só pode ser algum fator transiente, ou talvez o fato de quase ninguém acessar o ipv6.google.com. Mas foi uma surpresa agradável.

Quem quer rir, tem de fazer rir

Tem toda essa polêmica aí sobre a lei Rouanet, que acaba beneficiando Ivete Sangalo e outros artistas que ao menos na minha visão estão claramente no ramo do "entertainment", e não da cultura. Não que o arrego^Wincentivo tenha sido ilegal. Vou discutir é a validade da Lei Rouanet como um todo.

Pessoalmente acho que incentivo pecuniário governamental à cultura deve restringir-se a financiar museus e bibliotecas públicas, que claramente não conseguem sustentar-se com ingressos mas todo mundo concorda que são essenciais. Cultura é, como o próprio nome diz, algo que "fermenta" naturalmente a partir de um aglomerado de pessoas, como em "caldo de cultura". Se não surge naturalmente, se depende de incentivo governamental, então não é cultura.

Num primeiro momento pode até parecer uma boa idéia dar uma "mãozinha" às manifestações culturais preexistentes, mas aí começam todos os problemas de não-linearidade que incentivos governamentais começam a criar. Você financia manifestação cultural X e não Y, aí a coisa X começa a inchar para manter o arrego, enquanto a coisa Y, inicialmente tão legítima quanto X, definha. No fim X vira X', X e Y desapareceram, e a cultura entrou pelo cano, dando lugar à pseudo-cultura mamando nas tetas do governo.

O pior mesmo desse processo é que não precisa haver desonestidade para ele acontecer. Muitas vezes há, mas muitas vezes é a simples não-linearidade que causa a distorção.

Ok, mas por que eu estou falando isto tudo no meu blog "profissional"? Será que estou escrevendo no blog errado? Não exatamente. Penso que existe um problema parecido com muitos projetos de software livre.

Atire a primeira pedra quem nunca viu um projeto de software livre que

a) persegue objetivos completamente alheios ao que os usuários realmente precisam?

b) pior, persegue objetivos que outros já provaram ser impossíveis?

c) mantém decisões de arquitetura absurdas, que prejudicam os usuários, por motivos ininteligíveis?

d) já deveria ter morrido ou jogado a toalha para um projeto concorrente e melhor, mas não o faz, confundindo concorrência e liberdade com duplicidade?

De uns tempos para cá eu suspeito que boa parte dessas mazelas é derivada dos "arregos" ou patrocínios que muitos projetos de software livre conseguem. Admitir derrota ou perseguir objetivos úteis de curto prazo põem em risco o arrego.

E como no caso da Lei Rouanet e da cultura, não é preciso haver desonestidade para isso acontecer. Não é característica humana chegar e dizer "ok, este meu projeto acabou/está obsoleto/foi obsoletado pelo outro projeto". O que mais se vê é gente insistindo numa tese muito depois de ela estar obsoleta: Richard Stallman, Fidel Castro, Delfim Neto (com a história da desvalorizacão do real, é, eu lembrei, gordo sinistro!).

Aí você junta o instinto normal do ser humano com o incentivo financeiro, e está criado o problema. Na verdade MESMO, esse problema acontece também com software proprietário, com facções dentro das empresas advogando esta ou aquela tecnologia, este ou aquele projeto. Os "agravantes" desse problema em relação ao software livre são: o "pool" de recursos destinados ao software livre é relativamente pequeno, o que faz do seu mau uso um problema muito mais grave; e o fato do software livre ser, em tese, um fenômeno cultural, que corre o risco de virar pseudo-cultural por conta do arrego.

É um equlíbrio muito delicado. Eu não tenho uma solução para o problema, mas o problema existe. Grandes projetos de software livre precisam de incentivo financeiro, muita coisa boa já saiu de ambientes onde os participantes gozavam de completa liberdade (como o BSD), mas por outro lado como é que se lida com o problema do mau uso desses recursos? Onde acaba o "bold" e começa o "stubborn"?

Vamos pegar alguns exemplos como estudo de caso.

Muita gente tem dito que o Mozilla deveria adotar o Webkit como engine HTML. Como é de se esperar, o pessoal do Mozilla nem cogita fazer isso. Por que? Será que essa percepção do Webkit ser melhor é um erro? É importante haver um segundo engine livre para competir com o Webkit? Existe um sentimento de nostalgia em relação ao Gecko? Abandonar o Gecko implicaria num "downsizing" no projeto Mozilla?

Note que eu não sei a resposta. Estou apenas apontando um caso onde a questão do patrocínio PODERIA prejudicar (não estou dizendo que REALMENTE prejudica, note-se!) uma decisão técnica.

Também não estou dizendo que o Gecko "nunca foi bom". Pelo contrário, é graças a ele que tivemos uma alternativa viável ao Internet Explorer. O ponto é que agora há uma outra alternativa que aparenta ser ainda melhor.

Depois você tem essa guerra KDE x GNOME. Até que ponto os projetos recusaram-se a colaborar por conta dos feudos de patrocínio, a grana jogando lenha na fogueira da teimosia?

Um exemplo que um amigo meu (não vou dizer que é o Rudá) vive citando é o PyPy, aquele projeto que desenvolve um interpretador Python escrito em Python. Depois de defender o projeto e agüentar MUITA gozação de outros amigos céticos, eu fico pensando: por que não buscar objetivos mais palpáveis e úteis para o Python tais como: JIT, threading melhorado, enfim, essas coisas que o tão criticado Java possui, e que até o Javascript está chegando lá?

Mas toda regra tem exceção. Uma coisa que nem dinheiro explica é o absurdo de o Linux não ter uma API estável para drivers de kernel. Na verdade não tem desculpa para não oferecer inclusive uma API de nível mais alto, à moda do IOKit. Simplesmente não consigo imaginar uma forma de fazer essa decisão estúpida de arquitetura render grana. Até onde vai minha visão, é só burrice e teimosia mesmo.

Quo vadis Nokia?

I was thinking about a title for this post, something like "Where the hell is Nokia going?". Then I remembered about that old movie "Quo Vadis".

Funnily enough, I Googled the title before writing something, and surprise: I found another post with the same title and subject which actually tells the very same things I was going to write. So I am just going to write an "appendix" to vent out.

My angst (and rage) about Nokia began to build up when I went to download Python for Series 60. I am going to teach a mini-course about PyS60 in PyCon Brazil 2009. Went to the pages I used to find PyS60. All of them out-of-service or obviously abandoned. WTF, PyS60 getting abandoned?

I finally found PyS60 at garage.maemo.org, it's being released often, but... all that abandoned pages should have been taken care of, and PyS60 deserved a smarter and more official "home" than garage.maemo.org. It is not a Maemo project, after all. And which other alternatives do we have for easy S60 development? I know that everybody is going to Javascript these days, and S60 has this widget thing now, but widgets are not applications. PyS60 can do whole, standalone applications, so it is not a serious alternative by now. Please offer us developers JSS60 before thinking about ramping down PyS60!

And then we have this insistence on Symbian. People used to believe that Symbian OS has some "secret power" that makes it so good for mobile. Nokia certainly believes in that, because there is nothing left to believe: the API is terrible, the SDKs are terrible (maybe 5th Edition SDK is better, I havent' played with it yet), the UI is terrible, several APIs are not open, and so on.

Maemo Project, which is based on Linux, is around for 4 or 5 years. If Maemo couldn't be put in a mobile phone in so much time, Linux should be really bad, right? God in the skies and Symbian on Earth, right?

Well, in the last 4 years that I work more closely with mobiles, we have seen SEVERAL new mobile operating systems being built from scratch, all of them being very well-received. I am talking about Android, Palm Pre and iPhone OS. Two of them use Linux kernels, one of them is derived from UNIX (OS X). All of them have excellent SDKs, good APIs which make sense for the average developer, and so on. UNIX is not that bad for mobile, after all. (It could mount up to 5, if Openmoko and GreenPhone didn't sink.)

Maemo has IMHO a serious defect: it tries to be a "normal" Linux, with X11 and GTK+. All other mobile systems use a custom UI system. Nevertheless, it is still possible to use it, and make a nice UI on top of it. Maemo 5 is coming with accelerated 3D hardware, so OpenGL ES can be used to bypass X11 and GTK limitations completely.

Nokia seems to be afraid of releasing some mainstream product with Maemo. Or worse, Nokia does not really believe in Maemo, which explains why Maemo development is so slow, allowing no less than three competitors to release "open" systems running inside real cell phones before Maemo makes it. If only N810 had a 3G SIM card slot... Actually, Maemo 5 hardware will have it, but perhaps too late.

Indeed Maemo 5 brings three things that should be in place since Maemo 1: accelerated 3D, Qt toolkit, and support to GSM/3G packet data.

But Maemo 5.0 will still have GTK+ as official toolkit, and Qt as a community supported toolkit. Maemo 5.x or 6.0 will promote Qt to officlal and bust GTK+ to community. Wouldn't be better just to delay Maemo 5 and use Qt as official toolkit from the beginning? Maemo is late for the market anyway.

Buying Qt was the one right thing Nokia did. It was a surprise, and it was nice news. But I am growing skeptic about how Nokia will actually milk Qt. Let's remember TrollTech had a ready-to-used Linux phone (GreenPhone), based on QTopia which does not depend on X11. But the current trend in Nokia seems to be the S60 port for Qt. Why?

I must agree that it is desirable to have a common toolkit between Maemo and Series 60, since there are so many S60 phones out there... but let's be frank, how many S60 *developers* are out there? Very few, to the point that I bet PyS60 community is actually bigger. At least, you find PyS60 things way easier on Google than for C++/S60. How many S60 owners actually install 3rd party applications? Very, very few. Most people buy S60 phones because of the great hardware, way better than iPhone, but this reason for buying phones will not stand forever. The iPhone 3GS is out there already.

Worse yet, it feels like Nokia found an excuse to keep Symbian around and maintain the status quo. Extrapolating a little bit the observed facts, it even seems that Python (given what has been done to PyS60) is being abandoned because developing in C++ and Qt is soooo great. In fact Qt "fixes" C++ in several ways, but is still not Python. And Qt indeed has an internal Javascript interpreter, but it is *far* from allowing you to develop whole applications with pure Javsacript. Qt is great but it can not operate miracles. If it did, KDE would have taken over the world.

Another thing that I simply can not understand, is why smartphones newer than N93/N95 dared to show up without 3D hardware acceleration. N95 was so great by many because of that -- having 3d acceleration when nobody had it -- and I have even heard from many people that they are not going to buy a N85 or a N96 because some game they bought wouldn't run on them. I am not a hardware guy, I am a complete ignorant about how 3D acceleration influences device cost and price -- but I simply can't understand why Nokia didn't set this standard. It would be just for the S60 expensive smartphones, not for the 1208. (N810 coming without OpenGL was a mistake that came from the same source, I guess.)

Some people say that "Nokia can always make money selling cell phones for poor people". I am not sure; at least in Brazil the low-end phone market has been taken by LG, Samsung and other manufacturers from Asia, which make that pink-and-pretty-but-kitsch phones what we'd buy for a 17-year-old mistress. Nokia low-end phones are getting definetively scarce in cell phone stores, even though they *are* better.

And, in time, even poor people will want smartphones. CRT televisions simply don't sell anymore here; even poor people will buy LCD TVs (and stainless steel big and beautiful fridges) even if it makes no economic sense for them. The same is happening with other consumer electronics. Who buys a cell phone without a camera these days? So, the smartphone will eventually become the only kind of "phone" around. </john_dvorak>

So, wrapping it up:

* Kitsch phone market has been taken by Asian manufacturers, and this kind of phone will eventually disappear

* "Business" people are using Blackberries and will probably jump the Palm Pre bandwagon. Palm still has a lot of "friends" out there, and Palm development community is bigger than most people think.

* "Cool" people have bought iPhones

* GNU/boring people, a niche market, will probably go for Android phones

So, what's left for Nokia? Currently, not even the GNU/borings can be satisfied by any Nokia product (though Maemo 5 will be "almost" a cell phone.)

I have an opinion about Nokia should do. I am not a business executive but I am a developer and I know a bit about platforms, and why they become popular or not.

* It's the developers' community, stupid! A platform is as good as the applications made for it. A new platform does NOT need to follow 100% of a established standard. It just needs to MAKE SENSE, and to have good APIs, SDKs and documentation. Making a good platform is not easy, but Palm has done it twice, so it is not impossible. And UNIX/Linux is out there to provide a good basement. Just don't make it utterly difficult and confusing like Symbian just because 16-bit mobiles needed applications to be that way. Also, take the opportunity and don't make things like secret APIs that every non-trivial application must use.

* There is no time to create an operating system from scratch, so it's gotta be Linux or Symbian. Neither Symbian nor Linux can compete head-to-head with iPhone OS, so don't even try. The alternate strategy is to offer things for "non-cool" people. A system that is open, developer's-friendly, and will find its way into many use cases, even if it is not flashy like an iPhone. Macintoshes continue to be a niche, after all.

* Dump Symbian APIs completely. Take the opportunity and dump Symbian kernel altogether. It's utterly proven that Symbian kernel has no magic powder trapped in it, and everybody else is doing well with UNIX kernels. (If Symbian were so good, Series 40 would have disappeared already.) Arguments about sunk cost are just for governments.

* Make Maemo happen, perhaps making some bold changes in its stack, like removing X11 or using it just as a display driver. Weld Qt into Maemo, so Qt *must* be used, even if it is the only option, to avoid that Linux thing "oh-you-have-3490-toolkit-options-but-no-one-is-actually-good-and-well-integrated-with-environment-but-YOU-HAVE-FREEDOM-MAN!".

* Given there are so many million Nokia smarthones out there, make them work for you. Offer a Maemo alpha for, say, N95. It doesn't even be compatible with more than one model. A lot of brave developers will like to test it. N95 is best because it is "old" but feature-packed and can be bought cheaply on eBay. And a N95 with Maemo can still be used as a phone, while N810 is deadweight that nobody carries around. I won't buy a new and expensive Maemo hardware just to help to test it; I'd rather buy an iPhone with that money, sorry. But I'd buy a N95 for that.

* Take the opportunity and compile Qt to use OpenGL backend only. Put 3D acceleration hardware as a platform requirement. If the factory UI comes out ugly, at least the talented developers have the tools to do better in their own applications.

* Take a really good team of UI designers and developers, lock them in a convent and don't let them exit until they come up with a really nice UI.

* Pretty please, commit to interpreted language support. Stop handling Python, as a concession made to silence noisy developers. If you prefer Javascript to Python, that's ok, but Javascript must be enabled to write whole applications; adding widget support is just copying Apple. Make it better than Apple, going beyond Javascript and not labeling interpreted languages as a "just for widgets" thing.

* I respect the *idea* of offering Qt for S60 as a bridge environment. But I guess that almost nobody will use it. Like OpenC, Qt does not free the developer from the infamous Symbian SDK (and Windows!), which is an even bigger problem than the API. I'd dump this effort too. It hurts to say that, because the port makes sense in principle, but now I am thinking about better R&D resource usage.

* I agree that some kind of code signing is necessary for cell phone applications which are made available "for the whole world", but Symbian Signed is infamous because it wants to extort the developers, while it should milk the customers. Also, it negates free access to capabilities even on developer's own phone! There is no reason why a developer should not be able to install a full-capability application in his own phone, or deploy it for a specific set of IMEIs. Take the opportunity and make it friendlier than Apple; listen to developer's complaints and do better.

* Make money by selling good hardware with decent software. Take these hypes like Internet stores etc. with a grain of salt. I believe that things like Apple Store are fit in an environment where there is a good hardware, with good operating system, and happy developers. Apple Store just closes the circuit while enforcing code signing (in a way that developers don't feel extorted.) iTunes music store happens because there is a good iTunes and a marvelous iPod to connect with. Ovi won't make Symbian look good, however.

* A shrink in product line may be in order. I am actively interested in Nokia N-smartphones and I must say I am permanently confused about the features of every one. We have N85, N82, N95, N96, N97... each one is best in a single thing. I already learnt that N82 has the best camera, but the rest, I don't know.

Qt and Javascript^WQtScript

Today (at dawn) I had my first experience with Javascript inside Qt. The language is actually referred as QtScript by Qt documentation. The thing is simply great. Executing simple Javascript code is simple as

QScriptEngine engine;
qDebug() << engine.evaluate("a = 1; b = 2; a + b;").toInt();

As expected, the "protocol" between C++ and Javascript objects has its rules. Javascript can't "see" the current application's context. For exemple, if we want to make an object available to Javascript, we must add it to the global scope:

engine.globalObject().setProperty("close_button", closeButton);

When an object is made available in Javascript context, the following features (among others) are made available from Javascript side:

a) properties can be set and get using the obj.property syntax. Yet another incentive to use Qt properties as much as possible in our C++ classes.

b) public slot methods can be called (as normal methods) from Javascript, since Qt has introspection information about them. Too good that exporting methods as slots costs nothing.

c) signals and slots can be used (connected and fired at will). Slot functions may be written in Javascript. The only limitation is that signals must be defined in C++; you can not define a new signal in Javascript.

Non-slot methods must be encapsulated to be made available. The easiest way is to connect them to properties, which in turn are always available in Javascript space.

Perhaps unexpectedly, class constructors are not made automatically available to Javascript. Constructors and C++ free functions must be added to Javascript by encapsulating them in QScriptValue objects and then adding them to Javascript scope the same way we did with closeButton.

This means that, for now, QtScript can not be used to write whole applications, because it always depends on a C++ supportive "shell" to make the right objects and classes available for scripting.

I guess the problem can be mitigated somewhat by using factories in C++; if you use factory("AnyClass") to instantiate objects, it is just a matter of exporting the factory() to Javascript. Of course, this leaves the Qt classes themselves out.

If we want to use some Javascript in our Qt apps, there are some architectural trends that we must follow. Using properties, signals/slots and factories instead of static method calls everytime we can. And leave behind the anal-retentive mania of keeping most methods protected/private. Those techniques make life easier in C++ anyway, so why not?