I did it. I went to FNAC and bought it. I really did it :)
I just got this new Acer Aspire One (D250).
I've installed UNetbootin on my Fedora and downloaded an Ubuntu 9.10 image. After deploying the image to a 2GB USB stick, and booting the netbook, it just went on booting without any trouble at all. That's what I like in Ubuntu, and that's what I need for this laptop. After booting, just went through the installer and, after a couple of questions, all was ready: Wi-fi, Ethernet, Microphone, Webcam, everything worked out-of-the-box. Even the Wifi led is working, against all odds :)
I went through a shared installation to keep things simple. I still have to investigate this further, but awesome as well is the fact the Ubuntu installer respected both Android and Windows 7. Both are still bootable, the first being booted without option (I think it's my fault when I was asked how I'd like it to boot), then GRUB, and from there I can go wherever: Ubuntu or Windows 7.
Windows 7, as usual, didn't seem prepared to partition adjustments. After first boot it started a filecheck (still the good'old CHKDSK, just imagine :)... after rebooting again, it was ready to stay. Luck for it that handled it afterall, as its days of existence here are probably limited.
So, this page is needing an update. Pending testing is now the card reader and the webcam. After that, I should update the page.
In the meantime, between reboots, I just found my newest addiction (on the phone, so far) online as well: Tower Bloxx :)
quinta-feira, 28 de janeiro de 2010
domingo, 24 de janeiro de 2010
Início das actividades da Wikimedia Portugal
Não deve ser novidade que a Wikimedia Portugal (WMP) já arrancou o Plano de Actividades para 2010-11. A primeira actividade oficial foi uma apresentação num seminário no Instituto Superior Técnico promovido pela Presidência do Departamento de Engenharia Informática, a convite do prof. José Borbinha, que gostámos muito de conhecer e a quem agradecemos o apoio e disponibilidade que demonstrou para connosco.
A Susana fez uma exposição da Wikimedia Foundation, do nosso contexto WMP, do processo editorial, da estrutura interna dos projectos (utilizadores, categorias, etc), da manutenção, licenciamento, etc.
A apresentação está aqui:
http://wikimedia.pt/download/Wikimedia_Slideshow.pps
Eu juntei-me à festa, atendendo a um público de informática, e apresentei brevemente a plataforma da WMF (servidores, software, arquitectura) mas o grosso da minha mini-apresentação foi para falar de predefinições, dados estruturados e seus benefícios na Wikipédia e, por fim, divaguei um bocadinho até à Web Semântica, conceito para o qual a Wikipédia está a ser bastante utilizada (os tópicos estão resumidos em 2 posts que já tinha feito no blog [1][2]).
A apresentação está aqui:
http://wikimedia.pt/download/Wikimedia_Web_Semantica.pps
Ainda sobre o tamanho dos campos VARCHAR...
Em Setembro escrevi sobre as consequências de deixar ao acaso o tamanho e character set de campos VARCHAR. Entretanto gostaria de complementar as observações com o que escrevo abaixo.
A mistura de charsets — como ter uma tabela num charset e um determinado campo dessa tabela com outro charset diferente, por exemplo — deve ser cuidadosamente analisada. Existe alguma probabilidade de ocorrerem complicações, caso se trate esta questão levianamente.
À parte do que se deve ou não fazer, o que eu gostaria era que se compreendesse o benefício que se pode atingir no caso particular da utilização de UUIDs. Já vimos que UTF-8 para este caso particular é um desperdício, mas o que gostaria de demonstrar são se, de facto, compensa alterar campos específicos quando nem todos podem ser alterados.
Vejamos: vão ser criadas 2 tabelas MyISAM em UTF-8, uma com um campo Latin1 e outra com o campo natural, em UTF-8. Vou usar uma tabela que tinha para aqui com 2M de UUIDs apenas para acelerar o processo. Essa tabela, table_uuid, é original Latin1, embora o foco não seja sobre o carregamento dos dados, mas sim do seu cruzamento entre as duas primeiras:
[mysql]
mysql> create table charset_latin1 ( id char(36) charset latin1, primary key (id) ) charset utf8;
Query OK, 0 rows affected (0.01 sec)
mysql> create table charset_utf8 ( id char(36) charset utf8, primary key (id) ) charset utf8;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into charset_utf8 select id from table_uuid ;
Query OK, 2097152 rows affected (2 min 29.77 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
mysql> insert into charset_latin1 select id from table_uuid ;
Query OK, 2097152 rows affected (50.15 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
[/mysql]
Agora, suponhamos que a tabela charset_latin1 é uma tabela originalmente em UTF-8, para a qual já fizemos a transformação do campo (que vai albergar UUIDs) para Latin1. O que pretendemos demonstrar são os ganhos/prejuízos do cruzamento de tabelas com as mesmas características, e com diferentes:
[mysql]
mysql> select count(1) from charset_utf8 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (1 min 8.82 sec)
mysql> select count(1) from charset_utf8 a, charset_utf8 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (58.00 sec)
mysql> select count(1) from charset_latin1 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (24.43 sec)
[/mysql]
Ou seja, como já se disse, fazer JOINs com Latin1 é muito rápido, relativamente às outras opções. Mas repare-se quando se cruzam diferentes charsets (1º JOIN): ocorre uma degradação de 19% face ao pior caso.
Ou seja, tendo em conta que estas tabelas podem ser apenas tabelas de relação [quero com isto dizer que não contêm dados que não sirvam senão para cruzamentos/JOINs] é expectável que a performance se degrade sempre que sejam cruzadas com outras cuja chave não esteja no mesmo charset. Deduz-se daqui que existe, portanto, overhead relativo às conversões de charset durante o JOIN.
Apesar de estarmos perante um index scan (ie, com os dados todos em cache), ocorreu-me também experimentar com InnoDB.
[mysql]
mysql> alter table charset_utf8 engine=innodb;
Query OK, 2097152 rows affected (48.18 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
mysql> alter table charset_latin1 engine=innodb;
Query OK, 2097152 rows affected (39.43 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
[/mysql]
Convém ressalvar aqui que fiz uns SELECTs primeiro para ter a certeza que os datafiles estavam carregados na buffer pool.
[mysql]
mysql> select count(1) from charset_utf8 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (21.65 sec)
mysql> select count(1) from charset_utf8 a, charset_utf8 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (12.61 sec)
mysql> select count(1) from charset_latin1 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (8.25 sec)
[/mysql]
Ou seja, a conclusão que se pode tirar daqui é que: não só devemos pensar na optimização que se ganha com a escolha do charset, mas também devemos analisar o impacto de não podermos levar a tarefa de reconversão avante na totalidade. A necessidade de cruzar campos com charsets diferentes torna-se, efectivamente, mais penoso. Resta comparar, caso a caso, o benefício que se obtém em queries pouco/nada optimizadas versus o prejuízo de performance que poderá reflectir-se em cruzamentos/JOINs com campos em charsets diferentes.
A mistura de charsets — como ter uma tabela num charset e um determinado campo dessa tabela com outro charset diferente, por exemplo — deve ser cuidadosamente analisada. Existe alguma probabilidade de ocorrerem complicações, caso se trate esta questão levianamente.
À parte do que se deve ou não fazer, o que eu gostaria era que se compreendesse o benefício que se pode atingir no caso particular da utilização de UUIDs. Já vimos que UTF-8 para este caso particular é um desperdício, mas o que gostaria de demonstrar são se, de facto, compensa alterar campos específicos quando nem todos podem ser alterados.
Vejamos: vão ser criadas 2 tabelas MyISAM em UTF-8, uma com um campo Latin1 e outra com o campo natural, em UTF-8. Vou usar uma tabela que tinha para aqui com 2M de UUIDs apenas para acelerar o processo. Essa tabela, table_uuid, é original Latin1, embora o foco não seja sobre o carregamento dos dados, mas sim do seu cruzamento entre as duas primeiras:
[mysql]
mysql> create table charset_latin1 ( id char(36) charset latin1, primary key (id) ) charset utf8;
Query OK, 0 rows affected (0.01 sec)
mysql> create table charset_utf8 ( id char(36) charset utf8, primary key (id) ) charset utf8;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into charset_utf8 select id from table_uuid ;
Query OK, 2097152 rows affected (2 min 29.77 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
mysql> insert into charset_latin1 select id from table_uuid ;
Query OK, 2097152 rows affected (50.15 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
[/mysql]
Agora, suponhamos que a tabela charset_latin1 é uma tabela originalmente em UTF-8, para a qual já fizemos a transformação do campo (que vai albergar UUIDs) para Latin1. O que pretendemos demonstrar são os ganhos/prejuízos do cruzamento de tabelas com as mesmas características, e com diferentes:
[mysql]
mysql> select count(1) from charset_utf8 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (1 min 8.82 sec)
mysql> select count(1) from charset_utf8 a, charset_utf8 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (58.00 sec)
mysql> select count(1) from charset_latin1 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (24.43 sec)
[/mysql]
Ou seja, como já se disse, fazer JOINs com Latin1 é muito rápido, relativamente às outras opções. Mas repare-se quando se cruzam diferentes charsets (1º JOIN): ocorre uma degradação de 19% face ao pior caso.
Ou seja, tendo em conta que estas tabelas podem ser apenas tabelas de relação [quero com isto dizer que não contêm dados que não sirvam senão para cruzamentos/JOINs] é expectável que a performance se degrade sempre que sejam cruzadas com outras cuja chave não esteja no mesmo charset. Deduz-se daqui que existe, portanto, overhead relativo às conversões de charset durante o JOIN.
Apesar de estarmos perante um index scan (ie, com os dados todos em cache), ocorreu-me também experimentar com InnoDB.
[mysql]
mysql> alter table charset_utf8 engine=innodb;
Query OK, 2097152 rows affected (48.18 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
mysql> alter table charset_latin1 engine=innodb;
Query OK, 2097152 rows affected (39.43 sec)
Records: 2097152 Duplicates: 0 Warnings: 0
[/mysql]
Convém ressalvar aqui que fiz uns SELECTs primeiro para ter a certeza que os datafiles estavam carregados na buffer pool.
[mysql]
mysql> select count(1) from charset_utf8 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (21.65 sec)
mysql> select count(1) from charset_utf8 a, charset_utf8 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (12.61 sec)
mysql> select count(1) from charset_latin1 a, charset_latin1 b where a.id = b.id;
+----------+
| count(1) |
+----------+
| 2097152 |
+----------+
1 row in set (8.25 sec)
[/mysql]
Ou seja, a conclusão que se pode tirar daqui é que: não só devemos pensar na optimização que se ganha com a escolha do charset, mas também devemos analisar o impacto de não podermos levar a tarefa de reconversão avante na totalidade. A necessidade de cruzar campos com charsets diferentes torna-se, efectivamente, mais penoso. Resta comparar, caso a caso, o benefício que se obtém em queries pouco/nada optimizadas versus o prejuízo de performance que poderá reflectir-se em cruzamentos/JOINs com campos em charsets diferentes.
Subscrever:
Mensagens (Atom)