Инновации в линуксе (в каком дистрибутиве что именно, будущее)

[astronom]

а на сервере ubuntu облачные вычисления Ubuntu Enterprise Cloud совместимые с Amazon EC2

Очень нужная дома штука

[t.t]

upstart

Communication with the init daemon over D-Bus

этот мир сошел с ума. Следующий шаг будет замена "все есть текст" на "все есть dbus-сообщение"? А потом придумают что-то а-ля powershell for dbus?

Не преувеличивай: не мир, а только отдельные убунтоиды.

какая разница?

(было бы в несколько раз больше если бы регулярно не прозёвывал момент полной разрядки батареи).

[offtop]В laptop-mode.conf есть опция "уснуть на диск при N% батарейки". У меня стоит, по-моему, 2; всегда хватало.[offtop]

[t.t]

абсолютно монопенесуально - комп перезагружаю раза 3-5 в год, чисто из-за нового железа и т.д.. пусть грузится хоть час, какая разница?

Ага - я тоже думал так, пока не купил ноут...

Не понял. Я, напротив, выключал машину каждый день, пока не купил ноут (не работает s2disks2ram на моём стареньком десктопе). А ноут я даже в "спячку на диске" редко отправляю -- обычно спит прямо в памяти, "включение" мгновенное (без преувеличений).

[aleksandrroot]

какой бы ни был Linux, он хорош тем, что свободный, а дистрибутив - дело вкуса. при желании к нему можно прикрутить всё, что вам угодно. Linux - он один. ИМХО.

[minoru-kun]

Следующий шаг будет замена "все есть текст" на "все есть dbus-сообщение"?

Там, где это реально удобно - почему бы и нет.

[watashiwa_daredeska]

Там, где это реально удобно - почему бы и нет.

Это реально нигде не удобно. Всилу некоторых частностей реализации.
D-Bus практически невозможно мониторить пользователю.
В общение по D-Bus невозможно встроиться, в отличие от пайпа.
D-Bus'овый интерфейс программ реально ужасен: смотрел конкретно Pidgin (когда он только-только им стал из Gaim'а) — чтобы сделать элементарные действия, которые делаются в один-два клика, вроде смены статуса, нужно написать охрененную программу.

Т.е. я, в принципе, не против шин сообщений, но D-Bus — полное г-но, уж извините.

[minoru-kun]

Там, где это реально удобно - почему бы и нет.

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

Откройте для себя dbus-monitor

В общение по D-Bus невозможно встроиться, в отличие от пайпа.

Абсолютно некритично. Если потребуется, можно вызвать метод или послать сообщение любому интерфейсу через dbus-send.

D-Bus'овый интерфейс программ реально ужасен: смотрел конкретно Pidgin (когда он только-только им стал из Gaim'а) — чтобы сделать элементарные действия, которые делаются в один-два клика, вроде смены статуса, нужно написать охрененную программу.

Нужно всего лишь послать 1 сообщение по D-Bus. То, что в птицгыне задействован не самый краткий API - это уже другая проблема. Общая, в общем-то, для большинства API под чистый C, включая GTK.

Т.е. я, в принципе, не против шин сообщений, но D-Bus — полное г-но, уж извините.

Ну, попробуйте предложить гномерам и кдешникам какой-нибудь более кошерный велосипед Только смотрите, как бы в итоге тот же D-Bus не получить

[t.t]

Там, где это реально удобно - почему бы и нет.

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

Откройте для себя dbus-monitor

В общение по D-Bus невозможно встроиться, в отличие от пайпа.

Абсолютно некритично. Если потребуется, можно вызвать метод или послать сообщение любому интерфейсу через dbus-send.

Если всё так хорошо, то расскажите, пожалуйста, где почитать о работе с dbus из shell-скриптов так же просто, как о конвейере у Кернигана с Пайком. Это не подколка, мне действительно интересно.

[NickLion]

Если всё так хорошо, то расскажите, пожалуйста, где почитать о работе с dbus из shell-скриптов так же просто, как о конвейере у Кернигана с Пайком. Это не подколка, мне действительно интересно.

Где почитать не подскажу, но вообще есть утилитки для работы из командной строки:
qdbus
dbus-send (тут и man'ы есть)
с их помощью из shell можно обратиться.

[taaroa]

взаимодействие с yakuake посредством d-bus
http://goo.gl/tpZES

[alv]

Если всё так хорошо, то расскажите, пожалуйста, где почитать о работе с dbus из shell-скриптов так же просто, как о конвейере у Кернигана с Пайком. Это не подколка, мне действительно интересно.

Где почитать не подскажу, но вообще есть утилитки для работы из командной строки:
qdbus
dbus-send (тут и man'ы есть)
с их помощью из shell можно обратиться.

Во-во, об чём и речь: старики, типа того же Кернигана, не считали для себя впадлу написать умные понятные книжки.
А нынешняя мОлодеж - напридумывали черти чего, а вы уж, ребята, по выводу --help разбирайтесь...

[watashiwa_daredeska]

Откройте для себя dbus-monitor

Как замечательно! Сколько красивых понятных пользователю названий всякого хлама! И как теперь посмотреть, что есть, как называется и как работает у того же Pidgin'а? Ах да, есть замечательная документация на сайте самого pidgin'а, которая смахивает на обычную документацию для разработчиков. А для пользователей-то где?

dbus-send (тут и man'ы есть)
с их помощью из shell можно обратиться.

Честно говоря, пробовал я эту фиготень. Убил, помнится, часок-два на раскуривание манов и доков, но так и не сумел из командной строки переключить статус Pidgin в available во всех нужных мне 5 аккаунтах из 7 заведенных в нем.

[drBatty]

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

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

этот мир сошел с ума. Следующий шаг будет замена "все есть текст" на "все есть dbus-сообщение"? А потом придумают что-то а-ля powershell for dbus?

Не преувеличивай: не мир, а только отдельные убунтоиды.

+1.

Откройте для себя dbus-monitor

Shell

$ dbus-monitor signal sender=org.freedesktop.DBus -> dest=:1.1 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.1" method call sender=:1.1 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_call'" method call sender=:1.1 -> dest=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_return'" method call sender=:1.1 -> dest=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='error'"

и что это означает?

[minoru-kun]

Откройте для себя dbus-monitor

Как замечательно! Сколько красивых понятных пользователю названий всякого хлама!

man grep

Честно говоря, пробовал я эту фиготень. Убил, помнится, часок-два на раскуривание манов и доков, но так и не сумел из командной строки переключить статус Pidgin в available во всех нужных мне 5 аккаунтах из 7 заведенных в нем.

За 5 минут чтения документации я выяснил, что выставить Available можно за два RPC-вызова:

Код:

$ dbus-send --print-reply --dest=im.pidgin.purple.PurpleService /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterface.PurpleSavedstatusNew string:"" int32:2 method return sender=:1.114 -> dest=:1.222 reply_serial=2 int32 49325 $ dbus-send --dest=im.pidgin.purple.PurpleService /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterface.PurpleSavedstatusActivate int32:49325

Насчет конкретных аккаунтов - не нашел. Но даже если это вообще никак нельзя сделать, это проблема птицгына, но никак не D-Bus.

[minoru-kun]

Сколько красивых понятных пользователю названий всякого хлама!

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

[minoru-kun]

Во-во, об чём и речь: старики, типа того же Кернигана, не считали для себя впадлу написать умные понятные книжки.
А нынешняя мОлодеж - напридумывали черти чего, а вы уж, ребята, по выводу --help разбирайтесь...

Признаю, во времена Кернигана никаких аналогов D-Bus, вроде как, не существовало. Но то, что хорошо для консольных конвеерных программ, может быть плохо для графических интегрированных DE. И UNIX-идеология заключается в простоте, а не использовании решений, соответствующих высосанным из пальца критериям кошерности.

[BIgAndy]

DBUS -очень мощное и удобное и в то же время не требовательное к ресурсам средство.
Оно позволяет объединить множество разнородных приложений под единым интерфейсом. Мощным и удобным. Просто его надо "вкурить"..

[watashiwa_daredeska]

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

В этом и проблема создателей этого говна — они делят пользователей на две крайние категории: «обычные» и «необычные». Именно пэотому эта гадость непригодна вообще ни для каких пользователей. В этом и разница с текстовым интерфейсом unix.

то, что хорошо для консольных конвеерных программ, может быть плохо для графических интегрированных DE.

Пока никто не утверждал, что для графических интерактивных программ нужно использовать существующие инструменты unix, спроектированные совсем для другого паттерна использования. Однако, dbus это не оправдывает.

И UNIX-идеология заключается в простоте

Именно этому критерию dbus не удовлетворяет в первую очередь.

DBUS -очень мощное и удобное и в то же время не требовательное к ресурсам средство.
Оно позволяет объединить множество разнородных приложений под единым интерфейсом. Мощным и удобным. Просто его надо "вкурить"..

Ну, объедините мне мощно и просто под единым интерфейсом screen saver и pidgin. Чтобы pidgin уходил в away когда включается ss и просыпался при разблокировании экрана. Ежели б вместо dbus был какой-нибудь сокет, FIFO, консольная утилита или еще что-нибудь, то скрипт пишется строчек в 5 вполне очевидным образом. А простота dbus просто выносит мне мозг.

[lastpriot]

согласен, это сложно

Код: Выделить всё

qdbus org.psi-im.Psi /Main org.psi_im.Psi.Main.setStatus await ''

[t.t]

Сколько красивых понятных пользователю названий всякого хлама!

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

О чём и речь: разработчики отделили себя от пользователей и стали за них решать, что именно пользователям нужно. К примеру, сообщением выше Вы написали какую-то непонятную мантру, которую не то что воспроизвести по памяти, а даже прочесть невозможно. В традиционном конвейере понятен каждый элемент и каждый символ. Я не зря спросил, есть ли столь же простые описания dbus-интерфейсов. Я правильно понял прозвучавшие здесь ответы? Их нет?

[t.t]

согласен, это сложно

Код: Выделить всё

qdbus org.psi-im.Psi /Main org.psi_im.Psi.Main.setStatus await ''

А где здесь скринсейвер?

Ладно, допустим, в качестве скринсейвера можно задать скрипт, в котором вызывать эту команду. Тогда другой вопрос: что означают все эти странные слова и где о них можно прочитать?

[watashiwa_daredeska]

А где здесь скринсейвер?

Ну, к этому скринсейвер прикрутить уже легко.

Однако, это совсем частный случай более-менее хорошего интерфейса или по крайней мере его части. При этом:
1. Документация по интерфейсу отсутствует начисто даже у PSI, если не считать таковой dbus.h и dbus.cpp в исходниках PSI.
2. Такой хороший интерфейс предоставляют далеко не все. Некоторые методы Pidgin'а, например, вообще не получается вызывать qdbus'ом, а еще некоторые — даже dbus-send'ом. Интерфейс NetworkManager, например — тоже та еще хрень.

Просто потому, что D-Bus — это конструкция уровня разработчиков, а не пользователей. С соответствующим инструментарием и соответствующей документацией (отлично документировано на языке C).

[lastpriot]

просмотр доступных путей

Код: Выделить всё

qdbus org.psi-im.Psi

просмотр доступных методов

Код: Выделить всё

qdbus org.psi-im.Psi /Main

perl-скрипт для просмотра доступных сервисов bratislava.pm.org/presentation/dbus/dbus-list-services.pl
и есть даже GUI D-Feet

p.s. согласен с watashiwa_daredeska, d-bus все таки девелоперский инструмент, и далеко не userfriendly

[NickLion]

Естественно, dbus не сможет быть столь же простым как pipe. Ибо конвеер это просто передача выхода одной программы на вход другой. И, скажем, если выход одной программы - XML, а вход другой - JSON, то это тоже становится уделом разработчиков. Просто большинство консольный программ имеют человекочитаемый plain-text вход-выход и значительно колбасить это не приходится, но опять же нет-нет, да и вставляется sed/perl/awk с зубодробилкой для преобразования.
Но нельзя сравнивать pipe и dbus, это не эквиваленты. pipe работает один раз, dbus - когда угодно в течение работы программы. Поэтому естественно рождается система RPC. Практически любая универсальная шина сообщений приходит к такой модели. Естественно как и что вызывать целиком зависит от разработчика, поэтому в одних программах интерфейс более удобен, в других менее.

PS для просмотра интерфейса есть ещё GUI'шный qdbusviewer

[sash-kan]

my humble opinion

rpc вообще штука уродливая по определению·
и d-bus, как один из вариантов реализации rpc, отлично это подтверждает·
на фоне d-bus-а реализация rpc в plan9 выглядит просто идеалом простоты и прозрачности·
и придумана она была задолго до d-bus-а, и его вдохновителя dcop-а, да и самого kde вообще·

почему люди частенько клепают собственные уродливые велосипеды, не обращая внимания на уже существующие более стройные модели — вопрос, конечно, риторический…

[taaroa]

на фоне d-bus-а реализация rpc в plan9 выглядит просто идеалом простоты и прозрачности·
и придумана она была задолго до d-bus-а, и его вдохновителя dcop-а, да и самого kde вообще·

…и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?
и придуман был план пу plan9, да только оказался он не нужен почти никому.

почему люди частенько клепают собственные уродливые велосипеды, не обращая внимания на уже существующие более стройные модели — вопрос, конечно, риторический…

[sash-kan]

и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?

это тоже была ирония?
если нет, то в каком месте «намекает»?

[watashiwa_daredeska]

и придуман был план пу plan9, да только оказался он не нужен почти никому.

It was developed primarily for research purposes as the successor to Unix

Сам по себе Plan9, конечно, мало распространен, но идеи потихоньку расползаются по другим системам. Тот же /proc.

…и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?

Она намекает, что в классических *nix'ах отошли от классического unixway. Plan9 — попытка реализовать средствами классического unixway то, что в классических *nix'ах реализовано через задницу.

[taaroa]

[NIXP] В Fedora рассматривают предложение перенести все исполняемые файлы в /usr/bin
[ON] Релиз звукового сервера PulseAudio 1.0
[ON] Линус Торвальдс перешёл с Gnome 3 на XFCE и призвал продолжить развитие Gnome 2
[LOR] BSD сдерживает развитие СПО
[ON] Обсуждение развития GNOME как основанной на Linux операционной системы
Почему systemd?
[ON] В Fedora и других GNU+Linux-дистрибутивах появится директория /run
[ON] Представлен первый стабильный релиз системы инициализации Upstart 1.0
systemd — новая init-система для Linux
инновации. subj^

[NickLion]

rpc вообще штука уродливая по определению·

но для межпроцессного взаимодействия в произволный момент времени (а не при запуске, как в случае pipe) ничего лучше я что-то не замечал. либо простая специализированная шина сообщений с ограничением по типам сообщений, либо rpc - в этом случае стилистика будет зависеть от приложения и может быть достаточно уродской... но сам rpc от этого почему становится уродским? в общем-то вызов представляет собой четверку: сервер, зарегистрированный клиент, имя вызова, параметры. всё просто и понятно.

на фоне d-bus-а реализация rpc в plan9 выглядит просто идеалом простоты и прозрачности·
и придумана она была задолго до d-bus-а, и его вдохновителя dcop-а, да и самого kde вообще·

ок, для тех кто в танке, можете кинуть ссылку на почитать как оно организовано? из вики нашёл упоминание 9p, но по описанию не понял как оно способно заменить rpc.