Ответ на »сообщение 45« (Takun)
___________________________
Прошу прощения, что не по теме, просто обратил внимание на цитату:

Good composers don’t imitate, they steal.
Igor Stravinsky

Поиск в инете дал следующую руссую фразу, возможно это и есть оригинал:

Хороший композитор не имитирует, но просто берёт, что ему нравится, то есть ворует.

Вполне возможно, что фраза вырвана из контекста, а буквальное ее толкование представляетс крайне сомнительным. А может просто хороший != великий.

Может кто-нибудь объяснить мне что означает слово "инвариант"? Я столько раз его слышал (например, инвариант цикла, инвариант памяти), а смысла не знаю.

Ответ на »сообщение 63« (AVC)
___________________________


Собственно, поэтому меня и привлекают две идеи:
1) запрет импорта SYSTEM для несистемных модулей;
2) введение аналога сборки для Оберон-систем.

С первым понятно. Со вторым - нет. Сборки чего?


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

А она и не будет падать целиком. Точнее будет очень и очень редко. Стандартная ситуация - запустили какой-нибудь пасьянс, поиграли, выключили. Запустили длительный рассчет задачи. Уехали на дачу. Приехали. Рассчет выполнен. Сохранили. Выключили программу. Поиграли в Дум. Запустили Блокнот - блокнот завис.

Вопрос - из за чего завис блокнот? Память у нас не защищена, адресное пространство одно. В память мог, извиняюсь, нагадить кто угодно. Мог пасьянс, в этом случае и результаты рассчета задачи и результаты игры в дум сразу ставятся под сомнение. Могла задача напакостить в память. А мог и дум.

Если адресное пространство у всех задач одно и то же и пямять никак не защищена, то работа системы становится непредсказуемой. Оно будет и сыпаться по частям и падать сразу. И работать месяцами без перезагрузки. Как угодно.


Все это хорошо только для офисных систем.
Мол, упало, ну и ладно -- снова загрузим. :)
Если упало приложение и мы точно знаем что память других задач у нас защищена (изолирована), то мы точно знаем что проблема в этой программе или в данных для этой прораммы. Также это означает, что все остальные задачи в система, равно как и сама система, продолжают нормально работать. Т.о. получаем детерминированость поведения.


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

Собственно не имея защиты памяти, мы создаем прям таки рай для всяких кулхацкеров. То что запускаемый модуль вроде как не импортирует SYSTEM еще не означает что в нем не используется адресная арифметика, что он не напакостит в память. Ибо бинарник после компиляции можно и ручками подправить. И убрать упоминание о SYSTEM.

Т.о. без защиты памяти система крайне уязвима для: 1)Ошибок. 2)Преднамеренного вредительства.

И если первое еще как-то лечится запретом импорта SYSTEM для несистемных модулей, то второе уже не лечится.


Ведь опасным может быть не только "падение" конкретной программы, но и неверное вычисление, и принятое вследствие этого решение и т.д.

Ну, если в модуле MATH, кто-то на функцию SUM повесил не а+б, а а-б, то тут уже ничего не поделаешь.

Так. А давайте еще вспомним, что в большенстве оберон-системы (в т.ч. и ББ) у нас есть проблема со сборщиком мусора для многопоточных приложений...

Думается, что именно все эти проблемы и привели к Active Oberon и Bluebottle.

Ответ на »сообщение 60« (Alexey Veselovsky)
___________________________


Т.о. если в Оберон-системе разрешено (явно и категорично не запрещено) несистемным модулям импортировать SYSTEM или же системные модули экспортируют низкоуровневые функции для непосредственной работы с памятью, указателями и пр, то Оберон система для конечного пользователя является намного МЕНЕЕ надежной чем "классические" системы на типа *nix, Windows, BeOS и пр. писаных на таком кривом и не надежном языке как C/C++. По всей видимости, именно из за использования столь небезопасного инструментария разработчики этих систем позаботились о взаимной изоляции отдельных частей-приложений системы, чтобы ошибка в одном приложении не могла угробить всю систему. Ибо иначе, посольку ошибки часты, системыпадали бы от любого чиха. Установка и запуск любого ПО превращается в русскую рулетку.  Что собственно и наблюдалось например в MacOS и Windows 3.x. По моему в AmigaOS тоже.

Собственно, поэтому меня и привлекают две идеи:
1) запрет импорта SYSTEM для несистемных модулей;
2) введение аналога сборки для Оберон-систем.

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

Вместе с тем, у меня вызывает большое сомнение мысль, что система, "сыплющаяся" по частям "надежнее" системы, падающей целиком.
Все это хорошо только для офисных систем.
Мол, упало, ну и ладно -- снова загрузим. :)
Обероновский подход именно нацелен на то, чтобы вообще "не падало".
Кроме того, а что делать с ошибками, вызванными нарушениями инвариантов памяти, если они не распространяются за пределы адресного пространства процесса?
Ведь опасным может быть не только "падение" конкретной программы, но и неверное вычисление, и принятое вследствие этого решение и т.д.

Ответ на »сообщение 58« (Сергей Перовский)
___________________________

Ответ на »сообщение 56« (AVC)
___________________________
Структура Windows основанная на dll - то, что потом прозвали dll-адом - это не пример динамической загрузки и линковки?

В 1989 году Windows была только в проекте - это раз :-)
DLL реализуют лишь толику от полноценной динамической загрузки. DLL не экспортирует типы, не выполняется контроль сигнатур и т.п.
Первые технологии загрузки не интерпретируемых, а копилированных модулей, подобные Оберону - это COM & CORBA. Грамотнтое название таких стандартов загрузки/компоновки, кстати - "объектные модели". Это уже 93-95 годы. Технологии мощные, языковонезависимые, но именно поэтому очень громоздкие...

Ответ на »сообщение 58« (Сергей Перовский)
___________________________


>>>динамическую загрузку и линковку (статическая линковка не требуется);
Не требуется или невозможна? Второй вариант представляет собой ограничение, далеко не всегда полезное.

Если брать Оберон как язык, то существует множество его реализаций со статической линковкой.
Например, XDS.
Что касается ОС Оберон, то там, действительно, загрузка всегда динамическая.


>>>Мне пока неизвестны о существовании подобных "фич" до Оберона.
Структура Windows основанная на dll - то, что потом прозвали dll-адом - это не пример динамической загрузки и линковки?

Dll-hell есть следствие именно невозможности поддерживать целостность системы.
Раздельная компиляция и fingerprintы как раз имеют своей целью обеспечить целостность системы.
ИМХО, это как раз тот пункт, где Оберон опередил "mainstream" лет этак на 15.


>>>Благодаря этой маленькой хитрости, динамическое определение типа (v IS T) в Обероне требует всего одного сравнения.
Подозрительное утверждение, не могли бы Вы обосновать его?

А что там обосновывать? :)
Давайте посмотрим, что должен сделать компилятор, встретив конструкцию

  v IS T

Сначала он возьмет из таблицы символов информацию об уровне расширения типа T (целое число), затем сгенерит код, получающий доступ (через type tag переменной v) к таблице дескрипторов базовых типов (это массив) и сравнивающий его элемент с индексом, равным уровню расширения, с конкретным значением.
Собственно все. :)

Ответ на »сообщение 59« (AVC)
___________________________

Ответ на »сообщение 57« (Alexey Veselovsky)
___________________________

Не могу пока сказать насчет Bluebottle. :(
BlackBox в Windows является обычным приложением.
Но -- в принципе -- да, кривонаписанный модуль, использующий SYSTEM, может натворить больших бед в Оберон-системе.
Правда, кажется, в оригинальной ОС Оберон использовалась (аппаратная) защита памяти для ядра.
Но т.к. в принципе Оберон может работать и без memory protection, то в конкретном случае, ИМХО, надо четко определиться, разрешать ли импортировать SYSTEM несистемным модулям.

Т.о. если в Оберон-системе разрешено (явно и категорично не запрещено) несистемным модулям импортировать SYSTEM или же системные модули экспортируют низкоуровневые функции для непосредственной работы с памятью, указателями и пр, то Оберон система для конечного пользователя является намного МЕНЕЕ надежной чем "классические" системы на типа *nix, Windows, BeOS и пр. писаных на таком кривом и не надежном языке как C/C++. По всей видимости, именно из за использования столь небезопасного инструментария разработчики этих систем позаботились о взаимной изоляции отдельных частей-приложений системы, чтобы ошибка в одном приложении не могла угробить всю систему. Ибо иначе, посольку ошибки часты, системыпадали бы от любого чиха. Установка и запуск любого ПО превращается в русскую рулетку.  Что собственно и наблюдалось например в MacOS и Windows 3.x. По моему в AmigaOS тоже.


Пока не готов ответить на этот вопрос, но у меня сложилось впечатление, что это именно так.
Все же, хотелось бы выслушать по этому поводу более компетентных людей.
Так. Ясно. О FileMapping'e для обработки больших файлов, можно смело забыть если есть вероятность что какой-то еще модуль может заниматься тем же самым.

Например, Trurlя.
В отношении работы с очень большими объемами данных (речь шла о гигабайтах) в одной из веток был интересный пост info21. (пост №981 в ветке "Информатика-21ю Форум проекта")
Там речь шла о обработке динамических данных. Это несколько отличается от обработки данных из большого файла. Кроме того, думаю через FileMapping и там можно было бы сделать проще/быстрее.

Ответ на »сообщение 57« (Alexey Veselovsky)
___________________________


Итак вопрос: в реализациях Оберон-систем (а именно: Oberon System, Bluebotle, BlackBox) все модули исполняются в одном и том же адресном пространстве? Т.е. один не безопасный, кривонаписаный модуль вооружившись SYSTEM может легко и непренужденно разрушить всю систему?

Не могу пока сказать насчет Bluebottle. :(
BlackBox в Windows является обычным приложением.
Но -- в принципе -- да, кривонаписанный модуль, использующий SYSTEM, может натворить больших бед в Оберон-системе.
Правда, кажется, в оригинальной ОС Оберон использовалась (аппаратная) защита памяти для ядра.
Но т.к. в принципе Оберон может работать и без memory protection, то в конкретном случае, ИМХО, надо четко определиться, разрешать ли импортировать SYSTEM несистемным модулям.


Это во-первых. Во-вторых: например для BlackBox'a, если конечно все модули живут в одном и том же адресном пространстве, получается что на ВСЕ модули (а модуль в Обероне это часто эквивалент программы в классических системах) отведено всего-навсего адресов под 2 гигабайта? Т.о. в винде под каждую нативную программу отведено 2 Гб адресного пространства, а для ББ-модулей на их ВСЕ отведено всего 2. То есть ББ может использоваться (с небольшими оговорками) как всего лишь ОДНА программа, но не как система (совокупность) работающих программ. Со всеми вытекающими.

Пока не готов ответить на этот вопрос, но у меня сложилось впечатление, что это именно так.
Все же, хотелось бы выслушать по этому поводу более компетентных людей. Например, Trurlя.
В отношении работы с очень большими объемами данных (речь шла о гигабайтах) в одной из веток был интересный пост info21. (пост №981 в ветке "Информатика-21ю Форум проекта")

Ответ на »сообщение 56« (AVC)
___________________________
>>>динамическую загрузку и линковку (статическая линковка не требуется);
Не требуется или невозможна? Второй вариант представляет собой ограничение, далеко не всегда полезное.
>>>Мне пока неизвестны о существовании подобных "фич" до Оберона.
Структура Windows основанная на dll - то, что потом прозвали dll-адом - это не пример динамической загрузки и линковки?

>>>Благодаря этой маленькой хитрости, динамическое определение типа (v IS T) в Обероне требует всего одного сравнения.
Подозрительное утверждение, не могли бы Вы обосновать его?

Ответ на »сообщение 56« (AVC)
___________________________
Повторю свой вопрос:

Итак вопрос: в реализациях Оберон-систем (а именно: Oberon System, Bluebotle, BlackBox) все модули исполняются в одном и том же адресном пространстве? Т.е. один не безопасный, кривонаписаный модуль вооружившись SYSTEM может легко и непренужденно разрушить всю систему? Это во-первых. Во-вторых: например для BlackBox'a, если конечно все модули живут в одном и том же адресном пространстве, получается что на ВСЕ модули (а модуль в Обероне это часто эквивалент программы в классических системах) отведено всего-навсего адресов под 2 гигабайта? Т.о. в винде под каждую нативную программу отведено 2 Гб адресного пространства, а для ББ-модулей на их ВСЕ отведено всего 2. То есть ББ может использоваться (с небольшими оговорками) как всего лишь ОДНА программа, но не как система (совокупность) работающих программ. Со всеми вытекающими.

Это действительно так?