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

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

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

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

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

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

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

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

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

В случай, че идентификацията е наложителна, непременно трябва да се обмисли използването на механизми, независещи пряко от сайта. Най-добре е, ако тези механизми зависят и принадлежат на самия потребител. Такъв механизъм за идентификация е 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 прочетете в официалното обявление.