понедельник, 28 апреля 2008 г.

Google AJAX Language API

Великий Google порадовал разработчиков новым online сервисом «Google AJAX Language API». Функционал нового API — опреление языка текста и получение его перевода. На текущий момент поддерживается 13 языков, среди которых есть и русский. Переводы выполняются только на английский или только с английского языка, т.е. нельзя например напрямую перевести с русского на итальянский.

Чем это может быть полезно web-разработчику? Один из вариантов применения — генерация url-ов для динамического контента, по заголовку новости, теме в форуме или поста в блоге. А с кирилицей в урлах пока дела обстоят неважно. Например, урл новостей на ЛОРе никуда не годится в эпоху Web 2.0 :-)
http://www.linux.org.ru/view-message.jsp?msgid=2686861
Куда симпатичнее смотрелось бы:
http://www.linux.org.ru/news/ubuntu_8.04_released
или
http://www.linux.org.ru/news/2008/04/23/ubuntu_8.04_released

Сам Google позиционирует свой сервис для использования совместно с javascript. Однако, на практике, ничто не мешает применять любой другой язык программирования. Вот небольшой пример на perl, который позволяет получать онлайн перевод с русского на английский в консоли:

#!/usr/bin/perl -w
use strict;

use URI::Escape;
use LWP::UserAgent;
use JSON;

my $text       = $ARGV[0];
my $escaped    = uri_escape( $text );
my $user_agent = LWP::UserAgent->new;
$user_agent->env_proxy;
my $response   = $user_agent->get(
    "http://ajax.googleapis.com/ajax/services/language/translate" .
    "?v=1.0&q=$escaped&langpair=ru%7Cen"
)->content;
my $translated = jsonToObj($response)->{responseData}->{translatedText};

print $translated, "\n";


Пример использования:

$ ./ggl_trnslt.pl "Возьми моё сердце"
Take my heart

Если слово не найдено в словаре, то производится его транслитерация, что обычно лучше чем ничего:

./ggl_trnslt.pl паровоз
parovoz

Хотя и непонятно, почему Гугль не знает про паровозы... Остается надеяться что со временем качество перевода возрастет.

Русский текст должен быть в кодировке utf8. Пример упрощен, в частности не делает никаких проверок на ошибки, но зато хорошо демонстрирует принцип использования.

пятница, 18 апреля 2008 г.

Стандартные ядра в Slackware 12

Какие версии ядра есть в Slackware 12 и как ими пользоваться.
Данная статья предворяет будущий рассказ о сборке ядра в slackware пакет. Эта информация специфична для Slackware 12, в предыдущих версиях системы все было не так.

В дистрибутив Slackware 12 включены 4 сборки ядра 2.6.21.5. Вот они:

kernel-huge-smp-2.6.21.5_smp-i686-2.tgz
kernel-huge-2.6.21.5-i486-2.tgz
kernel-generic-smp-2.6.21.5_smp-i686-2.tgz
kernel-generic-2.6.21.5-i486-2.tgz

Как видно из названий пакетов, 4 сборки ядра получены путем комбинации признаков:
huge или generic
smp или no_smp

SMP версия ядра

Разберемся сначала с тем, что попроще. SMP (Symmetric Multiprocessing) — это поддержка многопроцессорных систем и многоядерных процессоров. Если у вас в компьютере есть несколько процессоров или один процессор с двумя (или более) ядрами, например Intel Core2Duo, то чтобы получить максимальную производительность вы должны выбрать smp ядро. Если у вас один одноядерный процессор, например Intel Celeron, то чтобы ядро занимало меньше памяти и не обрабатывало неподдерживаемые конфигурации оборудования следует выбрать не smp ядро. Кроме того, для очень старых процессоров — Pentium Pro и ниже, также необходимо выбирать не smp ядро, т.к. smp версия собрана с использованием архитектуры i686. Убедится что smp ядро работает с вашим процессором можно с помощью команды:

cat /proc/cpuinfo

Вы должны увидеть информацию о нескольких процессорах, а не об одном.

Huge/generic версия ядра

Теперь рассмотрим признаки huge и generic.

Huge (огромное) — ядро, содержащее вкомпиленные модули для большинства дисковых (SCSI, RAID) контроллеров и файловых систем. При использовании этого ядра у вас в принципе не возникает проблем с загрузкой системы, даже с экзотического оборудования или файловых систем, типа xfs или jfs. Однако, это ядро занимает больше оперативной памяти и работает медленнее. После установки системы всегда по-умолчанию запускается huge ядро.

Generic (общее) — ядро, в котором драйвера дисковых контроллеров и файловых систем собраны в виде внешних загружаемых модулей. Для загрузки такого ядра нужен initrd образ, содержащий необходимые драйвера. Эта версия ядра требует дополнительных телодвижений при настройке, но занимает меньше памяти и работает быстрее.

Переключение на другое ядро

Итак, исходя из изложенной информации вы уже должны знать какое из стандартных ядер вам подходит больше всего. Вопрос в том, как переключится на другое ядро. Ответ — настроить загрузчик lilo, естественно. Для huge ядер это делается очень просто, в файле /etc/lilo.conf должны быть такие строки:

#huge-smp:
image = /boot/vmlinuz-huge-smp-2.6.21.5-smp
  root  = /dev/xxxN
  label = lnx-huge-smp
  read-only

#huge-nosmp
image = /boot/vmlinuz-huge-2.6.21.5
  root  = /dev/xxxN
  label = lnx-huge
  read-only

Напомню пару правил при работе с загрузчиком lilo.

  1. После изменения файла /etc/lilo.conf всегда запускайте утилиту lilo, чтобы изменения вступили в силу.
  2. Всегда оставляйте один из пуктов меню с гарантированно рабочей конфигурацией на случай, если что-то пойдет не так.

Для generic ядер надо создавать initrd образ. Для этого используется утилита mkinitrd. Например, мне надо создать initrd образ для ядра generic-smp, корневая файловая система на ext3. Тогда мне необходимо ввести команду:

mkinitrd -с -k 2.6.21.5-smp -m ext3 -o /boot/initrd-generic-smp-2.6.21.5.gz

Ещё пример — initrd образ для ядра generic-nosmp и корневая файловая система reiserfs:

mkinitrd -с -k 2.6.21.5 -m reiserfs -o /boot/initrd-generic-2.6.21.5.gz

Теперь как это прописать в /etc/lilo.conf:

#generic-smp:
image = /boot/vmlinuz-generic-smp-2.6.21.5-smp
  initrd = /boot/initrd-generic-smp-2.6.21.5.gz
  root   = /dev/xxxN
  label  = lnx-gen-smp
  read-only

#generic-nosmp
image = /boot/vmlinuz-generic-2.6.21.5
  initrd = /boot/initrd-generic-2.6.21.5.gz
  root   = /dev/xxxN
  label  = lnx-gen
  read-only

В заключении скажу, что переход на generic ядро всегда оправдан. В моём тестовом случае:

  1. Освободилось 5Мб оперативной памяти. Вычислялось как разница между показаниями
    grep MemTotal /proc/meminfo
    для huge и generic ядра.

  2. Количество системных процессов ядра, те, чьи имена пишутся в квадратных скобочках, уменьшилось на 11 штук:
    ps axo cmd | grep \\[