Участник:StasFomin/rp8 — различия между версиями

Типографская раскладка Бирмана

В футуристических фильмах и прогнозах 50-х годов, в видении будущего были радио-видео-телефоны, но мало кто мог представить, что люди будут радостно общаться печатными текстами — стучать по клавиатуре, набивая письма и электронные дневники, насмерть спорить в форумах и даже общаться с супругом, сидя в соседних комнатах.

И только «изобретатель Интернета» Винтон Серф верил в силу печатного общения, хотя у него были к этому основания^[1]

Он оказался провидцем или просто отформатировал реальность под себя: персональные компьютеры от декстопов до смартфонов, стали в первую очередь коммуникационными устройствами, причем им удалось вывести на небывалый уровень именно текстовое общение.

Клавиатурные разговоры и переписки оказались реально удобны — не нужно синхронности и изоляции, совмещаются с работой или развлечениями, пишущий формулирует мысли в своем темпе, переключаясь для изучения темы, и общеизвестно, что информацию гораздо легче и быстрее^[2] читать, чем слушать.

И собственно декстопы — неважно, громоздкие ли это ящики или ультрамобильные лептопы, обладающие настоящей клавиатурой, были и остаются основными «терминалами» в мире блогов и форумов, фейсбуков и одноклассников, асек и прочих джабберов, не говоря уже про мир «электронных документов».

Сейчас, мы общаемся с огромным количеством людей, большинство из которых мы никогда не встретим лично, и часто оцениваем друг друга именно по качеству текстов — как говорится, «the medium is the message»©. Особенно это важно профессионалам — журналистам, блоггерами, и просто «редакторам контента».

Да, несмотря на то, что мы часто видим безграмотные сообщения («не пускайте школьников в Интернет, он от них глупеет»©), а, может, именно из-за этого, в моде снова грамота, «албанское» поветрие забыто. Но если с орфографией-пунктуацией примерно все понятно — вспоминай правила, следи за своими любимыми ошибками^[3], то следующий уровень текстовой культуры — это типографика.

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

Теперь все надо делать самим — и если с орфографией нам могут помочь программы проверки, с версткой — стандартные шаблоны блогов и сайтов, плюс непрерывная верстка в броузерах или текстовых процессорах, то с типографикой, увы, «все сложно».

Так вышло, что на стандартной клавиатуре поселилось лишь небольшое подмножество печатных символов, и нам приходится в текстах, как Остапу Бендеру с его сломанной машинкой без буквы «e», заменять длинные и короткие тире, дефисы → жалким «минусом», типографские кавычки-лапки — знаком дюйма, многозначительные троеточия «…» — грубой россыпью обычных точек, не говоря уже о более редких, но все же полезных знаках валют^[4] градуса, копирайта, и т.п. — они все есть в стандартных шрифтовых наборах, но увы, доступ к ним затруднен.

Эстетам печатного слова игнорирование типографики рвет душу!

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

---

Что же делать? Один из вариантов решения этой проблемы — Compose-режим, когда зажав клавишу-модификатор надо отстучать специальную последовательность клавиш, и если вам повезло и вы правильно ее запомнили и ввели — вам таки выпадет приз — тот самый хитрый типографский символ. Но. Это адски тяжело, почти как набирать текст в TeX-е, причем вслепую. Причем этому трудно научиться — ибо на самой клавиатуре ничто не может напомнить вам об этих символах, да и вообще, использование модальных режимов и многосимвольных последовательностей — дико неудобно^[5], сбивает с ритма и мыслей, ведь для эффективности должна быть так — «один удар — один символ», иначе не выйдет быстрой слепой печати. Не говоря уже о том, что «Compose» и схожие режимы совершенно по-разному реализованы в Linux и Windows мире.

Что же делать, учитывая, что программируемые клавиатуры со сменными символами^[6] не факт, что взлетят даже в далеком будущем, а везде стандартом являются классические qwerty-клавиатуры?

Да, есть еще возможность использовать полуавтоматическую типографизацию, используя «автозамены» текстовых процессоров, всякие «онлайн-типографы», но это все не то, жалкие костыли, вместо естественного и правильного решения.

А правильное решение — типографские раскладки, т.е. ввод дополнительных типографских символов за одно нажатие с клавишей модификатором, а чтобы легче было запомнить, а для гладкости кривой обучения надо положить эти дополнительные символы на клавиши, вызывающие графическую или смысловую ассоциацию ^[7] с дополнительным символом.

В свое время было несколько развиваемых вариантов, но сейчас, по крайней мере, в рунете, остался только один, вероятно самый удачный, стандарт — «Типографская раскладка Ильи Бирмана».

С ней все становится в порядке не только с тире™ и «кавычками», но появляется куча способов обогатить свой текст, даже если это скучная форма для ввода простого комментария

• Кошерно оформить простые формулы 1¼ $ ≈ € ≈ ⅓£, i²=-1, 20°×Ѵ4≈40°±3°
• Можно упомянуть и ѣ-стыд™, да и вообще, сослаться на любой мем «уже сейчас видно, что все это будет глючить и тормозить»©
• «Я угадала знак ∞»
• ¿ hablan más español

Эх, а какие возможности «пунктуации 2.0» дают стрелки ←↓↑→…

В любом случае, в этой раскладке самые полезные типографские символы, отобранные ведущими собаков дизайнерами, общеизвестный стандарт, прошедший проверку временем.

Теперь о грустном. Автор, реализовал ее поддержку только для Win и Мак (он ведь дизайнер).

Разумеется, в Linux-мире нашлись добрые люди, реализовавшие одну из самых первых версий раскладки, в KDE и GNOME.

Но это была одна из первых версий раскладки, без кучи полезных символов, например, стрелок… и самое страшное — резкие движения третьего гнома выплеснули на повороте с водой и этого ребенка.

Да, в GNOME3 это выпилили [1] с таким комментарием "Toggling different arrangements of punctuation characters is crazy and produces lots of bugs. Typographic characters should be available without having to adjust a setting and these characters are available through the Third Level Chooser key. We need to develop a better solution though (see Extra Characters).". Типа мы все сделаем правильно, по науке, продумав дизайн, КОГДА-НИБУДЬ.

А пока → …

---

Good news, everyone!

Мы еще летом, провели нетривиальную работу, и

• реализовали типографскую раскладку Бирмана в GNOME SHELL^[8].
• довели типографскую раскладку в KDE до полного «стандарта Бирмана».

---

Включить типографскую раскладку в нашем GNOME проще простого → не надо ничего ставить, просто в настройках «Параметры → Клавиатура → Комбинации клавиш → Ввод → Клавиша альтернативных символов», надо задать удобную вам клавишу, лично я рекомендую старый добрый «правый ALT». ↓↓↓

Т.е. в наших дистрибутивах все уже есть, просто мы не Typo-Nazi, и не можем насильно заставить вас этим пользоваться, а только просим — зайдите в настройки, включите типографские раскладки правым альтом (ну или другой любимой вами клавишей), ну и начните с «кавычек-лапок» и длинных тире — даже только этим мы вместе сделаем мир, ну или хотя бы Рунет, лучше!

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 46 55% Порадовала :) 22 27% Оставила равнодушным -_- 6 7% Огорчила :( 9 11%

• Кнопка WIN ваш лучший друг! Учим горячие клавиши в GNOME

Мы уже говорили про мощь клавиатуры в GNOME, про то, что GNOME SHELL вовсе не «оболочка для планшетов», а наоборот, вполне годен именно для продвинутых пользователей. Там полно удобных хоткеев, а наши доработки позволяют смело пересаживаться продвинутых Windows-пользователей.

Но мы бы хотели, чтобы любой пользователь мог стать Advanced Power User, и смог освоить горячие клавиши — хотя бы постепенно, и по самой комфортной кривой обучения.

Современный пользователь, увы, не будет читать ни справки по горячим клавишам, ни смотреть в хелп, разве что должна быть краткая шпаргалка, которая всегда под рукой… куда бы ее положить?

Ага! Самая важная кнопка в GNOME — это кнопка WIN. Именно эта кнопка включает режим обзора, про эту кнопку рассказывают видеороликом каждому пользователю при первом входе, и именно с ней связаны почти все хоткеи…

И если пользователь, пытается вспомнить, какой там хоткей типа «WIN-чтото-там-еще», он нажимает WIN, и не отпуская, начинает вспоминать… зависает — ага, именно в этот момент самое разумное — показать ему эту шпаргалку.

И показать ее максимально ненавязчиво, в духе шпаргалок GMAIL-а^[9], полупрозрачным окном-оверлеем.

---

Good news everyone!

Мы сделали это^[10] — теперь, по долгому нажатию на клавишу WIN, показывается вот такая, аккуратно сверстанная шпаргалка по горячим клавишам:

Единственный хитрый момент — рисование по «CTRL-1», которое обещает шпаргалка, заработает, когда вы включите установленное расширрение «ScreenPen Launch», см. Blog:Точка Росы/Screenpen — магия пера или эффективная свобода преподавания со стилусом.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 37 33% Порадовала :) 58 52% Оставила равнодушным -_- 8 7% Огорчила :( 8 7%

мышами и тачпадами…

• Раскол Магического Коврика — гладить его двуперстно или по краю? Еще одна гномопроблема решена

Да, на самом деле, речь пойдет о настройках тачпада в GNOME, а именно, как обеспечивать скроллирование — по старому обряду, касаясь тачпада по краю, или двуперстно?

Ведь удобный скроллинг — фантастически удобный элемент интерфейса, и изобретение колеса мыши принесло человечеству пользу сравнимую с изобретением настоящего колеса — возникло и настоящее удобство чтения, компьютерные интерфейсы из мелких форм-окошек, пытающихся перекрывая друг-друга разместится на одном экране, стали превращаться в длинные красивые страницы с прекрасным форматированием и инфографикой, в общем, скроллинг это наше все, жить без него плохо, а с учетом того, что десктопы с мышами вытесняются лептопами с тачпадами, тема работающей прокрутки на тачпаде архиважна даже для самого простого домашнего пользователя, не говоря уже о профессионалах.

Исторически, все тачпады^[11] умели скроллить «по-краю», когда пальцем водили по правому краю тачпада. Затем, с планшетами и смартфонами пришла новая мода — многопальцевые жесты, и, в частности, двухпальцевая прокрутка, которую, наряду с вышеупомянутой классическо-старообрядческой прокруткой, поддерживают все современные тачпады.

Да, у нас в команде были споры, какой тип скроллинга сейчас более правильный, и, кстати, сейчас хороший повод об этом спросить:

Какой тип прокрутки на тачпаде вы используете?

Классический edge-scrolling 22 28% Двухпальцевая прокрутка 51 65% Все равно 2 3% Вообще не скроллирую на тачпаде 4 5%

Этот спор у нас возник, когда обнаружили, что в GNOME по-умолчанию, устанавливается «two finger scrolling». У нас тоже, аргументами моды и трендов, победила модная «двухпальцевая» партия, хотя возможно, результат предложенного голосование еще даст нам, ортодоксам, шанс переиграть.

Но в целом, какая разница, если нормально работают настройки системы и можно за пару секунд все правильно настроить.

Каково же было наше удивление, когда мы, тестируя наш гном на ноутбуках с классическими тачпадами, обнаружили, что скроллинг не работает, и поменять его тип невозможно:

Настройка «прокрутка двумя пальцами» была включена, и заблокирована от изменения. Приехали. Да, конечно, продвинутый пользователь поставит и запустит dconf-editor, залезет в очевидное место org.gnome.settings-daemon.peripherals.touchpad……, но нормальный человек такую магию не осилит и справедливо разозлится — «даже тачпад не работает!».

Расследование подтвердило первое же предположение — да, когда-то изначально по умолчанию был «edge-scrolling», а в диалоге настройки тачпада настройка блокировалась, если тачпад не поддерживал многопальцевость. Затем мода поменялась, по умолчанию сделали двухпальцевый скроллинг, а разработчики — либо все сидят на современных лептопах, либо не переинсталлировали систему… в общем, никто и не заметил, что выплеснули всех пользователей старых лептопов.

---

Good news, everyone!

Разумеется, наша доблестная UXTeam, починила и это. Теперь по-умолчанию, если тачпад поддерживает многопальцевость, предлагается двухпальцевый скроллинг, если нет — скроллинг по краю, ну и в любом случае, все можно в пару секунд сменить для любого пользователя через корректно работающий диалог параметров.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 7 16% Порадовала :) 29 67% Оставила равнодушным -_- 7 16% Огорчила :( 0 0%

• Теперь можно не боятся бесхвостой мыши в GNOME

Да-да, именно бесхвостая беспроводная мышь^[12] могла пугать пользователей лептопов.

Работаешь, себе работаешь — и вдруг раз, видишь, что аккумулятора осталось на донышке. На самом деле, это была кривая логика рисования иконки заполнения аккумулятора, в случае если подключены другие батарейные устройства: т.е. для полностью заряженного ноутбука, к которому подключена разряженная мышь, не всегда, но часто показывалась иконка разряженного аккумулятора.

Разумеется починили.

---

На самом деле, таких доработок масса, и практически по каждому нашему коммиту можно писать интересную историю, что мы и проделали по нескольким разнородным доработкам — ведь обидно, что замечают обычно отдельно разработанные продукты, а зачастую тяжелые доработки оторвавшегося в будущее апстрима, остаются незамеченными.

Поэтому сегодня расширим классический наш опрос, добавив пункт, стоит ли нам завязывать с рассказами про подобные доработки.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 10 22% Порадовала :) 28 62% Оставила равнодушным -_- 4 9% Огорчила :( 0 0% Надоело уже читать про мелкие доработки GNOME! 3 7%

Голосуйте, нам действительно интересно.

Надежно работает сеть:

• OpenVPN в линуксах — не rocket science, это должен уметь каждый

Итак, можно сказать, что времена массого заселения интернетов прошли успешно, минимальная компьютерная грамотность сегодня — умение запустить браузер и ориентироваться в вкладках-закладках, ссылках и поисковиках есть у всех.

Все это поддержалось тотальной WiFi-зацией пространства, и в целом, все привыкли, что Интернет — это некое единое магическое пространство, платоновский мир идей, к любому объекту которого которому можно всегда подключиться, если на ноутбуке-планшете-смартфоне горит значок сети или иконка веселой антенны.

Однако мир меняется, разные границы появляются и в интернете, и все чаще, можно получить удивительные ошибки «Ресурс заблокирован», «Это видео недоступно для вашей страны» и т.п. Кто только этим не занимается — Netflix и Hulu не хотят, даже за деньги^[13] делиться контентом с Восточной Европой и Азией, ну, а про а про наши интернет-блокировки решениями районных судов тоже наслышаны все.

Впрочем, иногда ограничение доступа вполне оправдано, когда речь идет о доступе к корпоративному интранету — только доверенные сотрудники должны иметь к нему доступ. Но ведь этим сотрудникам хочется удобства и постоянного доступа, и не с привинченного к полу громоздкого десктопа в унылом офис-центре, а с своего любимого лептопа, в любой момент, из дома, вайфайзированного кафе или парка, и прочего цивилизованного пространства («дом, это то место, где WiFI подключается автоматически»). В общем, BYOD-тренд заруливает.

Все эти задачи — как протуннелировать в другую сеть, и стать для интернета «голландцем» или «американцем», или наоборот, попасть в свою внутреннюю сверхзащищенную сеть, или даже просто — вырваться из недоверенной сети, где твои пароли могут прослушать — решают VPN-технологии, и здесь мы не будем говорить прописных истин о том, как это работает, почему это надежно, о тонкостях алгоритмов шифрования, сертификатах, heartbleed, капусте, Королях и т.п., а расскажем о том, как это для выглядит для пользователя в наших дистрибутивах.

Да, подавляющее большинство VPN-сетей кстати тоже сделаны на базе open-source технологий OpenVPN^[14], и там очень много гитик, как все это настраивать — сертификаты, ключи, конфиги, под винду надо ставить специальный софт, с глючными драйверами, в общем, сам в свое время писал регламенты подключения удаленным сотрудникам, ставил все это, офигевая от сложностей объяснения, ну а большинство пользователей запомнили, что «випиэн» — это какой-то рокетсайнс, и надо звать бородатых чуваков в растянутых свитерах^[15], ибо само не заработает.

В GNOME же все это работает из коробки! И не нужно знать практически ничего.

Допустим, вы решили вырваться в Атлантический Интернет — арендуете за $1/месяц какой-нибудь ProstoVPN^[16], вам присылают набор каких-то файлов (файл-конфигурации и всякие ключи — не глядя положите-распакуйте их куда-нибудь, где вы их не сотрете, и запустите «Настроить сеть» → «+» → «VPN» → «Импортировать из файла»

Тут уже выберите файл с расширением «*.ovpn» или «.config», это зависит от фантазии сисадминов или провайдера, и если есть выбор между «что-то TCP» и «что-то UDP», то, в любой такой непонятной ситуации выбирайте «что-то TCP».

Все, ничего не трогая руками, можете смело жать кнопку «Добавить».

Ура! У вас в выпадающем списке сетей появился еще один слайдер-переключатель для защищенной сети, и достаточно переключить его, как иконка сети превратится в замочек, а вы, согласно сервисам, типа http://internet.yandex.ru, смените место жительства.

---

Итак, все замечательно, работает из коробки, зачем же я начал писать статью… А, конечно нет. Не все. Без напильника и наших доработок конечно не обошлось.

Да, обычный VPN, когда весь трафик мы выбрасываем через выбранную точку, работает ОК, но при доступе к корпоративным частным сетям нужно несколько другое — чтобы только в корпоративную сеть шли только обращения за внутренними сайтами, всякими там *.office.supercompany.ru, а гугл-яндекс-вконтактик по-прежнему работали с вами напрямую.

Технически, это означает, что маршрут по умолчанию не должен меняться (см. первую строчку таблицы)

[stas@stas-HP2740p-grey test-openvpn]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.168.0.1      0.0.0.0         UG        0 0          0 wlan0
10.9.0.0        10.9.0.5        255.255.255.0   UG        0 0          0 tun0
10.9.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0

А практически, для этого в GNOME Network Manager нужно было поставить одну галочку:

Но это не работало! Галочку «использовать это подключение только для ресурсов локальной сети» ставили, но она не запоминалась, и соответственно, все работало по прежнему, через… туннель.

Пришлось разбираться и фиксить — оказалось да, глупая UI-ошибка, когда изменение этого чекбоксика формой не отслеживалось, это изменение не запоминалось, ну и так далее.

---

Good news, everyone!

UX Team пофиксил и это, и у нас OpenVPN в GNOME работает из коробки и как должно — просто, легко, и надежно.

---

А, что касается KDE — там тоже все ОК, допиливать не пришлось, и примерно также.

Тоже не надо забывать установить правильную галочку про частные сети, и про использование TCP-соединения:

Здесь могла бы быть реклама вашего VPN-сервиса

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 6 17% Порадовала :) 25 71% Оставила равнодушным -_- 1 3% Огорчила :( 3 9%

Надежное ядро и система обновлений:

• Ядро nrjQL - "сердце" РОСЫ

Как известно, сердцем ОС является ее ядро, и именно по имени ядра получили свое название дистрибутивы Linux.

Ядро Linux содержит огромное количество настроек и из одного и того же исходного кода можно собрать ядра, работающие совершенно по-разному. Кроме того, существует большое количество патчей, не входящих в основную ветку разработки, но представляющих интерес для определенных групп пользователей. Неудивительно, что различные дистрибутивы, даже базируясь на одной и той же версии исходного кода от Линуса Торвальдса, предоставляют своим пользователям ядра, имеющие серьезные отличия.

В РОСЕ используются варианты ядра Linux, изначально созданные участниками группы MIB (Mandriva International Backports) и получившие обозначения nrj и nrjQL. Что означают эти обозначения и что за ними стоит? Даем слово Николо Констанца (Nicolò Costanza), собирающему ядра для нашей ОС:

С технической точки зрения, в конфигурации «NRJ» для CPU and RCU включены опции Full Preemption (CPU Preemption, RCU Preempt tree). Набор патчей «QL» включает в себя различные патчи из набора Кона Коливаса (CK1) — такие, как планировщик работы с диском BFQ и планировщик задач BFS. Стоит отметить использование UKSM для лучшего управления памятью и TOI для улучшенной функциональности спящего режима. Все эти разработки созданы с учетом потребностей настольных машин и ноутбуков обычных пользователей. Так что мы стараемся получить ядро, с котором бы ОС для конечного пользователя выглядела бы как система реального времени в плане времени отклика приложений, с которыми он непосредственно работает.

Каково происхождение имени? Мы думали над коротким именем, в 2-4 символа. Было рассмотрено несколько вариантов, и в конце концов участники MIB остановились на NRJ. Среди других вариантов был, например, kernel-viagra, но оно одобрения не получил:) Название NRJ подчеркивает, что ядро действует на компьютер как энергетик на человека — такой вот RED BULL для машины, но это имя мы использовать не могли, равно как и другие зарегистрированные торговые знаки. В ситуациях, когда компьютер загружен различными задачами, а пользователю требуется высокая скорость реакции ОС, ядро NRJ добавляет вашей машине энергии. С ядром nrjQL ваша машина способна выполнять большой объем работ, в то же время сохраняя высокую отзывчивость.

Вот такое вот у нас ядро, если вкратце.

Отметим, что Николо собирает несколько вариантов ядер — как минимум, vanilla, nrj-laptop и nrj-desktop. За ходом работ всегда можно наблюдать в реопзитории Нико на ABF. Наконец, историю патчей и их использования в РОСЕ можно почитать на форуме MIB.

Репозиторий Нико на ABF — практически каждое минорное обновление ядра собирается и тестируется для РОСЫ

• Urpmi.recover - машина времени для пакетной базы

Многие разработчики и любопытные пользователи нередко сталкиваются с необходимостью откатить недавно установленные пакеты, которые привнесли в их систему не совсем ожидаемые обновления. Это обычно случается при установке пакетов из неофициальных источников, из testing-репозиториев или просто из частных репозиториев разработчиков и контейнеров, содержащих пакеты исключительно для тестирования. Последнее особенно актуально для нашей команды QA — откатывать установленные для тестирования пакеты им приходится очень часто.

Откатывать пакеты вручную не очень удобно, особенно если их много и вы не вполне уверены, что именно надо откатить для возврата системы в нормальное состояние. На помощь может прийти urpm-reposync, но этот инструмент может оказаться слишком мощным — он осуществит полную синхронизацию вашей системы с подключенными репозиториями, и откатить только часть пакетов с его помощью затруднительно.

Хорошая новость — теперь ниша между ручным откатом пакетов и использованием reposync заполнена утилитой urpmi.recover, способной откатывать установленные вами пакеты. Urpmi.recover может вернуть пакетную базу в состояние на определенную дату в прошлом, либо откатить заданное количество транзакций по установке пакетов.

Urpmi.recover является частью пакета urpmi и автоматически попадет в вашу систему с обновлениями.

Для осуществления такого отката пакетов, urpmi.recover сохраняет старые версии обновляемых пакетов в директории /var/spool/repackage. И для того, чтобы начать пользоваться утилитой, необходимо сначала инициализировать сохранение старых версий пакетов, выполнив команду

# urpmi.recover --checkpoint

Этой командой вы как-бы говорите: «Сейчас у меня система в стабильном состоянии, но я собираюсь установить потенциально опасные пакеты. Пожалуйста, начиная с этого момента, отслеживай все устанавливаемые пакеты и сохраняй их старые версии в случае обновления».

Вы можете выполнять эту команду и в будущем для переопределения стабильного состояния системы. При этом при каждом вызове urpmi.recover --checkpoint директория /var/spool/repackage будет очищаться, так что откатиться на более раннюю дату вы уже не сможете.

Пока отслеживание установки и обновления пакетов включено, старые версии пакетов сохраняются в поддиректориях /var/spool/repackage, соответствующих дате обновления, так что вы всегда можете изучить эти пакеты самостоятельно.

Если в некоторый момент времени вы решаете, что настало время откатить систему в прошлое, то просто выполните команду

# urpmi.recover --rollback <timestamp>

Время отката можно указать как число секунд с начала Эпохи, но для людей предусмотрены и более удобные варианты, например:

# urpmi.recover --rollback "2014-03-07 13:20:47"

или даже так:

# urpmi.recover --rollback "1 hour ago"

Можно откатить и заданное количество транзакций, указав опцию --transactions и передав количество транзакций для отката опции --rollback:

# urpmi.recover --transactions --rollback <число_транзакций>

В частности, если вы только что установили пакет (который притянул кучу зависимостей), то вы можете просто откатить это обновление, выполнив

# urpmi.recover --transactions --rollback 1

Наконец, отключить отслеживание установки пакетов вы можете командой

# urpmi.recover --disable

Эта команда также очистит /var/spool/repackage.

Вот так с помощью urpmi.recover можно откатывать состояние пакетной базы. Утилита находится в экспериментальном состоянии и отсутствие ошибок не гарантируется, тестируйте на свой страх и риск:). Впрочем, перед осуществлением отката urpmi.recover сообщит вам, что именно он собирается сделать (какие пакеты удалить, какие откатить), и у вас будет возможность отказаться, если вам что-то не понравится. Наконец, в случае чего, urpm-reposync готов прийти на помощь.

Также стоит помнить, что мэйнтейнеры не всегда заботятся об обеспечении корректного отката пакетов на предыдущие версии — так что если новая версия пакета вам что-то сломала в системе, то откат на старую может и не помочь.

• Графический интерфейс для urpmi.recover

На прошлой неделе мы отправили в репозитории urpmi.recover, способный откатывать состояние пакетной базы в прошлое. Новая утилита уже нашла своих пользователей, которые, в свою очередь, нашли в ней некоторые шероховатости:) Впрочем, систему urpmi.recover никому не убил, данные не потер, а найденные недочеты мы оперативно исправляем. Но хотим напомнить, что текущий urpmi.recover пока надо рассматривать как бета-версию, недостаточно оттестированную и не готовую к повсеместному промышленному использованию.

Неожиданные результаты работы urpmi.recover иногда происходят из-за того, что в командной строке не очень-то удобно определять, на какую дату следует откатиться или сколько транзакций надо отменить для возврата системы в рабочее состояние. Для решения этой проблемы, мы на скорую руку соорудили для urpmi.recover простенький графический интерфейс — а точнее, добавили его поддержку в утилиту qt4urpm.

Qt4urpm — это небольшая программа, написанная несколько лет назад участниками сообщества MandrivaUser.de для двух операций с репозиториями urpmi — поиском в них файлов и определения и удаления осиротевших пакетов (то есть пакетов, которые были когда-то установлены в систему для удовлетворения зависимостей других пакетов, но необходимость в которых с тех пор отпала — например, потому что зависящие от них пакеты были удалены). Конечно, схожую функциональность предоставляет и графический Rpmdrake, однако qt4urpm — гораздо более легковесная программа (написанная на Qt) с очень простым интерфейсом, но в то же время нередко более удобная в плане стоящих перед ней задач — например, здесь можно удалять только определенные пакеты-сироты, а не все сразу, как в Rpmdrake, при этом выполнение типичных действий требует максимум трех кликов мышкой.

В общем, мы решили, что простой и прямолинейный интерфейс для urpmi.recover хорошо впишется в qt4urpm и оперативно это дело реализовали. Устанавливайте свежую версию (2.0) пакета qt4urpm, запускайте программу и переходите на вкладку urpmi.recover. Здесь будут перечислены транзакции, отсортированные по дате, и для каждой транзакции указывается перечень установленных во время ее выполнения пакетов:

Выбирайте интересующую вас дату/транзакцию и жмите Rollback — и urpmi.recover откатит все транзакции, начиная с выделенной.

В будущем, возможно, наши специалисты по приложениям с графическим интерфейсом создадут что-нибудь более красивое и эстетичное, но в плане функциональности qt4urpm предоставляет все необходимое. Надеемся, он позволит вам избежать путаницы в транзакциях rpm и более удачно рассчитывать эффекты от отката пакетной базы.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 2 11% Порадовала :) 17 89% Оставила равнодушным -_- 0 0% Огорчила :( 0 0%

Нестыдно поставить РОСу, девушкам, детям и прочим родственникам. Все сделано понятней и привычней, и удобно для «домашнего использования»,

• Развиваем и KDE! Нескучные обои — сразу из броузера

Обои для рабочего стола. Казалось бы, элементарная вещь, но сколько шума и проблем связано с ними у линукс-дистрибутивов.

С одной стороны, Труѣ-линуксоиды считают недостойным само размышление на эту тему, что лучше всего отражено в следующем коане:

Как-то Сисадмин спросил:

— Учитель, не желаете ли красивую картинку для вашего десктопа? У меня есть коллекция «обоев для рабочего стола» со звёздным небом и моральным законом.

— Почему ты думаешь, что мой нынешний «wallpaper» хуже? — спросил в ответ Инь Фу Во.

— Я не знаю, какая у вас картинка сейчас. Я никогда не видел вашего десктопа. У вас всегда открыто множество окон.

— Я тоже его никогда не видел, — сказал почтенный Инь. — Я работаю.

©

С другой — почему-то выбор обоев для дистрибутива считается чуть ли не системообразующим фактором, порождающим кучу самоделок с «нескучными обоями», ну и часто, при поверхностных^[17] обзорах дистрибутивов, основное все впечатление по дизайну обосновывается скриншотами прибитых по умолчанию обоев, что на самом деле, также осмысленно, как оценивать покупаемую квартиру по обоям.

С третьей — невыразимый ѣ-стыд охватывает, когда ставишь KDEшный Linux девушке/жене и видишь, что самое первое, что делает типичный «female user» — это пытается придать уют, пытаясь сменить обои рабочего стола, неважно, были ли они специально страшные, или специально разрабатывались целым отделом дизайна. И не может. Ведь те, кто меняет обои в KDE, знают, что это совершенно неочевидный процесс, который нельзя понять, можно только запомнить, и состоит из странных действий, связанных с файловой возней («файловой» — значит уже неочевидной «нормальному пользователю») или какими-то странными KDEшными каналами их получения.

При том, что даже ребенку, выпущенному в интернет, понятно, что именно там находится тот самый неисчерпаемый источник красивых обоев (Яндекс, Google), где можно их выбрать и по ключевым словам, темам, популярности и адаптированным под нужное разрешение. Впрочем, в интернете уже все хранят даже семейные фотоальбомы, если кто захочет радовать себя фотками родных на рабочем столе — он тоже будет ставить их из браузера.

И не нужно ни странных методов настройки, закопанных в глубины центров управления, ни странных «wallpaper stor-ов», нужно лишь одно, чтобы работала стандартная функция браузера, контекстое меню на картинке → «Сделать обоями рабочего стола».

Такая штука уже работала в GNOME (хотя не совсем ОК, об этом дальше), но ее не было в KDE, а соответствующие баги мирно тухли уже лет пять.

---

Good news, everyone!

Наш KDE-эксперт, Андрей «Pulfer» Бондров, наконец-то закрыл страницу этого позора, запатчив KDE, KMozillaHelper и Firefox.

Теперь и KDEшный ROSA Fresh можно без стыда поставить девушке и ребенку. И умильно наблюдать, как ваша жена, перебирает для обоев ваши фотографии… чтобы потом выкинуть их и поставить что-нибудь по-настоящему красивое^[18].

И кстати, по нашим прошлым постам в «Точке РОСы» могло сложиться впечатление, что работа идет только по GNOME-версии, а KDEшная версия заброшена — уверяем вас, это не так.

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

Кроме доработок апстримого KDE много исправлений делалось и в наших KDE-продуктах — ROMP, SimpleWelcome… описывать исправленные ошибки как-то наверно скучно, хотя там были исправлены и очень неприятные проблемы, например, когда пользователь проигрывал видео с подключенных сетевых хранилищ (FTP и т.п., как описано в Blog:Точка Росы/Из всех искусств для нас важнейшим является кино…), система, ради красивого тамбнейла вытаскивала целиком видеофайлы в /tmp, забивала его полностью и происходило много-много неприятностей. В общем, и с этим «чудовищем, которое преследовало ваш род» было покончено.

---

Впрочем, насчет обоев, мы еще не закончили. Ведь пришлось делать доработки и в GNOME, где, казалось бы, все должно было работать из коробки. Так казалось мне, и наверное всем гномо-пользователям. Мужского пола. Ведь мужской выбор (если все-таки лень вообще что-то менять удалось победить) — это неторопливый выбор подходящей картинки в браузере, установка ее, и все. Забываем на годы.

Как выяснилось, наблюдая за женским выбором — он не таков. Картинка выбирается, на нее смотрят, ставят на рабочий стол… живут с ней несколько минут… после чего «нет, что-то не очень» и идем переклеивать обои заново. Хорошо, что не в квартире, но каково же было мое удивление, когда мне сообщили «WTF? Обои меняются только четыре раза, а потом все, надо перезагружаться». Такие странные физические ограничения для электронных артефактов обычно вводят в удивляющий ступор, заставляя вспомнить разные истории, про «email, который идет не дальше 500 миль» и т.п.

Оказалось да, там была вполне реальная проблема, связанная с именованием выбранной из браузера картинки, кешированием, и отслеживанием изменений… — и UX Team успешно зафиксил и ее.

---

Так что теперь, и ROSA GNOME Fresh и ROSA KDE Fresh можно смело ставить девушкам, женам и детям…

Остается только ROSA LXDE Edition, где и браузерно-обойная проблема еще не решена, и выбор обоев по умолчанию, у многих пользователей вызывает … некоторое удивление^[19]… но будем пока считать это не багом, а фичей, и лично я, ROSA LXDE поставил на лептопы тестю и теще^[20].

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 87 75% Порадовала :) 17 15% Оставила равнодушным -_- 3 3% Огорчила :( 9 8%

• Мы вернули ярлыки на рабочий стол в GNOME

... to delete

• «Приложение по-умолчанию» в GNOME теперь можно запомнить в момент выбора

Основная ответственность «Среды Рабочего Стола»^[21] — это удобный и быстрый запуск нужных пользователю приложений на требуемых файлах.

И тут исторически есть два подхода:

«Действие→объект»

самый старый^[22] подход, проявляемый в

• интерфейсах командной строки, когда сначала указывается действие-глагол, а потом параметры,
• либо когда запускается приложение, а потом средствами приложения открываются нужные файлы.

Тут от оболочки требуется либо предоставить удобный способ запуска программы — будет ли это кнопка «Пуск» с иерархией меню, список или плиточная сетка иконок, быстрый поиск по введенным подстрокам… либо хотя бы возможность запустить консоль. Про это мы больше тут говорить не будем.

«Объект→Действие»

Более дружелюбная парадигма, когда пользователь, бродя через «файловый менеджер/проводник» находит нужный объект^[23], после чего, выбирает, кто и что будет с ним делать. Отсюда возникло древнее интерфейсное понятие «ассоциаций приложений», когда некоторым типам объектов^[24] можно сопоставить программы, ну, а в случае, когда их несколько, выбрать «приложение по умолчанию».

Вся эта концепция ассоциаций очень важна, и даже минимальные изменения в концепциях настройки серьезно влияют на удовлетворенность пользователей^[25].

И во всех классических оболочках, от Windows до KDE-LXDE-Unity, ну или если быть точнее, в файловых менеджерах этих оболочек, реализовано, что для каждого объекта можно

• вызвать контекстное меню;
• в этом контекстом меню будет что-то типа «Открыть с помощью» или «Открыть в программе»;
• в этом интерфейсе выбора программ, можно выбрать приложение и назначить его главным приложением по умолчанию для всех таких файлов — «ох, я не хочу ничего выбирать, я хочу фыр-фыр-фыр просто смотреть фильм, но я был вынужден выбрать правильный плеер, я выбор сделал, поэтому больше не спрашивайте меня об этом, и тем более не заставляйте идти искать какие-то настройки».

К этому пользователи привыкли абсолютно, виндузятники ли они, макюзеры или негномовые линуксоиды, и столкнувшись с Nautilus-ом из GNOME, они испытавают некий шок и ступор^[26]. Ибо этого там нет. Можно только выбрать приложение, но это не сделает его приложением по умолчанию. И совершенно неочевидно, как его задать. Ибо для того, чтобы задать соответствие приложения для типа файлов, в GNOME Shell нужно

• найти файл соответствующего типа в Nautilus
• по контекстому меню вызвать его «Свойства»
• и там, на последней вкладке «Открыть с помощью», наконец-то есть нужный выбор и «Установить по умолчанию».

Почему это нельзя сделать через совершенно ожидаемый способ с выбором приложения в момент запуска, почему это надо настраивать отдельным от запуска действием, почему требуется неочевидный путь, где настройки для типа файлов спрятаны в глубине свойств (права, размеры, время доступа и правки) обычного файла, так, что «сынок, это нельзя понять, это можно только запомнить» — неизвестно.

---

Good news everyone!

«Теперь все будет, как при бабушке ©» — мы это починили!

Казалось бы маленькая обработка напильником, но мы боремся, чтобы в «нашем гноме» не осталось неоправданных странностей, вызывающих у пользователя ступор и проклятия.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 16 36% Порадовала :) 14 32% Оставила равнодушным -_- 5 11% Огорчила :( 9 20%

• Из всех искусств для нас важнейшим является кино…

Из всех искусств для нас важнейшим является кино и цирк… ©

Несмотря на победное шествие планшетов, как «специализированных устройств для личного потребления контента», хороший ноутбук практически ни в чем не уступает планшету, более того, имеет немало преимуществ именно в «активном потреблении», где он однозначно выигрывает не только у планшетов, но и [Smart]TV. Эргономически компактный лептоп не менее удобен для чтения и просмотра видео, более того, все больше ноутбуков идет с тачскринами, превращаясь в планшет с удобной подставкой-клавиатурой. В результате, не нужена большая грудь большой удобный живот, чтобы смотреть видео лежа с лептопа, не нужны руки, чтобы смотреть или читать видео сидя, плюс есть удобство клавиатуры для «активности» — т.е. для комментирования и заметок, навигации по видео и переключений на другие приложения^[27]. Планшет может выиграть разве что в грустной ситуации типа «стоя в шатающемся забитом вагоне метро», зато с большого домашнего ноутбука^[28] можно устроить даже качественный семейный просмотр, даже без подключения к телевизорам-проекторам.

В общем, ноутбук вполне годная штука и для чтения, и для видео. Но для этого, конечно, на нем должна быть правильная, полноценная десктопная система, и мы внимательно следим, чтобы в нашей РОСЕ с этим все было идеально.

Оставив пока за бортом книги-тексты, поговорим именно о видео.

Казалось бы, ну «видео на компьютере», кого этим можно удивить с лохматых 90х, когда вместо дурацких DVD-дисков, видео стало расползаться удобными файлами на самонарезанных золотых CDромах, и постепенно набирающем силу интернете.

Росло разрешение, появлялись более эффективные кодеки упаковки, появлялись новые форматы — с множественными звуковыми, видео и субтитровыми дорожками, пользователи мучались, кололись, но продолжали перебирать разные плееры, скачивать под Win сомнительные «кодек-паки», постоянно ожидая, что что-то может внезапно не проиграться, или потребует установку специального плеера, который, в лучшем случае, будет выносить им мозг регулярными обновлениями.

Поток видео же нарастал, сериалы вышел из низкого жанра «мыльных опер» в настоящие драматические произведения, культурно эквивалентные великим романам доинтернетной эры, а ютубы и прочие vimeo из хранилищ «мелких прикольных видео» стали хранителями курсов лекций и развлекательных передач, обогнав по объему контента телеканалы.

Сейчас на дворе третье тысячелетие, и вроде как странно гордиться, что в нашем дистрибутиве есть наш вполне годный плеер ROMP:

• всеядный по кодекам;
• запоминающий для каждого видео текущее положение просмотра, чтобы можно было не гадать — смотрел или нет, и не искать, где зритель заснул;
• автоматически подкачивающий субтитры из OpenSubtitles.org;
• где для youtube есть поиск и непосредственное воспроизведение;
• реализованы простые «видеомонтажные» потребности — вырезать звуковую дорожку и кусок видео, записать скринкаст и т.п.
• а еще он работает и под WIN, что удобно, если хочется привыкнуть к единому интерфейсу медиаплеера.

Не удержусь, от того, чтобы не процитировать короткий^[29] проморолик:

Но это не значит, что мы навязываем «свои велосипеды» — у нас также собирается десяток других медиаплееров. Например, очень популярен VLC^[30]. Интерфейс у него не очень дружелюбен, но в нем есть нетривиальные фичи, которые нужны продвинутым пользователям — например, мне часто нужно воспроизведение матрешек с мультивидео потоками.

Он тоже качественно собирается у нас — т.е. с максимально возможными опциями поддержки^[31], и с вдумчевым автоматическим и ручным тестированием. Собранную версию VLC мы тестируем на отсутствие багов воспроизведения, отслеживая статистику dropped frames^[32], боремся с хитрыми проблемами, типа поддержки многослойных DVD-9, и т.п.

Впрочем, тут наверное многие рассмеются, на тему «поддержки DVD», говоря, что CD-DVD мертвы, BlueRay «не нужен», и 99% всех пользователей смотрит видео из сети, локально-квартирной, из домашней сети провайдера, или из глобального интернета — из бесплатных ютубов или платных нетфликсов. Это тоже совершенно разумно, ибо «контент жиреет», а лептопы «тощают», и в них нет места под оптические накопители, а пока недешевые гигабайты SSD жалко тратить на многосезонные сериалы или многогиговые BDB-рипы — контент должен:

• хранится на домашних, внутрисетевых или глобальных интернет-сервисах
• и по мановению ока, как только захочется что-то посмотреть — без предварительных лаого скачивания, немедленно проигрываться в выбранном плеере, ведь cтандартной WiFi g-скорости в 54Mbit вполне достаточно для realtime стриминга даже HD-фильмов.

Казалось бы, очевидные мысли, и все должно работать во всех Linux-дистрибутивах из коробки, ведь в отличие от разных других систем^[33] файловые менеджеры Dolphin и Nautilus поддерживают прозрачную навигацию по FTP-хранилищам, и могут вызвать на проигрывание нормальный плеер, например, VLC, который поддерживает FTP-стриминг, с навигацией и все такое. FTP-хранилище сделать проще простого и для дома — простой NAS или современный роутер с поддержкой USB-винчестера^[34], такие часто есть в хороших локальных сетях, предоставляющих пользователям больше^[35], чем просто канал в глобальный инет, такой очень просто и удобно завести в компании, для хранения обучающих курсов или записей семинаров и совещаний.

Однако и тут не все просто. Например, это не работает в Убунте^[36]! Дело в том, что в KDE-based дистрибутивах, Dolphin напрямую передает MRL-адрес видео в правильный плеер (например, для определенности будем считать VLC), а в GNOME, все это, как обычно, навороченно и вроде как по-уму, но не работает. Там используется GVFS-проксирование, что, в общем, круто и правильно, только для FTP оно не работает чуть более, чем полностью — куча багов, которые не правятся годами. В результате, получается «собака на сене» — хотя какой-нибудь VLC может воспроизводить FTP-адреса, а Nautilus прекрасно броузит FTP-хранилища, так, чтобы FTP-стриминг заработал — не выходит^[37].

Поэтому мы провели доработку самого Nautilus-а, и у нас, он передает FTP-урлы напрямую в VLC!

Следующий, возможно уже самый распространненый сценарий видео-потребления — видео через флеш-проигрыватели, с ютубов, видеохранилищ социальных сетей и 100500 различных сайтиков. Да, казалось бы, времена, когда флеш не работал в линуксе из коробки, давно прошли, да и вообще, что можно тут улучшить или сломать в самом обычно флеш-видео?

Увы, во всех GNOME-derived^[38] дистрибутивах^[39], есть неприятный баг с воспроизведением флеш-видео на полном экране. Выглядит это так, что при открытии флеш-видео в полноэкранном режиме, видео иногда зависает. На самом деле, это баг Mutter-а, стандартного оконного менеджера GNOME, который для полноэкранного воспроизведения открывал отдельное невидимое^[40] окно, но где-то внизу остальных окон.

Мы бились и с этим багом, и, победили и его^[41]!

---

Ну и наконец, возможно у некоторых читателей сложилось впечатление, что «все эти ваши линуксы — для халявщиков, скачивающих видео», а честному человеку, оплатившему абонемент в какой-нибудь сетевой кинотеатр — Netflix, Hulu, или наш ivi.ru, линукс противопоказан.

В этом, увы, есть некоторая правда. Дело в том, что DRM-технология воспроизведения «закрытого контента» действительно не поддерживается в большинстве Linux-дистрибутивов. Вернее так — единственная подсистема-сервис, необходимая для DRM в Linux, это HAL, Hardware Abstraction Layer, который параллельно занимался много чем, но делал это не очень, в результате чего практически во всех дистрибутивах он уже как пару лет был заменен на udev, и linux-пользователи стоят перед выбором — либо без HAL, но и без DRM-видео, либо поддержка DRM через HAL, но тогда жуткие конфликты HAL с udev, в борьбе за устройства — могут отваливаться даже USBшные мыши, в логах тонны жалоб, в общем — не жизнь. Все это даже несколько напоминает ситуацию с взбесившимся HAL-ом в «Космической одиссее-2001», если кто помнит эту нестареющую классику.

Но мы идем на все, чтобы помочь нашему пользователю — бригада наших системщиков-нейрохирургов провели лоботомию для HAL, в результате чего у нас он забыл про все оборудование, и занимается исключительно поддержкой DRM-видео. В таком безопасно-кастрированном видео он входит в наши KDE и GNOME дистрибутивы^[42], так что DRM-видео будет работать из коробки.

Отдельная проблема, это что механизм DRM удален из браузера Chrome (а именно из Flash старше 11.4). Кто тут виноват — Adobe или Google — неизвестно. Но первые похоже решили что Linux не про них, вторые же так и сделали нормальный DRM механизм на основе HTML5 (точнее он есть для Android, там то фильмы проигрываются безо всякого flash, но вот «запилить» его для Linux Google явно не судьба). Но в Fresh, со стандартным Firefox или установленным из наших репозиториев Chromium — все работает, и мы тестировали наши дистрибутивы и на ivi.ru, на play.google.com, и на HuLu^[43]. Единственное, не удалось попробовать Netflix — стандартные методы обмана не сработали, а пробрасывать VPN + заводить виртуальные американские банковские карты было влом не было времени. Так что если вдруг, кто-то из читателей и пользователей нашего Fresh, является Netflix-юзером — скажите, все ли там работает? Нам очень интересно.

Ох, поздравляем, что вы осилили многобукв этого краткого^[44] обзора видеопроблем и решений, и это убедит вас, что если вы, или ваши родные или знакомые любите смотреть видео с вашего десктопа или лептопа — наш дистрибутив отлично для этого подходит, ибо мы внимательно следим за этой темой, ибо мы сами постоянно смотр тестируем видео- мульт- и анимесериалы, и при обнаружении малейших проблем — чиним.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 76 57% Порадовала :) 47 35% Оставила равнодушным -_- 5 4% Огорчила :( 5 4%

• «Не заставляйте меня помнить!» — Свобода пользовательским паролям

В воображаемом мире нефункциональных требований «безопасность» всегда ведет смертельный бой с «юзабилити», или говоря простыми словами — попытки сделать удобно создают уязвимости, а перестраховка от возможных дыр может сделать продукт совершенно негодным.

Иногда возможны компромиcсы, но в случае конфликтов, мы всегда на стороне наших пользователей. Fresh — дистрибутив для домашних пользователей, и он не должен изображать из себя SELinux^[45].

Реальные риски, от которых защищаются домашние пользователи:

• другой член семьи не посмотрит историю в броузере,
• если аккаунт детский, то возможно там установлен родительский надзор (SkyDNS и т.п.).

Реальная атака, если sshd не установлен (по умолчанию — нет) — ручной перебор, от чего эффективно защитит и пароль из пары-тройки символов^[46]. Защита рутового аккаунта — только от «дурака» или потенциальных троянов.

В Fresh GNOME, и во всех других дистрибутивах, выросших из Mandriva, была проблема, архитектурно связанная в использованием библиотеки pam_tcb.so и жестких проверок cracklib, а выглядело это так, что у пользователя

• требовалась адова секьюрность пароля (длина, наличие цифр и букв и т.п.)
• при смене обычным пользователем своего пароля, требовалось вводить дополнительно root-овый пароль — что либо выглядело издевательством^[47], либо профанацией^[48] безопасности.

---

Good news, everyone!

Мы сменили pam_tcb на на pam_unix, что дало возможность и

• Улучшить удобство — теперь можно делать пользователям любые пароли, система только будет оценивать его относительную сложность, и рекомендовать усиление. Но если рисков реально нет — нетбук для ребенка, с играми — то можно обойтись и без пароля, и поставить даже пустой пароль.
• Усилить безопасность — теперь в pam используется sha512, до этого там был вовсе bluefish.

А что касается возражений «проверкам на сложность паролей надо подчиняться», или вообще, «используйте только одноразовые сгенерированные пароли», то на самом деле, гораздо более остро стоит проблема «интернетных паролей» от разных сетевых аккаунтов и даже тут, мы рекомендуем использовать либо использовать удобные для запоминания ассоциативные пароли, либо уникальные для каждого сайта пароли, вычисляемые прямо в броузере по удобному для запоминания мастер-паролю.

Кстати, может активно приучать «обычных пользователей» к сетевой безопасности, и добавить букмарклет «SuperGenPass» в Firefox по умолчанию?

Идея добавлять букмарклет «SuperGenPass» в Firefox по умолчанию?

Отличная 7 47% Хорошая 5 33% Плохая (поясню почему) 3 20%

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 3 21% Порадовала :) 6 43% Оставила равнодушным -_- 1 7% Огорчила :( 4 29%

Advanced users, которым нужны все возможности быстрого и надежного Desktop Environment, надеемся, оценят наши доработки рабочих столов:

• Укрепляем GNOME — дело о пропавшей памяти и неучтенных картинках

Продолжим тему невидимых, но очень полезных доделок и исправлений GNOME.

Ведь на поверхности, что всплывает в разных обзорах — это фичи, внешний вид, обои и иконки, … а реально пользователей в первую очередь беспокоит надежность работы системы, чтобы работало без глюков и торможений месяцами.

Да, месяцами, хотя казалось бы месячный аптайм нужен только серверным системам, пользователям же надо спать и все-такое. Но современный пользовательский подход — работа без перезагрузки, чтобы не терять открытых окон программ, контекстов работы, и десктоп-лептоп не выключается в перерывах, а только засыпает или гибернируется.

Поэтому любые утечки памяти достаточно критичны — ведь стоит оболочке «наесться памяти», система «зароется в своп», все начнет дико тормозить и придется перегружаться, как в давно забытые времена.

Мы серьезно подходим к тестированию клиентских систем, и если говорить о «нагрузочном тестировании» тут, наверное, некорректно, поэтому мы проводим, как мы это называем, «марафонское тестирование» — автоматическое и ручное тестированием системы в течении недель с непрерывным воспроизведением различных сценариев — это и браузер с флеш-видео с ютубом, это и поочередный запуск абсолютно всех установленных программ.

И при этом тестировании мы начали получать неприятные сигналы — тестировщики жаловались, что «этот ваш GNOME ест память, как не в себя». Мы целыми днями мучили gnome-shell Valgrind'ом — но никак не могли найти серьезных зарегистрированных утечек. Однако автоматическое тестирование, запускавшее все пользовательские программы, включая кучу игр, подтвердило сигналы тестировщиков: система в какие-то моменты подъедала память, и часто при тестах, когда система съедала больше четырех гигов, падала тестирующая виртуалка.

Все это выглядело, как будто вроде как добротный сборщик мусора GNOME не спешил отдавать память.

Похожие вещи наблюдались в куче дистрибутивов, гномовцам ставили баги, на которые они писали отписки в духе «это не мы, это ваши графические драйвера виноваты», так что нам пришлось прорываться самим.

Ловили эту проблему несколько итераций, … опустим грустные и неинтересные сложности, расскажем о некоторых выявленных причинах.

Например, внутри Javascript'овой логики (в background.js), создавался внутренний джаваскриптовый кеш-словарь картинок-обоев, причем картинка создавалась для каждого разрешения. В результате, часть программ, особенно которые перехватывали весь экран, как игрушки, в этом кеше происходило накопление картинок.

Теоретически, Garbage Collector от GNOME должен был удалять неиспользуемые картинки, но. Этого не происходило из-за тонкостей биндинга JavaScriptoвой логики с C-шными библиотеками — GC просто не видел, и не учитывал память, занимаемую картинками, учитывая только JavaScriptовые структуры ссылающиеся на них. Да, если бы он освободил их — то освободилась бы и захваченная на «C»-уровне память, но т.к. он эту память не учитывал, то он и не спешил со сборкой мусора и освобождением.

В результате, мы внесли пару точечных патчей именно в JavaScriptовую логику, и эта проблема ушла.

Так что знайте — в нашем дистрибутиве мы не только впиливаем красоту и фичи, но и серьезно исследуем проблемы надежности — к сожалению, там еще есть что копать.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 43 65% Порадовала :) 18 27% Оставила равнодушным -_- 2 3% Огорчила :( 3 5%

• Скриншотинг и скринкастинг — что нам пришлось доработать в GNOME SHELL

Блог:Точка Росы/Скриншотинг и скринкастинг — что нам пришлось доработать в GNOME SHELL

• Допиливаем Gnome Control Center — теперь контроль при любом разрешении

Продолжим рассказывать о серии наших полезных GNOME-доработок.

Те, кто пользуются GNOME Shell, хорошо помнят окно GNOME Control Center: по-военному построенные ряды иконок, расстояния между ними строго фиксировано по уставу, окну не полагается скроллеров и возможности ресайза.

С точки зрения дизайна, это конечно хорошо — сетки, минимализм, консистентность, но… заданные интервалы между иконками явно подбирались под лаконичные англоязычные подписи, и оказались слишком малы для их русских переводов.

Обрезать переводы было бы отвратительным, и мы, проведя исследование, увеличили интервал между иконками, так, чтобы влезали подписи на именно на русском языке — они самые длинные из всех остальных локализаций.

Потом обнаружили ту же проблему с невлезающими подписями в GNOME Tweak Tool, который мы давно сделали полноценной частью GNOME Control Center. Там было совсем плохо — пользователь не мог сделать разумный выбор в обрезанных списках опций.

Затем, тестируя GNOME Fallback на нетбуках, мы обнаружили, что разработчики Gnome совсем забыли про пользователей этих когда-то популярных лептопиков, с разрешением 1024×600 — тут уже проблема была в вертикальной плоскости, т.к. вертикального скроллинга не было предусмотрено, нижние ряды настроек были просто недоступны. А ведь это epic fail — система с недоступным интерфейсом управления.

Да и касается это не только нетбуков — ведь хотя разрешения дисплеев растут в сторону «ретин» и «4K», полно еще живых и используемых старых лептопов, которые под Linuxом будут жить долго и счастливо, их можно использовать самим, подарить родственникам и знакомым, использовать для технических задач (мониторинг и управление какими-нибудь устройствами) — у меня самого есть десяток старых добрых Thinkpad X61, с IPSным дисплеем 1024×768.

Впрочем, доля пользователей старых лептопов относительно невелика, и всегда уродовать окно скроллером не хотелось бы. Поэтому поправили адаптивно, скроллер возникает только когда разрешение по вертикали меньше требуемого, и, думаю, большая часть пользователей его никогда не увидит. Это даже немного обидно, в духе «наша служба и опасна и трудна, и на первый взгляд как будто не видна, на второй как будто тоже не видна, и на тре», поэтому не удержусь, и приложу скринпруф:

В общем, важно то, что хотя GNOME Shell декларирует одной из своих целей «accessibility for people», мы заморачиваемся на тему «accessibility in all computers», и этот пример показывает еще раз, сколько неожиданно мелких доработок надо сделать в GNOME Shell, чтобы перестать ходить по нему как по минному полю, а быть уверенным, что все в нем работает, и так как надо.

Ведь нас часто спрашивают в рассылках, письмах и форумах, почему у вас GNOME 3.8, когда уже готов 3.10, вы же FRESH и все должно быть абсолютно свежее.

Возможно название линейки дистрибутивов «FRESH» действительно немного сбивает с толку, но мы хотели бы прояснить, что мы не гонимся за абсолютными цифрами, у нас нет такого фетиша, это не олимпийские игры, а цифры версий измеряются не в сантиметрах. Мы стараемся сделать удобную и надежную систему, для домашних и профессиональных пользователей, а не только любителей «свежего линукса». И гонка версий тут самая плохая стратегия. Технически, нам ничего не стоит еженочно пересобирать образы, где все будет самое-самое свежее, но новое — это не значит лучшее, и у нас огромные усилия тратятся на контроль качества и доработки.

Мы внимательно следим за свежими версиями программ и в частности Desktop Environment, смотрели и GNOME 3.10, видели очевидную сырость, огромное количество багов, очень странные юзабилити решения^[49] при том, что интересных фич там практически не прибавилось.

В общем, если вам действительно нужно быть на самом острие гномо-прогресса, вам, конечно, стоит использовать Fedora. Если же вы хотите попробовать GNOME, обработанный напильником и шкуркой — попробуйте наш дистрибутив, и возможно вы увидите, что не так страшен GNOME, как его малюют, и получите удовольствие и радость, от того, что все работает и не отвлекает от работы и развлечений. Ведь минималистичный интерфейс GNOME позволяет и быстро переключаться между задачами, и при этом не занимает лишнего места и внимания.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 2 6% Порадовала :) 22 71% Оставила равнодушным -_- 6 19% Огорчила :( 1 3%

• Тук-тук, откройся, или решена проблема входа в GNOME после засыпания

На самом деле, кроме впиливания «крупных фич» в GNOME, нам приходится вносить также кучу мелких фиксов, казалось бы недостойных отдельного упоминания, но при этом, хотя патч-исправление может быть из пары строк, исправление это может занять много времени — воспроизведение, анализ, в общем, классическая история про почему «удар молотком стоит $100», и даже как-то обидно за ребят из UX Team, что никто не узнает об их упорной борьбе с этими багами.

Поэтому наверно, о нескольких таких случаях, мы для примера, расскажем.

Итак, GNOME-пользователи знают, что в после периода неактивности, или выхода из сна, GNOME переходит в заблокированное состояние, показывая^[50] обои, часы, и требуется его разбудить, что бы стащить с него «шторы обоев»:

Поднять эти шторы можно либо «планшетным» путем, оттягивая нижний их край наверх, но это дико неудобно для классических клавиатурных пользователей — точное позиционирование, зажим-захват, drag-and-drop… Поэтому для клавиатурных пользователей сделано разумно — «тук-тук» в anykey. К чему мигом приучаешься, не обращая внимания на планшетный интерфейс.

Но. Если усыпить/разбудить ноутбук, то ужас — клавиатурный способ не работает, а так как это пользователь приучается делать на рефлексах, он получает ступор («я жму, а оно не работает», «зависло что ли?») и, следовательно злость.

Good news, everyone!

Cпециалисты UX Team исследовали и решили эту проблему — оказалось, это «окно со шторами» просто теряет фокус.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 6 27% Порадовала :) 14 64% Оставила равнодушным -_- 2 9% Огорчила :( 0 0%

Удобство инсталляции — один из приоритетов

• Поумневший инсталлятор и больше удобства в консоли

Инсталлятор дистрибутива, казалось бы, вещь одноразовая, как первая ступень ракеты на пути к Марсу — важно, чтобы взлетело, отработало правильно и надежно, и все — скорее всего, домашний пользователь его больше никогда не увидит.

Однако, на самом деле, инсталляция может понадобиться неоднократно:

• теперь ведь обычно в семье несколько компьютеров (декстопов и планшетов).
• переинсталляция — это самый простой способ исправить любые неисправности, произошедшие как из-за ошибок собственного администрирования, после апгрейда/смены оборудования, либо из-за сбоев железа или системы обновлений.
• часто инсталлятором пользуется «продвинутый пользователь», устанавливая систему знакомым и родственникам.

В любом случае ужасно лень отвечать на однообразные вопросы, на часть из которых можно легко угадать правильный ответ, а на некоторые, наоборот, придумать хороший вариант, разгрузив пользователя до состояния «Я юзер, я не хочу думать, я хочу, чтобы система поставилась сама».

---

Good news, everyone!

Во-первых, теперь при инсталляции используются технологии GeoIP, чтобы догадаться, где находится пользователь, и с вероятностью >90% правильно угадать:

• Язык ввода
• Локализацию
• TimeZone

Идея использовать GeoIP для угадывания языка-локализации-таймзоны…

Отличная 25 57% Неплохая 13 30% Неважно 2 5% Ошибочна 4 9%

Во-вторых, инсталлятор пытается придумать удачное имя для вашего компьютера. Казалось бы, это исключительно человеческая прерогатива («Адам назвал тигра тигром, потому что он был похож на тигра…»), но на практике, проводя юзабилити-тестирования, наблюдая за пользователями дистрибутива, мы обнаружили, что подавляющее большинство пользователей совершенно не хотели задумываться над этим вопросом в процессе инсталляции, и в результате, инсталлируемый лептоп получал ужасно оригинальное имя «localhost.localdomain». Это было даже у некоторых разработчиков…

Из-за этого потом возникает куча неудобств: несколько «localhostов» в локальной сети, неуникальные названия расползаются в системы удаленного администрирования или коллаборации (разные там дропбоксы и т.п.), и эту проблему проще предотвратить, чем прописывать как все это настраивать в скучной документации, которую никто не читает.

Как же назвать новорожденный Linux-desktop?

• Во-первых, мы спрашиваем логин первого пользователя^[51] и разумно предположить, чей это будет ноутбук или десктоп.
• Во-вторых, мы опрашиваем автоматически сам инсталлируемый десктоп, на тему производителя или модели. На самый худой конец, если мы не поняли, что это^[52], инсталлятор по ряду эвристик выясняет, ноутбук это или десктоп — и именует соответственно «Laptop» или «desktop»

В результате, вместо «localhost.localdomain» мы получаем вполне вменяемый «masha-hp-2730», «stas-acer-travelmate-2480» или «vasya-desktop». В любом случае (если что-то не совсем угадали, или хочется что-то свежепридуманное внести в имя), сгенерированное имя можно поправить с меньшими временными затратами, чем придумывать с нуля и заново.

Да, эти фичи уже появились в инсталляторах некоторых продвинутых дистрибутивов, впрочем, даже в самых продвинутых не стали вытаскивать модели компьютеров-ноутбуков для именования, и мы думаем, наши доработки порадуют, например тех, у кого дома завал разношерстных ноутбуков.

---

---

И наконец, вопрос прав.

Мы разумно предполагаем, что первый пользователь, которого зарегистрируют при инсталляции — будет системным админитратором. И хотя все — инсталляцию, настройки, в наших десктопах можно сделать через пользовательский интерфейс, часто, если пользователь-администратор владеет клавиатурой, все это сделать через консоль. Особенно это удобно, если не надо вводить root-ового пароля, используя sudo для отдельных команд, или sudo bash для интерактивных пользовательских сессий.

Поэтому, мы сделали так — самый первый пользователь, который создается при инсталляции (это либо единственный пользователь, либо «семейный администратор»), считается системным администратором, он внесен в группу wheel в sudoers и таким образом, получает большой бонус к удобству настройки и инсталляции, без необходимости вводить, и даже помнить root-овый пароль^[53]

Идея «прописать» первого пользователя в sudoers…

Отличная 28 80% Неплохая 5 14% Неважно 0 0% Ошибочна 2 6%

---

Ну, и как обычно, спросим…

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 8 20% Порадовала :) 26 65% Оставила равнодушным -_- 5 13% Огорчила :( 1 3%

• Мультизагрузочная флешка с несколькими версиями РОСЫ

Хотите сделать мультизагрузочную флешку с несколькими версиями РОСЫ?

Сергей Жемойтель делится инструкциями по созданию такой флешки с использованием grub4dos на примере 32-битной и 64-битной редакций ROSA Desktop Fresh KDE.

Ниже мы полагаем, что /dev/sdX — это устройство, соответствующее флешке

• Устанавливаем grldr.mbr в корень флешки

dd_rescue grldr.mbr /dev/sdX

• Создаем разделы с помощью fdisk или diskdrake
  • /dev/sdX1 — 200 Мб
  • /dev/sdX2 — все остальное пространство

• Форматируем разделы
  • /dev/sdX1 — ext2 (grub4dos)
  • /dev/sdX2 — ext4

• В /dev/sdX1 складываем grldr и menu.lst
• В /dev/sdX2 создаем директории для наших двух образов:

mkdir -p rosa/kde/x86_64 rosa/kde/i586

• Распаковываем образы в директории, соответствующие архитектурами
• Правим наш menu.lst и перегружаемся.

В menu.lst должно быть что-то похожее на это:

default /default

title ***** ROSA Linux KDE R2 x86_64 ******
root

title ROSA install
find --set-root --ignore-floppies /rosa/kde/x86_64/isolinux/isolinux.bin
kernel /rosa/kde/x86_64/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/x86_64/LiveOS rhgb splash=silent logo.nologo install vga=788
initrd /rosa/kde/x86_64/isolinux/initrd0.img

title ROSA Live
find --set-root --ignore-floppies /rosa/kde/x86_64/isolinux/isolinux.bin
kernel /rosa/kde/x86_64/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/x86_64/LiveOS vga=788 desktop nopat rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 noiswmd splash=silent quiet logo.nologo
initrd /rosa/kde/x86_64/isolinux/initrd0.img

title Verify and Boot ROSA.Desktop.Fresh.R2.2012.x86_64
find --set-root --ignore-floppies /rosa/kde/x86_64/isolinux/isolinux.bin
kernel /rosa/kde/x86_64/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/x86_64/LiveOS rhgb vga=788 splash=silent logo.nologo rd.live.check
initrd /rosa/kde/x86_64/isolinux/initrd0.img

title Install ROSA Desktop.Fresh R2 2012 in basic graphics mode.
find --set-root --ignore-floppies /rosa/kde/x86_64/isolinux/isolinux.bin
kernel /rosa/kde/x86_64/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/x86_64/LiveOS rhgb vga=788 splash=silent logo.nologo install xdriver=vesa nokmsboot install
initrd /rosa/kde/x86_64/isolinux/initrd0.img

title Rescue ROSA Fresh R2 2012 x86_64
find --set-root --ignore-floppies /rosa/kde/x86_64/isolinux/isolinux.bin
kernel /rosa/kde/x86_64/isolinux/memdisk
initrd /rosa/kde/x86_64/isolinux/sgb.iso


title ***** ROSA Linux KDE R2 i586 *****
root

title ROSA install
find --set-root --ignore-floppies /rosa/kde/i586/isolinux/isolinux.bin
kernel /rosa/kde/i586/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/i586/LiveOS rhgb splash=silent logo.nologo install vga=788
initrd /rosa/kde/i586/isolinux/initrd0.img

title ROSA Live
find --set-root --ignore-floppies /rosa/kde/i586/isolinux/isolinux.bin
kernel /rosa/kde/i586/isolinux/vmlinuz0 root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df rootfstype=auto ro rd.live.image live_dir=/rosa/kde/i586/LiveOS vga=788 desktop nopat rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 noiswmd splash=silent quiet logo.nologo
initrd /rosa/kde/i586/isolinux/initrd0.img

Note: обязательно наличие таких опций:

• root=live:UUID=40af22cf-3bab-48f4-841b-9d4fffdd87df
• live_dir=/rosa/kde/i586/LiveOS

первая указывает на диск, где лежит распакованный образ, вторая — на файл с запакованной системой (squashfs.img)

UUID нужного раздела можно узнать с помощью blkid:

# blkid
<…>
/dev/sdc1: LABEL="grub4dos" UUID="74e94dfa-6b1d-48ec-96bd-d96c66e55400" TYPE="ext2"
/dev/sdc5: LABEL="flash" UUID="40af22cf-3bab-48f4-841b-9d4fffdd87df" TYPE="ext4"
/dev/sdc6: UUID="2013-11-29-20-39-56-00" LABEL="ROSA.FRESH.KDE.R2.i586" TYPE="iso9660" PTTYPE="dos"
/dev/sdc7: UUID="2013-11-29-17-24-42-00" LABEL="ROSA.FRESH.KDE.R2.x86_64" TYPE="iso9660" PTTYPE="dos"

Здесь UUID нашего раздела с образами — «40af22cf-3bab-48f4-841b-9d4fffdd87df».

---

Для мейнтейнеров

— новые возможности ABF и полезные утилиты:

• В помощь мэйнтейнеру - spec-cleaner и rediff patch

Работа мэйнтейнера включает в себя много рутинных операций — адаптацию spec-файлов под изменяющиеся политики и инструменты сборки, переделку патчей под новые версии пакетов, обновление списка файлов приложения в пакете и так далее. Много рутины берет на себя инструментарий сборки — сам rpmbuild и вспомогательные скрипты из пакета spec-helper. Однако эти скрипты по определению не могут выполнить ряд задач — например те, которые требуют внесения изменений в spec-файлы.

Чтобы несколько облегчить жизнь мэйнтейнеров, мы включили в пакет spec-helper два новых скрипта, которые не применяются автоматически при сборке, а предназначены для ручного запуска человеком. Полагаю, названия скриптов говорят сами за себя — spec-cleaner и rediff_patch. Обновите в своей системе spec-helper, и эти скрипты появятся у вас в /usr/bin.

Spec-cleaner выполняет следующие действия:

• удаляет устаревшие и ненужные декларации — например, определение BuildRoot и Packager, зависимость от install-info, очистку buildroot и так далее;
• изменяет оформление использования макросов и переменных — переменные печатаются в фигурных скобках — %{const}, а макросы — без них — %{macro}. Такие изменения производятся только для макросов и переменных, определенных в самом rpm (а точнее, перечисленных непосредственно в скрипте spec-cleaner). Если вы сами определяете какие-то сущности, то их оформление скрипт изменять не будет;
• изменяет форматирование Summary — делает первую букву заглавной, удаляет точку в конце;
• удаляет явные определения переменных %{name}, %{version} и %{release};
• заменяет устаревшие макросы на современные аналоги;
• … и много других мелочей.

Пользоваться spec-cleaner — проще простого:

spec-cleaner my.spec

Если вы не хотите, чтобы изменения делались непосредственно в spec-файле, то можно указать второй параметр — имя нового spec-файла:

spec-cleaner old.spec new.spec

При разработке spec-cleaner мы старались прежде всего избежать ситуаций, когда новый spec-файл окажется некорректным — поэтому некоторые недочеты spec-файлов, исправление которых кажутся тривиальными, пока не реализованы.

Rediff_patch, как нетрудно догадаться, переделывает (точнее, пытается переделать) имеющийся патч под новую версию тарболла с исходным кодом. Прежде, чем пытаться использовать этот скрипт, внимательно прочтите инструкции ниже:)

1. запускать rediff_patch необходимо в директории склонированного проекта — там, где лежит spec-файл и патчи. Spec-файл используется для того, чтобы определить — как именно применяется патч;
2. в эту же директорию необходимо поместить новый тарболл с исходным кодом, для которого надо переделать патч;
3. непосредственно запуск скрипта выглядит так:

 rediff_patch <patch_ro_rediff> <tarball>

Если у вас в директории только один тарболл, то второй параметр можно опустить — rediff_patch возьмет единственный тарболл самостоятельно.

В ходе работы rediff_patch создаст директорию rediff_patch, распакует в нее новый тарболл и попытается применить к нему патч с параметрами, взятыми из spec-файла, добавив к ним опцию «--force» и используя значение fuzz по умолчанию (при сборке в rpmbuild используется «--fuzz=0»). Сейчас скрипт рассчитан на работу с тарболлами, при распаковке которых получается одна директория — обрабатывать tar-бомбы он откажется. В случае, если все сложится успешно, рядом с вашим патчем вы обнаружите новый патч с суффиксом «.new», а остальные следы деятельности скрипта (директория rediff_patch со всем содержимым) будут уничтожены. Если же что-то не заладится (например, патч применился не целиком), то вам останется директория rediff_patch с двумя поддиректориями — исходной и новой, к которой пробовали применить патч. Так что вы сможете вручную завершить работу, которую не получилось сделать автоматически, и уже самостоятельно сформировать новый патч с помощью стандартного diff -Naur.

Практика показывает, что большинство патчей все-таки требуют доработки, переделать их автоматически с использованием --force и более мягкого значения fuzz получается не очень часто. Однако даже если rediff_patch справился со всем самостоятельно, обязательно проверьте результирующий патч — ведь '--force' иногда может привести к нежелательному результату. А если rediff_patch не справился — что ж, по крайней мере, мы немного сэкономим на распаковке архива и первой попытке применить патч.

Оба скрипта довольно просты и прямолинейны. Как всегда, приветствуются отзывы, предложения, а главное — патчи:)

• Новости ABF - новые возможности консольного клиента, поиск по Advisory и другие радости

ABF — один из ключевых компонентов разработки всех дистрибутивов РОСЫ (и не только), а вот новости про него в «Точке РОСЫ» проскакивают редко. Англоязычные пользователи могут читать новости в блоге ABF, а вот для русскоязычной аудитории мы постараемся восполнить недостаток известий в нашем блоге.

Итак, вкратце основные улучшения ABF за последний месяц.

Во-первых, мы улучшили поиск по Бюллетеням (Advisories) в веб-интерфейсе. Теперь вы можете искать бюллетень не только по его идентификатору, но и имени пакета и по описанию бюллетеня (в которое обычно включают ошибки, исправляемые обновлением — в том числе и проблемы с безопасностью со ссылкой на соответствующий CVE).

Во-вторых, мы добавили возможность регулярной сборки проектов по расписанию. В настройках проекта теперь есть раздел, где можно указать — в какие репозитории и с какой периодичностью надо собирать пакеты.

Из других улучшений в веб-интерфейсе можно отметить возможность автоматической публикации в testing-репозиторий. Теперь можно либо явно запретить автопубликацию, либо опубликовать пакет в testing-репозиторий, либо выбрать пункт «По умолчанию» — в последнем случае автопубликация будет производиться (или не производиться) в соответствии с настройками репозитория.

Наконец, консольный клиент ABF также получил ряд полезных функций. Теперь с помощью клиента вы можете создавать проекты на ABF из локальных SRPM-пакетов, клонировать проекты и приписывать/убирать проекты к репозиториям.

Клонирование проекта осуществляется с помощью команды fork, которой необходимо указать имена исходного и целевого проектов, включая владельцев:

abf fork dsilakov/foo import/bar

Для создания проекта из SRPM-пакета, дайте клиенту команду «create», указав SRPM-пакет для импорта и имя владельца, для которого будет создан проект (владельцем может быть как пользователь, так и группа, но у вас должны быть соответствующие права на создание проектов):

abf create foobar.src.rpm import

Имя и описание проекта будут взяты из соответствующих тегов пакета.

Такая возможность оказалась особенно удобна для импорта большого числа пакетов. Загружать их по одному через веб-интерфейс — долго, для массового импорта через веб пакеты надо сначала выложить на какой-нибудь публично доступный сервер, а с помощью клиента можно все провернуть в одну строчку:

for p in *rpm; do abf create $p import; done

Плюс к этому, консольный клиент теперь может добавлять и удалять проекты из репозиториев посредством команд add и remove:

abf add -p import/foobar rosa2012.1/contrib
abf remove -p import/foobar rosa2012.1/contrib

Если вы находитесь в директории склонированного проекта import/foobar, то указание его имени с помощью опции «-p» можно опустить.

Напоминаем, что пожелания по улучшению ABF всегда приветствуются на трекере идей и пожеланий.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 0 0% Порадовала :) 10 91% Оставила равнодушным -_- 1 9% Огорчила :( 0 0%

• Mib-report - еще одна утилита в помощь мэйнтейнерам

Вот уже несколько месяцев мы используем Updates Builder для автоматического обновления пакетов в наших репозиториях. Инструмент неплохо справляется со своей задачей и количество обновленных с помощью него пакетов исчисляется сотнями. Однако практика показала, что одно из узких мест автоматического обновления — это не сам инструментарий, а передаваемая ему на вход информация. Дело в том, что Updates Builder собирает новые версии пакетов на основе данных, получаемых от Upstream Tracker'а. Тот, в свою очередь, проводит мониторинг апстрим-проектов на основе ссылок на исходный код, содержащихся в spec-файлах пакетов RPM. Но эти ссылки часто отсутствуют, а если они и есть, то не всегда актуальны — ведь обычным пользователям такая информация не нужна, при сборке пакетов на ABF она тоже не используется, и поэтому мэйнтейнеры не уделяют ей большого внимания. Как следствие, пробелов в колонке «Available in Upstream» на страничке ROSA Updates Tracker хватает.

Но помимо мониторинга апстрима, можно подглядывать и на репозитории других дистрибутивов. И здесь на помощь приходит утилита mib-report, изначально созданная нашими друзьями из группы Mandriva International Backports. Эта утилита сравнивает версии пакетов в разрабатываемых репозиториях 11 дистрибутивов:

• Rosa Desktop Fresh
• OpenMandriva Cooker
• Mageia Cauldron
• Fedora Rawhide (с учетом RpmFusion)
• PCLinuxOS
• Alt Linux Sisyphus
• OpenSUSE Factory
• PLD
• Gentoo
• Debian
• Ubuntu

При этом mib-report не просто сравнивает версии пакетов, но для RPM-based дистрибутивов выдает ссылки на Source RPM пакет:

$ mib-report --search firefox
Searching for package firefox…
Rosa: 25.0
http://abf-downloads.rosalinux.ru/rosa2012.1/repository/SRPMS/main/updates/firefox-25.0-1.src.rpm
Cooker: 25.0.1
http://abf-downloads.rosalinux.ru/cooker/repository/SRPMS/main/release/firefox-25.0.1-1.src.rpm
Mageia: 24.1.0
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/SRPMS/core/release/firefox-24.1.0-1.mga4.src.rpm
Fedora: 25.0
http://mirror.yandex.ru/fedora/linux/development/rawhide/source/SRPMS/f/firefox-25.0-3.fc21.src.rpm
PCLinuxOS: 25.0
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/pclinuxos/pclinuxos/srpms/SRPMS.pclos/firefox-25.0-1pclos2013.src.rpm
Sisyphus: 25.0
http://mirror.yandex.ru/altlinux/Sisyphus/files/SRPMS/firefox-25.0-alt1.src.rpm
Gentoo: 25.0
http://packages.gentoo.org/package/firefox
Ubuntu: 25.0
http://packages.ubuntu.com/firefox
Homepage URL:
http://www.mozilla.com/firefox/

А внутри SRPM-пакетов можно найти и архив с исходным кодом! Так что даже если мы не можем автоматически найти самую свежую версию программы в апстриме, мы можем «подсмотреть», что имеется в других дистрибутивах. И если у них есть версия новее — то можно взять SRPM-пакет и вытащить из него тарболлы с новым исходным кодом. Заодно обновить URL в нашем пакете, чтобы в следующий раз уже не лазить к соседу.

Именно такую возможность мы и внедряем сейчас в наш инструментарий автоматического обновления пакетов — теперь он будет учитывать не только информацию от Upstream Tracker, но и данные от mib-report. Хотелось бы подчеркнуть, что из SRPM-пакетов других дистрибутивов мы извлекаем только архивы с исходным кодом, а ни в коем случае не патчи (поскольку без вмешательства человека сложно понять, актуален ли патч для нас или нет) и не spec-файлы (поскольку у нас есть все основания считать, что наши spec-файлы — одни из самых простых и понятных, и нет нужды загромождать их монструозными конструкциями, используемыми во многих других дистрибутивах).

В общем, если обновление пакета сводится к пересборке нового тарболла из апстрима — то почему бы не поручить это дело роботам? Для людей найдутся и более интересные занятия, которые принесут гораздо больше пользы и пользователям, и апстрим-разработчикам. Ведь наверняка апстрим больше заинтересован в том, чтобы мэйнтейнеры дистрибутивов работали над улучшением их продуктов и присылали в апстрим патчи, а не соревновались — кто быстрее обнаружит выход новой версии.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 10 91% Порадовала :) 1 9% Оставила равнодушным -_- 0 0% Огорчила :( 0 0%

• Визуализация результатов деятельности Updates Builder

Многие читатели «Точки РОСЫ» наверняка в курсе, что некоторые пакеты в наших репозиториях автоматически обновляются до новых апстримовых версий посредством Updates Builder (точнее, этот инструмент отслеживает появление новых версий в апстриме и пытается их собрать на ABF).

Списки отслеживаемых им пакетов можно найти на вики — для РОСЫ и для OpenMandriva. Эти списки достаточно велики, однако в реальности у некоторых пакетов апстрим-версии выходят редко, для других не получается автоматически отследить новые версии… Каков же реальный объем работ, проводимых Updates Builder’ом на ABF?

Конечно, мэйнтейнеры и вообще пользователи ABF могут оценить это по общей статистике сборок, но теперь есть способ проще — скрипты запуска Updates Builder’а сами формируют отчеты о его работе и выкладывают на upstream-tracker.org. Страничка результатов для РОСЫ находится здесь, а тут можно посмотреть отчеты по OpenMandriva.

Названия колонок достаточно говорящие, но некоторые из них стоит пояснить дополнительно.

Колонка «Merged Automatically?» может быть непустой только для успешных сборок. Она сообщает — были ли изменения перенесены в основную ветку Git-репозитория непосредственно роботами. Полностью автоматический перенос производится только для пакетов из репозитория Contrib, для основных пакетов, поддерживаемых сотрудниками РОСЫ, отправляется Pull Request на перенос изменений из ветки auto_update.

Колонка «Errors Recognized» пытается подсказать, почему именно не собралась новая версия. Скрипты запуска Updates Builder’а анализируют журналы упавших сборок и выявляют часто встречающиеся причины — ошибку применения патча, отсутствие файла и тому подобное. Сейчас этот анализ очень прост и распознает меньше десятка ошибок, но в будущем мы надеемся расширить охват.

«Last Build Date» отражает дату последней попытки обновить пакет. Для каждого пакета в таблице содержится только одна строчка, соответствующая последней попытке Updates Builder’а собрать его новую версию.

Надеюсь, эти отчеты смогут дать общую картину того, чем занимается Updates Builder. Учтите, что эти отчеты отражают именно результат работы Updates Builder’а. Если на основе этих результатов человек доработал обновленный пакет и собрал его, либо принял Update Request, в отчете это никак не отразится.

• Применение наших инструментов разработчика в апстриме

В процессе разработки операционных систем наши разработчики и мэйнтейнеры используют огромное количество разнообразных вспомогательных инструментов (для сборки пакетов, анализа качества кода, анализа изменений и т. д.). Большинство из них — это свободные давно зарекомендовавшие себя инструменты, доступные почти в любом репозитории, такие как, например, rpmbuild, gcc, rpmlint, check, valgrind, diff и др. Но иногда встречаются задачи, для решения которых инструментов еще не было создано. В таких случаях мы создаем свои собственные решения для наших разработчиков. В случае, если эти инструменты могут быть полезны не только для нас, но и для сообщества, мы публикуем их исходные коды.

Примером одной из нестандартных задач был анализ обратной совместимости API/ABI системных библиотек в нашей операционной системе РОСА. Поскольку количество библиотек в системе достигало нескольких тысяч, то отслеживать вручную изменения во всех было слишком неподъемной задачей. Поэтому мы разработали инструмент ABICC, который может производить анализ совместимости изменений в автоматическом режиме. Исходные коды этого инструмента были открыты и постепенно все больше и больше разработчиков библиотек в апстриме пользуются этим инструментом для контроля совместимости API/ABI интерфейсов. В результате этого, нашим мэйнтейнерам библиотек легче обновлять их в системе.

Примерами библиотек, успешно использующих наши инструменты, являются: Pacemaker, MySQL++, Wireshark, Glibc, Enlightenment, libDAP++, libapt, Barry, PySide, PLplot и др. Также довольно большое число разработчиков библиотек предпочитают пользоваться нашим специальным сервисом Upstream Tracker, где они могут бесплатно добавить любую библиотеку и следить за изменениями в ее API/ABI интерфейсе. Примерами таких библиотек являются ImageMagick, V8 и др.

С нашими наиболее популярными open-source инструментами для разработчиков можно ознакомиться здесь. Среди них представлены следующие инструменты:

ABICC

инструмент для анализа совместимости API/ABI системных библиотек.

PkgDiff

инструмент для классификации файлов в пакете и визуализации изменений.

Java ACC

аналог ABICC для Java библиотек.

API Sanity Checker

автоматический генератор автоматических модульных тестов для Си/C++ библиотек.

ABI Dumper

извлечение ABI-интерфейса из debug-информации библиотеки.

Vtable Dumper

извлечение структур виртуальных таблиц из бинарных файлов библиотек.

Мы призываем использовать наши инструменты в апстриме. Это позволяет улучшить качество и стабильность API/ABI интерфейсов. А нам это облегчает и без того сложную работу наших мэйнтейнеров при последующем обновлении библиотек.

---

Конференции

Ну и для всех более-менее связанных с IT, будут интересны наши обзоры и видеозаписи IT-конференций:

• ProfsoUX — юзабилити-конференция в SPB. Обзор ProfsoUX-2013, приглашение на ProfsoUX-2014

...to delete

• Видеозаписи AgileDays-2014 — я хочу сыграть с тобой в игру…

В конце марта в Москве прошла конференция AgileDays-2014, посвященная методам продвинутой разработки, объединенных ценностями Agile Manifesto. Можно пафосно распинаться про ее глобальность, межгалактичность международность, но вот простые факты — почти тысяча человек, два дня, семь десятков докладов в пяти треках… это действительно было круто.

Темы — как всевозможные вопросы продвинутого менеджмента проектов («Мотивация», «Управление продуктами», «Планирование и оценки», «Организация») — в общем, как делать что нужно, эффективно, без насилия и с песней, даже, если для этого вообще нужно отказаться от всего перечисленного — оценок, мотивации, и менеджмента как класса.

Плюс — всевозможные инженерные практики эффективной разработки — тут и Test-Driven Development и Domain Driven Design, и Pair Programming и CQRS-архитектура приложений, Continuous Integration & Deployment и прочий DevOps во всех видах…

В целом, тут собрались самый разные участники — от корпоративщиков, сытых, но скучающих, до вечноголодных упоротых стартаперов — Agile-подходы рулят везде, даже в таких консервативных областях, как 1C-development (да, был доклад и про это).

И если еще недавно, многие, надув щеки, презрительно цедили «Agile? У вас секта… У вас нет по настоящему больших проектов… Это для мелких лохов, а у нас Enterprise… Это для скучного Enterprise, а у нас Продукт… Это для софта, а у нас ВеликийСистемноинженерныйПроектВека… Это для анархистов, не осиливших мудрости PMBOK, SWEBOK, BABOK, и кому не дадут бабок… », то сейчас видно — новые подходы к разработке просто ВЕЗДЕ, и даже нет смысла спорить и переубеждать консерваторов, ведь, как известно «выживание не обязательно». Просто самые продвинутые разработчики и менеджеры не пойдут в компанию, где «угорают по хардкору … и царит дух старой школы»™, а неповоротливость на все более динамичных рынках может убить даже старожилов — в IT не очень работают традиции стабильности «занимаемся программированиемѣ с 1913 года».

Доклады были реально круты — программный комитет^[54], отобрал лучших из лучших, самых опытных специалистов и крутых спикеров — прошло время скучных конференций советского стиля, тут же отзывы в целом таковы:

Очень крутые блиц-доклады на #agiledays, как будто на TEDe сижу. ©

Можно почитать более подробные отчеты: [2], [3], [4], [5], [6], [7], посмотреть фотографии [8] или двухминутное видео [9], но, весь этот жанр, «Wish you were here/Ах, как там было хорошо, жаль, что вас не было», несколько обидный для тех, кто там не был. И даже для тех, кто был, но не смог посетить все интересующие доклады — тут было пять треков, и хотя программа была тематически выровнена, не было конкурирующих докладов на схожую тему в одно и то же время, куча народу жаловались на невозможность разорваться.

---

Good news, everyone!™

Мы организовали и видеосьемку! Снято все, за исключением нескольких игровых мастер-классов — по нашему опыту, в таких интересно участвовать, но смотрят их мало :(.

Как обычно, самые лучшие стандарты информационного видео — монтаж с точной записью экрана, плюс чередование крупных и дальних планов, видна реакция зала^[55], по возможности звук с микрофона докладчика, ускорение скучных докладов до бодрого тема лучших спикеров TED, в общем, все как мы любим.

Да, были и проблемы^[56] — в паре залов было темно на сцене при ярком экране… — плохо видно докладчика… иногда не очень хорошо получился звук^[57]. Но в любом случае, все вполне смотримо. Более того, в рамках первоапрельской шутки, доклады были выложены в специально изуродованном низком качестве, но к моему ужасу, народ не понял шутки, и начал смотреть, благодарить и распространять…

На самом деле, тут я подумал, что просто опубликовать, было бы скучно, и решил сделать это в Agile/Lean-стиле. А именно — итеративно, со сбором пользовательского фидбека, и геймификацией.

Первый первоапрельский драфт был для совсем нетерпеливых, теперь все^[58] доклады опубликованы в бета-версии.

---

Еще раз — это тут Видео AgileDays-2014.

---

Оно все вполне смотримо, но там встроена отладочная информация («маркеры времени»), и возможно их еще можно будет отредактировать, вырезав секретное или неудачное, поправить планы и т.п.

А спустя месяц наверно (ну, как пойдет), будет выложена уже окончательная версия.

---

Так вот, раз ты дочитал до сюда, ты — явно неглупый потенциальный зритель. И я хочу сыграть с тобой в Игру.

Нет, это не страшная игра на выживание, это Win-Win игра, и я сразу объясню, кому и что тут интересно.

Да, мы хотим, что бы эта конференция стала не только местом тусовки единомышленников, а стала «Конференцией 2.0», распределенной в пространстве и времени, собравшей в интернете на порядок больше зрителей, и с сontinuous обратной связью. И нам всем, очень важен feedback:

• Докладчикам, чтобы увидеть ошибки и получить новые идеи по теме — ведь многие из них будут рассказывать эти доклады и на других конференциях.
• Программному Комитету — мы уже собирались на ретроспективу, и будем делать это еще — чтобы понять, где мы ошиблись — в выборе докладчика или темы, где мы не доработали, рецензируя слайды или аудируя (или недоаудируя) докладчика.
  • У нас есть первоначальный простой фидбек в виде олдскульного голосования разноцветными стикерами, по нему мы уже видим неожиданные результаты (потенциально сильный доклад собирает много красных стикеров), но понять — почему, этот инструмент не дает.
  • Еще будут обработаны электронные анкеты участников… но в любом случае, это фидбек сильно ограничен и аудиторией, и нашей планировкой докладов по трекам — возможно интересный доклад попал в малый зал (из-за различных ограничений, включая расписание докладчика), и не собрал ожидаемую аудиторию… в общем, тут же будет равноценных доступ к любому из докладов, и нам интересны и ваши оценки, и желательно именно отзывы. Да, многие писали более-менее полноценные обзоры, но, увы, таких людей мало, а некоторые из них уже стали «профессиональными зрителями конференций», посещающими по десятку конференций в год, несколько пресыщенными («на мой взгляд, ничего нового-с…»), и оторванными от практики,… А хотелось бы именно Труѣ-фидбека, особенно от тех, кто нечасто бывает на конференциях по разработке.
• А еще лично мне, чтобы узнать, есть ли какие косяки в видеомонтаже — рассинхрон потоков, или выбранный план скрывает что-то важное («докладчик явно что-то важное показывает на экране указкой/рукой, а экран/рука закрыт скринкастом»), или тема и мысли ОК, но, скажем темп изложения усыпляющий — можно ускорить. Или наоборот, слишком шустро, не поспеваю — можно замедлить.

Или случайно спалили что-то секретное на слайдах (на прошлом AgileDays было, и на этом уже). Или про что-то проговорились («А я не знал, что записывают…»). Все это пока можно починить.

• И это нужно вам, зрителям — написать комментарий по просмотренному докладу — несложно, гораздо проще, чем писать полноценный отчет. Написание хотя бы одноабзацевого комментария — прекрасный метод рефлексии и запоминания основных мыслей доклада. Плюс, может получится интересная дискуссия, завязаться интересные знакомства, может там даже будут пастись хедхантеры.

Так какие же правила игры?

• Там, на каждой странице доклада из категории прикручена самая популярная система комментирования DISQUS — в нее можно логиниться любыми соцсетями и т.п., если их нет, полезно в ней завестись, все равно она прикручена к 80% всех комментируемых сайтов в инете.
• Просмотрев доклад — напишите хотя бы одноабзацный отзыв. На самом деле никаких ограничений нет, можно писать и кратко, можно и романы, но текущий ужасный тренд в том, что многие разучаются выражать свои мысли, заменяя это простым лайканьем, ознакомившись с заголовком, и хотелось бы этот тренд переломить. Т.е. да, можно писать и короче, можно и длиннее, можно написать отзыв в своем блоге, а сбросить только ссылку — как вам удобно. Заодно можно указать и на вышеперечисленные проблемы, если было что-то не ОК, причем указать точно — ведь во всех видео сейчас вшиты временные маркеры, однозначно определяющие момент (Не «Вырежи, где я где-то во второй половине доклада проговорился о наших заказчиках», а «плиз, вырежите 7:34:56-7:35:10»). И т.п.
• Особо я хочу выделить тех, кто действительно просмотрел весь доклад, ведь очень многие готовы написать отзыв вообще по заголовку и аннотации («Пастернака не читал, но осуждаю…»). Тут есть хитрость — во все видео вшиты в случайных местах слова, связанные с Agile-тематикой. Эти слова появляются на пару десятков секунд фиолетовым цветом по центру видео. Если вы просмотрели видео и увидели это слово — запишите его, и укажите его в комментарии — такие комментарии я выделю особо.

Ну и геймификация такова — я отберу топ тех, кто просмотрит больше всего видео, откомментировав его («собирая слова»), и обязательно придумаю, как нестыдно, материально или нематериально наградить. Среди идей — и «доски почета/hall of fames», и может удастся выбить скидки на следующее посещение AgileDays, а может целое приглашения, или приглашение на другие конференции пораньше, ну и я разыграю какой-нибудь набор полезных в образовании гаджетов — диктофоны например…, что-нибудь USB-полезное, +рюкзаки/сумки с символикой AgileDays… единственное с предметами может быть геморрой с пересылкой в другой город, очень хотелось бы обойтись самовывозом.

Собственно, в такие игры я играю впервые, не знаю — сработает ли, мне бы очень хотелось бы, чтобы да. Игра будет наверно в ближайшие пару недель, или целый месяц, это особенно ценное время, чтобы Программный Комитет и авторы могли осмыслить по свежим следам результаты, косяки видеозаписи, по крайней мере, в интересных докладах^[59] были найдены. Потом я залью уже окончательные, возможно исправленные версии без временных маркеров.

Может действительно окажется, что комментировать непросто… ну в любом случае можно также и шарить-лайкать кнопками, это все тоже наверно хорошо и полезно, но как-то геймифицировать лайки мне кажется неэтичным — поэтому лайкате и шарьте только, если вам действительно понравился доклад.

Такие дела, если есть предложения по правилам — тоже welcomed, но мне кажется, идея неплохая, явно типа Win-Win.

Удачного просмотра!

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 17 65% Порадовала :) 7 27% Оставила равнодушным -_- 2 8% Огорчила :( 0 0%

• Russian Open Source Summit

В пятницу, 11 апреля, будет проходить наверно крупнейшая российская конференция по свободному софту — Russian Open Source Summit.

Крупнейшая — по количеству участников, ибо посещение бесплатное, сняты огромные залы в крутом отеле в центре Москвы, там полдесятка треков, и бесплатный обед и плюшки.

Что же там будет классного (кроме плюшек и обеда) — сложно сказать уверенно, но зато, мы можем рассказать и показать, что там было в прошлом году.

Ведь за всю историю конференции, там не велась съемка, кроме как прошлом году, когда нас внезапно (вечер до) позвали снимать, и мы попробовали запечатлеть доклады.

Несмотря на кучу накладок^[60] все доклады записаны, и вполне смотримы^[61].

Но, понятное дело, мало кто хочет перебирать все видео в поисках интересного, поэтому мы предлагаем краткий обзор-отчет с нашей тематической классификацией, из которой возможно будут видны основные темы и тренды, спикеры и аудитория.

И так как боюсь, все равно получится «многобукф» — скажу главное — не важно, какие будут доклады, приходите все равно. Будет и тусовка, там будем мы со своим стендом, и парой докладов, можно будет пообщаться-пожаловаться, увидеть, что «слухи о моей смерти несколько преувеличены», предложить интересные идеи , узнать, почему это не работает…

Ждем вас! Только не забудьте зарегистрироваться — Russian Open Source Summit.

А теперь поехали, обзор прошлогодних докладов.

Бизнес и Open-Source

Это наверно самая основное направление конференции — как организовывать бизнес на базе open-source решений. И тут наверно можно выделить кластеры, связанные с определенными майнстрим-проектами, и рассказы, о построенных на них продуктах и сервисах.

CMS/EMS

Собственно самым трендовым решением для корпоративной портальщины-документооборота было представлено Alfresco.

In Content Chaos? Alfresco Hybrid — Ending Content Chaos Securely + Corporate Model for OS Development. The Alfresco way Маркетинговые доклады от Denis Dorval, регионального вице-президента Afresco («крутизна, фичи, облака, самые-самые»). Доклады на английском, но вполне понятные.

---

Alfresco в проектах (Алексей Асафьев)

Немного странная тема, по названию вроде ожидается отчет о своей работе, о внедрении Alfresco и прикладных решениях, но тут же выясняется, что компания докладчика — дистрибьютор, и сама проектами не занимается. В общем, «мопед не мой», но с другой стороны, получился более объективный обзор возможностей и внедрений — чуть ли не сразу докладчик заметил, что «Alfresco может не все». Впрочем жаль, что не было обзора конкретных бизнес-кейсов, скорее теоретизирование, ссылки на отчеты консалтеров, хотя и с некоторыми странными утверждениями «Garther показал, что это единственная открытая операционная система, достойная рассмотрения». В целом « Раза в два дешевле, чем закрытые системы аналогичной функциональности»

Дискуссия была интересной — «А есть ли документация на русском? — Русский есть, а документация пользователи все равно никогда не читают… Если нужна документация, это уже недостаток… где окажется специалист, который не освоит систему в течении одного часа» «У нас в стране заказчик номер один, это государство… — Это у вас в стране… государство это могильщик технологий»

---

Примеры интеграции Alfresco (Алексей Ермаков) Вот это ближе к реальным примерам внедрений, о том, что Alfresco это платформа для очень разных и крутых решений, выходящих за рамки портальчиков («Массовый ввод с распознаванием через Kofax» и т.п), но все равно, модератор был недоволен отсутствием четкого «маркетингового послания» — «СПО-профессионалы рассказывают аудитории на 90% состоящей из СПО-профессионалов, что такое СПО.», вопрос же в том … «как продать СПО? Ты инженер? Почему ты инженер, хочешь быть сейлом?». Надеемся, в этом году в аудитории будет больше business people, и таких жалоб не будет.

---

Alfresco. Гибридное решение (Елизавета Астафьева)

Тут речь об использовании SAAS Alfresco Cloud, причем совместно с локальными инсталляциями альфреско, вроде все понятно, типичный маркетинговый доклад с перечислением фич, тут удивляет скорее наблюдаемое непонимание публики — «чем это лучше чем гугл?», «…вы говорите хранится в амазоне^[62] — а надо ли мне аккаунт в амазоне, а то русские кредитки не берет».

Open Source ERP

Все крутилось вокруг линейки *piere (ADempiere, iDempiere). сделанной изначально одним из архитекторов eBussiness Suite.

Community Open Source ERP Project (Reduan Daniel Oon) Доклад на английском, но докладчик малазиец, и его спич понятен даже слышавшем только русско-школьный английский. Аккуратный троллинг SAPа («у меня есть друзья-саперы»), история линейки *piere, история открытий и закрытий кода, форков и т.п.

Сейчас iDempiere добротный продукт с нестыдным интерфейсом и достаточными фичами, возможно не очень понятных людям не в теме, ведь «про ERP все знают, что это скучно»©. А так докладчик напирал, что это да, опенсорс, но не бедное придонное существование («операционки, СУБД»), а жирный бизнес-уровень, где круто зарабатывать на внедрениях. Планы мирового господства — «Япония уже наша». Планы захвата «голубого океана». К сожалению дорассказать все докладчику явно не дали — «время!», были смешные вопросы — «Много людей вы увольняете в вашей компании? — Да нет у меня никакой компании, тут же сообщество, я консалтер-путешественник. Хотя увольнять — да, приходится, и много».

---

Существуют ли open-source бизнес-приложения для СМБ? (Алексей Сорокин) В оппозит прекраснодушным историям о мировом господстве, офигительные истории о попытках open-source ERPзации грустного российского SMB-рынка компанией «Siberium» SMB=small and medium bussiness в РФ — это почти все, у кого нет ярда, и надо идти. При этом обычно есть и полноценные процессы, и сложная логистика — но при невысоких оборотах. Требования к функционалу, точности планирования и настраиваемости — большие, но платить много не могут, а оракловый ERP=150лимонов («При внедрении ерп мы часто не можем назвать заказчика, они боятся — у тебя появилась ЕРП - значит ты богат»). Взлететь компании удалось на учете, как не прикольно звучит, ватников на Сахалине, но жизнь весьма непроста.

• «Проекты выше ляма баксов скоро кончатся, надо искать новые рынки»
• «Пощупали одинэс, вляпались, еле отмылись, отошли… готов дискутировать, что это трагедия российского IT рынка»
• «снизил порог входа ниже плинтуса, не нужно знать даже латиницу... это плохо, рынок наводнен людьми работающими за пять копеек и обещающих решить все проблемы в одно касание.… когда мы туда приходим, люди уже потратили деньги»
• «повысить эффективность организации за счет айти - это миф. только за счет ампутации головы у среднего менеджера»
• «эксперимент, OTRS как сервис-деск в ЖКХ... не страшно? — страшно. там ребята конкретные из мордовии.»
• «Не верь, не бойся, не сотрудничай с госсектором, его не интересует лонгтермсуппорт, его интересует шорттермоткат».

Реально, наверно самый интересный доклад на конференции, рекомендую. Растрогало и модератора, очередной раз призывавший — «я хочу видеть [в зале]людей с деньгами!»

Остальное

Опыт интеграции СПО в компаниях среднего и малого бизнеса и в сфере образования (Сергей Бессонов) — Доклад от широко известного в узких кругах Dr.Acelerа. Доклад бодрый, сверхкороткий, с главной мыслью — «Нельзя просто придти и внедрить СПО». «СМБ? Торговец запчастями? — он не умеет отправлять SMS…». «Постоянных сотрудников у нас человек шесть, заказчиков под сто» Влезать надо от учета пользователей. Сначала каталог пользователей/профилей + почта (Zimbra), потом можно заходить с альфресками. Рекламировался безимянный продукт с вкусной интеграцией «все хорошее в одном флаконе» (там и Zimbra+Asterisk+XFS+Moodle+FreeNX+Openmeetings+…), обещали что у него будет свой сайт — но так я ничего и не нашел, так что просто оставлю здесь ссылку на их решения.

---

Организация виртуальных ситуационных центров и виртуальных когнитивных центров на базе СПО Интересные истории, вроде для государства сделаны недешевые, но вполне нестыдные штуки, аналитические центры принятия решений, с Bussiness Intelegence, научным планированием и прочей кучей матана, потенциальный «Госплан 2.0»^[63] но, похоже, ими до сих пор забивают гвозди, используя на уровне региональных «госбагтрекеров».

---

OpenFlow. Технологии построения масштабируемой и отказоустойчивой сети (Александр Кривенцов) — Ребята пощупали-поигрались с OpenFlow — перспективной технологией программно-конфигурируемых сетей, используя open-source софт для контроллеров (POX) и т.п. Помоделировали нагрузку, автопереключение, живучесть — в общем, призывают пробовать, применений масса, включая такие грустные, как СОРМ.

Облака

В Cloud-buzzword свалилось куча докладов, не все их них вообще имели хоть какое-то отношение к open-source.

Облачный пользователь: каким он становится и к чему нужно быть готовым (Александр Прозоров) — Вообще не про опенсорс, так, размышления о неизбежности эволюционной победы облачных сервисов («от варварства — к Saas»), как аутсорсинг победил нормальную работу (насамомделенет™) с какими-то запредельными цифрами («полтора миллиона компаний»). В конце, подведя к мысли «нужен грамотный управленец» — самореклама + реклама Megaplan, который на слайде почему-то отнесен к СПО. Из интересного — в конце доклада случилась бодрая дискуссия на тему понимания термина «воронка продаж» (и да, склонен согласится с нападавшим известным IT-журналистом) — не каждая воронка — воронка продаж.

• Облачные сервисы на СПО — секреты успеха. Специфика российского рынка (Ирина Гришанова) — Продажа OpenStackoвских облаков в России.

СПО и Закон

О формировании комфортной правовой среды для компаний-разработчиков ПО (Николай Комлев)

• минимальные работы, легализация удаленки.
• война с профсоюзными лобби.
• бабла не дают, энтузиазм кончается.
• «Лоббисты встречавшиеся с Путиным, почти договорились, но сменилось правительство» — кулсторибро…

---

Юридические вопросы свободного программного обеспечения в России и перспективы создания российской свободной лицензии — больная тема, ибо до сих пор нет ни одной юридически корректной российской свободной лицензии (переводы GPL/MIT/… юридически полноценными не являются, применять можно, но непросто и непрактично). Доклад явно делал настоящий юрист — запутан адово, на «слайдоментах» законодательные дампы… я смотрел несколько раз, но все еще путаюсь.

• «свободное программное обеспечение — не техническое, а юридическое понятие»
• «эта презентация — мой продукт, лицензированна под Creative Commons, но это несвободная лицензия».

Про перспективу создания своей лицензии, кстати, почти ничего не было, кроме юридических доказательств, что вроде бы возможно, и вроде нужно — ибо GPLи принципиально непереводимы (FSF фонд не авторизует переводы), с другой стороны, похоже на изобретение «национальной арифметики». Народ из зала требовал юридической оценки «закрывания кода астралинуксом», дискуссию эту жестко пресекли модераторы.

---

Практика разработки и сертификации „смешанных“ программных решений и платформ (Роман Евдокимов) Доклад скорее рекламно-маркетинговый — если нужна сертифицированная система, то лучше не париться, и обратиться к тем, кто умеет готовить. Ребята причем сертифицируют не только опенсорс, а все что надо.

Коммьюнити-темы

Роль сообществ в развитии СПО-проектов (Александр Рябиков)

• «не все опенсорсы одинаково полезны — сообщество — признак, что ОК».
• «было бы сообщество, а код появится»
• «Что бы не говорили злые языки, РАСПО - это сила, которая помогает нам в решении наших проблем.»
• «Сообщество нужно оформлять только юридически, только хардкор.»

---

Организация открытого сообщества на примере Fedora

Доклад крут выбором докладчика, — про Федору рассказывала Александра Федорова! Так вот ты какая, Федора-тян.

• «толпа это белый порошок, сообщество это кристаллы» (метафоры очень ОК).
• «макет сообщества в натуральную величину»
• «в сообществе необходима бюрократия, регламенты и модерация»
• Рассказы о структуре кучи рулящих Fedoroй комитетов.

---

Мировой опыт использования СПО в целях кибербезопасности (Милан Прохаска) Несколько пафосный глобальный обзор «про космические корабли, которые бороздят просторы большого театра» — там и статистика с хекзабайтами, и ужасы бигдатаворд, и что 90% всей инфраструктуры — опенсорс… Но доклад веселый, с шутками — «Мы, сербы, как-то стали весьма озабочены безопасностью…»

---

Cистема управления облачным кластером на основе открытых технологий (Вадим Подольный) — вообще-то, «мы занимаемся военными разработками, но иногда мы делаем что-то для себя, что можно продать как гражданский продукт». Получилось хитрое удаленное управление рабочим столом.

---

Безопасность

Безопасность национальных ИТ-систем. Как это делается? (Андрей Бешков) Наверное, самый бодрый доклад по инфобезопасности был от техноевангелиста Микрософта.

Классическая апология MICROSOFT, как безопасной системы, с нападением на опенсорс скопом. Таблицы консалтинговой компании SECUNIA, классические сравнения теплого с мягким, количество уязвимостей в ядре Windows против дыр в прикладных PHP-пакетах. Но разумеется, есть и рациональное звено — идеализм Эрика Реймонда, что базарная модель разработки сама по себе даст безопасность, очевидно, не работает — неоднократные фейлы в OpenSSL, когда пару лет не могут обнаружить проблему, общеизвестны. Да и бодрый евангелист-докладчик, вошедший в пятерку ведущих спикеров по информационной безопасности — рекомендуем к просмотру, вне зависимости от ваших софтополитических воззрений.

---

К вопросу создания систематического выявления компьютерных атак на интернет-ресурсах (Валерий Иващенко) — ох, уж этот неуверенный канцелярит в именовании докладов, сразу видно старшее поколение. Истории об ужасах интернета в духе «однажды я забыл в интернете почтовый сервер и через пару часов его уже растерзали». С другой стороны, может именно такие рассказы это замотивирует некоторую аудиторию озаботиться информационной безопасностью, так что ОК.

Коммерческие средства обнаружения компьютерных атак, сертифицированные ФСБ России (Дмитрий Сатанин) — доклад настоящего ФСБшного сертификатора. В открытом доступе! «Я вообще не совсем понимаю, что такое свободное программное обеспечение… Свобода — это для существа мыслящего»©. Ну и обзор собственно тех счастливчиков решений, который повезло пройти сертификацию.

Наши доклады

Был маркетинговый Комплексный подход при построении ИТ-систем на базе СПО или Как мы „соображаем на троих“ (Юлия Никитина-Атилла) и осмысленно технологический Автоматизация разработки СПО с помощью современных средств и технологий (Владимир Рубанов) про наш путь максимальной автоматизации при дистрибутивостроении.

Вендоры за опенсорс

Поддержка проектов СПО в Dell (Антон Банчуков) — вендорский «мы за все хорошее и против всего плохого» доклад — маркетинговые слоганы, футуризмы в духе «космические корабли бороздят…», кстати, да буквально «Dell-Ubuntu-Sputnik™». Ну и да, поддержка опенсорс от клиента «линуксбуки Sputnik» до серверных технологий (OpenStack, Cloudera). Ну молодцы, чо. Наверно, к поддержке СПО они относят и плату за установку Firefox.

В ту же кассу бодрый англоязычный Open Source and Free Software (Gerald Pfeifer) — это про SUSE.

---

Дочитали до сюда? Удивительно… Но там еще была куча докладов, от скучноватых выступлений чиновников и длинных толковищ круглых столов и до … до чего не дошли руки обозреть.

Все лежит тут, и скорее всего, мы снимем и доклады на этом ROSSe.

Но все равно приходите на ROSS-2014, ибо доклады не главное, рулит живое общение и нетворкинг.

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 6 43% Порадовала :) 5 36% Оставила равнодушным -_- 2 14% Огорчила :( 1 7%

• FOSDEM 2014 - Свободное ПО в Европе

Проникнувшись идеей личных встреч разработчиков и воодушевившись первой встречей в Праге, ассоциация OpenMandriva решила не оттягивать следующую встречу и совместить ее с проведением FOSDEM — одной из крупнейших конференций по открытому свободному ПО, проходившей 1-2 февраля в Брюсселе. Естественно, хотелось не только других посмотреть, но и себя показать, так что на FOSDEM’е был организован стенд OpenMandriva, а на самой конференции можно было услышать два наших доклада — совместный доклад Александра Хрюкина из OpenMandriva и Дениса Силакова и Алексея Вохмина из РОСЫ про разработку ARM-версии дистрибутива на ABF, а также доклад Анурага Бхандари про разработку веб-приложений с помощью системы Meteor (сам Meteor никакого отношения к OpenMandriva не имеет, но Анураг в шляпе от OpenMandriva вполне неплохо нес бренд дистрибутива в массы).

За два дня FOSDEM посетило несколько тысяч человек — организаторы дают расплывчатую оценку «5000+», но поскольку вход абсолютно бесплатный, свободный и не требует никакой регистрации, то точное число узнать вряд ли получится. Посчитать посетителей можно только косвенно — например, по количеству подключений к dhcp-серверам wifi-сети. К слову, wifi работал без нареканий, но организаторы решили провести эксперимент и основную сеть сделали IPv6-only. Судя по достаточно большому количеству вопросов от людей, которые вроде бы подключались к wifi, но до интернета достучаться не могли, далеко не все настольные системы на данный момент готовы переехать на IPv6 прозрачно для пользователей. Впрочем, организаторы сжалились, параллельно развернули сеть с IPv4.

Возвращаясь к количеству посетителей, цифра 5000 на самом деле может оказаться и заниженной. Ведь всего на конференции было около полутысячи докладов, презентаций и круглых столов (и значит, почти столько же докладчиков). Доклады шли параллельно в 23 аудиториях, каждая из которых вмещала минимум несколько десятков человек, а многие — и несколько сотен. Конечно, на некоторых докладах залы были заполнены процентов на десять, но на некоторых из тех, что я посетил, было более двухсот слушателей.

К тому же помимо докладов, народ активно изучал стенды представленных на конференции проектов и общался с разработчиками. Стендов было 45 штук, и пообщаться было с кем. Из дистрибутивов помимо OpenMandriva были представлены Fedora, OpenSUSE, Debian, Mageia, а также дистрибутив для детей — DoudouLinux. Представлявший его товарищ сам похож на большого ребенка, так что есть основания полагать, что он знает, что делает:) Интересно полное отсутствие Ubuntu, хотя на машинах для общего пользования, стоявших в коридорах, была установлена именно эта ОС. Коммерческий Red Hat как дистрибутив тоже представлен не был, однако сама компания являлась основным спонсором конференции и ее сотрудники представили достаточно много докладов про открытые технологии, продукты и процессы, развиваемые и используемые в крупнейшем коммерческом Linux-вендоре.

В частности, были несколько докладов от разработчиков Foreman — нового инструментария для управления пулом серверов (как реальных так и виртуальных и витающих в облаках). Foreman предоставляет средства развертывания ОС на множество серверов и интегрируется с системами управления конфигурацией — на конференции рассказывалось о Puppet и Chef. Авторы также обещают интеграцию с Katello — в совокупности с системой управления репозиториями Pulp эти продукты должны прийти на смену Spacewalk/Satellite в будущих поколениях RedHat Networks. Правда, пока что интеграция Foreman с Katello сводится к наличию ссылок на интерфесый друг друга. Pulp на данный момент умеет работать только с репозиториями, созданными с помощью createrepo, но разработчики высказали заинтересованность в поддержке других платформ. Внутри РОСЫ мы уже сделали вполне работоспособную поддержку urpmi-репозиториев в Pulp — теперь на очереди общение на эту тему с апстримом. Может, подскажут — как сделать еще лучше:)

Помимо рассказов о продуктах и технологиях (большинство из которых так или иначе были связаны с облачными технологиями и обслуживанием большого количества машин), представители RedHat делились некоторыми подробностями внутренней кухни компании и процессов разработки. Можно было узнать, что инженеры RedHat активно используют Gerrit для инспекции исходного кода, Nitrate для управления тестами, Dogtail для автоматизации тестирования приложений с графическим интерфейсом. Автоматизации тестирования вообще уделялось достаточно много внимания, ведь компаниям, предоставляющим коммерческие услуги, необходимо заботиться о качестве своих продуктов. А как показывает практика, полагаться в сфере тестирования исключительно на сообщество — не самый хороший вариант. Поэтому над тестами в RedHat работают активно, и по возможности стараются все автоматизировать.

Прогресс в этой области, безусловно, есть, и автоматические тесты активно используются для регрессионного тестирования различных приложений — как консольных, так и графических. Например, был неплохой доклад про cwrap — обертку для libc, позволяющая тестировать клиент-серверные приложения без развертывания реальной сети и виртуальных машин. Для тестирования GUI разработчики используют AT-SPI, что позволяет не привязываться к внешнему виду приложений, темам DE и прочим элементам оформления, не имеющим отношения к функциоанлу программы. Теоретически, это делает возможным использование одних и тех же тестов для разных версий одного и того же приложения в разных версиях ОС, но и здесь есть нюансы — например, при изменении структуры меню все равно придется модифицировать тесты, имитирующие клик на тот или иной пункт. В общем, забот по поддержке автотестов у RedHat хватает, но компания считает эти затраты обоснованными и смотри в будущее с оптимизмом. А заодно планирует в будущем «привить» культуру разработки с автоматическим тестированиям в Fedora.

Представители других дистрибутивов докладов особо не делали, хотя, я думаю, товарищи из SUSE тоже могли бы рассказать много интересного. Зато был показательный доклад от Debian, вполне дающий представление о процессе разработки этого дистрибутива — доклад назывался Reproducible Builds for Debian и, как нетрудно догадаться, был посвящен проблеме невоспроизводимости сборок многих пакетов в этой системе. То есть на основе одного и того же исходного кода и при использовании штатных инструментов Debian у разных разработчиков могут получиться несколько различные приложения, а какой из них попадет в репозитории — загадка. Так что исправив небольшую ошибку и пересобрав пакет, мэйнтейнер может случайно внести в него и еще ряд изменений по сравнению с предыдущей версией, обусловленные изменением сборочного окружения. Наличие проблемы создатели Debian признают, но вместо создания единой среды сборки типа ABF, OBS или Koji, которая была бы единственным источником пакетов в репозиториях, они предпочитают работать над «допилкой» инструментов сборки. Согласно тезисам доклада, после некоторой доработки инструментария в ходе массового эксперимента в сентябре идентичность сборок была достигнута для 1200 из 5000 пакетов. Авторы считают это неплохим достижением и потихоньку двигаются вперед.

Немало было обсуждений еще одной вечной темы — нивелирования различий между дистрибутивами для разработчиков приложений и вендоров. Ведь далеко не все разработчики горят желанием тестировать свои творения во всех существующих системах, но при этом нередко с подозрением относятся к мэйнтейнерам, видоизменяющим их продукты. Как сказал в кулуарах один из апстрим-разработчиков: «We need a way to protect us from maintainers». Впрочем, каких-то серьезных подвижек в этой сфере пока не предвидится. Как не предвидится их и в смежной проблеме распространения приложений — ведь собирать пакеты под каждый дистрибутив достаточно накладно, даже если использовать среды наподобие ABF или OBS, а сделать что-то универсальное, способное корректно устанавливаться в любой ОС — совсем непросто. На FOSDEM в очередной раз «всплыл» проект Listaller, три года назад слившийся с Autopackage, а сейчас активно поглядывающий на AppStream.

Для достижения кросс-дистрибутивности Listaller использует в качестве бэкенда хорошо известные PackageKit. Для решения проблемы зависимостей автор Listaller, не мудрствуя лукаво, предложил статически линковать приложение со всем, чем нужно. Вопрос отслеживания ошибок/уязвимостей в библиотеках, которые оказались встроены в приложение? Ну да, хороший вопрос, ну так что поделать — такова цена универсальности, придется в случае багов в библиотеке пересобирать и обновлять приложение. Заодно автор объяснил ненужность всяких post-скриптов в пакетах, пообещав, что Listaller выполнит все, что надо, автоматом — запустит ldconfig в случае установки библиотеки, перезапустит http-сервер при установке веб-приложения и так далее. В общем, Listaller умеет делать примерно то же самое, что файловые триггеры в нашем rpm5. А опыт использования файловых триггеров показывает, что несмотря на все свое удобство, предусмотреть все возможные ситуации и совсем избавиться от post-скриптов они не позволяют даже в рамках одного дистрибутива. Да и кросс-дистрибутивность многих файловых триггеров тоже вызывает сомнения.

В общем, подход Listaller на деле оказывается даже более ограниченным, чем способ, рекомендованный стандартом Linux Standard Base (LSB) еще десять лет назад. LSB рекомендует создавать пакеты формата RPM (и устанавливать их в debian-based системах с помощью alien), не делать никаких внешних зависимостей, кроме «lsb» (а любой дистрибутив, совместимый со стандартом, эту зависимость предоставляет), но при этому советует статически линковать только те библиотеки, которые не входят в LSB. Так что по крайней мере можно не линковать статически Qt, Gtk, ALSA и другие распространенные библиотеки.

Как итог — несмотря на долгую историю развития, ни Listaller, ни Autopackage, ни AppStream пока не снискали большой популярности у вендоров приложений. Однако актуальность проблемы никуда не делась, и искать какие-то пути ее решения надо.

Наконец, отмечу, что все больше разработчиков приходит к мысли, что большинству пользователей вообще-то без разницы, как устроены пакеты в репозитории — они всего лишь хотят устанавливать себе готовые приложения, а что такое «пакет» им и знать не обязательно. И постепенно начинают обдумывать, как бы пользователям предоставить что-то проще пакетного менеджера — например, Центр Приложений, как у Ubuntu. Так что и наш разрабатываемый Software Center вполне в общем тренде, только гораздо ближе к завершению, чем задумки большинства зарубежных коллег.

Немало интересного можно было узнать и на стендах. Разработчики KDE показывали будущий KDE5 — правда предупреждали, что на экране работают только часы и кнопка «Пуск» . На вопрос о Kiosk, который многие находили полезным для enterprise-использования, но который не был перенесен в KDE4, разработчики ответили просто — никто из активных участников проекта KDE не заинтересован в Kiosk, и даже не совсем не в курсе, что точно от него требуется. Так что если вы хотите допиливать Kiosk — you are welcome. А то, мол, все только жалуются на его отсутствие, а помочь сделать не хотят. Да и вообще — Kiosk на самом деле можно использовать в KDE4, правда GUI у него работать не будет:)

Разработчики Gnome высказывали схожий подход к просьбам пользователей — ведь в Gnome тоже неплохо знают, что этим пользователям нужно, а если чего-то не хватает — patches are welcome.

На стенде MySQL и Percona можно было обсудить состояние MySQL, его перспективы и взаимосвязь с MariaDB. Представители Percona со скепсисом отнеслись к слухам о возможном свертывании активности самого MySQL и сказали, что не очень понимают тенденцию дистрибутивов переезжать на MariaDB (конечно, если не считать того аспекта, что MySQL — продукт классового проприетарного врага, а MariaDB вроде как поближе к сообществу). Сама Percona стабильно базируетсяна кодовой базе MySQL, никаких проблем с исправлением ошибок и уязвимостей не наблюдает и переходить на MariaDB не собирается. Может, немного лукавят, но возможно они и правы. В конце концов, я бы не сказал, что во время пребывания MySQL под крылом Sun жизнь в нем кипела, а потом прекратилась. В проекте по развитию инфраструктуры LSB мы использовали MySQL очень активно, и временами натыкались на ошибки, которые висели в баг-трекере MySQL годами, сталкивались с регрессиями и вообще старались очень аккуратно подходить к обновлениям MySQL. С переходом MySQL под крыло Oracle не заметили каких-то ухудшений в этой ситуации; впрочем, насчет улучшений утверждать тоже не берусь, но и насколько лучше в этом плане MariaDB — тоже вопрос открытый.

Интересной оказалась секция, посвященная свободным текстовым процессорам, где рассказывали далеко не только про Libre- и OpenOffice. Скорее можно было узнать, что для многих других проектов эти монструозные офисные пакеты выступают хорошей площадкой для экспериментов. Например, разработчик GDB рассказывал, какие улучшения происходят в последних версиях отладчика по просьбам разработчиков LibreOffice. А эти самые разработчики в ответ жаловались, что GDB при отладке их продукта все еще временами подвисает и подтормаживает:) Схожее взаимодействие наблюдается между Eclipse и OpenOffice — во всяком случае, разработчики CDT сделали немало улучшений именно по запросам разработчиком открытого офиса. Что касательно непосредственно офисных пакетов, то мне понравилась презентация использования GPU при работе LibreOffice Calc, а также рассказ про использование групповых политик (GPO) для управления конфигурациями LibreOffice на клиентских машинах. В этом же докладе авторы нахваливали RemoteRoot — новый инструмент для удаленного обслуживания большого парка машин, не требующий (в отличии от того же Katello) наличия специальных агентов на клиентских машинах. Правда, разделы Documentations и Downloads нового инструмента сейчас гордо заявляют «Very soon, please be patient!», так что попробовать это новшество в деле пока не получится.

Техническими докладами конференция не ограничивалась. Много слушателей привлекли доклады на юридические темы, рассказы про формирование сообщества и работу с ним и прочие аспекты, немаловажные при создании любого продукта. Было много докладов с научным уклоном — например, про эвристические алгоритмы для решения NP-сложных задач. Целая секция была посвящена инструментам работы с графами — но до туда никто из нас не добрался, так что можем только отослать на сайт FOSDEM за тезисами, видео и презентациями.

В завершение конференции мы побеседовали с представителями Google Summer of Code, в рамках которого сотрудники РОСЫ не раз выступали в роли менторов от Linux Foundation. Обсудили возможность участия в этом году OpenMandriva как менторской организации — представителям OMV тоже такая идея понравилась, так что они попробуют побороться за право участия, и сейчас идет сбор идей для студентов. В конце концов, старая Mandriva участвовала в GSoC, почему бы не попробовать и ее правопреемнице? Конечно, было бы неплохо там поучаствовать и РОСЕ. Но пока объективная реальность такова, что у европейской OpenMandriva шансов существенно больше, чем у российской компании, пусть даже и с международным сообществом. Однако представители РОСЫ вполне могут предложить свои идеи OpenMandriva — ведь у нас много общего в плане кодовой базы, OpenMandriva использует огромное количесвто наработок РОСЫ, так почему бы не поработать совместно над студенческими проектами? На представление идей и подачу заявки от организации есть еще чуть больше недели.

Заодно представителям GSoC был задан вопрос, волнующий студентов из России и ряда близлежащих стран — почему Google в прошлом году перестал присылать в эти страны футболки, ручки и прочие наклейки, ограничившись выплатой стипендий и рассылкой сертификатов. Ведь многие студенты радуются футболкам ничуть не меньше, чем стипендии:) Ответ был таким, что решение было принято на высшем уровне, и точные его причины неизвестны — может, с таможней что-то не так, а может решили упростить логистику. И в этом году улучшений не планируется.

Вот такая вот европейская конференция по свободному ПО. По масштабам российским конференциям до FOSDEM еще расти и расти. Но зато мы гораздо лучше организуем запись докладов:)

Сорри за много букв, но конференция действительно нереально большая, и выше изложено только то, что вспомнилось навскидку, и что я видел своими глазами:)

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

Надеюсь, эта новость вас…

Ввела в экстаз ^_^ 6 26% Порадовала :) 15 65% Оставила равнодушным -_- 1 4% Огорчила :( 1 4%

• OpenMandriva Association - встреча в Праге

С 22 по 24 ноября в Праге прошла встреча OpenMandriva Association — первая встреча основных участников разработки OpenMandriva, призванная наладить личные связи друг с другом, подвести итоги подготовки релиза OpenMandriva 2013.0, а также обсудить планы на будущее. Поскольку разработчики РОСЫ принимают участие в создании OpenMandriva, то и мы там были представлены.

География участников встречи получилась очень обширной — были участники из Бразилии, Германии, Индии (правда, удаленно — из-за проблем с визой), Италии, Польши, России, США, Франции и Швейцарии.

Сидят (слева направо): Denis Silakov, Marco Benatto, Cristina (rugyada), Maik Wagner, Kate Lebedeff, Jean-Claude Vanier

Стоят (слева направо): Robert Xu, Crispin Boylan (crisb), Bernhard Rosenkränzer (bero), Jochen Schönfelder (arisel), Nicolò Costanza, Raphaël Jadot (ashledombos), Tomasz Gajc (TPG), Colin Close (itchka), Paulo César Pereira de Andrade (pcpa)

Большое внимание было уделено вопросам организации разработки дистрибутива. Прошедший год характеризовался в первую очередь созданием фактически нового коллектива, формированием различных команд (ответственных за инфраструктуру, локализацию, собственно разработку и так далее), притиркой участников друг к другу. Неудивительно, что процесс подготовки первого релиза несколько затянулся — с момента выход Alpha-версии до финального релиза прошло пять месяцев. Однако теперь разработчики набрались необходимого опыта, наладили взаимоотношения и готовы думать о том, как работать над следующими релизами. В частности, все согласились с необходимостью иметь четкий план подготовки релизов со сроками и действиями, которые необходимо к этим срокам сделать. Была высказана идея в потребности менеджера проекта для разработчиков, который бы выполнял в первую очередь организационную работу — помогал с планированием, координировал усилия и тому подобное. Заодно в первом приближении сошлись на том, что следующий релиз следует ожидать примерно через год.

Из различных организационных моментов, которые обсуждались на встрече, можно отметить следующие:

• регулярная сборка ISO-образов со всеми обновлениями — чтобы после установки с образа не было необходимости сразу же ставить сотни обновленных пакетов; заодно рассмотрели и вопрос о налаживании выпуска DVD-дисков и USB-флешек с OpenMandriva для раздачи на различных мероприятиях и, возможно, для продажи;
• необходимость регулярного информирования аудитории о том, как идет процесс разработки дистрибутива — у нас вот есть «Точка РОСЫ», и OpenMandriva тоже хотела бы иметь регулярно обновляемый блог и новостную рассылку;
• необходимость поддержки релизов качественной документацией (например, в старой Мандриве было принято выкладывать документацию в виде HTML на сайте http://doc.mandriva.com/index.php, в РОСЕ мы предпочитаем использовать вики);
• бурное обсуждение вызвали вопросы, связанные с QA и контролем качества дистрибутива — пока у OpenMandriva нет четких политик по работе с сообщениями об ошибках, но они обязательно появятся с ростом популярности системы. Приятно, что в качестве хорошо поставленного процесса был приведен и регламент работы QA в РОСЕ, однако для OpenMandriva такой регламент вряд ли подходит — ведь этот дистрибутив развивается исключительно добровольцами и, возможно, его разработке требует менее формализованных процессов.

Сугубо технических обсуждений практически не велось, однако были рассмотрены некоторые глобальные направления, как то:

• использование clang в качестве компилятора по умолчанию — решили, что разработчики OpenMandriva попробуют ради эксперимента пересобрать весь репозиторий с использованием clang; Беро (Bernhard Rosenkränzer) пообещал привлечь одного из разработчиков LLVM к анализу проблем, которые при этом возникнут;
• избавление от drakxtools — разработчики OpenMandriva, как и мы, уже вдоволь «насладились» счастьем поддержки этого стека надстроек над Gtk2 более чем десятилетней давности с сомнительного качества кодом. Избавление от него — дело долгое, и решено было начать с инсталлятора, как одной из основных программ, завязанных на drakxtools. Небольшим мозговым штурмом попробовали прикинуть, что какими характеристиками должен удовлетворять новый инсталлятор. В плане реализации решили, что инсталлятор должен быть написан на Qt без привлечения дополнительных прослоек/надстроек, но также должен уметь работать и из командной строки и по сети. Однако главный вопрос пока остается открытым — кто именно будет заниматься этой работой, ведь задача достаточно серьезная, и если ей заниматься по вечерам на досуге, то времени она может отнять много.
• возможные аналоги urpmi — в первую очередь, речь шла об использовании libzypp и libsolv;
• адаптация Wayland.

Обсуждались и вопросы, связанные с ABF, являющейся платформой разработки OpenMandriva (к слову, странички проектов с ABF были постоянно открыты в браузерах на ноутбуках многих участников). Был высказан ряд идей и пожеланий, которые мы обязательно рассмотрим, как то:

• возможность привязывания проектов ABF к проектам на каком-либо сервере Transifex для удобной работы по локализации приложений, разработка которых ведется на ABF (в первую очередь это специфически для РОСЫ и OpenMandriva программы — urpmi, rpmdrake, drakxtools и основанные на них утилиты);
• дополнительные средства отслеживания активностей по работе над репозиторием — например, git-хуки, отправляющие e-mail заинтересованным разработчикам при коммите в тот или иной проект.

Наконец, одной из горячих тем стал вопрос, заданный на Facebook-странице OpenMandriva в комментариях к выпуску релиза — «Чем OpenMandriva отличается от РОСЫ»? Ведь OpenMandriva и РОСА действительно во многом основываются на одинх и тех же пакетах, что неудивительно — процесс переноса разработок активно идет в обе стороны, а многие разработчики одновременно работают над обоими дистрибутивами. К тому же в OpenMandriva решили использовать по умолчанию SimpleWelcome, так что и внешних различий оказалось не так много и вопросы пользователей вполне логичны. Но конечно, OpenMandriva — это не просто ROSA Desktop Fresh с переделанными иконками. Разработчики OpenMandriva хотели разъяснить этот момент и подчеркнуть уникальные особенности своей системы, в то же время не отрицая большого сходства с РОСОЙ. Главная мысль которая пронизывала все обсуждение — это что разработчики РОСЫ и OpenMandriva сотрудничают, а не «таскают» наработки друг друга. Однако различные подходы к разработке обуславливают и различия в системах, основной из которых является факт использования в OpenMandriva новых, но еще недостаточно хорошо протестированных технологий и продуктов — ведь в OpenMandriva нет таких строгих критериев QA, как в РОСЕ, и многое отдается на откуп мэйнтейнерам. Результирующий текст, описывающий разницу между OpenMandriva и ROSA можно найти на FAQ-страничке OpenMandriva.

Отмечу, что встреча вышла очень насыщенной. Изначально предполагалось, что официальное обсуждение будет проходить в субботу и воскресенье с 10:00 до 17:00, однако выяснилось, что большинство участников уезжают во второй половине воскресенья. В итоге часть программы перенесли на субботу, и работа в этот день кипела с утра до вечера с недолгим перерывом на обед в виде пиццы. Стоит ли говорить, что и в неофициальной обстановке существенная часть разговоров велась все на те же темы разработки и развития дистрибутива:) При этом работа проходила очень организованно — выступления были по делу, без пространно-философских рассуждений о жизни, докладчиков не перебивали, и даже дискуссии велись с уважением к мнению других сторон — к сожалению, в мире Open Source такая атмосфера царит далеко не всегда. Такой ответственный подход позволил обсудить большой пласт вопросов за относительно небольшой промежуток времени и при этом принять ряд серьезных конструктивных решений.

В целом, впечатления от встречи остались очень благоприятные. Разработчики OpenMandriva настроены на серьезную работу, а также на активное сотрудничество с РОСОЙ — все уверены, что совместная работа пойдет на пользу обеим системам. Так что в новый год — с новыми планами:)Шаблон:CONFIDENTIAL-BEGIN Обсуждаем контент и дизайн.

Просьба прочитать перечисленные статьи — и если видите ошибку — правьте прямо там. Замечания по дизайну обложки ко мне — Стасу Фомину

Шаблон:CONFIDENTIAL-END

1. ↑ Он, и его жена были глуховаты…
2. ↑ Даже для несложных тем, чтение текста раза в три быстрее, чем воспринимать его на слух, плюс тут есть полный контроль над информационным потоком — можно вернутся, перечитать, скопировать, гуглить — полная власть над потоком.
3. ↑ У меня это http://tsya.ru/
4. ↑ кроме разумеется, победившего и здесь доллара
5. ↑ Обоснование ошибочности использования модальных клавиш см. у Джефа Раскина в «Интерфейсе»
6. ↑ Всякий там «Оптимус»
7. ↑
   • градус → «degree» → d → °
   • евро → «e» → €
   • фунт → «f» → £
   • ® ← «restricted»
   • © ← «copyright»
   • ™ ← «tm»
   • ѣ ← «y» ← «ТрУ»
   • ↓↑ ← «v»+«^»
   …
8. ↑ Пока у нас есть пара расхождений с каноном, так
   • нет редконужного символа «‰» (в свое время был веселый доклад про презентации без картинок, символами юникода, и этот символ предлагали для обозначения ситуации «программисты получают опционы»)
   • добавили еще «дробей» — по ALTGR-SHIFT-8 → ⅛.
9. ↑ Вызываются по CTRL-?
10. ↑ Кстати, это опять таки было непросто, пришлось существенно править оконный менеджер Mutter, чтобы научится отслеживать это «долгое нажатие по клавише WIN»
11. ↑ Кроме совсем древних еретических Sentinel-ов, которые вообще не умеют скроллить.
12. ↑ А также и беспроводные клавиатуры и прочие устройства ввода с собственными батарейками
13. ↑ Когда я тестировал работоспособность платных DRM-каналов, см. Blog:Точка Росы/Из всех искусств для нас важнейшим является кино…, я оплачивал доступ к этим ресурсам… и так получилось, что как-то забыл отписаться от Hulu — и оно несколько месяцев доило мой карточный счет, а чтобы отписаться, пришлось пройти нетривиальный квест… :(
14. ↑ И кровавыми слезами плачут пользователи разных малораспространенных вендорских решений
15. ↑ Ну или тыжпрограммиста
16. ↑ Это бесплатная реклама
17. ↑ А таковых — большинство
18. ↑ My true sad story :(
19. ↑ Даже политкорректные англоязычные пользователи признаются «Now to be honest, the default wallpaper doesn't do much for me. Actually it probably almost fried my eyes and shot me back to the 90's at the same time…»[10]
20. ↑ Разумеется, я не зверь, и обои по умолчанию сменил на нестыдные, а тяги к перемене обоев в их возрасте уже нет
21. ↑ Так коряво переводится благородное Desktop Environment
22. ↑ Другой подход был невозможен до появления многопроцессных операционных систем-оболочек
23. ↑ Технически, это может быть даже не локальный файл, а некоторый сетевой объект — все зависит от возможностей файлового менеджера, и с другой стороны, сам файловый менеджер может быть даже скрыт, например, при работе с «ярлыками на рабочем столе»
24. ↑ Не обязательно файлов, если рассматривать броузеры как оболочки, для них типами файлов являются не расширения, а MIME-типы web-ресурсов
25. ↑ Например, в Windows 8 запретили самим приложениям устанавливать ассоциации, и это стало серьезной проблемой для многих.
26. ↑ Этот ступор мы реально наблюдали и на организуемых юзабилити-сессиях, и при экспериментах на родных и знакомых, да и что греха таить, я сам долго тупил и гуглил, где же это настраивается в GNOME Shell.
27. ↑ В режиме обучения например, удобно смотреть блоками, повторять, гуглить непонятное, и переключаясь в текстовый процессор/майндмаппер — конспектировать.
28. ↑ Например, у меня в семье три штуки 19" HP dv8t, разбросанных по разным комнатам — видео-игро-развлекательные терминалы
29. ↑ Он короткий, но так много сил было затрачено, чтобы его снять… так что посмотрите обязательно!
30. ↑ Даже за пределами Linux-мира, в Windows-мире, и даже я видел гламурных девушек с Mac-ами, смотрящих видео в VLC
31. ↑ --enable-dv и т.п., например, ибо я встречал известные линукс-дистрибутивы, где например, VLC был собран без поддержки DV- и MTS- видео, что грустно тем, кто например, занимается домашним видеомонтажом
32. ↑ CTRL-J, вкладка «Statistics»
33. ↑ Это очень непросто сделать в Win, требуется дополнительно платный Webdrive, и все равно «будет глючить и тормозить©».
34. ↑ Часто еще со встроенной торрентокачалкой с вебинтерфейсом, так что если нужно что-то редкое → можно быстро найти в удобном каталоге, оставить выкачиваться, и дальше — все снова под рукой.
35. ↑ В большинстве внутридомовых сетей есть общедоступные медиаресурсы — файловые сервера с наиболее популярными сериалами, фильмами (включая HD/BDrip), образовательными медиа, мультфильмами. По крайней мере, я наблюдал это в нескольких московских и казанских сетях. Локальным провайдерам держать такой медиакеш, несмотря на все затраты — выгодно. Ибо иначе пользователи будут доставать все тоже самое торрентами, что увеличивает траффик (для провайдеров он таки платный), и нагрузку на железки (число соединений).
36. ↑ Не говоря уже о ВСЕХ других GNOME-derived дистрибутивах
37. ↑ Когда я пользовался Ubuntu, то впиливал хак с пользовательским дополнительным меню. Впрочем, этот сценарий еще более-менее поддерживает Totem — официальный плеер для GNOME, но поддерживал он с помощью грязного хака — внутри, он переделывал присланные локальные gvfs-урлы, восстанавливая из них оригинальные FTP-урлы — впиливать такой хак во ВСЕ возможные пользовательские плееры, было бы совершенно неправильно.
38. ↑ Например [11], но даже и в Ubuntu → [12].
39. ↑ Наблюдается даже в родной для GNOME Fedora
40. ↑ С точки зрения переключения по Alt-Tab
41. ↑ Если это не так — жалуйтесь нам в Bugzilla и форуме, но мы тестировали на всех видеосервисах, которые смогли вспомнить, вроде все было ОК
42. ↑ В LXDE, где максимальный фокус на минимализме и облегченности он не включен, но можно, при необходимости поставить
    • Устанавливаем hal из репозитория contrib (далее все команды от root):
    urpmi hal
    • Убеждаемся что демон запущен через /etc/init.d/haldaemon status. Если демон не запущен, то делаем это командой
    /etc/init.d/haldaemon start
43. ↑ Требуются некоторые приседания, чтобы обмануть сервис, и он думал, что вы не из России
44. ↑ На самом деле, я очень пытался быть кратким, но видимо, опять не удалось
45. ↑ Хотя это сравнение несколько некорректно, мы на самом деле даже размышляем, не собирать ли Fresh с поддержкой (по-умолчанию отключенного) SELinux, что бы тем, кому нужна именно безопасность, могли ее быстро включить.
46. ↑ Да и при sshd и автоматических переборах штрафные таймауты защитят даже при «пинкодовом» пароле
47. ↑ Немедленно вспоминается классика:

    • «Sorry, your password has been in use for 30 days and has expired — you must register a new one.»
      • roses
    • «Sorry, too few characters.»
      • pretty roses
    • «Sorry, you must use at least one numerical character.»
      • 1 pretty rose
    • «Sorry, you cannot use blank spaces.»
      • 1prettyrose
    • «Sorry, you must use at least 10 different characters.»
      • 1fuckingprettyrose
    • «Sorry, you must use at least one upper case character.»
      • 1FUCKINGprettyrose
    • «Sorry, you cannot use more than one upper case character consecutively.»
      • 1FuckingPrettyRose
    • «Sorry, you must use no fewer than 20 total characters.»
      • 1FuckingPrettyRoseShovedUpYourAssIfYouDon’tGiveMeAccessRightFuckingNow!
    • «Sorry, you cannot use punctuation.»
      • 1FuckingPrettyRoseShovedUpYourAssIfYouDontGiveMeAccessRightFuckingNow
    • «Sorry, that password is already in use.»

48. ↑ Если каждый чих требует рутового пароля — значит этот пароль будет известен всем.
49. ↑ Одно то, что для переключения WiFi сети требуется лезть в настройки… уже достаточно чтобы не мучать этим наших пользователей
50. ↑ Теоретически он еще может при этом показывать музыку и работать плеером, но это тут неважно…
51. ↑ К сожалению, пока платы телепатии не очень распространены, но в будующем, может и в этом не будет необходимости — идентификация по вебкамере с базой Google Glass…
52. ↑ Редкий китаnoname ноут, или самосборный десктоп
53. ↑ Если пользователь рисковый — он может даже сделать свой пароль пустым, и таким образом «sudo-ить» администрирующие команды без пароля. Но будьте внимательны, особенно при копипасте консольной линукс-магии с незнакомых ресурсов — технически можно добавить невидимые в броузере команды (белым по белому, и т.п.), который ворвутся в вашу консоль, и может быть с помощью sudо, сделают что-то плохое…
54. ↑ Где тоже были наши
55. ↑ Особо рекомендуем докладчикам, чтобы работать над ошибками
56. ↑ А еще я куда-то потерял две камеры и фотоаппарат…
57. ↑ Очень хотели везде записать звук с микрофона, но тут нам выкатили оху нечеловеческий ценник — 800руб/час/трек за запись звука, и записать идеальных звук удалось только в одном зале, несанкционированно подключившись к системе
58. ↑ Есть еще парочка, которых нужно доделать, это вопрос пары дней
59. ↑ Если будут косяки в докладах, которых никто не захотел смотреть… ну значит так звучит ломающееся дерево в лесу, в котором никого нет
60. ↑ Внезапность, неподготовленность, пришлось к половине докладов прибивать слайды руками при монтаже — как я замучился, местами не очень получился звук…, операторская работа, т.к. бегать пришлось одному добровольцу между пятью залами…
61. ↑ Обязательно монтаж с экранным видео или вручную привязанными слайдами, иногда видео зала, плюс вставили при монтаже в несколько докладов несколько сцен снятых участником конференции goury@lor.ru, плюс, как обычно, доклады ускорены, чтобы было все бодрей. Возможно надо было бодрить еще сильней, но в любом случае, зритель записей в выигрыше
62. ↑ Как подавляющее большинство *AAS сервисом, альфресковский клауд тоже на базе Amazonовских мощностей
63. ↑ Первые системы такого класса почти появились в социалистическом правительстве Альенде… увы, каналы связи тогда были не очень, и оно не спасло чилийский социализм