(Обещах в предишния запис да отворя една тема специално за да се карат в коментари под него привърженици на различните ОС колкото си искат. Това не е този запис. Него ще напиша малко по-нататък.)
Красимир Гаджоков изказа в коментар под предишния запис тезата, че фирмените софтуери преминават много по-сериозно тестване от свободните, и затова са по-сигурни. Аз обаче не съм съгласен с него. Според мен механизмите за тестване на свободния софтуер не само дават повече възможности, но потенциално и по-добри резултати. Те обаче са различни от механизмите на “собственическия” софтуер – за да можеш да извлечеш от тях по-добрите резултати, трябва да ги познаваш. Затова и смятам да ги опиша в този запис, и да ги сравня със собственическите.
При писане на собственически софтуер фирмата-автор обикновено след приблизителното завършване на поредната версия, като правило веднъж на две-три години, я подлага на набор стандартизирани тестове. Откритите грешки се коригират, и продуктът се пуска на пазара чак тогава. Тъй като стандартизираните тестове се правят от елитни експерти, те обикновено изчистват много добре кода от грешки. Затова и когато на пазара бъде пусната версия собственически софтуер, тя обикновено е чиста или почти чиста от грешки.
Така е на теория. На практика обаче нещата са по-различни.
Като начало, не съществуват експерти, способни да създадат тестове, които да открият всички или дори почти всички възможни грешки в една програма. За изчистването на точно определен тип грешки например е възможно да се създадат автоматизирани тестове (за някои грешки е по-лесно, за други – по-трудно). Ако програмата е много ограничена като възможности, и има точно определена, добре изучена математически функция, създаването на тестове за всякакви нейни грешки също принципно е възможно. С увеличаване на сложността на програмата обаче сложността на изчистването й от грешки расте експоненциално: типична проста програмка за чат вече е някъде около границата, след която пълното изчистване от грешки вече струва повече, отколкото е икономически смислено да се инвестира.
Затова всяко едно тестване на по-сложни програми задължително включва специалисти, които търсят грешките лично, чрез работа с програмата. Тази работа обаче изисква време, и сложността й също расте с растежа на програмата, но експоненциално. Отделно, почистването на открита грешка не винаги е тривиално. Затова дори най-добрите компании поставят мениджърски срокове за процеса на чистене на грешки. Неизчистените просто си остават в софтуера, и в добрия случай биват коригирани чрез безплатни ъпгрейд-версии, ъпдейтове и/или сървиспакове.
Търсенето на грешки в “собственически” софтуер обикновено е в близо 100% вътрешнокорпоративна дейност; отстраняването им е в 100% вътрешнокорпоративна дейност. Кодът е търговска тайна, така че няма възможност да го преглеждат, още повече пък коригират, външни лица. Малка част от процеса на чистене на грешки се състои в рапорти, получени от външни лица; голямата част е затворена вътре във фирмата, тоест разчита единствено на нейните ресурси (и по-точно на неголяма част от тях). Това обективно създава условия, особено при по-големи софтуери:
– те да бъдат пускани на пазара в не особено изтествано състояние
– и след пускането им на пазара премахването на грешките да не върви по-бързо
– корекциите на грешките да идват късно и бавно, заради по-малкия ресурс зад тях.
Въпреки тези недостатъци, фирмите често произвеждат прилично стабилен софтуер, за сметка на налагани от ръководството високи изисквания и добре отработени методики за писане на код, и осигуряване на преминаването на един минимум изтестване. Класически пример е “желязната” OS/2 – операционна система не само почти без бъгове, но и почти неуязвима за атаки. (Уви, успешно загробена от безумно некадърния й маркетингов екип. Да бяха хванали IBM няколко клошари от улицата, щяха да се справят по-добре…) Друг що-годе приличен пример са продуктите на… Майкрософт. (Ние често ги ругаем колко са зле, но като се има предвид обемът им, всъщност не са никак зле.)
Как стоят нещата при свободния софтуер?
Принципно свободният софтуер не е обвързан с една определена задължителна методика за чистене на грешки. Има обаче методика, която се е наложила като добре работеща в неговите условия. По-долу описвам нея. Известна е като “Release Early, Release Often”.
При тази методика версии на софтуера се пускат често, примерно веднъж на около три месеца за по-малки програми, и на около шест за големи софтуерни пакети. (Фиксиран период често няма – версията се прави за “когато стане готова”.) Версията се пуска след сравнително по-малко изтестване, отколкото при “собственическите” програми. Идеята е, че след като потребителите получават нещата свободно, е редно и те да допринесат в някаква степен за продукта – като го тестват.
Наглед това хич не говори добре за свободния софтуер. На практика обаче нещата пак са по-различни.
Като начало, доста свободни софтуери, особено по-големи, напоследък прилагат преди пускане интензивни батерии тестове, напълно сравними с тези на комерсиалните софтуери. Така че това, което излиза от тях, още в началото си е на нивото на типичен комерсиален софтуер – в нашия случай, критерият ни за “изтестваност”. (А и всеки техен потребител може да ги прекара през подобни батерии от тестове; много често това се прави, при сериозно финансиране, от фирми, които преценяват дали този софтуер е годен за тяхна вътрешна употреба.)
Свободният софтуер се придружава от пълна достъпност на изходния код. Огромен брой професионалисти, както любопитни програмисти, така и експерти по сигурност, могат да ги преглеждат лесно и юридически легално. Това подсигурява на софтуера голям peer review – изпитаният и доказан механизъм за откриване и изчистване на проблеми от всякакъв интелектуален продукт. (Много дисциплини, например науката, не признава едно откритие, ако то не е преминало широк peer review.) Също така, ако авторите на софтуера не са направили нещо полезно, било поради недосетливост, било поради нежелание, всеки има право да го доправи (и обикновено има и достатъчно желаещи). Това допълнително повишава сигурността по начин, който е недостъпен при собственическия софтуер.
За целите на някои потребители – военни, служби за борба с организираната престъпност, и т.н. – пълната достъпност на изходния код е, или при тяхната специфика би трябвало да е задължително условие. Направените от тях прегледи на свободния софтуер са полезни и за всички останали потребители.
Пускането в обръщение на поредната версия свободен софтуер е само началото на истинското й тестване, дори когато той се пише изцяло от фирми. Потребителите му докладват за всякакви проблеми, които са срещнали, авторите предимно ги чистят “наготово”. Достъпният изходен код води до това, че често потребители с програмистки умения дори дават готови корекции. Също, понеже тестването е при потребителите, то улавя почти всички грешки, които е реално програмата да даде при употреба – тестват я тези, които ще я употребяват. Резултатът е голяма степен на покриване на възможните грешки.
Официалната “бързо пусната” поредна версия бива максимално бързо последвана и от “бъгфикс” подверсии, чиято единствена новост е почистването на грешки. Всяка от тях е все по-изчистена от предишните. Обикновено в края на живота си, преди излизането на следващата нова версия (което значи обикновено три до шест месеца), версията е почти напълно изчистена от грешки.
Много продукти дори поддържат по две или повече активни версии едновременно: “стара”, стабилна, “нова”, включваща нови качества, и евентуално междинни. Чистенето на грешките върви паралелно; с узряването “новата” става “стара”, и т.н. Потребителят може да си избира оптималния за него баланс между нови качества и стабилност.
(Всъщност, в комерсиалния софтуер положението е точно същото. Много специалисти например препоръчват на фирми с високи изисквания към работния софтуер да не преминават на нова версия на Уиндоус, преди да излезе за нея един, по възможност дори два сървиспака. Истинското предимство на свободния софтуер тук е, че той казва открито на потребителите си какво е реалното положение с тази или онази версия, и им дава възможност да си изберат информирано оптималното за тях. Иначе нещата са сравними.)
Различните дилъри и интегратори на свободен софтуер се съобразяват с тази негова особеност в различна степен. Най-добро съобразяване с нея съм намерил в Дебиан (който именно и позволи да блесне силата й). По всяко време той поддържа три поддистрибуции с различна новост и изтестваност на софтуера в тях. Така наречената stable най-често съдържа софтуер на по две-три години, но е почти напълно изчистена от грешки: по всяко едно време в типичния stable има около стотина известни бъга, което е нищо на фона на около 20 000-те пакета в него – един бъг на двеста програми… Unstable пък залага на това да съдържа най-нов софтуер, но гаранциите й за изтестваност са по-малки. (Обикновено използвам нея – виждал съм бъгави софтуери, а понякога дори счупени пакетни зависимости. Но като цяло също е сравнима като стабилност с новоизлязла версия на Уиндоус.)
В най-голяма степен нарушават тази система интегратори, които пускат стабилни версии на базата на най-нови софтуери. По критериите на повечето потребители например Убунту или Федора например са ОК, но аз не бих ги сложил на сървър, на който искам да разчитам (поне докато имам като алтернатива Дебиан stable – ще е осезаемо по-стар, но го слагаш и забравяш без угризения на съвестта). Съответно, системите им може да са или да не са стабилни, но са правени не чрез използване на силата на тази методика, а в борба с нея. (Добре де, Убунту LTS след първата си година също вече са до голяма степен изчистени.)
Затова и при подбиране на свободен софтуер е важно методологията му за чистене на грешки да се познава, и потребителят да се съобразява с нея. Ако първият му приоритет е стабилността, не е разумно да се нахвърля на най-нова версия на софтуера. Ако пък е новостта, няма нужда да се мъчи със стабилна, но стара версия. И в двата случая ще ругае софтуера, а грешката ще е негова. Поправи ли си я, ще бъде доволен.
В крайна сметка: свободният софтуер, поне по-често използваните програми, преминава не по-малко, а повече и по-качествено тестване от собственическия. Методиката му за тестване обаче е различна от тази на собственическия; за правилен подбор на софтуер е нужно тя да бъде познавана.
Аз смятам, че по отношение на сигурност и производителност свободния софтуер води пред комерсиалния.
Обаче, изостава чувствително по отношение на features, потребителски интерфейс, обратна връзка с клиента, интеграция с други комерсиални софтуери, поддръжка и развитие (софтуер Х беше много хубав, ама разработчика влезе в затвора и вече не го поддържа – да ви е познато?). Незнам от колко време чакам да има възможност за домейн контролер под Линукс, примерно (равен по възможности на MS варианта и да може да обслужва MS машини).
заключението е доста съмнително.
По принцип реалното тестване е при употребата от юзъри на бета/RC версии или официалния продукт. За да кажеш че свободния софтуер се тества повече, значи го ползват повече юзъри, което не е така с малки изключения.
Качеството идва от количеството, колкото повече даден продукт се използва, толкова по-голяма вероятност има някой да налети на проблем и да го докладва.
Според мен самия факт, че сорс кода е свободно достъпен няма никакво отношение към качеството на тестване и това на крайния продукт.
Единици са тези, които ще седнат да четат и дебъгват сорс на нещо което не са писали те самите.
За да се оправи бъг, единственото необходимо е да знаеш в какво се изразява проблема и как точно да го възпроизведеш – ако знам това, ще си го оправя сам, изобщо не ми трябва някой друг. А пък за да ми изпрати някой такава информация, изобщо не му трябва да гледа сорса.
@Galarad: Интеграцията с комерсиални софтуери често е трудна не по вина на свободния софтуер. Вярно е, че това крайния потребител не го вълнува. И съответно си плаща като поп за незаинтересоваността. Ако Asus не бяха имали нахалството да пуснат Eee PC с Линукс, към момента Уиндоус XP щеше вече да е в пенсия като продажби (и твърде скоро като поддръжка), а Уиндоус 7 вероятно още нямаше да има публична бета (и може би изобщо нямаше да има).
@Пешо: Реалното тестване винаги продължава през целия живот на продукта; при комерсиалния софтуер обаче реалното оправяне на грешки често свършва с бетите. Отговори си сам дали това е плюс. А свободният софтуер, заради свободата си, се ползва (в пряк или косвен вид, примерно като модули, включени в други софтуери) далеч по-разнообразно от несвободния, въпреки по-малкото си (на десктопа – на сървъра са далеч повече) потребители. Да не говорим, че една от най-големите разлики между двата типа софтуер е какво се случва след докладването на бъг. Ако е реално важен, в свободните софтуери корекцията се появява обикновено за часове. (Което не винаги е плюс, но вината тук е не на типа софтуер или разработчиците му.)
Фактът, че сорс кода е свободно достъпен, има колосално отношение към качеството. Тези, които четат и дебъгват сорс, било защото са се насадили на бъг, било защото им искат одит на еди-кой си софтуер, са много хиляди. От по-използваните свободни софтуери вероятно всеки минава поне по три-четири пълни одита, на всеки ред сорс код, от хора, които не са сред авторите му. И тогава се случва бъгове да останат неткрити дълго време, дори гадни – примерно прословутия тъп бъг с рандъм-генератора на SSH в Дебиан. Но в свободния софтуер в крайна сметка те биват откривани, и биват взимани мерки за опазване на потребителя, а не за опазване на авторитета на авторите.
За да се оправи бъг е необходимо той да бъде оправен в изходния код. Пробвай примерно да оправиш бъга, който бях описал преди време – Microsoft Outlook кешва DNS резолвинга на майлсървърите си, и не го опреснява, докато компютърът не бъде рестартиран; ако преместиш майлсървъра на друго IP, пощата ще спре да идва до рестарт. Чакам бъгфикс за него. 🙂
@ Григор
“Ако Asus не бяха имали нахалството да пуснат Eee PC с Линукс, към момента Уиндоус XP щеше вече да е в пенсия като продажби (и твърде скоро като поддръжка), а Уиндоус 7 вероятно още нямаше да има публична бета (и може би изобщо нямаше да има).”
Е хайде сега. Някакво си Еее с незначителен пазарен дял определило съдбата на ХР и 7. Ти вярно си фантаст 🙂
Виста е рядък за Майкрософт случай, при който потребителите масово отказват да минат от предишната версия на ОС-а към новата, и това вече няколко години. Въпреки огромната цена на маркетинговата кампания за рекламирането й. Мениджърите на Майкрософт са всичко друго, но не и идиоти. Не можеш да спреш поддръжката на версия, която има 2 пъти повече инсталации от Виста. Не можеш и да не си направиш изводи защо потребителите реагират така срещу Виста и да не вземеш мерки следващия Уиндоус да не повтори съдбата й. Еее с Линукс тук няма нищо общо. Майкрософт иска да получава парите на потребителите за ъпгрейд към нов Уиндоус, и за целта трябва да направи желан нов Уиндоус. Ако вместо това спре поддръжката на стария, който все още е най-разпространения й продукт, скандалът ще бъде огромен. Това би било най-добрата услуга за Мак и Линукс, която изобщо може да бъде направена. Просто няма толкова голям идиот в Майкрософт.
“при комерсиалния софтуер обаче реалното оправяне на грешки често свършва с бетите.”
Това беше едно време. Днес комерсиалния и изобщо “затворения” софтуер редовно се ъпдейтва. Всички сериозни продукти го правят. Иначе бързо губят пазарен дял.
“От по-използваните свободни софтуери вероятно всеки минава поне по три-четири пълни одита, на всеки ред сорс код, от хора, които не са сред авторите му.”
Погледни ррt презентацията на оня Линукс експерт, който работи от година в МS, Краси беше дал линк. Той говори точно обратното – имал е огромни трудности да осигури одит на софта си. Не знам дали ти си автор на популярен Линукс софт и си си осигурил няколко одита. Той обаче е такъв автор и мнението му е меродавно. В общия случай одит получаваш, ако си платиш. С изключение само на няколко проекта от сорта на Линукс кернела.
Даже в суперизвестен и популярен продукт като Мозила има брадати бъгове – погледни в Бъгзилата. Появяват се и нови, направо абсурдно тъпи. Скоро се наложи да ъпдейтвам Firefox extention, който спря да работи като излезе FF 3.0. Защото някакъв умник е сменил името на един DOM element, отговарящ за първия таб, който се създава при стартиране на браузъра, от browser на xul:browser. Това само на този таб, всичко останало се създава със старото име. И още няколко подобни изпълнения. Гледам че си седи така и в 3.5.1, сигурно вече се води feature, а не бъг.
Та имаме си extention, който благополучно си работи, докато не излезе нова щуротия в нова версия на ФФ. Програмистът, който е писал този extention, отдавна е напуснал и се занимава с други работи. Моя милост се наложи да учи от нулата ДОМ и Мозила API-та и да дебъгва куп код. Направо супер продуктивно.
Всъщност разбиването на съвместимостта със старите разширения при Мозилата вече е класика.
Вярно е че тестването продължава през целия живот на продукта но не и че при комерсиалния софтуер оправяне на грешки свършва с бетите. Изобщо не е така, сериозните фирми правят редовно ъпдейти ако има нужда. Много като че ли ги правят и без нужда, но това е друга тема. Аз по принцип съм доста консервативен към ъпдейти и никога не преминавам към нова версия само защото такава се е появила.
Тези, които четат и дебъгват сорс изобщо са много хиляди. Четенето на сорс е забавно горе-долу колкото това на телефонен указател. И аз съм поглеждал от време на време от любопитство как е направено нещо, но от четене по диагонал полза за продукта няма. Истински задълбочена проверка на чужд код (без да имаш наум конкретен бъг за оправяне) е нещо много трудно и досадно, а ако не е добре коментиран си е направо невъзможно. Не виждам някой с всичкия си да седне да прави нещо подобно нещо без заплащане.
За оправяне на конкретен бъг, вярно че ако сорса е достъпен много хора може да го оправят. Но дали ще го направят с необходимото качество и с преценка и тестване на всички последствия е друг въпрос. По скоро не, защото всички последствия е трудно да се оценят от външен човек. По-добре е бъга просто да се докладва на автора (за което сорс не ти трябва) и той да го оправи. Аз примерно много по-спокойно ще ползвам софтуер който е разработен от ясен екип, отколкото такъв в който е бърникало неясно мнозинство от ентусиасти.
Григоре,
Крайния потребител не е особено сложен и предизвикателен пазар, за разлика от копроративния сегмент. Крайния потребител не ползва активна директория и няма особено високи изисквания към сигурност и интеграция. Корпоративния потребител иска мощност, удобство, съвместимост. Линукс, колкото и да е добър и подходящ за някои неща, не може да задоволи изискванията на бизнеса за операционна система. А корпоративния потребител ИСКА да плаща – в края на краищата, Microsoft продуктите не са толкова скъпи, сравнено с продуктите на други производители.
“Ако Asus не бяха имали нахалството да пуснат Eee PC с Линукс, към момента Уиндоус XP щеше вече да е в пенсия като продажби (и твърде скоро като поддръжка), а Уиндоус 7 вероятно още нямаше да има публична бета (и може би изобщо нямаше да има).” – да, щяха да са фалирали MS, ако Асус не беше направил този “ни рак, ни риба” продукт. Отделно от дискусията, докато Intel не изкарат нещо по-сериозно от Atom, ЕЕЕ PC си е живо обирджийство.
@Господин Гюров: Фантасти са, по тази логика, и 99% от експертите, анализирали причината Майкрософт да си обърне на 180 градуса решението за XP, и за ранните, неограничени и достъпни за дълго използване бети на Уиндоус 7. Спирането на поддръжката за XP би било наистина огромен скандал, но преминаването на един сериозен бизнес от една ОС на друга е много трудно, а ако преминаването е от Уиндоус на друга, клони към невъзможното, без да загубиш много данни или процедури. Така че народът щеше с крива физиономия да се бръкне, и финансовите резултати на Майкрософт да литнат към небето. Eee PC обаче показа на практика колко удобен и приятен може да е продукт с “другата ОС”, и създаде опасност за загуба от Майкрософт на значителен по размер пазарен сегмент, а това щеше да отключи лавинообразна загуба. Затова и Майкрософт реагира толкова бързо и действено, и направи толкова отстъпки на производителите на нетбуци, ако се съгласят да изхвърлят Линукс.
“Линукс експерт, който от година работи в МС” обикновено значи точно едно нещо, което винаги е едно и също. В конкретния случай, “одит” не означава само официално мероприятие, правено от оторизирана специализирана фирма. Примерно одитът на Дебиан, правен на значително подмножество на всяка негова нова версия от МВР на Германия, се прави от вътрешни специалисти на министерството им – навън изтича само стрийм от бъгрепорти и бъгфиксове. Това не се води официален одит, въпреки че всеки нов ред код бива прекарван като през сито – значи не е правен, и бъговете са останали неоправени? Защото тяхното оправяне е от значение – одит, който е официален, но не ги оправя, струва колко?
Мозила е само един пример за свободен софтуер, и според мен най-лошият – прекалено много пара в свирката, прекалено малко в колелата. А за бъга – ти гласува ли за важността му в бъгзилата, че да имаш някакви претенции да бъде оправен? (Дали си предложил готов бъгфикс мисля, че е безсмислено да те питам. Длъжни ли са програмистите на Мозила да оправят този бъг, за да го ползваш ти?)
@Пешо: Сериозните фирми наистина правят ъпдейти при нужда. Само че “сериозни фирми” означава не повече от трийсетина, а “при нужда” означава когато на фирмата й кефне, или поредният бъг е опасен до степен да докара PR катастрофа.
За различните хора са забавни различни неща. Познавам хора, които обожават да четат и оправят сорсове на популярни програми. Че на теб това не ти е забавно – и на мен не ми е, но това не значи, че няма доста (в световен мащаб) хора, на които е. А тях ще намериш почти само в свободния софтуер, просто защото неговият сорс е достъпен за четене и оправяне.
Преценката на последствията от оправяне на бъг в софтуер в някои отношения е по-трудна за външен човек, но пък външните хора като цяло преценяват повече неща от авторите на програмата. Затова и пращането на бъгфикс е по-полезно от бъг рапорта: авторът може да не го приложи задължително какъвто е изпратен, но може да види в него аспекти на корекцията, които сам не е предвидил. В бъг рапорта тези аспекти няма как да ги има. И сравнението между Линукс и Уиндоус дава достатъчно ясна представа дали следва да се счита повече на ясен екип, дори отлични професионалисти, отколкото на неясно множество ентусиасти. Уикипедия е друг такъв пример, сравнена с Британика, примерно – надеждността на двете е сходна, но едната превишава като количество информация другата към 50 пъти… И т.н.
@Galarad: Крайният потребител рядко ползва АД, но понякога има още по-високи изисквания към сигурност от корпоративния. Корпоративният потребител иска да НЕ плаща, по възможност, и това е основното – малко са толкова “умни”, че да наблягат първо на производителност и надеждност. По мои впечатления, изискванията на бизнеси с до няколко хиляди служители чудесно се покриват от Линукс. От по-големи просто нямам опит, за да преценя; предполагам, че ако бизнесите не са с главата в пясъка, също. Гугъл, примерно?
@ Григор
Ти сериозно ли предлагаш да тръгна да правя фиксове на всеки бъгав софт от милиони редове код, до който се докосна?
Опитах се да задавам въпроси в Мозила форума и чатовете – в стая с надслов “просто попитайте и ще ви се отговори” няколко часа никой не забеляза съществуването на въпроса ми, след което си излязох и повече не влязох.
Аз поддържам развитието на десктоп приложение, което комуникира с всички известни браузъри, има Win Mobile версия и възможност за синхронизация освен с последната със Симбиан, Палм, Блякбери, а скоро и с iPhone. Не мога да се занимавам с месеци с Мозила бъговете, никой не ми плаща за това, нито ще ми остане време за нещо друго, ако тръгна да го правя.
Нямам претенции към Мозилата, това просто не е моят браузър. Почти всичко добро в него така или иначе е крадено от Опера. Давам го само като известен опън сорс пример, който противоречи на описанието ти как стоят нещата с тестовете и фиксовете в “двата свята”.
Одитът на Дебиан може да се прави безплатно от някое МВР, но това далеч не важи за всички опън сорс продукти.
А как установи, че 99% от експертите са на твоето мнение относно колосалното значение на Еее-то с Линукс?
@Господин Гюров: Сериозно ли очакваш в една организация предимно от доброволци да има непрекъснато дежурни, които да отговарят на всеки въпрос? Колко комерсиални софтуери предлагат подобно нещо? Също, за Мозила форума не знам, в него не съм питал, но обикновено където попитам нещо по подобен форум, максимум до два дни имам отговор. (Ако никой не го е питал преди мен вече – тогава може да получа само линк към първия такъв въпрос, или направо да ме оставят да се сетя първо да пробвам Гугъл, а после да питам. А ако си дам труда да го рапортувам като бъг, или ида да прегледам историята на бъга и да гласувам за него, обикновено намирам и решения.)
Апропо, колко бъга на Мозила са ти се пречнали досега, за да трябва с месеци да се занимаваш само с тях? Когато аз чистя бъгове, обикновено се справям с по десетина на ден. Ако един бъг се очаква да ти отнеме месеци, може би програмирането не е “твоят спорт”. (Надявам се да е, и просто да си попреувеличил малко периодите.)
Немското МВР не е единствената организация, която прави за свои цели одит на някой свободен софтуер. Между другото, да се прави пълен одит на Дебиан означава да се прави одит на голям процент от свободните софтуери, които съществуват. Към момента Дебиан е над 27 000 пакета, което е около 40 bzip2-компресирани CD-та. 🙂 Немското МВР, доколкото съм чувал, прави одит само на тази около една трета от него, която реално използва. Други организации обаче използват други пакети, така че одитите вероятно покриват (с различна честота) почти всичко в него.
Как установих мнението на експертите ли? Прочетох в Интернет различните мнения за какво е накарало Майкрософт да си промени така рязко политиката на бързо изхвърляне на XP, при положение, че тази промяна се очакваше да лиши компанията от приходи на очаквана стойност между 8 и 10 милиарда долара в двегодишна перспектива (по-точно до шестия месец след официалното излизане на следващата версия, Уиндоус 7 – тогава тенденцията на купуване на старата версия спада до пренебрежими стойности). Отсях мненията на “близките до Майкрософт” източници, които бълват маркетингова пропаганда, и погледнах останалите. Даже хора като Роб Ендерле си пишат направо по тая тема – щом той е казал нещо срещу Майкрософт, значи то просто няма как да бъде скрито от никого…
“Regression testing: професионалистите знаят защо!” 🙂
Ако мога да си позволя тази алюзия с известната реклама, мога да твърдя, че Open Source общностите обикновено нямат хабер от това нещо.
Те са силни на оправяне на бъгове, намерени и посочени от някого, особено такива с по-голяма “видимост” (вкл. медийна).
Което не означава, че не постигат достатъчно добро ниво на тестване. Просто се получава по друг начин: разчита се на голямата база ентусиасти, които ще пуснат поправката, и евентуално ще открият, че тя внася проблем в нещо, което е работило ОК преди. Метода на “пробата и грешката”, или още известен като “метода на многото грешки”. 🙂
Все повече ми се изяснява, че в “мача” Уиндоус-Линукс, последните губят не заради по-ниско качество на софтуера. А най-вече заради това, че Линукс са решили да започнат да “играят” много по-късно. И че никой “голям” никога не взе насериозно “войната за десктопа”. Десетилетия наред Линукс се хвалеше колко е “стабилен”, без въобще да приема насериозно идеята, че си заслужава да се “бие” и на “полето” на десктопите.
Защото се оказа, че десктопа прави много пари. Адкси много пари. Много повече отколкото “велики” сървърни софтуери на “велики” фирми като Sun, Novell, DEC, и т.н.
Просто заради фокуса си в десктопа, Уиндоус спечели битката докато Линукс “спеше” на славата си на супер стабилна ОС.
В това време бяха на написани много софтуери за Уиндоус. Друга причина е, че на прозиводителите на софтуер определено им е много по-удобно да поддържат версия само за една архитектура ОС.
Извън темата: впечатлен съм от Убунту (9.04), което успя да се инсталира без проблеми на Microsoft Virtual PC 2007. Това въпреки предупрежденията и сума ти дълги инструкции – верно, за по-ранни версии на Убунту – какво къде трябвало да пипна за да тръгне графиката. Верно, тръгва в някаква доста странна разрешаваща способност 896х600. И която да сменя под Virtual PC би ми отнело сигурно цяла вечност 🙂
@ Григор
Поразрових се малко по темата, удълженият ХР съпорт, уж заради Еее, е удължен още през 2005! Като това е редовна практика за МS, не за първи път удължават срока на поддръжка на свой продукт. Първоначалният срок (при излизане на продукта) обикновено е 5-6 години, като впоследствие търпи удължавания. Ето ги сроковете:
http://support.microsoft.com/lifecycle/?LN=en-gb&x=16&y=12&C2=1173
Mainstream Supporta наскоро е изтекъл, Extended Supportа е до 2014.
За минаването на Еее от Линукс към Уиндоус очевидно има съвсем друга причина:
http://www.liliputing.com/2009/03/linux-loses-more-netbook-market-share.html
“in many cases you can buy a mini-laptop with Windows XP for just $20 or $30 more than the Linux version, and you often get a larger hard drive in the deal.”
В коментар под подобна тема, търговец на нетбуци посочва, че са получили оферта от Майкрософт да получават ХР за тези машини по $4 (което си е направо без пари), ако го слагат на 100% от машините. End of story.
Оправяш по 10 бъга на ден в огромен, комплексен софтуер, в чието писане не си участвал и сефте започваш да се занимаваш с него? Браво на теб, аз не мога така. Ако оправя 10 бъга така, сигурно ще вкарам поне 20 нови. А пък след като продължават да ми плащат за това, което върша (на време, което аз рапортувам, и се приема на доверие), явно не съм някакво некадърно изключение сред програмистите.
Във форума един човек ми отговори. Отговорът му беше, че със С++ extensions почти никой от пишещите там (във форума) не се занимава (JS хора били), и да питам в чата, където имало такива специалисти. Все пак по аналогия ме наведе на една идея, за което съм му благодарен. А какво стана в чата вече писах.
Но да оставим Мозилата, да вземем другия всеизвестен флагман на опън сорс десктоп продуктите – Опън Офис. Вече писах някои неща за преживяванията си с него в другата тема. Версия 2.4 имаше следното загадъчно поведение: като натисна Save, процесорът ми се натоварва на 100% за 10-15 сек., без ОО да показва, че прави нещо. Ако натисна Х бутона (Close) през това време, ОО се затворя безмълвно, и при следващото стартиране установявам, че всички промени във файла ми са изчезнали! Т.е. той не е бил записан изобщо. Наложи се да си пускам таск мениджъра и след запис да гледам кога ще падне до нулата ЦПУ натоварването, та чак тогава да затворя ОО, след като съм си свършил работата с него.
Във версия 3.0 пък се появи описаният в другата тема ефект с изчезването на макросите след записване. Добави и неща като онова с десетичната запетая. Това е много тежка симптоматика – говорим за продукт на много години, с няколко major releases. Явно и той се пише от хора, които “оправят по 10 бъга на ден”. И минава през редовни одити на всеки ред.
@Galarad: Крайният потребител рядко ползва АД, но понякога има още по-високи изисквания към сигурност от корпоративния. Корпоративният потребител иска да НЕ плаща, по възможност, и това е основното – малко са толкова “умни”, че да наблягат първо на производителност и надеждност. По мои впечатления, изискванията на бизнеси с до няколко хиляди служители чудесно се покриват от Линукс. От по-големи просто нямам опит, за да преценя; предполагам, че ако бизнесите не са с главата в пясъка, също. Гугъл, примерно?
Григоре,
Като си говорим за корпоративен потребител и двамата сме наясно, че Български корпорации все още няма? Тук при нас има само представителства на западни корпорации и всички те имат ясен модел на поведение – купувай скъпа фирмена техника, купувай лицензен софтуер, разчитай на проверено и работещо, а не на бляскави аматьори и т.н. Защо се купува толкова CISCO – щом като същия ефект може да се постигне с Линукс рутер (понякога – десетки пъти по-евтино)? Ми защото парите не са от значение в случая, купувайки CISCO/MS получаваш провереност, стабилност, производителност, съвместимост, разширяемост, море от СТАНДАРТНО подготвени хора за поддръжка и обслужване. Не казвам, че аз смятам това за правилно, но това е реалността.
“По мои впечатления, изискванията на бизнеси с до няколко хиляди служители чудесно се покриват от Линукс.” – ами ето ти предизвикателство, разпиши една ИТ инфраструктура изцяло под Линукс. Заданието е:
– Терминален сървър на който върви интегрирана система за управление на бизнеса, която система трябва да има версия за Линукс и цена ~100к Евро
– Пощенски сървър с collaboration tools към него, интеграция на офис пакета с мейл клиента
– Активна директория или неин аналог за централизирано управление на 200 компютъра – политики за сигурност и достъп, single sign-on, управление на печат, roaming профили
– Road warrior лаптопи – постоянен достъп до корпоративната мрежа през Интернет, синхронизация на данните
– Система за управление на ъпдейтите на десктоп и сървър машините
– Десктоп машините трябва да имат възможност да правят OCR на кирилица, някои от тях трябва да ползват DTP софтуер, други – електронно банкиране и фискални принтери
– Бекъп решение за базата данни, пощенския сървър, профилите и данните на потребителите, системните настройки на сървърите
Добави ако съм пропуснал нещо – примера не е реален и си го измислих на момента. Как това може да се създаде, поддържа и развива под Линукс – колко време ще е необходимо, за да се изпълни; какво ще правим, ако дойде някаква нова версия на комерсиален софтуер, която не сме предвидили или устройство, за което няма още драйвери?
За Гугъл няма смисъл да коментираме, както и примерно за IBM – те имат ресурсите да ползват каквото си поискат – и като хора и като софтуер; каквото си нямат ще си го създадат сами.
Няма как да подмина такова несериозно изказване, най-вече защото уважавам Григор и читателите му. НЯМА комерсиален софтуер, при който да липсва екип по поддръжка, или поне част от работата на основния екип да не е по поддръжката. Писал съм софтуер и в малка фирма, и в средноголям проект, и в Dynamics AX. Несериозно е да се твърди, че “често” “реалното оправяне на грешки” свършвало с релийза. Григор, отдавам това ти мнение на факта, че поради естеството на работата и сферата ти, не познаваш и не си запознат с Application Lifecycle Management циклите на комерсиални проекти.
…и ето тук се чупи прекрасния мит за бързия, светкавичен съпорт. Факт е, че повечето бъгове там се оправят от външни за проектите хора, т.е. за да разчиташ на бърз съпорт на такъв продукт или трябва да имаш свой екип разработчици, познаващ добре продукта и развиващ го, или трябва да си много голям, или бъгът трябва да е с много лош PR. Понеже безплатността е също така и отказ от отговорност, повечето компании предпочитат да си платят, но и да получат. И поради това “десетки” ( 🙂 ) години вече няма читав конкурентен бизнес модел, базиран на тези продукти.
@Красимир Гаджоков: Нямам представа защо си решил, че програмистите на свободен софтуер нямат представа от regression testing. OpenBSD проектът реално е сглобен около методиката им на тестване (и резултатите като сигурност са наистина впечатляващи – общо 1 вътрешен за проекта експлойт за 7 години, а проектът хич не е малък). В оправянето на бъгове обикновено програмистите на свободни софтуери са силни (и бързи) в оправянето на бъгове, които са реално опасни, или не са, но засягат тях лично. Което прави някъде по-бързо и по-добре от несвободния софтуер, някъде по-бавно и по-зле, но като цяло за по-важните неща е по-бързо, и често и по-добре.
Иначе си прав – от “големите” допреди по-малко от десет години никой не взимаше въобще Линукс насериозно за нищо, което би ги накарало да пишат сериозно код за него, и да го правят удобен за потребителя. Всички си падаха само по безплатното използване. И понеже зад Линукс не стои корпорация с амбиции за господство, никой въобще не се е замислял къде и за какво той си струва да се сражава – просто всеки е правел каквото е било полезно и удобно за лично него си.
@Господин Гюров: Съпортът на XP някъде през 2007 г. беше рязко съкратен, той беше изтеглен от всички пазари освен от OEM-а, закъдето имаше крайна дата за продажби някъде в началото на 2008. След това крайната дата беше удължена до юни 2008, след това премахната, а след това тихомълком XP се появи отново на пазара на лицензи, уж “нелегално” (аз лично си направих гаврата да уведомя Майкрософт България, че куп големи фирми продават не-ОЕМ лицензи за XP – като ги попитах дали не е забранено още от началото на годината, те ми се смяха от сърце). Mainstream съпорта още не е изтекъл, и доколкото разбирам, няма да изтече скоро. 🙂
Информацията за причината на загубата на пазарен дял за Линукс в нетбуците съвпада точно с написаното от мен. Това за цената от $4 за XP, ако производителят го слага на 100% от нетбуците, е само половината инфо – другата половина е, че ако го слага не на 100%, а на само 99% от нетбуците, цената става над $60 на лиценз. Както му харесва. Нищо лично, просто бизнес. Уиндоус се продава повече, защото хората не искат Линукс, понеже е по-лош. И т.н.
За бъговете – свободният софтуер обикновено се пише така, че да е четивен (и да, ако ми е напълно непознат, няма да мога да оправям по 10 бъга на ден). Наскоро имаше едно интервю с Харалд Велте, покрай проекта му gpl-violations.org. Питаха го колко код е добавила инициативата му към свободния софтуер – той каза: “Николко. Страшно много код премина под GPL, но когато го отвориха и погледнахме, никой не поиска да вземе и една функция от него, толкова зле написан е. Единствено драйверите стават, да гледа от тях човек как се управлява съответният хардуер, докато пише свой драйвер.” Има, разбира се, и фрапантни изключения, дори сред големите проекти – но правилото е, че от първите хиляда фирми за комерсиален софтуер не повече от 20-30 пишат изходен код с качеството на този примерно на ядрото Линукс. (В интерес на истината, Майкрософт са между тях.)
За бъга на ООо от 2.4 – чувал съм за него, опитвал съм се да го повторя, не се е получавал при мен, нито под Линукс, нито под Уиндоус. Също не съм виждал да ми изчезват макроси след записване (а използвам и пиша макроси). А това с десетичната запетая се решава с настройването на локал в настройките, точно както под Уиндоус – оплаквали са ми се от него, показвал съм къде се настройва (на логичното и очевидно място), проблемът е изчезвал. Ако аз съм девелопер, в моите очи това са два несъществуващи проблема и един проблем със задклавиатурното устройство. Как да ги оправя? Да бях успял да ги повторя, разбирам – но поне дай повече инфо!
@Galarad: От описанието ти за система не мога да разпиша на секундата единствено решение за OCR на кирилица (мога, но като го гледах преди година, беше калпаво). А, и решение за бизнеса на цена около 100К евро за Линукс ми е трудно да ти намеря – SugarCRM е безплатен… Какво ще кажеш да ти го препродам за 100К евро? 😉
Мога да добавя и още доста неща. Не мога да ти подсигуря на Линукс единствено случаи, когато клиентът работи с програма, написана само за Уиндоус, ползваща чрез вграден в нея драйвер нестандартен хардуер, или недокументирани API-та на Уиндоус, или смотани защити (които обикновено са проблем и под Уиндоус, ако тази програма не е единственото нещо на компютъра). И всичко това при положение, че аз въобще не съм бог на Линукс – обикновен любител съм, понаритан от занаята си да понаучи как се решава този или онзи проблем чрез него. Познавам доста професионалисти, способни да ме сложат в малкото си джобче: за тях задачата ти сигурно би била еднакво елементарна и под двете ОС.
@Дончо: Има много такива комерсиални софтуери. Проблемът е, че си работил само в свестни софтуерни фирми, и нямаш наблюдение колко маймунски се поддържат немалко известни и популярни несвободни софтуери… Не че със свободните е различно – но там поне обикновено е публично и се знае кое как се поддържа, така че още отначало можеш да направиш информиран избор. Иначе, занимавам се с поддръжка на компютри от 8 години, а с писане на софтуер под някаква форма съм се занимавал почти 20 години преди това (и в по-малка степен продължавам и сега). Знам наизуст стандартните модели на ALM. Но знам и колко и как се спазват реално.
Реално, опровергаването на светкавичния съпорт на абсолютно всеки бъг е straw man bashing. Никой нормален от свободния софутер няма да ти гарантира подобно нещо. Всеки ще ти каже, че незначителни бъгове могат да персистират с години, и че бързо се оправят реално важните бъгове. (Между другото, в различните проекти се оправят от вътрешни за проектите хора между 70 и 100% от бъговете. Почти не ми е известен свободен проект, в който да се оправят от външни хора над 40% бъговете.) PR-ът на бъга обикновено е без никакво значение, освен ако проектът не е под пълния контрол на голяма корпорация, примерно OOo – от значение е дали бъгът не е реално неприятен. Ако обаче е, обикновено го оправят до няколко часа.
Колко комерсиални софтуери се справят за това време? Има ги, но са единици. И като правило са миниатюрни проектчета, стотици и хиляди пъти по-малки от примерно ядрото, или големите десктопи, или GNU toochain-а. Единствено антивирусаджиите добавят дефиниции със скоростта на свободните проекти при важен проблем. И затова имат уважението ми.
полезна статия
@ Григор
“Съпортът на XP някъде през 2007 г. беше рязко съкратен”
Откъде е тази информация, можеш ли да посочиш официален източник? Струва ми се крайно съмнителна. Не говорим за изтегляне на продукта от продажба, а за ПОДДРЪЖКА. Значи през 2005 я удължават, през 2007 я съкращават, а през 2008 я удължават отново? Сори, но това докато не го видя черно на бяло от официално място, не го вярвам.
Нищо подобно не чета тук (April 13, 2009):
http://www.computerworld.com/s/article/9131505/Microsoft_moving_XP_into_reduced_support_phase
“Microsoft’s mainstream support, which is usually offered for only five years, actually ran seven and a half years because of the long lag between XP and its successor, Vista. Two years ago, Microsoft also extended mainstream support for XP Home and XP Media Center until 2009, and pushed back the deadline for the follow-up phase, dubbed “extended support,” until 2014, to match the dates that had been set earlier for the business-grade XP Professional.”
Mainstream Supporta е приключил (през април тази година), както писах и предния път, а преди 2 години (т.е. точно през 2007) е бил УДЪЛЖЕН за Home и Media Center, за да отговаря на по-раншното (мисля че става дума точно за това от 2005 г.) удължаване на срока на Professional версията.
“Как да ги оправя? Да бях успял да ги повторя, разбирам – но поне дай повече инфо!”
Не го вземай толкова лично де 🙂 Говорим по принцип за качеството на софта. Ако наистина държиш да се занимаваш с бъга в 2.4, можем да организираме нещо. Не съм сигурен в 3.0 дали го имаше същия проблем с ЦПУ натоварването при запис, или само новопоявилия се ефект със забърсването на макросите (изхвърлих го доста бързо от компа си та не помня вече).
За проблема с десетичната запетая, вече писах в предната тема. Първото място, където погледнах, бяха сетингите естествено. Там такова нещо нямаше (през цялото време говоря за Уиндоус версията, за другите не знам), или е било скрито прекалено добре. Имаше едно поле със запетая в него, но то не промени нищо, а и пояснителния текст там казваше, че е за нещо друго (не помня вече какво точно).
Това далеч не бяха единствените проблеми с ОО, просто тези са ми най-пресни в паметта. Сигурен съм, че ако се заровя в продукта, бързо ще излязат още поне 100 други. Неведнъж ми се е случвало например да виждам некоректно показвани на места doc файлове.
Знам че не е лесно да се направи продукт, съвместим с чужди формати данни. Писал съм мултиплатформен rtf конвертор към комерсиален офис пакет за мобилни устройства, а колегите там още преди това бяха направили конвертор на doc файлове. Това за doc-a си е чисто хакерство (в добрия стар смисъл на думата, не в днешното й изкривяване) и дълбоко го уважавам. Бяха го направили и работеше – даже на малките екранчета на мобилните устройства документите излизаха съвсем прилично.
Случаят с ОО (давам го само като пример по темата, не като повод да почнем да го оправяме сега) обаче доста се разминава с твърденията ти тук. Пише се от повече от десетилетие, опън сорс е от 9 години, един от двата най-известни (и вероятно най-разпространени) опън сорс продукти изобщо, т.е. постоянно е в центъра на вниманието – и каква е реалността? БЪГОВЕ ПРИ ЗАПИСА НА ДАННИ. Една програма за обработка на данни, ако не може да гарантира даже коректния запис на тия данни, за какво е? Как е тествана тая програма, и как подобен бъг си седи с месеци, ако не и с години? За това ставаше въпрос. Ясно че ти лично като не можеш да го възпроизведеш, няма как да го оправиш. Фактът е, че системата на тестване и фиксване при тоя продукт не работи добре.
Аз не мога да тегля такава черта и да кажа, опън сорс продуктите се тестват по-добре или пък затворените продукти се тестват по-добре. Всичко опира до екипа, който стои зад конкретния продукт. Да се разчита на външни ентусиасти днес – през 2009 г. – не става. Продуктите станаха прекалено грамадни и сложни и това просто не работи.
Когато Нетскейп беше трансформиран в опън сорс продукт, в опит да бъде спасен, това просто не стана. Години наред той не получи почти никакво внимание от външни програмисти и си остана дело на вътрешния екип. Помня отвореното писмо на един от създателите на браузъра, когато той обяви своето напускане на проекта. Обясняваше защо битката срещу ИЕ е била загубена (технологичната страна на въпроса, не онова със съдебните дела) и др. неща, като ми се е запечатала в съзнанието една негова знаменателна мисъл (цитирам приблизително, по памет, и няма да прозвучи толкова добре като оригинала на английски, но не мога да го намеря сега):
“Някога Нетскейп беше страхотен, защото ние, работещите в него, искахме да направим фирмата велика. После Нетскейп западна, защото в него дойдоха хора, които идваха, за да работят във велика фирма.”
@Господин Гюров: Бъгът от 2.4 вероятно вече не съществува. Но по принцип, ако искаш един бъг да бъде отстранен, давай заедно с него достатъчно информация, за да бъде повторен. Ако напишеш само “като пусна програмата Х, и забива”, не очаквай от това да има полза. 🙁
За “БЪГОВЕ ПРИ ЗАПИСА НА ДАННИ” – такива твърдения се подкрепят с факти. Това, че няма 100% съвместимост с Майкрософт Офис, не значи нищо – дори MSO няма 100% съвместимост със себе си между версиите. Оттам и тръгва проблемът: .doc форматът не е официално документиран, информацията за него идва от дебъгване на файлове, правени от MSO. Различните версии пишат леко различни, и не винаги съвместими формати. Не виждам как това може да бъде отстранено като проблем без официална дефиниция на .doc.
Иначе, системата на фиксиране и тестване на повечето свободни софтуери е една и съща – първо се оправя каквото е важно, или каквото е по душа на девелопърите. Точно при ООо обаче не е много представителна. Сън Майкросистемс, които контролират ООо, изискват от контрибуторите да прехвърлят копирайта върху приносите си на Сън, което е адски лош ход за свободен проект. Съответно, външните приноси към ООо клонят към нула. Оттам нататък, ООо се оказва свободен проект, който обаче е дело изцяло на корпорация, без въобще да й е сред приоритетите. Съответно, оправянето на бъговете получава доста малко ресурси, и по-дребни бъгове се оказват зарязани в течение на години. (Може би трябва да пренапиша за тук един мой стар анализ върху икономиката на свободния софтуер: той обяснява доста неща.)
Ако кодът на продукта е правилно структуриран, размерите му нямат значение. Ядрото е приблизително с размерите на ООо, и е много по-омотан и вътрешно обвързан тип софтуер, отколкото офис пакет, но въпреки това в него можеш да пишеш своето си модулче, и няма да има проблем то да се интегрира в цялото. Разбира се, ако един продукт е зле проектиран и реализиран като структура на кода, това не важи. Но мисля, че проекти могат да се правят с голямо участие на външни ентусиасти, или дори изцяло от тях, и ще могат докато има програмиране във вида, в който е днес.
Нетскейп загуби битката по две причини: че се мереше точно с Майкрософт, и че беше технически здравата оплескан проект. А беше технически здравата оплескан по причината, която цитираш. (Аз й казвам по-иначе: един продукт е велик, докато хората, които го правят, работят с идеята да го направят велик. Почнат ли хората в него да мислят за това те да са велики, продуктът се скапва. Впрочем, това важи за горе-долу всяка дейност, независимо дали е бизнес, изкуство, наука…)
Нещата са доста по-комплексни от описаните. Въпреки, че съм съгласен с голяма част от нещата, те са верни и за опреден кръг от потребители и доставчици на софтуер. Доста сериозно се коментира удължаването на срока за поддръжка на XP, но забелязвам, че липсва една много сериозна причина – при голяма част от големите клиенти (фирми с по 10 000+ работни места) мигрирането на операционна система и/или приложения е дълъг, трудоемък и най-вече много скъп процес. Причините са много и комплексни:
1. Обучение на персонала
2. Обучение на Help Desk
3. Тестване на всички приложения използвани от организацията дали ще работят с новите системи
4. Тестване и донастройване на собствените приложения
Относно коментарите – отворени с/у затворени операционни системи – все повече от големите производители на софтуер поддържат за основните си продукти и отворени платформи, но само такива, за които седи ясна комерсиална организация за поддръжка. И IBM и HP и Oracle и много други предлагат софтуер-а си за Linux„ но сертифицираните и поддържани платформи са предимно – RedHat и SuSE – просто защото там има начин да се контролират истински нещата с новите версии и за отстраняване на проблеми. Когато имаш “малка фирма” с 5-10-20 сървъра и относително стандартни приложения – шансът да имаш проблем е много по-малък отколкото ако имаш 100-200 сървъра различни приложения и един “малък” ъпдейт на системите направи 1/2 приложения неработещи.
А ето правилното отношение 🙂
http://vbox7.com/play:804b551f