VladD2 wrote: > C>Что значит "partition"? Размер swap-файла или swap-раздела? > Незнаю как сейчас. А тогда в Линуксе понятия swap-файл просто не было. > Предлагалось создать отдельный раздел (причем если не ошибаюсь специальный).
Линукс может использовать для swap'а любое блочное устройство или файл —
можно при желании своп через сеть подмонтировать, а еще я как-то ради
шутки сделал swap на ramdisk'е.
VladD2 wrote: > C>Нет. WinXP просто не может работать на 486 — нет нужного HALа. > Я вообще-то о P90 говорил. А на 486 с 1 метром и Линукс на запустится. А > на 8088 вообще только ДОС пойдет.
На 1 метре — пойдет. Правда кроме ядра мало что будет.
VD>У меня все ассоциируется нормально. А вот у OMG явно через зад. Причины очень просты. Решили создать штуку в рекламе которой можно было бы ипользовать модные слова (тогда компонентность была модной).
Компонент — это самоописываемая бинарная сущность. С этой точки зрения все OK. И ничего там не через зад, ты неправильно понимаешь работу OMG. Они не делают реализаций, они разрабатывают стандарты, которые рельно можно реализовать на очень многих платформах и языках. Это идет как ТЗ. Причем, что характерно для CORBA, все ее стандарты даются в виде обычно очень простых (малословных) интерфейсов, т.е. определяются лишь самые обобщенные моменты. Для возможностей КОП они ввели рефлексию с инвоками и что-то вроде службы активации. Что еще надо? Кстати, дополнительно описали стандарты на персистенцию состояний компонентов (сперли у OLE2, очевидно). Тоже весьма удобно.
КОП именно требовали от OMG, и вот они им дали... хотя мне лично трудно представить необходимость самоописания компонентов в работающей системе, ибо обычно интерфейсы интересующих служб известны в дизайн-тайм. Ну разве что для ср-в монитора и диагностики можно юзать компонентные закидоны. Или же когда-нить наступит время, когда мы свои программы будем строить из взаимодействующих по всему миру сетевых служб, а не компиляторами на наших машинах.
VD>На практике же КОП в Корба нет и никто даже не использует эту спецификацию.
В CORBA очень много служб и протоколов, которые мало где используются, ибо CORBA — это большой набор основных (системных) стандартов и служб. Для каждого приложения в отдельности может понадобится лишь малая часть из набора стандартов OMG.
VD>И вообще КОРБА теперь рассматривается как низкий уровень (уровень протколов) для Явовских технологий. И то не всеми. Многие на Корбу вообще забили. Вот Борладн с ней до сих пор мучается. Но это их проблемы.
Ну вот мы пока используем для связи C++ и .Net технологий. И ведь альтернативы никакой. А по экономичности трафика Корбу можно записывать в чемпионы. Сетевой протокол CORBA очень продуман, и легко расширяем, в отличие от ремотинга донета. Я имею ввиду, что если будет желание, например, как-то расширить стандартный ремотинг путем своих каналов или там еще чего (для передачи, скажем, неких атррибутов, привязанных к конкретным вызовам методов удаленных объектов), то это вступит в конфликт с другими компонентами системы, которые это расширение не поддерживают. В CORBA протокол можно безболезненно обогащать произвольными кастомными данными, не боясь за работоспособность "всего остального".
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>У меня все ассоциируется нормально. А вот у OMG явно через зад. Причины очень просты. Решили создать штуку в рекламе которой можно было бы ипользовать модные слова (тогда компонентность была модной).
V>Компонент — это самоописываемая бинарная сущность.
Главное свойство компонента — возможность автономного использования как независимого модуля. А это значит динамическая загрузка и независимость от какх-то там сервисов.
V> С этой точки зрения все OK.
Никакого ОК там нет.
V> И ничего там не через зад, ты неправильно понимаешь работу OMG. Они не делают реализаций, они разрабатывают стандарты,
Они занимаются херней. И практика это подтверждает.
V>Кстати, дополнительно описали стандарты на персистенцию состояний компонентов (сперли у OLE2, очевидно). Тоже весьма удобно.
В Корбе "персистентность" была сто лет назад. У них вообще идея о долгоживущих (то есть живущих дольше жизни экземпляра) объектах была "идей фикс".
Как компонентную модель Корбу никто так и не использует.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Он может ОТДАТЬ ее, а не продать.
Лицензия распростроняется на тех кто пользуется ОП, а не на тех кому оно на фиг не упало и кто хочет его продать. Продавая ПО я не являюсь "конечным пользователем" и на меня не распростроняется EULA.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
AVC>>Я только хотел сказать, что ведь можно использовать активные объекты и в рамках отдельных процессов (чем это хуже thread-ов), не сводя все к выбору "или-или, а третьего не дано". WH>А зачем они вобще нужны если есть каналы и потоки?
Думается, для того же, для чего нужны безопасные языки и сборка мусора, — для надежности.
Активные объекты — развитие мониторов Хансена и Хоара, а мониторы всяко надежнее бессистемного управления потоками.
В каком-то смысле — это та же инкапсуляция (данных, потоков и блокировок).
WH>Просто там нет анализа того что произойдет на системах где нет неприрывной памяти. Те есть куча процессоров и у каждого своя память. Таже фигня и с кластерами. Ну нет там общей памяти...
И отсюда следует, что не надо использовать общую память и тогда, когда она есть?
AVC>>Запомнилось, что системный вызов в Aos примерно в 30 раз эффективнее системного вызова в Linux. WH>Ну и какой смысл сравнивать с ОС из каменного века?
А какая ОС (в смысле эффективности переключения контекстов) не из каменного века?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
V>>Компонент — это самоописываемая бинарная сущность.
VD>Главное свойство компонента — возможность автономного использования как независимого модуля. А это значит динамическая загрузка и независимость от какх-то там сервисов.
Когда давали определение, то там еще было что-то проде этого: "предназначенного для работы в определенном окружении".
И как ты себе хотя бы в дотнете представляешь активацию серверного объекта по-требованию без наличия специального сервиса с неким протоколом на целевой машине?
V>>Кстати, дополнительно описали стандарты на персистенцию состояний компонентов (сперли у OLE2, очевидно). Тоже весьма удобно.
VD>В Корбе "персистентность" была сто лет назад.
Не знаю насчет что лет назад. В IDL никакая персистентность не поддерживалась. Были только утверждены пара интерфейсов-хранилищ, но там можно хранить все что угодно, не только объекты. Сейчас же речь идет о том, чтобы перемещать объекты по гетерогенной сети. Т.е. чтобы передать объект Java по значению в Delphi-программу, поработать с объектом, и отправить его жить дальше куда-нить в дотнет.
VD>Как компонентную модель Корбу никто так и не использует.
И как же ее можно использовать, если еще реализаций и инструментария нет?
Ты чего-то не понимаешь, ИМХО. Возьми несколько основных интерфесов из иерархии MemberInfo и Type дотнета. Оставь только самые необходимые методы и св-ва этих интерфейсов (избавляться надо от специфичных для дотнета методов и св-в). И ты получишь некий стандарт на рефлексию. Добавь сюда описание протоколов активации серверных объектов, и ты получишь примерно то, что родили в OMG, т.е. голые спецификации, которыми разве что утереться можно, пока не будет имплементации.
Кстати, взгляни на реализацию интерпретатора и объектов JScript в дотнете. Там используется такая же точно иерархия от MemberInfo для описания структуры динамических (не скомпилированных в байт-код) JavaScript-объектов. Т.е. налицо несколько реализаций определенного стандарта на предоставление метаинформации в дотнете.
VladD2 wrote: > C>На 1 метре — пойдет. Правда кроме ядра мало что будет. > Современный то? Не уверен.
Ядро 2.6.16 спокойно работает на встроенных устройствах. Кажется, там
ему что-то около 300Кб памяти по минимуму надо (если отключить все, что
только можно).
> C>И на 8088 тоже пойдет — http://elks.sourceforge.net/ > Это не Линукс.
"Embeddable Linux Kernel Subset". То что с Линуксом можно делать
такие извраты — это показатель его гибкости.
Здравствуйте, AVC, Вы писали:
AVC>Думается, для того же, для чего нужны безопасные языки и сборка мусора, — для надежности. AVC>Активные объекты — развитие мониторов Хансена и Хоара, а мониторы всяко надежнее бессистемного управления потоками. AVC>В каком-то смысле — это та же инкапсуляция (данных, потоков и блокировок).
А теперь попробуй объяснить чем синхронизация на активнах объектах лучше чем синхронизации на каналах?
Через каналы можно посылать только строготипизированные сообщения.
В сообщении могут передаватся данные либо по значению либо ссылки на данные в общей памяти. Это нужно для того чтобы гарантировать изолированность объектных простанств процессов. При передачи ссылки на общие данные в другое адресное пространство в том числе на другой компьютер данные копируются.
Для каждого канала описан протокол общения представляющий из себя конечный автомат.
Для каждого состояния этого автомата гарантируется что из него можно либо только посылать либо только принимать сообщения. Это нужно для того чтобы гарантировать отсутствие дедлоков на одном канале.
Если при попытке получить сообщения из канала там ничего не будет то поток блокируется до поступления в канал сообщения или закрытия канала. Возможна установка таймаута в том числе нулевого тогда управление будет возвращено немедленно. Также возможно ожидание на нескольких каналах.
AVC>И отсюда следует, что не надо использовать общую память и тогда, когда она есть?
Если тебе нужно используй. Хотя большинство систем прекрасно режутся на кучу мелких процессов. Создай один процесс с кучей потоков и общайся между потоками через каналы. Болие того для каналов работающих исключительно внутри одного процесса можно отменить ограничеие на передачу данных по ссылке.
AVC>А какая ОС (в смысле эффективности переключения контекстов) не из каменного века?
Singularity
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > AVC>А какая ОС (в смысле эффективности переключения контекстов) не из > каменного века? > Singularity
Ага, конечно:
1. Невозможность динамической подгрузки кода.
2. Отсутствие аппаратной защиты (и невозможность нормально использовать
unmanaged).
3. Опять же, нет системный поддержки для nccNUMA.
4. Ориентированость на старое поколение железа.
Всего то навсего. Конструкторы Intel и AMD уже побежали вносить поддержку во все новые процессоры, а пользователи стройными рядами понесли свои компьютеры на свалку.
AF>Всего то навсего. Конструкторы Intel и AMD уже побежали вносить поддержку во все новые процессоры, а пользователи стройными рядами понесли свои компьютеры на свалку.
Надо будет сделают, притом быстро, и прозрачно для пользователей, пройдет три года и на большинстве установленных компьютеров будет эта фича. Например сейчас также неощутимо вводится 64 разрядность и подержка виртуализации. А вот смена OS на абсолютно не совместимую практически не реальна, максимум такая OS займет какую нибудь узкую маргинальную нишу.
> Всего то навсего. Конструкторы Intel и AMD уже побежали вносить > поддержку во все новые процессоры, а пользователи стройными рядами > понесли свои компьютеры на свалку.
Эта фича (Fast Address Space Switching) будет абсолютно прозрачна для
старых приложений. Так что через несколько лет после ее внедрения, она
появится на большинстве компьютеров. А там и ОСки подоспеют.
Так сейчас с 64-битами происходит, почти все новые системы поддерживают
x64.
Здравствуйте, Cyberax, Вы писали:
C>Ага, конечно: C>1. Невозможность динамической подгрузки кода.
Это решение конкретной реализации. Оно может быть очень легко преадалено в болие позней версии.
Например сравни первые UNIX'ы (или даже UNICS ИМХО Singularity находится примерно на тойже стадии) с современными Linux'ами. C>2. Отсутствие аппаратной защиты (и невозможность нормально использовать unmanaged).
Ну в обероновских ОС теже проблемы... К тому же ИМХО это нахрен не упало. C>3. Опять же, нет системный поддержки для nccNUMA.
Чего простите? Что может леч на nccNUMA лучше чем множество изолированных процессов которые обмениваются сообщениями? C>4. Ориентированость на старое поколение железа.
Это вобще не понял.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>1. Невозможность динамической подгрузки кода. > Это решение конкретной реализации. Оно может быть очень легко преадалено > в болие позней версии. > Например сравни первые UNIX'ы (или даже UNICS ИМХО Singularity находится > примерно на тойже стадии) с современными Linux'ами.
Там с этим фундаментальные проблемы (точно те же, что и с Обероновскими
ОС, кстати).
> C>2. Отсутствие аппаратной защиты (и невозможность нормально > использовать unmanaged). > Ну в обероновских ОС теже проблемы... К тому же ИМХО это нахрен не упало.
Именно. Подсказать где сейчас Оберон-ОСи?
> C>3. Опять же, нет системный поддержки для nccNUMA. > Чего простите? Что может леч на nccNUMA лучше чем множество > изолированных процессов которые обмениваются сообщениями?
Возможность явного управления барьерами, поддержка понятия "близости" на
уровне языка (см. COMA — http://en.wikipedia.org/wiki/Cache_only_memory_architecture ). Много
чего еще можно придумать.
> C>4. Ориентированость на старое поколение железа. > Это вобще не понял.
Не используются возможности виртуализации, например.
Здравствуйте, Cyberax, Вы писали:
C>Там с этим фундаментальные проблемы (точно те же, что и с Обероновскими ОС, кстати).
А в чем фундаментальность этой проблемы?
Почему ты считаешь что динамическую загрузку кода в принципе нельзя реализовать?
Кстати сейчас придут оберонщики и объяснят что в ОберонОС можно динамически подгружать код ибо они специально для этого проектировались.
>> Ну в обероновских ОС теже проблемы... К тому же ИМХО это нахрен не упало. C>Именно.
Подсказать сколько софта вобще не использует небезопасные языки? И колличество такого софта растет. C>Подсказать где сейчас Оберон-ОСи?
У ОберонОС очень много других проблем не связанных с этой. Она однопользовательская, ее модель ну совершенно не ложится на туже nccNUMA и что сейчас болие актуально на кластеры, в ней не реализованна проверка загружаемого кода... И заметь эти проблемы настолько крупные и фундаментальные что ОберонОС нельзя использовать в реальном мире.
C>Возможность явного управления барьерами, поддержка понятия "близости" на уровне языка (см. COMA — http://en.wikipedia.org/wiki/Cache_only_memory_architecture ). Много чего еще можно придумать.
Я вобщето всегда говорил что виртуальная машина у Singularity мягко говоря уродская.
Тем не мение сама по себе модель мелких изолированных процессов ложится на nccNUMA лучше чем чтобыто нибыло еще. Просто по тому что данные шарить не нужно.
А если таки нужно шарить данные то есть очень простое решение: шаренные данные должны быть не изменяемы.
C>Не используются возможности виртуализации, например.
Опять же критикуя ИДЕЮ ты докапываешься до КОНКРЕТНОЙ РЕАЛИЗАЦИИ.
Давай я сейчас проедусь по Linux основываясь на UNICS... Ы?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Там с этим фундаментальные проблемы (точно те же, что и с > Обероновскими ОС, кстати). > А в чем фундаментальность этой проблемы? > Почему ты считаешь что динамическую загрузку кода в принципе нельзя > реализовать?
А как GC будет определять что ему выкинуть?
> Кстати сейчас придут оберонщики и объяснят что в ОберонОС можно > динамически подгружать код ибо они специально для этого проектировались.
А он там вечно висит.
>> > Ну в обероновских ОС теже проблемы... К тому же ИМХО это нахрен не упало. > C>Именно. > Подсказать сколько софта вобще не использует небезопасные языки? И > колличество такого софта растет.
Подсказать какой процент оно составляет относительно остального софта?
> Тем не мение сама по себе модель мелких изолированных процессов ложится > на nccNUMA лучше чем чтобыто нибыло еще. Просто по тому что данные > шарить не нужно. > А если таки нужно шарить данные то есть очень простое решение: шаренные > данные должны быть не изменяемы.
Простое — не значит правильное. Это один из самых простых вариантов, но
он далеко не всегда подходит.
> C>Не используются возможности виртуализации, например. > Опять же критикуя ИДЕЮ ты докапываешься до КОНКРЕТНОЙ РЕАЛИЗАЦИИ. > Давай я сейчас проедусь по Linux основываясь на UNICS... Ы?
Можешь хоть катком проехаться по реализации ядра Linux 2.6.18. Я катком
проедусь по реализации S. Ок?
Здравствуйте, Cyberax, Вы писали:
>> Почему ты считаешь что динамическую загрузку кода в принципе нельзя реализовать? C>А как GC будет определять что ему выкинуть?
Гм??? А в чем проблема? В жабе же определяет
C>А он там вечно висит.
Ну дык ОберонОС то еще угребище... с этим я не спорю.
C>Подсказать какой процент оно составляет относительно остального софта?
Что-то мне подсказывает что заметный. И этот процент всевремя ростет.
C>Простое — не значит правильное. Это один из самых простых вариантов, но он далеко не всегда подходит.
Для этого нужно просто учесть это в ВМ. Для боевой реализации сингулярити нужно проектировать ВМ с нуля, а не брать учребище типа CLR или жабы.
C>Можешь хоть катком проехаться по реализации ядра Linux 2.6.18. Я катком проедусь по реализации S. Ок?
Нет не так. Я проедусь по UNICS и прировняю этот проезд к Linux 2.6.18. Как это будет выглядеть?
Примерно также выглядит твои наезды на прототип который показал верность направления но и выявил кучу просчетов авторов данной реализации. Для меня сингулярити это не конкретная ОС от мелкософт ресерч, а прежде всего идея того как это все должно быть сделано.
Кстати насчет линуха... как там у него дела с nccNUMA? А с кластеризацией?
Только не нужно говорить что все хорошо... я сейчас работаю в конторе у которой несколько линуксовых кластеров..., а я пишу еще один.
Так вот архитектура линукса как минимум не помогает мне решать мои задачи.
В прочем наезд на линух я отложу до времен когда наберу побольше страшилок...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
