> Как вы относитесь к тем, чей мозг овладёван XML? Может их уже изолировать надо?
Если хочешь что-то развалить - возглавь это. Организуй этих извращенцев - пусть кропают с нуля "принципиально новый", "политически правильный", "первый и единственный в своём роде" (можно ещё русский, посконный, православный, но это на любителя) дистрибутив полностью на xml - и пусть копошатся там, как черви. Заодно спасёшь от этой заразы нормальные дистры. А гомункулюс всё равно сдохнет :)
Макос получиццо - там довольно много xml. А вот вы лучше сделайте дистрибутив совсем без xml. Интересно, на что это будет похоже. ЖОсткая такая аскеза должна выйти.
Не просто без гнома. Всякие hal-ы c dbus-ами (и все, что их использует) - тут же вылетает в трубу. В общем, получится что-то типо линуха середины 90х, только версии свежие.
Ну я вообще даже не о Linux говорил. Делают люди проект. Используют WebServices для взаимодействия частей. То есть RPC поверх SOAP(XML), а в вызовах строками передают XML который потом руками разбирают и накладывают на него другой XML, чтобы на выходе получить XML из которого посредством XSLT будут строить xHTML (который еще и подмножество SGML).
> Не просто без гнома. Всякие hal-ы c dbus-ами (и все, что их использует) - тут же вылетает в трубу. В общем, получится что-то типо линуха середины 90х, только версии свежие.
Так и есть, но если DE как таковое не нужно - то и всё очень даже здорово будет. vim/bash/80x25 - наше всё ;)
Ну Вы хоть бы посмотрели, сколько информации предоставляет hal. Причем способом, не зависящим от конкретных драйверов. И даже ОС. Как Вы предлагаете это все реализовывать, если у Вас есть только файлы устройств? Кстати, чтобы эту информацию мог получать пользователь, у которого нет прав на чтение-запись в соотв. устройства, без повышения прав через sudo.
> IPC во втором ?
В каком из традиционных IPC можно специфицировать интерфейсы, при этом автоматически генерировать код для stubs?
> Даже не смешно.
Это я подстраховался на тот случай, если бы кто-нибудь произнес слово CORBA.
> Это унификация+ускорение разработки в ущерб производительности.
Это важно. Это мощный плюс. Железо дешево (уже даже в мобильных устройствах - в n800, например). Рабсила дорогая (даже индийская).
> Это все гонка за кол-вом целевых платформ.
И это тоже неплохо.
> Как не раз уже советовал Танненбаум стандартизировать интерфейсы на уровне ядра.
Мы же знаем, что этого нет - и скорее всего, не будет. Не говоря о том, что в мире есть еще бсд, солярка и про аихи..
> tcp/ip ? Странно но тем не менее.
В tcp?? Научите, где там формально можно описать интерфейс? Где там IDL? RFC не предлагать - он не является машинно-читаемым документом. Кстати, я просил без потери производительности.
> А если бы кто-нибудь сказал ASN ?
Это немного из другой оперы AFAIK. И еще ужаснее, чем корба ИМХО.
В hal есть некоторое кол-во собственного кода по обработке этой информации. И собственные файлы с данными, которые недоступны из ядра (потому что ядру не нужны).
Фишка в том что оно дешевеет весьма относительно. И если делить производительность железа на время системы и время пользователя. Большая часть стоимости таки уходит на переферию (которая не сильно изменилась).
> И это тоже неплохо.
Это вообще ужасно. Стирая границы целевого применения различных ОС мы получаем везде неповоротливую кучу костылей.
> Мы же знаем, что этого нет - и скорее всего, не будет.
Теперь скорее всего нет.
> RFC не предлагать
"Этокакэто ?" IDL там таки есть, не в полном понимании термина, но скажем так для прослойки между стулом и клавиатурой. Машиночитаемым сделать можно все но вот машинопонимаемым ниразу. Коряво выразился но
маразм вроде <preved param="medved"/> без рукописного DTD нифига никому ничего не скажет.
> Это немного из другой оперы AFAIK.
Да чет смаху брякнул сюда не хватает RPC. Так было бы точнее.
Это и есть плюс. Плюс - увеличение пользовательской базы и базы разработчиков.
> Фишка в том что оно дешевеет весьма относительно.
Важно то, что оно уже достаточно дешево-быстро, чтобы не обращать внимания на накладные расходы типа 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.
> Макос получиццо - там довольно много xml. А вот вы лучше сделайте дистрибутив совсем без xml. Интересно, на что это будет похоже. ЖОсткая такая аскеза должна выйти.
А чё, у правильных потсанов бывают только крайности - либо везде, либо совсем не? Просто рациональное использование технологий там, где они действительно дают преимущества, - это для плебеев?
Я слышал, что использование солнечных батарей с 10% КПД на территории 700x700 км обеспечивает энергетические потребности всего человечества.
Это намного меньше территории Сахары.
>Я слышал, что использование солнечных батарей с 10% КПД на территории 700x700 км обеспечивает энергетические потребности всего человечества. Это намного меньше территории Сахары.
Ты что-то слышал о сроке службы таких батарей, стоимости производства - т.е. конечной стоимости киловатта?
Сейчас это трудно оценить, поскольку технологии меняются. Но поскольку машины с электродвигателями - уже реальность, то, по всей видимости, необходимость в горючих энергоносителях существенно упадет.
>> Т.е. на маке не просто "много xml", там практически все настройки в XML, а что не в XML, то от лукавого.
> Во-во, типичный религиозный фоннатизм.
Я вообще-то не фанатик XML-я, но когда в системе есть очень удобное и продвинутое API аля "ПрочитайНайстройко()/ЗапишиНайстройко()", которое внутри все хранит в XML-е, то использовать что-то отличное от этого API, в большинстве случаев неразумно, по этому и от лукавого.
>когда в системе есть очень удобное и продвинутое API аля "ПрочитайНайстройко()/ЗапишиНайстройко()",[...], то использовать что-то отличное от этого API, в большинстве случаев неразумно, по этому и от лукавого.
Правильно, поэтому хорошие программы под винду хранят все свои настройки в реестре.
> Типа долгоиграющей пирамиды которая рано или поздно валится.
А к чему еще стремиться технологии, как не к захвату рынка - в первую очередь через привлекательность для разработчиков? Запертые в нишу технологии мрут, и поделом.
> hal/dbus это таки некислый оверхед на который нельзя не обращать внимания.
Копеечный. Если его даже на н800 запихали. Каким образом Вы его замечаете?
> На вендора, на системный/прикладной уровень - разницы нет.
Есть разница. Она в возможности поменять вендора, когда старый перестанет нравиться по каким-то параметрам.
> Люди выбравшие целевую платформу и играющие по ее правилам
И совершенно неприспособленные к жизни на других платформах. Фактически, находящиеся в рабстве у вендора (и зависящие от его милости, поломать или не поломать совместимость в версии n+1). И еще. Именно любовь производителей к своим нишевым-платформенным фишкам и убила уних.
> Не может быть универсальный интерфейс у унитаза и кухонной плиты.
Может. Небольшой, но может. То и другое можно продавать в магазинах. То и другое можно утилизировать. О то и другое можно биться головой. Продолжать? Требуемый интерфейс зависит от задачи. Хороший интерфейс покрывает большое кол-во задач.
> Абстракция - кастрирование в ущерб функциональности.
Не всегда. Если абстракции удается предоставить интерфейс, нужный для большинства решаемых задач, и при этом дать возможность доступа к широкому классу ресурсов - она оправдана. Даже если при этом редко используемая функциональность будет потеряна или просто оставлена за пределами абстрагирования. hal не заменяет и не отменяет /dev /proc ... - он просто делает возможным решение большого кол-ва задач без обращения к этим сугубо частным средствам.
> А зачем ?
Зачем нужны stub/skeleton? Чтобы не мучаться ваянием стандартного кода, который может быть сгенерирован.
> Вот отсюда надо только убрать OO и idl.
В них вся соль. И без них оно нафиг не сдалось. Меня не греет всю жизнь программировать на pipes/signals (тем более они еще и не кросс-платформенны в некоторых деталях).
> И про реализацию тоже.
Какую именно реализацию RPM имеете в виду?
Подытаживая: да здравствуют хорошие абстрактные интерфейсы. Да сгинут детали реализации.
Plan9 - это замечательно. В условиях подобной платформы вообще четверть гнома можно было б выкинуть. Беда в том, что решение требовалось для существующих мейнстримовских платформ.
Ну я имел ввиду, что уход от целевой платформы на самодельные прокладки положительно на качестве нижнего уровня не скажется. Ну это так... пессимистичное ворчание ;)
> Напомнить почему зашевелился линух ?
И почему?:)
> У нее далеко не слабые характеристики.
Достаточно скромные. Во всяком случае, любой современный десктоп на пол-порядка мощнее. А 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 цифры. От разумное применение >:)~
А вообще можно какой нибудь жизненный пример в котором ну вот никак без первого и/или второго ? Может я что-то пропустил ?