Некоторое время назад обнаружил, что если крутануть звук на 100% (там, в колонке, есть ограничение по усилению, поэтому на 100% она не шумит, если источник в канал не выдаёт заметные шумы), то колонка начинает "свистеть", тихонечко, по-цифровому.
Думаю, хер с ним, вероятно, по-просту шумный звуковой тракт. Такое бывает. Тем более, у гигабайта не всегда в плане шумов всё идеально. (Зато если визуально странного на материнке нет, типа, батарейки вплотную к радиатору, то доски обычно живучие.)
Возникает логичный вопрос: как бы сократить эти шумы, потому что они и правда достают. Ну то есть, смотришь ты какой-нибудь ютубчик - их особо не заметно на фоне, например, голоса, вещающего в ролике, а вот если ты занят каким-то другим делом, допустим, пишешь какую-нибудь прогу или скриптец, то шумы уже вполне заметно, особенно ночью, когда все вокруг уже засыпают.
ЧСХ, при заметной нагрузке на процессор, шумы исчезают. Думаю, это зацепка. Возможно, дело в частоте? Ставлю штатные 1800 в качестве базовой/минимальной частоты. Ноль эффекта. Решил поковырять драйвера. Иногда, надо выключить энергосбережение "чтобы работало лучше". Выключаю, где нашёл - ничего не поменялось.
Думаю, жаль... Но вроде в биосе есть "акустик менеджмент", который, как будто, про свист дросселей и вот это всё. Там формулировка "акустические шумы", без конкретики. Но есть пояснение, что настройка влияет на C-State.
Покрутил настройку - влияние есть. На тональность шума там вариации на тему fast/2, fast/4, fast/8, fast/16 (чтобы это ни значило). 16 даёт вместо свиста, тихое рипение, эдакий храп. Красота. Но совсем не то, к чему мы стремимся.
Однако, там было что-то про C-State. Выключаю все доступные к выключению C-State, и шумы пропадают вообще. Полностью.
Вобщем, на десктопе надо не забывать выключать c-state. Комп будет жрать чуть больше, но звук в наушниках/колонках будет чище. В моём случае остались невыключаемые c0 и c1. C1 это инструкция hlt, со слов биоса. Что такое c0 - тайна.
Что касается ноутбуков, то там история чуточку другая - там важно время работы от батареек и каждый ватт на счету и возможно отключение c-state там будет не самым оптимальным выбором.
]]>По свежим следам - на днях я таки решил завернуть звук с одного компа на другой.
Дело в том, что у меня сетам из 2-х компов - один из них включён постоянно и это не такой мощный комп, кроме того на нём встроенная видяшка. Собственно, была идея его держать по-возможности включённым постоянно.
И есть другой комп - на нём крутится виртуалка с рабочим окружением и игрушки. Ну и виртуалка с программизмами, когда мне надо попрограммировать конкретно под линуксом. Например, по причине того, что разработка перлового барахла на линуксе происходит с бОльшим комфортом, чем под вендой.
А у него нету колонок для вывода аудио. Дело не страшное, вроде как можно использовать наушники.но от науников потеют уши. Да и потом у меня внутриканальные наушники, а от них уши устают часа через 2. А рабочий день - 8 а то и 9 часов.
В теории можно было бы забить и переставить колонки с одного компа на другой, но заниматься этим на регулярной основе что-то не очень хочется. С другой стороны на отдельные колонки на столе места маловато.
Можно купить KVM-свич и лёгким манием руки переключаться между компами. Это тоже вариант. Но у меня уже был свич, опыт от этого не то чтобы приятный. Особенно, если на одном компе у тебя висят 2 монитора, а на другом - всего один.
Есть ещё один вариант - подключиться по rdp к другому компу и работать через так. У меня это не получилось сделать по той причине, что RDP почему-то пытался сделать что-то странное - то есть он идеально работает, если учётная запись майкрософтовская, но если она локальная, то ошибка авторизации. У меня локальная учётка, я старомоден.
VNC в принципе работает, но понятное дело, что оно работает медленно. Во всяком случае по сравнению с rdp-то уж точно. А звук vnc не захватывает - он для другого.
Как его передать на другой комп? По сети, конечно. Интернеты подсказали такую программу как butt - broadcast using this tool. Спонсируется одним из сервисом по предоставлению radiostation as a service.
Помимо захвата аудио с микрофона эта штука умеет хватать и устройства воспроизведения. Нам это и нужно. Программа хватает звук с выходного устройства и отправляет его на icecast-сервер. К этому серверу мы цепляемся через какой-нибудь vlc и получаем звук на удалённой тачке. То что нам надо было.
В моём сетапе butt запущен на тачке с видюшкой, а icecast и vlc на рабочей лошадке.
Да, он есть. Звук отстаёт примерно на 3 секунды. Мне удалось сократить это отставание. Во-первых, сокращением размера буфера в vlc (100мс для воспроизведения "блым-с" от очередной icq или от телеги вполне терпимо, по сути - это в основном и есть цель всех этих совокуплений). Во-вторых, отключением burst-а в сервере icecast, кроме того, и размер буфера в нём тоже имеет смысл подрезать. От размера буфера зависит задержка, напрямую.
В итоге я остановился на задержке примерно в одну секунду.
Не сказать, что такой сетап меня полностью устраивает, но он вроде как работает. В...
]]>Закончилась ещё одна итерация связанная с "совершенствованием" (или деградацией) бота aleesa.
Когда-то давно, году эдак в 2008-м этот бот начинался, как забавный развлекательный сервис в конференции slackware на jabber.ru. Время шло, бОльшая часть участников того канальчика разошлись своими путями... С кем-то мы встретились снова, а кто-то пропал из поля зрения. Сама конференция перешла в telegram, но комната на jabber.ru осталась. И внезапно она не пустая.
Бот aleesa претерпел несколько инкарнаций, сменились движки - то это была isida, то eggdrop... какое-то время бота и вовсе не было. И вот в один прекрасный момент я натолкнулся на перловую библиотеку для создания xmpp-ботов. И оказалось, что на том же самом перле есть всё необходимое для написания собственного бота.
Начальная инкарнация бота - это альфа-версия бота sulci. Автор бота работала в компании Яндекс и бот был скорее pet-проектом для расширения кругозора, чем чем-то серьёзным. Насколько мне известно, в какой-то момент времени она переехала в Испанию и бот оказался заброшеным. А поскольку он написан на ЯП ocaml, а это довольно экзотический язык, то поддерживать его оказалось некому. Sulci был интересен тем, что в нём был встроенный бредогенератор на основе цепей Маркова. И работал он странно, но забавно и вокруг этой фишки был построен весь бот. Остальное - это приятный бонус.
Так вот, оказалось, что вменяемого движка подобного рода нигде нету. И вот в один прекрасный момент я обнаружил таковой в перле. Это модуль hailo. И это событие стало отправной точкой в создании собственного "движка" бота.
Однако в ходе эксплуатации выяснилось, что xmpp-либа, которая есть в перле, обладает фатальным недостатком - она абсолютно не умеет обнаруживать, что соединение с сервером пропало. Я уж не говорю о том, что она абсолютно не умеет в обнаружение того, что бот больше не в комнате... Это довольно серьёзные недостатки, так как рано или поздно бот от конфы "отваливался". И есть ещё один существенный недостаток - бот использует собственную реализацию event loop-а - это не mojo, не anyevent и не poe. То есть интеграция его с этими event loop-ами будет болезненной - в приложении не может быть 2-х разных event loop-ов.
Кроме xmpp-бота у меня есть бот для telegram-а. И с некоторого времени он уже модульный: часть модулей на гошке, а часть - на перле. И благодаря модульности, у меня есть ещё и фронт-энд для irc, который тоже умеет в бОльшую часть сервисов, в которые умеет телеграммный бот. В том числе и в бредогенератор.
И возникла мысль - пора перенести xmpp-бота на этот модульный движок.
Переносить на перле - "ну такое". Придётся переписать собственно весь движок с кастомного event loop-а на что-то более "стандартное". На тот же anyevent, например. И... это в какой-то мере боль. Да, при этом я не связан узами обратной совместимости, но... кидаться xml-ками по tcp-соединению - развлечение "ниже среднего". Тем более, что у меня уже есть небольшой опыт программирования на гошке. Почему бы не написать этого бота на гошке?
Итак, гошка, либа go-xmpp от товарища mattn-а с гитхаба. Первая попавшаяся из относительно "свежих". Она же относительно минималистичная.
Судя по всему, мне везёт на забрасываемые...
]]>Тогда эти машинки у меня не задержались надолго. И на ~12 лет я просто забыл о существовании MacOS и яблочных устройств. Но в один прекрасный (или не очень) момент пришлось о них вспомнить. На работе сказали, что есть два стула - "совсем не очень" и "так себе". И этим "так себе" оказался Macbook Pro. И тут я уже подошёл к маку несколько более придирчиво, профессионально, если можно так выразиться.
На своих линупсах я уже давненько использую CapsLock для переключения раскладки клавиатуры и это работает быстро и чётко. А тут.. MacOS предлагает такую опцию из коробки. Казалось бы - вот оно, счастье. Но тут есть подвох. И вот я хочу поведать очередную охренительную историю о такой казалось бы простой вещи, как переключение языковой раскладки клавиатуры.
Штатно, насколько я помню, переключение раскладки в MacOS происходит по Option+Space/Option+Shift+Space что несколько неудобно, так как приходится сдвигать не только пальцы, но и руку целиком, если хочешь переключиться одной рукой. Можно переключаться двумя руками, но такой привычки ни у меня, ни у моих знакомых просто нету. А вот у моих знакомых-программистов есть привычка переключать раскладку по CapsLock, которую я благополучно перенял. Довольно удобный маппинг. В современной жизни кнопка Caps Lock используется крайне редко, но при этом находится в довольно удобной позиции относительно левого мизинца.
В Windows, например, переключение штатно висит на Alt+Shift, (в старых инстолляторах windows переключение раскладки было (неочевидным образом) назначено на left shift+right shift). Как альтернативный вариант, Windows предлагает переключение раскладки на Ctrl+Shift. Оба варианта пользуются в народных массах довольно широкой популярностью. И благодаря своей распространённости - это тоже неплохой вариант: механическая память - очень сильный мотиватор.
Сочетания кнопок "как в венде" для переключения клавиатурной раскладки в MacOS штатным образом намапить не получится: кнопки Cmd, Option, Alt, Shift, Ctrl - это модификаторы, а сочетание кнопок в MacOS должно состоять из 1 и более модификатора и одной обычной кнопки. По этой же причине нельзя зарегистрировать CapsLock в качестве переключателя раскладок из меню keyboard shortcuts.
Но вернёмся к нашим баранам.
Итак, переключение на Caps Lock. Можно настроить прям в настройках клавиатуры - переключение на английский и обратно по Caps Lock. Поскольку у меня всего 2 локали - это выглядит как то что надо. И... тут возникает нюанс: при нажатии на Caps Lock переключение происходит "какбы" не моментально и если начать печатать текст сразу после переключения, не выждав ~0.3 секунды, то переключение раскладки не произойдёт. Кроме того, само по себе переключение в некоторых случаях не происходит. Таким образом, штатные средства нам не подходят - они настолько жалкие, что вызывают только раздражение.
Другой вариант - это Karabiner Elements....
]]>Меня ждал сюр... сюрприз. Я никак не мог ожидать, что воскресная "история на полчаса" затянется на несколько вечеров.
Установочный диск freebsd меня приветствовал надписью btx halted. На тот момент я уже знал, что btx-говно, но мне ещё предстояло открыть - насколько.
Итак, традиционно, дебуг мы начинаем с убирания всего лишнего. Убираем usb-коробочку и... Установщик запускается нормально, как родной!
Тут надо бы уточнить, что у меня за система, а это материнская плата Asus P5Q-EM, она выпущена в далёком 2008-м году, то есть ей уже пошёл.. 14-й год. Но к чести Asus эта плата - живчик, никаких сбоев, глюков, странного поведения - очень удачный в плане беспроблемности экземпляр.
Вобщем, btx не завис, это значит, что проблемы вызывает именно коробочка. И коробочка у меня оказалась не то чтобы старая - это китайский полупрозрачный бокс, максимально дешёвый и работающий по интерфейсу usb-3.0. С приличными скоростями - на моём ssd мне удавалось выжать из коробаса почти 500 мегабайт в секунду на чтение и около 120-130 мегабайт в секунду на запись и, скорее всего, я упирался в производительность самого ssd. В windows и в linux этот коробас работает без нареканий - надёжно, без каких-либо сбоев. В MacOS - своя атмосфера, они там любят через некоторое время отключать usb-устройства, для экономии энергии и... возможно, там надо какие-то биты где-то ставить в device features или ещё где... вобщем, китайцы про это не знают.
Акей, одна коробочка виснет, но у меня есть другая! она по-древнее, умеет только в usb-2.0, но на плате 3.0 нету, поэтому в плане производительности мы ничего не теряем. А что с совместимостью? Btx halted. То есть, тоже самое.
Интересная история. Допустим... А может, дело тут в чипе, на котором сделана коробочка? (точнее, в драйвере, через который работает btx с такими коробчками). Для меня было открытием, но оба коробаса реализованы на чипе JMicron. Чипы сами по себе максимально дешёвые и известны тем, что умеют работать на широком спектре разных шин - pci, usb, pci-express итд, в электрическом плане относительно неприхотливые, работают устойчиво, умеют в разные режимы - в т.н. IDE-режим и в AHCI. Старая коробочка шла в комплекте с ssd Kingston в качестве т.н. migration kit. Удачная конструкция для механических дисков, они в ней не дохли, как, например, в одной из коробочек transcend (это прям death box для дисков был). И проблем с совместимостью у этого коробаса вообще никаких не было: с неё умели взлетать линуксы чуть ли не с ядром 2.6, с неё устанавливалась windows, в т.ч. в uefi-режиме (если коробас разметить в gpt, а партицию с установщиком сделать esp fat32 и запускать установщик в native uefi режиме). За новую я такого не скажу - её роль была - для создания бэкапов.
Но, довольно лирики....
]]>Однако, у меня есть mac для работы, у меня есть slackware linux для дома, для души. И собственно, на mac-е я поставил несколько софтинок именно из brew, так почему бы не поставить некоторый софт для linux-а тем же способом, тем более, что заявлена возможность работы этого софта на linux под amd64.
Сразу бросилось в глаза, что на mac brew со своими говнами ставится в /usr/local, а в linux - в /home/linuxbrew/.linuxbrew. Второе, что бросилось в глаза - это естественно менее богатый набор софта. Не то чтобы под линукс его катастрофически мало, нет, но кое-чего таки отсутствует. Например, нету psi и psi-plus (а под mac - есть).
Кроме того, brew несколько странно подходит к поставке софта: что-то поставляется в бинарной, собранной форме, а что-то собирается в процессе установки.
Что касается требований к программной платформе, то это должен быть linux на glibc, для amd64. И сравнительно не тухлый, то есть на CentOS-7 этот brew у меня не взлетел (просто написал, что glibc старовата и ruby нужен 2.6), а, например, на AlmaLinux 8 (продолжатель традиций CentOS) уже всё заработало.
И сам набор софта тоже несколько удручает - есть что-то, чего нету в пакетной базе большинства дистрибутивов, но это относительно экзотические вещи, которые нужны не то чтобы не всем, а я бы сказал единицам пользователей. Всё остальное - сравнительно "стандартное", но то, чего по тем или иным соображениям apple не включила в базу mac os (например, neovim, nginx).
Ну и что касается самого brew - при каждом запуске эта метаплатформа проверяет наличие свежей версии и самообновляется. Данные о "формулах" и "колбах" находятся в git-репозитории, который на текущий момент весит немногим за 500 мегабайт.
Вероятно, именно потому что brew ориентируется прежде всего на mac, а уже потом на linux, эта метаплатформа не пользуется популярностью у линуксоидов - нету киллерфич. Да и уникальных пакетов в репозитории всего-то 6223 (на 30 июля 2022) и довольно большая часть из этого - это зависимости и зависимости для зависимостей...
А для мака... там на безрыбье и brew пойдёт.
]]>Собственно, идея переписать этот модуль с перла на гошку и тем самым сократить количество потребляемой памяти и заодно ускорить работу модуля.
Что не устраивало в оригинальном модуле, так это сам перл. Есть ряд смущающих меня особенностей работы этого самого перла. Да и сам язык медленно но верно отходит в историю, как таковой.
В оригинале модуль... плагин... сервис... вобщем, демночек, реализующий эту функциональность написан на перле, в качестве ивент-лупа, на котором построено приложение, запользован фреймворк Mojolicious (достойный фреймворк, надо сказать). Для интерконнекта задействован Mojo::Redis, который, в теории, позволяет использовать биндинги к либе hiredis через Protocol::Redis::XS, но этот модуль уже довольно приличное время не мэйнтэйнится и не собирается с современной версией lib hiredis. Соотвественно, Mojo::Redis работает на pure perl реализации протокола redis, что не супер быстро. Ну, и понятное дело, где-то надо хранить данные. Можно, конечно, хранить их в текстовых файлах или в json-чиках, но вычитывать из этого данные - процесс не быстрый, да и нагрузка на диск (относительно) велика. Я взял BerkeleyDB в лице CHI::Driver::BerkeleyDB для складывания кармы фраз. И SQLite_File для складывания статических данных в tied hash с последующим извлечением из этого хэша данных, как из ro-таблицы. Всё это в куче работает с удовлетворительной скоростью для бота. Тем более, что популярность генерируемого этим демоночком контента не то чтобы очень велика.
Технически я давно тому назад пробовал взять Tie::LevelDB и в принципе оно работает неплохо, но... это ещё один компонент в и без того сложном приложении (а в тот момент это был весь бот целиком в "одном флаконе", монолитное приложение).
Соответственно, при планировании приложения с аналогичным функциями, но на гошке, надо было оперировать тем, что есть для этого ЯП. Писать сервис 1 к 1 я изначально не планировал, т.к. это слишком затратно. Была идея воспользоваться тем, что есть.
После беглого анализа, я выяснил, что bdb в гошном исполнении нету, зато есть старые знакомые - плеяда различных вариаций на тему leveldb/rocksdb и их подражателей/продолжателей.
Оригинальная реализация leveldb - это у нас заброшенный проект биндинга к сишной либе.
Есть и другие биндинги к сишной LevelDB, например, Levigo. Понятное дело, что это сразу "нет", привязываться к сишке без особой надобности что-то не очень хочется.
Go-leveldb - это чисто гошная реализация leveldb. Более менее полная и вполне себе работающая.
Pebble - это вариация на тему RocksDB. Неполная реализация, нужная CockroachDB для работы.
GoRocksDB - это биндинг к сишной rocksdb. И там пацаны намекают, что у них всё может поменяться в любой момент. Типа, если нужна стабильность - вендорите либу.
Далее, есть в природе BadgerDB и BoltDB эти бд тоже навеяны идеями leveldb/RocksDB, но реализуют эти идеи в довольно витиеватом api. Работать с ними, скажем так - сложновато, городить специальные врапперы, упрощающие этот процесс, я смысла не увидел, особенно при наличии более простых альтернатив.
Также имеется бд Pogreb, в некотором роде напоминающая LevelDB. В ней есть всё, что надо...
]]>Как выяснилось позже технически это было не самое удачное решение. Дело в том, что бот сам по себе был написан на языке ocaml, полагаю, что на тот момент это был очередной убийца плюсов. В нём были некие задатки "инфраструктурности" - управление версиями библиотек и тд... Но обслуживать это всё было не совсем понятно как. Сам бот был "экспериментальным", у автора было не то чтобы много времени на его доработку, а поскольку ocaml имел относительно высокий входной уровень, то желающих поддерживать этот проект по-просту не нашлось, да и github-а на тот момент тоже ещё не было и не сформировалась соответствующая культура... И вот в один прекрасный момент после апгрейда дистрибутива с одной версии debian на другую или возможно при переезде на другой дистрибутив вообще (я уже не помню) выяснилось, что sulci не собирается. Проковырявшись приличное время ( а на тот момент я ещё не был прожжёным линуксоидом), я таки заставил работать этого бота снова.
Это было одно из тех разочарований, которые крепко запоминаются. То есть, если бы бот был написан на чём-то универсальном, например, на плюсах (уж коли речь идёт за компилируемые языки), то с помощью сообщества и такой-то матери, кое-как но можно было бы заставить его работать, но ocaml как язык вначале немного ушёл вперёд, а потом и вовсе оказался на свалке истории. Через некоторое время туда же отправился и бот sulci.
Чуть позже была найдена альтернатива. То да не то - у "нового" бота не было бредогенератора - он умел отвечать стандартными фразами. Что конечно сильно печалило. Это была Isida. Сейчас развивается уже 6-я инкарнация этого бота и уже для телеграма, но тогда это была вариация на тему xmpp/jabber. Это более удачный вариант, т.к. он написан на питоне, а питон всё-таки (даже в те времена) популярный яп. Кроме отсутствия бредогенератора, какой ещё подвох? Вероятно на тех версиях isida, которые были связаны с jabber-ом автор тренировался в программировании на python-е, соответственно, сам бот был известен тем, что применял непопулярные подходы и парадигмы в своей кодовой базе.
Через некоторое время возникли определённые проблемы и с этим ботом. И я на довольно продолжительное время даже подзабил на бота, потом ради интереса запускал dropegg-а с megahal-ом через bitlbee... Но эта конструкция была больше лютым костылём, чем нормальным чат-ботом.
И наконец, где-то около весны 2019-го года, или пораньше была придумана 3-я мажорная версия aleesa-бота, чуть позже в том же году была сделана и jabber-вариация бота. Это была уже независимая поделка на perl-е, вокруг ботовых фреймворков, которые реализуют бОльшую часть подкапотной механики. Но, увы, автор телеграммной либы на неё забил, пришлось её форкнуть и влить в бота и с каждым обновлением bot api апдейтить эту либу. Что же касается jabber-ной либы, то здесь история более...
]]>В эпоху победившего systemd говорить о других системах да и вообще заострять внимание именно на системе инициализации как таковой уже не модно.
Но тем не менее, как то раз мне на глаза попалась новость о выпуске очередной версии этой системы. Тогда я лишь мЕльком глянул, что это за система и забыл.
Некоторое время назад эта тема всплыла снова. И тут я решил присмотреться к finit - собственно, что это и с чем его едят.
В тексте проекта написано, что автор вдохновлялся и вобщем-то содрал (чего уж там таить) довольно много наработок fast init-а. Проекта, автор которого занимался реверс-инжинирингом системы инициализации в первых eeepc.
Но, как бы то ни было, а результат получился... очень напоминающий классический system v init. Но на стероидах и подкостыленный. Стероиды напоминают идеи systemd, то есть имеется подпорка под инициализацию иксов, свои getty и по мелочи разные вещи.
Собственно, feature creep - это то, что мне не понравилось.
Что могло бы стать киллер-фичей? Зависимости между сервисами. В документации декларировано, что сервисы могут стартовать в зависимости от неких условий, в том числе по условию наличия pid-файлов и юзерских событий. Вроде звучит круто. Но ведь есть подвох? Должен быть подвох 😊
И он действительно есть - pid-файл должен создаваться сервисом. Мало того, несмотря на то, что сервис запускается, факт запуска сервиса не является событием. Конечно, есть генератор событий, то есть перед запуском сервиса в foreground-е можно бы триггерить такое событие, а все зависящие сервисы запускать с паузой например в 1-3 секунды, "чтобы уж точно". Но во-первых - не точно, а во-вторых, если я руками сервис остановлю, то ивент об остановке сервиса не будет сгенерён.
Как это можно было бы обойти? Хуками на пред-запуск, перезапуск, остановку и аварийное завершение сервиса. Но таких хуков в finit вообще нету. А вот, например, в openrc с событиями всё хорошо - то есть там вполне можно построить иерархию зависимостей сервисов. И, например, тогда, при запуске сервиса, который зависит от других сервисов, эти сервисы будут автоматом запускаться. А при останве сервиса, от которого зависят другие сервисы, эти все сервисы будут тоже автоматически останавливаться.
В результате мы имеем довольно бесполезный init, мало чем отличающийся от того же runit-а по своей сути. Разве что oneshot-скрипты поддерживаются из коробки (но формально такие же one-shot-ы можно накостылить и в runit-е. Например, через таски, которые никогда не завершаются (которые последней инструкцией например вызывают cat /dev/null
или делают while [ true ]; do sleep большое_число; done
, насколько помню sleep infinity в баше для 32 бит - это 68 лет а для 64 бит - это 10 ^ 11 лет).
Собственно, исключая синтаксис конфигов, finit от runit-а отличается только количеством форков в процессе запуска системы + синтаксисом этих самых конфигов.
Учитывая, что bash - это не самый эффективный и быстрый shell, то по большому счёту многие моменты оптимизации процесса подготовки системы к запуску или завершению работы сводятся к тому, чтобы запускать стартовые скрипты из-под например ash или dash, которые быстрее, имеют меньше зависимостей от системных библиотек, а также уменьшить количество вызываемых grep awk...
]]>Собственно, freedesktop-ное понятие seat на практике не так часто имеет место быть. Ну да и бох с ним. Сейчас образовалась иная ситуация.
Итак, немного ковыряясь в настройках i3wm и остальных компонентов десктопного окружения, иногда приходится графику рестартовать. Можно ребутнуть тачку, а можно раскорячить пальцы и нажать ctrl+alt+backspace. Как результат иксы грохнутся, но тут же взлетит новый экземпляр, всплывёт dm и предложит залогиниться. Логин происходит успешно, загружается десктоп... но не работают desktop notifications. Пробуем запустить нотификалку ручками - то бишь dunst, а он говорит, что не может прицепиться к dbus и падает.
По большому счёту, мало какому софту прям вот позарез надо dbus, но desktop notifications - это тот самый редкий пример, который работает исключительно через dbus.
В чём причина отказа dunst работать через dbus? А в неактуальности данных в переменной DBUS_SESSION_BUS_ADDRESS. А переменная эта наследуется через конструкцию запуска сессии "ck-launch-session dbus-launch --exit-with-session /usr/bin/supervisord" и так далее. Казалось бы, при повторном запуске эта вся хрень должна генерить новую сессию, новый экзепляр dbus итд... но что-то идёт не так и в переменной остаются неактуальные данные.
Касаясь конкретно dbus-а, можно сделать предположение, что более одной сессии (особенно, графической) у меня на этом компе не будет, мало того, от меня не убудет, если на все сессии моего юзера будет один инстанс dbus. Соответственно, достаточно положить сокет dbus куда-то в user-специфичное место, например, в ${XDG_RUNTIME_DIR}/dbus.session и нерандомизировать его имя, но при этом усиленно супервайзить сам dbus на предмет того, что он запущен. В этом случае можно выкладывать сторого известного содержания переменную на этот dbus-сокет и не волноваться ни о чём.
Собственно, я это и сделал. dbus запускается перед "сборкой" сессии. Теперь проблема неактуального сокета решена. Ну, то есть в условном ~/.xinitrc можно прописать нечто вроде:
DBUS_SESSION_BUS_ADDRESS="unix:abstract=${XDG_RUNTIME_DIR}/dbus.session,guid=5dfc247e34effbb3bcf4305a61600182"
/usr/bin/dbus-daemon --session --fork --address="${DBUS_SESSION_BUS_ADDRESS}" || :
export DBUS_SESSION_BUS_ADDRESS
и оно будет прекрасно работать.
]]>