Грег Кроа-Хартман (Greg Kroah-Hartman), мантейнер нескольких подсистем ядра Linux, также отвечающий за поддержку стабильной ветки ядра, поделился (http://www.kroah.com/log/linux/af_bus.html) планами по интеграции в основное ядро Linux подсистемы обмена сообщениями, предоставляющей аналог протокола D-Bus (http://www.freedesktop.org/wiki/Software/dbus), реализованный на уровне ядра. В рамках проекта предлагается обеспечить внутри ядра поддержку надёжной, быстрой и безопасной системы обмена сообщений, поддерживающей доставку сообщений как в мультикаст режиме, так и в режиме точка-точка.Созданная функциональность позволит обеспечить работу протокола D-Bus без необходимости запуска в пространстве пользователя отдельного демона D-Bus. Для работы конечных приложений с D-Bus планируется подготовить библиотеку libdbus, которая будет предоставлять интерфейс, работающий поверх новой подсистемы ядра. Координация обмена сообщениями внутри ядра позволит существенно ускорить работу протокола D-Bus, подняв характеристики производительности и отзывчивости до уровня, недостижимого для реализации D-Bus, работающей в пространстве пользователя.
Отдельно отмечается, что развиваемый вариант D-Bus отличается от ранее представленной реализации AF_BUS (http://lwn.net/Articles/504970/), которая была отвергнута для включения в основное ядро Linux, но интегрирована в LTSI-ветку (http://www.opennet.me/opennews/art.shtml?num=35898) ядра Linux 3.4, используемую некоторыми производителями встраиваемой техники.
Среди одной из областей применения новой системы обмена сообщениями упоминается организация доступа к внешним ресурсам в развиваемом (http://www.opennet.me/opennews/art.shtml?num=36043) разработчиками GNOME проекте по организации работы самодостаточных пакетов приложений, не зависимых от дистрибутивов и выполняемых каждый в своей изолированной песочнице.
URL: http://www.kroah.com/log/linux/af_bus.html
Новость: http://www.opennet.me/opennews/art.shtml?num=36067
Здравая мысль !!! Будет быстро и единообразно, молодец Грег.
мысль
Ну пусть попробует.Общая шина конечно же нужна, другое дело, что все попытки ее создать - не очень-то хороши. Вообще говоря, наиболее адекватной шиной мне кажется проект ебуса, продложенный Вагнером.
Вот взялся бы кто реализовать эту штучку - вот тогда я бы порадовался.
Меня больше всего смущает то, что может быть в случае уязвимости в этом сервисе. У кого-нибудь из разбирающихся в вопросе есть соображения на тему безопасности?
> У кого-нибудь из разбирающихся в вопросе есть соображения на тему безопасности?lolwut?
sud lolly
А что бывает сейчас, когда находят уязвимости в ведре?И чем они должны принципиально отличатся от будущих уязвимостей Д-Буса?
> Меня больше всего смущает то, что может быть в случае уязвимости в
> этом сервисе. У кого-нибудь из разбирающихся в вопросе есть соображения на
> тему безопасности?Уязвимости, конечно, будут... Но не будет такого ада, как с D-Bus. Не Поттеринг же.
Знающие люди говорят, что в винде чуть ли не 80-90% реально опасных уязвимостей именно из-за удаленного доступа к шине, в том числе при загрузке системы. Так что вопрос вполне актуален.
> уязвимостей именно из-за удаленного доступа к шине,А я думал - из-за уязвимостей сетевых сервисов, системных либ и прочая. Бывают конечно приколы и с сообщениями по шине, но их не так уж и много. Хотя бывали и довольно фундаментальные, т.к. у MS шина сообщений делалась в эпоху винды 3.0, когда про секурити и сети вообще никто ни сном ни духом.
>> уязвимостей именно из-за удаленного доступа к шине,
> А я думал - из-за уязвимостей сетевых сервисов, системных либ и прочая.
> Бывают конечно приколы и с сообщениями по шине, но их не
> так уж и много. Хотя бывали и довольно фундаментальные, т.к. у
> MS шина сообщений делалась в эпоху винды 3.0, когда про секурити
> и сети вообще никто ни сном ни духом.Window message пофиксили в современных версиях??
> Window message пофиксили в современных версиях??Костылей и подпорок налепили. Типа запрета сервисам взаимодействовать с десктопом, так что наиболее проблематичный софт просто не может слать сообщения десктопным программам. Ну, вы понимаете, виндовая очередь сообщений дизайнилась еще в эпоху ранних виндов (3.х наверное) и кооперативной многозадачности. В те поры программа не толкающая очередь сообщений дальше могла вообще повесить всю систему. Учитывая такие свойства, думаю понятно что ни о какой секурити там речи не шло в принципе. А с тех пор оно не так уж и изменилось - совместимость же. Вон для совместимости с досом буквы дисков и то до сих пор таскают :)
>> Window message пофиксили в современных версиях??
> Костылей и подпорок налепили. Типа запрета сервисам взаимодействовать с десктопом, так
> что наиболее проблематичный софт просто не может слать сообщения десктопным программам.
> Ну, вы понимаете, виндовая очередь сообщений дизайнилась еще в эпоху ранних
> виндов (3.х наверное) и кооперативной многозадачности. В те поры программа не
> толкающая очередь сообщений дальше могла вообще повесить всю систему. Учитывая такие
> свойства, думаю понятно что ни о какой секурити там речи не
> шло в принципе. А с тех пор оно не так уж
> и изменилось - совместимость же. Вон для совместимости с досом буквы
> дисков и то до сих пор таскают :)http://blogerator.ru/page/princip-sohranenija-sovmestimosti-...
2 стороны одной медали. 2 подхода. Совместимость - это великолепно и одновременно совместимость - это кошмар.
Если речь идет о варианте Витуса - он без оглядки на производительность спроектирован. Разумеется, текстовый протокол в ядро интегрировать не имеет смысла. А существующий бинарный дбас в пространстве пользователя - бред и ересь, ибо латентность все равно не от этого зависит, а отлаживать неудобно и проч. (у Витуса в т.ч. перечислены некоторые проблемы текущей реализации). Если ядерный механизм обмена сообщениями появится - и дбас в юзерспейсе выкинуть можно, и многие системы обмена сообщениями/очередей могут стать неактуальными.
> Если речь идет о варианте Витуса - он без оглядки на производительность
> спроектирован.Вот ссылка на предложение и обсуждение - http://vitus-wagner.livejournal.com/293683.html
> Вот ссылка на предложение и обсуждение - http://vitus-wagner.livejournal.com/293683.htmlИ при большом потоке сообщений шина с таким дизайном станет раком. Спасибо, HTTP и XML уже надизайнили. И теперь при нужде передать бинарные данные в ход идут похабства типа data: uri, base64 кодирование и прочие костыли. Которые тормозят парсинг в хренадцать раз, раздувают данные в разы, при том что читать ЭТО глазами все-равно ни одна сволочь не будет.
> И при большом потоке сообщений шина с таким дизайном станет раком.Так вот основная мысель в том, что не надо туда большого потока. Как не надо большого потока в логи (их же, блин, читать придётся в худшем случае).
> Так вот основная мысель в том, что не надо туда большого потока.Нафиг-нафиг таких мыслителей, оторванных от реалий. Пусть сидят там в своем уютном загоне, дизайнят свои сферические микроядра в вакууме с расово верными шинами и не лезут, блин, с своими поделиями в системы предназначенные для реального применения в реальном мире.
> Как не надо большого потока в логи (их же, блин, читать придётся в худшем случае).
Стоит сервант в чистом поле. Обслуживает тысячи запросов в секунду. Если он совсем логи не пишет - это suxx, читать будет нечего. Если он зашивается при логгинге - тоже suxx, половина клиентов пойдет нафиг "потому что у товарищ майора обеденный перерыв и он не может вас записать в досье".
Вот честно, не в обиду вам, такое ощущение что вы с другой планеты и вообще не представляете себе как и для чего люди на этой планете используют компьютеры. По поводу чего норовите сосватать порцию рафинированных концепций, которые красивы на бумаге, но на реальных компьютерах работать будут хреново и половина практических задач по применению компьютеров превратится в головняк.
P.S. и да, даже в юниксвэе есть grep. Это как раз чтобы не читать ВСЕ простыни на гигазы. Но начиная с некоторой точки оказывается лучше когда там будет некая быстрая БД с индексами наиболее интересных полей, т.к. грепать простынку на ...цать гигз конечно лучше чем читать глазами, но тоже долго. А если индексы построены - оно куда как интереснее уже. Пардон, времена когда все было просто - закончились. Теперь эпоха гигабитов и терабайтов. И даже типовой десктоп спокойно вывалит несколько тысяч rps и упрется в гигабит с каким-нибудь нжинксом.
> Нафиг-нафиг таких мыслителей, оторванных от реалий. Пусть сидят там в своем уютном
> загоне, дизайнят свои сферические микроядра в вакууме с расово верными шинами
> и не лезут, блин, с своими поделиями в системы предназначенные для
> реального применения в реальном мире.Очень хорошо. Расскажите, пожалуйста, зачем в реальном мире нужна такая шина?
> Очень хорошо. Расскажите, пожалуйста, зачем в реальном мире нужна такая шина?Да дофига применений. Общесистемные броадкасты world-changing событий. Обмен между программами в изолированных окружениях информацией в аккуратном и контролируемом виде. И да, ничему не противоречит например те же логи вести в виде когда источник кидает сообщения по шине а все заинтересованные в логгинге ловят их, соответственно. И по разному логгируют. Кто в сеть шлет на другой хост, кто локально пишет в быструю индексированную базу, а кто вообще отладочный probe и в текстовом виде, в консольку все дампает, например. Ну так, один из вариантов, раз уж мы тут про логи флудим.
>> Очень хорошо. Расскажите, пожалуйста, зачем в реальном мире нужна такая шина?
> Да дофига применений. Общесистемные броадкасты world-changing событий.Это довольно редкий тип событий и без особого трафика.
> Обмен между программами в изолированных окружениях информацией в аккуратном и контролируемом виде.
Corba уже есть.
> И да, ничему не противоречит например те же логи вести в виде когда
> источник кидает сообщения по шине а все заинтересованные в логгинге ловят
> их, соответственно. И по разному логгируют.Есть же вроде syslog, в котором вывод настраивается. Если не хватает - для большого трафика есть pipe, sockets.
> Кто в сеть шлет на
> другой хост, кто локально пишет в быструю индексированную базу, а кто
> вообще отладочный probe и в текстовом виде, в консольку все дампает,
> например. Ну так, один из вариантов, раз уж мы тут про
> логи флудим.Вопрос - как часто? Если делать общесистемную шину, держащую большую нагрузку, к ней придётся прикрутить:
1. Планировщик.
2. Приоритетность сообщений.
3. Разбиение сообщений на пакеты (для больших сообщений).
4. Сложную систему блокировок.
5. Мультипроцессорность.
Если учитывать сетевые транспорты, всё ещё больше усложняется, т.к. скорость транспортов будет отличаться на порядки.
Поэтому значительно проще ограничить область применения редкими и маленькими сообщениями, открывая каналы и соединения там, где нужна передача больших данных и в близком к реальному времени режиме.
> Поэтому значительно проще ограничить область применения редкими и маленькими сообщениями,
> открывая каналы и соединения там, где нужна передача больших данных и
> в близком к реальному времени режиме.А открывалку чем триггерить? Клиент может сам не знать, сколько данных сейчас захочет передать. Динамически по объему можно, но не идеально, как минимум латентность будет прыгать, о реальном времени говоря. Куда-то прописывать правила для конкретных клиентов — совсем плохо.
Потом, требовательным пользователям придется делать множество интерфейсов вместо одного и, возможно, висеть сразу на нескольких одновременно (иначе с латентностью будет еще б0льший ой).Это больше мысли вслух, если что.
> А открывалку чем триггерить?Если часто, то другими методами. Если редко, можно через шину.
Хорошая аналогия того, что вы предлагаете высокоскоростной шиной - это коаксиальное кольцо, объединяющее компьютеры локальной сети. Начиная с определённого кол-ва компов нужно переходить к топологии "звезда" со свитчами.
Поэтому, надо просто ограничить такую шину - не больше 10-ти сообщений в секунду, сообщение не длиннее СМСки. Такой объём на типичном десктопе не нагрузит и Ардуину ни в текстовом виде, ни в бинарном. Для остальных задач - берите Corba, pipes, sockets, shared memory. Эти варианты позволят построить сети передачи среди тех и только тех программ, кому это нужно, с правильной топологией "звезда".
> Динамически по объему можно, но не идеально, как минимум
> латентность будет прыгать, о реальном времени говоря.Вот, вот, вот. О чём я и говорю - у вас какая-то программа решила прогнать 3 гигабайта через эту шину и компьютер подзавис. Лучше сразу явно ограничить область применения этой шины. И сделать в рамках этой области максимально хорошо.
>> А открывалку чем триггерить?
> Если часто, то другими методами. Если редко, можно через шину.Такая логика должна быть у сервера (т.к., повторюсь, приложение само может не знать сколько сейчас будет передавать). А значит единой и подходящей для большинства случаев.
> Хорошая аналогия того, что вы предлагаете высокоскоростной шиной - это коаксиальное кольцо,
> объединяющее компьютеры локальной сети. Начиная с определённого кол-ва компов нужно переходить
> к топологии "звезда" со свитчами.Я пока ничего не предлагал :-) А насчет звезды, она выгодна за счет оффлоада планирования на отдельного участника. Он занимается только этим и у него получается хорошо. Но если (как тут) всё на одном CPU, то сбежать некуда, надо как-то разбираться локально.
> Поэтому, надо просто ограничить такую шину - не больше 10-ти сообщений в
> секунду, сообщение не длиннее СМСки. Такой объём на типичном десктопе не
> нагрузит и Ардуину ни в текстовом виде, ни в бинарном. Для
> остальных задач - берите Corba, pipes, sockets, shared memory. Эти варианты
> позволят построить сети передачи среди тех и только тех программ, кому
> это нужно, с правильной топологией "звезда".Возможно для реального мира вы правы. Чтобы адекватно такое оценивать теоретически, нужно иметь в голове сильно поболе моего. Но против такого варианта сразу бунтует перфекционистская часть (такие ограничения! Закладываемые сразу!), поэтому легко оно точно не взлетит.
> Вот, вот, вот. О чём я и говорю - у вас какая-то
> программа решила прогнать 3 гигабайта через эту шину и компьютер подзавис.Не, там я тоже про открывание отдельных производительных каналов. Как его хорошо организовать.
> Такая логика должна быть у сервера (т.к., повторюсь, приложение само может не
> знать сколько сейчас будет передавать). А значит единой и подходящей для
> большинства случаев.Ну вот у одного сервера она и будет единой. Но отдельной от системной шины.
> Но если (как тут) всё на одном CPU, то сбежать некуда, надо как-то разбираться локально.
У меня уже нет компьютеров с одним CPU и одним ядром. Везде минимум 2 ядра.
> Возможно для реального мира вы правы.
Реальный мир многообразен и его нельзя охватить одной шиной. Значит не надо и стараться.
> Но против такого варианта сразу бунтует перфекционистская часть
> (такие ограничения! Закладываемые сразу!), поэтому легко
> оно точно не взлетит.Я знаю, что не взлетит. Сейчас основная масса орёт "давай кодить" - см. поддержку Wayland. А о всяких ТЗ никто не заботится, т.к. думать действительно тяжело.
А ведь это очень важно, знать где шина будет использоваться, а где - нет.
> Не, там я тоже про открывание отдельных производительных каналов. Как его хорошо
> организовать.Есть масса механизмов, я не вижу смысла их дублировать. А навязывая свой стандарт по открытию таких каналов, вы ограничиваете людей. Мне кажется, что этого делать не стоит.
> Ну вот у одного сервера она и будет единой. Но отдельной от
> системной шины.Если сервер == сущность, обеспечивающая эту шину, то он вроде один в системе, и сейчас, и в варианте сабжа. И эту логику так или иначе он должен включать. Или см. ниже.
> У меня уже нет компьютеров с одним CPU и одним ядром. Везде
> минимум 2 ядра.А я вот пишу с одноядерника. Но это тут значения вообще не имеет, смысл был в том, что выбросить решение за пределы машины (как в варианте "звезды") не выйдет же.
>> Возможно для реального мира вы правы.
> Реальный мир многообразен и его нельзя охватить одной шиной. Значит не надо
> и стараться.Не понял сарказма. D-bus, повторюсь, уже есть и какие-то задачи решает. Кто-то из разработчиков ядра видит способы его улучшить. Обычное развитие системы, что значит не надо стараться?
> Есть масса механизмов, я не вижу смысла их дублировать. А навязывая свой
> стандарт по открытию таких каналов, вы ограничиваете людей. Мне кажется, что
> этого делать не стоит.Где есть? Выше писал, их же к шине прикрутить надо. Или клиенты сами друг с другом будут это согласовывать? Тогда исходный вопрос, всегда ли они могут знать, когда и для чего нужен высокопроизводительный интерфейс. Вы, как понимаю, за "да", но /me не уверен.
И это не навязывание, это уточнение логики одной из основных составляющих предложения.
> Если сервер == сущность, обеспечивающая эту шину, то он вроде один в
> системе, и сейчас, и в варианте сабжа.Тогда не понимаю проблемы. У сервера шины просто нет таких данных, что нужно передавать гигабайтами.
> А я вот пишу с одноядерника. Но это тут значения вообще не
> имеет, смысл был в том, что выбросить решение за пределы машины
> (как в варианте "звезды") не выйдет же.Система UNIX изначально рассчитана на работу в рамках одной машины PDP-11. Уже два процессора - выход за пределы изначальной концепции. Сетевая прозрачность натягивается с трудом - сравните с plan9.
Поэтому какие-то высокоскоростные механизмы передавать наружу не очень получится. А тем более, такую сложную шину, которая должна сочетать мощность передачи, удобство использования и мириады разных потребителей с совершенно разными скоростями (от скриптов bash до передатчиков Гб/сек).
Я знаю системы, которые поддерживают всё, кроме удобства использования - это TCP/IP. Но использовать TCP/IP для связи программ внутри одной машины несколько опрометчиво.
> Не понял сарказма.
Это не сарказм, это правда жизни.
> D-bus, повторюсь, уже есть и какие-то задачи решает. Кто-то
> из разработчиков ядра видит способы его улучшить. Обычное развитие системы, что
> значит не надо стараться?Я сомневаюсь, что это улучшение. Какие минусы решения:
1. Сложность использования и поддержки.
2. Упадёт надёжность ОС - чем больше ядро, тем меньше надёжность.
3. Быстрая DBus будет провоцировать неправильную архитектуру программ, гоняющих по ней видеофайлы.
> Где есть? Выше писал, их же к шине прикрутить надо. Или клиенты
> сами друг с другом будут это согласовывать?Сами, сами. Мы же вообще не знаем, что они хотят передавать, какие данные.
> Тогда исходный вопрос, всегда
> ли они могут знать, когда и для чего нужен высокопроизводительный интерфейс.Более-менее всегда, если на шину наложены строгие ограничения. Если сказано, что шина гарантировано не передаст ни при каких условиях больше 10 SMS в секунду.
Если будет "мы постараемся передать всё", то люди будут слать гигабайтами.
> Вы, как понимаю, за "да", но /me не уверен.
> И это не навязывание, это уточнение логики одной из основных составляющих предложения.Предложение - чётко ограничить ответственность этой шины. Чтобы она была проста и удобна, ей ПРИДЁТСЯ быть маленькой и слабенькой. Это покроет в данный момент не очень хорошо покрытую область - передачу редких системных сообщений всевозможным программам.
С текстом общаться, как известно, относительно легко работать на любом языке программирования даже без специальных модулей.
> Если будет "мы постараемся передать всё", то люди будут слать гигабайтами.Не будут, если увидят что тормоза получатся в несколько раз по сравнению с UDP или каким-нибудь shared memory. Даже в той же винде в нормальных программах "гигабайты через сообщения" не передаются. Т.е. те, кто будут слать гигабайты - будут слать только на своих компах, ибо люди откажутся от таких программ.
А вот общая шина сообщений очень даже нужна - куда проще просто подписаться на какую-то конкретную очередь сообщений, чем ждать что-то на сокете и одновременно мониторить что-то через сигналы и семафоры или еще вдобавок следить за изменениями каких-то файлов
> Тогда не понимаю проблемы. У сервера шины просто нет таких данных, что
> нужно передавать гигабайтами.У него нет, у клиентов могут оказаться. Да, пусть в нештатном режиме работы, но всё-таки лучше чтобы они прошли, а не подропались.
> Система UNIX изначально рассчитана на работу в рамках одной машины PDP-11. Уже
> два процессора - выход за пределы изначальной концепции. Сетевая прозрачность натягивается
> с трудом - сравните с plan9.
> Поэтому какие-то высокоскоростные механизмы передавать наружу не очень получится. А тем
> более, такую сложную шину, которая должна сочетать мощность передачи, удобство использования
> и мириады разных потребителей с совершенно разными скоростями (от скриптов bash
> до передатчиков Гб/сек).Тут пока никуда не денемся (да и у нас не UNIX, и "изначально" было 40 лет назад:-)
И повторюсь, Гб/сек штатно (24/7/365 кто-то кому-то что-то шлет таким темпом) не надо. Но осиливать недолгие всплески имхо значительный плюс.> Я сомневаюсь, что это улучшение. Какие минусы решения:
> 1. Сложность использования и поддержки.Смотря как завернут. Теперешний d-bus разве сильно отличается?
> 2. Упадёт надёжность ОС - чем больше ядро, тем меньше надёжность.
Ок. Но если сами разработчики ядра хотят практически то же, но у себя, то, наверное, причины есть. В конце-концов, если сильно захочется, возможно сделают вариант когда приложение будет делать один и тот же вызов, а библиотека сама разберется, нужно это передать ядру (где эта поддержка собрана модулем), или в юзерспейсе для этого дела свой демон работает (как сейчас).
> 3. Быстрая DBus будет провоцировать неправильную архитектуру программ, гоняющих по ней
> видеофайлы.
> Если будет "мы постараемся передать всё", то люди будут слать гигабайтами.Не аргумент имхо вообще. Ну придется стрелять в скрипачей, как обычно. Они что, кроме этого не найдут что испортить? :-)
Все мы знакомы с ОС, которые ради заботы о юзере задают побольше ограничений и вопросов. И что в итоге получается.> Более-менее всегда, если на шину наложены строгие ограничения. Если сказано, что шина
> гарантировано не передаст ни при каких условиях больше 10 SMS в
> секунду.Не, это вы про out. А я про in. Если они не знают, сколько SMS им повалит в след. секунду, им сложно принять решение открытия отдельного производительного интерфейса.
> С текстом общаться, как известно, относительно легко работать на любом языке программирования даже без специальных модулей.
Ага, снова работа со строками на С :-) sizeof()-1 или не -1, указатель еще разок передвинуть, или уже всё, ставить в конце \0 или он там и так будет, изменил отправитель отступ в новой версии или оставил...
Но неважно, библиотеку вылизать можно.
> Реальный мир многообразен и его нельзя охватить одной шиной.см. USB
> см. USBСм. на витую пару, на SCSI, SATA.
>> см. USB
> См. на витую пару, на SCSI, SATA.Если бы не написал "Витая пара", то я бы ответил нормально. А так звиняйте...
>>> см. USB
>> См. на витую пару, на SCSI, SATA.
> Если бы не написал "Витая пара", то я бы ответил нормально. А
> так звиняйте...FireWire работает в т.ч. и через витую пару, внезапно.
А что, к SATA уже можно подключать что-то кроме дисков? А то это одна из причин по которым esata сдает позиции usb 3.0 :P. Usb более универсален при сравнимой скорости.
> esata сдает позиции usb 3.0
> :P. Usb более универсален при сравнимой скорости.Школота отжигает!:) И вроде ж не каникулы сейчас.
>> esata сдает позиции usb 3.0
>> :P. Usb более универсален при сравнимой скорости.
> Школота отжигает!:) И вроде ж не каникулы сейчас.USB 3.0 - up to 625 MB/s
>> Обмен между программами в изолированных окружениях информацией в аккуратном и контролируемом виде.
> Corba уже есть.Корба уже не применяется ввиду сложности и запыленности. Даже из Java выкидывают обратную совместимость с ней.
>>> Очень хорошо. Расскажите, пожалуйста, зачем в реальном мире нужна такая шина?
>> Да дофига применений. Общесистемные броадкасты world-changing событий.
> Это довольно редкий тип событий и без особого трафика.Это редко используется потому, что технологически не выдержит даже средней нагрузки. При адекватном проектировании то же соединение с сетью и меж-сетевой роутинг удобно сделать на цепочках обрабочиков. Секьюрити удобно вшивать в разрез цепочек, а не прописывать в коде. И многие другие применения... все ограничено скоростью обработки данных. И userspace DBus пока не может переварить требуемый объем. Потому и пихают в ядро.
> Корба уже не применяется ввиду сложности и запыленности. Даже из Java выкидывают
> обратную совместимость с ней.Если вы сделаете аналогичную систему, она будет отличаться от Корбы только меньшей запылённостью.
> Это редко используется потому, что технологически не выдержит даже средней нагрузки. При
> адекватном проектировании то же соединение с сетью и меж-сетевой роутинг удобно
> сделать на цепочках обрабочиков.На DBus?
> Секьюрити удобно вшивать в разрез цепочек, а не прописывать в коде.
> И многие другие применения... все ограничено скоростью
> обработки данных. И userspace DBus пока не может переварить требуемый объем.Потому, что она предназначена для другого. Ну не надо использовать легковушку для перевозки картошки. И картошки мало привезёте, и машину запачкаете так, что люди туда садиться перестанут.
> Если вы сделаете аналогичную систему, она будет отличаться от Корбы только меньшей
> запылённостью.Сейчас схожий функционал делают через другие технологии - те же MQ. И полезнее и вкуснее. А полный аналог корбы походу слишком сложный, чтобы его применять =)
>> Это редко используется потому, что технологически не выдержит даже средней нагрузки. При
>> адекватном проектировании то же соединение с сетью и меж-сетевой роутинг удобно
>> сделать на цепочках обрабочиков.
> На DBus?На аналоге DBus, с приемлемой производительностью.
>> Секьюрити удобно вшивать в разрез цепочек, а не прописывать в коде.
>> И многие другие применения... все ограничено скоростью
>> обработки данных. И userspace DBus пока не может переварить требуемый объем.
> Потому, что она предназначена для другого. Ну не надо использовать легковушку для
> перевозки картошки. И картошки мало привезёте, и машину запачкаете так, что
> люди туда садиться перестанут.Это потому что машина маленькая и не удобная. Сделают флаеры достаточной мощности - и пользуйся! хоть сам катайся, хоть контейнер с картошкой цепляй ;)))
> Сейчас схожий функционал делают через другие технологии - те же MQ. И
> полезнее и вкуснее. А полный аналог корбы походу слишком сложный, чтобы
> его применять =)Да. Поэтому надо разграничить зоны ответственности. Для DBus и аналогов это слабая загрузка, передача общесистемных сообщений.
> На аналоге DBus, с приемлемой производительностью.
Вот этот аналог и должен заниматься своим делом - роутингом и передачей пакетов сети. В userspace к GNOME/KDE он ходить не должен. Так вы обеспечите и развязку kernel space от user space, отвязку всяких непроверенных программ типа gedit от сети и большую безопасность.
> Это потому что машина маленькая и не удобная.
Маленькая машина очень удобна для езды по городу. Особенно по европейскому. Будете в ЕС, берите напрокат самую маленькую машину, какую можете себе позволить. Тогда никого не поцарапаете.
> Сделают флаеры достаточной мощности
> - и пользуйся! хоть сам катайся, хоть контейнер с картошкой цепляй
> ;)))Ну да, ну да.
> Да. Поэтому надо разграничить зоны ответственности. Для DBus и аналогов это слабая
> загрузка, передача общесистемных сообщений.Why not? Если смогут совместить передачу любых сообщений (адекватной длинны) и высокую скорость роутинга, то технология станет базой и для общесистемных сообщений и для обработки TCP пакетов. А то и вовсе драйвера на ней смогу строить. Вопрос скорости.
Кстати AF_BUS уже решил эту задачу... но походу само решение не понравилось девам Linux.
> Вот этот аналог и должен заниматься своим делом - роутингом и передачей
> пакетов сети. В userspace к GNOME/KDE он ходить не должен. Так
> вы обеспечите и развязку kernel space от user space, отвязку всяких
> непроверенных программ типа gedit от сети и большую безопасность.Согласен. О том и речь, что мессенджинг должен идти от источника в приемнику через два переключения источник->ядро->приемник. Без userspace роутера.
> Это довольно редкий тип событий и без особого трафика.На самом деле - как повезет.
>> Обмен между программами в изолированных окружениях информацией в аккуратном и контролируемом виде.
> Corba уже есть.Насколько я понимаю - все реализации получались столь переросточными что ими никто кроме махровейшей ынтырпрайзятины просто не рискует пользоваьтся. Собственно, где оно в мелком, легком и культурном виде, простом для использования софтом и достаточно легким чтобы даже ядро могло в этом принять участие?
> Есть же вроде syslog, в котором вывод настраивается.
Как бы нет стандартного метода кинуть сообщение, а там пусть разные получители логгят как хотят. Сислог - частный случай. В результате появляются всякие там systemd и их супер-пупер-логгеры как ответ на все вопросы жизни и всего-всего. Ну то-есть есть системный вызов, но он не подразумевает в своем дизайне неопределенную группу таргетов, которые заинтересованы в получении логгинга. Изящнее было бы пулять логгинг в шину а там пусть все заинтересованные подписываются на это, если им надо, и логгят как им там удобнее. Кому нравится - сислог, кому нравится - системдэшный логгер, кому нравится - еще что-нибудь. Смотрелось бы вполне логично вроде. И заодно заткнуло бы вопли насчет того какой логгер расово верный. Они бы просто стали все абсолютно равноправными, сосуществующими совместно out of the box, etc. Вся эпопея просто мигом закончилась бы. И устроило бы и олдскульщиков с сислогом, и аваннгардистов с systemd и еще 100500 граждан с специфичными потребностями. А кернел мог бы например предоставить сервис логгинга в оперативу для девайсов с глухим readonly в ФС, благо он наполовину умеет это. А так умел бы целиком, включая не только свой крешдамп но и сообщения сервисов на момент до краха.
> Если не хватает - для большого трафика есть pipe, sockets.
Вот только
1) Форматы обмена никак не стандартизированы. Поэтому или софт знает друг друга явно, или возникает уйма головняка и костылестроения. В самых типовых операциях. Казалось бы простая задачка, сделать несколько получателей системных логов - превращается в целый отдельный головняк.
2) По большому счету эти механизмы не предназначены для броадкаста заведомо неизвестной группе получателей.
3) Собственно шины по большому счету являются логичным развитием идеи. Решая проблемы 1) и 2).> Вопрос - как часто? Если делать общесистемную шину, держащую большую нагрузку, к
> ней придётся прикрутить:
> 1. Планировщик.
> 2. Приоритетность сообщений.
> 3. Разбиение сообщений на пакеты (для больших сообщений).
> 4. Сложную систему блокировок.
> 5. Мультипроцессорность.Как ни странно, даже самый обычный TCP/IP стек в любой нормальной операционке обладает всеми этими свойствами, живет в ядре, имеет около нуля опасных багов и почему-то никаких проблем по этому поводу никто не испытывает. Получается что сделать такое не просто можно, но и делается на регулярной основе.
> Если учитывать сетевые транспорты, всё ещё больше усложняется, т.к. скорость
> транспортов будет отличаться на порядки.Да, вот это уже хитрее, но я думаю что ремотный доступ по шине - сам по себе источник ремотно эксплойтабельных дыр. Как максимум таким должен заниматься какой-то отдельный бридж, берущий на себя подобные вопросы. Скорее всего уже в юзерспейсе.
> Поэтому значительно проще ограничить область применения редкими и маленькими сообщениями,
Да, а еще можно упразднить TCP и оставить только какой-нибудь UDP-lite. И маршрутизацию нафиг. И планировщики и приоритеты. Вообще, нехай только в пределах 1 сегмента работает, а лучше - только локалхоста. Тогда еще и драйвера сетевух можно выбросить. Зато насколько сетевой стек упростится сразу.
> открывая каналы и соединения там, где нужна передача больших данных и
> в близком к реальному времени режиме.И не пользуясь преимуществами шины. Вот скажите, кто как не кернел может очень эффективно реализовать мультикаст? Вплоть до zero copy.
> Как ни странно, даже самый обычный TCP/IP стек в любой нормальной операционке
> обладает всеми этими свойствами, живет в ядре, имеет около нуля опасных
> багов и почему-то никаких проблем по этому поводу никто не испытывает.
> Получается что сделать такое не просто можно, но и делается на
> регулярной основе.Это не "самый обычный стек". Это разработка, которая стоит миллиарды. Дело в том, что нужно учитывать разработку протокола, отладку протокола, разработку стека, разработку маршрутизаторов и т.д. Вот есть такая штука - QOS, относительно недавно введённая.
В случае общесистемной шины это - основополагающая вещь.
В общем, мне вырисовывается шина, которая будет тяжела в общении, которая будет очень дорого стоить, и отлажена будет через годы. Возможно в этом смысл и есть, но явно не для посылки сообщений типа "закрыли ноут", "нажали кнопку питания", "пришло письмо", "разорвалась связь" и т.д.
> Это не "самый обычный стек". Это разработка, которая стоит миллиарды.Весь кернел оценивается IIRC, в ~пару миллиардов баксов. TCP/IP стек - очень незначительный его кусочек. Какие миллиарды, вы о чем? И вообще, первую версию этого ядра выкатил 1 студент, сделав ее буквально на коленке. Тогда как над микроядерным HURD пахало явно больше народа и куда дольше. Что ему почему-то нифига не помогло. Как впрочем и микроядерному миниксу, etc. И микроядерный qnx был много лет. Так и остался весьма нишевой хренотой.
> Дело в том, что нужно учитывать разработку протокола, отладку протокола,
> разработку стека, разработку маршрутизаторов и т.д. Вот есть такая штука
> - QOS, относительно недавно введённая.А линух все это уже довольно давно умеет, между прочим. В лучшем виде. Ага, в ядре, там где "сложно отлаживать", блаблабла. А теперь показывайте где все это в ваших микроядрах, раз там все так просто и замечательно. Чего-то ваши тезисы не подтверждаются практикой, что их сильно обесценивает.
> В случае общесистемной шины это - основополагающая вещь.
Ну если TCP/IP со всеми наворотами в ядре сделать можно и это даже вполне себе прилично работает - то уж локальную шину и подавно более чем реально сделать.
> смысл и есть, но явно не для посылки сообщений типа "закрыли
> ноут", "нажали кнопку питания", "пришло письмо", "разорвалась связь" и т.д.Я думаю что в итоге придут к некоему компромиссному варианту, который достаточно прилично работает и который можно реализовать за разумные сроки с имеющимися ресурсами. Это же линуксоиды, они всегда так делают :)
> TCP/IP стек - очень незначительный его кусочек.Про разработку спецификации TCP/IP вы забыли? Шину-то нужно с 0-я разрабатывать.
> Тогда как над микроядерным HURD пахало явно больше народа и куда
> дольше.При чём тут микроядра? Мы вроде бы на другую тему общаемся в этом треде.
Вы, кстати, не учитываете то, что разработка архитектуры значительно труднее забивки кода в компьютер. Если знать, что писать, то машинистка с 300 знаков в минуту вам набьёт под полмиллиона строк в день.
> Ну если TCP/IP со всеми наворотами в ядре сделать можно и это
> даже вполне себе прилично работает - то уж локальную шину и
> подавно более чем реально сделать.Всё можно. Вопрос - как дорого по финансам и времени. Эта ваша мегашина - фактически развитие Х-ов: тоже нужно уметь перекидывать гигабайты, тоже реалтайм, тоже сервер, клиенты, тоже огромное кол-во транспортов. Очень похоже, только сложнее.
> Очень хорошо. Расскажите, пожалуйста, зачем в реальном мире нужна такая шина?Просто почитайте для чего люди хотя бы тот же д-бус создали и кто его использует. Как минимум эти потребители дэбуса и ускорятся (в новости же писАли).
почитайте зачем был сделан netlink, как работает и поймете что dbus лишь жалкий аналог ее.А вопрос ускорения очень спорный - из-за того что каждый context switch вещь дорогая.
> И при большом потоке сообщений шина с таким дизайном станет раком.В целом да, память выделенная ядру не изменяется динамически. Либо будет легко зафлудить ядро через такую шину, либо к клиентам шины будут приниматься жесткие ограничения. С нетерпением ждем в логе ядра "Limiting message bus overload from xxx to 200 packets per second" и занятные баги приложений связанные с этим. :)
Это всё вполне себе решается для сокетов
> Это всё вполне себе решается для сокетовАлекс, сколько стоит разработка "сокетов"?
В смысле? Решения для сокетов уже разработаны, есть в ядре. Почти уверен, что будут просто задействованы те же механизмы, да и всё.
> В смысле? Решения для сокетов уже разработаны, есть в ядре. Почти уверен,
> что будут просто задействованы те же механизмы, да и всё.Алекс, общение с сокетами сложно. А нужна ПРОСТАЯ в общении шина. В общем, другая задача.
Так ничего не мешает сделать, чтобы она для общеупотребительных кейсов была такой же простой, а для более экзотических случаев появлялись сложности. Ладно, мне сейчас проще согласиться, чем прикидывать, как должна быть построена такая шина.
> Ладно, мне сейчас проще согласиться, чем прикидывать,
> как должна быть построена такая шина.Это, фактически, должны быть Х, только без графики. :-) Они и удовлетворяют почти всем мыслимым требованиям:
1. Максимальная производительность - выбор транспорта по месту.
2. Реалтайм.
3. Сетевая прозрачность.
4. Объединяют все машины, на которых работает в данный момент пользователь.
Минусы:
1. Нужно отпилить графическую часть.
2. Нужно сделать поддержку многопроцессорности, улучшить кеширование.
3. Нельзя всовывать в ядро из-за повышенной сложности и => склонности к багам.
4. Может быть следует сделать своё шифрование/сжатие для передачи по открытым/медленным каналам. А может быть и нет.
Это соображение, кстати, и зарубает на корню всю затею - слишком сложная задача для пилильщиков Wayland и Gnome.
> Если речь идет о варианте Витуса - он без оглядки на производительность
> спроектирован. Разумеется, текстовый протокол в ядро интегрировать не имеет смысла.Так я и не говорил про ядро. А текстовая шина - это очень вкусная штука, согласитесь. Можно было бы отлавливать и изменять сообщения на лету банальным sed'ом.
> Если
> ядерный механизм обмена сообщениями появится - и дбас в юзерспейсе выкинуть
> можно, и многие системы обмена сообщениями/очередей могут стать неактуальными.В принципе да. Лично мне бы это пришлось очень даже по вкусу. А то я многие программы на десктоп себе не ставлю просто потому, что жестко тянут за собой dbus. Особенно обидно то, что evince на dbus завязался. Не жестко, но djvu и pdf без него не отображает.
Кстати, я бы посмотрел на то, что произойдет, когда выйдет релиз этого kernel-dbus. По сути, обратная же колбаса начнется. Все, кто завязывался на dbus, начнут от него потихоньку отвязываться, ибо зная товарища Леннарта, может оказаться очень сложным добиться полной совместимости с dbus.
>> Если речь идет о варианте Витуса - он без оглядки на производительность
>> спроектирован. Разумеется, текстовый протокол в ядро интегрировать не имеет смысла.
> Так я и не говорил про ядро. А текстовая шина - это
> очень вкусная штука, согласитесь. Можно было бы отлавливать и изменять сообщения
> на лету банальным sed'ом.Да блин, пишется простейший диссектор протокола и "отлаживается седом" до посинения. Какая-то надуманная проблема.
>>> Если речь идет о варианте Витуса - он без оглядки на производительность
>>> спроектирован. Разумеется, текстовый протокол в ядро интегрировать не имеет смысла.
>> Так я и не говорил про ядро. А текстовая шина - это
>> очень вкусная штука, согласитесь. Можно было бы отлавливать и изменять сообщения
>> на лету банальным sed'ом.
> Да блин, пишется простейший диссектор протокола и "отлаживается седом" до посинения. Какая-то
> надуманная проблема.Отвечу в пику вашему посту №74:
Ужасно доставляют посты вида "если вы хотить сделать что-то само собой разумеющееся, то просто напишите для этого программу".
> Отвечу в пику вашему посту №74:
> Ужасно доставляют посты вида "если вы хотить сделать что-то само собой разумеющееся,
> то просто напишите для этого программу".Совершенно с этим согласен - мне близка по духу мантра shut up and code. От постов типа витовского разит некомпетентностью и маниловщиной за версту. В том же мемкеше непросто так возник бинарный протокол, при всей, замечу, его простоте ) Если бы я хотел заменить дбас - то не писал бы идиотские посты ни-о-чем,а сделал бы прототип, перевел бы на него пару opensource программ, написал бы бенч и начал бы доказывать что он лучше. А так это из серии "вот если бы ядро линукс было написано на ___, оно бы работало быстрее и надежнее" гг
> Совершенно с этим согласен - мне близка по духу мантра shut up
> and code.Ну а потом получается Wayland, systemd, hal и тому подобная чушь. Боюсь, что уже пора пользоваться другим афоризмом - "если можешь не писать, не пиши". :-)
> Ну а потом получается Wayland, systemd, hal и тому подобная чушь. Боюсь,
> что уже пора пользоваться другим афоризмом - "если можешь не писать, не пиши". :-)Ну вот вы и не пишите. А в данном случае пользователи, админы и програмеры просто выберут те механизмы и инструменты которые для них лучше работают. А то что окажется не востребовано - отомрет естественным методом.
> Ну вот вы и не пишите.Я именно так и делаю, когда есть возможность - беру готовое.
Следуя вашей логике - пользователи уже выбрали Windows, а Linux с его 1% статистической погрешности - должен тихо сдохнуть. Ведь так?Почему OS/2 которая сильно технологичнее - умерла?
> Ну а потом получается Wayland, systemd, hal и тому подобная чушь. Боюсь,
> что уже пора пользоваться другим афоризмом - "если можешь не писать,
> не пиши". :-)Писатели, которые литература, давно его рекомендуют.
>[оверквотинг удален]
>> то просто напишите для этого программу".
> Совершенно с этим согласен - мне близка по духу мантра shut up
> and code. От постов типа витовского разит некомпетентностью и маниловщиной
> за версту. В том же мемкеше непросто так возник бинарный протокол,
> при всей, замечу, его простоте ) Если бы я хотел заменить
> дбас - то не писал бы идиотские посты ни-о-чем,а сделал
> бы прототип, перевел бы на него пару opensource программ, написал бы
> бенч и начал бы доказывать что он лучше. А так это
> из серии "вот если бы ядро линукс было написано на ___,
> оно бы работало быстрее и надежнее" ггЯ не считаю себя достаточно квалифицированным, чтобы судить о компетентности Вас или Вагнера. Однако, судя по рассылке debian-russian, к Витусу очень стоит прислушаться.
Я Вас, конечно же, не знаю, но испытываю большие сомнения, что адекватный человек, создав прототип нового протокола общей шины, начал бы переводить на него open-source программы только для того, чтобы доказать, что его протокол лучше.
Ну и в тему: http://xkcd.com/927/
> испытываю большие сомнения, что адекватный
> человек, создав прототип нового протокола общей шины, начал бы переводить на
> него open-source программы только для того, чтобы доказать, что его протокол
> лучше.Побенчить на чем-то реальном всё же идея хорошая. А то окажется потом, что упустил что-то в размышлениях и минимум пол-идеи насмарку...
> Так я и не говорил про ядро. А текстовая шина - это
> очень вкусная штука, согласитесь.Кроме момента когда таки потребуется передать массив бинарных данных. Вот тут начнется полный прон. А почему по универсальной шине должно быть нельзя быстро перекинуть массив произвольных данных?
> Кроме момента когда таки потребуется передать массив бинарных данных.Это большой массив? Если маленький, то сериализовать и передать. Если большой - отправлять другими путями.
> Это большой массив? Если маленький, то сериализовать и передать. Если большой -
> отправлять другими путями.Угу, вон в жаббере уже довыделывались - передать аватар или фото оказывается целый отдельный гемор с base64, распухоном на треть потока на ровном месте и прочая. А когда в центре этого флуда оказывается сервер на который приперлись тысячи клиентов - его начинает жесточайше клинить. Эталонный пример - jabber.org, на котором в силу его названия висит огромная толпа клиентуры. Дошло до того что сервак иногда тратит десятки секунд на разборку stanzas. И да, как пользователь я вижу большую разницу между разбором протокольного сообщения за 1 секунду (мне похрену) и 10 секунд (меня начинают выбешивать тормоза).
> Угу, вон в жаббере уже довыделывались - передать аватар или фото оказывается
> целый отдельный гемор с base64, распухоном на треть потока на ровном
> месте и прочая. А когда в центре этого флуда оказывается сервер
> на который приперлись тысячи клиентов - его начинает жесточайше клинить.Это неправильная топология. Если сервер клинит от тысячи клиентов и вы его ускорите в 2 раза, считайте, что ничего не произошло - придёт 2 тысячи клиентов, и опа.
> Эталонный пример - jabber.org, на котором в силу его названия висит огромная
> толпа клиентуры. Дошло до того что сервак иногда тратит десятки секунд
> на разборку stanzas. И да, как пользователь я вижу большую разницу
> между разбором протокольного сообщения за 1 секунду (мне похрену) и 10
> секунд (меня начинают выбешивать тормоза).Это, извините, 10 раз, а не 2. Впрочем, народу в РФ - 140 миллионов. Если мало-мальски значительное кол-во пойдёт на Джаббер.орг, то, сами понимаете, можно хоть в 100 раз оптимизировать, толку не будет. Надо изначально алгоритмически исключать подобные ситуации.
Ну, разница между парсингом XML и какого-нибудь Msgpack влёгкую может быть сотни раз. Архитектура - это хорошо, но иногда реализация добавляет совершенно глупые тормоза - что ж, не избавляться от них?
> Ну, разница между парсингом XML и какого-нибудь Msgpack влёгкую может быть сотни
> раз. Архитектура - это хорошо, но иногда реализация добавляет совершенно глупые
> тормоза - что ж, не избавляться от них?Это желательно, конечно. Но надо понимать, что даже 100 раз не спасут бедное животное. А уж тем более 10 и 2. Ради ускорения в 2 раза я бы вообще ничего не переписывал, а купил бы тонны за 3 компьютер с процессором помощнее.
Вообще-то два порядка здесь проблему как раз решат, скорее всего. Но я скорее не о переписывании, а о том, что с самого начала об эффективности думать всё же надо - как раз потому, что это получается довольно дёшево, особенно учитывая, что софт потом может крутиться в очень многих экземплярах. А полиси сверху прикрутить всегда можно.С джаббер-серверами вообще забавно - есть ejabberd и openfire. Так вот для минимального функционала на небольшое количество юзеров ejabberd хватает мелкой vds с 256 памяти (хватит и меньше, но я таких уже и не вижу), а для openfire поболе надо - под 700 где-то, иначе тупит. В результате поднять свой сервер на ejabberd может любой программист/сисадмин (vds сейчас у каждого первого, а сервис жрёт мало), а вот openfire поднимать уже не станет и полезет на гугл или другой какой большой сервер. Вот вам и "дорога в облака"...
> Вообще-то два порядка здесь проблему как раз решат, скорее всего.Только на первое время. Народу-то дофига.
ну понятно, что где-то всё равнобдует потолок. На это есть другая механика - тот же ejebberd кластеризуется отлично. Но надо ж какое-то разумное число клиентов держать. И, простите, если проблема не в обработке логики, а в парсинге - то это совершенно явный косяк.
> И, простите, если проблема не в обработке логики,
> а в парсинге - то это совершенно явный косяк.Разумеется. Но надо понимать, что на что рассчитано. Витусовский bus - для удобной передачи крайне редких сообщений. Настолько редких, что их может и человек читать. То есть, во главу угла ставится удобство подключения, посылки/приёма, мониторинга шины.
Такой шины на данный момент нет - посылка по DBus обладает определёнными непрозрачностями.
Ага, я знаю. Это при том, что он (попзже) этот самый bus вполне готов был положить в основу построения гуя.Но я правда, не могу понять, чего D-Bus считают непрозрачным. Он отлично логируется, мало того - просто по именам сообщений и интерфейсов, по типам полей разбирать содержимое сообщений гораздо удобнее, чем очередной home-grown текстовый формат. Ну бинарь - но ведь все инструменты вывода/ввода в виде текста давно написаны и поставляются вместе с D-Bus.
> Ага, я знаю. Это при том, что он (попзже) этот самый bus
> вполне готов был положить в основу построения гуя.В Гуе bus уже есть. Называется Х. :-)
> Это неправильная топология.Для начала это дебильный выбор формата сообщений. В бинарном виде сервер мог бы смолотить в несколько десятков раз больше сообщений. И выдержал бы не только приход 2000 юзерей но и 10 000. А вот мысля про "эй, парни, а докупите-ка в 10 раз больше серверов под кластер?" обычно не находит понимания. Ну кроме случаев особо жирных энтерпрайзов, которым надо еще вчера, а поэтому они готовы простить любой гогнокодинг, лишь бы оно было готово ну самый край вот прямо сейчас.
> Если сервер клинит от тысячи клиентов и вы его ускорите в 2 раза,
Скорее, в 10+ раз. А так получилось уникально: оно и двуногими читается никаковски (врядли кто-то декодирует base64 на глаз) и машины прилично тормозит. Ни два, ни полтора. Вон файлтрансфер почему-то вообще никогда не работает. А в бинарной насквозь аське - почему-то без проблем. Ну и хренли радости с "простоты отладки" в результате? И где практически значимые результаты, собственно?
> считайте, что ничего не произошло - придёт 2 тысячи клиентов, и опа.
Я вижу некую разницу - поставить N серверов или 2 * N. А если 10 * N - и подавно. Особенно если за это надо платить из своего кошелька.
> изначально алгоритмически исключать подобные ситуации.
Понимаете ли, сервера - они денег стоят. И поставить в 10 раз больше серверов - в 10 раз дороже. Вот и гоняют то что есть по принципу "ну как-то ползает же".
Еще более показательный пример вышел с OSM. Они вон тоже думали что текстовые форматы проще, блаблабла. В результате они пришли к XML портянке на 250 гигабайтов. Офигев от такого счастья они забили на это дело и юзанули бинарный формат. Те же самые данные стали весить около десятка гигз. Что ясен фиг ускорило их скачку, работу с ними и прочая во многие разы. Вот так вот бывает если сглупить и не оценить что маленькая хотелка может стать реально большой задачей. Потом придется на полпути костылить и подпирать.
> А вот мысля про "эй, парни, а докупите-ка в 10 раз больше серверов
> под кластер?" обычно не находит понимания.Обычно находит. Зарплата года программиста в США - 100 тыс. баксов. Это 20 серваков. Только купив серваки получаешь результат сразу, а с программистом - после оптимизации и вылавливания ошибок.
> Скорее, в 10+ раз. А так получилось уникально: оно и двуногими читается
> никаковски (врядли кто-то декодирует base64 на глаз) и машины прилично тормозит.
> Ни два, ни полтора. Вон файлтрансфер почему-то вообще никогда не работает.Ну так это протокол неправильный, overengineered. В текстовом UUCP эта самая передача файлов работает.
> Ну и хренли радости с "простоты отладки" в результате? И где практически значимые
> результаты, собственно?Это проблемы Джаббера, что даже с такими приемуществами в отладке не доделали.
> Я вижу некую разницу - поставить N серверов или 2 * N.
Это очень слабая разница. Нормальная разница - \sqrt{N} и N. Или lnN и N. Остальное не стоит ничего.
> Понимаете ли, сервера - они денег стоят. И поставить в 10 раз
> больше серверов - в 10 раз дороже. Вот и гоняют то
> что есть по принципу "ну как-то ползает же".Гоняют, открою секрет, всегда по-минимуму. Если вы сделаете так быстро, что хватит 0.5N серваков, то половину серваков уберут. И будет ровно то же самое порно. А если будет хватать одного сервака с запасом, его заменят на виртуалку.
> Еще более показательный пример вышел с OSM. Они вон тоже думали что
> текстовые форматы проще, блаблабла.Где как. Но мы-то начали с посылки уведомления. Там бинарный формат хуже.
>> А вот мысля про "эй, парни, а докупите-ка в 10 раз больше серверов
>> под кластер?" обычно не находит понимания.
> Обычно находит. Зарплата года программиста в США - 100 тыс. баксов. Это
> 20 серваков. Только купив серваки получаешь результат сразу, а с программистом
> - после оптимизации и вылавливания ошибок."20 серваков" тоже нужно обслуживать, и тоже не "за еду". И электроэнергия для этих "20 серваков" в США не копейки стоит. И на этих "20 серваках" не слака от Васи пупкина, так что софт там тоже может что-то стоить.
> Обычно находит.Нормальный капиталист давится жабой за каждую копейку.
> Зарплата года программиста в США - 100 тыс. баксов.
1) Далеко не любого.
2) Сие btw привело к основательному аутсорсу в другие страны.> Это 20 серваков.
А еще - чем больше серверов, тем больше затрат на их содержание и ремонт, электроэнергию, охлаждение, администрирование, ...
> Только купив серваки получаешь результат сразу, а с программистом
> - после оптимизации и вылавливания ошибок.А тут еще вопрос что перевесит - затраты на большую инфраструктуру или зарплата программисту. В больших инсталляциях судя по всему инфраструктура начинает существенно перевешивать. Так, глядя на то как всякие фэйсбуки делают трансляторы пыха в си++ и вообще пыжатся с оптимизацией там и тут. Тем более что опенсорс размазывает затраты на разработку на всю ораву в ряде случаев (как например в случае линуксового ядра). А вот содержание инфраструктуры таки будет целиком на ее обладателе, как ни крути.
>> Ни два, ни полтора. Вон файлтрансфер почему-то вообще никогда не работает.
> Ну так это протокол неправильный, overengineered.Ну да. И не помогло ему что он текстовый чего-то.
> В текстовом UUCP эта самая передача файлов работает.
Это то чудо природы, где бинарные файлы почем зря раздувают на треть в виде UUE-кодирования, фиг знает зачем? (найти нынче не-восьмибитнй канал передачи данных - отдельная наука). А через файрволы и наты оно нормально пролезает? А как насчет клинических случаев, когда NAT или firewall с обоих сторон у участников файлтрансфера? Это не блажь, это всего лишь обыденные реалии современного интернета.
> Это проблемы Джаббера, что даже с такими приемуществами в отладке не доделали.
Скорее, это пример того что сама по себе текстовость протокола ни разу не гарантирует вообще нифига. С другой стороны, я видел и очень удачно реализованную отладку бинарных протоколов. Более того - если для не сильно навороченного бинарного протокола я и сам напишу парсер/диссектор и какой-никакой логгер, то вот писать нечто перестраивающее абы как наваленный XML в нечто читаемое я уже поднапрягусь, т.к. это уже явно менее тривиально.
>> Я вижу некую разницу - поставить N серверов или 2 * N.
> Это очень слабая разница.Ага, сразу видно математика. Ну ладно, я согласен, давайте вы тратите 20 килобаксов на сервера и 20 килобаксов дарите мне. Разница небольшая, а мне зато приятно :).
> Нормальная разница - \sqrt{N} и N. Или lnN и N. Остальное не стоит ничего.
Ага, хорошо рассуждать о том что и сколько стоит. При условии что оплатишь не ты :). Но лично я вижу некую разницу между "заплатить 100 баксов" (N) и "заплатить 10 000 баксов" (100 * N).
>> Вот и гоняют то что есть по принципу "ну как-то ползает же".
> Гоняют, открою секрет, всегда по-минимуму. Если вы сделаете так быстро, что хватит
> 0.5N серваков, то половину серваков уберут.Есть еще некие потолки качества сервиса после которого юзеры начинают разбегаться. Вот в частности когда просто логин на сервер занимает около 5 минут (столько сервер парсит станзы потребные для логина), а доставка сообщения занимает 30 секунд, превращая IM в странный подвид почты - это превысит пределы толерантности большинства юзерей.
> И будет ровно то же самое порно. А если будет хватать одного сервака с запасом,
> его заменят на виртуалку.Именно порно не будет - сервис поддерживают на том уровне на котором им можно нормально пользоваться. А вот если в это надо доп. вложения - вот тут бизнес начинает жаться.
> Где как. Но мы-то начали с посылки уведомления. Там бинарный формат хуже.
Не вижу чем именно. Читают это машины. Человеку вообще нечего делать в такой шине, по большому счету. Это чисто техническая сущность операционки. С таким же успехом можно требовать чтобы в сисколах все параметры были текстом, а никак не integer или массив бинарных данных.
> Это большой массив? Если маленький, то сериализовать и передать. Если большой -
> отправлять другими путями.По-хорошему с большим бинарным должна быть та же проблема, что и с большим текстовым, не? А небольшой бинарный чтобы <content-type=application/octet-stream> и погнали, без обработки.
> По-хорошему с большим бинарным должна быть та же проблема, что и с
> большим текстовым, не?Разумеется. Но единая системная шина не может быть предназначена для пихания огромных массивов данных. Она в таком случае будет узким местом.
Помните про коаксиальные сети, где switch не поставить? Вот то же самое будет и в случае передачи больших массивов по системной шине. Методы обхода есть, но они страшно усложнят архитектуру такой шины.
> Помните про коаксиальные сети, где switch не поставить? Вот то же самое
> будет и в случае передачи больших массивов по системной шине. Методы
> обхода есть, но они страшно усложнят архитектуру такой шины.Ок, мой пост был к тому, что проблема от типа данных (текст/бинарные) особо зависеть не должна.
Насчет обхода, ну планировщик и динамические приоритеты, да. Усложнит — да, страшно и неприемлемо — кто знает, надо с выгодами сравнивать.
> Насчет обхода, ну планировщик и динамические приоритеты, да. Усложнит — да, страшно
> и неприемлемо — кто знает, надо с выгодами сравнивать.Я не вижу выгод. А вижу лишь одни проблемы. Если кому-то там надо передать гигабайтный AVIшник, этот кто-то передаёт по шине, что читать надо из /tmp/.pipe_AVI_212412 :
Программа А > всем: Имею гигабайтный файл порнухи. Кто желает, отзовитесь.
Программа Б > А: Хочу.
Программа А > Б: Читай из /tmp/.cool_porno_1
Программа В > А: Хочу.
Программа А > В: Читай из /tmp/.cool_porno_2
Программа Г > А: Хочу.
Программа А > Г: Читай из /tmp/.cool_porno_3Всё. Если нужно что-то более быстрое - пусть открывают прямой канал и посылают сообщения в том же формате.
Текстовый вариант ещё ведь хорош тем, что его можно передавать по ssh, слать между программами в каналах без использования каких-либо системных шин, легко эмулировать человеком.
> Я не вижу выгод. А вижу лишь одни проблемы. Если кому-то там
> надо передать гигабайтный AVIшник...
> Всё. Если нужно что-то более быстрое - пусть открывают прямой канал и
> посылают сообщения в том же формате.Ага. Значит один из триггеров — объем кванта данных. Ок, но ведь а) он не всегда известен; б) проблему можно создать и флудом мелочью.
> Текстовый вариант ещё ведь хорош тем, что его можно передавать по ssh
По ssh и tar-архивы пайпом передают.
> слать между программами в каналах без использования каких-либо системных шин
Чем это плюс само по себе? В кернел-спейс вы при этом все равно данные будете копировать.
> легко эмулировать человеком.
`echo "test" | /tmp/app` или `buscli --msg "test" --target "app"` для шелла, соответствующие библиотечные вызовы для программ. Особой разницы вроде нет. Хоть и не UNIX-way, да, но тут весь топик о типизированных шинах.
> Ага. Значит один из триггеров — объем кванта данных. Ок, но ведь
> а) он не всегда известен; б) проблему можно создать и флудом
> мелочью.Вот отсюда 2 ограничения: 10 сообщений в секунду и 140 символов на сообщение.
>> слать между программами в каналах без использования каких-либо системных шин
> Чем это плюс само по себе? В кернел-спейс вы при этом все
> равно данные будете копировать.Это значит, что будет легко сделать workaround для машин, где этой шины нет.
>> легко эмулировать человеком.
> `echo "test" | /tmp/app` или `buscli --msg "test" --target "app"` для шелла,
> соответствующие библиотечные вызовы для программ.Вот у вас есть языки программировани: Perl, Python, C, C++, Java, Haskell, OCaml, Pascal, Fortran, sh, Tcl и другие. Сколько вам потребуется библиотек? :-)
> Вот отсюда 2 ограничения: 10 сообщений в секунду и 140 символов на сообщение.Ага, и вместо шины в ядре можно вообще использовать twitter. Облачные технологии, все дела... /юмор
> Ага, и вместо шины в ядре можно вообще использовать twitter. Облачные технологии,
> все дела... /юмор;-) Самое смешное тут то, что многие отсоединяют компьютер от сети значительно реже, чем постят в твытыр.
> Ага, и вместо шины в ядре можно вообще использовать twitter.Ну так люди примерно что-то такое и делают :)
Дефолтная - одна - тормозная и вызывающая тот самый конвертер текст->бинарь, что используется в buscli. По производительности будет не хуже варианта "прост шлём текст". Но при желании можно будет для любого языка сделать нативную библиотеку любой степени навороченности. А если формат самих сообщений взять сколько-нибудь поддержанный библиотеками - тот же MessagePack или Protocol BUffers - то соответствующие оптимизированные реализации будут совершенно тривиальны.
>> Ага. Значит один из триггеров — объем кванта данных. Ок, но ведь
>> а) он не всегда известен; б) проблему можно создать и флудом
>> мелочью.
> Вот отсюда 2 ограничения: 10 сообщений в секунду и 140 символов на
> сообщение.Это понятно. Но оно не отвечает полностью на а), и говорит что в б) часть сообщений просто дропнется, без вариантов. В то время как во втором варианте сложного&&производительного сервера оно бы таки пролезло. Пусть медленнее и намного дороже, но дошло бы до получателя. Имхо это серьезный минус.
> Это значит, что будет легко сделать workaround для машин, где этой шины
> нет.А чего "будет" тогда, это ж текущий без-dbus'овый вариант. От которого и пытаются уйти.
> Вот у вас есть языки программировани: Perl, Python, C, C++, Java, Haskell,
> OCaml, Pascal, Fortran, sh, Tcl и другие. Сколько вам потребуется библиотек?
> :-)Одной больше, одной меньше. Не причина, имхо, это ж общая проблема для любой фичи.
Для sh своей библиотеки не надо :-)
> Это понятно. Но оно не отвечает полностью на а), и говорит что
> в б) часть сообщений просто дропнется, без вариантов. В то время
> как во втором варианте сложного&&производительного сервера оно бы таки пролезло.А нужно ли это? Вот в варианте, когда неисправен CD-ROM, сообщающий ложно о своём открытии/закрытии 100 раз в секунду - кому-нибудь это сообщение нужно? Его должен был зарубить уже драйвер привода.
> А чего "будет" тогда, это ж текущий без-dbus'овый вариант. От которого и
> пытаются уйти.Тогда будет совместимость с FreeBSD/Solaris и другими UNIX'ами, где этой Ebus нет.
> Одной больше, одной меньше. Не причина, имхо, это ж общая проблема для
> любой фичи.Ну как это? Писать 20 обёрток или не писать ни одной? Обёртки-то по-хорошему должен писать человек, вводящий шину. Это же не Поттеринг какой-то, а приличный человек.
> Для sh своей библиотеки не надо :-)
Библиотека для sh - это выполняемый файл-утилита.
> А нужно ли это? Вот в варианте, когда неисправен CD-ROM, сообщающий ложно
> о своём открытии/закрытии 100 раз в секунду - кому-нибудь это сообщение
> нужно? Его должен был зарубить уже драйвер привода.Должен был. А как есть вот видим.
Но для этого случая ваш вариант как раз лучше, потерять 90 из 100 одинаковых сообщений не страшно. Хуже когда в этих 90 будет такая же полезная информация, как в остальных 10.>> А чего "будет" тогда, это ж текущий без-dbus'овый вариант. От которого и
>> пытаются уйти.
> Тогда будет совместимость с FreeBSD/Solaris и другими UNIX'ами, где этой Ebus нет.Так опять же, такую совместимость вы можете получить только с давно существующими механизмами. Тогда сабж в любом случае побоку.
>> Одной больше, одной меньше. Не причина, имхо, это ж общая проблема для
>> любой фичи.
> Ну как это? Писать 20 обёрток или не писать ни одной? Обёртки-то
> по-хорошему должен писать человек, вводящий шину. Это же не Поттеринг какой-то,
> а приличный человек.Приличный человек пусть напишет 2-4. Если оно того стоит, то народ растащит без особых проблем.
> Библиотека для sh - это выполняемый файл-утилита.
Которая будет использовать другую библиотеку, уже непосредственно общающуюся с шиной.. Ладно, неважно.
> Разумеется. Но единая системная шина не может быть предназначена для пихания огромных
> массивов данных.Почему она не может выполнять такие функции?
> Помните про коаксиальные сети, где switch не поставить? Вот то же самое
> будет и в случае передачи больших массивов по системной шине.Так и пытаются сделать чтобы и шина была, ибо удобно, и объемы переваривала, ибо надо.
> Почему она не может выполнять такие функции?Из-за простой топологии, единого центра. Из-за того, что тогда придётся реализовывать аналог TCP/IP - гигабайтные данные надо будет бить на пакеты, иначе одно такое сообщение заблокирует центр передачи и всю шину. Ну а принимать пакетами тоже весело.
> Так и пытаются сделать чтобы и шина была, ибо удобно, и объемы
> переваривала, ибо надо.Объёмы переваривать не надо, т.к. для доставки данных от одной программы другой есть масса специально сделанных для этого методов.
> Объёмы переваривать не надо, т.к. для доставки данных от одной программы другой
> есть масса специально сделанных для этого методов.Напоминает - для компьютера достаточно 640к памяти. Делают и хорошо, главное чтобы разработка не стояла на месте. Будет удобно - будут использовать. Окажется шлаком - через 3-5 лет выкинут.
> Напоминает - для компьютера достаточно 640к памяти.Для тех задач было вполне достаточно. Для других задач - нет. Умные люди это понимали.
> Делают и хорошо, главное чтобы разработка не стояла на месте.
Это странный подход. Разработка может ухудшать текущее состояние. Нужно не только, чтобы она не стояла на месте, но ещё и чтобы двигалась в правильном направлении.
> Будет удобно - будут использовать. Окажется шлаком - через 3-5 лет выкинут.
Не выкинут из-за вопросов совместимости. В ядро значительно проще что-то добавить ненужное, чем выкинуть.
>> Делают и хорошо, главное чтобы разработка не стояла на месте.
> Это странный подход. Разработка может ухудшать текущее состояние. Нужно не только, чтобы она не стояла на месте, но ещё и чтобы двигалась в правильном направлении.Понятие "правильное" у каждого свое. И часто заранее не известно будет ли новая технология полезна или наоборот уйдет в утиль. Причем стоит помнить, что все технологии уйдут в утиль. Рано или поздно... вопрос в том, что придет на смену.
То же параллельное программирование было не актуально пока мощь CPU росла. А как уперлись в предел, то технологии CPU свернули в сторону многоядерности. И создание параллелизуемых программ стало актуально.
Также и здесь. Есть кому выгодно развивать технологию - wellcome. А будет ли она востребована - на это ответит эволюционный отбор.
Ну вот навскидку - вполне реально на основе этой штуки будет сделать аналог Jack. Плохо? Собственно, я бы и для юникс (а для TCP - как альтернативу) сокетов с удовольствием увидел бы типизированную замену (либо стандартизированную надстройку), оринтированную на сообщения, а не на поток.
> Ну вот навскидку - вполне реально на основе этой штуки будет сделать
> аналог Jack.Зачем? Если Jack уже есть.
например - с ядерной шиной есть шанс ещё понизить его латентность.
> например - с ядерной шиной есть шанс ещё понизить его латентность.За счёт постоянных переключений контекста и copy_{from,to}_user?
> например - с ядерной шиной есть шанс ещё понизить его латентность.Выставляем из-под root значение nice в отрицательное. И всё. Ну ещё планировщик желательно по-лучше, как в Haiku.
Ужасно доставляют посты вида "если бы я был президентом". Взял бы и сделал форк, если уж так хотелось, а так - псто ни-о-чем.
Неудобство отладки, как и проблема взаимодействия с шелл-скриптами, реашются стандартной утилитой сериализации/десериализации в текст или иное какое подходящее представление. Тут я правда не пойму, почему Виту так за текст борется. Как делаются приличные бинарные протоколы мы со времён создания юникса давно выяснили.Что приятно - там,похоже, достаточно будет поправить эту самую libdbus чтобы сменить внутренний формат сообщений - тот же msgpack смотрелся бы очень неплохо, как мне кажется.
Нонепонятны две вещи:
1) чем им не понравился вариант с AF_BUS, который, как говрит Грег, позовляет to shove tens of thousands of D-Bus messages through their system at boot time, all while using extremely underpowered processors.
2) планирует ли Грег какой-то эффективный мостик из этого ядерного протокола в TCP или ещё какую-то сеть - это вроде бы было бы следующий очевидным шагом - сделать его кластерным.
> Неудобство отладки, как и проблема взаимодействия с шелл-скриптами, реашются стандартной
> утилитой сериализации/десериализации в текст или иное какое подходящее представление.
> Тут я правда не пойму, почему Виту так за текст борется.потому, что тупой и никогда не видел тот же wireshark. Вот в TCP, бяда, не текстовые заголовки в пакетах, ггг
> Как делаются приличные бинарные протоколы мы со времён создания юникса давно
> выяснили.Ну всякие там кобры и прочие сложные IPC уж много лет как известны.
> Что приятно - там,похоже, достаточно будет поправить эту самую libdbus чтобы сменить
> внутренний формат сообщений - тот же msgpack смотрелся бы очень неплохо,
> как мне кажется.
> Нонепонятны две вещи:
> 1) чем им не понравился вариант с AF_BUS, который, как говрит Грег,
> позовляет to shove tens of thousands of D-Bus messages through their
> system at boot time, all while using extremely underpowered processors.
> 2) планирует ли Грег какой-то эффективный мостик из этого ядерного протокола в
> TCP или ещё какую-то сеть - это вроде бы было бы
> следующий очевидным шагом - сделать его кластерным.Да, соглашусь, это бы выглядело крайне разумно. Правда, учитывя броадкасты возможно UDP было бы даже ближе.
> Неудобство отладки, как и проблема взаимодействия с шелл-скриптами, реашются стандартной
> утилитой сериализации/десериализации в текст или иное какое подходящее представление.
> Тут я правда не пойму, почему Виту так за текст борется.Потому, что он предполагает (умышленно), что трафик по этой шине будет мал. А раз так, что никаких объектов и бинарников гнать не нужно. Наоборот, лучше иметь текст, для обработки которого уже сделана масса инструментов.
Про всевозможные wireshark он, конечно, знает. Очередную Corba делать он не хочет, т.к. одна уже есть.
>> Неудобство отладки, как и проблема взаимодействия с шелл-скриптами, реашются стандартной
>> утилитой сериализации/десериализации в текст или иное какое подходящее представление.
>> Тут я правда не пойму, почему Виту так за текст борется.
> Потому, что он предполагает (умышленно), что трафик по этой шине будет мал.
> А раз так, что никаких объектов и бинарников гнать не нужно.
> Наоборот, лучше иметь текст, для обработки которого уже сделана масса инструментов.Охх. Я уже писал - ровно 1 инструмент - дисектор для протокола и все "старые добрые" седы работают. Все, что он написал - это такой вот ужасный, тупой велосипедстрой, единственное достоинство которого - отсутствие реализации. Мне, если честно, пофиг, отлаживать "бинарный" ip или текстовый http, например, поверх него.
> Потому, что он предполагает (умышленно), что трафик по этой шине будет мал.Спасибо, шины задизайненые адептами культа "640K хватит всем" нахрен не упали. Особенно в ядре. Заранее расписываться за всех апликушников - это маразм высшей степени.
> Спасибо, шины задизайненые адептами культа "640K хватит всем" нахрен не упали. Особенно
> в ядре.Зачем она вообще нужна в ядре? Для передачи больших массивов данных от аппликухи к аппликухе есть pipe, есть разделяемая память. Приемущества этих механизмов в том, что они затрагивают только взаимодействующие программы, давно отлажены и работают.
> аппликухи к аппликухе есть pipe, есть разделяемая память.Только проблема в том что
1) А где мультикаст?
2) Формат обмена вообще никак не специфицирован.
3) Как понять что в некоей информации заинтересована не 1 программа а несколько?Собственно шины и придуманы для решения этих проблем. А вот тормозить их - самое идиотское что можно придумать. Читать это напрямую человеки все-равно в общем случае не будут.
Кто не верит - идите почитайте XML жабберовский, с base64-включениями и кучей костылей. И как, очень читабельно? А может вы голыми руками base64 кодировать умеете? Нет? Ну тогда получается что goals удобства отладки не достигнуты, а вот разбор такого уродца требует нетривиального объема ресурсов при интенсивном потоке сообщений.
> Собственно шины и придуманы для решения этих проблем. А вот тормозить их
> - самое идиотское что можно придумать. Читать это напрямую человеки все-равно
> в общем случае не будут.Вы слишком оптимистично смотрите на жизнь. :-( Увы, человекам то и дело приходится отлаживать программы.
>> Читать это напрямую человеки все-равно
>> в общем случае не будут.
> Вы слишком оптимистично смотрите на жизнь. :-( Увы, человекам то и дело
> приходится отлаживать программы.Отладка общим случаем использования не является :-)
> Отладка общим случаем использования не является :-)Нет, но чем она проще, тем лучше. Плюс, в сценарии использования "медленная шина для редких событий" никаких особых приемуществ от бинарной формы нет.
> Нет, но чем она проще, тем лучше.В такой формулировке да, но имхо всё, что не требует отдельных аппаратных средств (от другой машины до JTAG) и чтения ассемблера, уже нормально. В модуль выделят и покатит.
> Плюс, в сценарии использования "медленная
> шина для редких событий" никаких особых приемуществ от бинарной формы нет.В этом случае да.
> В модуль выделят и покатит.И получим геморрой при связывании с языками, отличными от С, вернее, того языка, на котором написан модуль. А если это исполняемая программа, плохо будет везде, кроме sh.
> И получим геморрой при связывании с языками, отличными от С, вернее, того
> языка, на котором написан модуль. А если это исполняемая программа, плохо
> будет везде, кроме sh.Имел в виду модуль ядра. Сисколлы дергать и в /proc | /sys лазить все более-менее умеют. Юзерспейсный вариант — это ж то, что уже есть.
> Имел в виду модуль ядра. Сисколлы дергать и в /proc | /sys
> лазить все более-менее умеют.Уже даже для системного языка, в данном случае - С, делают обёртку в виде libc. В остальных языках тем более придётся делать обёртку.
> Уже даже для системного языка, в данном случае - С, делают обёртку
> в виде libc. В остальных языках тем более придётся делать обёртку.Так вроде жалоб немного. Да и без оберток можете сисколл сами вызывать, а тем более псевдоФС читать, если хочется. С обертками просто удобнее.
> Нет, но чем она проще, тем лучше.Ставить отладку во главу угла - маразм, извините. Вы так говорите как будто целью существования шины является удобная отладка. А не собственно нормальная работа. Вон жаббер уже сделали, спасибо. Теоретически его отлаживать как бы проще, а практически - проблемы совместимости и нестыковки - это его фирменное проклятие.
1) читайте спецификацю к netlink
2) формат обмена стандартизирован - да и в любом случае получатель должен знать что читает.
3) а какое до этого дело отправителю? тем неменее - в netlink есть возможность узнать количество народа в группе получателей.
ебус нетипизированный. Что сразу лишает горы метаинформации о сообщениях (в том числе - верификацию корректности формата сообщений каким-нибудь промежуточным софтом) и и сильно роняет производительность.
> ебус нетипизированный. Что сразу лишает горы метаинформации о сообщениях (в том числе
> - верификацию корректности формата сообщений каким-нибудь промежуточным софтом) и и сильно
> роняет производительность.Я Вас не понял. Объясните, что ль.
Одно дело, когда у нас летит нетипизированное "что-то", понятное только отправителю и получателю. Другое - когда у нас определен формат сообщения каким-то IDL, тогда можно над эти сообщением что-то сделать - запротоколировать, выбрав по каким-то критериям, подправить, сделать аналог файрволла, посчитать статистику сообщений разных типов и тому подобное. В общем, получаем много более управляемый поток. А можно и круче (чего в d-bus нет) - сделать более сложный idl, в котором можно будет, скажем, указать, что такое-то поле должно указывать на реально существующий и доступный получателю файл, такое-то - соответствовать такому-то регэкспу, и так далее... И тогда можно генерировать код прямо с проверкой валидности, которую иначе придётся писать руками. А обработка потока чем-то промежуточным (грубо говоря, аналог iptables) станет ещё удобнее.
> Другое - когда у нас определен формат сообщения каким-то IDL,
> ...
> А можно и круче (чего в d-bus нет) - сделать более сложный idl, в котором можно будет, скажем, указать, что такое-то поле должно указывать ...Как Вы думаете, почему же тогда Corba (которая спроектирована сильно лучше, чем COM/DCOM) таки не пользуется популярностью?
Сложность концепций и паршивая скорость. Но это не значит, что надо впадать в противоположную крайность и делать совсем уж примитив.
> Общая шина конечно же нужна, другое дело, что все попытки ее создать - не очень-то хороши. Вообще говоря, наиболее адекватной шиной мне кажется проект ебуса, продложенный Вагнером.NETLINK существует уже лет 20. им кто-то пользуется? поддерживет как мультикаст - так и unicast сообщения. Оттестирован. доступен как из userland (через сокет) - так и в ядре. Но не используется.. почему?
Ну не знаю, мне кажется что это может обернуться для линукса тем же, чем обернулось для майкрософта включение NetBios в состав их ядра, а именно - валящийся сервис (который "сервис" только на словах так - часть ядра) валил ядро.
Грег Кроа-Хартман может гарантировать что код DBUS идеален ? :)
Во всяком случае на сервера такую версию ядра лучше не ставить.
> Во всяком случае на сервера такую версию ядра лучше не ставить.это ты опасаешься что на сервере у тебя появился вдруг неудержимый соблазн использовать программы, которые будут задействовать этот новый механизм IPC ? :)
# P.S.: если не понял намёк, то даю подсказку: ядро Linux является модульным (обычно собрано как модульное) , и неиспользуемые модули просто даже могут так и не подгрузиться!
Вообще-то, в идеале на сервера заливается монолит без поддержки загрузки модулей. А D-Bus в текущем виде больше напоминет костыль и необходимость оного на сервере более, чем весьма, сомнительна
> в идеале на сервера заливается монолит без поддержки загрузки модулейу меня на десктопе такое, ) в идеале на [всех компах] заливается ядро linux, монолит без поддержки загрузки модулей
> D-Bus в текущем виде больше напоминет костыль и необходимость оного на сервере более, чем весьма, сомнительнакак бы зачем оно и на десктопе..(?
Ну да, ну да, фтыкаем в USB на десктопе новую камеру, гаджет и... опаньки. Чтобы оно завелось, извольте ядро заново пересобрать. На десктопе это ну офуенно удобно, да.
каждый день покупаете новую камеру? Ну да, ну да))
У нормальных людей есть родственники, друзья, знакомые. У тебя их может и не быть, но мир на тебе не заканчивается и вокруг тебя не крутится.
> каждый день покупаете новую камеру? Ну да, ну да))Я как-то так думал что машины нужны чтобы разгрузить людей от рутинной работы. В том числе, от работы по детектированию "а что это воткнул юзер?". Поскольку шины процессору виднее чем мне - пусть он и вкалывает по детектированию того что там навешано.
Приходит друг, приносит видяху:
- Слу, можешь мою видуху проверить? Не пойму, почему у меня моник ничё не показывает...
- Конечно, братан, сейчас только ядро пересоберу. :)
> Приходит друг, приносит видяху:
> - Слу, можешь мою видуху проверить? Не пойму, почему у меня моник
> ничё не показывает...
> - Конечно, братан, сейчас только ядро пересоберу. :)И так каждый день, да по нескольку раз на дню... реальный случай из жизни (рука_лицо.жпг)
Умному человеку хватит одного такого случая, чтобы осознать ущербность подхода. Идиотам наверное действительно нужно, чтобы такое происходило по несколько раз в день, по другому до них не доходит.
Действительно умный человек делает следующее:1. Имеет для загрузки второе "обычное нормальное" ведёрочко
2. Имеет вторую линуксовую систему в дуалбуте, на всякий случай
3. Имеет даже венду в дуалбуте, тоже на всякий случай, ибо хоть и пользует в основном линукс, но Столлман его не покусал.
4. Имеет live-cd или live-dvd или live-usb и грузится в случае надобности с нихМногие имеют комбинацию этих четырёх вариантов, а особо продвинутые АППК ( анонимные пользователи персональных компьютеров ) имеют все эти штуки.
Так шта сиди, Angra, и выбирай себе на вкус и цвет.
> Действительно умный человек делает следующее:
> 1. Имеет для загрузки второе "обычное нормальное" ведёрочко
> 2. Имеет вторую линуксовую систему в дуалбуте, на всякий случайИ дрочится в 2 раза больше с поддержкой оных. Нафига?
> 3. Имеет даже венду в дуалбуте, тоже на всякий случай,
И платит биллу за лицензию? Пардон, линукс вполне полноценная операционка, ничем не хуже остальных. В свете чего я не вижу смысла платить биллу и ко 100 баксов за лицензию. А качать варез с черти-каких помоек мне еще менее охота.
4. Нормальный человек давно уже перешел на флешки. Они механически более прочные - не боятся царапин в разумных пределах и залапывания пальцами. И умещаются в карман.
Меня тут скорее Столлман покусал, но какая поддержка нужна системам "для проверить"? Там скорее наоборот лучше ничего не трогать от дефолта.
> И дрочится в 2 раза больше с поддержкой оных. Нафига?Дорогой брат Аноним, поставь себе уже нормальный дистрибутив с которым не надо "дрочиться", а достаточно просто запускать обновления.
> И платит биллу за лицензию? Пардон, линукс вполне полноценная операционка, ничем не хуже остальных. В свете чего я не вижу смысла платить биллу и ко 100 баксов за лицензию. А качать варез с черти-каких помоек мне еще менее охота.
В 99,99% случаев имеется "искаропке" при покупке компа, дополнительные траты не нужны. Только пожалуйста не начинай размазывать тему о том как ты сам собрал себе комп или получил таки свою "пятнаху" после двух лет хождения по сервис-центрам и переписки с производителем - это обычно навевает скуку и соответственно вызывает зевоту.
> 4. Нормальный человек давно уже перешел на флешки. Они механически более прочные - не боятся царапин в разумных пределах и залапывания пальцами. И умещаются в карман
Глаза разуй и читай что написано было: "live-usb". Это как раз и есть они самые - "флэшки".
> Дорогой брат Аноним, поставь себе уже нормальный дистрибутив с которым не надо
> "дрочиться", а достаточно просто запускать обновления.Ну вот это я и сделал. На самый крайний случай у меня флешка есть. Она и загрузочная и инсталляционная. Нафига при этом еще какой-то дистр и винды? Если я допустим в процессе экспериментов воткну небутабельное ядро - чертыхнусь и выберу в меню grub-а предыдущее ядро. И все.
> В 99,99% случаев имеется "искаропке" при покупке компа,
Я сам себе комп под свои требования собрал. И при покупке ноута мне было западло платить лишние 2500 дяде баллмеру за крап которым я пользоваться не буду. Вот такой вот я нехороший.
> сам собрал себе комп или получил таки свою "пятнаху" после двух
> лет хождения по сервис-центрам и переписки с производителем - это обычно
> навевает скуку и соответственно вызывает зевоту.Не знаю какую там пятнаху кто получил, а модель моего нотика без винды стоила на 2.5 килорубля дешевле при прочих равных. Нет, по легенде, давным давно, у меня была в дуалбуте винда XP. И диски в NTFS. А потом я понял что линукс - вполне полноценная операционка и сам по себе. А NTFS сделанный через FUSE к тому же еще более тормозной чем оригинальный. Поэтому все это было нафиг повыпилено. И с тех пор уже лет пять как у меня на винте только линь. Каких-то проблем по этому поводу лично я не имел. Если ну ооооочень надо запустить какую-то виндовозную программу - ну, вайн наконец есть. Но у меня как-то проще получилось - на весь софт накопались открытые аналоги. Даже вон KiCad - вполне себе нормальный cad для электронщиков. И не надо тырить варезок, опасаясь вирья в кряках или платить конские бабки. Очень удобно, между прочим.
> Глаза разуй и читай что написано было: "live-usb". Это как раз и есть они самые - "флэшки".
Ох, сникерсу мне. Что-то я торможу.
Странно. Я когда пользовался форточками ни разу за них не платил. Чего и другим желаю.
> Странно. Я когда пользовался форточками ни разу за них не платил.С таким же успехом можно хвастаться что ты батон хлеба в супермаркете утащил незаметно для охраны. Правда вот это в результате приводит к усилению охраны и серьезным пи...лям в случае поимки. Ну вот и с виндой аналогично. Привело к предустановке на большинство ноутов и секурбутам всяким, чтоб уж точно заплатили, канальи.
Форточки лучше запускать через virtualbox. Впрочем, уменя их вообще ни в каком виде нет.
На такой случай вторым ядром может быть generic, но грузиться постоянно с ним совершенно необязательно. У меня, вон, пять ядер себе живут, из них три самосбора. На все случаи жизни. Благо, меню в згрузчике давно придумали. Зато никакой мороки с initrd.
Вот это уже разумный подход, но большинство фанатиков оптимизации до такого не додумываются.
> У меня, вон, пять ядер себе живут, из них три самосбора. На все случаи жизни.=)
Почти как в вендовс: подключил железку -- два раза ребутнись, один раз просто так, второй раз, после установки драйвера, чтобы этот драйвер подгрузить. Правда в вашей ситуации, я полагаю, достаточно одного ребута, и устанавливать уже ничего не требуется.> Зато никакой мороки с initrd.
А iniramfs и модульность ядра -- это несколько перпендикулярные вещи.
Я, например, столкнувшись с проблемами описанными выше, оставил статически вкомпилированным в ядро, во-первых, необходимый для загрузки минимум (поддержка SATA, файловых систем, текстовую консольку 80x25), во-вторых, немножко generic драйверов, на случай если я жёсткий диск переткну в другой компьютер, ну и в-третьих то, что мне просто захотелось иметь в ядре всегда. При этом я выкинул из ядра в модули всякие файловые системы кроме ext, драйвера всех usb-устройств, драйвера сенсоров... в общем выкинул всё, что используется не постоянно, от случая к случаю. А, ну да, и драйвера на сетевые карты с видеокартами я храню в виде модулей. Но это исторически так сложилось. С какой-то сетевушкой я просто проблем огрёб -- там драйвер отказывался работать, если ему не сделать modprobe. А видео... Мне честно говоря лень собирать два ядра под разные драйвера видеокарты.Такое ядро, несмотря на то что модульное, в состоянии без всякого initramfs смонтировать корневую фс и добраться до /lib/modules, чтобы взять оттуда все драйвера необходимые для полноценной работы системы.
initramfs у меня лежит, единожды собранный, но без модулей, так, на всякий случай. initramfs совершенно бесполезный при нормальной загрузке и, поэтому, даже не упомянутый в menu.lst.
Для случаев "товарищ принёс видеокарту" ребут неизбежен. А для всего моего оборудования всё в самосборе уже есть. И зачем мне морочить голову с инитрд, если я всё равно делаю самосбор? Проще вкомпилировать всё нужное намертво. Впрочем, модули всё равно используются - тот же виртуалбокс, например, да и то, что не используется, я не отключаю, а именно в модулях держу за исключением совсем уж экзотики. Но если что-то будет нужно сравнительно часто - запихну в ядро когда буду на следующее апгрейдиться.
> Зато никакой мороки с initrd.А какая с ними "морока"? Хотя, у гентушников...
> Зато никакой мороки с initrd.В нормальных дистрах "мороки" с ним ровно ноль. А почему с ним должна быть какая-то морока вообще?
> Приходит друг, приносит видяху:
> - Слу, можешь мою видуху проверить? Не пойму, почему у меня моник ничё не показывает...
> - Конечно, братан, сейчас только ядро пересоберу. :)загрузить generic ядро; загрузить инквизитор/любой другой live; не засовывать запанибрата разный глючный хлам в свою машину; вообщем чушь.
А ради чего весь этот лишний прыгот с бубном? Чтобы полметра памяти модулями сэкономить? Проще сделать проверку на вшивость и пару программ на питоне вышвырнуть - сразу в 10 раз больше эффекта будет.
> А ради чего весь этот лишний прыгот с бубном? Чтобы полметра памяти модулями сэкономить?собираю модульное ядро, в тоже время никогда не сталкиваюсь и незаинтересован, например, в wi-fi, а теоретически возможное и допустимое включаю модулями, полгода как избавился от необходимости в закрытых видеодрайверах, счастливо использую вещи, которые не входят в generic optimizations, вообщем вполне доволен.
> Проще сделать проверку на вшивость и пару программ на питоне вышвырнуть - сразу в 10 раз больше эффекта будет.не уловил взаимосоответствия между программами на питоне и phthiraptera, опять какие-то optimizations непонятные, так можно дооптимизироваться до маразма.
> собираю модульное ядро,Это не ответ на мой вопрос. Какая конечная цель всего этого? Что приобретается ценой потери времени на данные операции?
> в тоже время никогда не сталкиваюсь и незаинтересован,
(и русский язык не учили в школе, ай-яй-яй)
> например, в wi-fi,
Если у меня нет карты вайфая - ну, не загрузится модуль для нее в оперативку. А то что там лишние 100Кб на диске - так и фиг бы с ними, пожалуй. Если мне на десктопнике захочется место расчистить - есть уйма очевидных методов получить намного больший выигрыш с намного меньшими трудозатратами. Такое еще может быть актуально в мелких железках где каждый килобайт на счету, но это явно не ваш случай, как я понимаю.
> а теоретически возможное и допустимое включаю модулями, полгода как
> избавился от необходимости в закрытых видеодрайверах,Всего полгода? Они уже несколько лет как вполне юзабельны. Даже чтобы поиграть в не очень навернутые 3D игры. Более того, совсем уж юзерская убунта много лет как поставляется по дефолту с открытыми драйверами :). С закрытыми дровами вообще головняк какой-нибудь постоянно приключается. И что характерно - пофиксить его майнтайнеры не могут. А до разработчиков амд и нвидии - под там еще доорись. У них даже багтрекеров нормальных нету.
> счастливо использую вещи, которые не входят в generic optimizations,
И что это вам дает на практике? Ну, кроме +5 к ЧСВ? :)
> вообщем вполне доволен.В общем то это главное.
> не уловил взаимосоответствия между программами на питоне и phthiraptera, опять какие-то
> optimizations непонятные, так можно дооптимизироваться до маразма.Не очень в курсе что есть "phthiraptera" (раскладка неверная?), но зато в курсе что обычно если зудит что-то отоптимизировать - проще начать с обкусывания юзермода. А то получается как в песенке про мельника - "он истратил шиллинг, заработал грош".
> Какая конечная цель всего этого? Что приобретается ценой потери времени на данные операции?безотказное условно минималистическое окружение без излишеств, которое не повиснет при выходе из X, не потеряет данные, оставит ресурсов для, собственно, юзерской активности, не доставит негативных эмоций ни мне ни родным, и, поскольку я простой юзер, то достичь такого эффекта могу лишь перекомпоновкой ядра и окружения.
> Если мне на десктопнике захочется место расчистить - есть уйма очевидных методов получить намного больший выигрыш с намного меньшими трудозатратами.если очевидные - значит проходили, либо методы разные.
> "он истратил шиллинг, заработал грош".для меня это отдохновение, вылавировать к открытому и безотказному десктопу, как упражнение, повышает мой оптимизм.
Отключение модулей дает +10 к безотказности и +5 к условной минималистичности.
Экий бред.
учите-учите. в сумме методы упрощения структур ядра и конкретная политика в компоновке укорачивают векторы нестабильности.
> безотказноеЧем докажете что оно у вас более безотказное чем у других?
> условно минималистическое
Это как? вот я например билданул образ опенврты. Вышло менее 3 метров. Вот это я понимаю, конкретный такой минимализЪм. А ваша хренота с кучей питонятины и чем там еще - не слишком то и минималистична на фоне таких хардкорных экспонатов. Но там я понимаю нафиг это надо. А вот у вас - не совсем. Там когда система взлетает с NOR флехи на 4Мб и больше памяти в системе нет + RAM мало - минимизация системы внятный смысл имеет. А не является самоцелью без аргументации "а нафига?".
> окружение без излишеств,
Это не является багом или фичой, вкусы у всех разные. И минималистичных окружений есть навалом. Почему это считается за достоинство у лично вас?
> которое не повиснет при выходе из X,
Это, типа, достоинство? А что, остальные - виснут? И вообще, нафига на десктопе кто-то будет из иксов вываливаться? На мое мнение это очень странное "достоинство", скажем прямо.
> не потеряет данные,
А что, другие - теряют? Чаще и больше? А обосновать - что у них в архитектуре такого что у них данные теряются, а у вас - нет?
> оставит ресурсов для, собственно, юзерской активности,
Это точно про генты, где вечно все из сорцев норовят пересобрать, прогрузив под завязку мощный проц на несколько часов, т.к. пересобирают всякие немеряные браузеры/офисы/... ?
> не доставит негативных эмоций ни мне ни родным,
А у вас в системе какой-то особый софт? Там магическим образом пропадают баги которые есть у других? Обычно все это доступно всем у кого под руками есть пряморукий системщик. А какая там ОС будет - не так уж и принципиально, если системщик пряморукий. Вот системщику правильный выбор системы может сильно скостить время на долботню с ней, это да. Так что при правильном подходе новый комп кому-нибудь запускается с нуля за полчаса, а не 2 дня прыга вокруг компа.
> и, поскольку я простой юзер, то достичь такого эффекта могу лишь перекомпоновкой ядра и окружения.
Простые юзеры страшно далеки от пересборки софта. Если вы можете пересобрать софт - вы уж точно не "простой юзер". Ну так же как человек способный успешно удалить апендицит - таки не только гражданин, но еще и какой-никакой хирург.
> если очевидные - значит проходили, либо методы разные.
Просто на десктопнике экономить вообще каждый бит на данный момент смысла особо не имеет. Это не значит что надо сорить ресурсами, однако обкусывание едва ли считанных единиц мегабайтов модулей - явно не то место где имеет смысл экономить.
> для меня это отдохновение,
Ну так бы сразу и сказали что вам нравится копаться в кишках системы.
> вылавировать к открытому и безотказному десктопу, как упражнение, повышает мой оптимизм.
А мне нужен работающий десктоп не преподносящий сюрпризов. Вот еще - лавировать среди мин как корабль под обстрелом. И таки да, работоспособных из коробки линуксов нынче есть. На все вкусы и размеры. Возможно, вам не нравится изкоробочность. Ну, это бывает. Но каким-то достоинством само по себе оно не является. Ну то-есть умение делать что-то своими руками и не потребццтвовать - это похвально. Если результат чем-то лучше других получается.
я ведь не экспандирую свой жалкий опыт на чужой десктоп, зачем этим занимаются другие мне не до конца понятно.
>Вообще-то, в идеале на сервера заливается монолит без поддержки загрузки модулей.Наверное ТруЪАдмины, в отличие от простоАдминов, не знают, что уже давно есть /proc/sys/kernel/modules_disabled.
> /proc/sys/kernel/modules_disabled.ды неее -- мне кажется что /proc/sys/ -- тут не причём..
просто сам процесс перекомпиляции (выставление конфигурационных галочек вручную) -- добавлет очков чуства собственной важности :)
> очков чуства собственной важности :)Вы их раскусили!
расскажи ето нам когда будешь конпелять идро для 100-500 одинаковых серверов
> Вообще-то, в идеале на сервера заливается монолит без поддержки загрузки модулей. ...а кстате, можно поинтересоваться -- речь идёт случайно не про те ли самые сервера, ядро на которых не обновляется долгими периодами, оставляя безопасность в Ж^Wнеприорите
???
Это будет не страшнее сокетов. Собственно, D-bus часть будет в юзерспейсе, в ядре окажется в оснвном диспетчеризация.
имхо, selinux в ядре не нужен, однако это им не помешало его включить в ядро
> имхо, selinux в ядре не нужен, однако это им не помешало его
> включить в ядроSelinux вообще-то реализован как подсистема ядра,следящая за деятельностью userspice
процессов.
> В рамках проекта предлагается обеспечить внутри ядра поддержку надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений как в мультикаст режиме (от одного отправителя к группе получателей), так и в режиме точка-точка.Короче, делаем микроядро, только через попу?
В каком месте оно вдруг станет микроядром?
> В каком месте оно вдруг станет микроядром?Это шутка была. Оно станет макроядром с пересылкой сообщений.
Если даст нормальную скорость - то это надежда сделать существенно более модульную систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.
> Если даст нормальную скорость - то это надежда сделать существенно более модульную
> систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый
> что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.В ядро-то на кой?
Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не как на "полтора сообщения в секунду прокинуть", а как на легковесную корбу какую.Но на самом деле я радуюсь потому что оно в некоторыемои идеи о десктопе очень хорошо укладывается :-)
> Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не
> как на "полтора сообщения в секунду прокинуть", а как на легковесную
> корбу какую.Видите ли, то, что пишет Витус, очень хорошо укладывается в идеологию UNIX - текстовые сообщения, склейка скриптами, усё есть файл. При этом эта системная шина уже не является чем-то, что должно поддерживать высокий трафик. Если хочется что-то серьёзное передать, делается pipe между программами, и вперёд.
Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что не нужно отправлять сообщения о вставленной флешке раз в 10 микросекунд. Её трафик оценивается, как трафик файла /var/log/messages - то, что можно прочесть.
> Но на самом деле я радуюсь потому что оно в некоторыемои идеи
> о десктопе очень хорошо укладывается :-)Сама концепция UNIX безнадёжно устарела. Система UNIX построена на портабельном ассемблере - языке C. Сейчас прошли две "революции" - появление в mainstream объектно-ориентированных языков и функциональных. Вы хотите объектную шину, поддерживающую серьёзный трафик, в том числе и broadcast, при этом берёте "старую" ОС. И, естественно, эта шина выглядит как на корове седло.
Нужно менять ОС - тот же Ведроид уже объектен, там такие типизированные шины будут в дугу. А по-настоящему общеупотребительной функциональной ОС ещё нет, будем ждать.
>> Для шустрости и возможности сделать хорошее управление доступом. Смотри на это не
>> как на "полтора сообщения в секунду прокинуть", а как на легковесную
>> корбу какую.
> Видите ли, то, что пишет Витус, очень хорошо укладывается в идеологию UNIX
> - текстовые сообщения, склейка скриптами, усё есть файл. При этом эта
> системная шина уже не является чем-то, что должно поддерживать высокий трафик.
> Если хочется что-то серьёзное передать, делается pipe между программами, и вперёд."Идеология юникс" - она, суко, разная. И тот же SSH, или даже ESC последовательнсоти в телнете - отнюдь не текстовые. Как и тысячи других "традиционных" юникс решений и протоколов.
> Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что
> не нужно отправлять сообщения о вставленной флешке раз в 10 микросекунд.
> Её трафик оценивается, как трафик файла /var/log/messages - то, что можно
> прочесть.Через тот же uevent в мобильных устройствах часто проходит немаленький поток. Разбирать текст просто потому, что кто-то ниасилил дисекторы в 21 веке - немного странно.И тем более странно предлагать шаг назад (да еще и овер х11, п..ц!) в 21 веке. Повторюсь - в этой затее хорошо только отсутствие реализации, так что никто кроме читателей уютненького это не оценит, гг.
> - текстовые сообщения, склейка скриптами, усё есть файл.То-то в юниксах даже логи помнится были бинарными. "Все есть файл" != "все есть текстовый файл". Более того - передавать большой массив данных текстом как бы редкостное порно. А иногда оно может быть надо. HTTP вон уже сделали, теперь не знают как разделать в нормальный вид, извращаются вон с всякими data: (куча base64 кодированного фуфела). Руки обрывать за такие инициативы. Желательно вместе с головой.
В конце концов. вот есть gzip. Вам сильно мешает жить что он бинарный? Ах, есть прозрачная утилита которая спокойно расжимает его? Так что даже скрипты могут гзипнутые логи жрать? Ну вот и получается что бинарные данные ничем таким не плохи. При правильном подходе к делу, разумеется. А вот во сколько раз сдувается гзипнутый лог - думаю понятно. Давайте расскажем о том что все кто сжимает логи, превращая их в бинарный мусор - делают это неправильно? :)
> То-то в юниксах даже логи помнится были бинарными. "Все есть файл" !=
> "все есть текстовый файл". Более того - передавать большой массив данных
> текстом как бы редкостное порно.Проблема логов в том, что их периодически нужно читать. И если в логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных, читать придётся терабайты.
Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет думать, что писать в логи, а что - нет.
> Проблема логов в том, что их периодически нужно читать.Wrong. На самом деле их надо не "читать" а "анализировать". Это еще IBM сформулировал: "Машина должна работать, а человек - думать". Вы же предлагаете свалить машинную работу на человека. Ужас!
Если стоит сервак который держит приличную нагрузку, немеряные портянки логов на нем - просто данность. Ну, если запросов много - значит и логов от них много. Более того - это внешний фактор, админу он не подконтролен. Значит даже absolute worst case, когда кто-то целенаправленно пытается зафлудить логи не должен вызывать никаких проблем. Иначе сервак уронит первый же мальчиш-плохиш, которому что-то не нравится. Нафига такое счастье?
> И если в логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных,
> читать придётся терабайты.Именно читать втупую логи - удел дураков, уж простите. А нормальные люди логи анализируют по критериям. И гигабайты резко превращаются в килобайты, а миллионы запросов - в десятки наиболее интересных записей.
А зачем мне читать вообще ВСЕ запросы? Логи изучают по поводу тех или иных проблем или происшествий. Ну так вот и должна быть возможность оперативно выцепить куски представляющие интерес.
Вся эта текстовая дребедень в этом плане очень проблематична. Чтобы просто выцепить "все запросы за вчера, от 00:51:05 до 00:52:18" надо как минимум сделать полный проход по немеряной портянке текстового лога и проскипать все не относящееся к нужным критериям. Портянка будет немелким кусом за период ротации логов. И если с датой еще можно попытаться хоть как-то соптимизировать, допустив что лог линейный и монотонный, то например с хотелкой вида "а вот дать мне все обращения с этого айпишника за последний месяц" так уже не катит. Там будет кондовый полный проход по вообще всем логам за этот самый месяц. Который займет немеряно времени в случае нагруженного сервака. И админ будет как дебил ждать выполнение машинной работы машиной.
> Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет
> думать, что писать в логи, а что - нет.А велопривод в качестве тягловой силы для самолета заставляет инженеров на ушах стоять по поводу максимальной легкости конструкции и рекордной эффективности в ущерб вообще всему остальному. По каким-то таким причинам, самолеты приводимые в движение мускульной силой и являются редкими экзотичными экспонатами, на грани научных курьезов.
> Если стоит сервак который держит приличную нагрузку, немеряные портянки логов на нем
> - просто данность.А если десктоп, то его логи придётся именно читать. Зато крайне редко. :-)
> А если десктоп, то его логи придётся именно читать. Зато крайне редко. :-)Ну да, у вас как-то так удобно придумано что вот лично ваш частный случай оно будет окучивать, лично вам будет удобно, а там хоть трава не расти. Вот по какому-то такому поводу оно и будет (если вообще будет) только у вас в системе. И да, не хочу вас расстраивать но вот прожка есть. На десктопе. А 20 Мб логов за 2 часа она таки генерит. Как вы думаете, если ее оставить работать недельку - приятно ли мне будет потом искать что-то в этих логах? Да, разумеется на десктопе в отличие от сервера нет ротатора логов, особенно знающего что-то там о каких-то прожках.
> И да, не хочу вас расстраивать но вот прожка есть. На десктопе. А
> 20 Мб логов за 2 часа она таки генерит.Это значит, что она, скорее всего, неправильно устроена.
> Это значит, что она, скорее всего, неправильно устроена.Этот мир вообще "неправильно" устроен, от и до. Вон на википедию прутся сотни миллионов леммингов. Неизбежно генеря адскую прорву логов. Вместо того чтобы приходить по сто штук в день, выстроившись в многомесячную очередь за счастьем. И вот так - в любом нагруженном сервисе. Случай когда просто лог создает даже просто неприемлимо много нагрузки на диск - вполне обычная ситуация в нашем реальном мире. Прикиньте, активность от логинга может быть сравнима или превышать полезную активность. А вы предлагаете в этот вентилятор еще лом воткнуть дополнительно...
>> Это значит, что она, скорее всего, неправильно устроена.
> Этот мир вообще "неправильно" устроен, от и до.Так вот "текстовые логи" тем и хороши, что "дурь каждого становится видна". В таком случае есть шансы, что человек сразу заметит, что что-то идёт не совсем так, если программа слишком много протоколирует.
> И вот так - в любом нагруженном сервисе. Случай когда
> просто лог создает даже просто неприемлимо много нагрузки на диск -
> вполне обычная ситуация в нашем реальном мире.Почему он неприемлимо много даёт нагрузки? Нет ли тут слишком сильной непродуманности системы протоколирования, которая записывает незначимые события? Помните "You mouse position has changed. Press OK to reboot."
Всё-таки, программа должна выполнять, в основном, свою главную цель. А протоколирование выполнения в неё никак не входит. Может быть просто она откомпилирована не в release вариант, а в debug?
> Так вот "текстовые логи" тем и хороши, что "дурь каждого становится видна".Я все-таки не понял: вы таки против гзипования логов? Файл то получается бинарный - в текстовом виде данные для LZ+Huffman не очень удобно передавать. Но я так понимаю что хранение лога в сжатом бинарном файле при всем этом претензий не вызывает? Т.е. по большому счету - это лишь вопрос доступности утилит для прозрачной работы с форматом. В том числе - возможности пайпинга в другие программы.
> В таком случае есть шансы, что человек сразу заметит, что что-то
> идёт не совсем так, если программа слишком много протоколирует.Странный человек который сам лично окарауливает логи. Там где это кого-нибудь волнует - давно вкалывают автоматические системы мониторинга. Что вообще за мания - спихивать на человека рутинную работу? А машины для чего?
> Почему он неприемлимо много даёт нагрузки? Нет ли тут слишком сильной непродуманности
> системы протоколирования, которая записывает незначимые события? Помните
> "You mouse position has changed. Press OK to reboot."Ну да, все можно довести до маразма. В таких случаях уместнее трассировщик, профайлер и деьагер. Но опять же - возможны варианты. Вот глючит сетевая утиля раз в неделю. Не будете же вы ее с дебагером караулить столько? А если просто бряк поставить - ну, она завалится туда. А вы допустим спали. Ну и отвалится ремота по таймауту, и вообще. И когда вы это увидите - картина будет уже не та которая привела к глюкам. В этом случае таки вариант заюзать вербозный логгинг, вплоть до packet-level tracing. Диски нынче большие.
Тем не менее, если хост отгружает допустим много мелких файлов, для него вообще нормально много писать в логи. Доходит до того что лог ведут по этому поводу на ремотном сервере. И как-то идея в несколько раз увеличивать объем записи на диск, сетевой траффик и прочая - достаточно спорные. Опять же, автоматические анализаторы потребуют более сложный и тормозной парсер.
Так что лично я ничего не имею против бинарных логов, если это дает плюсы. При одном условии. Должны быть описание формата + утилиты и библиотеки для работы с оным. Ну, как с gzip/deflate. Разумеется с исходниками. Тогда оно никаких проблем не вызывает.
> Всё-таки, программа должна выполнять, в основном, свою главную цель. А протоколирование
> выполнения в неё никак не входит. Может быть просто она откомпилирована не в release вариант, а в debug?В совсем культурных программах это даже настраивается в рантайм. И намного хуже если надо понять что отвалилось а вербозности логов не хватило. Придется как минимум возиться с пересборкой, а если совсем не повезло - самому дописывать недостающие логи. Ну и гадостное же это занятие, скажу я вам. Приходилось несколько раз так делать - гемор конкретный. По уму это автор программы должен делать. Ему это в 20 раз проще - он уже кишки своей программы знает. А мне приходится "с места в карьер" вкуривать что и как.
Тем не менее, повторяю, например элементарный HTTP сервер, отдающий статику в нагруженном проекте - генерит прорву логов в совершенно штатном режиме. Это его нормальное состояние. И это вполне типовой юзкейс пингвинов, кроме всего прочего.
> Проблема логов в том, что их периодически нужно читать. И если в
> логи писать терабайты текстов, умело сжимая их до гигабайтов бинарных данных,
> читать придётся терабайты.Читать вам при прочих равных придется одно и то же, что текст -> gzip -> zgrep, что бинарник -> анализатор с нужным фильтром. Вот машина при этом выполнит разную работу, это да.
> Поэтому текстовый формат хорош тем, что из-за определённых ограничений заставляет думать,
> что писать в логи, а что - нет.Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не хочет, не делает это и с текстом.
> Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не
> хочет, не делает это и с текстом.Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять высоты. :-)
>> Есть предложение не гнать кнутом в светлое будущее :-) Кто думать не
>> хочет, не делает это и с текстом.
> Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять
> высоты. :-)Увольте, free software for free people! :-)
Вообще пусть покоряет, только чтобы эти стимулы не приводили к безрезультатным NIH, 15му стандарту и 5му форку. Хотя тут "а судьи кто", поэтому оставим.
> Это вы зря. Как известно, ограничения стимулируют творческий ум, позволяя ему покорять высоты. :-)Вот только анализ большого объема логов в таком формате будет неизбежно связан с костылестроением.
Ну так и у меня в глове объектность. А юникс - я ж специално указал - я не о "всё есть файл и текстовые сообщения", а о компонентности, когда задача решается комбинацией специфических инструментов. В этом плане можно "объектный" юзерспейс делать уже сейчас, поверх существующего posix. А такие штуки, как эта шина, просто добавляют выстродействие (и, возможно, чуть упрощают обеспечение безопасности - это на реализацию надо смотреть).Ну а в функциональщину как основу архитектуры я не особо верю, честно говоря. Вот для решения локальных задач она иногда оказывается к месту, это да. И уж точно ей не место там, где, по-хорошему,пользователь должен быть способен без особых умственных усилий сляпать простой скрипт, автоматизирующий какую-то рутину. Просто потому что если ещё можно пользователей в массе научить ООП на уровне Visual Basic 1.0 (а больше и не надо,собственно), то "функциональщина в массы" - это, IMHO, утопия полнейшая.
Юниксвейность в плане грамотной декомпозиции - это просто грамотная архитектура. Ни какого особенного отношения к UNIX она не имеет. Также грамотно можно спроектировать и любую другую ОС.> В этом плане можно "объектный" юзерспейс делать уже сейчас, поверх
> существующего posix.Можно. Это называется JVM - Java Virtual Machine. Она знает об объектах, поэтому объектную шину поддерживает родным образом.
> Ну а в функциональщину как основу архитектуры я не особо верю, честно
> говоря.Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.
> Вот для решения локальных задач она иногда оказывается к месту,
> это да.Ну это же набор приёмов, по факту. Как и структурное программирование, и ОО.
> И уж точно ей не место там, где, по-хорошему,пользователь
> должен быть способен без особых умственных усилий сляпать простой скрипт,
> автоматизирующий какую-то рутину.Как раз bash заменить на какого-нибудь потомка OCaml, чтобы можно было в параметры программ передавать другие программы вроде find -x, было бы неплохо. Ну и любимая вами типизация, причём автоматическая.
> то "функциональщина в массы" - это, IMHO, утопия полнейшая.
Ну как это? Есть find -x, есть множество мест, где аналогичный механизм оказался бы в дугу. Автовыводу типов вообще учить не надо. А больше там ничего, подходящего для скриптов, и нет.
> Можно. Это называется JVM - Java Virtual Machine. Она знает об объектах,
> поэтому объектную шину поддерживает родным образом.Вот только в целом из явы получился еще тот монструозный и тормозной переросток, который никому кроме энтерпрайзов с очень мощными серверами даром не упал. Ну, он занял свою нишу и пусть в ней и сидит. Насколько было востребовано - настолько и заюзалось.
> Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.
Остается только найти желающих все это использовать...
> Вот только в целом из явы получился еще тот монструозный и тормозной
> переростокА из Ведроида - нет, получились новые Винды. Т.е. mainstream OS.
>> Почему? Во-первых, ОС на Haskell уже есть. Она, если не ошибаюсь, называется HOME.
> Остается только найти желающих все это использовать...Это же исследовательская ОС.
>> Вот только в целом из явы получился еще тот монструозный и тормозной
>> переросток
> А из Ведроида - нет, получились новые Винды. Т.е. mainstream OS.Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.
> Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.Нет, не синоним качества. Это было к "никому не нужный".
>> Mainstream OS как синоним качества, что ли? :-) Это ж чистый холивор.
> Нет, не синоним качества. Это было к "никому не нужный"./me не согласен с тем анонимом по поводу серверов, но все же есть предложение не смешивать успех по маркетинговым и техническим причинам. И не рассматривать тут первые вообще.
> есть предложение не смешивать успех по маркетинговым и техническим причинам.Объектность системы - это техническая причина. То, что нет необходимости в сериализации при сохранении данных - это очень удобно.
> То, что нет необходимости в сериализации при сохранении данных - это очень удобно.Ну так вот в общем случае данные не ограничиваются текстом. Потуги представить вообще все как текст приведут к тому что в ряде ситуаций потребуется костылить черти-что.
Простейший пример: дамп памяти процесса довольно сложно сохранить как некий человекочитаемый текстовик.
> Объектность системы - это техническая причина. То, что нет необходимости в сериализации
> при сохранении данных - это очень удобно.Но не причина успеха системы, я к этому. Хочется вам с одними объектами работать — делайте так, хотите текст и пайпы — этак. Но только поэтому нельзя сказать, что один из вариантов в сумме для всей ОС явно лучше другого.
А удобно может и удобно, но не сериализовывать никто и в C / UNIX-way не запрещает, пардон за формулировку. Может не так удобно, как в java (не могу сравнить), но имхо не страшно.
> Объектность системы - это техническая причина. То, что нет необходимости в сериализацииРазмечтался то, академик. Вот хочешь ты данные переслать на ремотную машину. С хрен знает какой системой. И чтоб они могли с этим работать. И чего? Ах, добро пожаловать в сериализацию-десериализацию. Надо же, какая незадача: устройства хранения - по сути тупые массивы секторов. А сетевые интерфейсы - перекидывают пакеты. И про объекты оно вообще ни разу не слышало. И какая разнца, сервис в ОС сделает эти трансформации с ножом к горлу или это сделает некая сторонняя либа?
Ну да, некомпозиция. Но как-то в винде я её особо не видел, макось не глядел почти, но вроде тоже не заметно, а больше сейчас реально живого ничего и нет.И, простите, при чём здесь ява, если нам нужны,в общем-то, всего лишь сложные типы данных?
А идею пайпов мне, насколько я помню, объяснили в своё время за минуты, с MS-DOS, на первых уроках работы с компьютером. Вот если у вас получится так же функциональный вариант объяснять - то шанс есть. Но я сильно сомневаюсь, честно говоря. А "существующая система" - это, всё же, не о plan9 - а хотя бы о FreeBSD. В смысле - оно хоть кому-то должнобыть нужно и иметь хоть некоторую популярность.
Кстати, судя по всему, не HOME, а House - но это ж не ос, это игрушка-дипломник чей-то. А не верю по очень простой причине - ФП вообще никак не ложится на фон-неймановскую архитектуру. Система, у которой концепции радикально отличаются от железа, на котором она живёт - не верю, что она может быть эффективно реализована.
> А идею пайпов мне, насколько я помню, объяснили в своё время за
> минуты, с MS-DOS, на первых уроках работы с компьютером. Вот если
> у вас получится так же функциональный вариант объяснятьХохма в том, что пайпы и являются функциональным подходом в шелл-программировании. :)
a | b | c
c(b(a))
> Хохма в том, что пайпы и являются функциональным подходом в шелл-программировании. :)Еще большая хохма - что вссе это ни разу не клещится ни с дбасом, ни с бинарными логами, ни с чем там еще. При наличии для этого утилит которые можно использовать для вывода данных в тот же пайп.
Основное - придётся править основной набор (авк/греп/head/tail и т.п.)
Если вы мне покажете, где здесь передаются функции как отдельные от аргументов сущности - то соглашусь. А пока я вижу куски функционального подхода (кстати, там можно и получше сделать) в find, xargs и подобном, но никак не в обычном пайпе. И главное - не соблюдаются (и не будут) основные заморочки функциональщины, вроде "чистоты" функций и отсутствия сайд-эффектов. Так что скорее я бы даже версию find императивными коллбеками обозвал.
> Если вы мне покажете, где здесь передаются функции как отдельные от аргументов
> сущности - то соглашусь.Запись cat z.h | B | C | D можно легко трактовать, как передачу функции в качестве аргумента stdout.
> Так что скорее я бы даже версию find императивными коллбеками
> обозвал.Вот это, как раз, сложнее для использования, чем соглашение, что передаём функции.
Хм, ну да, можно и так. Хотя как только у "функций" появятся аргументы (параметры командной строки) сразу можно будет придраться, что нет униформности функции и её параметра, как в ФП положено - но это всё же скорее придирки. И, опять же, никаких претензий, пока не требуют "чистоты", иммутабельности и отсутствия сайд-эффектов. А как запись трактовать - дело десятое, тем более что там можно и while и for in написать.
> А не верю по очень простой
> причине - ФП вообще никак не ложится на фон-неймановскую архитектуру. Система,
> у которой концепции радикально отличаются от железа, на котором она живёт
> - не верю, что она может быть эффективно реализована.Ну много чего "радикально отличается от железа". Например, ООП. Или шаблонное программирование.
А так, как Михаил написал - в 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);;
ООП совершенно спокойно ложится на железо - в тех же плюсах это предельно наглядно. Таблицы функций и переменные - чему ж тту не ложиться? Шаблоны - тем более, это ж обычные макросы, разворачивающиеся в пачку того же кода, что под ними, каким бы он нибыл - хоть структурным, хоть ООП, хоть ФП прикрути.И нет, бэктики - это не из той оперы, по крайней мере при таком вызове. Кавычки здесь - это примерный эквивалент foreach(ls()){...} - что здесь функционального? И, опять же, ограничения ФП не соблюдаются. Собственно, если их не соблюдать и допутстить императивный стиль и функциональный однвоременно - то это как раз то, чем я твержу - берутся удобные куски, а на идеологию плевать.
> ООП совершенно спокойно ложится на железо - в тех же плюсах это
> предельно наглядно. Таблицы функций и переменные - чему ж тту не
> ложиться?Нет спец. аппаратной поддержки. Вернее, она есть (out-of-order очень помогает на С++ коде), но не везде и не так явна, как call и ret.
> Шаблоны - тем более, это ж обычные макросы, разворачивающиеся в
> пачку того же кода, что под ними, каким бы он нибыл
> - хоть структурным, хоть ООП, хоть ФП прикрути.
> Кавычки здесь - это примерный эквивалент foreach(ls()){...} -
> что здесь функционального?Прямое - передаётся функция.
> И, опять же, ограничения ФП не соблюдаются.
Какие? Если вы про "все переменные неизменяемы", то это ведь необязательная штука. Да и вообще, никто не заставляет делать исключительно "функциональный" язык, без императивных возможностей. Лучше наоборот - связка и того, и другого, см OCaml.
> Собственно, если их не соблюдать и допутстить императивный стиль
> и функциональный однвоременно - то это как раз то,
> чем я твержу - берутся удобные куски, а на идеологию плевать.И функционалка, и императивка - это просто приёмы. Ничего взаимоисключающего, заставляющего использовать либо то, либо другое, нет (см. OCaml/F#)
Ну так и ОО отлично передаются и делегаты и функторы и стретгии, в обычных сях есть указатели на функцию, в ассемблере (x86, по крайней мере) есть indirect call... могу еще фортран вспомнить с вычисляемыми метками. И всё это - передача функции, в общем-то.Вот за вариант "это просто приёмы, используем то,что удобнее в нужный момент или любую комбинацию" - я всеми лапами. Но обычно когда речь ведут об ФП именно на ограничения налегают...
> Ну так и ОО отлично передаются и делегаты и функторы и стретгии,
> в обычных сях есть указатели на функцию, в ассемблере (x86, по
> крайней мере) есть indirect call... могу еще фортран вспомнить с
> вычисляемыми метками. И всё это - передача функции, в общем-то.Можешь. Но эти делегаты, функторы и т.д. - не родное. В OCaml я поставил
-inline 1000, всё встроилось в код. Опять таки, делегаты и функторы слишком
тяжеловесно описываются в ОО.> Вот за вариант "это просто приёмы, используем то,что удобнее в нужный момент
> или любую комбинацию" - я всеми лапами. Но обычно когда речь
> ведут об ФП именно на ограничения налегают...Я, кстати, не очень понимаю, в чём ограничения - компилятор прекрасно может
понять по тексту функции, является ли она "pure" или нет. И даже для С++. :-)
Ну, описываются - это уже вопрос синтаксиса языка, isn't it? Вон, в D они вполне себе легко описываются.
По второму - я не понял, к чему это. Я имел в виду, что под ФП обычно понимают целую пачку концепций - функции как firt class members, иммутабельность, чистота, а остальные варианты - только с струдом или неудобствами (вообще обойтись, разумеется, не выйдет). ладно, тут уже разговор больше подходящий для джаббера или переписки пошел, как мне кажется - к теме отношения никакого не имеет.
> Сама концепция UNIX безнадёжно устарела. Система UNIX построена на портабельном ассемблере
> - языке C. Сейчас прошли две "революции" - появление в mainstream
> объектно-ориентированных языков и функциональных. Вы хотите объектную шину, поддерживающую
> серьёзный трафик, в том числе и broadcast, при этом берёте "старую"
> ОС . И, естественно, эта шина выглядит как на корове седло.
> Нужно менять ОС - тот же Ведроид уже объектен, там такие типизированные
> шины будут в дугу. А по-настоящему общеупотребительной функциональной ОС ещё нет,
> будем ждать.На ОО языках в mainstream пишут охочие до прибылей шараги,творящие свои Business Suite-ы за
как можно меньшие промежутки времени.Ядра-это только C.
> На ОО языках в mainstream пишут охочие до прибылей шараги,творящие свои Business
> Suite-ы за
> как можно меньшие промежутки времени.Ядра-это только C.Более того, отдельные участки ядра делаются на ассемблере или вообще в маш. кодах. Но интерфейсов ядра и идеологии ОС это не задаёт.
> Более того, отдельные участки ядра делаются на ассемблере или вообще в маш. кодах.Так ассемблер и есть человекочитаемое представление машинных кодов по сути. В общем сразу видно человека который витает в облаках высоких концепций и ... и не представляет как же там внутри работают эти чертовы компьютеры.
> Так ассемблер и есть человекочитаемое представление машинных кодов по сути."Отрок, ты мне так всю физику к х-ям сведёшь." Между ассемблером и маш. кодами есть ещё автокод. А в "человекочитаемое представление машинных кодов" можно при желании и Хаскелл записать.
> маш. кодами есть ещё автокод.По большому счету, я понимаю под ассемблером программу или набор программ которые переводят человекочитаемый листинг в бинарный код. Да, вот так вот просто мы и сводим физику к этому самому :). Кстати этой физикой если что я умею пользоваться в том числе и на практике, вплоть до компоновки машинных слов в желаемом лично мной формате. Так что например осмысленный для человека текст окажется осмысленным машинным кодом. Just because I can, разумеется. Ну и потому что это по своему красиво.
> По большому счету, я понимаю под ассемблером программу или набор программ которые
> переводят человекочитаемый листинг в бинарный код.Ну нельзя так вольно обращаться со словами. Плюс ещё категорично обвиняя других людей в том, что они "не знают". Это детское поведение - очевидно же, что я не обладаю телепатией и поэтому не знаю ваших внутренних определений.
> Ну нельзя так вольно обращаться со словами.Ну я уже взрослый и сам для себя решаю что мне можно, извините :). Те кто что-то на практике пишет на ассемблере - меня понимают с пол-оборота, а это в общем то единственное что для меня роялит. А рассуждения о красивостях от академиков - оно конечно да, но это чисто эстетический аспект. На результат это не влияет. Докопаться до формальностей конечно можно, а смысл? Это буквоедство ради буквоедства.
> Плюс ещё категорично обвиняя других людей в том, что они "не знают".
А где я кого-то обвинял? Я лишь выступал против навязывания вашей точки зрения как единственно верной. Как по мне - пусть кому "нужно делать вот так" - так идет и делает наздоровье. Так как посчитал нужным. А другие сами разберутся как им нужно. Вон Торвальдс не послушал Таненбаума - и сделал нечто работающее в результате хотя-бы. А наслушался бы как надо - и постигла бы его участь hurd'ов и minix'ов. Как показывает практика - иногда надо уметь показать всем умникам с их поучениями фак и сделать так как считаешь нужным. Особенно если результат потом тебе же и кушать придется. Вот Торвальдс очень метко заметил что когда теория и практика начинают клещиться, практика побеждает.
> Это детское поведение - очевидно же, что я не обладаю телепатией и поэтому не знаю
> ваших внутренних определений.Чтобы их знать - достаточно лишь немного практиковать и немного общаться с теми кто делает то же самое, чтобы понимать атмосферу в этой среде.
> Именно поэтому в ядре эта хрень совершенно не нужна. Ну, потому, что
> не нужно отправлять сообщения о вставленной флешке раз в 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 не только рождается ведь. То есть "в дугу" давно и тут присутствует.
> 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 не только рождается ведь. То есть "в дугу"
> давно и тут присутствует.А зачем тогда делать кентавра? Если нужна такая шина и вообще передача не текста, а объектов, стоит развивать Ведроид в направлении на десктопы. Может быть добавить в него Фантомовскую персистентную память.
> Знаете такую штуку - fork bomb? Или, например, неправильно сделанная программа может
> выжрать всю имеющуюся память, уйдя глубоко в swap. Как люди борятся
> с таким? Ставят ulimits - не хватило ресурсов компа, значит не
> судьба выполнить эту программу. Жалко, но делать нечего.Если в данном случае не судьба пользоваться этим устройством, то это немногих устроит.
В ulimits, кстати, ресурс памяти afaik давно не работает, надо в cgroups лезть.> программные системы делаются
> из программ 2-х уровней - быстрые Сшные и медленные, но легко
> пишущиеся - на скриптах; управляющие каналы в текстовом виде (для простой
> отладки).
> Почему вы так решили? Чаще всего для ОС имеется "системный язык". И
> концепции ОС должны быть хорошо выражаемы на этом "системном языке".Так есть, но имхо это не лучший вариант. Системный язык пусть будет для ядра, а для остального... "работа со строками в С" это отдельный мем, и что? Эта же концепция UNIX его и включает. То есть и по факту не сильно хорошо привязывается к возможностям языка, с момента своего появления.
> А зачем тогда делать кентавра?
Улучшить существующего :-)
> Если нужна такая шина и вообще передача
> не текста, а объектов, стоит развивать Ведроид в направлении на десктопы.
> Может быть добавить в него Фантомовскую персистентную память.Ведроид это продукт одного конкретного производителя, имеющий своей основной задачей (очевидно) захват рынка. Никаких особых преимуществ у него имхо нет (быстрая/легкая разработка софта, по сравнению с С, лично для меня не оно).
> В ядро-то на кой?А чем ядро хуже всех остальных, что ему так должно быть нельзя? Согласитесь, ядро могло бы разослать броадкаст вида "парни, мы тут перешли с сети на батарею, экономим питание кто как умеет!" вообще всем заинтересованным в этом программам, которые могут как-то менять свое поведение. Ну там менеджер питания может завернуть более жесткие политики powersave-а оборудованию, фоновые программы которые не критичны - встать на паузу до лучших времен, etc, etc. Один из наиболее очевидных примеров.
как ни смешно, но с этой штукой ядро такого не сделает. И это правильно - ядро даёт общий механизм, а выбор кокртеных форматов соообщений (в частнсоти, D-Bus) остаётся юзерспейсу. А чтобы рассказат о батарее есть udev, который с этим вполне справляется. А вот он может уже и по D-Bus ссобщение бросить. Собственно, так сейчас и происходит, AFAIK.
> А чем ядро хуже всех остальных, что ему так должно быть нельзя?Сложность отладки, повышенная опасность ошибок в коде.
> Согласитесь, ядро могло бы разослать броадкаст вида "парни, мы тут перешли
> с сети на батарею, экономим питание кто как умеет!" вообще всем
> заинтересованным в этом программам, которые могут как-то менять свое поведение.Тем кто подписался на сообщение. Так для рассылки такого ядерные скорости совершенно не нужны. Сообщения о смене питания можно вообще через минуту обрабатывать, никто не помрёт. Это, конечно, крайний случай, но такая шина уведомлений не должена гонять большой трафик.
Поэтому тут достаточно программы пользовательского режима, гоняемой, видимо, даже не из-под root'а, а, скажем, пользователя dbus из группы dbus.
> Сложность отладки,Было актуально ...цать лет назад. С виртуализаторами - можно ковырять вдоль и поперек. Даже снапшотов с образами оперативной памяти налепить и колупать их потом в свое удовольствие. А еще там KDB есть к тому же, так что если ядро не полностью околело, можно его само собой же и отлаживать :)
> повышенная опасность ошибок в коде.
Вот это есть. Ну так и отношение там к коду лучше чем у абы каких быдлокодеров все-таки.
> Тем кто подписался на сообщение. Так для рассылки такого ядерные скорости совершенно
> не нужны. Сообщения о смене питания можно вообще через минуту обрабатывать,Через минуту - не пойдет. За минуту юзер может сделать кучу действий связанных с питанием. Кроме того, ядру все эти события просто виднее всего по его природе. Ну, работает ядро и его модули с интеллектуальным чипом менеджера питания, висящим на I2C шине, например. Логично что если чип информирует нас о чем-то - удобнее всего было бы чтобы ядро отброадкастило от него эту информацию всем заинтересованным подписчикам. А зачем там туева хуча побочных прослоек? Так пожалуй даже менее надежно станет - чем больше звеньев в цепи, тем вероятнее что что-нибудь обломается и сглючит.
> никто не помрёт. Это, конечно, крайний случай, но такая шина уведомлений
> не должена гонять большой трафик.Для универсальной шины заранее не известно какой именно там будет траффик и по какому поводу. Значит оно должно быть способно на многое. Иначе потом юзеры начнут удивляться - что за нафиг - процессор грузится непонятно чем, батарей садится на 2 часа раньше чем должна! Отстой эта ваша операционка!
> Поэтому тут достаточно программы пользовательского режима, гоняемой, видимо,
> даже не из-под root'а, а, скажем, пользователя dbus из группы dbus.Так оно сейчас как-то так и есть, но мне не совсем понятно на основании чего ядро должно быть обделено на возможности броадкаста и получения сообщений.
>> Сложность отладки,
> Было актуально ...цать лет назад. С виртуализаторами - можно ковырять вдоль и
> поперек.И откуда вы с виртуализатором выясните, где у вас идёт обращение к памяти ядра, но не принадлежащей этому драйверу?
>> повышенная опасность ошибок в коде.
> Вот это есть. Ну так и отношение там к коду лучше чем
> у абы каких быдлокодеров все-таки.И? Это квалифицированные люди, их время стоит денег. Значит, разумно упростить им отладку и обезопасить их код, чтобы они могли не так сильно напрягаться.
>> Тем кто подписался на сообщение. Так для рассылки такого ядерные скорости совершенно
>> не нужны. Сообщения о смене питания можно вообще через минуту обрабатывать,
> Через минуту - не пойдет. За минуту юзер может сделать кучу действий
> связанных с питанием.Ну сделает, ну обработаются через минуту. Никакой пользователь не будет вытаскивать и втыкать штеккер в ноут со скоростью 25 раз в секунду. Даже 2 раза в секунду не будет.
> Кроме того, ядру все эти события просто виднее
> всего по его природе. Ну, работает ядро и его модули с
> интеллектуальным чипом менеджера питания, висящим на I2C шине, например. Логично что
> если чип информирует нас о чем-то - удобнее всего было бы
> чтобы ядро отброадкастило от него эту информацию всем заинтересованным подписчикам.Ну вот оно передаёт демону в пространстве пользователя. А демон шлёт по шине в пр-ве пользователя. Зачем тут шина в ядре?
> А зачем там туева хуча побочных прослоек?
Давайте засунем всю систему в пространство ядра. :-)
> Для универсальной шины заранее не известно какой именно там будет траффик и
> по какому поводу.Если вы будете гонять гигабайты, вы во-первых, заблокируете шину. Если вы будете делать шину с использованием всех имеющихся в системе процессоров, с коммутацией пакетов, с приоритезацией и т.д., вы сильно усложните простую задачу уведомления о редких событиях.
> Так оно сейчас как-то так и есть, но мне не совсем понятно
> на основании чего ядро должно быть обделено на возможности броадкаста и
> получения сообщений.Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?
> И откуда вы с виртуализатором выясните, где у вас идёт обращение к
> памяти ядра, но не принадлежащей этому драйверу?В теории, виртуализатор может стопроцентно мониторить всю память. На практике понятное дело есть куча факторов, в том числе и само оборудование, которое само может данные в память гонять через DMA "как драйвер запрограммит" и прочие прелести, позволяющие поставить колом систему не столь очевидными но не менее невкусными марштурами. С другой стороны эти факторы и микроядро с драйверами в юзермоде так же поставят колом. Ну вон например драйвера GPU. Ну тот же радеон, пускай. Его основной бич - GPU вешается из-за ошиобк в работе оборудования (errata, не описаны в спеках). Рекавери GPU - отдельный гемор, сравнимый по сложности реализации с чуть ли не запуском ракеты в космос и столь же обломоопасный, т.к. современный GPU - это навороченный комплекс из нескольких подсистем. Которые желательно показать апликухам в том виде как было, иначе они осыпятся как горох. А если рекавери не удался - система резко остается без картинки на экране по вполне очевидной причине. Скажите, пожалуйста, как именно то что вы сватаете поможет в отладке в этом вполне рядовом и заурядном случае? А вот тормознет - запросто. Там летают чуть ли не гигабайты в секунду, так что одно лишнее копирование может положить производительность в разы.
> И? Это квалифицированные люди, их время стоит денег. Значит, разумно упростить им
> отладку и обезопасить их код, чтобы они могли не так сильно напрягаться.Вы так говорите как будто эти разработчики уполномочивали вас говорить от своего лица. А они этого не делали, между прочим. И т.к. они вполне успешно пилят свои драйвера уже более десятка лет и не рвутся пилить микроядра и дрова в юзерспейсе - удачи вам их пинками загнать в всеобщее счастье.
> Ну сделает, ну обработаются через минуту. Никакой пользователь не будет вытаскивать и
> втыкать штеккер в ноут со скоростью 25 раз в секунду. Даже 2 раза в секунду не будет.Тормозные системы пользователям не нравятся. В свое время это крепко подгадило WinNT с более правильным дизайном заставив несколько лет выпускать 9х попутно допиливая дизайн NT до состояния когда его скорость таки устроит юзерей. А сейчас запросы выросли, юзеры хотят разрешения FullHD и выше, 3D навороченное и что там еще. И опять же тормознуть ту же графическую подсистему - не вариант. SSD опять же по скорости - очень быстрые штуки, приближающиеся к физическим лимитам интерфейсов. Если проц прии этом начнет клинить в пять раз сильнее - кому оно будет надо?
> Ну вот оно передаёт демону в пространстве пользователя. А демон шлёт по
> шине в пр-ве пользователя. Зачем тут шина в ядре?Затем что по факту этим заведует ядро и довольно глупо пытаться делать вид что это не так. Только почем зря строится лишняя длинная цепочка, снижая скорость. А может и надежность. По такой логике и TCP/IP должен отдельный демон делать. Вот только нафига оно надо такое счастье? Пусть кому надо - тот этим и пользуется, если хочет.
>> А зачем там туева хуча побочных прослоек?
> Давайте засунем всю систему в пространство ядра. :-)Маленькие и простые системы ксати так и делают - на 8-битниках всяких вообще нет разделения режимов. И ничего, работает. Даже в ответственных применениях, между прочим. А оно всякими ABS щелкает, подушки безопасности выбрасывает и делает прочие задачи, в общем то завал которых достаточно критичен. Наверное секрет не в том чтобы изящно подтереться после того как из штанов потекло, а не допускать этого самого вытекания, для начала. Кому нужна система от которой дурно пахнет?
>> Для универсальной шины заранее не известно какой именно там будет траффик и
>> по какому поводу.
> Если вы будете гонять гигабайты, вы во-первых, заблокируете шину.Значит по хорошему должен быть некий арбитраж и дележ ресурсов, предотвращающий такой сценарий в бесконтрольном виде.
> Если вы будете делать шину с использованием всех имеющихся в системе процессоров,
> с коммутацией пакетов, с приоритезацией и т.д., вы сильно усложните простую
> задачу уведомления о редких событиях.Ну вон TCP/IP реашает довольно сложную задачу и имеет довольно много опций. И тем не менее, его не так уж сложно использовать. И да, таки в ядре есть возможность приоретизации пакетов и прочая. Но это не значит что апликушнику будет сложно создать сокет с нужными параметрами и прочая.
>> на основании чего ядро должно быть обделено на возможности броадкаста и
>> получения сообщений.
> Не обделено - как ещё получаются сообщения о смене режима питания, как не из ядра?Вот мне и не понятно - зачем в этом процессе какие-то левые юзерспейсные демоны вообще будут фигурировать?
> Вот мне и не понятно - зачем в этом процессе какие-то левые
> юзерспейсные демоны вообще будут фигурировать?Потому что в ядро кладется по минимуму, механизмы. Всё остальное, в т.ч. логику, как их использовать — юзерспейсу. Иначе можно много чего в ядро затащить, webkit там, libodf какую-нибудь... :-)
> Потому что в ядро кладется по минимуму, механизмы.Это не ответ. Получается что концепции ради концепций. А так не пойдет, особенно если надо делать добавочную работу и/или начинает работать хуже чем было.
Если "если", значит плохо подумали. А почему "ради" не понял, цель концепции — помочь определить, что лучше класть в ядро, а что оставлять юзерспейсу. Если есть такой выбор, то должны быть какие-то guidelines же.
> В теории, виртуализатор может стопроцентно мониторить всю память.Ну можете. Но как вы определите, что функция одного драйвера в ядре затёрла память другого драйвера ядра? Вы же не анализируете расположение динамически выделенных таблиц.
> С другой стороны эти факторы и микроядро с драйверами в юзермоде
> так же поставят колом.Да, но хоть часть проблем уйдёт. Это уже неплохо.
>[оверквотинг удален]
> 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 - это вообще не операционная система. Это "монитор".
> Да. Наш дедушка пахал плугом. И мы будем делать то же самое.Ну да. Дедушка пашет плугом, разработчики разрабатывают ядра ОС, форумные теоретики треплют языком.
Каждому свое.
> Ну можете. Но как вы определите, что функция одного драйвера в ядре
> затёрла память другого драйвера ядра? Вы же не анализируете расположение динамически
> выделенных таблиц.До некоторой степени можно по адресам разных сущностей, все-таки карта размещения оных - генерится. Именно заезд в чужой динамический массив - сложнее, скорее всего понадобится какой-то костылик в аллокаторе проверяющий это явным образом. С другой стороны, у медали есть обратная сторона: можно сделать из бага фичу. И все эти очень эффективные 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 программам.
> Если даст нормальную скорость - то это надежда сделать существенно более модульную
> систему, не ломая юникс-вей (в смысле кучи невависимых модулей, делающих каждый
> что-то своё). У нас же сейчас нет шустрых способов взаимодействия many-to-many.сеньер сознательно забыл о существующием netlink*() ?
mqueue
Старая концепция linux: всё есть файл.
Новая концепция linux: всё есть ядро.
> Старая концепция linux: всё есть файл.
> Новая концепция linux: всё есть ядро.Ошибка. Концепция «всё есть файл» - это UNIX, а Linux - не UNIX ©Linus Torvalds.
Это во-первых. А во-вторых, Linux - это как раз только ядро и есть. Если речь идет о системе на базе ядра Linux, то это нужно явно указывать, например, GNU/Linux или Андройд тот же ;)
"Linux is a Unix-like computer operating system"
"GNU's not Unix"
> Ошибка.Ну, блин. Была такая классная шутка.
Ну, вроде как про GNU/Linux говорили что это "UNIX-подобная операционная система". "Всё есть ядро" это конечно сильно сказано, но до концепции "всё есть модуль" доскакать весьма могут, в том или ином виде.
Хозяйственный. Всё в дом, всё дом^W в ядро.
https://www.linux.org.ru/forum/development/7881682
только хотел эту ссылку кинуть :)
> https://www.linux.org.ru/forum/development/7881682Спасибо, очень в тему.
Лол, надеюсь тот чувак собрался _реализовывать_ ядерный dbus, а не просто подпиливать готовую реализацию в ядро...
Тот чувак?) Ну хотя бы Торвальдса ты так не называешь?))
> Тот чувак?) Ну хотя бы Торвальдса ты так не называешь?))А кто такой Торвальдс ?
Ну, чувак же
Кто вообще все эти люди?
Вроде zeromq планировали впилить, передумали,что ли.
Кстати DBUS по сети уже научилась работать?
zeromq на крестах написан, куда ему в ядро? Впрочем, красноглазым не привыкать к забиванию гвоздей микроскопом с помощью костыля. Вот это для ядра подойдет куда лучше: http://www.crossroads.io От автора ZeroMQ и написано на Си.
для сети есть сокеты
вы zeromq вообще видели?
вы тред вообще читаете? Что вы вообще хотели сказать своим постом?
Я к тому,что ZeroMQ и есть "сокеты на стероидах". Избавляет от массы мороки. И в ядре его видеть было бы довольно интересно - там иногда из-за неядерности тормоза чуть ли не на порядок выскаивают. Но да, реализация плюсовая, так что не для линуксового это ядра.
zmq нельзя впилить в ядро, иначе оно перестанет быть Z.
DBus - не предназначен для работы по сети, на данный момент он зацелен строго на in-host communication.
я их не понимаю. какие-то части старательно выносят в юзерспейс (KMS и прочая херотень), а в то же время зачем-то пихают туда явно юзерспейсную приблуду.
> я их не понимаю. какие-то части старательно выносят в юзерспейс (KMS и
> прочая херотень), а в то же время зачем-то пихают туда явно
> юзерспейсную приблуду.Привыкай ! это же Линукс с большой буквы
Главное в ядро побольше всякой лабудени напихать что бы потом было сложнее недокументированные возможности искать (Очередные фитчи называемые багами)
KMS (Kernel Mode Settings) и юзерспейс. Знатно ты на ноль делишь.
угу, множественная эффективная дисчпетчеризация сообщений - юзерспейснее некуда. Ну а чего, давайте и FS только в виде FUSE писать будем, возьмём пример с NTFS-3G.А D-Bus там будет или другой какой специфический вариант шины поверхсамого диспетчера - дело уже юзреспейса.
> угу, множественная эффективная дисчпетчеризация сообщений - юзерспейснее некуда. Ну а
> чего, давайте и FS только в виде FUSE писать будем, возьмём
> пример с NTFS-3G.Между прочим, NTFS-3G - это классический случай упрощённой отладки в пространстве пользователя. Я помню, как Антон разрабатывал linux-ntfs, это была долгая эпопея, в которой делались и kernel драйвер, и fuse драйвер. Так вот, какая-то поддержка записи появилась лишь в FUSE драйвере. В драйвере ядра отладка этой сложной FS оказалась чересчур трудоёмкой.
> Между прочим, NTFS-3G - это классический случай упрощённой отладкиА также клинический случай пожирания процессора. По поводу чего я очень быстро перевел диски из ntfs в другие файловые системы в свое время. А то обидно, знаете ли, когда скорость работы ФС упирается не в диск а в 3ГГц процессор. Который при этом взвывает вентилятором как реактивный самолет, разумеется (10x to "turbo core" или как там его правильно).
> А также клинический случай пожирания процессора. По поводу чего я очень быстро
> перевел диски из ntfs в другие файловые системы в свое время.Правильно. Это неродная система для Linux'а. И смысла её использовать нет ни малейшего. Плюс, она ещё и сильно фрагментируется.
> Это неродная система для Linux'а. И смысла её использовать нет ни малейшего.Это как? А XFS или JFS родные? Почему с ними нету проблем, а в некоторых задачах по производительности они обходили ext3?
>> Это неродная система для Linux'а. И смысла её использовать нет ни малейшего.
> Это как? А XFS или JFS родные? Почему с ними нету проблем,
> а в некоторых задачах по производительности они обходили ext3?Да, XFS и JFS - вполне себе "родные", так как их портировали и поддерживали разработчики этих систем, при 100% поддержке (и за деньги) вендоров, почитайте их историю. Причем портировали код, а не писали реализацию с 0.
Это сильно отличается от "внебрачного" нтфс, где даже полных спецификаций нет, не говоря уж об исходном коде.
> Правильно. Это неродная система для Linux'а. И смысла её использовать нет ни
> малейшего. Плюс, она ещё и сильно фрагментируется.Ну да, а родные ФС на то и родные что в кернелмоде крутятся и потому проц не насилуют лишними мотаниями контекста туда-сюда + вообще могут пользоваться услугами ядра, используя прямые, быстрые и короткие маршруты с минимальным оверхедом. В эпоху SSD выжимающих 500Мб/сек и более все это становится еще более злободневно.
Насколько я понимаю, поддержка появилась просто там, где финансово заинтересованная сторона эту поддержку сделала. И препочла в открытом варианте отдать только FUSE-модуль. Впрочем, вариант "отладка в юзермоде и затем перенос в ядро" я ни разу не отрицаю.
> я их не понимаю. какие-то части старательно выносят в юзерспейс (KMS иKMS == Kernel ModeSetting. Внезапно, он заменил собой устаревший интерфейс UMS - User ModeSetting. Вы все поняли с точностью до наоборот. FAIL.
Отличная новость. Шина сообщений на уровне ядра позволит значительно ускорить работу D-Bus и ему подобных проектов. Мало того, можно будет организовать отправку сообщений между приложениями, запучшенными от разных юзеров. Как только права выставляться будут? Нужен механизм для обеспечения контроля доступа процессов к сообщениям.
тебе сюда https://plus.google.com/111049168280159033135/posts/4cAYcew55bN
Прикольный комментарий к этому сообщению:
"Finally, after all these years we'll know what happens if Linus gets run over by a bus"
(тема сообщения: AF_BUS в ядре).
А в микроядерных осях это все есть бай дисигн. И в принципе, не важно, где мейлбокс процесса, на этой железке, в этой стойке, или в датацентре за океаном. Скоро дубас научится по сети работать и это преподнесут как прорывную технологию.
Сокеты уже давно существуют и выполняют данную роль, причем, в отличии от микроядерных ОСей, они есть везде и всюду в реальности, а не в идеальном гипотетическом будущем.
many-to-many через сокеты? Подцепись к сокету, объясни, где твой лежит, руками распарси, где одно сообщение началось и другое закончилось, руками проверь, целиком ли сообщение дошло, руками отправь ack... То же мне, радость.Впрочем, микроядерные оси идут туда же, куда и остальные "чистые идеи" - в диссертации и игрища теоретиков. А практики оттуда натащат удобные им куски. Один из которых вполне может оказаться реализованная в ядре толковая шина сообщений.
> Впрочем, микроядерные оси идут туда же, куда и остальные "чистые идеи" -
> в диссертации и игрища теоретиков.А как же всякие телефоны и т.д.? http://stackoverflow.com/questions/8405505/is-there-any-appl...
Просто для эффективной работы микроядра нужно уметь его поддерживать в ЦП. Ну точно также, как для эффективной работы многопользовательской ОС нужно уметь поддерживать защиту памяти.
Насколько я понимаю, оно там используется исключительно как гипервизор же? Меня, честно говоря, монолит просто стопроцентно устраивает, особенно в виде линуксовой реализации. Ну начнут через пару-тройку лет более активно оттуда выкидывать устаревший код - и всё нормально будет. А вот от микроядра я практического рофита не вижу. В теории хорошо, конечно, что драйвер не может повалить систему - только по факту оказывается, что выгоднее таки баги просто исправлять, либо решать более общие проблемы на более высоких уровнях системы - резервирование, выбор подходящего оборудования и софта, внешний мониторинг и т.п. Просто потому что это всё делать так и так придётся.
> Насколько я понимаю, оно там используется исключительно как гипервизор же? Меня, честно
> говоря, монолит просто стопроцентно устраивает, особенно в виде линуксовой реализации.А меня - нет. У меня много раз вылетало ядро по совершенно дурацким причинам.
> А вот от микроядра я практического профита не вижу.
> В теории хорошо, конечно, что драйвер не может
> повалить систему - только по факту оказывается, что выгоднее таки баги
> просто исправлять, либо решать более общие проблемы на более высоких уровнях
> системы - резервирование, выбор подходящего оборудования и софта, внешний мониторинг и
> т.п. Просто потому что это всё делать так и так придётся.Алекс, вы отлаживали программы под MS DOS? Там никаких Segmentation Fault нет, и если программа записывает данные не туда, этого не видно => велик шанс оставить такие ошибки в программе.
А драйвера пишут явно не боги. И даже не полубоги. Поэтому им подспорье в виде естественной защиты, срабатывающей при неправильном обращении к памяти, сильно бы помогло с отладкой.
Кхм, а куда б я от DOS делся :-) И отлаживал, и в жесткие диски через порты терзал, и резиденты писал... Собственно, поэтому и считаю, что то,что есть сейчас - вполне приемлемое состояние. на то, чтобы толком писать ядро, специалистов много не надо и их вполне хватает, а юзерспейс уже вполне достаточно ограничен.Вот в варианте "подмоги с отладкой" - да, вариант любопытный. Но, думаю, это и сейчас как-то решается.
> Вот в варианте "подмоги с отладкой" - да, вариант любопытный. Но, думаю,
> это и сейчас как-то решается.Ну зачем, спрашивается, должен работать человек, если может работать машина? :-) Пусть лучше процессор определяет, кто там куда не туда залез. :-)
Потому что после основной отладки это будет совершенно бесполезная трата ресурсов машины на разные IPC и проверки.
> Потому что после основной отладки это будет совершенно бесполезная трата ресурсов машины
> на разные IPC и проверки.Так можно сказать, что и защита памяти после отладки - бесполезная трата ресурсов машины. Только вот мы знаем, что ничего нельзя отладить до 0-я ошибок.
ну да. Но на практике лично мне надежности ядра хватает с головой.
> Просто для эффективной работы микроядра нужно уметь его поддерживать в ЦП.Уже нашлепаны миллиарды процессоров. Вот сейчас, разбомбим все до основания и будем строить новый мир, с нуля. С расово верными процессорами. А сами то вы в это верите? :)
> many-to-many через сокеты? Подцепись к сокету, объясни, где твой лежит, руками распарси,
> где одно сообщение началось и другое закончилось, руками проверь, целиком ли
> сообщение дошло, руками отправь ack... То же мне, радость.Как бы большинство всего этого уже есть в готовых либах. Необязательно каждый раз начинать с нижнего уровня. А сложности протокола общения от способа доставки не сильно зависят.
> many-to-many через сокеты? Подцепись к сокету, объясни, где твой лежит, руками распарси,
> где одно сообщение началось и другое закончилось, руками проверь, целиком ли
> сообщение дошло, руками отправь ack... То же мне, радость.Т.е. ты предлагаешь впихнуть весь этот крап в ядро?
> Т.е. ты предлагаешь впихнуть весь этот крап в ядро?Ну вон TCP/IP запихан и никто не жалуется вроде. А там и рассылка ACK, и пересборка фрагментов, и очередизация/приоритеты, и чего там только нет!
Лучше бы они общелинуксовый аналог kio/gio реализовали. Вот это был бы реальный прорыв…
Дык fuse же.
Давно пора. Существующие ИПЦ - полнейший ад.
Хорошо "придумали"! Ещё б этим ребятам английский подучить, чтобы сайт qnx.com прочесть и тогда они с удивлением обнаружат систему, которая 20 лет назад всё это уже имела.
эээээ... ну может быть тогда не надо разрабатывать велосипеды, а просто взять нужные исходные коды из этого QNX и засунуть их в ядро? :)</sarcasm>
Поменьше разговаривайте с голосами в голове. Никто, ну кроме голосов, не утверждал, что они придумали что-то принципиально новое.
Windows 3.0 - 22 года с сообщениями. Теперь все точно знаем на сколько отстаёт в развитии ядро.
> сколько отстаёт в развитии ядро.Только его в отличие от винды 3.0 не клинит, если программа забила на обработку сообщений. Маленькая такая разница :)
И парсер xml надо туда втолкнуть. Обязательно.
> И парсер xml надо туда втолкнуть. Обязательно.А потом - интерпретатор особых инструкций, скрываемых в специальных xml-тэгах - чтобы можно было передать кусок xml, который должен по-разному парситься в зависимости от состояния принимающей стороны. Ну, Вы поняли, о чём я.
Мне давно необходим Postgres в ядре!!!1 Почему до сих пор нет?
Ничего, что там даже парсера d-bus не будет - только диспетчер, на базе которого шустрый dbus можно сделать?
>Ничего, что там даже парсера d-bus не будет - только диспетчер, на базе которого шустрый dbus можно сделать?Уже есть. UDS называется.
Великолепно! Давно ждал, когда же в бетон монолита подольют немного микроядерности.
> Великолепно! Давно ждал, когда же в бетон монолита подольют немного микроядерности.Тоже подумал про микроядро.
Таких правда макроскопических размеров.
А что, главное что бы надежно работало.
Потом драйверы начнут в отдельные процессы выводить, вот размерчик и начнет уменьшатся.
Всё как обычно, группа анонимов учит Грега Кроа-Хартмана писать ядро.
> Всё как обычно, группа анонимов учит Грега Кроа-Хартмана писать ядро.Если он такой крутой, то может на всех срать?
Нет, не на всех.
> Нет, не на всех.Только на дебилов? Я одобряю такой подход.
А давайте включим туда Systemd, пульсу и бизибокс.
Нет. только первое и второе.
А давайте включим мозги.
призыв включить мозги на opennet. nuff said
> А давайте включим мозги.Если вы включим в ядро мозги - оно таки очень скоро соберется в глобальный скайнет и тогда вы уж точно ответите за ваши сообшения на опеннете по полной программе :)
> А давайте включим туда Systemd, пульсу и бизибокс.Давайте! Засылай патчи прямо Линусу на мыло!
> ... прямо Линусу на мыло!Узнай американо-финский разговорный фольклор и лексику!
>> ... прямо Линусу на мыло!
> Узнай американо-финский разговорный фольклор и лексику!Линус плоховато говорит по-фински
Впилили бы туда еще аналог udev и вообще стало бы шикарно :)
> Впилили бы туда еще аналог udev и вообще стало бы шикарно :)уже пробывали. Выпиливали назад - так как это был ад по поддержке. Ждем теперь впиливания и выпиливания d-bus.
>так как это был ад по поддержкеЕсли впилить в виде devfs - то безусловно, а если в том виде, в каком udev пока еще существует, то можно и помечтать... Однако сдается мне, что добавление функциональности D-bus в ядро, при всей здравости этой идеи, создаст "дыру" для проникновения туда systemd всеми возможными и невозможными способами. При своем врожденном пессимизме, я все-таки надеюсь ошибиться. ;)
> пробывали.Ох, опять школьная аналитика. А за русский вам двояк в аттестат записали?
Однозначно пора сваливать на FreeBSD.
одобряем зпт можете сваливать тчк
> Однозначно пора сваливать на FreeBSD.Недостаточно хардкорно. Лучше сразу на миникс, qnx или что-нибудь подобное.
>... сваливать на FreeBSD.Точно, - во всём виновата FreeBSD.