Блог:Точка Росы

Ссылки сюда (2) →

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

Если вы умеете пользоваться агрегаторами RSS/Atom, подписывайтесь!. По любым вопросам можно писать сюда.

Весь контент данного блога распространяется на условиях Creative Commons Attribution-ShareAlike 3.0 License (CC-BY-SA)

Допиливаем 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, видели очевидную сырость, огромное количество багов, очень странные юзабилити решения при том, что интересных фич там практически не прибавилось.

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

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

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

Разместил Stanislav.fomin 22 января 2014 21:11 (GMT), нет комментариев.

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

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

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

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

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

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

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

---

Good news everyone!

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

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

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

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

Разместил Stanislav.fomin 20 января 2014 15:01 (GMT), 4 комментария.

Укрепляем 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%

Разместил Stanislav.fomin 20 января 2014 10:01 (GMT), 1 комментарий.

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

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

Сергей Жемойтель делится инструкциями по созданию такой флешки с использованием 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».

Разместил Denis.silakov 17 января 2014 11:25 (GMT), нет комментариев.

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

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

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

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

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

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

Good news, everyone!

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

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

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

Разместил Stanislav.fomin 15 января 2014 19:19 (GMT), нет комментариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Good news everyone!

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

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

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

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

Разместил Stanislav.fomin 10 января 2014 18:49 (GMT), нет комментариев.

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

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

Понятно, что скритшоты и скринкасты нужны тестировщикам, скриншоты могут пригодится техническим писателям или околотехническим журналистам, скринкасты полезны преподавателям чего-то технического.

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

• «эффективной» техподдержкой, из трех уровней индусов или дебилов в колл-центре, прорваться сквозь которых, убедив, что ты не ламер, и проблема вызвана не только твоими кривыми руками, может только очень упорный боец,
• «эффективным» пофигизмом-скептицизмом — «It works on my machine!™».

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

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

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

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

Важность скриншотов осознавали еще в такие долгие времена, что на всех клавиатурах есть клавиша PrintScreen.

В Windows нажатие на нее просто без лишних слов помещает скриншот в клипборд, в KDE обычно запускается KSnapshot, с кучей опцией и настроек («что делать дальше? → сохранять-посылать-открыть в …», «как снимать — скурсором или без?» и т.п.), в GNOME Shell же, выбран вполне разумный минималистичный вариант — просто положить снимок в папку «Изображения/Pictures», проименовав ее датой и временем, так что при скриншотинге не надо придумывать имена и тратить вообще время на прочую «ручную перемотку пленки», можно в традициях времени не задумываясь «щелкать затвором», а потом, в «режиме обработки», просмотреть полученное, отобрать нужное и сделать что-надо — cropping, аннотации, публикация и т.п.

Но. Как часто бывает в GNOME Shell, идея правильная, но не работает. Вернее работает, но не у всех. А у кого даже работает — не всегда.

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

И да — это общая проблема всех гномодистрибутивов, включая убунту.

---

Good news, everyone!

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

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

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

---

А что насчет скринкастинга? Тут как раз в GNOME все отлично из коробки — встроенный скринкастер всегда под рукой, не надо ничего специально запускать, только надо запомнить нетривиальное клавиатурное заклинание «CTRL-ALT-SHIFT-R» для запуска сьемки в формат webm. Этим же заклинанием горшочек, не вари «CTRL-ALT-SHIFT-R», скринкастинг и останавливается.

И, аналогично скриншотам, скринкасты создаются в папке «Видео/Pictures» и автоименуются с датой-временем записи.

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

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

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

Разместил Stanislav.fomin 10 января 2014 03:18 (GMT), нет комментариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Ну и наконец, возможно у некоторых читателей сложилось впечатление, что «все эти ваши линуксы — для халявщиков, скачивающих видео», а честному человеку, оплатившему абонемент в какой-нибудь сетевой кинотеатр — 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 дистрибутивы, так что DRM-видео будет работать из коробки.

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

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

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

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

Разместил Stanislav.fomin 30 декабря 2013 21:48 (GMT), нет комментариев.

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

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

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

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

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

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

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

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

---

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%

Разместил Stanislav.fomin 30 декабря 2013 17:38 (GMT), 2 комментария.

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%

Разместил Denis.silakov 30 декабря 2013 11:08 (GMT), нет комментариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

• Кошерно оформить простые формулы 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.
• довели типографскую раскладку в KDE до полного «стандарта Бирмана».

---

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

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

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

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

Разместил Stanislav.fomin 23 декабря 2013 20:27 (GMT), 5 комментариев.

Визуализация результатов деятельности 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, в отчете это никак не отразится.

Разместил Denis.silakov 16 декабря 2013 19:45 (GMT), нет комментариев.

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

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

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

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

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

---

Good news, everyone!

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

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

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

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

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

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

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

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

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

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

---

---

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

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

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

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

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

---

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

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

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

Разместил Stanislav.fomin 3 декабря 2013 17:10 (GMT), 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 настроены на серьезную работу, а также на активное сотрудничество с РОСОЙ — все уверены, что совместная работа пойдет на пользу обеим системам. Так что в новый год — с новыми планами:)

Разместил Denis.silakov 25 ноября 2013 16:32 (GMT), нет комментариев.

Ядро 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 — практически каждое минорное обновление ядра собирается и тестируется для РОСЫ

Разместил Denis.silakov 25 ноября 2013 13:49 (GMT), нет комментариев.

Наши дистрибутивы используете? Какие? Опрос.

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

Какой из наших дистрибутивов-систем вы используете в данный момент:

ROSA 2011 1 1% ROSA MARATHON 7 10% ROSA FRESH KDE 41 60% ROSA FRESH GNOME 9 13% ROSA FRESH LXDE 6 9% Неупомянутый дистрибутив от ROSA (секретные и т.п.). 3 4% Ничего из перечисленного 1 1%

Разместил Stanislav.fomin 21 ноября 2013 16:32 (GMT), 2 комментария.

Точка Росы №8

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

Представляем его и в обычном формате вебжурнала «подборка статей с обложкой», так и в oldschool PDF-файле c полусотней страниц.

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

Итак, в восьмой выпуск «Точки РОСЫ» войдут:

«Фичи» — наши наработки и доработки, все для юзабилити и надежности:

• Мы покончили с национальной дискриминацией хоткеев в GNOME!
• Хоткеи для Windows-свитчеров. Смело переходите на GNOME!
• GNOME для нетбуков — режим без тормозов
• WiFi и Broadcom - работа над ошибками
• Легализация Gnome-tweak-tool

Инструменты мантейнера, качество репозитория:

• Urpmi, rpmdrake и автоматический выбор зависимостей
• Работаем над качеством пакетов, или Новости Rpmlint
• Linux Kernel ABI Tracker - инструмент для отслеживания изменений в ABI ядра
• Updates Builder – Pull Request'ы и автоматическое исправление ошибок сборки

IT-конференции — мы снимаем и публикуем записи разных IT-конференций, это интересно даже тем, кто не связан с Linux и Open-Source:

• talks.rosalab.com — конференции, которые всегда с вами
• OSSDEVCONF-2013 (Десятая конференция разработчиков свободных программ)
• OSDN-UA-2013 (Всеукраинская конференция разработчиков и пользователей свободных программ)
• LinuxCon Europe 2013 - О поиске "гонок" в ядре Linux
• Осенний листопад конференций! SECR, ProductCamp, AgileKitchen, WUD — смотрите все

Новости наших сайтов:

• Редизайн wiki.rosalab.ru — стильная мода для нашей вики
• talks.rosalab.com — конференции, которые всегда с вами

Как обычно, описание большого числа доработок GRUB2:

• Ряд улучшений и багфиксов для GRUB2
• GRUB2: новый функционал - размеры и положение терминала

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

• Редизайн wiki.rosalab.ru — стильная мода для нашей вики
• Наши дистрибутивы используете? Какие? Опрос.

Кстати, в одной из статей предложен challenge с наградой «ноутбук с ROSA», может это кого-нибудь заинтересует.

И совсем скоро, через считанные дни мы зарелизим всю линейку наших десктопных дистрибутивов (ROSA FRESH KDE/GNOME/LXDE), и перед этим будут еще серия статей, про реализованные фичи, с боями исправленные баги, ну и может о внутренних процессах — разработки и тестирования, юзабилити исследований и т.п.

Разместил Stanislav.fomin, Alexey.yermakov, Stanislav.fomin, Alexey.yermakov, Eugene.shatokhin, Denis.silakov и Andrey.ponomarenko 21 ноября 2013 16:06 (GMT), нет комментариев.

Редизайн wiki.rosalab.ru — стильная мода для нашей вики

Мы планируем активно наполнять wiki.rosalab.ru документацией, ценными статьями, переводами, блогами наших команд, и многим другим… но нас смущает один момент.

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

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

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

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

Итак, встречайте макет дизайна для нашей вики →

→ продолжить чтение…

Разместил Stanislav.fomin 14 ноября 2013 16:17 (GMT), 3 комментария.

Linux Kernel ABI Tracker - инструмент для отслеживания изменений в ABI ядра

Ядро операционной системы Linux постоянно развивается: улучшается поддержка оборудования, оптимизируются различные подсистемы ядра и др. В результате этого размер ядра и количество его ABI/API интерфейсов постоянно растет от версии к версии. При этом, в процессе разработки, могут быть изменены некоторые старые интерфейсы, что может неблагоприятно повлиять на работу других программных компонентов, использующих интерфейсы ядра: модулей, драйверов, динамических средств тестирования и трассировки ядра и др.

Для регулярного автоматического анализа изменений в интерфейсах ядра мы разработали инструмент Kernel ABI Tracker. Этот инструмент следит за появлением новых версий ядра на офф. сайте kernel.org, собирает их и анализирует изменения с помощью набора базовых инструментов. Для каждой версии ядра создается так называемый ABI dump ("снимок" или "дамп" ABI ядра) из его debug-информации при помощи инструмента ABI Dumper. Дамп ABI включает в себя информацию о всех публичных экспортируемых интерфейсах ядра, их параметрах и структуре типов данных. Для получения отчета об изменениях в двух версиях ядра сравниваются два соответствующих дампа ABI при помощи инструмента ABI Compliance Checker. В отчете описаны все изменения в интерфейсах ядра и разделены по уровню опасности для приложений. Отдельно описаны добавленные и удаленные интерфейсы, изменения в типах данных и в параметрах интерфейсов. Кроме своего прямого назначения дампы ABI могут также использоваться для других видов анализа интерфейса ядра сторонними разработчиками и поэтому доступны для скачивания всем желающим.

Интерфейс инструмента предоставляет отчеты о результатах тестирования defconfig-конфигураций всех последних longterm, stable и mainline версий ядра. На главной странице показан график зависимости количества интерфейсов ядра от версии. На данный момент результаты получены для двух архитектур: x86 и x86_64. Поддержка архитектуры arm планируется в ближайшее время. Также планируется тестирование других конфигураций ядра, например, allyesconfig.

Базовые инструменты ABI Dumper и ABI Compliance Checker, ранее разработанные в компании РОСА для проверки совместимости Си-библиотек, потребовали существенных изменений для возможности анализа изменений в ядре Linux. В силу огромной глубины дерева структур данных ядра и большого количества интерфейсов, требуемые для обработки одной версии ядра процессорное время и объем оперативной памяти были неудовлетворительными и вследствие были оптимизированы в несколько раз до нормальных величин. В результате этих улучшений, инструменты теперь работают быстрее при анализе библиотек большого объема. Код новых версий этих инструментов был выложен на их офф. сайте.

Разместил Andrey.ponomarenko 12 ноября 2013 14:50 (GMT), нет комментариев.

Работаем над качеством пакетов, или Новости Rpmlint

Одним из инструментов проверки корректности пакетов, с которым волей или неволей имеет дело каждый мэйнтейнер, является Rpmlint. Этот инструмент, проверяющий соответствие пакетов политикам дистрибутива, запускается автоматически при каждой сборке на ABF. Также мы проводим регулярный мониторинг репозиториев РОСЫ на портале FBA.

Правила сборки пакетов не высечены в камне и меняются со временем. Кроме того, время от времени появляются новые идеи - что еще можно статически проверять в собранных пакетах. Не стоит на месте и Rpmlint. Недавно мы провели его рефакторинг, выбросив неактуальные для РОСЫ проверки - вызов ldconfig в post-скриптах, определение и очистка BuildRoot и ряд других. Эти проверки уже долгое время не использовались, но загромождали код и увеличивали время работы инструмента.

Помимо чистки кода, мы добавили и ряд новых возможностей.

Во-первых, мы усилили проверки пакетов, исполнимые файлы или библиотеки которых выставляют параметр RPATH. Этот параметр влияет на то, в каких каталогах производится поиск библиотек при загрузке приложения - пути, указанные в RPATH, просматриваются в первую очередь. Пользоваться этой возможностью следует аккуратно, особенно в библиотеках, которые могут использоваться другими компонентами дистрибутива. В РОСЕ при необходимости использовать RPATH в каком-либо пакете рекомендуется помещать все библиотеки, доступ к которым будет контролироваться RPATH, в отдельный подкаталог директории /usr/lib (желательно, чтобы имя подкаталога совпадало с именем пакета - например, /usr/lib/fglrx содержит библиотеки, специфичные для fglrx). Если же RPATH указывает на директорию, в которой могут оказаться не ожидавшиеся авторами пакета библиотеки, то поведение приложений может оказаться непредсказуемым. Часто встречающимся примером такого рода является установка RPATH в системные значения наподобие /lib или /usr/lib. Как показала практика, установка RPATH в такие значения может оказаться даже фатальной - например, мы недавно исправили проблему с Empathy, "падавшего" на системе с драйверами Nvidia из-за RPATH, выставленного в библиотеке libwebkit (используемой Empathy). Отныне Rpmlint выявляет такие ситуации непосредственно при сборке пакета и при обнаружении исполнимого файла или библиотеки, в которых RPATH установлен в /lib, /usr/lib, /lib64 или /usr/lib64, останавливает сборку с ошибкой.

Во-вторых, по просьбе команды локализации, мы добавили проверку desktop-файлов в пакетах на предмет наличия в них непереведенных на русский язык описаний. Локализация таких файлов является важной, ведь именно информация из них используется для предоставления пользователю сведений о приложении, запускаемом при нажатии на ту или иную иконку. Поскольку такая проверка предназначена только для русскоязычных разработчиков, мы не стали включать его в основную ветку Rpmlint, распространяемую с РОСОЙ. Этот тест используется только при запуске тестов на FBA и результаты его можно наблюдать в соответствующих разделах FBA. Например, для репозитория main дистрибутива ROSA Desktop Fresh R1:

Непереведенные названия

Непереведенные описания

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

Наконец, Rpmlint теперь может проверять корректность суффиксов в названиях пакетов. В РОСЕ каждой версии дистрибутива соответствует свой суффикс, который автоматически выставляется средой сборки. Однако бывают ситуации, когда пакет не собирается на ABF, а подкладывается в репозиторий руками из другой версии дистрибутива. Например, некоторые пакеты имеют кольцевые сборочные зависимости, и для пересборки таких пакетов под новую версию дистрибутива проще всего использовать уже собранные зависимости из предыдущей версии. Как правило, "подложенные" пакеты удаляются из репозитория, как только в них отпадает необходимость. Однако человек может и забыть удалить какой-либо пакет, поэтому надежнее автоматизировать их отслеживание. Чем теперь и занимается Rpmlint, а точнее - проверка non-standard-distsuffix.

Список "корректных" суффиксов необходимо задавать в настройках Rpmlint, в параметре ValidDistSuffixes.

Разместил Denis.silakov 5 ноября 2013 17:12 (GMT), нет комментариев.

« новейшие ‹ 20 более новых … 20 более старых › старейшие »