Държа да отбележа, че проблема, според мен, се дължи по-скоро на промени в начина по който се записват сессите, отколкото на бъг в самото KDE 4, понеже досега всичко беше наред и подобни неща не се бяха случвали.

Както и да е, факт е, подобно поведение може да изкара от кожата всеки потребител. Проблемът беше как да запиша настройките по desktop-а си и да накарам session manager-а да ги ползва при login.

Оказа се, че макар и да е изчезнал бутонът Save session, DBus call-ът си седи, което и беше решението на проблема ми. Ето го и магическият ред, който оправи нещата:

dbus-send --type=method_call --dest=org.kde.ksmserver \
/KSMServer org.kde.KSMServerInterface.saveCurrentSession

dd if=/dev/urandom count=1 2> /dev/null | uuencode -m - |  \
sed -ne 2p | cut -c-64

А ето и резултата от стартирането й 5 пъти:

zMqzLNZAzVlQWMvEztpgfeY289TEtdUFbPVB8nXoo1PvdUsKVKSHHBmFo7p8
Xr9JfBcb5hb5oKqNre6kF6DXTVAcUycCW8ru+BpqvsxRlJ57dji7MHfoFcN1
5no2uWDeJtkHpO2qm71pyMx7Bt7pomBiJqrILVgPZckXUvMpqzeQPDiwRQ8v
kdTExBa0jFZrQZFjJ8TeQ9AaL0m3M2vWXymPxcrPn4HtepZT0EQh1nzoiA5x
TUPbIeyEluKEOGSVOP33wY8DiJVnWu2Mn8ElMbwYMt/TH08sTsJVOOEN7qkV

Затова навсякъде където видите съобщение от сорта на:

package [somepackagename] removed but not purged

изпълнете като root

dpkg --purge [somepackagename]

При мен, обаче, освен тези по-дребни проблеми, имаше и един малко по-сериозен.

Едно от съобщенията гласеше:

insserv: warning: script Slibdevmapper1.02 missing LSB tags
and overrides

След малко ровене в google намерих въпросния header:

### BEGIN INIT INFO
# Provides:          libdevmapper
# Required-Start:    modutils
# Required-Stop:     modutils
# Should-Start:      hotplug discover udev devfsd
# Default-Start:     S 2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO

Добавих го в /etc/init.d/libdevmapper1.02 веднага под shebang-а (първият ред, започващ с #!) и, за да си конфигурирам успешно миграцията към dependancy based boot, пуснах отново

dpkg-reconfigure sysv-rc

За проблема със слушалките – в /etc/modprobe.d/alsa-base трябваше да конфигурирам драйвера snd_hda_intel по следния начин:

options snd_hda_intel model=sony-assamd

После с rmmod разкарах заредените модули свързани със snd_hda_intel и ги презаредих с което приключи с този проблем.

С осветлението на дисплея, обаче, нещата не бяха толкова розови. Специалните клавиши за него изобщо не работеха. За да получа кодовете на brightness up (Fn+F5) и brightness down (Fn+F6) пуснах от Konsole в KDE xev и с фокус върху него натиснах последователно двете комбинации. Резултата беше следното:

KeyRelease event, serial 31, synthetic NO, window 0x1a00001,
    root 0x78, subw 0x0, time 3516679, (535,672), root:(538,694),
    state 0x0, keycode 101 (keysym 0xffd1, F20), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
    .... (skipped) ....
KeyRelease event, serial 34, synthetic NO, window 0x1a00001,
    root 0x78, subw 0x0, time 3520374, (535,672), root:(538,694),
    state 0x0, keycode 212 (keysym 0xffd2, F21), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Kодовете, които ми трябваха бяха 101 и 212 (втората секция на всеки трети ред от KeyRelease event-a). Следващата стъпка беше да ги добавя във файла .xmodmaprc в /home/stinger.

# /home/stinger/.xmodmaprc
keycode 160 = XF86AudioMute
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 101 = F20
keycode 212 = F21

Това, обаче не ми реши проблема изобщо. За да накарам тези клавиши да работят, в KDE Control Center > Regional & Acessibility > Keyboard Actions си създадох два action-a от тип Keyboard Shortcut -> Command/URL (simple). Първият кръстих Brightness Up с Shortcut Key F21 и action /etc/acpi/sonybright.sh up, а вторият – Brightness Down с Shortcut Key F20 и action /etc/acpi/sonybright.sh down.

Сега вече командата се извикваше, но пак не вършеше никаква работа Причината беше, че търси за текущата стойност на осветеността на дисплея в /sys/class/backlight/sony/brightness, а поне на моята машина на съществуваше изобщо директория sony в /sys/class/backlight.

С малко човъркане из Google се спрях на бързото решение с ползването на вградения в X инструмент за управление на backlight-a, кръстен… xbacklight. Копирах си неработещия файл:

cp /etc/acpi/sonybright.sh /etc/acpi/sonybright.sh.orig

и на негово място създадох файл sonybright.sh със следното съдържание:

#!/bin/bash
case $1 in
   down)
      xbacklight -time 100 -steps 12 -dec 12.5
   ;;
   up)
      xbacklight -time 100 -steps 12 -inc 12.5
   ;;
   *)
      echo "Usage /etc/acpi/sonybright.sh {up|down}"
   ;;
esac

Забелязах обаче нещо странно – ACPI не хващаше event-a от клавишите. С малко четене разбрах, че Sony имат два модела контролери за notebooks – първият беше SNC (Sony Network Controller), вторият – SPIC. Моята машина беше със SNC, затова mod-нах леко два файла в /etc/acpi/events, докато не получих това:

# /etc/acpi/events/sony-brightness-up

event=sony/hotkey SNC 00000001 00000011
action=/etc/acpi/sonybright.sh up

# /etc/acpi/events/sony-brightness-down

event=sony/hotkey SNC 00000001 00000010
action=/etc/acpi/sonybright.sh down

Рестартирах acpi демона и пуснах следната команда, тествайки клавишите:

acpi_listen

Клавишите проработиха (поне връщаха event-и от вида sony/hotkey SNC 00000001 00000010), но xbacklight не вършеше никаква работа, защото достъпът до X като root беше забранен. Реших да го оставя така и да разчитам на KDE Input Actions за управление на клавишните комбинации към скрипта. Ако искате да имате управление през ACPI – разрешете root достъпа до X, или в конзола, като нормален потребител, напишете:

xhost +

За мен лично сигурността е по-важна от глезотиите. След това остана само да изпълня следното и всичко тръгна по вода:

xrandr --output LVDS --set BACKLIGHT_CONTROL native

За да не ми се налага всеки път като заредя KDE да пиша въпросната команда я сложих в края на .profile в /home/stinger. Малка персонализация на решението беше да сложа и команда, която променяше осветлението на 50% от интензитета му при всеки login, защото 100% ми идваха в повече. Затова, последните два реда на .profile изглеждат така:

xrandr --output LVDS --set BACKLIGHT_CONTROL native
xbacklight -set 50

С това машинката започна да си управлява осветлението на екрана, вярно само под KDE, но все пак е нещо. В GNOME получавам notification за статуса на осветлението, дори стойността му в notification-a се променя, но xbacklight не се изпълнява. При разрешаване на root access към X-a нещата ще проработят и там, а и в X изобщо, гарантирам… Друг е въпроса дали това е цената, която сте готови да платите за тази глезотийка. В крайна сметка, винаги в конзола можете да напишете нещо от сорта на:

xbacklight -set 50

Преди повече от половин година стария ми компютър предаде богу дух и остави след себе си купчина железария, която продължава да събира прах. Заместникът му – едно Sony Vaio – засега се справя отлично и единственото с което си спомням старата машина са няколкото лични проекта, останали заровени по хардовете й. Единият от тях беше Flex проект за личното ми портфолио, който видя бял свят на този адрес. Този, който ми беше по-важен, обаче, по всички закони на Мърфи страдаше от липса на SQL dump от базата данни.

Понеже съм мързелив, първата ми работа беше да си копирам .frm файловете от DB-то на другия компютър, само за да установя, че съм ползвам InnoDB като storage engine. Неприятното в случая беше, че InnoDB пази доста голяма част от данните за базата във файла ibdata1, и възстановяването по този начин ставаше почти невъзможно.

Втората опция беше да ползвам chroot за да стартирам MySQL от харда на умрялата машина, но първият опит завърши със следното:

/dev/null: Permission denied

Проверката показа следното:

$ ls -Al /dev | grep null
crw-rw-rw- 1 root root      1,   3 2009-01-18 19:50 null

Device-a си стоеше, но беше неизползваем по някаква причина. Оказа се, че при mount по подразбиране всичко devices са неизползваеми (nodev) и решението на моя проблем беше ето това:

mount -o remount,dev /dev/sdb2

След като remount-нах устройството и chroot-нах вътре пробвах да пусна mysql, но се оказа, че нямам /proc в jail-a. Успях да го създам по следния начин:

mount -t proc none /mnt/olddeb

Пускането на mysql сега обаче ревеше за съществуващ PID. Оказа се, че съм забравил да спра локалния mysql, този който е извън chroot-a и след като го направих, този от старата машина запали без никакви ядове. След това dump-a мина по вода, успях да си прехвърля файла и да си възстановя целия проект.

Предполагам горното ще бъде полезно на всеки, който се опитва да пуска услуги от съсипана по една или друга причина дистрибуция, стига поне основните неща от нея да работят. За мен играта с chroot беше нова, но ми даде разни идейки за “затваряне” на несигурни услуги.

Вчерашният Свети Валентин се е оказал target дата за пускането на дълго отлаганата нова версия на най-голямата Linux-дистрибуция – Debian. Всеки, запознат с проекта знае, че излизането на нова версия си е жива мъка – докато бъдат удовлтворени всички изисквания, относно качеството на софтуера, бинарните драйвери и проблемни лицензи обикновено минават поне 5 месеца. И този път случаят е такъв – версия 5.0 трябваше да се появи още септември миналата година, но поради ред причини (най-вече release critical bugs и един дебат, свързан с т.нар. blob драйвери) нещата се позабавиха леко. Ако не знаете, всяка от версиите на Debian е именувана на някой от героите от филмчето на Pixar – Toy Story – и версия 5.0 носи кодовото име Lenny.

Чакането, обаче, си струва всеки ден, защото едни от най-ключовите неща в този release са свързани със затягането на сигурността – инсталатора проверява и обновява системата още преди първото стартиране, отделни пакети, засягащи сигурността, са компилирани със специални опции за сигурност на GCC, а като цяло “чистата” система след инсталация отваря много по-малко портове и значително по-малко от приложенията се ползват със setuid root.

Като фен на testing branch-a отдавна ползвам нещо, близко до 5.0, и съм много доволен както от производителността, така и от стабилността на системата. Излизането на Lenny, обаче означава и придвижване на нещата от experimental в unstable, а на тези от unstable – в testing, което гарантира следващите два-три месеца да са много интересни. Относно сегашният stable – с този набор пакети не виждам по-добър избор на операционна система за hosting-компаниите. Ако ви е интересно какво се случва преди пускането на release – ето log от работата на един от членовете на екипа за пускане на Lenny:

• [10:23] turned off all cronjobs
• [10:43] Release Team GO
• [12:00] etch is now oldstable
• [13:07] lenny is now stable
• [13:28] squeeze is born (and lot of the work for it was parallel with the lenny work)
• [14:18] the cd-builder host gets an exclusive push so people can start building cd images.
• [15:34] squeeze is now grown up enough to be ready for the world. Most of the other work that had to be on the ftp-master machine before we are done is also done. ftp-master is ready for regular work again (but won’t do any yet).
• [15:40] Lets start the work for the security archive
• [16:54] The security archive is ready.

Това, което е ясно от цялата работа е, че следващата версия на Debian ще носи името Squeeze. В името на рекорда Lenny идва във вариант от по 32 CD-та или 5 DVD-та за всяка от 12-те поддържани архитектури. Да ни е честито!

Наскоро се натъкнах на следната ситуация: приятел ме помоли да му запиша FreeBSD, защото искал да се пробва седмица-две с нея на личния си компютър. Това, което ме учуди при свалянето на дисковете от сайта на проекта е липсата на DVD ISO image. Малко търсене в Google ме убеди, че инсталация във формат на DVD е налична само за закупуване, а за свободно сваляне разполагате с избор от три инсталационни диска и един с документация.

Все пак живеем в 21-ви век, където 4 CD-та със сигурност струват повече от 1 DVD, а и инсталацията от DVD е в пъти по-бърза от варианта с CD, затова потърсих още малко из Google и с това, което открих успях да събера всичките 3 инсталационни диска, както и този с документацията на едно DVD.

Стъпките, които са необходими са сравнително елементарни – след като изтеглите CD ISO-тата за вашата архитектура (i386 или amd64), отворете конзола и в домашната си директория придобийте root-права:

$ cd ~
$ su
Password:
#

След това, като root изпълнете следните команди:

$ mkdir /tmp/tst
$ mkdir fbsd7
$ cd fbsd7
$ mount -t iso9660 -o loop ../7.0-RELEASE-i386-docs.iso /tmp/tst
$ tar -C /tmp/tst -cf - . |tar -xf - 
$ umount /tmp/tst
$ mount -t iso9660 -o loop ../7.0-RELEASE-i386-disc3.iso /tmp/tst
$ tar -C /tmp/tst -cf - . |tar -xf - 
$ umount /tmp/tst
$ mount -t iso9660 -o loop ../7.0-RELEASE-i386-disc2.iso /tmp/tst
$ tar -C /tmp/tst -cf - . |tar -xf - 
$ umount /tmp/tst
$ mount -t iso9660 -o loop ../7.0-RELEASE-i386-disc1.iso /tmp/tst
$ tar -C /tmp/tst -cf - . |tar -xf - 
$ umount /tmp/tst

Ако сте предпочели друга подредба при mount-ване на дисковете, уверете се, че вторият ред във файла cdrom.inf е set-нат на 1:

$ cat cdrom.inf 
CD_VERSION = 7.0-RELEASE
CD_VOLUME = 1

След това, отново като root, изпълнете следните команди:

$ cd packages
$ cat INDEX | sed "s/||2/||1/g" > ix
$ cat ix | sed "s/||3/||1/g" > ix2
$ mv ix2 INDEX 
$ rm ix
$ cd ../..
$ rm -r fbsd7/rr_moved

Сега вече имате цялата директорийна структура, необходима за записването на DVD-то. Можете да го запишете на диск със следната команда (заменете устройството с това на Вашата система и сменете скоростта за записване, ако устойството Ви е по-бавно, или диска изисква по-малка скорост) :

$ growisofs -Z /dev/cd0 -speed 16 -J -R \
-no-emul-boot -b boot/cdboot -iso-level 3 fbsd7

След като тествате DVD-то, можете спокойно да изтриете както свалените ISO-та, така и директорията fbsd7, тъй като няма да са Ви необходими повече.

Както обикновено повечето промени са “под повърхността”. Няма лъскави скрийншоти, няма я и типичната за други дистрибуции пропаганда в мрежата…. Всичко е като при всеки предишен release. И този път в инсталационните дискове ще намерите най-новите версии на KDE, XFCE, ядрото и развойните инструменти. И, както е било досега, нито едно от приложенията не е patch-вано или модифицирано по какъвто и било начин. Slackware Linux е известен именно с това – ядрото е във версията от kernel.org, а desktop-а не предлага дори буквичка брендиране

Всъщност, единственото място, на което разработчиците на Slackware са модифицирали някакъв пакет е boot-екрана на LInux LOader (LILO), а ето и каква е причината:

Added a simple splash screen (the default one had too many colors and was making my eyes hurt . Thanks to the unknown Slacker who submitted the idea ages ago when we were dead-set against “branding”.

Инсталационната процедура отново изисква малко команден ред, но, ако следвате текстовите инструкции от инсталационния диск, моята препоръка е за разделяне на харддиска да използвате по-удобния инструмент cfdisk, вместо fdisk. Другата ми препоръка е задължтелно след инсталация на системата да отделите време за прочитането на файла CHANGES_AND_HINTS.txt, намиращ се в основната директория на инсталационния диск. Оттам можете да научите за включването (най-накрая) на HAL (Hardware Abstraction Layer) в дистрибуцията, как да го накарате да работи с KDE, за някои аргументи относно избора на ядро, както и разни дребни подсказки свързани с организацията на системата.

Макар повече от година да съм с Debian, 4-годишния период със Slackware всъщност ме научи на доста от тънкостите в работата с Linux. В резултат на това съм абсолютно съгласен с твърдението “once a slacker – forever a slacker”. Още повече, Slackware в момента се води най-старата оцеляваща Linux-дистрибуция и аз определено не съм единствения, оценил качествата й.

Та честито на всички фенове, аз чакам удобен момент да почовъркам повече DVD-то…

11-тата версия на Real Player за Linux беше анонсирана преди повече от година, но стана факт едва в началото на миналата седмица. С тези темпове разработчиците могат да са абсолютно спокойни – вече са изтървали влака. MPlayer отдавна предлага Real Media support, а и плъгина му за Firefox е по-стабилен. Вероятно за да компенсират изоставането, хората от Real не само не са се постарали да добавят нещо интересно, но и типично по Windows-маниер са опитали да повлияят на environment-a дотолкова, че да досадят на потребителите повече от прилично…

Колко пъти ви се е случвало в Windows да инсталирате някакъв софтуер и да установите, че файловите асоциации и иконите за определен тип файлове са променени в резултат на инсталацията? Редовен номер е Update на Media Player да смени асоциацията на всякакви медийни формати без да се интересува, че искате да слушате MP3-ките си с WinAmp, примерно. Е, Real Player за Linux, в новата си версия, “страда” от същата “болест”…

Може да видите “симптомите” веднага след инсталация под GNOME или, ако като мен ползвате KDE, при стартиране на Nautilus или Save-диалога на Firefox. Лошото при GNOME е, че асоциациите обикновено са базирани на единица и, макар да имате възможност да промените иконата на произволен файл, няма удобна графична възможност за промяна на иконите на група файлове, в зависимост от техния тип.

За щастие, Linux инсталацията на Real Player е базирана на скриптове и възстановяването на “оригиналните” асоциации и икони не е кой знае колко сложно. В директорията, където сте инсталирали програмата (при мен /usr/local/RealPlayer) има поддиректория, наречена postinst, a в нея освен инсталационни, има и деинсталационни скриптове.

За да възстановите файловите си асоциации, просто се log-нете като root и изпълнете следното:

./uninstall_icon_resource.sh
./unregister_mime_types.sh

Това не премахва RealPlayer, а само досадните икони и файловите асоциации, така, че MP3-ките Ви ще продължат да се отварят с предпочитаното от Вас преди инсталирането му приложение.

Така и не разбрах едно нещо, обаче – така или иначе версията е забавена с година, толкова ли е било трудно да сложат два checkbox-a в инсталационните панели с опции “Associate Real Player with supported media types” и “Install Real Player media icons”, примерно? Мистерия…

С появата на Flex 3, потребителите на GNU/Linux се докоснаха до света на RIA, поне според начина по който виждат нещата хората от Adobe. Една досадна подробност беше отсъствието на AIR (Adobe Integrated Runtime), което ограничаваше Flex-потребителите само до web-базирани разработки. Макар и alpha версия, AIR вече е наличен от сайта labs.adobe.com и за Linux, след като преди месец дебютира на платформите Windows и Mac OS.

Въпреки, че е все още alpha стадий, runtime-а предлага доста добри възможности, лесна инсталация и солидна документация, а липсващата функционалност ще бъде добавена в следващите няколко месеца. Приложения, написани за AIR вече се намират на много места из мрежата, а възможността освен Flex за създаване на приложения да се използва и HTML/JavaScript дава на framework-a отлична гъвкавост.

Изглежда, битката с Microsoft е накарала мениджмънта на Adobe да вземе някои доста интересни решения. Редом с обявяването на alpha-та, от press release-а на фирмата обявиха присъединяване към Linux Foundation, а като капак на всичко части от продукта LifeCycle бяха пуснати като Open Source под името BlazeDS. Междувременно Flex Builder за Linux стигна до версия Alpha 3, осигурявайки поддръжка на AIR, a според главния софтуерен архитект на Cold Fusion, продукта ще последва съдбата на Flex, отваряйки кода си.

Хубаво нещо е конкуренцията, особено когато от цялата работа печеливш се оказва крайният потребител

Понеже така или иначе не ползвах 0.2.2 най-вече заради проблеми с производителността, първото нещо което ми направи сериозно впечатление е количеството труд, вложено в тази посока. Новият compiz е доста “по-пъргав” и дори досадният проблем с видеокартите на nvidia, при който след превключване във виртуален терминал и връщане към X-сесия машината увисва, вече има решение. За да нямате проблеми от този род, единственото необходимо е през gconf-editor да премахнете checkmark-а в опцията:

/apps/compiz/general/screen0/options/detect_refresh_rate

Един леко дразнещ пропуск от страна на maintainer-a на пакета е свързан с невъзможността да се избере window decorator измежду gtk-window-decorator (наличен по подразбиране), kde-window-decorator и compiz-decorator. Понеже работя с KDE, опцията gnome-window-decorator не ме устройва кой-знае колко, а и kwin има доста полезни настройки за размерите и позиционирането на прозорците при стартиране на приложения. Поради тази причина ми се наложи да създам patch, който редактира файла /usr/bin/compiz, указвайки използване на kde-window-decorator вместо този по подразбиране. Всъщност по-чистото решение е да има 3 различни файла за всеки от decorator-ите, със съдържание, подобно на сегашният compiz (промерно compiz.kde, compiz.gtk и compiz.native), които да се сменят чрез update-alternatives, а самият пакет да поддържа кофигуриране на decorator-ите по време на инсталация, но подобно решение изглежда не е на дневен ред за хората, поддържащи текущите deb пакети. Предполагам по времето, когато testing стане със статус freeze подобни неща ще намерят място при финалните фиксове преди официалния release.

Download compiz.patch (0,5 KB)

Ако като мен използвате KDE, изпълнете горния patch като root в директория /usr/bin (разбира се преди това трябва да сте инсталирали compiz-kde от някое от repository-тата):

# cd /usr/bin
# patch -p0 < /path/to/compiz.patch

Когато обаче стартирате compiz ще останете неприятно изненадани от поведението на pager-а в KDE. Нямам си идея чия умна глава е решила, че всеки Desktop трябва да има по 4 workspaces, обаче 16 бутона за вируални дектопи ми идват в повече. На всичко отгоре изглежда pager-a, компилиран с текущата версия на KDE не е съвместим с compiz, и ако не искате да имате проблеми с поведението му, можете да инсталирате следния пакет:

Download kicker-compiz_3.5.4-1_i386.deb (70,3 KB)

В него ще намерите patch-нат Pager аплет с име “Desktop Preview & Pager – Compiz”, който НЕ ЗАМЕНЯ оригиналните файлове на pager-a от KDE и може да се използва като негов заместител при работа в compiz-среда. Ако решите да го използвате ще трябва да укажете в настройките му да използва само един Desktop, като и през gconf-editor ще се наложи да сетнете на “1″ (без кавички) опцията:

/apps/metacity/general/num_workspaces

С настройките по-горе KDE се държи прилично, използва OpenGL ефектите на compiz при доста добра производителност дори с вехта видеокарта от вида на GeForce4 MX 440, но заради проблемите с Pager така и не успява да ме убеди, че си заслужава пускането им заедно в реална среда, поне на този етап.

В сравнение с комерсиалните операционни системи, процесът на стартиране при Linux изглежда като излязъл от каменната ера – макар и атрактивни и полезни, съобщенията в конзолата рядко говорят нещо на обикновения потребител. Bootsplash изглежда скоро ще отиде в небитието, тъй като вече има достоен наследник – Splashy.

Рожба на проекта Debian, Splashy представлява user-space приложение, което не изисква patch-ване на ядрото, и може да работи с initramfs, правейки процеса на стартиране доста по-приятен за окото. Като недостатък (заради все още ранния стадий на разработка) мога да посоча работата му във verbose-режим, както и някои недоразуемния в управлението на шрифтовете, но съм сигурен, че с набирането на повече потребителска маса ще има видими подобрения в тази насока. Можете да погледнете ръководството за инсталиране за подробно описание на процеса.

Макар, че сайтове от сорта на kde-look.org и gnome-look.org вече предлагат теми за splashy, аз лично така и не успях да си харесам нещо, което да отразява виждането ми за boot екран на личният ми компютър. За сметка на това splashy е отлично документиран, предлага инструмент за направа на теми, както и такъв за тестване, без да се налага да рестартирате машината си, и всеки който не харесва темите по подразбиране може да си направи собствена.

Моят вариант за стартиращ екран можете да видите на картинката по-горе, а самата тема може да свалите оттук:

Download swirlonblack.tar.gz (Compressed gzip archive, 280 KB)

За да я инсталирате изпълнете следното като root:

cd /etc/splashy/themes
tar xzvf /path/to/downloaded/swirlonblack.tar.gz
splashy_config -s swirlonblack

# modprobe lirc_gpio
FATAL: Error inserting lirc_gpio
(/lib/modules/2.6.22/misc/lirc_gpio.ko):
Unknown symbol in module, or unknown parameter (see dmesg)

Причината за невъзможността на lirc_gpio дори да зареди е в някои премахнати символи в bttv секцията на ядрото (виж тук за повече информация). Работата е там, че въпросните символи не са премахнати от раз – поне 6-7 версии назад зареждането на lirc_gpio беше придружено от краткия, но ясен текст:

The bttv_* interface is obsolete and will go away, please use the
new, sysfs based interface instead.

Разбира се, първата работа, след като вече имах работещо ядро 2.6.22, беше да пратя съобщение до mailing list-а на LIRC за проблема. Изглежда нещата са по-сериозни, или точно този драйвер в момента няма разработчик, защото вече почти месец няма fix на въпросния проблем.

Ако някога сте ползвали дистанционно за управление на музикалния си плейър, или при гледане на филми с компютър, със сигурност ще оцените липсата му в първия момент, в който то не работи. Понеже ми писна от дребните проблемчета при lirc_gpio, започнах да преглеждам варианти за използване на дистанционното без да ми се налага да прибягвам до услугите на въпросния драйвер.

Оказа се, че някои от картите в bttv регистрират собствен event device, който всъщност представлява интерфейс към дистанционното управление на тунер-а. Наличието или липсата на event device зависи от опцията card при зареждане на драйвера (за някои от картите е известно адресирането на infrared приемника, за други липсва). При мен досега card беше установена на 13 и, както можете да предположите, event device нямаше. Преглеждайки списъка с поддържани карти (файлът CARDLIST.bttv в директория Documentation/video4linux от изходния код на ядрото), установих, че варианти за моят модел са опциите 6 и 41. Пробата с 41 не даде резултат, но с 6 нещата започнаха да си идват на мястото. Във файла /etc/modprobe.d/bttv сложих следните опции:

alias char-major-81     videodev
alias char-major-81-0   bttv
options bttv            card=6 radio=1 pll=1 tuner=5

С тях, при зареждането си, драйвера започна да създава и необходимият event device:

$ cat /proc/bus/input/devices
...
I: Bus=0001 Vendor=109e Product=036e Version=0001
N: Name="bttv IR (card=6)"
P: Phys=pci-0000:00:0a.0/ir0
S: Sysfs=/class/input/input2
U: Uniq=
H: Handlers=kbd event2
B: EV=100003
B: KEY=40fc310 82140000 0 0 0 0 2048000 180 4001 9e0000 0 0 ff

След като имах готовия интерфейс, оставаше да накарам LIRC да работи с него. Небходима ми беше малко информация от списъка с input-устройствата по-горе. Тя се намира на реда, започващ с H: и показва името на устройството, създадено в /dev/input. В моят случай устройството е event2 и за да създам lircd.conf за него, изпълних следното:

# irrecord -H dev/input -d /dev/input/event2 lircd.conf

Следвайки инструкциите създадох файла и го копирах в /etc/lirc, замествайки старият lircd.conf. Последната стъпка беше да редактирам файла hardware.conf в същата директория. Ето как изглеждаше той след промените:

# /etc/lirc/hardware.conf
#
# Arguments which will be used when launching lircd
LIRCD_ARGS=""

#Don't start lircmd even if there seems to be a good config file
#START_LIRCMD=false

#Try to load appropriate kernel modules
LOAD_MODULES=false

# Run "lircd --driver=help" for a list of supported drivers.
DRIVER="dev/input"
# If DEVICE is set to /dev/lirc and devfs is in use /dev/lirc/0
# will be automatically used instead
DEVICE="/dev/input/by-path/pci-0000:00:0a.0--event-ir"
MODULES=""

# Default configuration files for your hardware if any
LIRCD_CONF=""
LIRCMD_CONF=""

Обърнете внимание на реда, който започва с DEVICE=. Първоначално там седеше DEVICE="/dev/input/event2", но това доведе до объркване с event device на мишката. За да не ми се налага да пипам udev-правила използвах автоматично създаваният symlink към всеки event device в директория /dev/input/by-path. Ако не сте сигурни кое от устройствата в тази директория е дистанционното, или имате повече от един TV tuner – погледнете реда, започващ с P: при изпълнението на командата:

cat /proc/bus/input/devices
...
P: Phys=pci-0000:00:0a.0/ir0
...

При мен, както виждате, дистанционно се регистрира като pci-0000:00:0a.0/ir0, и в /dev/input/by_path имам кореспондиращ symlink към /dev/input/event2 с име pci-0000:00:0a.0--event-ir. След като нанесете промените, запишете hardware.conf и рестартирайте LIRC:

/etc/init.d/lirc restart

При мен това доведе до успех – LIRC захапа дистанционното и без никакви грижи започна да реагира на сигналите от него без необходимост да ползвам проблемния драйвер lirc_gpio, от което съм повече от доволен.

Update (04.04.2008): Версия 0.8.2 на lirc за Debian идва с преработен init script, който проверява за наличие на модулите, указани в реда MODULES= на файла /etc/lirc/hardware.conf. Поддръжката на /dev/input устройства не изисква наличието на никакви модули от lirc пакета, затова реда изглежда така:

MODULES=""

Преди време попаднах на статия, в която се споменаваха някои от по-рядко използваните опции от функционалността на програмата. Една от тях е оцветяване на резултатите, подобно на начина по който някои от търсачките оцветяват ключовите думи, по които извършвате търсенето си. Ето как изглежда резултатът от работата на grep при използване на оцветяване:

За да накарате grep да оцветява резултатите е достатъчно да добавите следните два реда във файла ~/.bashrc (разбира се, ако ползвате друг shell ще трябва да добавите опциите във файла, от който конфигурирате поведението му):

export GREP_OPTIONS='--color=always'
export GREP_COLOR=32

Стойността на GREP_COLOR е цифра между 30 и 37 и означава, както следва:

30	black
31	red
32	green
33	yellow
34	blue
35	purple
36	cyan
37	white

Не вярвам да има някой, който да се усъмни в полезността на оцветяването на срещанията – на мен поне със сигурност ми помагат да се ориентирам в пъти по-бързо сред върнатите резултати. Bonus feature е опцията --line-buffered която буферира всеки ред, правейки търсенията в дълги текстови файлове значително по-бързи.

Update: Преди малко установих, че set-ването на GREP_OPTIONS като root причинява проблем при компилиране на ядрото – при изпълнение на make modules процесът спира веднага след навлизане във втория стадий на компилацията, издавайки следното съобщение:

Building modules, stage 2.
MODPOST 0 modules

Изглежда make-файловете на ядрото ползват променливата GREP_OPTIONS по някакъв по-специфичен начин и решението е да избегнете директното й set-ване, като за целта е достатъчно във файла ~/.bashrc, да замените реда

export GREP_OPTIONS='--color=always'

с този:

alias grep='grep --color=always'

Реших да тествам и двата варианта като proxy-та пред mongrel cluster-а, seeing is believing ‘дето викат хората. За целта използвах собствената си Debian-базирана машина. Вярно, цифрите в Benchmark-a не са за завиждане, но и хардуера не е първа младост.

За конфигуриране на Mongrel cluster, вижте страхотната статия на Coda Hale. За коректна Debian-базирана инсталация на Rails – вижте първата част от тази статия

Макар че в Debian има пакет за Nginx, в този за версия 0.5.26 има проблем – процесът по деинсталиране спира с досадна грешка, налагайки ви да редактирате init script-a за да можете да изчистите пакета в случай че не Ви е необходим повече. Поради тази причина изтеглих source на Nginx (версия 5.0.30 към момента на написване на статията) и компилирах собствен .deb пакет, ползвайки конфигурационните опции на официалния maintainer.

Download nginx_0.5.30-1_i386.deb (232 KB)

За да инсталирате пакета, първо спрете процеса на Apache, ако имате пуснат такъв:

/etc/init.d/apache2 stop

След това изпълнете следното:

dpkg -i nginx_0.5.30-1_i386.deb

В слуай, че искате да премахнете Nginx, след като вече е инсталиран:

dpkg --purge nginx

От конфигурационните файлове, които използвах за benchmark-a, съм направил полуготови темплейти. Заместете навсякъде във файловете projectname с името на вашия сървър, а yourproject с името на проекта. И двете решения разчитат, че приложението Ви е разположено (изпълнен е cap deploy) в директория /var/www/apps/:

Apache virtual host config template (rails_project_apache.conf – 2.1 KB)
Nginx virtual host config template (rails_project_nginx.conf – 0.9 KB)
Nginx daemon config example (nginx.conf – 0.5 KB)

За да конфигурирате виртуалните хостове следвайте стандартната процедура – копирайте файловете rails_project_apache и rails_project_nginx съответно в /etc/apache2/sites-available и /etc/nginx/sites-available. Сменетe имената им с нещо, което има значение за Вас, редактирайте ги, така че да отразят местоположението на проекта и добавете символни връзки към тях в съответните sites-enabled директории.

Понеже машинката ми е слаба, използвах симулация на 100 паралелни заявки, повтарящи се само 1000 пъти. Командата с която стартирах bechmark-а е следната:

ab -c 100 -n 1000 http://projectname/

Повече детайли можете да намерите в следните файлове (в конфигурацията на Apache съм забранил показването на server credentials, което е и причината да виждате Mongrel като име на сървъра):

Apache benchmark results (apache2.txt – 1.3 KB)
Nginx benchmark results (nginx.txt – 1.3 KB)

Изглежда на еднопроцесорна машина Apache 2.2 има леко предимство, и разработчиците с право могат да се гордеят с резултатите. От друга страна nginx изглежда интересен, но имам чувството, че с добавянето на повече функционалност сървърът няма да остане толкова лек и бърз.

Все пак няма да е зле да има вариант за benchmark върху дву- или четирипроцесорна машина за да проверя скалируемостта на двете решения – Apache има навика да fork-ва процеси и да пълни сериозно паметта, докато nginx е доста по-непретенциозен. Ако някой има по-яка машинка под ръка и му се занимава с ръчкане ще съм доволен да сподели своите резултати…

Update: Debian testing вече съдържа пакет с версия 0.5.30 на nginx, който обаче страда от същият проблем като по-старата версия – prerm скрипта извиква два пъти спиране на демона на nginx, проваляйки по този начин премахването му. Поради тази причина можете да използвате или по-горната версия, с която са направени тестовете, или пакета с по-актуална версия от тук:

Download nginx_0.5.31-1_i386.deb (232 KB)