Здравствуйте, Cyberax, Вы писали:

[]

S>>А публичные методы у capability таковы, что ее содержимое в принципе immutable. Всё, что можно сделать — это получить копию capability с меньшими привилегиями.
C>На самом деле, ещё обычно есть механизмы обмена capability. Т.е. процессы могут безопасно ими меняться, что тоже прекрасно ложится на систему типов.

Господа. О какой [системе типов] может идти речь, когда наличие capability определяется тем, есть у тебя на нее не-null ссылка или нет?

Либо я чего-то не понимаю, либо вместо магического и сокрушительного [система типов] стоит писать [архитектура]?

[]

Здравствуйте, Sinclair, Вы писали:

[]

C>>Очевидно, что привиллегированый процесс держит capability, позволяющую создавать другие capability Что тут непонятного?
S>Непонятно, какова гранулярность этой capability. Вот простой пример: capability на доступ к файлу. Винда выделяет что-то вроде 12 привилегий для файлового объекта. Мне (непривилегированному) дают только готовый файловый хэндл, открытый, допустим, в режиме read-only. Его выдает кто-то, кто имеет на это право.
S>Ок, допустим у него был full access хэндл, он склонировал его с понижением привилегий до read-only. Это пока понятно. Непонятно, какие именно привилегии были у того, кто создал тот full access handle?
S>Даже это мне не вполне понятно как реализовать с помощью системы типов. Ну то есть если у нас набор допустимых операций над файлом однозначно определяется типом хэндла, то нужны 2^12 типов для хэндлов, с соответствующими правилами преобразования типов (так, чтобы нельзя было сконструировать высокопривилегированную ссылку из низкопривилегированной).

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

[]

Здравствуйте, Константин Л., Вы писали:

КЛ>Господа. О какой [системе типов] может идти речь, когда наличие capability определяется тем, есть у тебя на нее не-null ссылка или нет?
КЛ>Либо я чего-то не понимаю, либо вместо магического и сокрушительного [система типов] стоит писать [архитектура]?
Конечно не понимаешь.
Ибо без защиты со стороны системы типов вся архитектура и как следствие вся безопасность полетит к чертям после первого же любителя срезать углы.

Здравствуйте, nme, Вы писали:

nme>Если я правильно тебя понял, то у Майкрософт лет 15 назад был такой проект (Warp OS кажется). В общем это была исследовательская ОС, которая могла ход выполнения программы менять на противоположный и обратно в любой момент времени. Сейчас они хотят включить те наработки в CLR.

Я хочу сказать вот чего. Работу с базой данных можно значительно ускорить, если собирать транзакции в кучки — потому что транзакция кончается, когда данные уже на диске, а это seek головками, а это очень долго, по сравнению с любой другой дисковой операцией.

Однако программировать так довольно неудобно. Поэтому можно было бы программе сказать, что транзакция уже закончилась, у пусть себе бежит спокойно, пока транзакция либо правда не закончится, либо программа не собиралась сказать кому-то наружу, что транзакция закончилась (и даже эту попытку сказать наружу можно попридержать — реально программа может бежать до того места, когда она сказала, что транзакция закончилась, и хочет что-то получить в ответ). Беда однако в том, что если в конечном итоге транзакция закончится неудачно, а мы программе уже наврали, что все ОК, поличится нехорошо. И вот в этот момент можно бы откатить программу до того места, где мы ей наврали то, что в конечном итоге оказалось неправдой, и пустить ее по новой, но уже сказав ей правду.

То же самое относится к любому дисковому вводу-выводу.

Понятно, что если код не managed, то откатиться назад очень сложно, а если managed — значительно проще.

Однако я не знаю, реализована ли такая штука уже кем-то на практике. Может быть, правильнее было бы не сюда писать, а пойти написать заявку на патент

Здравствуйте, Pzz, Вы писали:

Pzz>То же самое относится к любому дисковому вводу-выводу.
Pzz>Понятно, что если код не managed, то откатиться назад очень сложно, а если managed — значительно проще.
С чего бы?

Pzz>Однако я не знаю, реализована ли такая штука уже кем-то на практике. Может быть, правильнее было бы не сюда писать, а пойти написать заявку на патент
Уже реализована для undo/redo, причём для нативного кода: http://www.codeproject.com/KB/cpp/transactions.aspx

Здравствуйте, Pzz, Вы писали:

Pzz>Однако программировать так довольно неудобно. Поэтому можно было бы программе сказать, что транзакция уже закончилась, у пусть себе бежит спокойно, пока транзакция либо правда не закончится, либо программа не собиралась сказать кому-то наружу, что транзакция закончилась (и даже эту попытку сказать наружу можно попридержать — реально программа может бежать до того места, когда она сказала, что транзакция закончилась, и хочет что-то получить в ответ). Беда однако в том, что если в конечном итоге транзакция закончится неудачно, а мы программе уже наврали, что все ОК, поличится нехорошо. И вот в этот момент можно бы откатить программу до того места, где мы ей наврали то, что в конечном итоге оказалось неправдой, и пустить ее по новой, но уже сказав ей правду.

Ну получается Warp OS это и делает. Если транзакция вдруг не прошла, то начинаем выполнять программу в обратную сторону до места где мы вызывали транзакцию, меняем результат выполнения транзакции и запускаем программу в нормальном порядке.

Здравствуйте, Pzz, Вы писали:

Pzz>Я хочу сказать вот чего. Работу с базой данных можно значительно ускорить, если собирать транзакции в кучки — потому что транзакция кончается, когда данные уже на диске, а это seek головками, а это очень долго, по сравнению с любой другой дисковой операцией.

Pzz>Однако программировать так довольно неудобно. Поэтому можно было бы программе сказать, что транзакция уже закончилась, у пусть себе бежит спокойно, пока транзакция либо правда не закончится, либо программа не собиралась сказать кому-то наружу, что транзакция закончилась (и даже эту попытку сказать наружу можно попридержать — реально программа может бежать до того места, когда она сказала, что транзакция закончилась, и хочет что-то получить в ответ). Беда однако в том, что если в конечном итоге транзакция закончится неудачно, а мы программе уже наврали, что все ОК, поличится нехорошо. И вот в этот момент можно бы откатить программу до того места, где мы ей наврали то, что в конечном итоге оказалось неправдой, и пустить ее по новой, но уже сказав ей правду.

Это уже не транзакция. Да и зачем городить такой сложный огород — проще воспользоваться RAID контроллером с кешем записи с резервным батарейным питанием.

Здравствуйте, nme, Вы писали:

nme>Ну получается Warp OS это и делает. Если транзакция вдруг не прошла, то начинаем выполнять программу в обратную сторону до места где мы вызывали транзакцию, меняем результат выполнения транзакции и запускаем программу в нормальном порядке.

P.S. Правильное название Timewarp OS.

Здравствуйте, _d_m_, Вы писали:

___>Это уже не транзакция. Да и зачем городить такой сложный огород — проще воспользоваться RAID контроллером с кешем записи с резервным батарейным питанием.

Современный диск может сделать что-то около 200 seek'ов головкой в секунду. RAID не улучшает этого показателя при записи, но спорить мне на эту тему лень, поэтому пусть будет 1000 seek'ов в секунду — чудовищно медленно по сравнению и с производительностью процессора и со скоростью линейного чтения с диска.

Использование кеша записи не решает проблему как таковую, а лишь делает ее проблемой контроллера диска. И это имеет свою цену: не все данные нуждаются в столь бережном отношении (например, временные файлы не нуждаются), но контроллер диска об этом не знает.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Я тут немного буду хихикать, потому что сингулярити — это игрушка, предназначенная показать, что из .Net можно тоже сделать операционную систему. Сингулярити не является, и никогда не будет прототипом настоящей ОС.

Сейчас в майкрософт разрабатывается Midori. Это настоящая ОС (не исследовательская) и она основана на Singularity.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Константин Л., Вы писали:

КЛ>>Господа. О какой [системе типов] может идти речь, когда наличие capability определяется тем, есть у тебя на нее не-null ссылка или нет?
КЛ>>Либо я чего-то не понимаю, либо вместо магического и сокрушительного [система типов] стоит писать [архитектура]?
WH>Конечно не понимаешь.
WH>Ибо без защиты со стороны системы типов вся архитектура и как следствие вся безопасность полетит к чертям после первого же любителя срезать углы.



может быть уже пора описание системы типов в студию?

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, _d_m_, Вы писали:

___>>Это уже не транзакция. Да и зачем городить такой сложный огород — проще воспользоваться RAID контроллером с кешем записи с резервным батарейным питанием.

Pzz>Современный диск может сделать что-то около 200 seek'ов головкой в секунду. RAID не улучшает этого показателя при записи, но спорить мне на эту тему лень, поэтому пусть будет 1000 seek'ов в секунду — чудовищно медленно по сравнению и с производительностью процессора и со скоростью линейного чтения с диска.

Про то что RAID контроллер ускоряет — я и не говорю — просто только на этих контроллерах есть кэш записи.

Pzz>Использование кеша записи не решает проблему как таковую, а лишь делает ее проблемой контроллера диска. И это имеет свою цену: не все данные нуждаются в столь бережном отношении (например, временные файлы не нуждаются), но контроллер диска об этом не знает.

Ну понятно. Только какую цену за это платить? Кэш записи дешевое приемлимое решение.

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

Насчет пучить... Хм... Не знаю, что это такое, наверное, да.
А думать, развивать мышление — очень даже полезно.
А вот нервные клетки, между прочим восстанавливаются. Так что не надо заезженных стереотипов. Читаем про нейрогенез здесь. И вот здесь еще.

Здравствуйте, WolfHound, Вы писали:

WH>Собственно говоря по логике вещей нужно делать код отдельно приложение отдельно.
WH>Те весь код лежит в подписанных сборках.
WH>А приложение это грубо говоря подписанный XML в котором прописанно какие сборки этому приложению нужны.
WH>В какой сборке и как завут точку входа.
WH>И какие привилегии это приложение хочет.
Пока что я так и не услышал описание реализации простейшей вещи, которая работает уже лет десять как во всех сэндбоксах: приложение имеет право доступа к любому файлу, при условии, что его открыл пользователь через FileOpenDialog.

Каким образом планируется это сделать?

Здравствуйте, Константин Л., Вы писали:

КЛ>может быть уже пора описание системы типов в студию?
Пока нет.
Она не завершена.
Но свойство которое защищает данный метод уже озвучено не раз.

Здравствуйте, Sinclair, Вы писали:

S>Пока что я так и не услышал описание реализации простейшей вещи, которая работает уже лет десять как во всех сэндбоксах: приложение имеет право доступа к любому файлу, при условии, что его открыл пользователь через FileOpenDialog.
Ты издеваешься чтоли?

Как приложение может открыть любой файл:
Идем в пространство имен.
Получаем ссылку на сервис открытия файлов.
Передаем сервису capability на открытие диалога в одном из своих окон.
Сервис открывает диалог с контексте окна приложения.
Пользователь открывает файл используя пространство имен укоцанное с учетом прав пользователя.
Приложение от сервиса открытия файлов получает capability на работу с файлом.

(С)

Автор: WolfHound
Дата: 03.07.08