Все мы знаем, как сильно выручает cygwin, когда приходится работать в Windows (и где-то тут в галерее даже были скришоты с cygwin :) ). Но, между тем, относительно мало известен coLinux — проект по портированию ядра Linux поверх ядра и служб NT.

Завелся тут у меня компьютер с Windows XP, на который я не могу поставить Linux (пускают на нём виндузятные программы, да и комп не мой). Стоит себе, простаивает без работы большую часть времени. И посетила меня мысль запустить на нём систему посредством coLinux, чтобы гонять там distcc. Установил andLinux (coLinux + урезанная Убунту), собрал под неё pacman, накатил Арч из репозиториев. И что вы думаете? — Работает! ;)

На скриншоте на заднем плане виндовый эмулятор терминала, в котором запущен демон coLinux. В верхнем левом углу эмулятор системной консоли (в частности, виртуальные консоли переключаются по Alt-{F1..F12}, как и положено). На переднем плане три окна Eterm, отображающиеся в Windows при помощи Xming.

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

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

В общем, для тех, кому приходится, скрепя сердце, сидеть за Windows, или кому надо облинуксить по-быстрому машину с виндой, coLinux будет очень полезна. На оффсайте, кстати, лежат предустановленные образы нескольких дистрибутивов, от Gentoo до Федоры, но там старьё. Лучше руками поставить.

Я у себя в блоге описал подробно процесс установки Арча, может, пригодится кому. Там же и «моар» скриншотов можно посмотреть.

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

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

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

Поскольку 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. Если я начну это пилить потихоньку, найдутся среди ЛОР юзеров Ъ, которые будут это принимать участие в разработке, тестировать и т.п.?

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

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

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

Решил составить для grc универсальный конфиг, выполняющий подсветку чисел, размеров («100 MB»), дат («21.02.2011»), /путей/от/корня, прав доступа («-rwxr--r--»), ip адресов и прочих вещей, часто встречающихся в выводе команд. И вот что получилось.

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

Сам конфиг и соответствующий набор алиасов для оболочки можно взять у меня в бложике.

Пришлось помучиться с правильной подсветкой прав доступа. «В лоб» у меня не получилось при помощи ()-захвата фрагментов регулярки распарсить такое выражение, пришлось подсвечивать в 4 шага: сначала захватывать тип файла, а затем по 3 фрагмента rwx. Хотя возможно, я просто протупил что-либо. Остальные регулярные выражения довольно тривиальны.

Для ссылок подсветку делать не стал, т.к. она уже встроена в gnome-terminal.

В главных ролях:

Дистрибутив: Archlinux.
Управление окнами: Openbox + pytyle2
Панель: Gnome Panel + апплеты GlobalMenu, Window Title, Window Buttons
Шрифты: Либерастика и терминус.

Подробности:

Заголовки окон отключены. Гномопанель используется, главным образом, ради апплетов Window Title, Window Buttons и GlobalMenu.
Окнами управляет Openbox. Для тайлинга — пропатченный pytyle2. Глобальные хоткеи, не относящиеся напрямую к управлению окнами, повешены на xbindkeys.

В роли ШГ Либерастика и Терминус + убунтовские патчи на рендеринг. Текст в интерфейсе, главным образом, тёмно-серый по светло-серому (либо наоборот) — меньше устают глаза и не видно субпиксельной радуги.
Набор иконок: MacUltimateLeopard — просто потому, что остальное либо страшное, либо надоело. Вместе с набором иконок в меню приложений приполз логотип Убунты, но выпиливать лень, так и живёт.
Темы Gtk: модифицированная Glossy и ThinIce. Переключаю их пару раз в месяц, чтоб не приедались.
Вкл/выкл рабочего стола наутилуса повешен на хоткей. На рабочем столе обычный бардак, но обычно рабочий стол просто выключен.

mc с темой xoria256. Подсветка вывода некоторых команд в консоли через grc. bash настроен отображать в заголовке терминала запущенную команду, а после её завершения — копию промпта + код возврата + название выполненной команды. Очень удобно. Вообще это, конечно, хак, реализованный через trap DEBUG, для нормальной реализации такой функций, похоже, надо патчить исходник.

Ну и пара скриншотов в традиционных для ЛОРа жанрах, куда ж без них: браузер с ЛОРом и файловый менеджер с корнем.

Обнаружил, что 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, бессмысленный и беспощадный?

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

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

Система: практически дефолтный 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.
Хотя я могуть быть в корне не прав.

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

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