XML овладёваные люди.

>Может их уже изолировать надо?

<?xml version="1.0" encoding="UTF-8"?>
<isolation strong=true>brain damaged хуман</isolation>

> овладёван

нифига себе вольное словообразование :-D

/me вспоминает знаменитую фразу "они выходили из столовой жря."

> Как вы относитесь к тем, чей мозг овладёван XML? Может их уже изолировать надо?

Если хочешь что-то развалить - возглавь это. Организуй этих извращенцев - пусть кропают с нуля "принципиально новый", "политически правильный", "первый и единственный в своём роде" (можно ещё русский, посконный, православный, но это на любителя) дистрибутив полностью на xml - и пусть копошатся там, как черви. Заодно спасёшь от этой заразы нормальные дистры. А гомункулюс всё равно сдохнет :)

as33, этот документ не well-formed. Вместо strong=true должно быть strong="true".

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

LFS без Гнома. Ну и документации там будет не сильно уж и много.

> Макос получиццо - там довольно много xml.

Все настройки (на 99.999% процентов) на маке хранятся в plist-ах.

Почти все plist-ы (за редкими бинарными исключениями) - это XML, к которому стандартизован доступ.

Т.е. на маке не просто "много xml", там практически все настройки в XML, а что не в XML, то от лукавого.

Не просто без гнома. Всякие hal-ы c dbus-ами (и все, что их использует) - тут же вылетает в трубу. В общем, получится что-то типо линуха середины 90х, только версии свежие.

> Всякие hal-ы c dbus-ами (и все, что их использует) - тут же вылетает в трубу.

Там им в принципе и место, поскольку что первое что второе преумножение сущностей.

И без жабира.
Корреспонденты l-t@cjr вас линчуют.

Альтернативы с той же функциональностью (желательно, без потерь в производительности)?

Ну я вообще даже не о Linux говорил. Делают люди проект. Используют WebServices для взаимодействия частей. То есть RPC поверх SOAP(XML), а в вызовах строками передают XML который потом руками разбирают и накладывают на него другой XML, чтобы на выходе получить XML из которого посредством XSLT будут строить xHTML (который еще и подмножество SGML).

Мне кажется что мой моск съели :(.

> в вызовах строками передают XML который потом руками разбирают и накладывают на него другой XML

А вот за это убивать. Беда не в ХМЛ, а в дураках, которые всегда расшибают лбы, какому бы богу их не научили молиться.

> Альтернативы с той же функциональностью

Альтернативы чего ? block-device char-device в первом случае ? и IPC во втором ?

> (желательно, без потерь в производительности)?

Даже не смешно.

> Не просто без гнома. Всякие hal-ы c dbus-ами (и все, что их использует) - тут же вылетает в трубу. В общем, получится что-то типо линуха середины 90х, только версии свежие.

Так и есть, но если DE как таковое не нужно - то и всё очень даже здорово будет. vim/bash/80x25 - наше всё ;)

Ну расскажи им про JSON, а заодно и про REST. И дай почитать вот этот боян: http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stnds-for-simple/. Хотя кто инкапсулировали ящерикой, тому никакими боянами не помочь.

> block-device char-device в первом случае ?

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

> IPC во втором ?

В каком из традиционных IPC можно специфицировать интерфейсы, при этом автоматически генерировать код для stubs?

> Даже не смешно.

Это я подстраховался на тот случай, если бы кто-нибудь произнес слово CORBA.

> Корреспонденты l-t@cjr вас линчуют.

Это хорошо, драки старый Гарик любит ;)

> а в вызовах строками передают XML который потом руками разбирают и накладывают на него другой XML

Что-то не понял. Это как? Можно пример?

> Ну Вы хоть бы посмотрели, сколько информации предоставляет hal.

Не более чем может сказать ему устройство.

> Причем способом, не зависящим от конкретных драйверов.

Это унификация+ускорение разработки в ущерб производительности.

> И даже ОС.

Это все гонка за кол-вом целевых платформ.

> Как Вы предлагаете это все реализовывать, если у Вас есть только файлы устройств?

Как не раз уже советовал Танненбаум стандартизировать интерфейсы на уровне ядра.

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

полиси на доступ вобщем-то никто не отменял.

> В каком из традиционных IPC можно специфицировать интерфейсы

tcp/ip ? Странно но тем не менее.

> если бы кто-нибудь произнес слово CORBA.

А если бы кто-нибудь сказал ASN ?

> Это унификация+ускорение разработки в ущерб производительности.

Это важно. Это мощный плюс. Железо дешево (уже даже в мобильных устройствах - в n800, например). Рабсила дорогая (даже индийская).

> Это все гонка за кол-вом целевых платформ.

И это тоже неплохо.

> Как не раз уже советовал Танненбаум стандартизировать интерфейсы на уровне ядра.

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

> tcp/ip ? Странно но тем не менее.

В tcp?? Научите, где там формально можно описать интерфейс? Где там IDL? RFC не предлагать - он не является машинно-читаемым документом. Кстати, я просил без потери производительности.

> А если бы кто-нибудь сказал ASN ?

Это немного из другой оперы AFAIK. И еще ужаснее, чем корба ИМХО.

> Не более чем может сказать ему устройство.

В hal есть некоторое кол-во собственного кода по обработке этой информации. И собственные файлы с данными, которые недоступны из ядра (потому что ядру не нужны).

> Это важно. Это мощный плюс.

Это рыночная выгода, но никак не плюс.

> Железо дешево

Фишка в том что оно дешевеет весьма относительно. И если делить производительность железа на время системы и время пользователя. Большая часть стоимости таки уходит на переферию (которая не сильно изменилась).

> И это тоже неплохо.

Это вообще ужасно. Стирая границы целевого применения различных ОС мы получаем везде неповоротливую кучу костылей.

> Мы же знаем, что этого нет - и скорее всего, не будет.

Теперь скорее всего нет.

> RFC не предлагать

"Этокакэто ?" IDL там таки есть, не в полном понимании термина, но скажем так для прослойки между стулом и клавиатурой. Машиночитаемым сделать можно все но вот машинопонимаемым ниразу. Коряво выразился но маразм вроде <preved param="medved"/> без рукописного DTD нифига никому ничего не скажет.

> Это немного из другой оперы AFAIK.

Да чет смаху брякнул сюда не хватает RPC. Так было бы точнее.

> Кстати, я просил без потери производительности.

А это кстати самый здравый вариант - раздачи идентификаторов (портов) под задокументированные протоколы.

> В hal есть некоторое кол-во собственного кода по обработке этой информации.

Эта информация в драйвере должна быть.

> Это рыночная выгода, но никак не плюс.

Это и есть плюс. Плюс - увеличение пользовательской базы и базы разработчиков.

> Фишка в том что оно дешевеет весьма относительно.

Важно то, что оно уже достаточно дешево-быстро, чтобы не обращать внимания на накладные расходы типа hal/dbus.

> Стирая границы целевого применения различных ОС мы получаем везде неповоротливую кучу костылей.

А искусственно их поддерживая - получаем vendor lock на разработчиков. Что намного хуже (см. виндовые разработчики как экстремальный пример). Насчет неповоротливости - см. выше про скорость железа. Насчет костылей - любая попытка унификации интерфейсов может считаться костылем. Но тем не менее это благо. Это я как разработчик утверждаю. За что я больше всего люблю жабку - именно за подход, ставящий во главу угла универсальность интерфейсов. От всей души ненавижу частные, привязанные к конкретному вендору, интерфейсы. Выше уровень абстракции, общЕе интерфейсы - вот к чему надо стремиться.

> для прослойки между стулом и клавиатурой.

Неинтересно. Хочу, чтоб компилировалось в stubs/skeletons. Чтоб машинно читаемое.

> сюда не хватает RPC. Так было бы точнее.

Дык dbus и есть OO RPC со своим idl. Или Вы про конкретную реализацию?

Зачем она там, если для работы ядра она не нужна? Тем более "должна быть" - не то же, что "есть". Опять же, гарантировать это никто не может - по всему спектру ядер, поддерживаемых hal.

А почему из другой? Сериализация объектов для передачи по сети. LDAP (помимо прочих протоколов) эти пользуется.

Abstract Syntax Notation One (ASN.1) is a standard and flexible notation that describes data structures for representing, encoding, transmitting, and decoding data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities.

Чем не зумль?

Вы контекст потеряли. Там было про dbus.

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

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

> Т.е. на маке не просто "много xml", там практически все настройки в XML, а что не в XML, то от лукавого.

Во-во, типичный религиозный фоннатизм.

Это была всего лишь реакция на предложение сделать дистрибутив на одном хмл. Как раз я обеими руками (и всеми ногами) за рациональное использование.

>> Это унификация+ускорение разработки в ущерб производительности.

>Это важно. Это мощный плюс. Железо дешево (уже даже в мобильных устройствах - в n800, например). Рабсила дорогая (даже индийская).

Это ещё один плюс, для глобального потепления. Энергоносители неизбежно дорожают. У универсального нет будущего в перспективе.

>>Энергоносители неизбежно дорожают.

Не читайте советских газет за обедом.

Я слышал, что использование солнечных батарей с 10% КПД на территории 700x700 км обеспечивает энергетические потребности всего человечества.
Это намного меньше территории Сахары.

Для дальнейшего просветления:
http://en.wikipedia.org/wiki/World_energy_resources_and_consumption

> Плюс - увеличение пользовательской базы и базы разработчиков.

Я имел ввиду что это "рынок ради рынка". Типа долгоиграющей пирамиды которая рано или поздно валится.

> чтобы не обращать внимания на накладные расходы типа hal/dbus.

hal/dbus это таки некислый оверхед на который нельзя не обращать внимания.

> А искусственно их поддерживая - получаем vendor lock на разработчиков.

А какая разница на что будет lock ? На вендора, на системный/прикладной уровень - разницы нет.

> (см. виндовые разработчики как экстремальный пример).

Ну и ? Люди выбравшие целевую платформу и играющие по ее правилам (я надеюсь мы тут подразумеваем нормальных разработчиков).

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

Не может быть универсальный интерфейс у унитаза и кухонной плиты. Хотя вроде и то и то бытовая техника.

> Выше уровень абстракции, общЕе интерфейсы - вот к чему надо стремиться.

Абстракция - кастрирование в ущерб функциональности.

> Неинтересно. Хочу, чтоб компилировалось в stubs/skeletons. Чтоб машинно читаемое.

А зачем ?

> Дык dbus и есть OO RPC со своим idl.

Вот отсюда надо только убрать OO и idl.

> Или Вы про конкретную реализацию?

И про реализацию тоже.

>Я слышал, что использование солнечных батарей с 10% КПД на территории 700x700 км обеспечивает энергетические потребности всего человечества. Это намного меньше территории Сахары.

Ты что-то слышал о сроке службы таких батарей, стоимости производства - т.е. конечной стоимости киловатта?

> гарантировать это никто не может - по всему спектру ядер, поддерживаемых hal.

При наличии hal она и не понадобится.

> Как раз я обеими руками (и всеми ногами) за рациональное использование.

Plan9 namespace - вот пример разумной унификации.

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

>> Т.е. на маке не просто "много xml", там практически все настройки в XML, а что не в XML, то от лукавого.

> Во-во, типичный религиозный фоннатизм.

Я вообще-то не фанатик XML-я, но когда в системе есть очень удобное и продвинутое API аля "ПрочитайНайстройко()/ЗапишиНайстройко()", которое внутри все хранит в XML-е, то использовать что-то отличное от этого API, в большинстве случаев неразумно, по этому и от лукавого.

>когда в системе есть очень удобное и продвинутое API аля "ПрочитайНайстройко()/ЗапишиНайстройко()",[...], то использовать что-то отличное от этого API, в большинстве случаев неразумно, по этому и от лукавого.

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

> Типа долгоиграющей пирамиды которая рано или поздно валится.

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

> hal/dbus это таки некислый оверхед на который нельзя не обращать внимания.

Копеечный. Если его даже на н800 запихали. Каким образом Вы его замечаете?

> На вендора, на системный/прикладной уровень - разницы нет.

Есть разница. Она в возможности поменять вендора, когда старый перестанет нравиться по каким-то параметрам.

> Люди выбравшие целевую платформу и играющие по ее правилам

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

> Не может быть универсальный интерфейс у унитаза и кухонной плиты.

Может. Небольшой, но может. То и другое можно продавать в магазинах. То и другое можно утилизировать. О то и другое можно биться головой. Продолжать? Требуемый интерфейс зависит от задачи. Хороший интерфейс покрывает большое кол-во задач.

> Абстракция - кастрирование в ущерб функциональности.

Не всегда. Если абстракции удается предоставить интерфейс, нужный для большинства решаемых задач, и при этом дать возможность доступа к широкому классу ресурсов - она оправдана. Даже если при этом редко используемая функциональность будет потеряна или просто оставлена за пределами абстрагирования. hal не заменяет и не отменяет /dev /proc ... - он просто делает возможным решение большого кол-ва задач без обращения к этим сугубо частным средствам.

> А зачем ?

Зачем нужны stub/skeleton? Чтобы не мучаться ваянием стандартного кода, который может быть сгенерирован.

> Вот отсюда надо только убрать OO и idl.

В них вся соль. И без них оно нафиг не сдалось. Меня не греет всю жизнь программировать на pipes/signals (тем более они еще и не кросс-платформенны в некоторых деталях).

> И про реализацию тоже.

Какую именно реализацию RPM имеете в виду?

Подытаживая: да здравствуют хорошие абстрактные интерфейсы. Да сгинут детали реализации.

>Сейчас это трудно оценить, поскольку технологии меняются.

Я тебе скажу: это _как минимум_ в 5 раз дороже, чем нефть/уголь

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

угадай, какая часть этой машины самая дорогая

>> гарантировать это никто не может - по всему спектру ядер, поддерживаемых hal.

> При наличии hal она и не понадобится.

Простите, мысль не понял.

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

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

Напомнить почему зашевелился линух ?

> Если его даже на н800 запихали.

У нее далеко не слабые характеристики. А вот именно за hal и dbus в эмбеддед надо просто убивать. Именно там это вообще не оправданно ни разу.

> Она в возможности поменять вендора, когда старый перестанет нравиться по каким-то параметрам.

Ну тут лишь вопрос в желании/нежелании менять привычки и есть еще не очень хорошая сторона - наплевательское отношение к кадрам.

> И совершенно неприспособленные к жизни на других платформах.

Это все очень зависит от человека.

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

Да если список задач который он покрывает не сужается таксказать "устройством" с которым его пытаются унифицировать.

> Даже если при этом редко используемая функциональность будет потеряна

Это не есть хорошо.

> Меня не греет всю жизнь программировать на pipes/signals (тем более они еще и не кросс-платформенны в некоторых деталях).

И это тоже не есть хорошо

> да здравствуют хорошие абстрактные интерфейсы.

В разумных пределах абстрактные.

> Да сгинут детали реализации.

Только недалеко, чтоб было куда копать в случае чего.

> Простите, мысль не понял.

Ну я имел ввиду, что уход от целевой платформы на самодельные прокладки положительно на качестве нижнего уровня не скажется. Ну это так... пессимистичное ворчание ;)

> Напомнить почему зашевелился линух ? И почему?:)

> У нее далеко не слабые характеристики. Достаточно скромные. Во всяком случае, любой современный десктоп на пол-порядка мощнее. А hal/dbus сделаны в первую очередь именно для десктопа.

> А вот именно за hal и dbus в эмбеддед надо просто убивать. Возможно. Хотя, думаю, могут быть разные варианты. Например, OLPC - это эмбеддед или нет?

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

> Это все очень зависит от человека Вендор (МС) специально старается, чтобы разработчик был заблокрирован на платформе. И требуется специальное противодействие человека, чтобы этому не поддаться.

> Это не есть хорошо. Недостающую функциональность приходится восполнять частными решениями (как я сказал, у нас всегда есть /proc /dev). Но если в большинстве случаев можно обойтись без них - интерфейс можно признать относительно ("статистически") удачным.

> В разумных пределах абстрактные. Ну, мы ж говорим про разумных людей;) ИМХО hal - разумно абстрактен. Что доказывает куча софта, использующего его. Как и dbus.

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

> И почему?:)

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

> Достаточно скромные.

Угу 330 Mhz arm 128 метров памяти + графический акселератор. Для машинки такого класса это много.

> А hal/dbus сделаны в первую очередь именно для десктопа.

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

> OLPC - это эмбеддед или нет?

классический

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

Ну само собой не с голоду же помирать без МС.

> ИМХО hal - разумно абстрактен.

ИМХО он больше удобен (причем разработчику), отсюда и текущий расклад.

Вот чтоб далеко не ходить - в данный момент hald чего-то слушает на acpi (при рабочем acpid), что-то слушает на keyboard (при нативной-то поддержке ядром), и что-то слушает на сторадже. Зачем ? Acpid - нормально справляется со своими задачами. Клавиатуру и устройства ввода вполне себе нормально обслушает x-server. Со стораджами справляется udev. Зачем ?.

> Как и dbus.

Да. Особенно когда bluez-utils цепляется за него для того чтобы спросить у человека 4 цифры. От разумное применение >:)~

А вообще можно какой нибудь жизненный пример в котором ну вот никак без первого и/или второго ? Может я что-то пропустил ?