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

V>Мде... зато с каким апломбом....
Мде... зато с каким апломбом....

V>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
Можно пример?

А то в Линуксе, идиоты такие, смогли как-то сделать общую систему поддержки DMA с поддержкой IOMMU для x86 и ARM (с его странными требованиями когерентности). Никакой зависимости от "драйверов конкретных чипсетов" нет и в помине.

V>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
Мимо.

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

>> Но хуже то, что даже переписывание все еще дает возможность легкого заражения системы вирусами. Что делать — непонятно. Искусственный интеллект и поведенческий анализ ПО?

G>Имхо 95% всех вопросов или даже больше решить можно организационно, на верхнем уровне изоляции. Схема: совместно используемое оборудование (почти) без состояний. Полностью изолированные разделы:
G> — игры (опасный)
G> — хрень (опасный)
G> — работа (безопасный)
G> — пароли, явки (безопасный)
G> — еще какая-нибудь хрень (безопасный)

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

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

ARK>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

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

V>>Давай мы сначала разберемся с OCaml. А то вы меня забодали тыкать одной и той же, вполне справедливой фразой. В отличие от Оберона, у тебя и возможности-то не будет узнать про зависимость от модуля Obj в конечном образе. А в Обероне можно явно запретить загрузку модуля с такой зависимостью.
C>Нельзя. Я могу в бинарном коде написать "cli; hlt" без всяких зависимостей от SYSTEM. И всё, стоп-система.

В обесуждаемой AOS не можешь. Там байткод у всех модулей, причем, байткод этот детерминированный и безопасный. А модуль SYSTEM — это псевдо-модуль, его нет. Это на самом деле не классический модуль, а низкоуровневое АПИ ОС, доступ к которому дается через такой же интерфейс модулей.

C>Так как бинарный код в Обероне никоим образом не проверяется.

Байткод загружается через JIT и что-то там проверяется. Насчет глубины проверки утверждать не буду, в 80-90-х годах акценты/задачи по-другому формулировались.

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

ARK>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению.

Заметь, для этого не потребовалось переписать всю ОС. Нужен просто специальный загрузчик, который при связывании создает "умные переходники" к системным ф-ям. Подобными хуками под винду я тоже когда-то баловался. Не знаю как в iOS, а сверху виндов написать такую систему можно даже самому.

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


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


M>Суммируем:

M>В чем гордость, брат? ©

Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

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

C>>Нельзя. Я могу в бинарном коде написать "cli; hlt" без всяких зависимостей от SYSTEM. И всё, стоп-система.
V>В обесуждаемой AOS не можешь. Там байткод у всех модулей, причем, байткод этот детерминированный и безопасный. А модуль SYSTEM — это псевдо-модуль, его нет. Это на самом деле не классический модуль, а низкоуровневое АПИ ОС, доступ к которому дается через такой же интерфейс модулей.
Таки AOS — это галимый тормозной байт-код, значит? Через 40 лет после появления P-Code? Ну и где инновации?

C>>Так как бинарный код в Обероне никоим образом не проверяется
V>Байткод загружается через JIT и что-то там проверяется. Насчет глубины проверки утверждать не буду, в 80-90-х годах акценты/задачи по-другому формулировались.
Так, а где новизна и промышленность и всё такое?

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

V>А это уже юления после залета. А казалось бы, всего-то предложили пару сценариев использования.
Нет. Это ты пытаешься убедить себя что что-то понимаешь.

V>Спорно АБСОЛЮТНО каждое словос т.з. современной безопасности. В реальности всегда требуется суперпозиция прав приложения и пользователя. Вот эти вот попытки упрощать закончились задолго до появления Юниксов.
Опять бредишь.
Разговор начинался с офиса и фотошопа.
Им OpenFileDialog за глаза.
Игрушкам даже он не нужен.

Что у нас еще остается на десктопе?
Да ничего.

А на серверах ясен хрен нужен другой подход к раздачи привилегий.

V>Ну сейчас-то уже убедился, кто и чего не понимает? Всего-то 5-6 итераций мне понадобилось чтобы до тебя дошли все побочные эффекты предложенного сценария... какие мелочи, право.
Ты конечно.

WH>>Никто не мешает установить защищённое соединение с защитой от MiM. И таких протоколов тьма.
V>Ты всьерьез решил попросить очередного лулза? А потом утверждать "я никогда не говорил что это единственный способ." (С).
V>Предлагаю вместо 5-6 итераций один раз тебе помедитировать над исходными условиями.
А что над ними медитировать то?
Если у нас защищенное соединение с защитой от MiM то мы можем верить этому соединению как тому пользователю от имени, которого оно установлено.

V>Это уже совсем другой уровень безопасности. Если ты до этого всячески настаивал на безопасности и закрыточти машины от прониктовения — то это ровно противоположная идеология: машины открыты для проникновения (это банально удобно для работы), но защита пытается выстроиться на уровне сети. Ты вообще понимаешь, насколько это далекий от обсуждаемого подход? В этом случае характеристики конкретных операционок на ендпоинтах вообще не играют рояли. Я же тебе скзаал — Кайберакс подложил тебе свинью, закатав всю твою теорию под асфальт.
Что-то чем дальше, тем бредовее.
И никогда ничего про закрытость машины не говорил.
Наоборот.
Я говорил про то что на машину можно ставить что попало.
Лишь бы этому чему попало лишних привилегий не давать.

И я совершенно не понимаю, какая разница между пользователем, который подключен локально и пользователем, который подключен удаленно.

V>И да, на самом деле это то, о чемя говорил с самого начала — что если речь о злонамерениях, то ключевая инфраструктура. Ты спрорил до соплей, а теперь, ради согласшения с одним из участников, который на твоей стороне конкретно здесь и сейчас, подписался под каждым моим словом, оспоренным тобой раньше.
Ты опять бредишь. И пытаешься съехать с темы.
Изначально разговор был про приложения.
И про то, что согласно твоей вере нужно сертифицировать 100% приложений.
Иначе все развалится.

Но ты нашёл аж ДВА драйвера и ядро ОС, которые нужно сертифицировать.
Весь остальной софт будет прекрасно жить без этого.

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

V>Да еще с таким присущим тебе последние нескоолько лет твоей недолгой жизни апломбом.
Чья бы корова...

V>Я же говорю, вы, ребятки, кормите лулзами похлеще иных домохозяек.
Ты даже не представляешь, сколько лулзов ты поставляешь.

ARK>Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

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

ARK>>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

ARK>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

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

V>Давай мы сначала разберемся с OCaml. А то вы меня забодали тыкать одной и той же, вполне справедливой фразой. В отличие от Оберона, у тебя и возможности-то не будет узнать про зависимость от модуля Obj в конечном образе. А в Обероне можно явно запретить загрузку модуля с такой зависимостью.
Те вся разница в том чтобы научить, компилятор OCaml'а выставлять в бинарнике флаг, что там опасный модуль используется?
После чего OCaml сразу становится супертипизированным?

V>Да бери любые транзакции из EDIFACT X12.
Нет, ты конкретную грамматику давай.

V>GLR хоть и разбирает любую контекстно-свободную грамматику, но для более сложных, т.е. неоднозначных в рамках контектсно-свободных, он в конце разбора выдает ВСЕ варианты. Причем, эти варианты хранятся компактно, без избыточности.
И что толку?
Если мне всё равно их потом нужно руками анализировать?

Это я еще про восстановление после ошибок говорить не начинал.

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

V>Вот почему определение "оперативный" — это ключевой момент и почему разборщики неоднозначных грамматик делают по восходящей технологии. Потому что мощность представления неодозначного результата для оперативного парсера не может быть больше длины разбираемой цепочки.
Языки программирования однозначны.

V>GLR даст все возможные корректные ветки разбора. Ес-но, приведенный отрезок не парсится ни одним контекстно-свободным парсером, даже TDOP. Но TDOP будет безбожно врать на этом примере, т.к. он разбирает первую попавшуюся ветку, как и ПЕГ, а GLR честно предоставит все варианты. А потом эти варианты уже ресолвятся решателем на основе программирования в ограничениях.
Другими словами ГЛР тоже ничего не разберет.
А заставит ручками разбираться что произошло.
При это нисходящим парсерам можно спокойно добавить таблицу имен, и они волшебным образом начинают разбирать такой код.

V>Любой разберет с таблицей, твой парсер тут не при чем. Я же эту технику и показывал для С++, как неоднозначности сводятся к однозначностям. Но это такой язык, где необязательно объявление идет впереди использования, а если нет, то TDOP парсер для таких сценариев вообще самый худший вариант.
Что за бред?
С++ так не умеет.

V>Я когда-то пытался донести до вас мысль, что TDOP — это всего лишь один из алгоритмов парсинга. Ну чтобы вы поднялись чуть над темой и не считали никакой конкретный реализованный алгоритм за панацею. Потому что панацеи нет.
То-то ты GLR во все щели толкаешь.

V>Ды ты бы вола бы за хвост не тянул и закрыли тему еще несколько месяцев назад.
Я тебе просто показываю, как ты общаешься.

V>Гы, я думал интересно будет насчет преобразований м/у цветовыми пространставами, бо там много тонкостей. А ресэмплинг внутри одного пространства, в какой-нить ARGB — это детсад.
Но ты не знаешь, как он работает.
Иначе ты бы сразу понял, что не так с той картинкой.

V>Формула эта — простая линейная пропорция.
Не правильно.

V>Поэтому, чтобы сохранить статистику исходного изображения при ресэмплинге:
V>1. Изображение необходимо привести к линейной шкале, то бишь к гамме=1, а после преобразования вернуть гамму обратно.
V>2. Сам алгоритм ресэмплинга должен сохранять исходную статистику изображения.
Это правильно.

V>Собственно ВСЁ.
Нет не все.
Почему попробуй догадаться сам.

V>ABA-problem не гуглится? А сейчас?
V>Судя по проблемам с преодолением описки, ты даже и не слышал о такой? Ох уж эти мне "на элементарщине сыпающиеся" (С).
1)Знаю я про это. Просто названия плохо запоминаю.
2)В каналах сингулярити такой проблемы нет благодоря дизайну этих самых каналов.
И кто тут сыпется на элементарщине?

V>>>и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити.
WH>>Это полный звездец.
WH>>Ты действительно не понимаешь, что на бутылке сингулярити не сделать?
V>Делать надо
Ну да.
Выкинуть все. И написать с нуля. Правильно.
А нет, так как написано.

WH>>Ты действительно не понимаешь, сколько возможностей для той же оптимизации дают изолированные процессы?
V>Я уже одергивал тебя от таких обобщений. Связь через каналы — дорогое удовольствие само по себе, не самый лучший вариант для многих сценариев.
Так можно и без каналов. Не нарушая изоляции процессов.

V>И уже где-то пощупать эти гипотетические оптимизации можно?
В сингулярити.

V>Есть такое, в реальном мире я оптимизирую через локальные вычисления, то бишь загружаю из памяти в локальные переменные, числодроблю и выгружаю обратно.
Это опять не в тему.

WH>>Ты действительно не понимаешь, что на мониторах lockfree не получится?
V>Пока что видно, что это ты lock-free не понимаешь.
Реализация локфрии на локах. Интересно.

V>Яуже начинаю тебя подозревать в том, что ты вызов метода объекта пытаешься отличать от посылки ему сообщения. И вся твоя изоляция держиться только на это разнице. Это надуманно. Политику синхронизации определяет вызваемый ресурс. Если он помечен, как синхронизируемый, никакой внешний код не вызовет его в несинхронизируемом виде.
Ну что за бред ты несешь. Переставай за меня думать. У тебя не получается.
Запомни: я всегда очень буквален. И когда я говорю, кури альфабленд. Ты должен курить альфабленд. Ибо ты его не понимаешь.
Короче до тех пор, пока ты мне не покажешь, как в сингулярити передать ссылку на объект из одного процесса в другой записываю тебя в безответственные бредогенераторы.

В обероне это делается на раз.
После чего по этому объекту начинаются гонки.
Да и не на всех архитектурах запись/чтение указателя атомарны.

V>Оттуда же, откуда списки процессов и остальных ресурсов. Каналы закрываются "сами", даже если процесс прибит насильно. Потому что он принадлежт операционной системе и она имеет на него ссылку. Исходники Сингулярити есть? Я в них не смотрел, но могу на этот момент поспорить.
Бред.
Каналы абсолютно пассивны и полностью автономны.
И убивают их процессы во время собственной смерти.
Таким образом, глобального списка каналов не существует.

WH>Разговор начинался с офиса и фотошопа.
WH>Им OpenFileDialog за глаза.
WH>Игрушкам даже он не нужен.

WH>Что у нас еще остается на десктопе?
WH>Да ничего.

WH>А на серверах ясен хрен нужен другой подход к раздачи привилегий.

Да даже там, по большому счету, этот подход мало отличается от OpenFileDialog, если так подумать Может, только более гранулярно, но и то.

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

V>>Если тебя лично напрягают глобальные переменные в модулях — это твои предрассудки. Модуль — это всего-лишь синглтон, это полный аналог обычного объекта, который заведомо будет существовать в единственном экземпляре в любой операционке, даже в Сингулярити.
WH>Бред.
WH>В бутылке модуль глобален на всю ОС.
WH>В сингулярити на процесс.
WH>Хотя я бы их вообще отменил.
WH>Не нужны они.

Э... Модули не нужны? А как без них, код где будет лежать? К примеру, по сути в дотнете assembly — это модуль.

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

ARK>>Хосспади, чего вы все прицепились к Оберону? Это нормальный язык, хорошая замена С, без херни типа fallthrough в свитче, операций-статементов в одном лице, интересного синтаксиса указателей, подверженного ошибкам цикла for, далее со всеми остановками. В своей системной нише он хорош — если добавить ему механизмы типа design by contract, можно было бы писать на нем верифицируемую часть кода ядра, в которой требуется прямой доступ к памяти (где не требуется — там лучше взять что-нибудь более высокоуровневое).

M>Это не мы прицепились, это защитники Оберона его преподносят то как панацею, то как первый в мире, то как самый супер-пупер-лучший язык, с которого все и вся все слизали и т.п. Что, естественно, вызывает отторжение, так как действительности соответсвует мало.

Ну прям не супер-пупер, конечно. Но и не так плох, как некоторые его тут малюют.

Кстати, забавно, что тема перешла в крупномасштабный срач про Оберон, Сингулярити, различные подходы к обеспечению безопасности операционных систем, компиляторы и виртуальные машины, аппаратные решения... А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...

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

ARK>>>>Честно говоря, это меня несколько беспокоит. Хочется какой-то механизм формального повышения устойчивости системы. Разделение прав и все, что мы тут обсуждаем — шаги в верном направдении, но их недостаточно, ИМХО...

M>>>Sandbox в iOS и предстоящий sandbox в MacOS X 10.8 и выше как раз идут по этому направлению. Скажем, приложения с несанкционированным доступом к файлам вне песочницы (всякие мониторы директорий и т.п.) уже отвалились и активно жалуются на «злой Apple, который закрыл к файлам доступ».

ARK>>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

M>Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

Если на Обероне, то точно без модуля System. Но не обязательно на Обероне, главное — нужна какая-то верификация байт-кода. То, что запускается в песочнице, может быть написано на чем угодно, а вот сама песочница...

ARK>>>Согласен, это шаг в верном направлении. Но нужны еще более радикальные варианты. В текущей реализации сама песочница может иметь (и будет иметь) ошибки и дыры.

M>>Пасскажи мне про «радикальные варианты». Переписать все на Обероне, чтобы залетный модуль, использующий System положил всю систему?

ARK>Если на Обероне, то точно без модуля System. Но не обязательно на Обероне, главное — нужна какая-то верификация байт-кода. То, что запускается в песочнице, может быть написано на чем угодно, а вот сама песочница...

А что сама песочница? Как показывают примеры Chrome и той же iOS, песочница вполне себе может писаться на C/C++ Взломов что одной, что другой песочницы предельно мало.

M>>Это не мы прицепились, это защитники Оберона его преподносят то как панацею, то как первый в мире, то как самый супер-пупер-лучший язык, с которого все и вся все слизали и т.п. Что, естественно, вызывает отторжение, так как действительности соответсвует мало.

ARK>Ну прям не супер-пупер, конечно. Но и не так плох, как некоторые его тут малюют.

Сам Оберон, как язык, достаточно примитивен, и интереса из себя не представляет — кроме как для использования там, где нужны достаточно примитивные языки со строгой статической типизацией. ОСи/среды на нем/для него написанные, интереса все так же не представляют. Может, на конец 90-х они могли быть хоть сколько-нибудь интересны, но сейчас они неинтересны совсем.

ARK>Кстати, забавно, что тема перешла в крупномасштабный срач про Оберон, Сингулярити, различные подходы к обеспечению безопасности операционных систем, компиляторы и виртуальные машины, аппаратные решения... А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...

Ага Ну, РСДН этому способствует.


Кстати. Обнаружил на вики гениальное:

http://en.wikipedia.org/wiki/Modula-2

The [Modula-2] language design was also influenced by the Mesa programming language

http://en.wikipedia.org/wiki/Mesa_programming_language

Mesa was an innovative programming language developed in the late 1970s... Mesa is an ALGOL-like language with strong support for modular programming. To use a library, a program or higher-level library must "import" the definitions. The Mesa compiler type-checks all uses of imported entities; this combination of separate compilation with type-checking was unusual at the time.

Mesa introduced several other innovations in language design and implementation, notably in the handling of software exceptions, thread synchronization, incremental compilation, and more.

Mesa had a major influence on the design of other important languages, such as Modula-2 and Java

Но, как мы знаем, все это неправда, и впервые появилось только и исключительно в Обероне И на Java повлиял только и исключительно Оберон, другие языки на нее не влияли

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

V>Мде...
ЧТо конкретно?

V>зато с каким апломбом....
У тебя учусь.

V>1. Зачастую не вся физическая память может быть использована для DMA, поэтому обслуживание буферов на совести драйверов конкретных чипсетов.
Пример в студию.

V>2. Ты описал ровно тот сценарий, на который жалуются разработчики Сингулярити — что безопасностью тут и не пахнет, коль можно назначить произвольную память для чтения/записи.
Ну да. Без IOMMU все печально.
С IOMMU все хорошо.

WH>>Кстати IOMMU на данную модель натягивается почти автоматически.
V>Не натягивается на эти два дврайвера без введения дополнительных динамических артефактов в среду исполнения, эдаких известных операционке структурах, на которых достоверно переносятся адреса страниц из диапазонов, прописанных в манифесте.
Что за бред?
Какие еще адреса страниц в манифесте?

V>Поэтому я и предлагал подумать над вариантами, что вся эта динамика на сегодня — одна сплошная дыра. Т.е. мы передаем по каналу какие-то байты, которые означают адреса, но операционка об этом понятия не имеет, так?
Имеет.
Ибо по каналу передаются не просто байты, а вполне конкретные типы данных.
Ты вообще на сингулярити то смотрел?

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

V>>>Я тебя уже поправлял: единица изоляции там — это приватная память объекта. Активный Объект — это и есть процесс. И ты никак не можешь эту изоляцию нарушить через голову публичного АПИ объекта.
WH>>БРЕД!
WH>>Ибо ссылки на внутренние объекты могут быть беспрепятственно сохранены, где попало.
V>Если на внутренние — то только внутри и могут,
И что же мне помешает передать ее в другой объект?
Оберон этому никак не препятствует.

V>Ну так с тем же успехом можно подменять модули в GAC. Насколько это реально?
Перестань говорить сам с собой.
ГАК тут вообще не причем.

V>И твоё "нельзя" — это на типонебезопасных языках нельзя, а если происходящее детерминировано, то можно.
Ни на каких нельзя.

V>ХЗ. Я под безопасностью имел ввиду какие-нить переполнения, выходы индексов за пределы массива и т.д. Без изоляции можно писать очень эффективные системы. Нафига, например, корабельной навигационной системе изоляция процессов. Поясни.
Ох. Ты даже не понимаешь, про какую изоляцию я говорю.
А говорю не про аппаратную защиту памяти. А про логическую изоляцию процессов на уровне системы типов.

V>>>А насчет модели исполнения — экземпляры объектов полностью изолированы.
WH>>Бред.
V>-1
Оберон не знаешь.

WH>>Ты что действительно не понимаешь, что в сингулярити для каждого процесса есть свое объектное пространство?
V>Я не вижу в этом особых преимуществ, если мы договорились, кто код безопасен сам по себе.
Ну да. Возможность грохнуть зажравшийся процесс, а не всю ОС фигня.
Гарантии того что нет гонок фигня.
Все фигня. Один vdimas умный.

V>Все-равно все объекты в одной плоской памяти, а пространство объектов — сугубо логическое. И еще. Для твоей изоляции требуется специальный дорогой инструмент обслуживания этой изоляции.. И оп-па — на сцену выходят каналы. Это же компромисс получился, если посмотреть на всю композицию в целом. Если бы ты хоть немного поработал с lock-free, понял бы, почему я на твои каналы смотрю без энтузиазма. Существуют механизмы передачи информации/сигналов многократно дешевле, в десятки и больше раз.
Которые можно реализовать, не нарушая изоляцию процессов.

WH>>Что не могут существовать ссылки из одного процесса в другой?
WH>>И что оберон никак от этого не защищает?
V>Ссылки возможны только при явных зависимостях.
Но они могут быть.
И гонки могут быть.
И вот такой код может быть. http://www.rsdn.ru/forum/philosophy/1004226.1.aspx

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

V>Никаких ссылок, типа как на безтиповый Object в дотнете быть не может.
Это вообще к делу не относится.

V>Без нарушения изоляции не обойтись
Еще как.

V>без посредников, то бишь без копий нужной инфрмации.
Это снова бред.

V>И здесь дорого всё: создание копий, помещение в очередь,
И снова...

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

V>Valgrind. Погоняй на досуге, очень рекомендую. А казалось бы — для опасных языков предназначен. Юоюсь предоложить во сколко раз будет проще для безопасных.
Гонял. Мышей кроме самых примитивных не ловит.
А мне нужны гарантии, что всё хорошо.
Понимаешь? ГАРАНТИИ!

V>Динамическая загрузка статических зависимостей, заметь. Модуль загружается при первом обращении к нему. То бишь зависимость торчит статически, но если модуль не вызвается, он не загружен.
Но ты никогда не знаешь, какой еще модуль использует данный.
И сколько их.
И когда они появятся.

V>Проверка протоколов — это уже высокоуровневые плюшки.
Это плюшка, которая необходима для работы.

V>А поддержка уникальных ссылок в паскалях всегда была изкаробки.
Что за бред.
Паскаль ты не знаешь.
Не было там никогда уникальных типов.

V>Он сам разбирается в процессе анализа при компиляции, где ему создать копию, а где переиспользовать имеющиеся данные. И да, CONST там все-таки ввели, это одна из гарантий для вызываемого метода.
Это все вообще не о том.

V>Если бы ты еще не вредничал в каждом предложении, как старая жена, было бы вообще идеально.
Нехрен на зеркало пенять.

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

ARK>Э... Модули не нужны? А как без них, код где будет лежать? К примеру, по сути в дотнете assembly — это модуль.
В бутылке к модулю прибиты статические переменные.
И они глобальные на всю ОСь.
Одни и те же переменные для всех юзеров, гостей и админов.
Прикинь.
Безопасности нет.
Хотя куда там. Два пользователя одновременно работать и то не могут.
Да даже один пользователь две копии одной программы запустить не может.

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

ARK>>Кстати, забавно, что тема перешла в крупномасштабный срач про Оберон, Сингулярити, различные подходы к обеспечению безопасности операционных систем, компиляторы и виртуальные машины, аппаратные решения... А собственно предмет обсуждения — язык ДРАКОН — давно всеми забыт и находится в глубокой ж...
M>Ага Ну, РСДН этому способствует.
Это я пофиксил.