(Обещах в предишния запис да отворя една тема специално за да се карат в коментари под него привърженици на различните ОС колкото си искат. Това не е този запис. Него ще напиша малко по-нататък.)
Красимир Гаджоков изказа в коментар под предишния запис тезата, че фирмените софтуери преминават много по-сериозно тестване от свободните, и затова са по-сигурни. Аз обаче не съм съгласен с него. Според мен механизмите за тестване на свободния софтуер не само дават повече възможности, но потенциално и по-добри резултати. Те обаче са различни от механизмите на “собственическия” софтуер – за да можеш да извлечеш от тях по-добрите резултати, трябва да ги познаваш. Затова и смятам да ги опиша в този запис, и да ги сравня със собственическите.
При писане на собственически софтуер фирмата-автор обикновено след приблизителното завършване на поредната версия, като правило веднъж на две-три години, я подлага на набор стандартизирани тестове. Откритите грешки се коригират, и продуктът се пуска на пазара чак тогава. Тъй като стандартизираните тестове се правят от елитни експерти, те обикновено изчистват много добре кода от грешки. Затова и когато на пазара бъде пусната версия собственически софтуер, тя обикновено е чиста или почти чиста от грешки.
Така е на теория. На практика обаче нещата са по-различни.
Като начало, не съществуват експерти, способни да създадат тестове, които да открият всички или дори почти всички възможни грешки в една програма. За изчистването на точно определен тип грешки например е възможно да се създадат автоматизирани тестове (за някои грешки е по-лесно, за други – по-трудно). Ако програмата е много ограничена като възможности, и има точно определена, добре изучена математически функция, създаването на тестове за всякакви нейни грешки също принципно е възможно. С увеличаване на сложността на програмата обаче сложността на изчистването й от грешки расте експоненциално: типична проста програмка за чат вече е някъде около границата, след която пълното изчистване от грешки вече струва повече, отколкото е икономически смислено да се инвестира.
Затова всяко едно тестване на по-сложни програми задължително включва специалисти, които търсят грешките лично, чрез работа с програмата. Тази работа обаче изисква време, и сложността й също расте с растежа на програмата, но експоненциално. Отделно, почистването на открита грешка не винаги е тривиално. Затова дори най-добрите компании поставят мениджърски срокове за процеса на чистене на грешки. Неизчистените просто си остават в софтуера, и в добрия случай биват коригирани чрез безплатни ъпгрейд-версии, ъпдейтове и/или сървиспакове.
Търсенето на грешки в “собственически” софтуер обикновено е в близо 100% вътрешнокорпоративна дейност; отстраняването им е в 100% вътрешнокорпоративна дейност. Кодът е търговска тайна, така че няма възможност да го преглеждат, още повече пък коригират, външни лица. Малка част от процеса на чистене на грешки се състои в рапорти, получени от външни лица; голямата част е затворена вътре във фирмата, тоест разчита единствено на нейните ресурси (и по-точно на неголяма част от тях). Това обективно създава условия, особено при по-големи софтуери:
– те да бъдат пускани на пазара в не особено изтествано състояние
– и след пускането им на пазара премахването на грешките да не върви по-бързо
– корекциите на грешките да идват късно и бавно, заради по-малкия ресурс зад тях.
Въпреки тези недостатъци, фирмите често произвеждат прилично стабилен софтуер, за сметка на налагани от ръководството високи изисквания и добре отработени методики за писане на код, и осигуряване на преминаването на един минимум изтестване. Класически пример е “желязната” OS/2 – операционна система не само почти без бъгове, но и почти неуязвима за атаки. (Уви, успешно загробена от безумно некадърния й маркетингов екип. Да бяха хванали IBM няколко клошари от улицата, щяха да се справят по-добре…) Друг що-годе приличен пример са продуктите на… Майкрософт. (Ние често ги ругаем колко са зле, но като се има предвид обемът им, всъщност не са никак зле.)
Как стоят нещата при свободния софтуер?
Принципно свободният софтуер не е обвързан с една определена задължителна методика за чистене на грешки. Има обаче методика, която се е наложила като добре работеща в неговите условия. По-долу описвам нея. Известна е като “Release Early, Release Often”.
При тази методика версии на софтуера се пускат често, примерно веднъж на около три месеца за по-малки програми, и на около шест за големи софтуерни пакети. (Фиксиран период често няма – версията се прави за “когато стане готова”.) Версията се пуска след сравнително по-малко изтестване, отколкото при “собственическите” програми. Идеята е, че след като потребителите получават нещата свободно, е редно и те да допринесат в някаква степен за продукта – като го тестват.
Наглед това хич не говори добре за свободния софтуер. На практика обаче нещата пак са по-различни.
Като начало, доста свободни софтуери, особено по-големи, напоследък прилагат преди пускане интензивни батерии тестове, напълно сравними с тези на комерсиалните софтуери. Така че това, което излиза от тях, още в началото си е на нивото на типичен комерсиален софтуер – в нашия случай, критерият ни за “изтестваност”. (А и всеки техен потребител може да ги прекара през подобни батерии от тестове; много често това се прави, при сериозно финансиране, от фирми, които преценяват дали този софтуер е годен за тяхна вътрешна употреба.)
Свободният софтуер се придружава от пълна достъпност на изходния код. Огромен брой професионалисти, както любопитни програмисти, така и експерти по сигурност, могат да ги преглеждат лесно и юридически легално. Това подсигурява на софтуера голям peer review – изпитаният и доказан механизъм за откриване и изчистване на проблеми от всякакъв интелектуален продукт. (Много дисциплини, например науката, не признава едно откритие, ако то не е преминало широк peer review.) Също така, ако авторите на софтуера не са направили нещо полезно, било поради недосетливост, било поради нежелание, всеки има право да го доправи (и обикновено има и достатъчно желаещи). Това допълнително повишава сигурността по начин, който е недостъпен при собственическия софтуер.
За целите на някои потребители – военни, служби за борба с организираната престъпност, и т.н. – пълната достъпност на изходния код е, или при тяхната специфика би трябвало да е задължително условие. Направените от тях прегледи на свободния софтуер са полезни и за всички останали потребители.
Пускането в обръщение на поредната версия свободен софтуер е само началото на истинското й тестване, дори когато той се пише изцяло от фирми. Потребителите му докладват за всякакви проблеми, които са срещнали, авторите предимно ги чистят “наготово”. Достъпният изходен код води до това, че често потребители с програмистки умения дори дават готови корекции. Също, понеже тестването е при потребителите, то улавя почти всички грешки, които е реално програмата да даде при употреба – тестват я тези, които ще я употребяват. Резултатът е голяма степен на покриване на възможните грешки.
Официалната “бързо пусната” поредна версия бива максимално бързо последвана и от “бъгфикс” подверсии, чиято единствена новост е почистването на грешки. Всяка от тях е все по-изчистена от предишните. Обикновено в края на живота си, преди излизането на следващата нова версия (което значи обикновено три до шест месеца), версията е почти напълно изчистена от грешки.
Много продукти дори поддържат по две или повече активни версии едновременно: “стара”, стабилна, “нова”, включваща нови качества, и евентуално междинни. Чистенето на грешките върви паралелно; с узряването “новата” става “стара”, и т.н. Потребителят може да си избира оптималния за него баланс между нови качества и стабилност.
(Всъщност, в комерсиалния софтуер положението е точно същото. Много специалисти например препоръчват на фирми с високи изисквания към работния софтуер да не преминават на нова версия на Уиндоус, преди да излезе за нея един, по възможност дори два сървиспака. Истинското предимство на свободния софтуер тук е, че той казва открито на потребителите си какво е реалното положение с тази или онази версия, и им дава възможност да си изберат информирано оптималното за тях. Иначе нещата са сравними.)
Различните дилъри и интегратори на свободен софтуер се съобразяват с тази негова особеност в различна степен. Най-добро съобразяване с нея съм намерил в Дебиан (който именно и позволи да блесне силата й). По всяко време той поддържа три поддистрибуции с различна новост и изтестваност на софтуера в тях. Така наречената stable най-често съдържа софтуер на по две-три години, но е почти напълно изчистена от грешки: по всяко едно време в типичния stable има около стотина известни бъга, което е нищо на фона на около 20 000-те пакета в него – един бъг на двеста програми… Unstable пък залага на това да съдържа най-нов софтуер, но гаранциите й за изтестваност са по-малки. (Обикновено използвам нея – виждал съм бъгави софтуери, а понякога дори счупени пакетни зависимости. Но като цяло също е сравнима като стабилност с новоизлязла версия на Уиндоус.)
В най-голяма степен нарушават тази система интегратори, които пускат стабилни версии на базата на най-нови софтуери. По критериите на повечето потребители например Убунту или Федора например са ОК, но аз не бих ги сложил на сървър, на който искам да разчитам (поне докато имам като алтернатива Дебиан stable – ще е осезаемо по-стар, но го слагаш и забравяш без угризения на съвестта). Съответно, системите им може да са или да не са стабилни, но са правени не чрез използване на силата на тази методика, а в борба с нея. (Добре де, Убунту LTS след първата си година също вече са до голяма степен изчистени.)
Затова и при подбиране на свободен софтуер е важно методологията му за чистене на грешки да се познава, и потребителят да се съобразява с нея. Ако първият му приоритет е стабилността, не е разумно да се нахвърля на най-нова версия на софтуера. Ако пък е новостта, няма нужда да се мъчи със стабилна, но стара версия. И в двата случая ще ругае софтуера, а грешката ще е негова. Поправи ли си я, ще бъде доволен.
В крайна сметка: свободният софтуер, поне по-често използваните програми, преминава не по-малко, а повече и по-качествено тестване от собственическия. Методиката му за тестване обаче е различна от тази на собственическия; за правилен подбор на софтуер е нужно тя да бъде познавана.