Навеяно обсуждением.

Вопросы теоретико-исторические:

1. Почему реализация динамического линковщика в GNU/Linux не проверяет бит исполнимости на файлах разделяемых библиотек? Какие есть теоретические, практические, исторические основания для этого?

2. В каких системах такая проверка была и есть ли она в каких-то в настоящее время?

Вопрос практический:

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

Сегодня в lxpanelx улучшил апплет Directory Menu (aka Структура каталогов). (Лог коммитов.)

• Апплет отображает не только дерево каталогов, но и простые файлы.
• При щелчке по файлу запускается указанный в настройках панели файловый менеджер. Что он будет делать с файлом, зависит от конкретного ФМ. pcmanfm, например, — умница — открывает файл в ассоциированной с типом файла программе.
• Вкл/выкл показа скрытых файлов и каталогов.
• Вкл/выкл показа размера файлов.
• Сортировка каталогов по имени, времени модификации или размеру. Аналогично для файлов.

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

• Насколько вообще апплет Directory Menu востребован? Вы им пользуетесь?
• Если пользуетесь, есть ли какие-то пожелание по его функциональности? Или баги? Подумываю прикрутить фильтрацию каталогов и файлов регэкспами ­— кому-нибудь это надо?
• Может быть, для lxpanelx имеет смысл сделать апплет pipemenu, аналогичный динамическим меню openbox-а? (Можно выдрать весь необходимый код прямо из openbox-а и оформить отдельной библиотекой.)
• А может быть pipemenu лучше оформить в виде отдельной программы, которую можно забиндить на хоткей или вызывать из командной строки? Будет очень универсальный и маложручий движок меню в стиле suckless.

Что нужно:
* Клиент формирует один или несколько запросов и посылает серверу.
* Сервер принимает запросы клиентов и отвечает либо сообщением об ошибке, либо сообщением о принятии запроса на обработку.
* Сервер обрабатывает запросы и по мере готовности результатов, отсылает данные отдельными записями (которые могут идти вперемежку от разных запросов, если клиент ждет результатов для нескольких запросов).
* Клиент получает частичные результаты (и что он дальше с ними делает, в рамках этого треда уже не важно).
* После полного выполнения запроса сервер посылает сообщение клеинту, что запрос выполнен, и новых результатов не будет.
* Клиент может отметить выполнение запроса, пока запрос находится в процессе выполнения.

Пересылаемые в результатах данные — записи вида ключ-значение, где ключ — пара чисел, а значение может быть типа: число, utf8-строка, произвольный массив байт. (Фактически, результатом является двумерная матрица, а пара чисел ключа — это координаты ячейки в ней. Результирующая матрица может быть разреженной.) Эти данные необходимо эффективно сериализовывать/десериализовывать. К эффективности пересылки и сериализации запросов специфических требований нет, т.к. запросы будут пересылаться относительно редко, по сравнению с пересылкой результатов.

Соединение клиента и сервера осуществляется через сокет TCP или локальный сокет Unix.

Язык реализации — Си.

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

Навеяно очередным нытик-тредом, который удачно совпал с моими давними мыслями о рзавитии десктопного линукса.

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

Итак, необходимы механизмы взаимодействия приложений и компонентов DE, которые выведут GUI в юниксе на новый уровень интеграции. Предполагается, что протокол будет реализован поверх протокола Иксов, аналогично NETWM. Впрочем, я готов выслушать вменяемую аргументацию за реализацию средствами dbus. (Аргумент «Скоро иксы умрут из-за вейланда» адекватным не является.)

Назовём это всё Semantic Window Management, ну просто потому что надо хоть как-то это назвать. :)

Ключевые фичи, как я их вижу:

1. Вкладки.

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

Для чего: возможность интеграции вкладок в заголовок окна в WM и/или в панель задач.

2. Документы.

Суть: Если окно приложения используется для открытия одного или нескольких документов, от окна можно получить список документов, включая такую информацию, как URL документа, тип MIME, название и признак «документ изменен». Окну можно посылать команды переключения и закрытия документов, а также открытия новых документов.

Для чего: Интеграция списка документов в механизмы переключения окон. Создание документо-ориентированного интерфейса. Автогруппировка или сортировка окон, отображающих один документ (например, html-страница в редакторе и она же в браузере) или отображающих документы из одного каталога. Автоназначение окон для работы с файлами разных проектов на разные рабочие столы. Интеграция открытых каталогов в ФМ и диалоговых окон открытия/сохранения файлов. (Допустим, открыт каталог ~/somedir/ в thunar-е, и в это время в medit я выбираю «Сохранить как»; в диалоге сохранения на левой панели я увижу ссылку на этот каталог. Или же можно прямо через меню: Файл -> Сохранить в -> меню с выбором каталогов) Интеграция окон файловых менеджеров между собой. Ведение учёта недавно открытых / часто используемых файлов. Возможность скриптовой связки двух окон между собой по типу «файл, открытый в редакторе, автоматически показывать в браузере», «для файла, открытого в редакторе, автоматически отображать ФМ с соответствующим каталогом».

3. Действия.

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

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

4. Окна состояния.

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

Для чего: Приложение может использовать специальное окно для отображения своего состояния. Например: RSS-клиент — заголовки самых свежих элементов фидов, email-клиент — количество непрочитанных сообщений. Приложение может использовать любое число таких окон с разными именами, если это имеет для приложения смысл. По сути, это способ показа виджетов. DE может давать пользователю возможность размещать такие окна на рабочем столе, в панели, во всплывающих контейнерах и т.п. Выглядеть это может как боковая панель, как Плазма или же как плитка Metro в Windows 8 — зависит от DE.

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

Что требуется реализовать для достижения светлого будущего:

• протокол Semantic Window Management.
• библиотеки, инкапсулирующие работу с протоколом.
• поддержку этих возможностей в некотором количестве распространённых приложений, достаточном для того, чтобы этим уже заинтересовались сторонние разработчики.

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

Итак, вопрос стоит следующим образом: найдётся ли среди посетителей ЛОРа, не довольных текущим положением вещей в десктопном линуксе, 5 человек, умеющих не только болтать, но и работать? Всего 5 человек, с навыками программирования и желанием улучшить своё рабочее место. По отдельности мы — толпа анонимных аналитиков, вместе — команда разработчиков.

Поскольку приложений на Gtk3 постепенно становится всё больше, то пришлось озаботиться проблемой подбора для них вменяемой темы оформления. Выбор, однако, невелик: дефолтное вырвиглазие, третьегномовое вырвиглазие и некоторое небольшое количество вырвиглазий из gnome-look и AUR-а.

Надо сказать, что лучшими движками тем для gtk2 я считаю ThinIce и Industrial. Ничего похожего на них по стилю найти не удалось, так что в итоге я остановился на единственной теме с gnome-look, которая не заражена градиентами, закругленными бордюрами и прочими рюшечками. Это Elegant Brit. В принципе, она вполне симпатичная, если не обращать внимание на то, что она... гм... оранжевая. После 15-минутной допилки цветовой гаммы под цвета ThinIce, получилось то, что видно на скриншоте.

Теперь можно смело смотреть в будущее и не опасаться, что с очередным обновлением системы, что-нибудь из нужных приложений превратится в УГ. ;-) По мере переползания софта на gtk3, буду постепенно пилить тему под свои предпочтения. Посылаю луч добра автору Elegant Brit за то, что мне не пришлось весь фарш CSS писать с нуля.

В остальном всё то же, что было на предыдущих скриншотах: openbox без заголовков в роли WM, PT Sans и freetype-infinality в роли ШГ, lxpanelx в роли панели.

Открываем в фирефохе первый попавшийся ролик на ютюбе (например). Проигрыватель флеша жрёт 70-100% CPU.

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

Теперь включаем на ютюбе поддержку html5 и повторяем без флеша. Результат: фирефохе жрёт 75% CPU (оставшиеся 25 съедают иксы), тормозит и периодически встаёт раком со статусом D. Блджад... как у них получается ТАК быдлокодить?! Как можно загнать процесс в непрерываемое ожидание IO, не производя никакого IO?!

А теперь скачиваем этот ролик и загоняем в mplayer, чтобы посмотреть реальную нагрузку от его воспроизведения на данном железе. mplayer — 9%, иксы — 3% CPU. Nuff said.

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

• Сначала убедитесь, что у вас всё в порядке с глазами, так как такого просто не может быть.
• Если невозможное всё же случилось, срочно кидайте в меня багрепортом. Всё будет починено.

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

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

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

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

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

Кроме того, имеется возможность автоматического разворачивания группы, к которой относится активное окно.

Всевозможные действия, которые lxpanelx умеет выполнять над окнами, могуть быть произвольно назначены на левую, среднюю или правую кнопку мыши, а также на прокрутку вверх-вниз мышинным колесом + всё те же самые варианты, но с модификатором Shift. Обращаю ваше внимание, что если вы выбираете окно в выпадающем списке окон группы или в списке всех окон рабочего стола, то биндинги работают и там: щелчок левой, средней или правой кнопкой по пункту списка будет срабатывать так же, как аналогичный щелчок по обычной кнопке окна в панели задач.

Обновляемся, тестируем, отписываемся о багах.

И всё это — только начало. Новые коммиты — новые фичи. Пусть маководы борются со своим неудобным доком. Пусть виндузятники плачут от злости. Следите за новостями и оставайтесь с нами!

Если есть люди, разбирающиеся в коде иксов, помогите выяснить причину такого поведения. Суть в следующем:

Когда клиент слушает KeyPress и KeyRelease для собственных окон, все сообщения приходят как и ожидается. Если же клиент слушает ввод для окна, которое создано другим клиентом, то перед каждым KeyPress он получает фейковый KeyRelease для этой же клавиши.

Например, запускаем xev с собственным окном и запускаем второй xev, который натравливаем на окно первого. Первый получает такие события:

KeyPress event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7167984, (838,-77), root:(953,658),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7168102, (838,-77), root:(953,658),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyPress event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7174348, (838,-77), root:(953,658),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7174453, (838,-77), root:(953,658),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7176414, (838,-77), root:(953,658),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7176494, (838,-77), root:(953,658),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

А второй в это же время получает такие события:

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7167984, (838,-77), root:(953,658),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyPress event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7167984, (838,-77), root:(953,658),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XmbLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7168102, (838,-77), root:(953,658),
    state 0x0, keycode 65 (keysym 0x20, space), same_screen YES,
    XLookupString gives 1 bytes: (20) " "
    XFilterEvent returns: False

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7174348, (838,-77), root:(953,658),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7174348, (838,-77), root:(953,658),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7174453, (838,-77), root:(953,658),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7176414, (838,-77), root:(953,658),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

KeyPress event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7176414, (838,-77), root:(953,658),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

KeyRelease event, serial 17, synthetic NO, window 0x1e00001,
    root 0x199, subw 0x0, time 7176494, (838,-77), root:(953,658),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

Поведение воспроизводится не только под xev, но в xneur. Т.е. определенно это не баг клиента, а фича иксов.

При чем, когда я вчера тестировал это поведение, то лишний KeyRelease приходил только для модификаторов. А сейчас, как видно по логу выше, он приходит и для алфавитных клавиш. Очень странно.

Используемая версия иксов: 1.10.3.901.

Копаясь в коде, я дошел до функции DeliverEventsToWindow() в файле dix/events.c, где происходит доставка сообщения сначала для «своего» клиента окна, а затем для всех остальных. Однако изучая, чем доставка для всех остальных отличается от доставки «своему», я не нашел ничего, что пролило бы свет на сабж. Единственное место, в котором подставляются фейковые KeyRelease — это функция TryClientEvents() (в том же файле), однако там KeyRelease вставляется для обработки удержания клавиши при автоповторе и, вроде бы, не имеет отношения к проблеме.

Если такое поведение в иксах было сделано специально, то для чего именно? Или же это баг? Гугл не помог.

Что хотелось бы:

• Игру с богатым геймплеем в боевой составляющей. Линейки и прочие тык-тык-тык-игры идут на фиг. Перемещения в пространстве должны иметь смысл. Эквип должен иметь смысл. Билд должен иметь смысл.
• Относительно короткие игровые сеансы. Максимум на полчаса. Зашел, сыграл партию, вышел. Задротство не нужно.
• Чтобы реал не оказывал существенного влияния на баланс.
• Наличие нескольких различных типов PVP-сеансов. CTF, захват башен, team DM и т.п. Чтобы не было как в Доте пожизненного задротства на одной карте. Наличие командных PVE-сеансов (попросту, «данжи») тоже было бы плюсом, хотя и не обязательно.
• «Бесшовный» мир не обязателен, не обязательно даже и наличие оного мира.
• Перситентность персонажа. Не то что бы критична, но желательна.
• Идеально, если бы система прокачки была рассчитана на мастерство игрока, а не на тупой фарм. В качестве примера можно привести GemCraft Labyrinth. Общее количество опыта начисляется как сумма от максимумов со всех пройденных карт. Т.е. пройдя 2 карты и получив 100 единиц опыта да каждую, а потом перепройдя первую и получив 150, всего очков вы получите не 100 + 100 + 150 = 350, а 150 + 100 = 250. Карт в игре много, уровней сложности для их прохождения много (можно перед стартом выбрать разные наборы усложняющих условий, дающих прибавку к итоговому опыту), возможностей раскидать билд тоже достаточно много — как результат, очень интересная система прокачки, где не пройдёт тупой фарм.

Советуйте. :)

Запускаю rsync с винта на винт. Памяти под кэш свободно процентов 25-30 из 1.2 Гб RAMы. Все процессы начинают лезть в своп (статус D рандомно на произвольных процессах), который быстренько разрастается до 500Мб занятого места, музыка на-на-начинает за-за-заикаться, GUI периодически встаёт раком.

Лезу смотреть swappines. swappines = 0. Делаю вот такие глаза: о_О. Переставляю swappines за 10. Тормоза исчезают.

Проходит 2 минуты. swappines по-прежнему 10. Тормоза возвращаются.

После того, как rsync отработал, запускаю для теста find /usr -type f | xargs cat > /dev/null. С ним тоже тормозит, хотя и не так сильно как при копировании.

Пробую разные значения swappines от 10 до 90. На всех тормоза примерно одинаковые. При 90, пожалуй, даже чуть меньше, что совсем уж противоречит здравому смыслу.

Что это было и куда копать?
Идеи? Советы? Рецепты?

Система Archlinux 32bit, ядро linux-pf-p4 3.0.2-1 (с BFS и BFQ)
Настройки подсистемы VM:
vm.overcommit_memory = 2
vm.overcommit_ratio = 90
vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152

Даже не знаю, в толксы это подходит или в General. Наткнулся на такую штуку: http://winswitch.org/

Для Ъ:

«Window Switch is a tool which allows you to display running applications on other computers than the one you start them on. Once an application has been started via a winswitch server, it can be displayed on other machines running winswitch client, as required. »

«Window Switch supports many different protocols for accessing remote applications and desktops:
NX: which is very efficient over slow links
VNC: for simple full-desktop access using the robust VNC standard
xpra: «screen for X», a fairly new option
ssh: SSH display forwarding
rdp: Microsoft's option
GStreamer: read-only screencasting
There is also partial support for screen and libvirt sessions.»

Короче, обертка над кучей терминальных протоколов для управления оными + GUI на питоне.

Кто-нибудь пробовал? Юзабельно?

Автор обещает изкоробочность, но у меня без бубна не завелось (пробовал с xpra). Еще не разбирался, почему.

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

Cairo-dock, AWN, docky, dockbarx. Они ведь все — унылота ненастраиваемая.

OpenGL-версия сairo-dock-а еще и умудряется тормозить. о_О

Docky тянет 32 пакета на 170 метров и виснет с пожирание CPU при попытке выйти из него. Остальные не лучше.

Потыкал настройки — в GUI нет практически ничего, что позволило бы гибко оттюнить интерфейс. (Конфиги не смотрел, но подозреваю, что там не лучше. Приложения-то мышекликательные.) В dockbarx глючит отрисовка менюшек и кнопок (оставляет не стертые куски интерфейса). Меню, выпадающие по наведению, начисто ломают юзабилити, т.к. каждый раз не понятно, чего ожидать и как закрыть меню — просто курсор увести или же щелкать надо. Цветастый звиздец, который у них по дефолту бекграундом, бьёт по глазам, вызывая дезориентацию. Разрабы полагают, это красиво и стильно?

В целом получается: жрут много, пакетов тянут много, толком ничего не умеют, неудобны, выбиваются из оформления тулкита, попусту занимают всегда драгоценное место по вертикали, некоторые откровенно глючат. А достоинства у них какие? Пользователи доков, расскажите, зачем оно вам? Только чтобы было «как в макоси и семерочке»? Мне правда интересно.

Офигеть, они таки сделали это.

Пользователь: PurchaseBrothers
Видео: Escape From City 17 - Part Two
Длительность: 14:28
Добавлено: 14 ч. назад

!Ъ: http://www.youtube.com/watch?v=4lyUNs7eNhs

Для Ъ не будет, ничего не поделаешь.

В принципе, форк от оригинала отделяют только 78 коммитов, но сделано уже довольно много.

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

Для апплета панели задач:

• Возможность отображать только иконку, только заголовок или оба.
• Опциональное отображение кнопки закрытия.
• Режим для отображения заголовка только активного окна. (Панель задач в роли заменителя заголовка окна, если они отключены в WM.)
• Если включена опция «Показывать окна всех рабочих мест», то кроме заголовка окна, также отображается и название рабочего места, на котором он находится.
• Доработки контекстного меню: два пункта Максимизировать/Восстановить объединены в один, меняющий название в зависимоти от режима окна; пункт «Значком» отображается неактивным, если окно уже свернуто; в подменю «Переместить на рабочее место» отображаются реальные имена рабочих мест вместо номеров.
• Возможность назначить на ЛКМ, СКМ и ПКМ, а также на прокрутку колесом любые действия из следующего списка:

  enum TASKBAR_ACTION {
      ACTION_NONE,
      ACTION_MENU,
      ACTION_CLOSE,
      ACTION_RAISEICONIFY,
      ACTION_ICONIFY,
      ACTION_MAXIMIZE,
      ACTION_SHADE,
      ACTION_UNDECORATE,
      ACTION_FULLSCREEN,
      ACTION_STICK,
      ACTION_SHOW_WINDOW_LIST,
      ACTION_SHOW_SIMILAR_WINDOW_LIST,
      ACTION_NEXT_WINDOW,
      ACTION_PREV_WINDOW,
      ACTION_NEXT_WINDOW_IN_CURRENT_GROUP,
      ACTION_PREV_WINDOW_IN_CURRENT_GROUP,
      ACTION_NEXT_WINDOW_IN_GROUP,
      ACTION_PREV_WINDOW_IN_GROUP
  };
  

  На прокрутку колесом в конфиге по умолчанию назначено листание окон вперед-назад, т.е. панель задач имеет feel, сложий с привычными табами.
• Группировать окна можно не только по WM_CLASS, но по рабочему столу, а также по состоянию окна (видимое/свернутое).
• Параметр GroupThreshold указывает количество однотипных окон, после достижения которого они будут объединенны в одну кнопку. 1 — делать объединяющую кнопку даже если окно не имеет однотипных «товарищей»; 2 — делать объединяющую кнопку, если есть 2 однотипных окна; и т.п. Если значение равно 0, то окна никогда не скрываются под общей кнопкой, а просто сортируются на панели, чтобы были рядом (временно сломано, работает не всегда).
• Возвращены на законное место опции «Show mapped windows» и «Show iconified windows», которые изначально присутствовали в fbpanel, но были выпилены разработчиками lxde после их форка.
• Интегрирован стороний патч для lxpanel, предотвращающий растягивание слишком маленькой иконки окна (лучше мелко, но чётко, чем мыло).

Скриншот панели и диалога настроек: http://s010.radikal.ru/i311/1108/83/6edd7c6d6069.png

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

Реализован новый плагин «Кнопка запуска»:

• Можно назначить команды, запускаемые по ЛКМ, СКМ и ПКМ.
• Можно задать название и иконку. Оба опциональны.
• Можно задать всплывающую подсказку для кнопки. Если не указана, автоматически формируется из команд, указанных для ЛКМ, СКМ, ПКМ.

В других частях кода панели:

• Из lxpanel перенесены несколько фиксов багов, выполненных после точки форка, включая баги для апплета заряда батареи и часов.
• Оптимизация модуля icon-grid, используемого такими апплетами как панель задач, трей и переключатель рабочих мест.
• В диалоги конфигурации апплетов добавлена возможность работать с выпадающими списками а также делать выравнивание элементов управления при помощи таблицы.
• Добавлена возможность запускать lxpanelx в kiosk mode. Включается параметром KioskMode=true в секции General в файле ~/.config/lxpanel/<PROFILE_NAME>/config. При работе в kiosk mode полностью блокируется возможность изменять во время работы любые настройки панели. Это позволит применять lxpanelx в общедоступных компьютерах организаций, школах и т.п.
• Апплеты на панели теперь выравниваются относительно центральной линии, а не сидят у верхнего края.

Что запланировано:

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

Планы относительно новых функций:

• Возможность гибко настраивать меню для панели задач (указывать, какие именно пункты отображать, из всех возможных действий для окна).
• Группировка окон по произвольному свойству окна, указанному в настройках. (Для интеграции с какой-либо внешней утилитой, которая будет выполнять группировку.)
• Возможность сортировать окна по нескольким параметрам, либо по параметрам, указанным в кустомном свойстве окна. (Аналогично предыдущему, для интеграции с внешним сортировщиком.) А также возможность перетаскивать мышой окна на панели.
• Аналогично предыдущему, фильтрация списка окон.
• Возможность указать в настройках собственные команды-действия и назначить их на кнопки мыши или колесо.
• Возможность читать кустомный список действий из свойств окна и добавлять его в контекстное меню.
• В переключатель рабочих мест добавить возможность отображать только имена рабочих мест, а не их миниатюры.
• Добавление в ядро панели модуля регистрации внутренних команд, доступных апплетам, и средства для назначения глобальных хоткеев на эти команды. Команды будут обрабатываться в exec-стиле, т.е. могут иметь произвольный список аргументов (как эти аргументы интерпретировать — зависит от апплета). Например панель задач сможет выполнять забинженные команды типа Alt-1 -> raise_and_focus #1, Alt-2 -> raise_and_focus #2 и т.п. для активации окон хоткеями по их номеру (WM этого делать не может, т.к. не знает, как панель отсортировала окна.)
• Появление/скрытие панели по хоткею.
• Апплет «кнопка запуска» планируется научить получать данные от stdout запущенного процесса или из именованного пайпа. Апплет будет парсить поступающие данные и изменять любые из своих параметров (назначенные команды, иконку, заголовок, подпись). Таким образом, это будет интерактивная кнопка, управляемая внешним скриптом в unixway-стиле.
• Также запланировано добавление апплета, позволяющего выполнять embedding окон на панель.

Теперь, что касается означенных в заголовке «свистелок современного десктопа». Windows 7 давно умеет, а недавно и Unity научилась использовать «умный» док, позволяющий делать «spawn or raise», а также отображать в контекстном меню кнопок разные плюшки, такие как список недавних документов приложения и специфичные для него команды. Также вспомним про двигло zeitgeist и умный журнал действий пользователя в Gnome3, который на том двигле работает. Всё это тяжко ворочается через dbus, скрипя библиотеками, и кое-где подпёрто питоном.

Как всё это счастье _правильно_ интегрировать с lxpanelx, не строгая новых апплетов и не тягая в зависимостях зоопарка левых либ? Ответ прост: пустить данные через иксовые свойства окна.

1. Пусть там нужно показать кнопку, которая будет делать «spawn or raise». Создаём фейковое окно, которое и отображается в таскбаре в роли такой кнопки. При попытке активации этого окна, скрипт запустит настоящее приложение, а фейковое окно спрячет. Когда приложение завершится, скрипт покажет окно обратно. И никаких зависимостей.

2. Теперь пусть для окна (не важно, фейкового или настоящего) надо показать особенное контекстное меню, содержащее специфичные пункты. У окна есть такая замечательная вещь, как WM_CLASS позволяющая идентифицировать его как принадлежащее некоторому приложению. Ну а дальше — просто. Зная приложение, получаем для него это меню и пишем в некоторое свойство окна. Этим будет заниматься соответствующий скрипт. А панель задач, как выше было обозначено в TODO, в скором времени научится читать определенное свойство окна и добавлять пункты оттуда в своё контекстное меню. И опять — никаких зависимостей.

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

Была такая утилита, которая позволяла прописать скрипты, срабатывающие при создании нового окна, изменении его свойств и т.п. В частности, можно было при её помощи автоматически назначать в принудительном порядке свойства окнам. Синтаксис конфига вроде бы лиспообразный. Как называется?

Имеется репозиторий, соединение с которым периодически виснет.

В mercurial я мог в такой ситуации сделать hg clone -r 1000 url, и затем hg pull -r 2000, hg pull -r 3000 и т.п.

А как в git склонировать репозиторий кусками?

Я, видимо, совсем туплю, но не могу найти в gtk reference manual информацию, как правильно запросить перерассчёт размеров для элементов контейнера.

Т.е., пусть у нас есть виджеты A и B в контейнере C. Виджеты, как им положено, на size-request возвращают свои желаемые размеры. Если у меня в программе изменились оные желамые размеры, как мне сообщить контейнеру, что надо заново выполнить size-request и пересчитать фактические размеры виджетов?

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

Давно хотел попробовать BFS, но было лень. Последней каплей стало то, что, как выяснилось, на работу CFS значения nice не оказывают никакого существенного эффекта. Можно запустить несколько процессов echo 'while true ; do : ; done' | nice -n20 sh и получить эпичные тормоза во всех приложениях. Установка отрицательных найсов иксам и нужным приложениям тоже не приводит ни к какому эффекту. Completely, блджад, fair.

Собрал ядро с набором патчей от post-factum-а, включающее в себя BFS и BFQ. Ударил в бубен, пропатчил nvidia-173xx PKGBUILD, чтобы завелось с новым ядром. Для полноты ощущений, поставил verynice. Выдохнул. Перезагрузился.

Запустил сполдюжины echo 'while true ; do : ; done' | sh.
Не тормозит.
Ладно. Запустил многопоточную сборку.
Не тормозит.
Запустил воспроизведение музыки, dbench на 50 потоков и find / > /dev/null.
Не тормозит. Бага-который-нельзя-называть не показывает. Просто работает.
Окей, применим секретное оружие: запись-чтение данных через ntfs3g. dd if=/dev/zero of=/media/e_data/test1 bs=16K & ; cat /media/data/Видео/* > /dev/zero
Не тормозит. (*)

Linux торт и готов для десктопа. Ня.


<дисклеймер мелким шрифтом>
(*) Все перечисленные тесты запускались раздельно. В случае одновременного запуска, отзывчивость системы не гарантируется. Ваш К.О.
</дисклеймер мелким шрифтом>

Дано:

Раздел ntfs, смонтированный через fuse:

$ ps ax | grep [n]tfs
 1170 ?        SNs   22:14 /sbin/mount.ntfs /dev/sdd5 /media/e_data -o rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,dmask=0077,fmask=0177

и любая программа, которая пишет на него данные. Например mc, eiskaltdc, cp, dd и т.п.

Результат: общее падение производительности системы из-за того, что большая часть CPU тратится на /sbin/mount.ntfs, а остальные задачи сидят голодные. Переключение вкладок в терминале тормозит, страница в браузере прокручивается рывками и т.п.

Пробуем численно измерить это падение производительности. Берём какую-нибудь чисто-CPU задачу и запускаем в ненагруженной системе:

$ time yes | head -n 50000000 | wc -l
50000000

real	0m3.785s
user	0m2.890s
sys	0m0.540s

Запускаем dd if=/dev/zero of=/media/work/test bs=16K (/media/work/ — это ext3) и повторяем тест:

$ time yes | head -n 50000000 | wc -l
50000000

real	0m5.934s
user	0m2.890s
sys	0m0.857s

Запускаем аналогичный dd, но уже для файла на ntfs разделе, повторяем тест:

$ time yes | head -n 50000000 | wc -l
50000000

real	0m11.274s
user	0m3.163s
sys	0m1.280s

Итого, при интенсивной записи на ext3, производительность работающей паралельно тестовой задачи падает в 1.5 раза, а при записи на NTFS — аж в 3 раза.

Выставление renice 20 для mount.ntfs или для dd не приводит к изменению результата.

Как это лечить? Как снизить влияние mount.ntfs на производительность остальных процессов? Нагуглить ничего полезного не смог. Что это — проблема планировщика? Кривость подсистемы fuse?

Если в хромиуме открыть на новой вкладке ссылку, по которой сервер не отвечает (как, например, сейчас полЖЖ лежит), то:

• при попытке нажать enter, чтобы попытаться достучаться к серверу заново, адрес исчезает и заменяется на about:blank;
• при попытке нажать «Стоп» в тулбаре адрес исчезает и заменяется на about:blank.

Лучи ненависти! КРОВЬ МЯСО КИШКИ МОЗГИ НА СТЕНАХ РУБИТЬ ТОПОРОМ ДОЛБАНУТЫХ ПРОГРАММИСТОВ ПЕРЕЕХАТЬ КАТКОМ ТОПТАТЬ НОГАМИ ЛУЖИ КРОВИ И КИШКОВ

Еще со времен IE4 во всех браузерах какие-то дебильные затыки, связанные со строкой адреса. У меня полное ощущение, что разработчики меня троллят. И у них это получается.