Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> AVC>А какая ОС (в смысле эффективности переключения контекстов) не из >> каменного века? >> Singularity C>Ага, конечно: C>1. Невозможность динамической подгрузки кода.
С чего бы это? Конечно же она есть. Невозможность исполнить динамический код в пределах своего же процесса — не проблема, а наоборот.
Преимущества от этого крайне велики. В частности, известный UDP вирус, поражавший MS SQL Server несколько лет назад, в принципе не смог бы сработать в Singularity.
Недостатков я не вижу — стоимость кросс-процессных вызовов настолько низка, что никаким реальным плагинным системам это не помешает. C>2. Отсутствие аппаратной защиты (и невозможность нормально использовать C>unmanaged).
Отсутствие аппаратной защиты — не недостаток, а преимущество. Стоимость аппаратной защиты неприемлемо высока. Современное веб-приложение, собравшееся отдавать 1пиксельный динамически сгенерированный gif файл, тратит основное время на переключение между ядром и worker process.
Невозможность использовать unmanaged код, в общем-то, тоже благо. Т.к. unmanaged для меня == untrusted. C>3. Опять же, нет системный поддержки для nccNUMA.
Не уверен что это неотъемлемое свойство Singularity. Во-первых, я не очень представляю, какой должна быть такая поддержка. Автоматическое распределение процессов с учетом их коммуникационных привычек для минимизации "неуниформного" трафика? Во-вторых, неясно, почему эта поддержка невозможна в Singularity, а точнее, нет уверенности в том, что поддержка nccNUMA обязательно потребует аппаратной изоляции и unmanaged кода.
C>4. Ориентированость на старое поколение железа.
Я не вижу никакой ориентированности на какое-либо железо в Singularity. Singularity в первую очередь идея, а в десятую — рабочий проект. То, что она реально существует "в железе" — это возможность поиграть с идеей не в уме, а на настоящей машинке. Я надеюсь, что все понимают, что MS никогда не выпустит Singularity в коммерческую эксплуатацию?
Или имеется в виду существует какое-то новое поколение железа, на котором нельзя будет скомпилировать Singularity?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> C>Там с этим фундаментальные проблемы (точно те же, что и с >> Обероновскими ОС, кстати). >> А в чем фундаментальность этой проблемы? >> Почему ты считаешь что динамическую загрузку кода в принципе нельзя >> реализовать? C>А как GC будет определять что ему выкинуть?
Вообще-то GC не является обязательной частью Singularity. Управление временем жизни в рамках системы может быть любым. Это было во-первых.
А во-вторых, Java уже десять с лишним лет демонстрирует GC, вполне способный определять что ему выкинуть, несмотря на не только возможность динамической загрузки кода, но и динамической загрузки загрузчиков кода
C>Подсказать какой процент оно составляет относительно остального софта?
Непрерывно растущий. И это хорошо.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>С чего бы это? Конечно же она есть. Невозможность исполнить динамический код в пределах своего же процесса — не проблема, а наоборот. S>Преимущества от этого крайне велики. В частности, известный UDP вирус, поражавший MS SQL Server несколько лет назад, в принципе не смог бы сработать в Singularity. S>Недостатков я не вижу — стоимость кросс-процессных вызовов настолько низка, что никаким реальным плагинным системам это не помешает.
Реально это не совсем так. Иногда может быть уместна динамическая компиляция и загрузка кода.
Хотябы для поддержки легаси кода написанного на жабе и .НЕТ...
Для этих целей ИМХО нужно просто выделить отдельный тип процесса и зпретить драйверам и возможно еще какимто системным сервисам работать в режиме допускающим поддержку динамической загрузки кода.
S>Невозможность использовать unmanaged код, в общем-то, тоже благо. Т.к. unmanaged для меня == untrusted.
А для меня еще и падучий. Причем самое обидное что падает не мой код, а одна библиотечка... фиксить ее не реально ибо тонна плохо спроектированного и еще хуже написанного сишного кода альтернативы еще хуже они просто не работают ...
S>Не уверен что это неотъемлемое свойство Singularity. Во-первых, я не очень представляю, какой должна быть такая поддержка. Автоматическое распределение процессов с учетом их коммуникационных привычек для минимизации "неуниформного" трафика? Во-вторых, неясно, почему эта поддержка невозможна в Singularity, а точнее, нет уверенности в том, что поддержка nccNUMA обязательно потребует аппаратной изоляции и unmanaged кода.
Я тебе больше скажу: оно их не только не требует но они даже мешают этой поддержке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Sinclair wrote: > C>А как GC будет определять что ему выкинуть? > Вообще-то GC не является обязательной частью Singularity. Управление > временем жизни в рамках системы может быть любым. Это было во-первых.
НЕТ!
GC в Singularity обязателен. Вместо него можно использовать
только статическое распределение памяти. Ручное управление памятью (а
если быть точным — ручной delete) там невозможен.
> А во-вторых, Java уже десять с лишним лет демонстрирует GC, вполне > способный определять что ему выкинуть, несмотря на не только возможность > динамической загрузки кода, но и динамической загрузки загрузчиков кода
Немного другая ситуация — смотри на давний флейм. Лень поднимать все это.
> C>Подсказать какой процент оно составляет относительно остального софта? > Непрерывно растущий. И это хорошо.
Что хорошего?
Здравствуйте, FR, Вы писали:
FR>Надо будет сделают, притом быстро, и прозрачно для пользователей, пройдет три года и на большинстве установленных компьютеров будет эта фича.
Поживем — увидим Хотя я в этом сильно сомневаюсь.
FR>А вот смена OS на абсолютно не совместимую практически не реальна, максимум такая OS займет какую нибудь узкую маргинальную нишу.
А вот и нет. Про Mac OS X никогда не слышал? Она совершенно несовместима с предыдущей версией, но старые приложения вполне благополучно выполняются в режиме эмуляции.
Здравствуйте, VladD2, Вы писали:
C>>"Embeddable Linux Kernel Subset". То что с Линуксом можно делать C>>такие извраты — это показатель его гибкости. VD>http://elks.sourceforge.net/introduction.html VD>
The goal of the ELKS project is to create a Linux-like kernel for:...
является ли линуксом то, что сделано по образу и подобию линукса?
из той же серии: является ли женщина человеком, если была сделана по образу и подобию человека?
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, FR, Вы писали:
FR>>Надо будет сделают, притом быстро, и прозрачно для пользователей, пройдет три года и на большинстве установленных компьютеров будет эта фича.
AF>Поживем — увидим Хотя я в этом сильно сомневаюсь.
Необходимости нет, так что вряд ли скоро появится.
FR>>А вот смена OS на абсолютно не совместимую практически не реальна, максимум такая OS займет какую нибудь узкую маргинальную нишу.
AF>А вот и нет. Про Mac OS X никогда не слышал? Она совершенно несовместима с предыдущей версией, но старые приложения вполне благополучно выполняются в режиме эмуляции.
Ну все-таки и старая и новая маковские операционки если сравнить их с OberonOS или Singularity практически близнецы братья. Боюсь эмуляция на новых управляемых операционках будет слишком дорогой. Кстати Эпловский переход на интеловские процессоры показывает что и неуправляемые OS и приложения на них, не так сильно зависят от аппаратуры. Да и средства виртуализации и эмуляции как программные так и аппаратные развиваются достаточно быстро, так что выгод от управляемых оперционок может и не остатся.
Здравствуйте, FR, Вы писали:
FR>Необходимости нет, так что вряд ли скоро появится.
Я думаю, вообще не появится. Управляемый код рулит
FR>Ну все-таки и старая и новая маковские операционки если сравнить их с OberonOS или Singularity практически близнецы братья.
Singularity — исследовательский проект, а OberonOS — вообще не пригодная к реальной работе поделка. Так что это не показатель.
Разница между Mac Os <= 9 и десятой версией ничуть не меньше, чем разница между linux и windows, к примеру. Я имею в виду конечно внутренности, а не интерфейс.
Так что появление новой оси, которая не совместима со старыми, но умеет исполнять их программы "в песочнице" — это абсолютно реально.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, FR, Вы писали:
FR>>Необходимости нет, так что вряд ли скоро появится.
AF>Я думаю, вообще не появится. Управляемый код рулит
Угу только парочка небольших и малозаметных аппаратных улучшений может его зарулить
FR>>Ну все-таки и старая и новая маковские операционки если сравнить их с OberonOS или Singularity практически близнецы братья.
AF>Singularity — исследовательский проект, а OberonOS — вообще не пригодная к реальной работе поделка. Так что это не показатель. AF>Разница между Mac Os <= 9 и десятой версией ничуть не меньше, чем разница между linux и windows, к примеру. Я имею в виду конечно внутренности, а не интерфейс.
Между linux и win нет принципиальной разницы, например одна небольшая фирма умудрилась сдлелать Lindows, то есть linux совместимый с win32
AF>Так что появление новой оси, которая не совместима со старыми, но умеет исполнять их программы "в песочнице" — это абсолютно реально.
Угу, только вряд ли в обозримое время это будет управляемая OS, скорее это может быть например MacOS умеющая запускать и совместимая на уровне приложений с WinXP.
Вообще подумай какой должна быть песочница для управляемых OS в которой будут запускатся неуправляемые приложения, если согласно генеральной линии партии аппаратная подержка это зло, то будет очень грустное зрелище.
Здравствуйте, FR, Вы писали:
FR>Угу только парочка небольших и малозаметных аппаратных улучшений может его зарулить
У любого аппаратного решения есть один небольшой и малозаметный, но очень серьезный недостаток. Его безумно дорого внедрить, и так же дорого внести в него любые изменения, хоть даже самые малые. И не только безумно дорого, но еще и безумно долго.
Теоретически можно сделать хоть даже "ОС на кристалле", и это наверно будет быстро — вот только практически никому не нужно.
Так что будущее — за гибкостью.
FR>Между linux и win нет принципиальной разницы, например одна небольшая фирма умудрилась сдлелать Lindows, то есть linux совместимый с win32
По-моему, они больше себя рекламировали, чем реально что-то сделали
FR>Вообще подумай какой должна быть песочница для управляемых OS в которой будут запускатся неуправляемые приложения, если согласно генеральной линии партии аппаратная подержка это зло, то будет очень грустное зрелище.
Обыкновенная эмуляция. Благодаря закону Мура, вполне реально, тем более что большинство приложений потребляют не так уж много ресурсов.
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, FR, Вы писали:
FR>>Угу только парочка небольших и малозаметных аппаратных улучшений может его зарулить
AF>У любого аппаратного решения есть один небольшой и малозаметный, но очень серьезный недостаток. Его безумно дорого внедрить, и так же дорого внести в него любые изменения, хоть даже самые малые. И не только безумно дорого, но еще и безумно долго. AF>Теоретически можно сделать хоть даже "ОС на кристалле", и это наверно будет быстро — вот только практически никому не нужно. AF>Так что будущее — за гибкостью.
Я наблюдаю совершенно другое, безумно дорого ломать именно совместимость софта, аппартные же вещи пусть и дорогие в разработке при массовом выпуске в цене стремятся к нулю. Да взять ту же х86 архитектуру, она конечно получилась и корявая в результате долгой эволюции, но прошла путь от 16 разрядного процессора с сегментированной памятью до 64 разрядного суперскалярного с аппаратной виртуализацией, и смогла впитать в себя кучу технологий которые при ее зарождении применялись только в суперкомпьютерах и стоили безумно дорого.
FR>>Между linux и win нет принципиальной разницы, например одна небольшая фирма умудрилась сдлелать Lindows, то есть linux совместимый с win32
AF>По-моему, они больше себя рекламировали, чем реально что-то сделали
А по моему ms больше потратила на адвокатов чем они на разработку.
FR>>Вообще подумай какой должна быть песочница для управляемых OS в которой будут запускатся неуправляемые приложения, если согласно генеральной линии партии аппаратная подержка это зло, то будет очень грустное зрелище.
AF>Обыкновенная эмуляция. Благодаря закону Мура, вполне реально, тем более что большинство приложений потребляют не так уж много ресурсов.
Обыкновенная эмуляция это полная ж.. Никто ни купит операционку в которой старые приложения выполняются на порядок медленее чем на старой.
Здравствуйте, FR, Вы писали:
FR>Я наблюдаю совершенно другое, безумно дорого ломать именно совместимость софта
А как же пример Мак Оси?
FR>аппартные же вещи пусть и дорогие в разработке при массовом выпуске в цене стремятся к нулю.
Не надо путать цену массового выпуска устройства и цену внедрения новой фичи. Вторая — намного, очень намного больше.
FR>Обыкновенная эмуляция это полная ж.. Никто ни купит операционку в которой старые приложения выполняются на порядок медленее чем на старой.
Здравствуйте, FR, Вы писали:
AF>>Я думаю, вообще не появится. Управляемый код рулит FR>Угу только парочка небольших и малозаметных аппаратных улучшений может его зарулить
Никакие аппаратные улучшение не смогут гарантировать защиту внутри процесса.
Для того чтобы гарантировать защиту внутри процесса необхождима прорва метаинформации. Эту метаинформацию нужно гдето взять. (Где?) Далие по этой метаинформации нужно постоянно все контролировать что приведет к очень сильному усложнению железа.
Короче это тупиковый путь.
Гораздо эффективней сделать тупую железку (ну можетбыть оставить предсказатель ветвлений) которая только и умеет что быстро считать, а контролировать целостность рантайм проверками которые раставлены только там где они реально нужны(все остальые можно убрать статическим анализом кода).
FR>Вообще подумай какой должна быть песочница для управляемых OS в которой будут запускатся неуправляемые приложения, если согласно генеральной линии партии аппаратная подержка это зло, то будет очень грустное зрелище.
Ну эту линию партии ты сам придумал... пока есть гигатонны легаси железа управляемые ОС вполне могут создавать аппаратно изолированные песочници для неуправляемого софта.
Также нужно учесть что управляемые ОС могут легко исполнять бинарники .NET'а и жабы (если там нет unsafe и JNI) сюда же относятся всевозможные скрипты типа питона, перла, руби итп
Те подавляющие большинство веб серверов можно будет очень легко перенести на эту ОС. Причем они получат неплохую прибавку к производительности.
Еще у управляемых ОС есть одна весьма циничная особенность... по началу они могут работать по верх классических ОС в том же стиле что .NET и жаба...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndreiF, Вы писали:
AF>Здравствуйте, FR, Вы писали:
FR>>Я наблюдаю совершенно другое, безумно дорого ломать именно совместимость софта
AF>А как же пример Мак Оси?
У них не было из-за этого проблем и потери приличного куска рынка?
Зато сейчас смена процессора наооборт помогла завоевать приличный кусок рынка.
FR>>аппартные же вещи пусть и дорогие в разработке при массовом выпуске в цене стремятся к нулю.
AF>Не надо путать цену массового выпуска устройства и цену внедрения новой фичи. Вторая — намного, очень намного больше.
Ну и какова цена внедрения 64 разрядности в x86?
FR>>Обыкновенная эмуляция это полная ж.. Никто ни купит операционку в которой старые приложения выполняются на порядок медленее чем на старой.
AF>Закон Мура, не забывай.
При просадке на порядок (для обыкновенного эмулятора без jit и тех оптимизации которые будут невозможны на управляемой OS без потери контроля над безопасностью выполнения кода) закон Мура слабое утешение.
Здравствуйте, WolfHound, Вы писали:
AF>>>Я думаю, вообще не появится. Управляемый код рулит FR>>Угу только парочка небольших и малозаметных аппаратных улучшений может его зарулить WH>Никакие аппаратные улучшение не смогут гарантировать защиту внутри процесса. WH>Для того чтобы гарантировать защиту внутри процесса необхождима прорва метаинформации. Эту метаинформацию нужно гдето взять. (Где?) Далие по этой метаинформации нужно постоянно все контролировать что приведет к очень сильному усложнению железа.
Может, я чего не понимаю.
Но мне всегда нравилось, что в Обероне защиту внутри процесса гарантировал компилятор.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, FR, Вы писали:
FR>У них не было из-за этого проблем и потери приличного куска рынка?
У тебя есть точные данные, что причина финансовых потерь — это именно выпуск новой ОСи?
FR>Ну и какова цена внедрения 64 разрядности в x86?
За такую информацию вообще-то немаленькие деньги аналитикам платят
А вообще, интересное место — форум философии. Никогда бы не подумал, что найдется человек, который будет доказывать, что внести изменения в железо — проще, чем в софт
FR>При просадке на порядок (для обыкновенного эмулятора без jit и тех оптимизации которые будут невозможны на управляемой OS без потери контроля над безопасностью выполнения кода) закон Мура слабое утешение.
Всё зависит от степени различия у исходной и целевой платформ. Делать какие-то догадки даже о величине порядка — брать цифры просто с потолка.
Здравствуйте, AVC, Вы писали:
WH>>Никакие аппаратные улучшение не смогут гарантировать защиту внутри процесса. WH>>Для того чтобы гарантировать защиту внутри процесса необхождима прорва метаинформации. Эту метаинформацию нужно гдето взять. (Где?) Далие по этой метаинформации нужно постоянно все контролировать что приведет к очень сильному усложнению железа.
AVC>Может, я чего не понимаю. AVC>Но мне всегда нравилось, что в Обероне защиту внутри процесса гарантировал компилятор.
1) Гм какое отношение имеет оберон к наезду на аппаратную защиту программного обеспечения?
2) Нихрена он не гарантирует. Злой хакер может пригнать хитро пропатченый бинарник и все гарантии оберона идут в лес.
3) На это
_rasta wrote:
> является ли линуксом то, что сделано по образу и подобию линукса?
ну по крайней мере
Q1.2. How does ELKS compare with standard Linux?
ELKS is intended to be a subset of true Linux
http://elks.sourceforge.net/FAQ-English.html#1.2
> из той же серии: является ли женщина человеком, если была сделана по > образу и подобию человека?
Вообще-то не была. Это человек был сделан по образу и подобию бога.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, WolfHound, Вы писали:
WH>>>Никакие аппаратные улучшение не смогут гарантировать защиту внутри процесса. WH>>>Для того чтобы гарантировать защиту внутри процесса необхождима прорва метаинформации. Эту метаинформацию нужно гдето взять. (Где?) Далие по этой метаинформации нужно постоянно все контролировать что приведет к очень сильному усложнению железа.
AVC>>Может, я чего не понимаю. AVC>>Но мне всегда нравилось, что в Обероне защиту внутри процесса гарантировал компилятор.
WH>1) Гм какое отношение имеет оберон к наезду на аппаратную защиту программного обеспечения? WH>2) Нихрена он не гарантирует. Злой хакер может пригнать хитро пропатченый бинарник и все гарантии оберона идут в лес.
На случай злобного хакера, можно подумать о технологии "тонких бинарников".
Модуль попадает в систему в полукомпилированном виде, докомпилируется при загрузке.
В принципе, можно докомпилировать один раз, потом грузить бинарник.
WH>3) На это
Будет.
Но мне надо хоть немного подумать, а у меня сейчас аврал.
Потому пока ограничиваюсь короткими репликами, когда кажется, что об этом больше никто не скажет.
Вон утверждают, что Оберон — поделка, а я ничего — я терплю.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
1.1.4 stable rev. 510
альтернативы еще хуже 
Хотя я в этом сильно сомневаюсь.
