>> Что бы действительно соответствовало моей логике, перечислите приложение которые
>> необоснованно завязываются за procfs/sysfs.
> Для начала - а кто решает "обосновано ли?", по каким критериям, и
> почему - именно он и именно вот так, а не кто-нибудь
> другой и как-нибудь иначе? Я уже не в первый раз спрашиваю,
> но ни разу не увидел ответа. Или просто пропустил.Вопрос сложный и каждый его решает сам.
Моя точка зрения:
1. если библиотека/подсистема не является необходимой частью для выполнения ключевых задач проекта, а лишь нужна для второстепенных возможностей - то она должна быть опцией.
2. выбранная библиотека/подсистема должна быть одним из лучших вариантов для решения _конкретной_ задачи.
> На всякий случай напомню что эксклюзивно решать как и что - лично
> вы можете за всех в 1 случае: если вы пишете и
> систему и программы целиком сами. В остальных случаях это будут какие-то
> иные критерии и механизмы, к тому же динамически меняющиеся во времени.
Слава Столману, мы говорим о свободном софте и каждый сам выбирает какой софт использовать или может изменять его под свои нужды/воззрения, в плоть до форка или создания альтернативных решений.
> С чисто технической точки зрения, теоретически ни sysfs ни procfs не являются
> абсолютно необходимыми.
Для большинства программ - да.
> Вон например в винде ни одна программа ими не
> пользуется. Значит, можно писать произвольные программы и без procfs и sysfs.
О том и речь: ненужно завязываться без реальной необходимости на особенности системы и портировать софт станет гораздо проще. Я выше озвучил свой эксперимент с отключением procfs/sysfs - можно найти приложения излишне цепляющиеся за procfs/sysfs, но в большинстве своем приложениям они не нужны.
> Они лишь позволяют что-то сделать удобнее, получить какую-то дополнительную информацию,
> на что-то повлиять. Можно придумать кучу иных методов как сделать то
> же самое без них. Ну там позаменять все ioctl'ами и syscall'ами,
> например. Иногда сисколы даже лучше чем файловые операции, как например вызов
> для получения рандома (работу сисколов сложнее саботировать чем файловые операции, а
> саботаж получения рандома штука чреватая).
Все зависит от конкретной задачи.
> ...а мой пойнт - в том, что все то же самое про
> нужность и использование можно сказать и про системные шины. Единственные отличия
> - может быть это скажут другие люди для других программ. А
> нужны ли эти программы лично вам - вообще дело десятое, имхо,
> т.к. ни Linux ни программы вообще не пишутся для лично вас.
> И поэтому учитываться должно далеко не только ваше мнение, по логике
> вещей.
Естественно, более того я рад _любому_ открытому проекту, даже если его подход отличается от того, который предпочитаю я. Но мне не нравится когда мне что-то навязывают и делают обязательным - это мешает здоровой конкуренции и сужает круг возможностей.
>> Я и не спорю, что в определенных случаях системная шина может быть
>> реально полезно, но пока мне попадались не очень удачные примеры ее использования.
> Это уже другой вопрос. Зачем именно gimp-у шина для вкладое - загадка.
Он сам себе посылает имя файла,который нужно открыть.
> А вот например рассылать так события затрагивающие работу системы в целом
> - очень даже. Ну вон в Nokia N900 (и более ранних
> Nokia 770, 800 и 810) - нокия конкретно оттянулась с d-bus.
> И заявы про ресурсы - идут лесом! Знаете, у этих девайсов
> мало ресурсов.
Просто ответьте - сколько памяти ест голая (без пользовательских приложений) система после запуска?
> И d-bus там - далеко не основная проблема. Наиболее
> прожорливы там, пардон, иксы.
1. Почему вы решили, что Xorg потребляет ресурсы необоснованно?
2. Если что-то потребляет ресурсы, это еще не повод плюнуть на все остальное.
> При том зачем фирма нокия так сделала - я понимаю. Они много
> ломали голову над сбалансированным набором компромиссов. Потому что ресурсов мало, фичей
> хочется огого, время на разработку - не резиновое и прочее.
ИМХО сделали как было проще, а на потребление ресурсов забили.
> И даже несмотря на хилые ресурсы, и d-bus и пульсаудио по итогам
> им оказались лучше чем самим все велосипедить.
Особенно PA - еще одна прослойка, преобразующая достаточно неслабый аудио поток, очень уместна на embedded. Андройдовцы наоборот пилили tinyalsa - им и возможности alsalib казались бессмысленными.
> Вот это - пример сбалансированного дизайна системы. Где оптимизации которые дают наибольший
> выигрыш - постарались сделать, насколько это позволяли разумные временные рамки. И
> кроме всего прочего, результатом просто приятно пользоваться. Он радует глаза и
> уши и весьма умеренно тормозит если не слишком увлекаться многозадачностью.
А без pa/dbus/и прочих демонов он работал бы медленнее?
> Ведроид
> с его явой тормозит и на вчетверо больших ресурсах. На ресурсах
> как у Nokia 770 и 800/810 - ведроид фундаментально не жилец.
> А на ресурсах как N900 он ... cильно хуже maemo.
Андройд вообще забавный зверь - походу его делали две разные команды: нижний уровень (до явы) относительно неплохо сделан, есть интересные моменты, но верхний ...
> А у вас антипатии к d-bus и прочие бряцания оптимизациями имхо завалились
> в иррациональный и контрпродуктивный формат, когда тормозным и жирным блоатваринам типа
> иксов, которые к тому же плохо работают - за что-то скидки.
> Зато под нож почему-то идут какие-то полезные на мой взгляд сервисы,
> явно не являющиеся лидерами top-списка.
То есть надо ждать, пока dbus/sytemd не станут есть больше чем Xorg?
>> Ну да, она нужна только тем, кто профессионально работает со звуком, кому
>> нужна минимальная задержка и максимальная гибкость,
> Ну вот этим и пользуется полторы узкоспециализированые программы на планете.
Весь софт создания/обработки звука (+ видеоредакторы и многие плееры) под линукс, включая закрытые коммерческие (тот же pianoteq). Насколько я помню его и под другие ОС портировали, но не знаю зачем и с каким успехом.
>[оверквотинг удален]
> А вот это - отдельная специфичная математика. И грабель там много. И
> не все делают это хорошо. И вы знаете, да, либы так
> умеют. Но положа руку на сердце, pulseaudio делает все это намного
> качественнее чем многие из либ. Из того что на злобу дня
> - libsdl умеет делать преобразования, но - это такой трэш. Там
> алгоритм примитивный, поэтому если случился upsample - это ведет к очень
> мерзотному звучанию с характерными артефактами. Вот и получается - либу вроде
> приволокли, а звук вроде все-равно поганенький. Логично что половина програмеров предпочтет
> сплевывать вывод в пульс самолично. Сэкономив на зависимостях и получив качество
> звука лучше. Сплошной профит...
Приведите конкретный пример когда работа напрямую с pa оправдана.
Если человеку нужно например сделать звуковое оповещение при событии в программе - он просто пропишет запуск вешнего плеера и имя звукового файла. В настройках сделает строку, в которой пользователь сам сможет указать любимый плеер/опции/свой звуковой файл. В дебри о том какая там у пользователя подсистема он не полезет - это забота пользователя/маинтейнеров дистрибутива.
