История изменений
Исправление intelfx, (текущая версия) :
Ты не пробовал отвечать на правильный комментарий? Или боишься, что я быстро опровергну все твои псевдодоводы?
Я провел эксперимент, и попробовал запустить весь софт, которым я пользуюсь (и много такого, которым нет), с отключеным Dbus.
Ключевое слово здесь — «я».
Внимание, вопрос: нахрена эта системная служба, и что она дает?
Она даёт универсальный механизм межпроцессного взаимодействия. Если так получилось, что он не используется ни одной программой из твоего рабочего набора — возьми и отключи, в чём проблемы? Не следует устраивать из этого факта прайд-парад.
Меня огорчает тындынция прикручивать к изначально GNOME-службе - чисто консольные программы.
4.2. D-Bus изначально создавался как универсальная кросс-DE шина.
И позволь спросить, чем эта тенденция тебя огорчает? Разъясняю на пальцах: функциональность программ не берётся из ниоткуда. Если программе необходимо связаться с какой-либо другой во время работы — это можно сделать ровно двумя способами: либо реализовать свой собственный протокол на каких-либо примитивах, либо взять готовый высокоуровневый инструмент и написать минимальное количество нового кода. Угадай, что выберет любой вменяемый разработчик, не ограниченный какими-то особыми условиями?
Сравнение с DCOP - некорректное. Он стартовал вместе с KDE и завершался с KDE, а не /etc/init.d/dbus start.
Наоборот, более чем корректное. DCOP не использовался ничем вне KDE. D-Bus используется значительным количеством программ вне KDE, GNOME и других сред рабочего стола. На моём компьютере их 14, даже без учёта systemd:
$ busctl --system list --unique | grep -v intelfx | grep -vE '(systemd|gnome|gdm)'
NAME PID PROCESS USER CONNECTION UNIT SESSION DESCRIPTION
:1.11 2009 accounts-daemon root :1.11 accounts-daemon.service - -
:1.12 2075 bluetoothd root :1.12 bluetooth.service - -
:1.15 2122 rtkit-daemon root :1.15 rtkit-daemon.service - -
:1.2 1896 avahi-daemon avahi :1.2 avahi-daemon.service - -
:1.3 1900 ModemManager root :1.3 ModemManager.service - -
:1.4 1898 upowerd root :1.4 upower.service - -
:1.52 2454 colord colord :1.52 colord.service - -
:1.54 2493 wpa_supplicant root :1.54 wpa_supplicant.service - -
:1.6 1913 polkitd polkitd :1.6 polkit.service - -
:1.69 2676 geoclue root :1.69 geoclue.service - -
:1.7 1905 NetworkManager root :1.7 NetworkManager.service - -
:1.70 2676 geoclue root :1.70 geoclue.service - -
:1.73 2698 udisksd root :1.73 udisks2.service - -
:1.80 2833 cupsd root :1.80 org.cups.cupsd.service - -
Если в твоей конфигурации никакие общесистемные программы не пользуются D-Bus, ты можешь просто не включать общесистемную шину. Но опять же повторяю, что мир одним тобой не ограничивается.
И хрен знает разработку чего он там облегчает, если ни одна прога на самом деле его не использует.
Ты лжёшь.
Исправление intelfx, :
Ты не пробовал отвечать на правильный комментарий? Или боишься, что я быстро опровергну все твои псевдодоводы?
Я провел эксперимент, и попробовал запустить весь софт, которым я пользуюсь (и много такого, которым нет), с отключеным Dbus.
Ключевое слово здесь — «я».
Внимание, вопрос: нахрена эта системная служба, и что она дает?
Она даёт универсальный механизм межпроцессного взаимодействия. Если так получилось, что он не используется ни одной программой из твоего рабочего набора — возьми и отключи, в чём проблемы? Не следует устраивать из этого факта прайд-парад.
Меня огорчает тындынция прикручивать к изначально GNOME-службе - чисто консольные программы.
4.2. D-Bus изначально создавался как универсальная кросс-DE шина.
И позволь спросить, чем эта тенденция тебя огорчает? Разъясняю на пальцах: функциональность программ не берётся из ниоткуда. Если программе необходимо связаться с какой-либо другой во время работы — это можно сделать ровно двумя способами: либо реализовать свой собственный протокол на каких-либо примитивах, либо взять готовый высокоуровневый инструмент и написать минимальное количество нового кода. Угадай, что выберет любой вменяемый разработчик, не ограниченный какими-то особыми условиями?
Сравнение с DCOP - некорректное. Он стартовал вместе с KDE и завершался с KDE, а не /etc/init.d/dbus start.
Наоборот, более чем корректное. DCOP не использовался ничем вне KDE. D-Bus используется значительным количеством программ вне KDE, GNOME и других сред рабочего стола.
Если в твоей конфигурации никакие общесистемные программы не пользуются D-Bus, ты можешь просто не включать общесистемную шину. Но опять же повторяю, что мир одним тобой не ограничивается.
И хрен знает разработку чего он там облегчает, если ни одна прога на самом деле его не использует.
Ты лжёшь.
Исправление intelfx, :
Ты не пробовал отвечать на правильный комментарий? Или боишься, что я быстро опровергну все твои псевдодоводы?
Я провел эксперимент, и попробовал запустить весь софт, которым я пользуюсь (и много такого, которым нет), с отключеным Dbus.
Ключевое слово здесь — «я».
Внимание, вопрос: нахрена эта системная служба, и что она дает?
Она даёт универсальный механизм межпроцессного взаимодействия. Если так получилось, что он не используется ни одной программой из твоего рабочего набора — возьми и отключи, в чём проблемы? Не следует устраивать из этого факта прайд-парад.
Меня огорчает тындынция прикручивать к изначально GNOME-службе - чисто консольные программы.
4.2. D-Bus изначально создавался как универсальная кросс-DE шина.
И позволь спросить, чем эта тенденция тебя огорчает? Разъясняю на пальцах: функциональность программ не берётся из ниоткуда. Если программе необходимо связаться с какой-либо другой во время работы — это можно сделать ровно двумя способами: либо реализовать свой собственный протокол на каких-либо примитивах, либо взять готовый высокоуровневый инструмент и написать минимальное количество нового кода. Угадай, что выберет любой вменяемый разработчик, не ограниченный какими-то особыми условиями?
Сравнение с DCOP - некорректное. Он стартовал вместе с KDE и завершался с KDE, а не /etc/init.d/dbus start.
Наоборот, более чем корректное. DCOP не использовался ничем вне KDE. D-Bus используется значительным количеством программ вне KDE, GNOME и других сред рабочего стола.
Если в твоей конфигурации никакие общесистемные программы не пользуются D-Bus, ты можешь просто его не включать. Но опять же повторяю, что мир одним тобой не ограничивается.
И хрен знает разработку чего он там облегчает, если ни одна прога на самом деле его не использует.
Ты лжёшь.
Исходная версия intelfx, :
Ты не пробовал отвечать на правильный комментарий? Или боишься, что я быстро опровергну все твои псевдодоводы?
Я провел эксперимент, и попробовал запустить весь софт, которым я пользуюсь (и много такого, которым нет), с отключеным Dbus.
Ключевое слово здесь — «я».
Внимание, вопрос: нахрена эта системная служба, и что она дает?
Она даёт универсальный механизм межпроцессного взаимодействия. Если так получилось, что он не используется ни одной программой из твоего рабочего набора — возьми и отключи, в чём проблемы? Не следует устраивать из этого факта прайд-парад.
Меня огорчает тындынция прикручивать к изначально GNOME-службе - чисто консольные программы.
4.2. D-Bus изначально создавался как универсальная кросс-DE шина.
И позволь спросить, чем эта тенденция тебя огорчает? Разъясняю на пальцах: функциональность программ не берётся из ниоткуда. Если программе необходимо связаться с какой-либо другой во время работы — это можно сделать ровно двумя способами: либо реализовать свой собственный протокол на каких-либо примитивах, либо взять готовый высокоуровневый инструмент и написать минимальное количество нового кода. Угадай, что выберет любой вменяемый разработчик, не ограниченный какими-то особыми условиями?
Сравнение с DCOP - некорректное. Он стартовал вместе с KDE и завершался с KDE, а не /etc/init.d/dbus start.
Наоборот, более чем корректное. DCOP не использовался ничем вне KDE. D-Bus используется значительным количеством программ вне KDE, GNOME и других сред рабочего стола.
Опять же повторяю, что если в твоей конфигурации никакие общесистемные программы не пользуются D-Bus, ты можешь просто его не включать, но мир одним тобой не ограничивается.
И хрен знает разработку чего он там облегчает, если ни одна прога на самом деле его не использует.
Ты лжёшь.