Думаю, усі читали розповідь про іконку для програм Google у iPhone. Однак, виявляється, Стів Джобс завжди надавав великого значення найменшим деталям своєї системи. Ось історія, що сталась під час роботи над першими Макінтошами (оригінал):

Кріс Еспіноза (Chris Espinosa) був одним з найперших і наймолодших працівників — він приєднався до компанії коли йому було 14. У 1978 році він лишив Apple, поступивши до коледжу у Берклі, однак продовжував виконувати певні завдання у якості позаштатного робітника. Так, наприклад, він написав довідникові матеріали до Apple II.

Влітку 1981 року Стів Джобс умовив Кріса кинути коледж та повернутися до роботи над Маками у повну силу. Основним аргументом було те, що навчання ще можна буде продовжити коли-небудь потім, а Макінтош треба завершити зараз. Кріс кинув коледж та з серпня 1981 став головним технічним письменником (manager of documentation for the Macintosh).

Нам була вкрай необхідна технічна документація, бо вже через кілька місяців планувалось залучення до роботи сторонніх розробників. Найбільш важливою частиною системи Macintosh була графічна бібліотека QuickDraw, тому Кріс вирішив почати з неї.

Для того, щоб краще зрозуміти роботу графічної системи, Кріс зібрався написати невелику демонстраційну програму. Йому дуже подобалась ідея створення віджетів робочого столу (”desktop ornaments“). Для реалізації цієї ідеї було вирішено написати віджет-калькулятор.

Через якийсь час програму було написано. Кріс був цілком задоволений тим, як вона виглядала, однак останнє слово мав сказати сам Стів Джобс — він слідкував за розвитком естетики системи.

Під час демонстрації ми зібрались навколо і, затамувавши подих, чекали на реакцію Стіва. “Що ж, для початку непогано” — промовив він. “Але в цілому це відстій. Фоновий колір занадто темний, деякі лінії не тієї товщини, кнопки завеликі”. Кріс пообіцяв Стіву, що вдосконалюватиме програму, доки її не буде погоджено.

Наступні кілька днів пройшли так: Кріс втілював вимоги Стіва, однак той щоразу прискіпувався до чогось іншого. Програму доводилось переробляти, узгоджувати і знову переробляти.

Нарешті Крісу це набридло. Він вирішив спробувати інший підхід — “нехай Стів сам зробить, що йому треба”. Для кожної вимоги щодо інтерфейсу калькулятора було створено відповідну менюшку. Можна було обирати товщину ліній, розмір кнопок, фон та інші речі.

Побачивши нову розробку, Стів одразу ж почав гратися з параметрами. Через десять хвилин він таки скомпонував щось таке, що його влаштувало. Кількома місяцями пізніше ми зробили реальну програму-калькулятор відповідно до цього дизайну. Ця програма пробула стандартним калькулятором для Макінтошу багато років аж до появи OS 9.

Переклад статті “C++ Compilation Speed“. Кроспост на розробці

Люди часто скаржаться на те, що написаний на C++ код вимагає надто багато часу для компіляції. Настільки багато, що іноді повну збірку великих проєктів доводиться відкладати на ніч.

Повільна компіляція навіть стала однією з причин появи мови Go. Я уже досить давно займаюсь розробкою компіляторів і ця проблема не давала мені спокою. Чому все так довго? Розробники компіляторів C++ — професіонали своєї справи, тому, скоріше за все, причину слід шукати у самій мові програмування. Швидкість роботи різних компіляторів дуже відрізняється, але програми, написані на інших мовах програмування, компілюються однозначно швидше.

Я займаюсь розробкою компіляторів для C++ з 1987. Комп’ютери у ті часи були значно повільніші, ніж зараз, і проблема швидкості компіляції стояла дуже гостро. Чимало часу було витрачено на профілювання на дослідження причин повільної
роботи.

Отже, основними причинами є:

1. Сім фаз трансляції. Вони перераховані у стандарті C++98, пункт 2.1:

• Конвертування триграфів та кодів символів
• Обробка екранованих символів
• Виділення частин, що підлягають обробці (preprocessing tokens, C++98, пункт 2.4)
• Виконання директив препроцесора; розгортання макросів;
• Читання підключених (#include) файлів та пропускання їх чераз попередні фази.
• Конвертування символів всередині строкових та символьних констант
• Поєднання строкових констант
• Виділення мовних одиниць (ідентифікаторів, операторів, ключових слів тощо; англ tokens, C++98 2.6)

Деякі фази можна комбінувати, але все одно вихідний код доводиться проходити не менше трьох разів. Принаймі, мені ніколи не вдавалося впоратись менше, ніж за три проходи. Водночас, для правильно спроектованих мов досить лише одного проходу.

У C++0X ситуація стала ще гірше: там додали так звані “чисті” рядки (raw string literals) всередині яких триграфи та екрановані за допомогою ‘\’ символи мають бути збережені.

У C++0x Standard 2.14.5-4 наведено наступний приклад:

const char *p = R"(a\ b c)"; assert(std::strcmp(p, "a\\\nb\nc") == 0);

2. Кожна фаза залежить від результатів попередньої. Наприклад, немає надійного способу виділення і пошуку підключених файлів, для того щоб асинхронно їх читати. Також компілятор не може глянути вперед, щоб визначити, чи знаходиться даний конкретний триграф всередині чистого рядка. Усі триграфи потрібно конвертувати, при цьому запам’ятавши їх позиції на випадок, якщо щось треба буде повернути назад. Єдиний можливий спосіб розпаралелити процес компіляції — на найвищому рівні, як це робить make з опцією -j.

3. #include передбачає саме вставку тексту, а не результатів обробки, тому компілятору доводиться весь час
обробляти ті самі файли, якщо їх було включено повторно (навіть якщо там був #ifdef). Можливо, десь у стандарті і була згадка про те, що це необов’язково, але я не знаю жодного компілятора, який би так працював.

4. Зазвичай люди включають усі можливі заголовочні файли, що додає компілятору купу зайвої роботи. Підключення стандартної бібліотеки, наприклад, означає, що до вашого коду буде додано ще 37687 рядків з 74 файлів (це не враховуючи повторні включення). Шаблони та розповсюдження ідей узагальненого програмування ще більш погіршують ситуацію.

5. Значення будь-якої синтаксичної та семантичної одиниці залежить від коду, що був до неї. Немає жодного елементу, незалежного від контексту. Відповідно, немає можливості проводити попередню обробку заголовочних файлів — для цього треба обробити інші підключені файли. Хедери можуть мати інший зміст, коли їх підключають повторно (ця особливість іноді використовується)

6. Через причину, вказану у попередньому пункті, компілятор не може використати результат обробки підключеного файлу для компіляції інших одиниць трансляції (одиниця трансляції — це один cpp-файл; в результаті його обробки eтворюється один об’єктний файл. Згодом з купи об’єктних файлів лінкер ліпить програму) з таким самим #include. Завжди доводиться усе повторювати спочатку.

7. Оскільки різні одиниці трансляції компілюються окремо, часто вживані однакові шаблони генеруються багато разів. Лінкер потім прибирає увесь код, що дублюється, але краще було б взагалі не витрачати час на його генерування.

Прекомпільовані заголовочні файли (precompiled headers) частково вирішують вказані проблеми, але при цьому порушуються вимоги стандарту. Наприклад, передбачається, що при повторному включенні хедер матиме той самий зміст (що насправді не гарантується, варто про це пам’ятати).

Буде дуже важко виправити усі ці вади і при цьому не порушити сумісність з уже написаним кодом. Можливо, вдасться чогось досягти у стандарті, що прийде на зміну C++0X, але це буде ще років через десять.

А поки що все дуже сумно. Експортовані шаблони (export templates) застаріли і не підтримуються, прекомпільовані хедери не відповідають стандарту, imports не затверджені у C++0X… Тому єдиним дієвим способом прискорення є використання make -j.

Уявіть, наприклад, що ви тестер і маєте перевірити роботу програми з усіма можливими версіями Qt від 4.4.3 аж до 4.7 . Або вам просто хочеться у новенькій убунті вести розробку під якусь стародавню систему, у якій нічого більшого ніж 4.4.3 немає. У цьому пості я спробую зібрати докупи усю інформацію, яка знадобиться для вирішення таких ситуацій.

Коли бінарному файлу потрібно буде завантажити динамічну бібліотеку, то її шукатимуть у наступних місцях:

1) За значенням RPATH бібліотеки, у якій було знайдено залежність (якщо ця залежність у бібліотеці)
2) За значенням RPATH виконуваного файлу
3) у директоріях, перелічених у змінній оточення LD_LIBRARY_PATH
4) За значенням RUNPATH виконуваного файлу.
5) /etc/ld.so.cache — кеш бібліотек, сформований ldconfig
6) у стандартних директоріях, призначених для зберігання бібліотек (/lib та /usr/lib)

RPATH

RPATH — це список каталогів, розділений двокрапкою. Лінкер записує його у певне місце виконуваного файлу (або динамічної бібліотеки).

Дізнатися значення RPATH можна за допомогою команди readelf:

bear@bear-VB:~$ readelf -d /usr/bin/qtcreator | grep RPATH
0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib/qtcreator]

Тут $ORIGIN — директорія, у якій лежить виконуваний файл.

Так же само можна подивитися значення RPATH для динамічних бібліотек

bear@bear-VB:~$ readelf -d /usr/lib/qtcreator/libExtensionSystem.so.1.0.0 | grep RPATH
0x0000000f (RPATH) Library rpath: [$ORIGIN/../lib/qtcreator]


Під час компіляції значення RPATH можна встановити за допомогою опції -rpath

bear@bear-VB:~/temp/dlp/cprog$ gcc cmain.c -o cprog -Wl,-rpath,/home/beardog/lib/
bear@bear-VB:~/temp/dlp/cprog$ readelf -d cprog | grep RPATH
0x0000000f (RPATH) Library rpath: [/home/beardog/lib/]

Крім того, в Debian та його нащадках є програма chrpath, призначена спеціально для того, щоб переглядати та змінювати RPATH. Типу

bear@bear-VB:~/temp/dlp/cprog$ chrpath -l ./cprog
./cprog: RPATH=/home/beardog/lib/
bear@bear-VB:~/temp/dlp/cprog$ chrpath -r /home/bd/lib ./cprog
./cprog: RPATH=/home/beardog/lib/
./cprog: new RPATH: /home/bd/lib
bear@bear-VB:~/temp/dlp/cprog$ chrpath -l ./cprog
./cprog: RPATH=/home/bd/lib

В принципі, використовувати RPATH у реальних системах не рекомендують, хоча для деяких не дуже складних ситуацій цей варіант може виявитися найкращим.

LD_LIBRARY_PATH

LD_LIBRARY_PATH — змінна оточення, що містить список директорій, розділених двокрапкою. У реальних системах її також не рекомендують (ще тут) використовувати, однак для розробки і тестування цей спосіб є найзручнішим. Очевидна перевага — можливість налаштувати запуск конкретної програми, не змінюючи при цьому саму програму і процес її створення.

Є можливість не встановлювати змінну оточення, а передавати безпосередньо завантажувачу як опцію командного рядка. Типу
bear@bear-VB:~$ /lib/ld-linux.so.2 --library-path /home/bearbog/lib /bin/echo ssss
ssss

RUNPATH

В принципі, RUNPATH — це ще один варіант RPATH, просто з міркувань безпеки його перенесли на крок назад.

Для читання можна використовувати той же readelf. Для встановлення під час створення програми треба передати лінкеру ті ж опції, що й для RPATH, і ще додати –enable-new-dtags. Особисто я так і не зрозумів, що робить ця опція; скоріше за все, буде одночасно встановлено і RPATH, і RUNPATH.

bear@bear-VB:~/temp/dlp/cprog$ gcc cmain.c -o cprog2 -Wl,-rpath,/home/bd2/lib/,--enable-new-dtags
bear@bear-VB:~/temp/dlp/cprog$ readelf -d cprog2 | grep -e "RPATH" -e "RUNPATH"
0x0000000f (RPATH) Library rpath: [/home/bd2/lib/]
0x0000001d (RUNPATH) Library runpath: [/home/bd2/lib/]

Кеш бібліотек.

Це якраз той спосіб, що зазвичай використовується у більшості дистрибутивів. Суть у тому, що є такий собі файл /etc/ld.so.cache; він містить інформацію про місцезнаходження усіх динамічних бібліотек, що знаходяться у системі.

Формується цей файл утилітою ldconfig. Теоретично, під час кожного запуску системи ldconfig має читати з текстового файлу /etc/ld.so.conf список директорій, у яких можуть знаходитись бібліотеки, переглядає їх і запам’ятовує, шо де лежить. Насправді все трохи складніше: /etc/ld.so.conf містить лише інструкцію про те, що шляхи до бібліотек потрібно взяти з текстових файлів, що знаходяться у /etc/ld.so.conf.d/. Ось як це виглядає в Убунті:

bear@bear-VB:~/temp$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
bear@bear-VB:~/temp$ ls /etc/ld.so.conf.d/
GL.conf i686-linux-gnu.conf libasound2.conf libc.conf
bear@bear-VB:~/temp$ cat /etc/ld.so.conf.d/i686-linux-gnu.conf
# Multiarch support
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
bear@bear-VB:~/temp$ cat /etc/ld.so.conf.d/libasound2.conf
/usr/lib/alsa-lib


ldconfig -p виводить список усіх зареєстрованих бібліотек.

bear@bear-VB:~/temp/dlp/cprog$ ldconfig -p | grep QtXml.so
libQtXml.so.4 (libc6) => /usr/lib/libQtXml.so.4
libQtXml.so (libc6) => /usr/lib/libQtXml.so

Очевидно, що основним недоліком ldconfig є те, що налаштування відбувається одночасно для всієї системи. Взагалі це добре, але якщо треба запустити одночасно пару програм з різними версіями бібліотек, доводиться шукати інші шляхи.

Інші речі, про які треба знати

Існує ряд змінних оточення, що можуть суттєво вплинути на поведінку завантажувача. Частина
з них перелічена у man ld-linux, частина у man ld.so, частина ще десь . Наприклад, якщо задати змінну LD_RUN_PATH, то її значення буде використано замість RPATH виконуваного файлу (не перевіряв, можливо, це відбуватиметься лише у випадку, коли rpath для виконуваного файлу не задавався).

Змінна LD_PRELOAD (а також, можливо, файл /etc/ld.so.preload) може містити список бібліотек (файлів, а не директорій, як у попередніх випадках), які обов’язково мають бути завантажені до початку виконування бінарного файлу. Між іншим, саме таким чином рекомендують використовувати гугловий профайлер

LD_DEBUG може приймати значення “all”, “files” або “help”. Коли вона встановлена, /lib/ld-linux.so.2 починає видавати купу всякої інформації про те, які бібліотеки було завантажено для даного файлу.

Ще слід пам’ятати, що для set-user-ID/set-group-ID binaries (грубо кажучи, “програми, запущені з-під sudo”) більшість змінних оточення буде проігноровано.

Доброго вечора, любі хлопчатка і дівчатка, зара я вам розкажу, як задавати іконки для ваших програм під Symbian.

На перший погляд, усе дуже просто. Треба лише додати у pro-файл рядок типу такого:
ICON = images/my_icon.svg
Але не варто розслаблятися, фінські хлопці приготували кілька неприємних сюрпризів.

Іконка може бути лише у форматі SVG. Всякі там PNG, JPEG та інші бітмапи не допускаються. Більше того, це має бути не просто svg, а SVG-T (також відомий як SVG Tiny). Фактично це підмножина тегів основного стандарту, існує воно у двох варіантах: 1.1 та 1.2. Який з цих варіантів підтримується нокієськими телефонами — не ясно, цілком можливо, що це залежить від моделі телефону. У нокії на сайті є документ, присвячений цьому, але він дуже-дуже старий.

Якщо у вас є якісь зображення png або jpeg, можете спробувати їх переконвертувати у svg. Інструкції тут, тут і ще ось тут, успіх не гарантується. Конвертування векторного малюнка у растровий — взагалі досить складна задача.

Дуже мало програм вміють працювати з SVG. Ось вони:

• Adobe Creative Suite — уміє конвертувати та зберігати у потрібному форматі. Коштує дофіга бабла
• Inkscape — опенсорсний. Виглядає підозріло, експортувати у SVG-T не вміє. Крім того, шматочки цієї програми у кращих опенсорсних традиціях існують окремо у вигляді клонів, бібліотек, утиліт командного рядка тощо.
• SVG Pony — невеличка утилітка, призначена спеціально для створення іконок під Symbian. Уміє все, коштує десять євро
• У старих версіях середовищ розробки для Symbian були якісь засоби для конвертування. Але у новій Nokia Qt SDK їх уже немає
• Ось ще якась програма, призначена для конвертування. Не пробував.
• а ще можна самому все написати у текстовому редакторі. Врешті решт, svg – це всього лише xml з досить простим синтаксисом.

Важливо: ваш svg повинен рендеритися у розмір 44х44. Наприклад там мають бути атрибути width="44px" height="44px" або щось типу того. Інакше можливі невідомі баги.

Крім того, треба пам’ятати, що Symbian кешує іконки, і цей кеш майже не оновлюється. Щоб протестувати нову іконку, вам доведеться:

• відключити телефон від комп’ютера (не факт що це обов’язково, але …)
• видалити стару версію програми
• вимкнути телефон. Батарею можна не виймати
• увімкнути телефон і встановити нову версію програми.

Якщо іконку для програми не задати, вона буде створена автоматично. Виглядає як шматочок пазлу з квадратиком у нижньому правому кутку. Якщо у svg будуть якісь проблеми (помилки), замість іконки скоріш за все буде пусте місце.

Кнопки намальовані з глюками, слова перенесені чортзна як — з цим все ще можна примиритися.

Але якого біса там на одній формі кнопка “Нагадати пізніше” та чекбокс “Не нагадувати зовсім”? I що буде, коли відмітити чекбокс, а потім вийти з діалогу, натиснувши цю кнопку?

Правило одного проценту, також відоме, як “принцип 90-9-1“, стверджує, що всі користувачі інтернету діляться на три групи:

• 90% — споживачі контенту
• 9% — люди, що коментують та редагують контент
• і лише 1% — люди, які ствоюють новий контент

Важливий практичний висновок з правила полягає в тому, що для формування в інтернеті іміджу для того чи іншого бренду досить заплатити баблазацікавити невелику групу активних людей. Саме так, наприклад, зробив Samsung, запропонувавши британським блогерам поміняти айфони на смартфони Galaxy S.

Також не слід забувати, що принцип діє і в протилежну сторону. Якщо вам хочеться оцінити ставлення людей до якогось проекту/явища, не слід довіряти окремим публікаціям чи коментарям — вони представляють лише 1% можливої аудиторії.

Насправді, 90-9-1 — досить умовні цифри. Вони походять з досліджень часів Usenet; очевидно, що з тих часів все неодноразово змінювалось.

Розподіл 1:100 дуже чітко підтверджується статистикою Вікіпедії. У проекті 135 тисяч активних користувачів (таких, які виконали хоч одну правку за місяць), при цьому за день проект отримує 15 мільонів відвідувачів.

Стверджується, що в 2005-2006 роках налічувалось 1.1 більйон користувачів інтернету; лише 5% вели блоги, і лише 0.1% створювали новий допис кожного дня. Таким чином, правило виглядало як 95-5-0.1. З поширенням Web 2.0 ситуація змінилась : лише 63% австралійців були пасивними користувачами, натомість 45% мають як мінімум профіль у соціальних мережах і 16% беруть участь в обговореннях.

Ще трохи інформації за темою:

• стаття у Вікіпедії
• критичний допис
• дослідження користувачів якоїсь CMS.
• історія про збирання грошей на благодійність у Facebook

• Основні поняття Qt, демонстрація роботи з бібліотекою
• Об’єктна модель Qt, поняття сигналів та слотів
• Віджети та лейаути
• Типи даних та файлів

До кожної теми підготовано набір слайдів, приблизний текст лекції та приклади. І ще є щось типу завдання на лабораторну роботу.

Все англійською мовою, звісно.

Ще один сайт з іконками , не такий багатий, але там є пошук. І ще один, для любителів svg: http://www.openclipart.org/

І ще пара сайтів с текстурами:
– тут просто якісні малюнки
– а тут надзвичайно багато малюнків, які можна викладати плиткою

На завершення — невеличкий приклад, щоб порівняти зручність та багатство різних ресурсів. Треба було мені тут знайти зображення пісочного годинника (hourglass). Порівняйте результати:
– хвалений deviantart видає купу всякого непотребу
– iconspedia трохи краще
– найкращий результат у openclipart.org

Це Київ, метро “Майдан Незалежності”.

Хоча, варто зазначити, що у себе на сайті вони слово embedded пишуть правильно

Після придбання On2 під вашим контролем опинилися найбільший в світі відеосайт(YouTube) та всі патенти, що стосуються нового високопродуктивного відеокодека – VP8. Задумайтесь, скільки всього можна було б досягти, якби випустити кодек VP8 під відкритою royalty-free ліцензією, і одночасно почати використовувати його на YouTube? Це могло б покласти кінець залежності вебу від закритого патентами пропрієтарного програмного забезпечення(Flash).

Для вільного світу було б непогано, якби ви не поводились з цією технологією як собака на сіні, хай навіть це й могло б принести вам якісь короткострокові вигоди. Звільнення VP8 без нав’язування його користувачам YouTube – це просто втрата можливості та удар по вільним браузерам, таким як Firefox. Закликаємо вас вчинити правильно. Звільніть VP8 та почніть використовувати його на YouTube!

Блискучі перспективи

Світ отримав би новий вільний формат, без усяких патентів. Глядачі, редактори відео, розробники програм та пристроїв, коротше, абсолютно усі, змогли б вільно створювати і розповсюджувати відео без усяких патентів, виплат та заборон. Наявний на сьогодні відеоформат Ogg Theora може забезпечити пристойну якість відео, таку ж саму, як і його пропрієтарний аналог H.264 (див. порівняння), і ми не відмовляємось від своїх рекомендацій щодо нього. Однак, раз уж ви придбали VP8, який покриває усі наші потреби, то їжаку зрозуміло, що його таки слід використовувати на YouTube.

У вас є нагода зробити вільний формат глобальним стандартом. YouTube – найбільший відеосайт; імовірно, там можна знайти будь-який відеоролик, який колись було зроблено. Навіть якщо YouTube запропонує цей кодек як опцію, це вже дозволить залучити до розробки більшу частину виробників пристроїв та програм.

Але пропонування вільного формату – це лише мала частина ваших можливостей. Насправді, ви могли б стимулювати користувачів використовувати вільні формати. Для цього є багато способів. Найкраще для нас було б, аби ви почали використовувати вільні формати та HTML замість Flash, пропонуючи користувачам застарілих браузерів плагіни (звісно, це має бути вільне ПЗ). Apple відмовляється від використання Flash у iPhone та iPad (хоча, за неприйнятними для нас мотивами(DRM)), і це змушує веб-девелоперів робити безфлешові альтернативи своїх сайтів. Ви можете так само вчинити з YouTube, і це стане останнім цвяхом у труну Flash.

Та навіть не скромніші дії теж можуть принести значну користь. Можна було б зацікавити користувачів, видаючи відео високої якості у вільних форматах. Або агресивно пропонувати користувачам оновити браузер (замість того, щоб оновлювати Flash). Такі кроки дозволили б швидко збільшити частину браузерів, що підтримують вільні формати. Вона б досягла 50%, і, крім, того, ще б зросла кількість людей, які ніколи не встановлюють собі Flash.

Якщо ви дійсно підтримуєте вільне програмне забезпечення та вільний веб (рух, якому, зокрема, і ви завдячуєте своїм успіхом) ви маєте щось зробити, щоб замінити Flash його вільними аналогами. Патентовані відеокодеки вже нанесли невимовної шкоди вебу та його користувачам, це продовжуватиметься. Патентні програми ускладнюють релізацю їх підтримки у браузерах, тому роздутий та недолугий пропрієтарний формат (Flash) став де-факто стандартом. Допоки ми не перейдемо на вільні формати, загроза патентного судового переслідування та ліцензійних виплат висітиме над кожним виробником ПЗ, творцем відео, розробниками фреймворків та корпоративними користувачами – і над вами теж.

Ви можете використовувати придбання On2 для розв’язання своїх власних проблем, але це буде стратегічною помилкою. Без звільнення VP8 так і залишиться просто ще одним відеокодеком. А яка користь від використання ще одного патентованого кодеку у браузері? Віддати його усім – ось що вирішить проблему. Ряд організацій, як Xiph, Mozilla, Wikimedia, FSF, та навіть і On2, вже оцінили необхідність вільних патентів і багато чого зробили для їх розвитку. Тепер черга за вами. А якщо ви так не зробите, то ми знатимемо, що ваша мета – аж ніяк не свобода користувачів, а просто домінування Google усюди.

Закликаємо вас вчинити правильно. Звільніть VP8 та запровадьте його на YouTube!

Оригінал