В допълнение към темата за добрите практики при работата със свободен софтуер. В частност — разработката на уеб-услуги. Често ви се е случвало интересът към даден сайт да ви бъде спрян от задължителна форма за регистрация, въвеждане на пароли и т.н. Много хора приемат всичко това за нормална даденост, но все пак поне веднъж сте се питали "защо ми искат изобщо регистрация тук", нали?

Разработката на уеб-страници има много особености, някои от тях строго специфични, много на брой и многообразни. Но има някои общи правила, които е важно винаги да се спазват. Това са общовалидните препоръки за проектиране, писане и поддръжка на качествен сайт. Разбира се, сайтове могат да се правят и с пренебрегване на такива препоръки и в мрежата има огромен брой примери за това. Но ако полагате грижа за даден сайт, бил той личен блог, галерия или портфолио, бил служебен представителен сайт на фирмата или пък бил еднократна поръчка към външен за собственика специалист, част от правилните, добри грижи за сайта включват и съобразяване с тези общи правила. Ще опитаме да разгледаме поне част от тези "препоръки за добрата практика" при правене на сайтове.

Имаме ли нужда от пароли?

Въпросът звучи реторичен и като че ли подразбиращият се отговор е утвърдителен. Но нека помислим пак — имаме ли наистина нужда да искаме от потребителите си да ни дават парола за достъп до сайта? Този въпрос е може би основният за решаване при работата с пароли в разработката на страници. Може да го разделим на две части — "За какво са ни пароли?" и "Как ще ги съхраняваме?". И двата въпроса могат да имат различни отговори, които изобщо не са "предопределени" от някаква уеб-тенденция за искане или неискане на пароли. Трябва да отговорим за конкретния сайт, по който работим и на двата въпроса, да намерим правилното им решение.

Водещо правило при обмислянето на тези два въпроса е "колкото по-малко, толкова по-добре". Това означава, че подробното и излишно утежнено занимание с пароли изобщо няма да помага на сайта ни. А напротив — ще пречи, като затруднява писането, изпробването и поддръжката му. Пароли трябва да се ползват само и единствено ако са наистина нужни.

За какво са ни пароли?

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

Във всеки случай е важно да се прецени дали тези "ценни" действия на потребителите задължително трябва да се придружават с регистрация и влизане с парола. Ако регистрациите и паролите са ни излишни, най-добре е директно да ги пропуснем изцяло. Един добър сайт има достатъчно много други неща, върху които можем да се съсредоточим.

Ако все пак наистина е нужно потребителите да се идентифицират пред сайта, трябва да продължим да си задаваме въпроса "за какво са ни пароли". Защото в Интернет има поне дузина разпространени начина за автентикация и този с локална за сайта комбинация от идентификатор и парола е само един от тях. Вярно, най-разпространеният може би. Но и най-трудният за поддръжка и най-уязвимият. Паролите се крадат, базите от данни се повреждат и такива инциденти определено не са в полза на потребителите. Или на поддържащите услугата.

В случай, че идентификацията е наложителна, непременно трябва да се обмисли използването на механизми, независещи пряко от сайта. Най-добре е, ако тези механизми зависят и принадлежат на самия потребител. Такъв механизъм за идентификация е OpenID. При него потребителят има пълен контрол върху сайтовете, на които се "доверява" и на идентифициращите машини, които OpenID-адресът му ползва. OpenID е много удобна възможност както за администраторите и разработчиците, така и за отделните потребители. Сваля от плещите на администраторите постоянната грижа с базата от данни с пароли и позволява на потребителите във всеки момент да прекратят акаунта си, като просто "изключат" доверяването към дадения сайт. или пък да променят идентифициращия сървър, като в специален таг в страницата си пренасочат идентификацията към друг нов сървър.

Трябва да се има предвид, че OpenID не е система за автентикация или оторизация, а само за идентификация. Затова е идеален за ползване в сайтове, където е важно да се знае кой е даденият потребител. Но за работа с финанси, лични данни, пароли и друга чувствителна информация вече трябва да се използва система, която да гарантира на нас, а не на външен ни OpenID-сървър кой точно е този потребител. Повечето готови системи за изработка на сайтове имат приставки за включване на влизане в акаунтите през OpenID.

Освен OpenID има и други системи за идентификация, като MicroID или Live ID на Майкрософт (известно преди като .NET Passport). Важно при избора на такава система е и дали е централизирана или разпределена. OpenID например е разпределена система, докато Live ID е централизирана и изцяло под контрола на Майкрософт. OpenID е с публикувана спецификация, докато Live ID е "walled garden", затворена система на фирмата Майкрософт. MicroID пък е начин да се идентифицира дадена публикация в мрежата. Тоест тя не сработва като начин за "влизане" на потребителя в сайта, но веднъж идентифициран по друг начин (с OpenID или пък с парола), неговото съдържание в сайта може да бъде направено автоматично разпознаваемо с добавяне на MicroID-тагове.

Как ще съхраняваме паролите?

Става дума не толкова за хардуерното обезпечаване и дублиране на сървърните системи, а за чисто софтуерната концепция на съхранението. Накратко, паролите никога не трябва да са в явен вид. Може да звучи "изкушаващо" за бъдещия собственик на сайт да знае, че може във всеки един момент да провери паролата на даден човек и да направи нещо нередно — например да влезе като него, да му смени данните, да му открадне акаунта и др. под. Но това е несериозно и опасно. Не само че е неетично, а и при доказана зла умисъл потребителят ще е в правото си да съди такъв собственик на сайт.

В случай, че пароли в явен вид се откраднат от сървъра, дори и веднага да реагират администраторите и да започнат да предупреждават потребителите (например по е-пощата) в най-скоро време да влязат и да си сменят паролите, защото е имало компрометиране на сайта, пак тези, в които е базата с явни пароли ще могат много по-бързо да влязат във всеки един акаунт, да сменят паролата с тяхна си нова и така да "превземат" всички (или поне огромна част) акаунти на сайта. Ако паролите са шифрирани, времето за разбиване на шифъра ще е достатъчно да се реагира правилно и даже потребителите да имат възможност да си сменят паролите и да си запазят акаунтите.

Паролите трябва да са шифрирани или поне криптирани по някакъв отнемащ време за разкриване начин. "Криптиране" е общият термин, с който се обозначава всякакъв вис "скриване" на информация с видимото й преобразуване. Ако преобразуването пък я прави "невидима", тогава процесът се нарича "стеганографиране". "Шифриране" пък е такъв вид криптиране, при който данните се преобразуват според някаква формула, шифър, ключ. Има различни видове шифриране, според това дали са еднопосочни или двупосочни, дали се ползва двойка ключове (т.нар. "ключ и ключалка") или пък според това какво ниво на сложност използват.

Във всеки случай паролите, независимо дали се пазят във файл, бил той и защитен по някакъв начин, например извън уеб-папките, или пък се пазят в SQL база от данни, трябва задължително да се замаскират — най-добре с шифриране. Това не е труден процес, всеки съвременен език за програмиране на уеб-страници позволява съвсем лесно да се работи с шифрирани пароли. Някои системи за сайтове (CMS, Wiki, blog и т.н.) поддържат вътрешно автоматично шифриране на паролите. Даже всички разпространени и развити готови системи (Wordpress, Drupal, Mediawiki, Joomla, Mambo, PhpBB и безброй още други) идват с интегрирано шифриране на всички пароли.

Тази тема е малко встрани от новините за свободен софтуер. Но понеже много хора използват свободен софтуер за страниците си в Интернет, много често без самите да знаят за възможностите, които им дава това и за многото начини, по които могат да експлоатират услугата на хостингите, ползващи свободен софтуер, нека поговорим за уеб-пренасочванията.

Всяка заявка до уеб-сървъра Apache получава някакъв отговор. Той в повечето случаи е невидим за потребителя на сайта, защото е задействан, но не е предвиден за показване или защото е предвидено от програмистите и администраторите да се показва, но не е бил задействан. В първия случай става дума за кодове за "нормално състояние". Например отговор, че обектът се доставя или отговор, че обектът е преместен и може да се намери на еди-кой си адрес. Във втория случай става дума за кодове и придружаващите ги обяснителни съобщения, които означават някаква грешка. Била тя в сървъра, задействана от самия сървър, средата му или уеб-приложението или била от страна на клиента, в браузъра му.

Кодовете за състоянието на заявките се изписват в лог-файловете на сървъра, най-често в шестото поле на всеки ред. Полетата са разделени с интервал и някои от тях (например тези, които могат да съдържат разделителя, интервал в себе си) са оградени в кавички. Въпросното шесто поле съдържа трицифрено число, което е кодът за състоянието на заявката, върнат от сървъра. Тези кодове са доста и различни, но най-често срещаните и най-използваните при разработката на сайтове и проверката за грешки са сравнително малко на брой.

Тези от тях, които се отнасят до пренасочванията, започват с цифрата 3. Добре е всеки с интереси и занимания в областта на уебсайтовете, правенето, администрирането и поддържането им, или казано накратко всеки имащ нещо общо с HTTP да ги познава. Много често бързото поставяне на пренасочване е важно за оптимизацията на сайта за търсачки и за "задържане" на потребители при преместване, например.

Когато се настройва сървърът да връща код 3хх (някое от пренасочванията), задължително е и да се посочи като допълнителен аргумент адресът на пренасочването. Тоест къде да отиде клиентът, след като сървърът му е казал "има пренасочване". Адресът се изписва като стандартен URI-запис, тоест включва протокол, сървър, евентуално порт и евентуално път — http://example.com:8080/newsite например.

Видове пренасочване

постоянно (permanent) — връща се код за състояние "301" и това означава, че съдържанието е постоянно преместено на указания нов адрес. Предполага се, че настолните приложения и индексиращите машини на търсачките автоматично при посещение на адреса с постоянното пренасочване ще променят данните си. Например Google ще знае за новия адрес и вече ще показва предимно него и браузърите при посещаване на такъв сайт сами ще си променят записа в отметките си. Все пак трябва да се има предвид, че такава "миграция" за търсачката на Google отнема от месец до два или три. Чак след това се възвръща и PageRank-а, който при такова преместване в началото се нулира за новия адрес.

временно (temp) — връща се код за състояние "302", което означава, че временно съдържанието е на новия адрес. Ако е използвана директивата Redirect в настройката на сървъра (или съответно в .htaccess), но не е указан изрично кой код да се върне, това е подразбиращият се код.

замяна (seeother) — връща се код за състоянието "303", показващ че съдържанието е било заменено и всичко, което е било на предишния адрес, сега е смислово заменено от съдържанието на новия адрес. Това не е точно пренасочване и в днешното време на използване на аргумента "rel" към препратките за изразяване на смислово отношение се ползва много рядко.

премахнато (gone) — връща се код за състоянието "410". Това не е пренасочване в истинския смисъл, защото практически на клиента се връща код за грешка (каквито са тези, започващи с "4"). Понеже клиентът не се пренасочва наникъде след посещението, затова и не е нужно да се указва нов адрес. Споменаваме "410" при пренасочванията за пълнота на всички случаи на разместване на съдържание.

Това са най-разпространените. Иначе има и "300" (multiple choices — сървърът дава списък с адреси и браузърът трябва да избере къде да отиде), "304" (not modified — указва, че обектът не се е променил и съответно браузърът може да реши да полза локално кешираното копие), "305" (use proxy — указва, че търсеният обект трябва да бъде достъпен през посредник, чийто адрес дава също в отговора), "307" (temporary redirect — вариация на "302", който прави практически същото).

Начин за настройка

Начините за указване на пренасочване са, общо взето, три — през сървъра, през програмния език или през крайния HTML-код.

Настройката през сървъра може да бъде направена или във файла за настройки или, ако нямате достъп до него (например ползвате виртуален хост на споделен хостинг) през файла .htaccess в съответната директория. Синтаксисът е следният:

за постоянно пренасочване
Redirect 301 /old-path.html  http://example.com/newpath.html
или
Redirect permanent /old-path.html  http://example.com/newpath.html
или
RedirectPermanent /old-path.html  http://example.com/newpath.html

за временно пренасочване
Redirect 302 /old-path.html  http://example.com/newpath.html
или
Redirect temp /old-path.html  http://example.com/newpath.html
или
RedirectTemp /old-path.html  http://example.com/newpath.html

Има и по-сложни комбинации с условното RedirectMatch, което приема като първи аргумент регулярен израз, с който можете да пренасочите наведнъж цяла група приличащи си адреси в сайта ви.

Пренасочването през програмния език представлява извикване на функцията в езика, която изпраща HTTP-заглавка към клиента, съдържаща код за пренасочване. Например ето как става за PHP:

за постоянно пренасочване
header("HTTP/1.1 301 Moved Permanently");
header("Location: http://example.com/newpath.html");

за временно пренасочване
header("HTTP/1.1 302 Moved Temporarily");
header("Location: http://example.com/newpath.html");

и т.н. Важно е тези редове да се сложат най-отгоре, в началото веднага след "<php", защото заглавки трябва да се изпращат винаги преди съдържанието. И ако страницата ви даде някакво съдържание и чак след това заглавка, получава се грешка и търсеното пренасочване не става. Отново, ако не се спомене изрично кой е кодът, по подразбиране сървърът ще изпрати "302", временно пренасочване. Настройката за временно пренасочване е полезна, когато съдържанието наистина е на друго място само временно. Това подсказва индексиращите машини да продължават да следят стария адрес, но временно да насочват а съдържанието към новия. Ако обаче местите наистина за постоянно адреса, грешка е да се ползва 302 (което е по подразбиране) вместо правилното 301.

Пример с Perl през CGI:
#!/usr/bin/perl
print "Status: 301 Moved Permanently\nLocation: http://example.com/newpath.html\n\n";

или:
#!/usr/bin/perl
print "Status: 302 Moved Temporarily\nLocation: http://example.com/newpath.html\n\n";

При другите езици, когато се използват през CGI, нещата са подобни. Ако се използва някакъв фреймъурк, като Django или Rails, най-често има готови класове за пренасочване или за връщане на кратък отговор, в който изписваме като текст съобщението за пренасочване. Винаги важното е, че такива отговори трябва да се връщат към уеб-клиента преди всякакво друго съдържание. Общо взето, при пренасочванията всяко следващо съдържание не е важно и се пренебрегва, защото при правилно задаване на пренасочването клиентът вече се е обърнал към другия ресурс и слуша там.

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

<meta http-equiv="refresh" content="0; url=http://example.com/newpage.html" />

Стойността на "content" е времето на изчакване преди пренасочването в секунди. 0 означава прехвърляне веднага на новия адрес. HTML-пренасочването е удобно за малки сайтове или отделни страници. За по-мащабни проекти най-добре използвайте описаните по-горе други начини.

Сигурно сте чували за Марк Шатълуърт? Ако не сте, то няма начин да не знаете поне за Убунту. Марк е човекът зад проекта "Ubuntu" с всичките му под-проекти и поддържащите го фондации. Убунту е дистрибуция на GNU/Linux, базирана на дистрибуцията на Debian. Има ясно изказани причини да се направи отделен проект, вместо да се работи за подобряване на софтуера "отвътре", в Дебиан. През малкото изминали години на бурния растеж на Убунту имаше и много проблеми между новия проект и Дебиан, както принципни между двете общности и методите им, така и лични между разработчици от двата лагера. И все пак днес връзката между двете дистрибуции е много по-силна, отколкото между които и да са други проекти за операционни системи. Както самият Марк казва, всички разработчици на Дебиан са на практика и разработчици на Убунту, макар и неформални. За което той им е безкрайно благодарен.

Освен с Убунту, Шатълуърт е известен и с много други неща. Той е първият, роден след стъпването на Луната, който е летял в космоса. Един от малкото частни космически туристи и единственият от Африка. Да, той е от ЮАР и се казва, че е милиардер, който сам си е изкарал парите. Всичко това -- за един човек, при това толкова млад и то не американец и неработил за някой от мастодонтите в Силициевата долина? Да, явно е възможно. Но кой всъщност е Марк Шатълуърт, как е натрупал такова имане и дали само работата по GNU/Linux му е донесла парите? И с какво се занимава сега, как ги харчи, освен за разходки с ракети?

Роден през 1973г., Mark Shuttleworth е родом от Южна Африка и понастоящем е с двойно гражданство, добавил си е британско и живее в Лондон. Първият африканец в космоса и вторият космонавт в историята, който сам си е платил пътуването. Образованието, което получава е по финанси и информационни системи от университета в Кейптаун.

Първият бизнес, с който се захваща, е основаването на компанията Thawte през 1995г. Това е фирма издател на електронни сертификати, ползвани най-вече в уеб. Името й се произнася "thought" (англ. "мисъл", "мислене") и е вторият по големина издател на сертификати (CA, Certificate Authority). Първоначално всичко е започнало в гаража на родителите на Марк. В началото проектът е бил да се разработи сигурен уеб-сървър, който да не попада под ограниченията на САЩ за "износ на шифриране". САЩ много дълго имат силни ограничения върху високото криптиране и всякакви програми и продукти, които включват шифриране или друг вид криптиране са строго забранени за разработка в страната и за износ. Понеже Интернет е разпределена мрежа, в която всяко нещо подлежи на такъв "износ", проблемът дълги години е един от основните в света на защитения софтуер и услуги. Сървърът, който Марк разработва, нарича Sioux. Това е променен сървър Apache, оттам и заигравката в името на друг северноамерикански индиански народ.

По-късно сървърът Сиукс е интегриран в сървъра Stronghold, също включващ HTTPS-поддръжка към Apache, разработван от RedHat. Това става, когато Thawte се ориентира по-сериозно към бизнеса със сертификати и поизоставя работата по Сиукс. Компанията на Шатълуърт толкова напредва в областта си, че за по-малко от четири години, от началото на бизнеса в 1995г. до откупуването на фирмата през 1999г. Thawte дели почти наравно с гиганта VeriSign пазара на сертификати. Сертификатите и на двете компании вече са включени по подразбиране в големите и разпространени по това време браузъри и се разпознават автоматично за потребителите при посещаване на защитен сайт.

Отделно от печалбите от така успешната компания Thawte, Марк печели 575 млн. щатски долара (около 3.5 млрд. африкански ранда) от VeriSign, когато те откупуват бизнеса му. Това му позволява да основе компанията Canonical, която да спонсорира новата операционна система Ubuntu. През 90-те години Марк е участвал активно и като разработчик на Дебиан. В документациите на Убунту той пише, че причината да съществува проектът е най-вече "бъг №1" -- това е първият и емблематичен доклад за грешка в проекта Убунту, който описва доминиращото и монополно положение на Microsoft и операционната й система Windows в света. И макар да има много и то качествени свободни проекти, Уиндоус продължава да задържа огромния си дял, най-вече заради агресивната си пазарна политика. Затова проектът Убунту има за цел да промотира свободния софтуер не само със създаване на качествена система и отделни програми и докучентации, а и с типичното за бизнес-света финансово и пазарно влияние. Марк остава все така свързан с Дебиан, но винаги казва, че не търси някакво сливане на двата проекта, защото за него Убунту е конкретна реализация на нещо, което е по-общо и универсално, каквото е базата на проекта Дебиан.

След това, през 2001г. Марк основава и "Shuttleworth Foundation, фондация, която се занимава с инвенции и проекти в областта на социалното, най-вече в образованието в Южна Африка. Най-мащабният засега неин проект е "Freedom Toaster", който се занимава с разработка и пакетиране на свободен софтуер за образованието и неговото разпространение в училищата. Като част от проекта в училища и други образователни институции се поставят "киоски", автоматични машини за записване и раздаване на компактдискове със свободен софтуер, оптимизиран за образователни цели.

През 2005г. основава фондацията "Ubuntu Foundation", като дава пъвоначално дарение от 10 млн. долара. Допреди това проектът Убунту изцяло е на финансиране предимно от компанията Canonical и лични дарения на Марк. Същата година купува и 65% от компанията "Impi Linux", разработваща дистрибуция за използване в правителствения сектор, базирана на Убунту. ImpiLinux включва доста несвободен софтуер, затова и не е безплатна, а се продава на администрациите в държавни и обществени учреждения. Марк винаги се е изказвал протев несвободния софтуер и дори ограниченото му наличие в Убунту той смята за нещо временно, което определено е проблем. И макар освен всичко това да не е бил и убеден в успеха на дистрибуция на GNU/Linux, която се продава за пари, все пак откупува контролния пакет на ImpiLinux. Защото, както обяснява сам, момчетата от проекта са го убедили, че има възможност за пазарно развитие и има възможност това развитие да доведе до по-голям дял на свободния софтуер в държавните администрации.

И все пак най-известен сред незапознатата със свободния софтуер или изобщо с ИТ публика Марк Шатълуърт остава с "разходката" си в космоса. За нея през април 2002г. той плаща 20 млн. долара и се качва на руската ракета "Союз ТМ-34", за да стигне до Международната космическа станция. Където прекарва осем дни в участие заедно с екипажа в провеждане на експерименти, свързани със СПИН и човешкия геном.

Проектите пред Убунту са много и набират все повече скорост. Освен дистрибуциите на операционни системи, както обща за всички потребители, така и специализирани за училища, администрации, музиканти и т.н., забележителни са и други инициативи. Като проекта Launchpad например, започнал в началото като вътрешен поддържащ проект на Убунту.

И всичко е започнало с една идея, един гараж, обмисляно развитие и правене на бизнес заради идеите, ползването му като инструмент за социално развитие, а не самоцелно или само за пари.

Месец и нещо след като пусна интеграция с Jabber за моментни съобщения и година и нещо след като стартира, услугата за микроблог и онлайн-състояния Jaiku вече е една от многото в богатото портфолио на Google. От гиганта обещават нови функционалности, които да подобрят още мобилното проследяване на състоянието, една от основните и може би най-съществена част от подобните на Jaiku услуги. Но не се казва нищо повече. Досегашните потребители ще продължат да разполагат с профилите си. Междувременно, докато двата екипа разработват новите неща и интеграциите си, записването на нови потребители е спряно и регистрациите са временно затворени. Човек може да поиска покана за бета-тестове, но директното регистриране не работи.

С какво Jaiku може да помогне на Google и с какво всичко това помага на потребителите? Ако помага, разбира се :)

Много хора използват подобните сайтове за микроблогове, но това далеч не е най-полезната им употреба. Най-голямото предимство на това да се ползва Jaiku е в достъпността на виртуален постоянно обновяващ се и достъпен през мрежата телефонен адресник. Който има въведени състояния и заетости. Например потребителят иска да се обади на свой приятел, но като поглежда адресника в телефона си, миг преди да натисне бутона за набиране вижда, че човекът отсреща е въвел, че е в Лондон. И вече е ясно, че ще трябва да се плати роуминг. Или пък че е в еди-какво си съвещание и съответно звукът е изключен и със сигурност няма да отговори.

Също така освен моментната заетост на контакта човек може да види и какво прави, какво го вълнува събеседника още преди обаждането. Това може да е кратко описание на настроението, или пък идея, записана с няколко думи или нещо важно, линк, цена, дата и час на концерт например. Така не само може да се разбере къде е събеседникът и дали може да отговори, а и вече да има предварителна информация, която да улесни, съкрати разговора и обясненията и да направи говоренето по телефон по-смислено и... дори приятно :)

Twitter, който се появи след Jaiku е малко по-различен. По-"орязан", центриран малко повече върху уеб Jaiku. Иначе и двете услуги са отличаващи се сред нароилите се напоследък подобни с това, че поддържат вътрешна интеграция с XMPP/Jabber. Наскоро от Twitter обявиха, че публикуват кода на библиотеката, която отговаря за Jabber-ядрото в системата им. Поредната софтуерна библиотека за джабър, и една от вече няколкото, написани на Ruby. И Twitter и Jaiku могат да се обновяват през джабър, може да се обновява както своето състояние, така и да се пише в групи. Същото важи и за обратната посока на данните -- известяванията за промените в своя и записаните приятелски профили може да се получава по XMPP.

Удобно звучи. Особено ако човек има някой от тези телефони, които могат да пускат директно клиент за връзка с услугата.

Сега Гугъл се намесват -- на пръв поглед нищо особено, те във всяка нова област си набелязват един от най-добрите проекти и започват да наддават за него. Повечето, ако не и почти всичките от обособените услуги на Гугъл не са разработени от компанията, а са закупени след създаването и първоначалното им представяне и налагане. Кое е интересното в Jaiku на Google? Може би тънката връзка с XMPP? Може би.

Но по-интересно е друго -- Google има проблеми с Facebook. От последните все обещават, че ще отворят данните си за претърсване и индексиране от търсачката на Google. И май вече направиха някои стъпки в тази посока, но все още всичко е много мъгляво. Гугъл имаше една затворена социална мрежа, Orkut, и в управлението на гиганта знаят много добре негативите от това. На никого не е нужен втори Оркут, особено във времето, когато навсякъде говорят за отваряне на социалните мрежи, за избягване на "заключването на потребители", за OpenID и автоматични, а не въвеждани социални профили. За всичко това трябва достъпна информация от отворени мрежи с публикуван и свободен API.

Възможно е това да е част от по-сложен ход на Google, който ще им върне структуриращото. Преди Гугъл беше търсачка и само търсачка, основната работа на сайта беше да внася ред в неподреденото, да показва на потребителите структура в мрежата и те да проследяват смисъл. След масовото навлизане на други и най-различни услуги информацията, идваща от Гугъл вече не е така добре структурирана. Не само че има всякакви услуги, които раздробяват още повече този смисъл, като Blogspot и Reader например, но и самата търсачка вече има реклами и платени промотирани резултати. Не че само по себе си е нещо лошо, не че и въпросните Blogspot, Reader и други подобни не могат също да се ползват за търсене. Но общото впечатление е, че Гугъл вече не е инструмент на потребителя, с който потребителят достига до данните, а е нещо, което "дава", "избутва към", "залива" потребителя с данни, които е преценило, че са му нужни.

С технологии като търсачката, GTalk и GMail, Reader и сега Jaiku потребителската страница в Google може би има шанса да се превърне в това, което Facebook и другите подобни социални мрежи все не успяват -- личен, изцяло настройваем портал към мрежата като динамичен социум. А не създаване на изкуствени статични и затворени социуми в мрежата.

Това може да е обяснение на купуването на Jaiku. А не на Twitter, който е съ-основан от Evan Williams, създателят на Blogspot, които пък бяха купени отдавна от Google. Явно доброто познанство не е достатъчно в такава сделка :)

Новият GNOME 2.20 е готов. Поредната шестмесечна подготовка на най-новото в настолната среда е в края си и днес 2.20 трябва да "плъзне по щандовете". Както винаги досега, новият GNOME следва концепцията, заложена в документите на HIG на проекта и съдържа все повече и удобни инструменти. Някои неща, като основно редактиране на снимки или пък софтуер за детайлно управление на електронни ключове вече минават в графата "задължителни за средата".

Подобренията в новата версия са: по-пълна и по-добра поддръжка на езиците с писане отдясно наляво, интеграция на настолното търсене (tracker, beagle) във файловия мениджър, много нови функционалности в Evolution, Eye of Gnome, подобрен контролен център и управление на захранването и батерията. Разбира се, както и във всяка друга версия на настолната среда, много поправки на грешки и малки подобрения са намерили място.

В пощенския и групов софтуер Evolution има някои интересни нови неща, например при изпращане на писмо се прави специална проверка дали не е "забравен" прикрепен файл. Текстът на писмото се претърсва за типични думи в писмата с прикрепки и ако се намерят, но няма прикрепяне на файл, програмата предупреждава и напомня. Това е настройваемо, разбира се. Други лъскави удобства са показването на иконка в панела при нова поща, което в тази версия си проправя път от приставка към основната част на Evolution. Също така са улеснени още повече миграцията и архивирането на всички данни от пощата, календара и т.н., с действието Backup/Restore. В пощата нишките с нови писма в тях може да се настрои да се показват в горния край на списъка за по-лесно и бързо четене.

Уеб-четецът Epiphany вече е преминал преходния етап от скорошното му сливане с Galeon и дори го очаква следващото голямо предизвикателство -- в следващата версия на GNOME се очаква Epiphany да работи с WebKit вместо с Gecko. WebKit е машината за обработка на уеб-страници, която се използва в Safari на MacOS и Konqueror на KDE. Проектът преди няколко години започва като освободен код от Apple и вече доста време се развива като следващата масово ползвана рендваща HTML машина след Gecko на Mozilla. Много от разработчиците на GNOME са ентусиазирани за тази смяна и все повече са недоволните възгласи, че Gecko е тежък, бавен и труден за поддръжка. Epiphany вече има пробна версия с WebKit и поне по разказите на пробвалите я е много по-бърза от Gecko и програмата не "зацепва" при прелистване или при зареждане на страници. Остава да изчакаме още шест месеца, докато дойде версия 2.22 на средата, съответно и с новия Epiphany.

В сегашния Epiphany има засега по-скоро козметични промени, продиктувани от обратната връзка на потребителите за по-голяма ползваемост. Подобрения в падащото меню на "умните отметки" и адресната лента, подобрения в прелистването на страниците и т.н.

Програмата за преглед да снимки Eye of Gnome е по-бърза и поддържа XMP-файлове освен вградения EXIF. Всички тези метаданни се ползват при показване на снимките -- например умалени копия във файловете, данни за ориентация и т.н. Добавени са и менюта за отваряне на снимката в други програми.

Evince, програмата за преглед на документи, поддържа интерактивни форми в PDF, като също така показването на страниците е чувствително забързано.

Tomboy вече може да работи с отдалечени бележки, съхранявани не само в папка на машината, а и през WebDAV или SSH. Има и синхронизация на бележките и внасяне на бележки от аплета "Лепкави бележки" -- неща, които може да са полезни при съвместна работа или при писане от различни машини.

Системата за помощ и програмата Yelp са променени много, с цел по-лесно ползване. Също така и контролният панел е с пренаредени менюта и листове.

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

Както винаги, можете да се отпуснете с превода на български, който екипът на "GNOME на български!" и най-вече главният ни предаващ преводите Александър Шопов е подготвил, проверил и поправил за вас. Повече за новата 2.20 на GNOME прочетете в официалното обявление.

Новината в сферата на графичните приложения под GNU/Linux (и особено игрите) от няколко дни е обявеното от AMD/ATI освобождаване кода на драйверите за графични карти, публикуване на спецификациите и дори работа с общността разработчици на свободен софтуер за подобряване на продукта и възможно най-скоро пускане на работеща свободна поддръжка на 2D и 3D. Съвсем логично за такава наболяла тема, много бързо емисиите на новинарските портали и на четените блогове, близки до темата, се запълниха с анализи и съобщения. Покриващи цялата гама от краен скептицизъм до също толкова неоправдан свръх-оптимизъм. Къде е истината, можем ли да разберем нещо по-категорично след всичко изписано или просто ще трябва да изчакаме първите версии на новия модул към ядрото?

Официално казаното от AMD е, че ще публикуват спецификациите на новите чипове Radeon и кода на управляваща ги библиотека. След това се надяват поддръжката на 2D и 3D в свободните модули да достигне по-високо ниво. И сега има работещи модули за карти Radeon, но те или са несвободен софтуер, разпространявани като двоични файлове от сайта на ATI, или са свободни, но с непълна поддръжка. Причината е банална -- разработчиците трябва да изследват собственическия модул и да опитват външно да го имитират в свободната си версия. Защото като всеки затворен софтуер, драйверът няма документация, не се знае как работи и всичко е въпрос на късмет с догадките и приближенията.

Някои се сетиха да попитат Марк Шатълуърт, ръководителя на проекта Убунту. Последните версии на Убунту са противоречиви за привържениците на свободния софтуер, защото от една страна са направени много добре за новите и незапознати потребители, но от друга страна дистрибуцията продължава да включва несвободен софтуер в инсталациите. И все пак Убунту успява да балансира и да не стига до крайностите на Linspire или Novell например, които напоследък всеки проблем разрешават с договаряне с Microsoft. Та Марк казва, че този ход на ATI ще подобри значително използваемостта на GNU/Linux за настолна графика. Вече има много добри чипове на Intel, които работят със свободни модули в преносимите компютри. Но в настолните машини човек винаги е изправен пред дилемата към кой несвободен драйвер и съответно чип да се ориентира -- дали да поеме пътя на NVidia, които макар и без да публикуват спецификациите си, дълги години дават на потребителите двоични драйвери с много лесна процедура на инсталиране и обновяване. Или да си вземе някоя от Radeon-картите, за които също има качествен несвободен драйвер, но инсталацията му е известно че не винаги е удобна и лесна. Разбира се, в X.org има и свободни модули за всички тези карти, но точно модулите за NVidia и Radeon ("nv" и "ati") никога не са имали пълна поддръжка на възможностите на чиповете. Особено що се отнася до триизмерна графика и до нови игри (каквито вече от доста време има и с версии за GNU/Linux, като Unreal Tournament, Quake и т.н.), хората просто трябваше да избират или да изтеглят двоичния файл от Nvidia или ATI, или да се откажат от графиката.

Следващата версия на Убунту след вече замразената пред издаване 7.10 Gutsy Gibbon -- очакваната като 8.04 Hardy Heron ще включва тези нови драйвери от ATI. Според Шатълуърт AMD/ATI има възможността да "повлече крак" за обръщане към Linux и на другите компании от бранша, най-вече прекия конкурент NVidia, и след няколко години настолният GNU/Linux да е оборудван с "пълно бойно" на новите графични чипове. И компаниите да печелят от все по-големите продажби на хардуерни видеокарти с увеличаването на интереса към тях от линукс-потребителите. Звучи много логично -- и сега несвободните драйвери се разпространяват напълно безплатно. Една освобождаване на кода и публикуване на спецификациите на хардуера само ще подобри поддръжката му в Linux-ядрото. Съответно ще повиши продажбите на нови карти. И аз бих си взел от тях, нима вие не бихте? :)

Ако всичко се развие добре, печелившите от цялата тази промяна ще са потребителите. Старите драйвери ще си запазят поддръжката, ще бъдат налични на сайтовете за изтегляне. Новите карти с новите драйвери ще бъдат достъпни за много повечеди стрибуции, не само за правещата понякога компромиси със свободността Убунту. Ако се публикуват под свободен лиценз, тези нови разработки по новата спецификация на чиповете ще могат да влязат в дистрибуции като Debian и Fedora. Тоест на практика в повечето, защото тези две са в основата на голяма част от иначе различно брандираните GNU/Linux дистрибуции.

Обещанието е за публикуване спецификациите на новия чип и свободна библиотека за управлението му на 10 септември. Първоначалната поддръжка в библиотеката ще е за 2D, скоро след това следвана от 3D. Старият код на Fglrx-драйвера е отделен и няма да се публикува, нито да се използва. Разработвали са начисто за новия чип. Разработката е на AMD и на екипа на SuSE Linux към Novell. 10-ти септември. Това значи утре, в понеделник.

Intel отвори кода на драйверите си, Майкъл Дел продава Dell с линукси, после HP също започват, Lenovo (които везха да правят лаптопите ThinkPad от IBM) пускат анкета сред потребителите си коя точно дистрибуция на GNU/Linux да инсталират на следващите тинкпади... Едип приятел тези дни си взе първия компютър и изобщо не зареди Уиндоус, а пусна диска с Убунту и сега си работи безгрижно. Проблеми за настолния линукс? Ъм... къде?

И все пак, най-добре ще знаем как ще се отрази това на настолната графика едва когато хората си купят новите карти и когато тези нови модули влязат в дистрибуциите. Другото засега е само прогноза и добро настроение след добрите обещания от AMD/ATI.

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

Какво е предимството на етикетите?

Когато се използват йерархични подредби, указването между два елемента на по-сложни връзки от тези от вида "родителски" и "дъщерен" е много сложно. Най-разпространена и най-добре позната ни е едноизмерната йерархична система -- като тази на файловата структура на почти всички настолни системи. Има родителска папка и дъщерен елемент, който е или нов клон (папка) или листо (файл) в едноизмерната дървовидна структура. Така е при настолните папки и категориите в сайтовете. Хак, който коригира този недостатък на дървовидната йерархия е ползването на символни връзки. Чрез тях един елемент пак съществува физически само в една конкретна папка, но може да е видим и като съдържание в други. Работата със символни връзки е улеснение, но не решава докрай проблема. А и е налична само за някои файлови системи. Други, масово разпространени файлови системи нямат начин за изход от едноизмерната дървовидна йерархия.

Етикетите, от друга страна, дават много по-голяма свобода на описване на елемента. И съответно -- много повече и по-бързи начини за откриването му при търсене. Един елемент може да има неограничен брой етикети, но може да присъства само в една папка или категория. Етикетите решават проблема със зариването с файлове, пръснати из директории с все по-малко говорящи имена и на все по-отдалечени едно от друго нива. Казано накратко, етикетите и всички достъпни метаданни правят търсенето на информация по-лесно и намирането й по-бързо.

В сайтовете -- да, но настолно...

Да, всичко това приложено към настолните програми изглежда малко странно на пръв поглед. Но изграждането на настолни приложения около метаданните има много по-мащабни последствия за ползваемостта, отколкото правенето на сайтове с етикети. Етикетите не са всичко и са само ограничен пример за метаданни. Те са нещо, което се пише на ръка и се залепя на бурканите с лютеница, за да знаем, че това е "лютеница". Но когато отворим шкафа и търсим буркан с лютеница ако само четем етикетите ще е по-трудно и бавно и даже може да сгрешим. Може например за вземем книга, чието заглавие е "лютеница" и е пъхната между бурканите. Да, може на всеки буркан да сме сложили предварително още етикети -- "буркан", "стъкло", "чупливо", "храна", "червено", "от баба" и т.н. Някои са нужни може би, но повечето повтарят нещо, което си е присъщо на обекта. Защо да се хабим да пишем "буркан" на всеки буркан, след като е ясно, че си е точно буркан?

Метаданните са това, което описва данните. Както метафизиката е това, което описва света. "Мета" е нещо близко, встрани, в съседство, от което може да се заключава за разглежданото друго. "Мета" е шаблонът, абстракцията, ръководството за ползване. Може и без метаданни, но дори и без да ги ползваме те присъстват иманентно. Бурканът си е буркан, стъклен, прозрачен, чуплив и т.н. дори и да не сме му залепили такива етикети.

Семантичното настолно търсене е такова търсене, което използва всички налични метаданни за обектите. Ръчно зададени етикети, но и в огромната си част автоматично открити родови описания и взаимовръзки с други обекти. Проследява смисъла, за да открие търсеното.

Пълнотекстово търсене? Защо, като има RDF?

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

Пълнотекстовото търсене ни помага, когато например помним цитат от текст и търсим по него смисъла. То е доста често по-бавно, индексирането при него е по-натоварващо и на практика не се ползва настолно от крайните потребители. Никой не си индексира за пълнотекстово търсене домашната директория с хиляди текстови файлове в различни формати, например. Не че не е възможно, просто е неефективно. Дори и да го направите, нали тези файлове се променят -- всеки път ще обновявате индекса? Да, пак е възможно, но е нужна ужасно мощна машина.

А всичко това може да се направи със семантично търсене. То е това, което ни помага, когато помним някакъв смисъл, някаква връзка между неща или някакво качество на обект, но не помним точен цитат. С него можем да доизградим смисъла, като намерим всички значения, които съществуват и изберем релевантните и после открием и проследим всички взаимовръзки между намерените обекти.

Това в Интернет понякога е излишно или досадно и ползването на категории понякога е по-удобно от търсенето по етикети. Но при настолната работа определено индексирането и търсенето по метаданни е правилната посока за развитие. Цялата ви домашна папка може да се индексира по мета-описания, ръчно поставени етикети и автоматично открити зависимости. Например връзката между файл и е-поща на човека, на когото сте го изпратили прикрепен към писмо преди два месеца не може да се открие с търсене от пълнотекстов тип. Но е нещо нормално за търсачките по метаданни. И понеже се индексират много по-малък обем данни, е възможно това да става в реално време и промените по файловата система на домашната ви папка да се отразяват в базата от данни почти веднага. Даже повечето програми имат настройка колко секудни да изчакват след промяна в обектите, за да не се обърква търсенето с временни файлове.

Всички събрани данни могат да се визуализират с графики, основани на RDF. Това е XML-форматът, използван в Интернет най-често за показване на автоматични карти на сайтовете. Има достатъчно програми, които работят с RDF и могат във всеки момент да визуализират връзките между обектите на търсене, описани от метаданните. Самите екрани на търсещите програми могат да показват именно посредством него смисловите връзки с други обекти. Например не намирате точно искания обект, но виждате връзки към смислово близки обекти и така коригирате връзката и накрая намирате търсеното.

Кои програми?

Разглеждането на отделните имплементации и сравняването на работата им е цяла нова тема за отделни статии. Нека кажем тук само адресите на най-известните настолни семантично търсещи програми за GNU/Linux. Някои от тях са по-нови проекти, други са вече наложили се и се инсталират даже по подразбиране в някои дистрибуции. Някои използват по-малко метаданните, други разчитат изцяло на тях.

Beagle е може би най-познатата програма. Проектиран е да е независим от настолната среда, но макар да поддържа KDE и да има интерфейси и за KDE, като Kerry, yaBi или kBeagleBar, както и уеб-интерфейс Peagle, все пак е по-разпространен в среда на GNOME.

Tracker е това, което мнозина казват, че ще измести Бийгъл. Индексира метаданните и на някои разпознати видове файлове индексира и съдържанието. Както и при другите индексиращи машини, всичко е настройваемо. Разпознава изрази и форми на думите, не само точно изписаните думи за търсене. Може да създава и умалени копия на документите за по-бърза ориентация. Според тестовете работи по-бързо от Бийгъл и е изработван в изискванията на проекта FreeDesktop, което го прави съвместим с всяка среда, която следва FreeDesktop.

Recoll е на основата на индексиращата машина Xapian. Има QT-търсачка и индексиращата машина може да работи както отделно от търсачката, така и като нишка вътре в нея, тоест да е активна само докато работи прозорецът на търсачката. Също както и горните, поддържа сложни търсения и най-различни видове файлове. Може да опростява формите на думите. Опростяването на формите (stemming) обикновено при пълнотекстовото търсене се прави при индексирането и след това търсенето се нагажда към индекса. При Recoll формите се опростяват чак при търсенето, а в индекса влизат всички форми на думата. Това позволява по-голяма гъвкавост при пълнотекстово търсене в документите. За сметка на малко по-обемния индекс.

Strigi ще влезе в бъдещото KDE 4 като подразбираща се и вградена машина за индексиране и търсене по метаданни. Много бърза и оптимизирана да работи незабележимо с другите програми. Както и доста от другите, и тя е преносима и освен под GNU/Linux, Solaris и MacOS се твърди, че работи и в среда на Windows. Както и другите, поддържа откриване на повтарящи се файлове, като пресмята контролни суми за всеки файл. И също така може да прави всичко в реално време и да обновява индекса при промени по файловете.

NEPOMUK е проектът, за който се говори най-много напоследък. Това е крачката, която ще бъде направена отвъд личното работно място към някаква управлявана форма на социална мрежа от метаданни. Целта е нещо, което се нарича "Social Semantic Desktop", съставен от категорично разграничени и ясно свързани две части -- настолна и социална. Така без да се налага силово нещо формално "социално", потребителите ще могат да имат достъп до общото знание, до смисловите свързвания, които правят другите потребители. Казано накратко, това е нещо като Web2.0, пренесен в настолни приложения и развит до пълните си мащаби.

Определено интересни месеци и години ни очакват. Нещо такова се "гласеше" да е и уиндоуската "Виста", но накрая се оказа, че са направили толкова много компромиси, че е далеч назад спрямо дори такива наложени вече програми като Beagle под GNU/Linux. Най-вероятно тласъкът от семантичните настолни търсачки ще "отключи" една друга интересна област -- изцяло семантично построени файлови системи и програми, които ползват пряко метаданни, без да ги превръщат всеки път в неща от вида "папка-директория".

Август е месецът на новата версия 0.12 за програмата за проявяване и обработка на RAW-файлове от цифрови фотоапарати UFRaw. В края на юли излезе версията, базирана на обновения dcraw 8.77 и в средата на август екипът издаде и версия с поправки на пропуснатите грешки. Вече в повечето дистрибуции на GNU/Linux е налична последната версия на UFRaw с новостите в нея. Дебиан леко изостава, защото поддържащият пакета разработчик е в летен отпуск и обещава да подготви 0.12 чак в началото на септември. Ако сте дебиан-потребител и изгаряте от любопитство и нетърпение, не е задължително да чакате официалния пакет. Може да инсталирате сами версия 0.12, но го направете внимателно и така, че след това като се публикува пакетът в Дебиан, да можете лесно и безпроблемно да махнете тестовата си инсталация и да продължите да обновявате системата си "по дебиански".

Как да видим UFRaw 0.12 бързо и лесно под Дебиан

0.12 има нови допълнителни зависимости -- gtkimageview и libbz2. Първата възможност може да е да ползвате пакет от някой от дериватите на Дебиан, например известното напоследък Ubuntu, но не си губете времето. Макар някои програми хората в Убунту да пакетират сами, даже някои неща и връщат на Дебиан, точно този пакет е от множеството такива, които се взимат от хранилищата именно на Дебиан. Така че и в Убунту в момента последната версия е "0.11-2ubuntu1", което е принципно същото като тази в Дебиан, 0.11-2". Любителите на FSF-визията също са ограничени в случая, защото пък GNewSense е дериват на Убунту. В rpm-света сигурно вече има доста пакети, но във Fedora също засега е старата версия 0.11. В Slackware положението е същото. С две думи неофициални пакети се намират, но официално вече почти цял месец след излизането на 0.12 никой не пакетира, макар да няма и доклади за грешки. Обяснението може би е, че е сезонът на отпуските. :)

Вместо да търсите неофициален пакет за да го преобразувате в такъв за дебиан с alien, може да компилирате кода на новата версия сами. Като внимавате да не замърсите излишно системата си, тоест да можете да махнете тази версия, когато излезе официалният пакет.

С помощта на програмата checkinstall може да направите в последния момент, след компилирането и преди инсталирането от готовите за инсталиране на системата ви файлове deb-пакет. Това е малко "мръсен" начин за бързо правене на дебиан-пакети, но когато става дума за ползване само на вашата машина или на ваша отговорност, и този "бърз хак" върши работата. Предимството на checkinstall пред ползването на "make install" е, че премахването на програмата след това става лесно под управлението на dpkg. Можете и при компилиране и инсталиране с make-скрипта да деинсталирате, но трябва да сте запазили директорията с кода, за да изпълните от нея "make uninstall". А и може например в скрипта да не е добавено "uninstall".

И така, вземаме кода от страницата на UFRaw. Разархивираме
$ tar -xzf ufraw-0.12.1.tar.gz
$ cd ufraw-0.12.1/
$ ./configure
Може да се окаже, че някои от нужните пакети ви липсват, при мен това беше само liblcms1-dev. Допълнително сложих и libexiv2-dev (за поддръжка на EXIF), libgtkimageview0, libgtkimageview-dev (за новият преглед на снимките през gtkimageview), libgimp2.0-dev (за създаване и на приставка за интеграция с GIMP). Тези допълнителни пакети си ги отбележете някъде, за да ги махнете когато сложите официалната 0.12 версия. Има и възможност за свързване с Cinepaint, но от известно време го няма в Дебиан, няма го и при мен, така че ще карам с GIMP.
След това компилираме
$ make
(правим си кафе)
След това, вместо да напишем "make install", ползваме checkinstall:
$ su -
# checkinstall -D make install
Следват няколко въпроса, искане на описание за пакета и потвърждение на настройките. След това пакетът е създаден в текущата директория и е инсталиран на системата.

Новите теща във версия 0.12 на UFRaw

0) Изрязване на кадъра в RAW. Нещо, което е по-близо до обработката, отколкото до проявяването, но ако се загледате в конверторите за други операционни системи (или ако ваши приятели ви разкажат;) ще видите, че все повече от рутинната работа по първоначалната или не особено сложна обработка се прехвърля към конверторите. Много по-удобно е да изрежеш или настроиш по друг начин снимката си още при проявяването, отколкото само заради едното изрязване да стартираш GIMP, например.
Изрязването работи при включване на листчето "Crop and rotate". Със завлачване с мишката на ръбовете на снимката оформяте правоъгълника, който искате да се прояви и запази.

1) Показване на снимката с gtkimageview, което води до много по-удобно и бързо разглеждане на части от кадъра, увеличаване и намаляване, бързо търсене на области. Както и при всички прегледи в новата версия на GIMP, така и тук в долния десен ъгъл на снимката има бутонче с две кръстосани стрелки. При натискането му се включва инструментът за бърза навигация. Също така и бутоните за увеличение са изнесени на подходящо място и превключването на мащабите става много по-бързо.

2) Бутони за бързо обръщане и завъртане на снимката. В предишните версии не можеше да се обръща огледално и да се завърта кадърът -- сега това става лесно, пак с режима "crop and rotate", който се използва и за изрязване.

3) Чистене на шума в RAW с помощта на вграденото в DCRaw "wavelet denoising". Плъзгачът се намира точно под тези за цветна температура, насищане на зеленото и настройките на интерполацията. Това е работният лист, който се използва най-много и най-често и по подразбиране се зарежда при пускане. Плъзгачът при зареждане е в положение "0", най-вляво, което значи че не се прилага никакво чистене на шум. Включването и засилването на обработката става с увеличаване стойността му надясно.

4) Два нови режима на интерполация -- PPG (Patterned Pixel Grouping) и EAHD (Enhanced Adaptive Homogeneity-Directed). EAHD е подобрение на подразбиращата се интерполация AHD. Включва сложно заглаждане на цветовете. Също така намалява шума и хроматичната аберация без загуба на качество. Другата нова интерполация, PPG, е горе-долу също толкова добра, но с доста по-добра производителност и може да се използва за намаляване времето на обработка на големи, сложни кадри или последователна работа по много снимки.

Другите налични интерполации в UFRaw, познати от предишните версии са AHD, VNG (Variable Number of Gradients), VNG four color, Bilinear и Half-size. AHD все още е подразбиращата се, доказала се интерполация. VNG е по-предишната подразбираща се, а вариантът й "VNG four color" се препоръчва да се ползва, ако в кадъра има нарушения на изображението, идващи от байеровата решетка на цифровия сензор. Последните две, Bilinear и Half-size се отличават с това, че са много по-бързи от другите и когато не се цели най-добро качеството, те са добър избор.

5) Поддръжка на RAW-файлове, компресирани с gzip и bzip2.

6) Възможност за работа като приставка към Cinepaint. Другите два режима, като отделна програма и като приставка към GIMP са запазени от предишните версии.

7) Поддръжка на цветови профили -- входни, изходни и такива за показване. Последните два могат да се настройват и според целта на изобразяване. По подразбиране е включен sRGB, за добавяне на други (AdobeRGB и др. под.) трябва ICC-файловете да се заредят в програмата през съответния бутон вдясно от настройката. Това беше заложено още в предходната версия, но сега е по-добре подредено в интерфейса.

Като цяло новата версия на UFRaw създава сигурно усещане и впечатление за стабилен инструмент. При режим "white balance" (първият работен лист) се забелязва, че в полето на снимката с мишката могат да се избират области. Засега това не води до селективно променяне на белия баланс и другите настройки от режима. Но такова избиране не се задейства в другите режими, а в режима за изрязване именно с мишката върху снимката се избира изрязваната област. Това може да ни наведе на мисълта, че явно за следваща версия е оставено избирателното настройване на баланса на бялото и зеленото.

Без да донася невиждани чудеса в конвертирането, версия 0.12 на UFRaw показва приятна тенденция. А именно подробното следване на нововъведенията в библиотеката dcraw и адекватното им и удобно внедряване в графичния интерфейс. Другите свободни RAW-конвертори за *NIX (като Rawstudio например) се развиват доста по-бавно и изостават от нововъведенията на Dave Coffin в неговия dcraw. Преди време Дейв Кофин беше казвал в интервюта, че пренасищането с всякакви собственически RAW-формати (някои от тях некачествени и неподходящи) е заплаха за фотографа любител, но той си е поставил задачата да премахва тази пречка със свободната библиотека dcraw. И че най-добрият досега създаден формат е DNG, който макар и компромис, защото не е съвсем свободен, е отворен и публикуван като спецификация. Затова и всички програми, работещи с drcaw отдолу имат много добра поддръжка на DNG.

След като години след публикуването на DNG единственият цифров фотоапарат с вградена DNG-поддръжка засега е Pentax K10D, пред фотографите все още стои дилемата дали за всеки случай да не си запишат копия на кадрите си, преобразувани с компютър до DNG. Много хора намекват, че след 5 или 10 години сегашните RAW-формати няма да бъдат поддържани от бъдещите фотоапарати и несвободни програми. Остава ни успокоението, че dcraw само ще добавя нови поддръжки в следващите си версии и няма да изоставя формати. Така и след 10 години ще можем да проявяваме днешните формати на Canon, Nikon, Olympus, Sony и кои ли още не -- всеки различен от другия и всеки "таен".

Новата версия 2.4 на програмата за обработка на растерни изображения The GIMP е на финалната права преди официалната си премиера. Екипът на GIMP публикува версията 2.4.0-rc1. След като дълго време беше бързо развиваща се програма, в последните си версии като че ли леко изостава откъм "нови неща" в сравнение с пряката конкуренция на, да кажем, Adobe Photoshop. Една от основните причини е, че голяма част от кода е бил основно преработен и от няколко версии вече GIMP е изцяло модулен софтуер. Очаква се това да ускори внедряването на новите функционалности. След като веднъж излезе 2.4 и след това се премине на използване на библиотеката GEGL. Библиотека с дълга известност в общността на свободния софтуер, между другото. Може би това е едно от парчетата код, за което се е говорило най-продължително и... все в бъдеще време. :)

И все пак какво е новото в 2.4? Който е ползвал междинните версии 2.3.х няма да забележи драстично нови неща, защото голяма част от тях се внедряваха в тези междинни версии. От друга страна, най-големият "минус" засега и причината за най-силният вой от другия, фотошопския лагер си остава -- и версия 2.4 ще поддържа само по 8 бита на цветови канал. Остава сериозната вече закана на екипа това да е последната версия преди 16-битовия цвят.

Та към новите неща:

0) Скорост, скорост, скорост. GIMP се зарежда доловимо по-бързо. Чувствително е подобрено бързодействието на алгоритмите за замъгляване, особено тези на гаусовото замъгляване и селективното гаусово замъгляване.

1) Нови инструменти за избиране. Старата концепция, при която с някои от инструментите се задаваше селекция и след това с инструмента за трансформиране тя се променяше е премахната изцяло. Сега направо избирате инструмент и работите само с него. След избиране при доближаване до края на областта се появяват контроли за промяна на размерите и съответно формата. С натискане на Shift и Alt пак получавате възможност да добавяте и отнемате от селекцията. Същото удобство е добавено и към други инструменти, например към инструмента за изрязване.

2) Избор на цвят от екрана. В палитрите за избор на цвят вече има пипети, с които можете директно да избирате произволен цвят от екрана, включително и от фона, от други работещи програми и т.н.

3) Нови икони от проекта Tango. Иконите навсякъде из програмата са съобразени със стиловите препоръки на Tango. Изгледът е еднакъв за всички поддържани операционни системи. По подразбиране идват два изгледа -- нормален и умален. Вторият може да е подходящ за по-малки работни площи или когато панелите имат склонност да ви се "пречкат" повечко.

4) Менютата са леко преподредени -- няма вече отделни менюта за Script Fu и Python Fu. И двете са подменюта във "Филтри". Има ново отделно меню за работа с цветовете.

5) Управление на цветовете. Вече може да се включват външни цветови профили (.icc или .icm), в настройките на програмата има отделен прозорец за управление на цветовете. Настр�