The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядро Linux планируется включить функциональность D-Bus, opennews (?), 09-Фев-13, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


9. "В ядро Linux планируется включить функциональность D-Bus"  +5 +/
Сообщение от ВовкаОсиист (ok), 09-Фев-13, 14:43 
В каком месте оно вдруг станет микроядром?
Ответить | Правка | Наверх | Cообщить модератору

17. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 09-Фев-13, 15:00 
> В каком месте оно вдруг станет микроядром?

Это шутка была. Оно станет макроядром с пересылкой сообщений.

Ответить | Правка | Наверх | Cообщить модератору

89. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 09-Фев-13, 21:54 
Если даст нормальную скорость - то это надежда сделать существенно более модульную систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.
Ответить | Правка | Наверх | Cообщить модератору

95. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 09-Фев-13, 22:31 
> Если даст нормальную скорость - то это надежда сделать существенно более модульную
> систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый
> что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.

В ядро-то на кой?

Ответить | Правка | Наверх | Cообщить модератору

99. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 09-Фев-13, 22:39 
Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не как на "полтора сообщения в секунду прокинуть", а как на легковесную корбу какую.

Но на самом деле я радуюсь потому что оно в некоторыемои идеи о десктопе очень хорошо укладывается :-)

Ответить | Правка | Наверх | Cообщить модератору

103. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Vkni (ok), 09-Фев-13, 23:19 
> Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не
> как на "полтора сообщения в секунду прокинуть", а как на легковесную
> корбу какую.

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

Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что не нужно отправлять сообщения о вставленной флешке раз в 10 микросекунд. Её трафик оценивается, как трафик файла /var/log/messages - то, что можно прочесть.

> Но на самом деле я радуюсь потому что оно в некоторыемои идеи
> о десктопе очень хорошо укладывается :-)

Сама концепция UNIX безнадёжно устарела. Система UNIX построена на портабельном ассемблере - языке C. Сейчас прошли две "революции" - появление в mainstream объектно-ориентированных языков и функциональных. Вы хотите объектную шину, поддерживающую серьёзный трафик, в том числе и broadcast, при этом берёте "старую" ОС. И, естественно, эта шина выглядит как на корове седло.

Нужно менять ОС - тот же Ведроид уже объектен, там такие типизированные шины будут в дугу. А по-настоящему общеупотребительной функциональной ОС ещё нет, будем ждать.

Ответить | Правка | Наверх | Cообщить модератору

108. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от sammemail (ok), 09-Фев-13, 23:48 
>> Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не
>> как на "полтора сообщения в секунду прокинуть", а как на легковесную
>> корбу какую.
> Видите ли, то, что пишет Витус, очень хорошо укладывается в идеологию UNIX
> - текстовые сообщения, склейка скриптами, усё есть файл. При этом эта
> системная шина уже не является чем-то, что должно поддерживать высокий трафик.
> Если хочется что-то серьёзное передать, делается pipe между программами, и вперёд.

"Идеология юникс" - она, суко, разная. И тот же SSH, или даже ESC последовательнсоти в телнете - отнюдь не текстовые. Как и тысячи других "традиционных" юникс решений и протоколов.

> Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что
> не нужно отправлять сообщения о вставленной флешке раз в 10 микросекунд.
> Её трафик оценивается, как трафик файла /var/log/messages - то, что можно
> прочесть.

Через тот же uevent в мобильных устройствах часто проходит немаленький поток. Разбирать текст просто потому, что кто-то ниасилил дисекторы в 21 веке - немного странно.И тем более странно предлагать шаг назад (да еще и овер х11, п..ц!) в 21 веке. Повторюсь - в этой затее хорошо только отсутствие реализации, так что никто кроме читателей уютненького это не оценит, гг.

Ответить | Правка | Наверх | Cообщить модератору

116. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 00:06 
> - текстовые сообщения, склейка скриптами, усё есть файл.

То-то в юниксах даже логи помнится были бинарными. "Все есть файл" != "все есть текстовый файл". Более того - передавать большой массив данных текстом как бы редкостное порно. А иногда оно может быть надо. HTTP вон уже сделали, теперь не знают как разделать в нормальный вид, извращаются вон с всякими data: (куча base64 кодированного фуфела). Руки обрывать за такие инициативы. Желательно вместе с головой.

В конце концов. вот есть gzip. Вам сильно мешает жить что он бинарный? Ах, есть прозрачная утилита которая спокойно расжимает его? Так что даже скрипты могут гзипнутые логи жрать? Ну вот и получается что бинарные данные ничем таким не плохи. При правильном подходе к делу, разумеется. А вот во сколько раз сдувается гзипнутый лог - думаю понятно. Давайте расскажем о том что все кто сжимает логи, превращая их в бинарный мусор - делают это неправильно? :)

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

131. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Vkni (ok), 10-Фев-13, 01:39 
> То-то в юниксах даже логи помнится были бинарными. "Все есть файл" !=
> "все есть текстовый файл". Более того - передавать большой массив данных
> текстом как бы редкостное порно.

Проблема логов в том, что их периодически нужно читать. И если в логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных, читать придётся терабайты.

Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет думать, что писать в логи, а что - нет.

Ответить | Правка | Наверх | Cообщить модератору

143. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 02:14 
> Проблема логов в том, что их периодически нужно читать.

Wrong. На самом деле их надо не "читать" а "анализировать". Это еще IBM сформулировал: "Машина должна работать, а человек - думать". Вы же предлагаете свалить машинную работу на человека. Ужас!

Если стоит сервак который держит приличную нагрузку, немеряные портянки логов на нем - просто данность. Ну, если запросов много - значит и логов от них много. Более того - это внешний фактор, админу он не подконтролен. Значит даже absolute worst case, когда кто-то целенаправленно пытается зафлудить логи не должен вызывать никаких проблем. Иначе сервак уронит первый же мальчиш-плохиш, которому что-то не нравится. Нафига такое счастье?

> И если в логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных,
> читать придётся терабайты.

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

А зачем мне читать вообще ВСЕ запросы? Логи изучают по поводу тех или иных проблем или происшествий. Ну так вот и должна быть возможность оперативно выцепить куски представляющие интерес.

Вся эта текстовая дребедень в этом плане очень проблематична. Чтобы просто выцепить "все запросы за вчера, от 00:51:05 до 00:52:18" надо как минимум сделать полный проход по немеряной портянке текстового лога и проскипать все не относящееся к нужным критериям. Портянка будет немелким кусом за период ротации логов. И если с датой еще можно попытаться хоть как-то соптимизировать, допустив что лог линейный и монотонный, то например с хотелкой вида "а вот дать мне все обращения с этого айпишника за последний месяц" так уже не катит. Там будет кондовый полный проход по вообще всем логам за этот самый месяц. Который займет немеряно времени в случае нагруженного сервака. И админ будет как дебил ждать выполнение машинной работы машиной.

> Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет
> думать, что писать в логи, а что - нет.

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

Ответить | Правка | Наверх | Cообщить модератору

150. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 02:39 
> Если стоит сервак который держит приличную нагрузку, немеряные портянки логов на нем
> - просто данность.

А если десктоп, то его логи придётся именно читать. Зато крайне редко. :-)

Ответить | Правка | Наверх | Cообщить модератору

160. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 03:20 
> А если десктоп, то его логи придётся именно читать. Зато крайне редко. :-)

Ну да, у вас как-то так удобно придумано что вот лично ваш частный случай оно будет окучивать, лично вам будет удобно, а там хоть трава не расти. Вот по какому-то такому поводу оно и будет (если вообще будет) только у вас в системе. И да, не хочу вас расстраивать но вот прожка есть. На десктопе. А 20 Мб логов за 2 часа она таки генерит. Как вы думаете, если ее оставить работать недельку - приятно ли мне будет потом искать что-то в этих логах? Да, разумеется на десктопе в отличие от сервера нет ротатора логов, особенно знающего что-то там о каких-то прожках.

Ответить | Правка | Наверх | Cообщить модератору

172. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Vkni (ok), 10-Фев-13, 11:26 
> И да, не хочу вас расстраивать но вот прожка есть. На десктопе. А
> 20 Мб логов за 2 часа она таки генерит.

Это значит, что она, скорее всего, неправильно устроена.

Ответить | Правка | Наверх | Cообщить модератору

176. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 11:44 
> Это значит, что она, скорее всего, неправильно устроена.

Этот мир вообще "неправильно" устроен, от и до. Вон на википедию прутся сотни миллионов леммингов. Неизбежно генеря адскую прорву логов. Вместо того чтобы приходить по сто штук в день, выстроившись в многомесячную очередь за счастьем. И вот так - в любом нагруженном сервисе. Случай когда просто лог создает даже просто неприемлимо много нагрузки на диск - вполне обычная ситуация в нашем реальном мире. Прикиньте, активность от логинга может быть сравнима или превышать полезную активность. А вы предлагаете в этот вентилятор еще лом воткнуть дополнительно...

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

183. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Vkni (ok), 10-Фев-13, 12:51 
>> Это значит, что она, скорее всего, неправильно устроена.
> Этот мир вообще "неправильно" устроен, от и до.

Так вот "текстовые логи" тем и хороши, что "дурь каждого становится видна". В таком случае есть шансы, что человек сразу заметит, что что-то идёт не совсем так, если программа слишком много протоколирует.

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

Почему он неприемлимо много даёт нагрузки? Нет ли тут слишком сильной непродуманности системы протоколирования, которая записывает незначимые события? Помните "You mouse position has changed. Press OK to reboot."

Всё-таки, программа должна выполнять, в основном, свою главную цель. А протоколирование выполнения в неё никак не входит. Может быть просто она откомпилирована не в release вариант, а в debug?

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

270. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 11-Фев-13, 11:24 
> Так вот "текстовые логи" тем и хороши, что "дурь каждого становится видна".

Я все-таки не понял: вы таки против гзипования логов? Файл то получается бинарный - в текстовом виде данные для LZ+Huffman не очень удобно передавать. Но я так понимаю что хранение лога в сжатом бинарном файле при всем этом претензий не вызывает? Т.е. по большому счету - это лишь вопрос доступности утилит для прозрачной работы с форматом. В том числе - возможности пайпинга в другие программы.

> В таком случае есть шансы, что человек сразу заметит, что что-то
> идёт не совсем так, если программа слишком много протоколирует.

Странный человек который сам лично окарауливает логи. Там где это кого-нибудь волнует - давно вкалывают автоматические системы мониторинга. Что вообще за мания - спихивать на человека рутинную работу? А машины для чего?

> Почему он неприемлимо много даёт нагрузки? Нет ли тут слишком сильной непродуманности
> системы протоколирования, которая записывает незначимые события? Помните
> "You mouse position has changed. Press OK to reboot."

Ну да, все можно довести до маразма. В таких случаях уместнее трассировщик, профайлер и деьагер. Но опять же - возможны варианты. Вот глючит сетевая утиля раз в неделю. Не будете же вы ее с дебагером караулить столько? А если просто бряк поставить - ну, она завалится туда. А вы допустим спали. Ну и отвалится ремота по таймауту, и вообще. И когда вы это увидите - картина будет уже не та которая привела к глюкам. В этом случае таки вариант заюзать вербозный логгинг, вплоть до packet-level tracing. Диски нынче большие.

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

Так что лично я ничего не имею против бинарных логов, если это дает плюсы. При одном условии. Должны быть описание формата + утилиты и библиотеки для работы с оным. Ну, как с gzip/deflate. Разумеется с исходниками. Тогда оно никаких проблем не вызывает.

> Всё-таки, программа должна выполнять, в основном, свою главную цель. А протоколирование
> выполнения в неё никак не входит. Может быть просто она откомпилирована не в release вариант, а в debug?

В совсем культурных программах это даже настраивается в рантайм. И намного хуже если надо понять что отвалилось а вербозности логов не хватило. Придется как минимум возиться с пересборкой, а если совсем не повезло - самому дописывать недостающие логи. Ну и гадостное же это занятие, скажу я вам. Приходилось несколько раз так делать - гемор конкретный. По уму это автор программы должен делать. Ему это в 20 раз проще - он уже кишки своей программы знает. А мне приходится "с места в карьер" вкуривать что и как.

Тем не менее, повторяю, например элементарный HTTP сервер, отдающий статику в нагруженном проекте - генерит прорву логов в совершенно штатном режиме. Это его нормальное состояние. И это вполне типовой юзкейс пингвинов, кроме всего прочего.

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

191. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 10-Фев-13, 13:09 
> Проблема логов в том, что их периодически нужно читать. И если в
> логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных,
> читать придётся терабайты.

Читать вам при прочих равных придется одно и то же, что текст -> gzip -> zgrep, что бинарник -> анализатор с нужным фильтром. Вот машина при этом выполнит разную работу, это да.

> Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет думать,
> что писать в логи, а что - нет.

Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не хочет, не делает это и с текстом.

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

226. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 15:10 
> Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не
> хочет, не делает это и с текстом.

Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять высоты. :-)

Ответить | Правка | Наверх | Cообщить модератору

283. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 11-Фев-13, 13:50 
>> Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не
>> хочет, не делает это и с текстом.
> Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять
> высоты. :-)

Увольте, free software for free people! :-)
Вообще пусть покоряет, только чтобы эти стимулы не приводили к безрезультатным NIH, 15му стандарту и 5му форку. Хотя тут "а судьи кто", поэтому оставим.

Ответить | Правка | Наверх | Cообщить модератору

347. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 16-Фев-13, 15:15 
> Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять высоты. :-)

Вот только анализ большого объема логов в таком формате будет неизбежно связан с костылестроением.

Ответить | Правка | К родителю #226 | Наверх | Cообщить модератору

122. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 10-Фев-13, 00:44 
Ну так и у меня в глове объектность. А юникс - я ж специално указал - я не о "всё есть файл и текстовые сообщения", а о компонентности, когда задача решается комбинацией специфических инструментов. В этом плане можно "объектный" юзерспейс делать уже сейчас, поверх существующего posix. А такие штуки, как эта шина, просто добавляют выстродействие (и, возможно, чуть упрощают обеспечение безопасности - это на реализацию надо смотреть).

Ну а в функциональщину как основу архитектуры я не особо верю, честно говоря. Вот для решения локальных задач она иногда оказывается к месту, это да. И уж точно ей не место там, где, по-хорошему,пользователь должен быть способен без особых умственных усилий сляпать простой скрипт, автоматизирующий какую-то рутину. Просто потому что если ещё можно пользователей в массе научить ООП на уровне Visual Basic 1.0 (а больше и не надо,собственно), то "функциональщина в массы" - это, IMHO, утопия полнейшая.

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

133. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 01:46 
Юниксвейность в плане грамотной декомпозиции - это просто грамотная архитектура. Ни какого особенного отношения к UNIX она не имеет. Также грамотно можно спроектировать и любую другую ОС.

> В этом плане можно "объектный" юзерспейс делать уже сейчас, поверх
> существующего posix.

Можно. Это называется JVM - Java Virtual Machine. Она знает об объектах, поэтому объектную шину поддерживает родным образом.

> Ну а в функциональщину как основу архитектуры я не особо верю, честно
> говоря.

Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.

> Вот для решения локальных задач она иногда оказывается к месту,
> это да.

Ну это же набор приёмов, по факту. Как и структурное программирование, и ОО.

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

Как раз bash заменить на какого-нибудь потомка OCaml, чтобы можно было в параметры программ передавать другие программы вроде find -x, было бы неплохо. Ну и любимая вами типизация, причём автоматическая.

> то "функциональщина в массы" - это, IMHO, утопия полнейшая.

Ну как это? Есть find -x, есть множество мест, где аналогичный механизм оказался бы в дугу. Автовыводу типов вообще учить не надо. А больше там ничего, подходящего для скриптов, и нет.

Ответить | Правка | Наверх | Cообщить модератору

144. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 02:20 
> Можно. Это называется JVM - Java Virtual Machine. Она знает об объектах,
> поэтому объектную шину поддерживает родным образом.

Вот только в целом из явы получился еще тот монструозный и тормозной переросток, который никому кроме энтерпрайзов с очень мощными серверами даром не упал. Ну, он занял свою нишу и пусть в ней и сидит. Насколько было востребовано - настолько и заюзалось.

> Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.

Остается только найти желающих все это использовать...

Ответить | Правка | Наверх | Cообщить модератору

145. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Vkni (ok), 10-Фев-13, 02:23 
> Вот только в целом из явы получился еще тот монструозный и тормозной
> переросток

А из Ведроида - нет, получились новые Винды. Т.е. mainstream OS.

>> Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.
> Остается только найти желающих все это использовать...

Это же исследовательская ОС.

Ответить | Правка | Наверх | Cообщить модератору

194. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 10-Фев-13, 13:13 
>> Вот только в целом из явы получился еще тот монструозный и тормозной
>> переросток
> А из Ведроида - нет, получились новые Винды. Т.е. mainstream OS.

Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.

Ответить | Правка | Наверх | Cообщить модератору

205. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 13:54 
> Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.

Нет, не синоним качества. Это было к "никому не нужный".

Ответить | Правка | Наверх | Cообщить модератору

217. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 10-Фев-13, 14:40 
>> Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.
> Нет, не синоним качества. Это было к "никому не нужный".

/me не согласен с тем анонимом по поводу серверов, но все же есть предложение не смешивать успех по маркетинговым и техническим причинам. И не рассматривать тут первые вообще.

Ответить | Правка | К родителю #205 | Наверх | Cообщить модератору

225. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 15:09 
> есть предложение не смешивать успех по маркетинговым и техническим причинам.

Объектность системы - это техническая причина. То, что нет необходимости в сериализации при сохранении данных - это очень удобно.

Ответить | Правка | К родителю #217 | Наверх | Cообщить модератору

273. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 11-Фев-13, 12:05 
> То, что нет необходимости в сериализации при сохранении данных - это очень удобно.

Ну так вот в общем случае данные не ограничиваются текстом. Потуги представить вообще все как текст приведут к тому что в ряде ситуаций потребуется костылить черти-что.

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

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

285. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 11-Фев-13, 14:00 
> Объектность системы - это техническая причина. То, что нет необходимости в сериализации
> при сохранении данных - это очень удобно.

Но не причина успеха системы, я к этому. Хочется вам с одними объектами работать — делайте так, хотите текст и пайпы — этак. Но только поэтому нельзя сказать, что один из вариантов в сумме для всей ОС явно лучше другого.
А удобно может и удобно, но не сериализовывать никто и в C / UNIX-way не запрещает, пардон за формулировку. Может не так удобно, как в java (не могу сравнить), но имхо не страшно.

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

348. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 16-Фев-13, 15:21 
> Объектность системы - это техническая причина. То, что нет необходимости в сериализации

Размечтался то, академик. Вот хочешь ты данные переслать на ремотную машину. С хрен знает какой системой. И чтоб они могли с этим работать. И чего? Ах, добро пожаловать в сериализацию-десериализацию. Надо же, какая незадача: устройства хранения - по сути тупые массивы секторов. А сетевые интерфейсы - перекидывают пакеты. И про объекты оно вообще ни разу не слышало. И какая разнца, сервис в ОС сделает эти трансформации с ножом к горлу или это сделает некая сторонняя либа?

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

247. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 10-Фев-13, 23:57 
Ну да, некомпозиция. Но как-то в винде я её особо не видел, макось не глядел почти, но вроде тоже не заметно, а больше сейчас реально живого ничего и нет.

И, простите, при чём здесь ява, если нам нужны,в общем-то, всего лишь сложные типы данных?

А идею пайпов мне, насколько я помню, объяснили в своё время за минуты, с MS-DOS, на первых уроках работы с компьютером. Вот если у вас получится так же функциональный вариант объяснять - то шанс есть. Но я сильно сомневаюсь, честно говоря. А "существующая система" - это, всё же, не о plan9 - а хотя бы о FreeBSD.  В смысле - оно хоть кому-то должнобыть нужно и иметь хоть некоторую популярность.

Кстати, судя по всему, не HOME, а House - но это ж не ос, это игрушка-дипломник чей-то. А не верю по очень простой причине - ФП вообще никак не ложится на фон-неймановскую архитектуру. Система, у которой концепции радикально отличаются от железа, на котором она живёт - не верю, что она может быть эффективно реализована.

Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

248. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Michael Shigorinemail (ok), 11-Фев-13, 00:04 
> А идею пайпов мне, насколько я помню, объяснили в своё время за
> минуты, с MS-DOS, на первых уроках работы с компьютером. Вот если
> у вас получится так же функциональный вариант объяснять

Хохма в том, что пайпы и являются функциональным подходом в шелл-программировании. :)

a | b | c

c(b(a))

Ответить | Правка | Наверх | Cообщить модератору

274. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 11-Фев-13, 12:07 
> Хохма в том, что пайпы и являются функциональным подходом в шелл-программировании. :)

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

Ответить | Правка | Наверх | Cообщить модератору

292. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 11-Фев-13, 16:34 
Основное - придётся править основной набор (авк/греп/head/tail и т.п.)
Ответить | Правка | Наверх | Cообщить модератору

293. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 11-Фев-13, 16:37 
Если вы мне покажете, где здесь передаются функции как отдельные от аргументов сущности - то соглашусь. А пока я вижу куски функционального подхода (кстати, там можно и получше сделать) в find, xargs и подобном, но никак не в обычном пайпе. И главное - не соблюдаются (и не будут) основные заморочки функциональщины, вроде "чистоты" функций и отсутствия сайд-эффектов. Так что скорее я бы даже версию find императивными коллбеками обозвал.
Ответить | Правка | К родителю #248 | Наверх | Cообщить модератору

296. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 11-Фев-13, 16:50 
> Если вы мне покажете, где здесь передаются функции как отдельные от аргументов
> сущности - то соглашусь.

Запись cat z.h | B | C | D можно легко трактовать, как передачу функции в качестве аргумента stdout.

> Так что скорее я бы даже версию find императивными коллбеками
> обозвал.

Вот это, как раз, сложнее для использования, чем соглашение, что передаём функции.

Ответить | Правка | Наверх | Cообщить модератору

303. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 11-Фев-13, 20:14 
Хм, ну да, можно и так. Хотя как только у "функций" появятся аргументы (параметры командной строки) сразу можно будет придраться, что нет униформности функции и её параметра, как в ФП положено - но это всё же скорее придирки. И, опять же, никаких претензий, пока не требуют "чистоты", иммутабельности и отсутствия сайд-эффектов. А как запись трактовать - дело десятое, тем более что там можно и while и for in написать.
Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

254. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 11-Фев-13, 00:37 
> А не верю по очень простой
> причине - ФП вообще никак не ложится на фон-неймановскую архитектуру. Система,
> у которой концепции радикально отличаются от железа, на котором она живёт
> - не верю, что она может быть эффективно реализована.

Ну много чего "радикально отличается от железа". Например, ООП. Или шаблонное программирование.

А так, как Михаил написал - в sh есть место функционалке - например кавычки ``:

for i in `ls -la`; do echo $i | grep u; done

Пожалуйста, ls -la используется как функциональный объект. Или другой вариант - с find:

$ find . -name *.gif -exec ls {} \;

То есть, необходимую функционалку вам уже объяснили. В OCaml бы это просто по-другому было бы записано:

find . ~name:*.gif ~exec ls;;

Или, если хочется сделать вывод с правами доступа

find . ~name:*.gif ~exec (fun x -> ls x -la);;

Ответить | Правка | К родителю #247 | Наверх | Cообщить модератору

295. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 11-Фев-13, 16:43 
ООП совершенно спокойно ложится на железо - в тех же плюсах это предельно наглядно. Таблицы функций и переменные - чему ж тту не ложиться? Шаблоны - тем более, это ж обычные макросы, разворачивающиеся в пачку того же кода, что под ними, каким бы он нибыл - хоть структурным, хоть ООП, хоть ФП прикрути.

И нет, бэктики - это не из той оперы, по крайней мере при таком вызове. Кавычки здесь - это примерный эквивалент foreach(ls()){...} - что здесь функционального? И, опять же, ограничения ФП не соблюдаются. Собственно, если их не соблюдать и допутстить императивный стиль и функциональный однвоременно - то это как раз то,  чем я твержу - берутся удобные куски, а на идеологию плевать.

Ответить | Правка | Наверх | Cообщить модератору

297. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 11-Фев-13, 16:55 
> ООП совершенно спокойно ложится на железо - в тех же плюсах это
> предельно наглядно. Таблицы функций и переменные - чему ж тту не
> ложиться?

Нет спец. аппаратной поддержки. Вернее, она есть (out-of-order очень помогает на С++ коде), но не везде и не так явна, как call и ret.

> Шаблоны - тем более, это ж обычные макросы, разворачивающиеся в
> пачку того же кода, что под ними, каким бы он нибыл
> - хоть структурным, хоть ООП, хоть ФП прикрути.
> Кавычки здесь - это примерный эквивалент foreach(ls()){...} -
> что здесь функционального?

Прямое - передаётся функция.

> И, опять же, ограничения ФП не соблюдаются.

Какие? Если вы про "все переменные неизменяемы", то это ведь необязательная штука. Да и вообще, никто не заставляет делать исключительно "функциональный" язык, без императивных возможностей. Лучше наоборот - связка и того, и другого, см OCaml.

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

И функционалка, и императивка - это просто приёмы. Ничего взаимоисключающего, заставляющего использовать либо то, либо другое, нет (см. OCaml/F#)

Ответить | Правка | Наверх | Cообщить модератору

304. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Crazy Alex (ok), 11-Фев-13, 20:26 
Ну так и ОО отлично передаются и делегаты и функторы и стретгии, в обычных сях есть указатели на функцию, в ассемблере (x86, по крайней мере) есть  indirect call... могу еще фортран вспомнить с вычисляемыми метками. И всё это - передача функции, в общем-то.

Вот за вариант "это просто приёмы, используем то,что удобнее в нужный момент или любую комбинацию" - я всеми лапами. Но обычно когда речь ведут об ФП именно на ограничения налегают...

Ответить | Правка | К родителю #297 | Наверх | Cообщить модератору

305. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Vkni (ok), 11-Фев-13, 23:38 
> Ну так и ОО отлично передаются и делегаты и функторы и стретгии,
> в обычных сях есть указатели на функцию, в ассемблере (x86, по
> крайней мере) есть  indirect call... могу еще фортран вспомнить с
> вычисляемыми метками. И всё это - передача функции, в общем-то.

Можешь. Но эти делегаты, функторы и т.д. - не родное. В OCaml я поставил
-inline 1000, всё встроилось в код. Опять таки, делегаты и функторы слишком
тяжеловесно описываются в ОО.

> Вот за вариант "это просто приёмы, используем то,что удобнее в нужный момент
> или любую комбинацию" - я всеми лапами. Но обычно когда речь
> ведут об ФП именно на ограничения налегают...

Я, кстати, не очень понимаю, в чём ограничения - компилятор прекрасно может
понять по тексту функции, является ли она "pure" или нет. И даже для С++. :-)

Ответить | Правка | К родителю #304 | Наверх | Cообщить модератору

314. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 12-Фев-13, 01:38 
Ну, описываются - это уже вопрос синтаксиса языка, isn't it? Вон, в D они вполне себе легко описываются.


По второму - я не понял, к чему это. Я имел в виду, что под ФП обычно понимают целую пачку концепций - функции как firt class members, иммутабельность, чистота, а остальные варианты - только с струдом или неудобствами (вообще обойтись, разумеется, не выйдет). ладно, тут уже разговор больше подходящий для джаббера или переписки пошел, как мне кажется - к теме отношения никакого не имеет.

Ответить | Правка | К родителю #305 | Наверх | Cообщить модератору

136. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от metallica (ok), 10-Фев-13, 01:49 
> Сама концепция UNIX безнадёжно устарела. Система UNIX построена на портабельном ассемблере
> - языке C. Сейчас прошли две "революции" - появление в mainstream
> объектно-ориентированных языков и функциональных. Вы хотите объектную шину, поддерживающую
> серьёзный трафик, в том числе и broadcast, при этом берёте "старую"
> ОС . И, естественно, эта шина выглядит как на корове седло.
> Нужно менять ОС - тот же Ведроид уже объектен, там такие типизированные
> шины будут в дугу. А по-настоящему общеупотребительной функциональной ОС ещё нет,
> будем ждать.

На ОО языках в mainstream пишут охочие до прибылей шараги,творящие свои Business Suite-ы за
как можно меньшие промежутки времени.Ядра-это только C.

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

138. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 01:52 
> На ОО языках в mainstream пишут охочие до прибылей шараги,творящие свои Business
> Suite-ы за
> как можно меньшие промежутки времени.Ядра-это только C.

Более того, отдельные участки ядра делаются на ассемблере или вообще в маш. кодах. Но интерфейсов ядра и идеологии ОС это не задаёт.

Ответить | Правка | Наверх | Cообщить модератору

161. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 10-Фев-13, 03:21 
> Более того, отдельные участки ядра делаются на ассемблере или вообще в маш. кодах.

Так ассемблер и есть человекочитаемое представление машинных кодов по сути. В общем сразу видно человека который витает в облаках высоких концепций и ... и не представляет как же там внутри работают эти чертовы компьютеры.

Ответить | Правка | Наверх | Cообщить модератору

174. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Vkni (ok), 10-Фев-13, 11:28 
> Так ассемблер и есть человекочитаемое представление машинных кодов по сути.

"Отрок, ты мне так всю физику к х-ям сведёшь." Между ассемблером и маш. кодами есть ещё автокод. А в "человекочитаемое представление машинных кодов" можно при желании и Хаскелл записать.

Ответить | Правка | Наверх | Cообщить модератору

177. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Аноним (-), 10-Фев-13, 12:31 
> маш. кодами есть ещё автокод.

По большому счету, я понимаю под ассемблером программу или набор программ которые переводят человекочитаемый листинг в бинарный код. Да, вот так вот просто мы и сводим физику к этому самому :). Кстати этой физикой если что я умею пользоваться в том числе и на практике, вплоть до компоновки машинных слов в желаемом лично мной формате. Так что например осмысленный для человека текст окажется осмысленным машинным кодом. Just because I can, разумеется. Ну и потому что это по своему красиво.

Ответить | Правка | Наверх | Cообщить модератору

180. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Vkni (ok), 10-Фев-13, 12:45 
> По большому счету, я понимаю под ассемблером программу или набор программ которые
> переводят человекочитаемый листинг в бинарный код.

Ну нельзя так вольно обращаться со словами. Плюс ещё категорично обвиняя других людей в том, что они "не знают". Это детское поведение - очевидно же, что я не обладаю телепатией и поэтому не знаю ваших внутренних определений.

Ответить | Правка | Наверх | Cообщить модератору

276. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 11-Фев-13, 12:29 
> Ну нельзя так вольно обращаться со словами.

Ну я уже взрослый и сам для себя решаю что мне можно, извините :). Те кто что-то на практике пишет на ассемблере - меня понимают с пол-оборота, а это в общем то единственное что для меня роялит. А рассуждения о красивостях от академиков - оно конечно да, но это чисто эстетический аспект. На результат это не влияет. Докопаться до формальностей конечно можно, а смысл? Это буквоедство ради буквоедства.

> Плюс ещё категорично обвиняя других людей в том, что они "не знают".

А где я кого-то обвинял? Я лишь выступал против навязывания вашей точки зрения как единственно верной. Как по мне - пусть кому "нужно делать вот так" - так идет и делает наздоровье. Так как посчитал нужным. А другие сами разберутся как им нужно. Вон Торвальдс не послушал Таненбаума - и сделал нечто работающее в результате хотя-бы. А наслушался бы как надо - и постигла бы его участь hurd'ов и minix'ов. Как показывает практика - иногда надо уметь показать всем умникам с их поучениями фак и сделать так как считаешь нужным. Особенно если результат потом тебе же и кушать придется. Вот Торвальдс очень метко заметил что когда теория и практика начинают клещиться, практика побеждает.

> Это детское поведение - очевидно же, что я не обладаю телепатией и поэтому не знаю
> ваших внутренних определений.

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

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

188. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 10-Фев-13, 13:04 
> Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что
> не нужно отправлять сообщения о вставленной флешке раз в 10 микросекунд.

Ага:

https://bugzilla.redhat.com/show_bug.cgi?id=684614 (и это не одна модель/производитель девайса)

http://www.spinics.net/lists/linux-scsi/msg53075.html (workaround же, хоть и оптимальный, наверное)

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

> Сама концепция UNIX безнадёжно устарела. Система UNIX построена на портабельном ассемблере
> - языке C. Сейчас прошли две "революции" - появление в mainstream
> объектно-ориентированных языков и функциональных. Вы хотите объектную шину, поддерживающую
> серьёзный трафик, в том числе и broadcast, при этом берёте "старую"
> ОС. И, естественно, эта шина выглядит как на корове седло.

Эту концепцию еще иногда называют философией. И имхо если она зависит от ориентации языков, то что-то с ней не так.

> Нужно менять ОС - тот же Ведроид уже объектен, там такие типизированные
> шины будут в дугу.

d-bus и в gnu/linux не только рождается ведь. То есть "в дугу" давно и тут присутствует.

Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

197. "В ядро Linux планируется включить функциональность D-Bus"  –2 +/
Сообщение от Vkni (ok), 10-Фев-13, 13:24 
> https://bugzilla.redhat.com/show_bug.cgi?id=684614 (и это не одна модель/производитель
> девайса)

Знаете такую штуку - fork bomb? Или, например, неправильно сделанная программа может выжрать всю имеющуюся память, уйдя глубоко в swap. Как люди борятся с таким? Ставят ulimits - не хватило ресурсов компа, значит не судьба выполнить эту программу. Жалко, но делать нечего.

Так и тут - разрешить от каждой программы не больше 10-ти сообщений в секунду. Больше - отказ от передачи. Для человека и для ОС такой спам бессмысленен - мы всё равно не можем это обработать.

> Эту концепцию еще иногда называют философией.

Это неправильно. Тут именно концепция - всё есть файл; программные системы делаются из программ 2-х уровней - быстрые Сшные и медленные, но легко пишущиеся - на скриптах; управляющие каналы в текстовом виде (для простой отладки).

> И имхо если она зависит от ориентации языков, то что-то с ней не так.

Почему вы так решили? Чаще всего для ОС имеется "системный язык". И концепции ОС должны быть хорошо выражаемы на этом "системном языке". Для Ведроида этот язык - Java, для UNIX - С, для BeOS - C++ (объектно-ориентированная часть). Для других очень часто берут С и добавляют в него свои фичи. Например, так сделано в OC Chorus.

> d-bus и в gnu/linux не только рождается ведь. То есть "в дугу"
> давно и тут присутствует.

А зачем тогда делать кентавра? Если нужна такая шина и вообще передача не текста, а объектов, стоит развивать Ведроид в направлении на десктопы. Может быть добавить в него Фантомовскую персистентную память.

Ответить | Правка | Наверх | Cообщить модератору

206. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от qux (ok), 10-Фев-13, 14:02 
> Знаете такую штуку - fork bomb? Или, например, неправильно сделанная программа может
> выжрать всю имеющуюся память, уйдя глубоко в swap. Как люди борятся
> с таким? Ставят ulimits - не хватило ресурсов компа, значит не
> судьба выполнить эту программу. Жалко, но делать нечего.

Если в данном случае не судьба пользоваться этим устройством, то это немногих устроит.
В ulimits, кстати, ресурс памяти afaik давно не работает, надо в cgroups лезть.

> программные системы делаются
> из программ 2-х уровней - быстрые Сшные и медленные, но легко
> пишущиеся - на скриптах; управляющие каналы в текстовом виде (для простой
> отладки).
> Почему вы так решили? Чаще всего для ОС имеется "системный язык". И
> концепции ОС должны быть хорошо выражаемы на этом "системном языке".

Так есть, но имхо это не лучший вариант. Системный язык пусть будет для ядра, а для остального... "работа со строками в С" это отдельный мем, и что? Эта же концепция UNIX его и включает. То есть и по факту не сильно хорошо привязывается к возможностям языка, с момента своего появления.

> А зачем тогда делать кентавра?

Улучшить существующего :-)

> Если нужна такая шина и вообще передача
> не текста, а объектов, стоит развивать Ведроид в направлении на десктопы.
> Может быть добавить в него Фантомовскую персистентную память.

Ведроид это продукт одного конкретного производителя, имеющий своей основной задачей (очевидно) захват рынка. Никаких особых преимуществ у него имхо нет (быстрая/легкая разработка софта, по сравнению с С, лично для меня не оно).

Ответить | Правка | Наверх | Cообщить модератору

114. "В ядро Linux планируется включить функциональность D-Bus"  +2 +/
Сообщение от Аноним (-), 10-Фев-13, 00:01 
> В ядро-то на кой?

А чем ядро хуже всех остальных, что ему так должно быть нельзя? Согласитесь, ядро могло бы разослать броадкаст вида "парни, мы тут перешли с сети на батарею, экономим питание кто как умеет!" вообще всем заинтересованным в этом программам, которые могут как-то менять свое поведение. Ну там менеджер питания может завернуть более жесткие политики powersave-а оборудованию, фоновые программы которые не критичны - встать на паузу до лучших времен, etc, etc. Один из наиболее очевидных примеров.

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

123. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Crazy Alex (ok), 10-Фев-13, 00:46 
как ни смешно, но с  этой штукой ядро такого не сделает. И это правильно - ядро даёт общий механизм, а выбор кокртеных форматов соообщений (в частнсоти, D-Bus) остаётся юзерспейсу. А чтобы рассказат о батарее есть udev, который с этим вполне справляется. А вот он может уже и по D-Bus ссобщение бросить. Собственно, так сейчас и происходит, AFAIK.
Ответить | Правка | Наверх | Cообщить модератору

139. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 01:55 
> А чем ядро хуже всех остальных, что ему так должно быть нельзя?

Сложность отладки, повышенная опасность ошибок в коде.

> Согласитесь, ядро могло бы разослать броадкаст вида "парни, мы тут перешли
> с сети на батарею, экономим питание кто как умеет!" вообще всем
> заинтересованным в этом программам, которые могут как-то менять свое поведение.

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

Поэтому тут достаточно программы пользовательского режима, гоняемой, видимо, даже не из-под root'а, а, скажем, пользователя dbus из группы dbus.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

146. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Аноним (-), 10-Фев-13, 02:27 
> Сложность отладки,

Было актуально ...цать лет назад. С виртуализаторами - можно ковырять вдоль и поперек. Даже снапшотов с образами оперативной памяти налепить и колупать их потом в свое удовольствие. А еще там KDB есть к тому же, так что если ядро не полностью околело, можно его само собой же и отлаживать :)

> повышенная опасность ошибок в коде.

Вот это есть. Ну так и отношение там к коду лучше чем у абы каких быдлокодеров все-таки.

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

Через минуту - не пойдет. За минуту юзер может сделать кучу действий связанных с питанием. Кроме того, ядру все эти события просто виднее всего по его природе. Ну, работает ядро и его модули с интеллектуальным чипом менеджера питания, висящим на I2C шине, например. Логично что если чип информирует нас о чем-то - удобнее всего было бы чтобы ядро отброадкастило от него эту информацию всем заинтересованным подписчикам. А зачем там туева хуча побочных прослоек? Так пожалуй даже менее надежно станет - чем больше звеньев в цепи, тем вероятнее что что-нибудь обломается и сглючит.

> никто не помрёт. Это, конечно, крайний случай, но такая шина уведомлений
> не должена гонять большой трафик.

Для универсальной шины заранее не известно какой именно там будет траффик и по какому поводу. Значит оно должно быть способно на многое. Иначе потом юзеры начнут удивляться - что за нафиг - процессор грузится непонятно чем, батарей садится на 2 часа раньше чем должна! Отстой эта ваша операционка!

> Поэтому тут достаточно программы пользовательского режима, гоняемой, видимо,
> даже не из-под root'а, а, скажем, пользователя dbus из группы dbus.

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

Ответить | Правка | Наверх | Cообщить модератору

152. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от Vkni (ok), 10-Фев-13, 02:47 
>> Сложность отладки,
> Было актуально ...цать лет назад. С виртуализаторами - можно ковырять вдоль и
> поперек.

И откуда вы с виртуализатором выясните, где у вас идёт обращение к памяти ядра, но не принадлежащей этому драйверу?

>> повышенная опасность ошибок в коде.
> Вот это есть. Ну так и отношение там к коду лучше чем
> у абы каких быдлокодеров все-таки.

И? Это квалифицированные люди, их время стоит денег. Значит, разумно упростить им отладку и обезопасить их код, чтобы они могли не так сильно напрягаться.

>> Тем кто подписался на сообщение. Так для рассылки такого ядерные скорости совершенно
>> не нужны. Сообщения о смене питания можно вообще через минуту обрабатывать,
> Через минуту - не пойдет. За минуту юзер может сделать кучу действий
> связанных с питанием.

Ну сделает, ну обработаются через минуту. Никакой пользователь не будет вытаскивать и втыкать штеккер в ноут со скоростью 25 раз в секунду. Даже 2 раза в секунду не будет.

> Кроме того, ядру все эти события просто виднее
> всего по его природе. Ну, работает ядро и его модули с
> интеллектуальным чипом менеджера питания, висящим на I2C шине, например. Логично что
> если чип информирует нас о чем-то - удобнее всего было бы
> чтобы ядро отброадкастило от него эту информацию всем заинтересованным подписчикам.

Ну вот оно передаёт демону в пространстве пользователя. А демон шлёт по шине в пр-ве пользователя. Зачем тут шина в ядре?

> А зачем там туева хуча побочных прослоек?

Давайте засунем всю систему в пространство ядра. :-)

> Для универсальной шины заранее не известно какой именно там будет траффик и
> по какому поводу.

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

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

Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?

Ответить | Правка | Наверх | Cообщить модератору

175. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от Аноним (-), 10-Фев-13, 11:41 
> И откуда вы с виртуализатором выясните, где у вас идёт обращение к
> памяти ядра, но не принадлежащей этому драйверу?

В теории, виртуализатор может стопроцентно мониторить всю память. На практике понятное дело есть куча факторов, в том числе и само оборудование, которое само может данные в память гонять через DMA "как драйвер запрограммит" и прочие прелести, позволяющие поставить колом систему не столь очевидными но не менее невкусными марштурами. С другой стороны эти факторы и микроядро с драйверами в юзермоде так же поставят колом. Ну вон например драйвера GPU. Ну тот же радеон, пускай. Его основной бич - GPU вешается из-за ошиобк в работе оборудования (errata, не описаны в спеках). Рекавери GPU - отдельный гемор, сравнимый по сложности реализации с чуть ли не запуском ракеты в космос и столь же обломоопасный, т.к. современный GPU - это навороченный комплекс из нескольких подсистем. Которые желательно показать апликухам в том виде как было, иначе они осыпятся как горох. А если рекавери не удался - система резко остается без картинки на экране по вполне очевидной причине. Скажите, пожалуйста, как именно то что вы сватаете поможет в отладке в этом вполне рядовом и заурядном случае? А вот тормознет - запросто. Там летают чуть ли не гигабайты в секунду, так что одно лишнее копирование может положить производительность в разы.

> И? Это квалифицированные люди, их время стоит денег. Значит, разумно упростить им
> отладку и обезопасить их код, чтобы они могли не так сильно напрягаться.

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

> Ну сделает, ну обработаются через минуту. Никакой пользователь не будет вытаскивать и
> втыкать штеккер в ноут со скоростью 25 раз в секунду. Даже 2 раза в секунду не будет.

Тормозные системы пользователям не нравятся. В свое время это крепко подгадило WinNT с более правильным дизайном заставив несколько лет выпускать 9х попутно допиливая дизайн NT до состояния когда его скорость таки устроит юзерей. А сейчас запросы выросли, юзеры хотят разрешения FullHD и выше, 3D навороченное и что там еще. И опять же тормознуть ту же графическую подсистему - не вариант. SSD опять же по скорости - очень быстрые штуки, приближающиеся к физическим лимитам интерфейсов. Если проц прии этом начнет клинить в пять раз сильнее - кому оно будет надо?

> Ну вот оно передаёт демону в пространстве пользователя. А демон шлёт по
> шине в пр-ве пользователя. Зачем тут шина в ядре?

Затем что по факту этим заведует ядро и довольно глупо пытаться делать вид что это не так. Только почем зря строится лишняя длинная цепочка, снижая скорость. А может и надежность. По такой логике и TCP/IP должен отдельный демон делать. Вот только нафига оно надо такое счастье? Пусть кому надо - тот этим и пользуется, если хочет.

>> А зачем там туева хуча побочных прослоек?
> Давайте засунем всю систему в пространство ядра. :-)

Маленькие и простые системы ксати так и делают - на 8-битниках всяких вообще нет разделения режимов. И ничего, работает. Даже в ответственных применениях, между прочим. А оно всякими ABS щелкает, подушки безопасности выбрасывает и делает прочие задачи, в общем то завал которых достаточно критичен. Наверное секрет не в том чтобы изящно подтереться после того как из штанов потекло, а не допускать этого самого вытекания, для начала. Кому нужна система от которой дурно пахнет?

>> Для универсальной шины заранее не известно какой именно там будет траффик и
>> по какому поводу.
> Если вы будете гонять гигабайты, вы во-первых, заблокируете шину.

Значит по хорошему должен быть некий арбитраж и дележ ресурсов, предотвращающий такой сценарий в бесконтрольном виде.

> Если вы будете делать шину с использованием всех имеющихся в системе процессоров,
> с коммутацией пакетов, с приоритезацией и т.д., вы сильно усложните простую
> задачу уведомления о редких событиях.

Ну вон TCP/IP реашает довольно сложную задачу и имеет довольно много опций. И тем не менее, его не так уж сложно использовать. И да, таки в ядре есть возможность приоретизации пакетов и прочая. Но это не значит что апликушнику будет сложно создать сокет с нужными параметрами и прочая.

>> на основании чего ядро должно быть обделено на возможности броадкаста и
>> получения сообщений.
> Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?

Вот мне и не понятно - зачем в этом процессе какие-то левые юзерспейсные демоны вообще будут фигурировать?

Ответить | Правка | Наверх | Cообщить модератору

196. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 10-Фев-13, 13:19 
> Вот мне и не понятно - зачем в этом процессе какие-то левые
> юзерспейсные демоны вообще будут фигурировать?

Потому что в ядро кладется по минимуму, механизмы. Всё остальное, в т.ч. логику, как их использовать — юзерспейсу. Иначе можно много чего в ядро затащить, webkit там, libodf какую-нибудь... :-)

Ответить | Правка | Наверх | Cообщить модератору

349. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 16-Фев-13, 15:26 
> Потому что в ядро кладется по минимуму, механизмы.

Это не ответ. Получается что концепции ради концепций. А так не пойдет, особенно если надо делать добавочную работу и/или начинает работать хуже чем было.

Ответить | Правка | Наверх | Cообщить модератору

350. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от qux (ok), 16-Фев-13, 15:35 
Если "если", значит плохо подумали. А почему "ради" не понял, цель концепции — помочь определить, что лучше класть в ядро, а что оставлять юзерспейсу. Если есть такой выбор, то должны быть какие-то guidelines же.
Ответить | Правка | Наверх | Cообщить модератору

198. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Vkni (ok), 10-Фев-13, 13:35 
> В теории, виртуализатор может стопроцентно мониторить всю память.

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

> С другой стороны эти факторы и микроядро с драйверами в юзермоде
> так же поставят колом.

Да, но хоть часть проблем уйдёт. Это уже неплохо.

>[оверквотинг удален]
> GPU вешается из-за ошиобк в работе оборудования (errata, не описаны в
> спеках). Рекавери GPU - отдельный гемор, сравнимый по сложности реализации с
> чуть ли не запуском ракеты в космос и столь же обломоопасный,
> т.к. современный GPU - это навороченный комплекс из нескольких подсистем. Которые
> желательно показать апликухам в том виде как было, иначе они осыпятся
> как горох. А если рекавери не удался - система резко остается
> без картинки на экране по вполне очевидной причине. Скажите, пожалуйста, как
> именно то что вы сватаете поможет в отладке в этом вполне
> Там летают чуть ли не гигабайты в секунду, так что одно лишнее копирование
> может положить производительность в разы.

А зачем лишний раз копировать? Есть всякие варианты с shared memory.

> Вы так говорите как будто эти разработчики уполномочивали вас говорить от своего
> лица. А они этого не делали, между прочим. И т.к. они
> вполне успешно пилят свои драйвера уже более десятка лет

Да. Наш дедушка пахал плугом. И мы будем делать то же самое.

> Тормозные системы пользователям не нравятся. В свое время это крепко подгадило WinNT

NT подгадило то, что память тогда была очень дорогая.

> А сейчас запросы выросли, юзеры хотят разрешения FullHD и выше, 3D навороченное
> и что там еще. И опять же тормознуть ту же графическую
> подсистему - не вариант.

Какое отношение имеет граф. система к общесистемной шине для редких событий? Или вы собрались о каждом кадре фильма оповещать народ? "Your mouse have moved. Press any key to reboot."

> Если проц прии этом начнет клинить в пять раз сильнее - кому оно будет надо?
> По такой логике и TCP/IP должен отдельный демон делать.

По хорошему - да. Это микроядерная концепция. Просто каждая строчка стека
TCP/IP выходит по цене Шекспировского тома. На отладку всего и всея таких ресурсов нет.

> Маленькие и простые системы ксати так и делают - на 8-битниках всяких
> вообще нет разделения режимов. И ничего, работает.

Там однозадачные системы. А раз другие задачи, то и другие решения. Это, как бы азбука. Даже неловко напоминать об этом.

> Значит по хорошему должен быть некий арбитраж и дележ ресурсов, предотвращающий такой
> сценарий в бесконтрольном виде.

Ну вот, предлагаю арбитраж - до 10-ти собщений в секунду. Сообщение до 140 символов. На вытаскивание флешки этого хватит.

> Ну вон TCP/IP реашает довольно сложную задачу и имеет довольно много опций.
> И тем не менее, его не так уж сложно использовать.

Использовать просто. РЕАЛИЗОВАТЬ сложно.

>> Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?
> Вот мне и не понятно - зачем в этом процессе какие-то левые
> юзерспейсные демоны вообще будут фигурировать?

За тем, что MS DOS - это вообще не операционная система. Это "монитор".

Ответить | Правка | К родителю #175 | Наверх | Cообщить модератору

257. "В ядро Linux планируется включить функциональность D-Bus"  +1 +/
Сообщение от XPEHemail (?), 11-Фев-13, 02:14 
> Да. Наш дедушка пахал плугом. И мы будем делать то же самое.

Ну да. Дедушка пашет плугом, разработчики разрабатывают ядра ОС, форумные теоретики треплют языком.
Каждому свое.

Ответить | Правка | Наверх | Cообщить модератору

324. "В ядро Linux планируется включить функциональность D-Bus"  +/
Сообщение от Аноним (-), 12-Фев-13, 05:40 
> Ну можете. Но как вы определите, что функция одного драйвера в ядре
> затёрла память другого драйвера ядра? Вы же не анализируете расположение динамически
> выделенных таблиц.

До некоторой степени можно по адресам разных сущностей, все-таки карта размещения оных - генерится. Именно заезд в чужой динамический массив - сложнее, скорее всего понадобится какой-то костылик в аллокаторе проверяющий это явным образом. С другой стороны, у медали есть обратная сторона: можно сделать из бага фичу. И все эти очень эффективные zero-copy, фокусы с тасовками страниц и прочая - они ведь по другому не прокатят. А там где гигазы в секунду летают, все это совсем не лишнее.

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

А линукс все-таки скорее ОС общего назначения, а не средство руления ядерным реактором напрямую, где зафэйленная аллокация памяти может вызвать "большой бумс" самым непосредственным образом, т.к. стержни видите ли заклинило и реактор по этому поводу пошел вразнос. Если так получается - это просто грубая ошибка в дизайне уровней системы. Все-таки, если память выделяется динамически, вполне возможно что аллокатор заявит что выделять ее вот прям сей момент - неоткуда. А вот это уже как бы проблема - корректное функционирование при этом будет нарушено точно. Ведь если память выделяли - наверное не для красоты?

> Да, но хоть часть проблем уйдёт. Это уже неплохо.

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

> А зачем лишний раз копировать? Есть всякие варианты с shared memory.

В микроядрах все это сильно сложнее получается.

> Да. Наш дедушка пахал плугом. И мы будем делать то же самое.

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

> NT подгадило то, что память тогда была очень дорогая.

Изначальному дизайну, с видеодрайверами в режиме пользователя, подгадило прежде всего то что графическое окружение в нем безбожно тормозило. MS очень конкретно на это взъелся и засунул в ядро не только видеодрайвера, но и вообще заметные куски GDI (в выноске win32k.sys). Вот это уже даже оверкилл. Но графика втопила конкретно. И вскоре NT захватила мир.

Замечу что даже в том же пингвине в попытках получить от графической подсистемы приемлимую производительность пришли к в чем-то похожим вариантам - низкоуровневые выноски для совсем базовых операций - все-таки внесли в ядро. До такой жести как win32k.sys на несколько метров в режиме ядра конечно же не дошли. Все-таки XXI век на дворе, компьютеры стали быстрее, да и куча проблем с секурити показывает что так делать не следует. Но кое-какие общие идеи все-таки кочуют по разным дизайнам.

[skip]
> Какое отношение имеет граф. система

В принципе - никакого. Это лишь как пример было приведено.

> к общесистемной шине для редких событий?

Это вы придумали что оно для редких. А как по мне так допущение что "для редких" это большой продолб на этапе проектирования. Потому что на практике окажется что нифига не редких и систему начнет радостно клинить там и тут.

> Или вы собрались о каждом кадре фильма оповещать народ?

Каждый кадр - это еще ладно. А почему должно быть нельзя слать логи всем заинтересованным подписчикам? А если это сервер с 5K RPS - это не 25 кадров фильма. Это 5K сообщений в секунду. И это кстати весьма скромный PPS.

> "Your mouse have moved. Press any key to reboot."

Вот шина с допущением что сообщений будет мало - что-то такое, да.

>> По такой логике и TCP/IP должен отдельный демон делать.
> По хорошему - да. Это микроядерная концепция. Просто каждая строчка стека
> TCP/IP выходит по цене Шекспировского тома. На отладку всего и всея таких ресурсов нет.

Как бы мне не нужна система где на регулярной основе падают драйвера, сетевой стек и что там еще. По поводу чего мне не очевидно чего ради меня должно волновать что система может видите ли попытаться изящно заменить обделанные панталоны.

> Там однозадачные системы.

Не обязательно кстати. Могут быть и RTOS. Правда там список задач обычно хардкодед, как и распределение памяти.

> А раз другие задачи, то и другие решения. Это, как бы азбука. Даже неловко напоминать об этом.

Ну так я и пытаюсь вам намекнуть что от обычного ширпотребного автомобиля (Linux) никто не требует надежности и технологий как у космической ракеты (микроядра).

> Ну вот, предлагаю арбитраж - до 10-ти собщений в секунду. Сообщение до
> 140 символов. На вытаскивание флешки этого хватит.

Угу, а потом оно начнет обрастать костылями как старикан х86. В половине задач придется делать пакетизатор/энкапсулятор, который сможет через это дерьмище пропихнуть то что на самом деле было надо. С немеряными буферами, пересборкой фрагментов и прочая. Во блин счастье.

В общем, если вам зачем-то нужна такая шина - идите и делайте. А я со своей стороны обещаю не пользоваться таким уродцем ни при каких обстоятельствах. Т.к. это нечто из разряда "а давайте у нас будет полтора регистра на весь проц и только 16 битов на адрес?!" :)

> Использовать просто. РЕАЛИЗОВАТЬ сложно.

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

>> Вот мне и не понятно - зачем в этом процессе какие-то левые
>> юзерспейсные демоны вообще будут фигурировать?
> За тем, что MS DOS - это вообще не операционная система. Это "монитор".

Это монитор пытающийся косить под операционку :). Ну, какое-никакое апи оно вывешивало, по поводу чего и "операционка", собственно. Монитор все-таки не занимается предоставлением API программам.

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

211. "В ядро Linux планируется включить функциональность D-Bus"  –1 +/
Сообщение от linux must _RIP_ (?), 10-Фев-13, 14:18 
> Если даст нормальную скорость - то это надежда сделать существенно более модульную
> систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый
> что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.

сеньер сознательно забыл о существующием netlink*() ?


Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру