LINUX.ORG.RU

Сообщения geekless

 

[lorgoogle] Встраиваемый функциональный язык

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

Требования:

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

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

Пока присматриваюсь к универсальным ЯП: лиспам и Tcl, но хотелось бы найти что-то более заточенное под задачу, если оно существует в природе.

 

geekless
()

[готов для] Поставил я этот ваш Agilia...

Поставил я, значит, сегодня этот самый AgiliaLinux.

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

Система, конечно, сырая до невозможности. Например, из коробки оснастка для управления pppoe ставится, а сам ppp — нет. (Кривые зависимости?) XFCE-шный терминал делает что-то ужасное, заставляя иксы сжирать до 80% CPU, пока он запущен. Решил проблему поставив православный urxvt. Установщик пакетов при ошибке чтения во время анализа репозитория молча закрывается, ничего не сообщая, что конкретно случилось. (Устанавливал с поцарапанной болванки.) «man: command not found» тоже порадовало. Ну и много прочих подобных багов по мелочи.

Но видно, что ребята стараются. Несколько вариантов рабочего окружения — кроме банальных GNOME и KDE, есть собственная сборка среднеминимального окружения на основе OpenBox и сильноминимального на основе Fluxbox, а также возможность поставить XFCE или LXDE — все эти варианты на одном установочном диске. Openbox-овый псевдоDE очень достойным получился, хотя и собран из кучи не связанных программ. Разумеется, минимальный вариант установки без иксов и прикладного ПО тоже предусмотрен.

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

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

geekless
()

[ССЗБ] Какое же говно это наше GTK

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

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

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

Средства для кустомизации компонент наследованием находятся в зачаточном состоянии, а для кустомизации тонкой настройкой в рантайме - и вовсе в противозачаточном. Часть компонент нуждается в разбиении на субкомпоненты, например, ужасный GtkNotebook. Часть компонент просто написана задней лапой. Исходники производят полное впечатление, что перед нами не универсальный тулкит, на котором работает чертова уйма гуёв, а всё тот же костыльный набор виджетов для GIMP-а.

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

 

geekless
()

Обзор графических просмотрщиков

По мотивам вот этого треда.

Сделал обзор графических просмотрщиков для GNU/Linux. Может быть, будет полезен кому-нибудь. ;)

Рассмотрены следующие программы: viewnior, eog, gpicview, ristretto, mirage, comix, feh, gqview, geeqie. Конечно, есть и другой софт для просмотра, модификации и каталогизации изображений, но невозможно объять необъятное.

geekless
()

[жж] Нормальные файловые менеджеры вообще существуют?

Встала задача разгрести довольно большую файлопомойку. Нужен файловый менеджер, умеющий следующее:
* инстант превью выделенного файла
* просмотр содержимого архивов in-place либо распаковка архива по хоткею
* помнит список последних N каталогов, куда производилось копирование/перемещение файлов и позволяет быстро скидывать туда
файлы (или хотя бы даёт возможность вручную сформировать такой список)
* показывает общий размер данных в каталоге (т.е. считает и кэширует du в фоне)
* не тормозит, т.к. если ждать по секунде на каждую смену каталога или превьюшки, можно файлопомойку месяц разгребать

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

Что имеем:
nautilus — тормозное убожество. Ничего из перечисленного не умеет.
pcmanfm — не сохраняет выделение на каталоге при возврате по истории на шаг назад, говно. Ничего из перечисленного не умеет.
xfe — вообще не пашет переход вперед/назад по истории, забагован. Дальше не смотрел.
gnome-commander — моргает панелями при каждой смене каталога, жалко глаза. Честно не осилил отыскать в нём превью выделенного файла на другой панели. Начал подозревать, что разработчики были вообще не в курсе, что это — одна из традиционных фич двухпанельника. Превью по F3 хоть формально и работает, но эта тварь опять мограет панелями, когда закрываешь окно просмотра.
dolphin — «Размер устанавливаемых файлов: 167,21 МБ». Да и без установки понятно, что оно будет тормозить, но всё же решил установить. И не ошибся — тормозит так, что nautilus обзавидуется.
krusader — еще один монстр, вытягивающий за собой половину kde. Ну вот нахрена файловому менеджеру звуковая подсистема и пакет иконок на 25 метров? MS-style пакетирования софта в действии. Тормозит еще сильнее dolphin, пользоваться невозможно.

Единственным хотя бы работоспособным (без явных багов и тормозов) ФМ оказался thunar. Но и в нём нужной функциональности нет.

Дальше я задолбался. Если это всё — мейнстримовые (ну кроме xfe) ФМ, то страшно представить каковы же остальные. Они же ничего не умеют (ну допустим, dolphin и krusader что-нибудь умеют — но тормозить зачем!). И ничем друг от друга не отличаются. Не понятно, зачем вообще разрабатывался этот софт, и о чем думали разработчики, потому что эти файловые менеджеры не пригодны для управления файлами. Забагованное велосипедостроительство. Я практически уверен, что никто из разработчиков этих велосипедов реально не пользуется своими поделиями — это не выглядит как софт сделанный для своих нужд, это выглядит как софт, сделанный на заказ по принципу «получи и отвали», а потом выложенный под свободной лицензией.

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

Человечество обречено.

 

geekless
()

[lorgoogle] Продвинутые фичи эмулятора терминала

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

Про фичи urxvt-а в курсе — интересует, как у остальных обстоит с этим делом.

 

geekless
()

[gui][и всё-таки она вертится] FOX toolkit, adie

В продолжение треда. Наткнулся совершенно случайно на тулкит FOX и редактор adie. Ну то есть я про FOX и раньше слышал краем уха, но посмотреть не было повода.

Про его внутренности говорить не буду, так как не в курсе — просто несколько чисто внешних наблюдений:

* Диалог открытия файлов. Практически полностью скопирован из винды — хорошие идеи нужно нагло копировать, всё правильно. Довольно гибко настраиваемый режим просмотра, сортировка, простейшие файловые операции, букмарки. Не как кдешный, конечно, но и отнюдь не убогий by design gtk-шный file chooser, все фичи которого — это на самом деле задокументированные баги.

* Диалог выбора цвета. Выбор по цветовому кругу. Выбор по значениям RGB, HSV и CMY ползунками или вводом точных значений. Выбор по палитре стандартных цветов. Выбор/сохранение цветов в пользовательскую палитру из 24-х элементов. Возможность взять цвет «пипеткой» прямо с экрана. Единственное, чего не хватает — возможности ввести цвет в виде значения #RRGGBB.

* В диалоге выбора шрифта можно фильтровать список по character set, width, pitch и scalable.

Казалось бы, неужели так сложно в дизайне стандартных диалогов: не делать хуже, чем есть в уже существующих реализациях. Вот почему у разработчика FOX toolkit это получилось, а у всей толпы авторов gtk - нет?

Текстовый редактор adie - отдельная песня. Боковая панель с деревом файлов. Подсветка синтаксиса. Персистентные букмарки. Поиск с регэкспами. Куча мелких удобств вида «открыть выделенное», «вставить из файла/извлечь в файл», «goto (..», «goto ..)», «select (..)», запоминание позиции в файлах, «search and replace history is stored persistently» и т.п. Разумеется, почти всё это вроде как очевидно и должно быть в любом уважающем себя редакторе. Но почему, блджад, этого нет в редакторах «для простого пользователя»?!

Быстрый. Реально, зараза, быстрый gui. Между двумя окнами редактора переключение происходит мгновенно, я как ни старался, не смог обнаружить никакой задержки отрисовки. Всё остальное — открытие диалогов, реакция на ввод и т.п. — тоже реактивно. Глянул еще пару софтин на этом тулките, но у них отрисовка подтормаживает, не так сильно, как в приложениях на gtk, но подтормаживает. Возможно, кривовато написаны. А этот редактор - непосредственно от автора тулкита, показывает нам, что тулкит на самом деле реально быстрый.

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

Жручесть памяти пониженная (в редакторе открыто 2 окна, в одном из которых - html главной страницы ЛОРа) :

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
vadim    10448  1.5  1.3  33412 17844 pts/7    S+   19:36   1:08 adie
При том что на самом деле кучу места там просто сожрал libGLcore:
vadim@host3:~$ pmap -q 10448 | grep -v ':' | awk '$4 != "[" {print $2 " " $4}' | sort -rh | head -n5
11960K /usr/lib/libGLcore.so.173.14.30
3092K /usr/lib/libFOX-1.6.so.0.0.43
2048K /usr/lib/locale/locale-archive
1588K /usr/lib/libGLcore.so.173.14.30
1404K /lib/libc-2.13.so

После открытия 5-мегабайтного html стало так:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
vadim    10448  1.5  2.2  43988 28616 pts/7    S+   19:36   1:19 adie
Для сравнения: на этом же файле gedit и emacs отъедают больше сотни метров и наааачинааааюююют туууупииить.

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

Что характерно, этот редактор обычно даже не упоминается в статьях типа «обзор 10-ти лучших редакторов для linux» и подобных.

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

 

geekless
()

[иксы][gui][вперде] Пора сваливать на другой глобус

Берем несколько (первых попавшихся под руку) приложений и смотрим на отзывчивость интерфейса.

xterm (с запущенным emacs)
Ресайз окна — мгновенно.
Обновление окна при таскании другого окна поверх него — мгновенно.
Реакция emacs-а на ввод символов — мгновенно.
Прокрутка текста в emacs-е — мгновенно.

lxterminal (с запущенным emacs)
Ресайз окна — с практически неощутимой задержкой.
Обновление окна — мгновенно.
Реакция emacs-а на ввод символов — мгновенно.
Прокрутка текста в emacs-е — мгновенно.

gnome-terminal (с запущенным emacs)
Ресайз окна — с едва заметной задержкой и морганием окна.
Обновление окна — чуток подлагивает.
Реакция emacs-а на ввод символов — мгновенно.
Прокрутка текста в emacs-е — мгновенно.

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

scite
Ресайз окна — видно, как рисуется окно.
Обновление окна — видно, как рисуется окно.
Реакция на ввод символов — мгновенно.
Прокрутка текста — сильно чувствуется задержка.

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

Так. Ладно. Запускаем xcompmgr и повторяем эксперимент. В тех случах, где слегка моргало — моргать перестаёт. Там где сильно моргало — композитинг помочь бессилен, только сильнее стало заметно лаги.


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

Отдельную благодарность выражаю разработчикам gedit (точнее gtksourceview; впрочем, это одни и те же люди), эти ребята сделали мой день.

 ,

geekless
()

[проприетарщина][nvidia]вперде

.

nvidia-173xx and nvidia-96xx removed from extra

The nvidia-173xx and nvidia-96xx driver packages have been removed from our repositories as they are incompatible with newer xorg servers. This can only be fixed by an upstream update, which has not happened yet.

For most video cards, the best alternative should be xf86-video-nouveau; see: https://wiki.archlinux.org/index.php/Nouveau

As lower-grade options, you might also consider xf86-video-nv and xf86-video-vesa: simply remove the old nvidia driver(s), install these, and the xorg server will automatically pick the best at startup.

 ,

geekless
()

[совсем не первоапрельское] Об истинных пользователях free software

Качественный вброс на тему различий истинных и ложных пользователей free software.

Для Ъ:

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

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

Недоеденные объедки еды выкидывают на помойку. Где этими объедками кормятся вороны.

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

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

А что людям невкусно - так это ж мелочи. Главное - вороны, они определяют судьбу.

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

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

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

Дискас.

geekless
()

graphviz-подобная тулза для рисования pie chart

Требуется утилита для автоматического построения pie chart. Чтобы можно было скормить данные через параметры вызова или stdin и получить картинку с результатом.

Гугл не помог.

geekless
()

[HATE][история успеха][убивать] font-manager

Поставил я из интереса этот font-manager посмотреть, что за фигня такая. Запустил, потыкал, никаких настроек не применял, закрыл, удалил. А потом обнаружил вот это:

$ cat ~/.fonts.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>

<!--
    This file is maintained by Font Manager.

    If you wish to make any changes it is suggested you do so using

        /media/work/home/vadim/.config/font-manager/local.conf

    Any changes made to this file will be automatically relocated there
    at startup and any settings already in that file will be overwritten.
-->

    <include ignore_missing="yes">/media/work/home/vadim/.config/font-manager/conf.d</include>
    <include ignore_missing="yes">/media/work/home/vadim/.config/font-manager/directories.conf</include>
    <include ignore_missing="yes">/media/work/home/vadim/.config/font-manager/local.conf</include>
    <include ignore_missing="yes">/media/work/home/vadim/.config/font-manager/select.conf</include>

</fontconfig>

Быдлокодеры быдлопрограмм на быдлопитоне захватили все репозитории этого нашего линукса. Костыли, отслеживающие права доступа не по аккаунтам, а по запущенному ПО, становятся всё актуальнее.

И ладно: у меня есть бэкап конфигов — но сам факт!

 , ,

geekless
()

[консолемания][юзабилити] Допилил ~/.bashrc показывать имена команд в заголовке

Как я и писал в галерее, у меня bash настроен отображать выполняемые команды в заголовке окна, что дико удобно, когда открыто 100500 эмуляторов терминала, и надо найти нужный в alt+tab-списке.

Сегодня у меня дошли руки прикрутить туда же показ названий сигналов, если команда была убита сигналом. За одно привел в порядок быдлокод в ~/.bashrc и дописал комментарии, так что теперь не стыдно показать результат анонимусу.

В общем, кому нужно, забирайте. Для Ъ не будет, т.к. там простыня кода на полторы экранных страницы.

 

geekless
()

[жж][технологии вперде][javascript] chromium

Дано: сhromium 9.0.597.94, в совокупности около 80 вкладок в нескольких окнах, флеш выключен. Загруженность процессора — 8-25% основным процессом хромиума и по 1-4% каждым подпроцессом. Всё тормозит.

Отключаем javascript, перезапускаем браузер. Загруженность: 0%. Всё летает, вкладки переключаются со скоростью света.

Вроде ничего особенного не открыто: блоги, форумы, справочники, википедия, ЖЖ. Чем так усердно занимается виртуальная машина JS — тайна, покрытая мраком.
И ведь не сказать, что chromium — хреновый браузер. Остальные-то тормозят еще больше.

 ,

geekless
()

Arch + Gobo = ?

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

* Пакеты «устанавливаются» (фактически, просто распаковываются) каждый в свой подкаталог: /programs/имяпакета-версияпакета/

* Используются арчевские пакеты. Перекомпиляция не обязательна. Т.е., фактически, это только Arch с иным пакетным менеджером, а не новый дистрибутив.

* Реальная установка производится отображением файлов пакета в корневое пространство. Примерно так:
/var и /etc — сюда копируются файлы из /programs/имяпакета-версияпакета/{var,etc} (при апдейте изменённых файлов принцип тот же, что и в арче — ворнинг в консоль, что надо смерджить файлы)
/usr, /lib и т.п. — сюда кидаются симлинки на соответствующие файлы из /programs/имяпакета-версияпакета/

* Таких корневых пространств может быть любое количество. Пространства можно наследовать («пространство A = пространство B + еще 10 таких-то пакетов»), импортировать часть одного пространства в другое («отобразить в пространство C из пространства A файлы пакета blabla-1.0 по маске /usr/bin/*»). При этом, ссылки на бинарники из другого пространства ведут на утилиту, которая делает chroot в нужное пространство и exec соответствующего бинарника.
Этим решаем проблему библиотечного ада, зоопарка версий, да и в целом задачу удобного управления системами, запускающимися в чруте.

* Разумеется, предусмотреть правила биндинга в пространства имён прочих файлов: одному надо дать доступ к /media, другому — нет; одному один /home, другому — другой и т.п.

* Скрипты сборки пакетов модифицировать, чтобы пакет всегда компилировался в минимально необходимом пространстве имён на основе его списка build-зависимостей.

Еще плюшки, которые можно реализовать в процессе:

* Предусмотреть возможность глобально переопределять имена пакетов и задавать правила поиска в репозиториях. Что-то типа такого:
blabla-1.2: bazbaz-1.2 # Пакет bazbaz-1.2 пакетный менеджер будет считать пакетом blabla-1.2
barbar-*: myextra/barbar-* # Пакеты barbar всех версий пакетный менеджер всегда будет искать в репозитории myextra.

* Предусмотреть набор хуков-фильтров, отрабатывающих в момент распаковки пакета в /programs/ (или во время проставления симлинков? не уверен) и позволяющих откусывать лишнее из содержимого пакета. Например: система без info (это и так выкусывается сборочными скриптами арча, но представим, что нет); система без любых манов, кроме англоязычных; система совсем без манов; система вообще без лишнего мусора в /usr/share, такого как README, INSTALL и прочая документация.

* Предосмотреть возможность собранное корневое пространство имён сконвертировать в систему без пакетного менеджера.

Итого: экономия дискового пространства, удобно разруливать несовместимости пакетов, удобно держать на одном разделе несколько разных конфигураций ОС, удобно создавать изолированные чруты для отдельных программ. При этом сохраняются все преимущества Arch-а, включая и изкоробочную работу всего массива ПО для него — нет необходимости велосипедить свой аналог PKGBUILD-ов, как это было сделано в Gobo.

Собственно, вопросы:

1. Может быть, всё уже есть, а я изобретаю велосипед?

2. Насколько будет востребован такой механизм менеджмента пакетов?

3. Если я начну это пилить потихоньку, найдутся среди ЛОР юзеров Ъ, которые будут это принимать участие в разработке, тестировать и т.п.?

В общем, стоит браться или нет?

geekless
()

[жж] О количестве вендотроллей на ЛОРе

Примерно сутки назад я оставил ссылку на свой блог в посте в галерее. Т.к. пост висел в неподтвержденных, то смотрели его, по большей части, завсегдатаи ЛОРа, нежели случайные посетители. Ну а теперь посмотрим статистику: ccылка раз, cсылка два.

P.S. Эталонно вырвиглазное ШГ на скриншотах любезно предоставлено файрфоксом.

 

geekless
()

[ЖЖ][python][code wtf] pytyle2 и панели по бокам экрана

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

            for wid in wids:
                win = ptxcb.Window(wid)

                # We're listening to _NET_WORKAREA, so a panel
                # might have died before _NET_CLIENT_LIST was updated...
                try:
                    x, y, w, h = win.get_geometry()
                    d = win.get_desktop_number()
                except:
                    continue

                if self.workspace.contains(win.get_desktop_number()) and self.contains(x, y):
                    struts = win.get_strut_partial()

                    if not struts:
                        struts = win.get_strut()

                    key = (x, y, w, h, struts)

                    if key in log:
                        continue

                    log.append(key)

                    if struts and not all([struts[i] == 0 for i in struts]):
                        if struts['left'] or struts['right']:
                            if struts['left']:
                                self.wa_x += w
                            self.wa_width -= w

                        if struts['top'] or struts['bottom']:
                            if struts['top']:
                                self.wa_y += h
                            self.wa_height -= h
                    elif struts:
                        # When accounting for struts on left/right, and
                        # struts are reported properly, x shouldn't be
                        # zero. Similarly for top/bottom and y.

                        if x > 0 and self.width == (x + w):
                            self.wa_width -= w
                        elif y > 0 and self.height == (y + h):
                            self.wa_height -= h
                        elif x > 0 and self.wa_x == x:
                            self.wa_x += w
                            self.wa_width -= w
                        elif y > 0 and self.wa_y == y:
                            self.wa_y += h
                            self.wa_height -= h

(полная версия)

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

Долго медитировал, глядя на код. Мучили вопросы:

1. Зачем берутся размеры окна панели (self.wa_width -= w) вместо явно указанного в struts размера зарезервированной под панель области?

2. Какой мистический смысл заключен в проверке and not all([struts == 0 for i in struts])?

3. Что за wtf живёт под условием elif struts и какой частный случай он призвал был обслуживать?

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

            for wid in wids:
                win = ptxcb.Window(wid)

                # We're listening to _NET_WORKAREA, so a panel
                # might have died before _NET_CLIENT_LIST was updated...
                try:
                    x, y, w, h = win.get_geometry()
                    d = win.get_desktop_number()
                except:
                    continue

                if self.workspace.contains(win.get_desktop_number()) and self.contains(x, y):
                    struts = win.get_strut_partial()

                    if not struts:
                        struts = win.get_strut()

                    key = (x, y, w, h, struts)

                    if key in log:
                        continue

                    log.append(key)

                    if struts:
                        struts_left = max(struts_left, struts['left'])
                        struts_right = max(struts_right, struts['right'])
                        struts_top = max(struts_top, struts['top'])
                        struts_bottom = max(struts_bottom, struts['bottom'])


            self.wa_x += struts_left
            self.wa_width -= struts_left + struts_right
            self.wa_y += struts_top
            self.wa_height -= struts_top + struts_bottom

У этом варианте, УМВР.

Собственно вопрос. Кто-нибудь понимает, что хотел сказать автор кода? Или это просто code wtf, бессмысленный и беспощадный?

 ,

geekless
()

[tiling wm][не холивар] Какой tiling wm вы используете и почему?

Фреймовых оконных менеджеров сейчас расплодилось до чёрта, и, похоже, они продолжают набирать популярность. Сам я тоже пару раз пробовал пересесть на тайловый wm, но никаких решающих преимуществ по сравнению с обычными stacking wm-ами для себя не нашел и вернулся обратно.

Интересно было бы послушать мнение юзеров ЛОРа по сабжу. Когда вы познакомились с концепцией wm-ов этого типа? Как и почему пересели на tiling wm? На каком wm в итоге остановились, и какие у него самые вкусные для вас фичи?

geekless
()

Фризы системы при исчерпании виртуальной памяти

Система: практически дефолтный Arch со всеми обновлениями, ядро 2.6.36, 32-разрядная сборка.

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

Перезагрузился и решил попробовать воспроизвести ситуацию целенаправленно. Открыл на консолях top, iotop, vmstat и стал смотреть.

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

Как происходит:
При исчерпании ОЗУ, система начинает выгружать страницы в своп: в статистике vmstat растут значения si и so. Повышается %wa, но фризов нет (хотя конечно иксами пользоваться невозможно, отрисовка окон лагает дико). Далее самое интересное. Своп заканчивается, в оперативе остаётся свободным 20-30 мегабайт. si и so падают до нуля, поскольку выгружать страницы уже некуда, и загружать обратно тоже практически некуда. Система работает в таком режиме некоторое время (несколько секунд), потом всё мгновенно фризится.
Top, iotop и vmstat продолжают обновляться, но очень медленно. Из них видно, что:
1) %wa почти 100%.
2) процессы продолжают выполняться, но при этом прочно сидят большую часть времени в состоянии uninterruptible sleep
3) iotop показывает интенсивный обмен данными
4) vmstat показывает высокое bi при практически нулевых si и so!
Ну в общем, понятно.

Выйти из этого состояния можно только либо выполнив killall имя_жирного_процесса, либо Ctrl+Alt+Del. Если в момент фриза вы не были залогинены в консоли, вам не повезло: логин висит больше минуты, а затем отменяется по таймауту. killall, кстати, тоже отрабатывает минуты 2.

Собственно, вопрос: что это такое и как это лечить?

У меня есть только одна гипотеза:
В память спроецировано множество файлов, начиная от исполняемых, и заканчивая различными файлами данных. Соответственно, все немодифицированные страницы памяти можно освободить, поскольку в любой момент можно подгрузить обратно с диска. В итоге при исчерпации ОЗУ и места в свопе, система этим и занимается: постоянно освобождает страницы отображенных в память файлов одних процессов, и загружает на их место страницы файлов других процессов, и так в бесконечном цикле.
Именно этим можно объяснить высокие значения bi.
Хотя я могуть быть в корне не прав.

В общем, какие есть соображения на сей счёт? Хотелось бы, во-первых, понять механизм возникновения фриза. И во-вторых, найти метод решения.

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

geekless
()

RSS подписка на новые темы