V>>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать? WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать. WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище. WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу. WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ. WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.
WH>Блин. Ну никакой фантазии.
Самое смешное, что MS SQL Server уже давно так и работает, по сути. Вплоть до того, что из Enterprise Studio хрен откроешь файлы на restore/backup, если у пользователя нет доступа к этим файлам
Здравствуйте, Mamut, Вы писали:
V>>Да. Потому что динамическия языки, в отличие от статически-тпизированных, трудно оптимизировать. Фактически только через суперкомпиляцию, а этот раздел IT находится пока мест в зачаточном состоянии. Поэтому в Эрланге выполняется постоянный eval любой динамической переменной. Помимо динамики, интерпретация байт-кода, это не тоже самое, что исполнений нейтивного кода.
M>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?
Мде...
Ес-но.
M>1. Берем Оберон—язык.
M>Что есть в языке из перечисленного (на уровне спецификаций, описаний и т.п.): M>- ООП M>- функциональные типы
В языке.
M>- динамическая загрузка модулей M>- активные объекты из коробки
в версии АО M>- GC
А эти пункты обеспечивается аналогом CRT, назовем его ORT, хотя его наывают просто Оберон.
Если написал хоть одну программу на дотнете, то должен понимать о чем речь. "Чисто язык" C# вообще не имеет смысла без GC, библиотечных модулей, RTTI и т.д. и т.п. Все эти вещи выходят за рамки языка, но программы на языке пишут из расчета, что все эти вещи есть. В Обероне аналогично. Вернее — наоборот, разарботчики Явы и Дотнета переняли философию Оберона. Не зря Java-язык и Java-среда исполнения названы одним словом, как и Оберон. Первое не имеет смысла без второго.
M>2. Берем программу на Обероне и компилируем ее в нативный код. То есть, например, в x86-нативный код, готовый выполняться, скажем, в винде без оберток типа BlackBox'а, BlueBottle или чего-то там еще
А чем не устраивает среда исполнения BlackBox?
M>Что там будет из перечисленного: M>- ООП M>- функциональные типы M>- динамическая загрузка модулей M>- активные объекты из коробки M>- GC
Кроме активных объектов — всё (если не ошибаюсь, мой гугл не лучше твоего). ИМХО, активные объекты вообще мало смысла имеют без специальной ОСи. Я это объяснял в предыдущем посте. Хотя, пощуать вживую их можно на WinAosMini.
M>4. Берем ОСь BlueBottle и пишем в ней программу на Обероне
M>- ООП M>- функциональные типы M>- динамическая загрузка модулей M>- активные объекты из коробки M>- JIT (то есть докомпиляция не в байткод, а до именно нативного кода — как бы он там ни был представлен)
Всё будет.
M>5. Берем Оберон, пишем программу для микроконтроллера, компилируем... Ну для того же PIC, или пофиг для чего.
M>Что там будет из перечисленного: M>- ООП M>- функциональные типы M>- динамическая загрузка модулей M>- активные объекты из коробки M>- JIT
Первые два пункта. Т.е. то, что относится сугубо к языку. Среда исполнения контроллеру не нужна. Потому что не нужно динамическое управление ресурсами. Это важный аспект, предлагаю помедитировать — а нахрена вообще нужны какие-то там среды исполнения? Какую именно задачу они берут на себя?
Здравствуйте, vdimas, Вы писали:
V>То есть полноценной десктопной ОСи на Обероне не существует. По уровню развития этой ОСи ее можно рассматривать только как встраиваемую, бо десктоп требует кучу прикладных плюшек, в т.ч. развитую систему ограничений.
И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует.
Здравствуйте, vdimas, Вы писали:
WH>>Ну так оно и будет происходить через OpenFileDialog. WH>>OpenFileDialog будет возвращать не строку как сейчас, а файл. V>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити?
Это уже используется в реальном мире более 20 лет. Ты бы посмотрел что-нибудь окромя виртовских куч дерьма?
Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.
Здравствуйте, vdimas, Вы писали:
V>>>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити? WH>>Не помню. Но модель сингулярити как раз на такой сценарий и заточена. V>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать?
Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android).
V>Первые два пункта. Т.е. то, что относится сугубо к языку. Среда исполнения контроллеру не нужна. Потому что не нужно динамическое управление ресурсами. Это важный аспект, предлагаю помедитировать — а нахрена вообще нужны какие-то там среды исполнения? Какую именно задачу они берут на себя?
Суммируем:
Сам язык:
— ООП
— Функциональные типы
То есть сам язык из себя ничего не предоставляет, как тут и говорилось уже много раз. Все эти вопли про «супероптимизирующие компиляторы» и прочий бред можно спокойно выкидывать, потому что в этом примитиве и оптимизировать, по сути, нечего.
Более того, как язык Оберон не привнес абсолютно ничего нового. Хуже того, в себя ничего нового он не вобрал. Что ООП, что «функциональные типы» (хак для того, чтобы иметь ФВП в языке) давно были, и применялись промышленно задолго до Оберона-языка.
Компиляция в нативный код:
— не известно, будет ли динамическая подгрузка модулей
— не известно, будет ли GC
— активных объектов не будет
потому что «гугл тоже не уверен».
VM/среда выпонения
— GC
— активные объекты (весьма примитивные, на основе мьютексов, локов и т.п)
— динамическая загрузка модулей
— GC не является чем-то новым. В частности, тот же Lisp широко использовался в промышленных масштабах еще в 80-е и — внезапно — у него был GC. Не говоря об изобретении GC в 1959-м. APL тоже не может пожаловаться на отсутсвие промышленного применения, и тоже обладал GC.
— Активные объекты не являются чем-то новым: к тому моменту, как появился Active Oberon, Erlang уже вовсю использовался в промышленности, причем с моделью намного более умной. И не надо рассказывать сказки про «ах, сравнивать компилируемый язык с интерпретатором». Как ты сам сказал, при нативной компиляции активные объекты внезапно куда-то исчезают. О чем, собственно, честно сказано у самих оберонщиков. То есть, как и что выполняется в Active Oberon для поддержки этих объектов, вопрос открытый. Ну и как я уже говорил, работа над Erlang'ом основывалась на еще более ранних параллельных языках, активно используемых тогда в промышленности.
— динамическая загрузка модулей так же не является чем-то новым. До Оберона в промышленных масштабах использовалась от того же Лиспа, как я понимаю, до того же Erlang'а.
Ну да, ну да, к началу 2000-ных маленькая часть всей этой Паскале-подобной куча-малы имела все вышеперечисленное, но существовало оно только в виде Bluebottle (или AOS?) + ActiveOberon. Ну да, собрали кучу идей и воплотили их в чем-то одном. И? Ну так не они первые собрали все в кучу, и не они последние. Ключевое: не они первые.
И чем так гордятся оберонщики? Тем, что он первым был в чем-то там? Так не был он первым. Тем, что на нем ОСь написана? Так не на нем одном и не на нем первом. Тем, что у него строгая статическая типизация, не позволяющая произвольно мнеять объекты в памяти? Так не у него одного, не у него первая (при том, что таки позволяет менять и System входит в описание языка). Тем, что у него к 1999-му году появились «активные объекты»? Ну так в реализации «mutex-lock-sync-wait» далеко не у него одного, и не у него первого. А в боле грамотной реализации точно не у него. То, что у него есть «функциональные типы»? Так не у него одного и точно не у него первого.
M>Суммируем:
M>Сам язык: M>- ООП M>- Функциональные типы
— простой
— детерминированный
— типобезопасный
— надежный
M>То есть сам язык из себя ничего не предоставляет, как тут и говорилось уже много раз.
Угу, как и разработанный на 20 лет позже C# ничего из себя не представляет. А Джава вообще стократ убогее смотрелась. Только на библиотеках и выехала.
M>Все эти вопли про «супероптимизирующие компиляторы» и прочий бред можно спокойно выкидывать, потому что в этом примитиве и оптимизировать, по сути, нечего.
Оптимизировать всегда есть чего. Никаких воплей не было, это твоя проблема восприятия. Речь шла о хорошей на тот момент оптимизации. Собственно, более-менее хороший код генерили только компиляторы паскалеподобных языков и Фортрана. Компиляторы С++ их существенно обогнали уже ближе к концу 90-х, начала 2000-х.
M>Более того, как язык Оберон не привнес абсолютно ничего нового.
Ну да, это продолжение того самого Паскаля и Модулы от того же самого автора. По сравнению с этими языками, собственного же производства, Вирт не привнес ничего нового, кроме более приятного синтаксиса (эти парные begin/end в Паскале когда-то нехило раздражали), + GC, плюс шлифанул сам язык, + добавил среду исполнения, получился Оберон. Для 80-х годов очень неплохо. Это считай та же Джава, только более продвинутая и на 10-15 лет раньше вышедшая.
M>Хуже того, в себя ничего нового он не вобрал.
Если брать сам первоначальный Паскаль — то язык достаточно элегантный по тем временам. Что и обеспечило его популярность. Тогда еще на Фортране вовсю шпилили, по сравнению с ним Паскаль смотрелся очень даже современно, ничуть не уступая ему в эффективности.
M>Что ООП, что «функциональные типы» (хак для того, чтобы иметь ФВП в языке) давно были, и применялись промышленно задолго до Оберона-языка.
Если ты про Лисп, то тут даже сравнивать нечего. Опять же, GC в интерпретаторе и GC в нейтивном коде — это настолько две большие разницы, что попытка ставить их рядом отдает невежеством.
M>Компиляция в нативный код: M>- не известно, будет ли динамическая подгрузка модулей
Известно, будет.
M>- не известно, будет ли GC
Известно, будет.
M>- активных объектов не будет
В каких-то версиях будет, в каких-то не будет.
M>потому что «гугл тоже не уверен».
Потому что зря ты учавствуешь в форуме, если не трудишься включать внимательность. Речь шла о конкретном BlackBox.
M>VM/среда выпонения M>- GC M>- активные объекты (весьма примитивные, на основе мьютексов, локов и т.п) M>- динамическая загрузка модулей
M>- GC не является чем-то новым.
Полноценный для нейтивных языков — считай являлось на тот момент. Да и сейчас это предмет активного исследования.
M>В частности, тот же Lisp широко использовался в промышленных масштабах еще в 80-е и — внезапно — у него был GC.
Ты видел этот лисповый GC? Самое время посмотреть и устыдиться. Две процедуры по 10-15 строк. Кароч, пытаться сравнивать синхронный и асинхронный GC — это даже не смешно.
M>Не говоря об изобретении GC в 1959-м. APL тоже не может пожаловаться на отсутсвие промышленного применения, и тоже обладал GC.
Угу, как и Матлаб, и которые все, упсс, интерпретаторы с синхронным GC.
M>- Активные объекты не являются чем-то новым: к тому моменту, как появился Active Oberon, Erlang уже вовсю использовался в промышленности, причем с моделью намного более умной.
Модель Эрланга намного более глупая, отсюда непреодолимые проблемы ввода-вывода. Чтобы Эрланг поумнел, ему нужна среда-операционка навроде AOS или Сингулярити. А так это полная профанация хорошей идеи. Если в AOS и Сингулярити ввод-вывод намного эффективнее, чем в обычных операционках, то на таком же точно активном Эрланге ввод-вывод тормозит ВСЮ программу из всех сотент и тысяч активностей. Это же полный П. Даже взять тот же нашумевший проект про роутер на Эрланге, приводилась статистика: объем кода на Эрланге в общей доле всего кода был менее 20%, в основном идет код на С/С++. Более того, эрланговский код обслуживал самую ненапряжную вещь — установку соединений, доля требуемых вычислительных ресурсов под которую — менее сотой доли одного % от всех задач. Очередной полный П.
M>И не надо рассказывать сказки про «ах, сравнивать компилируемый язык с интерпретатором».
Надо. Надо все эти тупые интерпретирующие поделки выжигать каленым железом. Если под язык существует только интерпретатор — это недоделанный язык. Интерпретатор хорош только для REPL и других малюсеньких задач, где критично время запуска после внесенного исправления. Идеальный вариант — шелл, написали строчку кода, тут же запустили. Если же программа отлажена, то нафига ей интерпретатор-то? Фактически, на любой компиллируемый сегодня язык можно написать интерпретатор, был бы смысл. Например, для Хаскеля так и сделали — идет компилятор + интерпретатор (сугубо для REPL). Но когда берут кастрат-интерпретатор для более-менее серьезных по объемам задач.... брр... Вот уж точно, "каждая домохозяйка должна уметь программировать" (С).
M>Как ты сам сказал, при нативной компиляции активные объекты внезапно куда-то исчезают.
Это ты уже совсем бредишь.
M>Ты хочешь сказать, в BlackBox/BlueBottle выполняется нативный код?
Ес-но.
BlueBottle построена на AOS. Работает полностью нейтивный код, ленивая загрузка образов с грануляцией уровня модуля, GC и все остальные плюшки.
M>О чем, собственно, честно сказано у самих оберонщиков. То есть, как и что выполняется в Active Oberon для поддержки этих объектов, вопрос открытый.
Где ты там увидел, что активные объекты исчезают? Живут и здравствуют. Какая поддержка — тоже сказано.
M>Ну и как я уже говорил, работа над Erlang'ом основывалась на еще более ранних параллельных языках, активно используемых тогда в промышленности.
А вышло, что вышло. Предмет потешательства и издевательств над вычислительной эффективностью языка.
M>- динамическая загрузка модулей так же не является чем-то новым. До Оберона в промышленных масштабах использовалась от того же Лиспа, как я понимаю, до того же Erlang'а.
Очередной незачет. Ну ты в курсе...
M>Ну да, ну да, к началу 2000-ных маленькая часть всей этой Паскале-подобной куча-малы имела все вышеперечисленное, но существовало оно только в виде Bluebottle (или AOS?) + ActiveOberon. Ну да, собрали кучу идей и воплотили их в чем-то одном. И?
И прямо сейчас такой же трюк пытается провернуть RUST, и некоторые коллеги заранее слюни пускают, хотя каждая новая версия языка отличатся от предыдущей больше, чем Паскаль от Си.
M>Ну так не они первые собрали все в кучу, и не они последние. Ключевое: не они первые.
Дык, молодец, что размахиваешь своими ключевыми комплексами. Мне-то до фени. Тем более, что в споре было ключевое не это. Зацеплись за другое — что в промышленном масштабе этому всему (реализованному в Обероне и AOS) только еще предстоит набирать обороты, поэтому объявлять идеи, обкатанные вокруг Оберона устаревшими, было как минимум глупо. Сейчас даже на дотнете толком продуктов на рынке коробочного ПО не видно, куда уж там до активных объектов... До них еще десяток лет, если не больше. Это всё ОСи следующего поколения. Не зря MS ковыряется в своей Сингулярити и её потомках...
Единственно в чем можно обвинить Оберон — это в низкой готовности к обще-коммерческому применению. Т.е. даже взять тот же Дельфи или Джаву — степень готовности была высокая. Но это всё требует денег и ничего кроме денег, на то она и коммерция. Посмотри на тот же Nemerle, уже сколько лет его пилят, а кач-во поставки такое, что на реальный проект его не возьмешь, при всей его интересности. Посмотрим на результаты через несколько лет развития при финансовой поддержке.
M>И чем так гордятся оберонщики? Тем, что он первым был в чем-то там?
Где ты видел, чтобы они гордились? Они просто считают свой инструмент удобным. Я и тоже считаю, что для спец-применений, где вся эта общеприкладная мишура не нужна, недостатки готовности под коммерческие задачи становятся несущественны, зато остаются видны надежность и эффективность языка, а при надобности — и среды. Сможешь на сегодня найти язык-среду со сравнимой надежностью и эффективностью? Боюсь, что нет.
M>Так не был он первым.
С указанным балансом качеств — подозреваю что был первый, и на сегодня пока последний.
M>А в боле грамотной реализации точно не у него.
Здравствуйте, WolfHound, Вы писали:
V>>Базы данных, конфиги, логи и т.д. до бесконечности тоже через OpenDigalog открывать? WH>Логи и конфиги монжно и нужно хранить с приватном хранилище. Нехрен их где попало разбрасывать. WH>Базы данных чуть менее чем всегда можно хранить в локальном хранилище.
Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
WH>А для тех редких случаев, что нельзя никто не мешает данному приложению дать постоянное разрешение на доступ к конкретному файлу. WH>Для пользователя будет все тот же OpenFileDigalog но с предупреждением что приложение получает постоянный доступ.
Угу, особенно это будет хорошо смотреться, если у меня только консоль к базе данных с удалённой клиентской машины. Ты эта... с базами-то работал?
WH>Ну и ессно будет список файлов, к которым у приложения есть постоянный доступ и возможность убрать оттуда файл.
Для баз данных эти файлы создаются:
1. удаленно;
2. при этом зачастую автоматически клиентским удаленным приложением.
WH>Блин. Ну никакой фантазии.
Воображение и фантазии — разные вещи. Фантазии — это результат неумения подчинять воображение законам мира, то бишь путь к сфероконям и прочим феям.
Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз.
Здравствуйте, Mamut, Вы писали:
M>Самое смешное, что MS SQL Server уже давно так и работает, по сути. Вплоть до того, что из Enterprise Studio хрен откроешь файлы на restore/backup, если у пользователя нет доступа к этим файлам
Ты всерьез открываешь бэкапы только из Enterprise Studio? Ручками? И создаешь бэкапы тоже ручками? Действительно, очень смешно. DMO/SMO/RMO пользовать не пробовал?
Здравствуйте, vdimas, Вы писали:
WH>>Базы данных чуть менее чем всегда можно хранить в локальном хранилище. V>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель.
Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.
V>Воображение и фантазии — разные вещи. Фантазии — это результат неумения подчинять воображение законам мира, то бишь путь к сфероконям и прочим феям. V>Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз.
Да-да. Ты придумал совершенно левый довод, и с апломбом считаешь, что все вокруг идиоты.
Здравствуйте, Cyberax, Вы писали:
WH>>>Ну так оно и будет происходить через OpenFileDialog. WH>>>OpenFileDialog будет возвращать не строку как сейчас, а файл. V>>Будет в воображаемом мире, или это уже есть де-факто в Сингулярити? C>Это уже используется в реальном мире более 20 лет.
Брехня. В реальном мире на десктопе винда, а на серваках линукса. И там и там такой функциональности НЕТ.
Все остальное на уровне Оберона по распространенности или еще многократно ниже.
C>Ты бы посмотрел что-нибудь окромя виртовских куч дерьма?
Ты бы до ветру сходил.
C>Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса.
Это уже операционка? И это точно человек на том конце интернета, а не бот?
Как GoogleChrome относится к Сингулярити? А к Оберону? Мало того, что пример своей нерелевантностью характеризует отсутствие логического мышления, дык еще у тебя хватает наглости эту нерелевантность пытаться натягивать сугубо на одну сторону спора. Хорошо себя чувствуешь? Нерелевантные аргументы априори можно натягивать с одинаковым успехом в обе стороны.
Здравствуйте, Cyberax, Вы писали:
C>Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android).
Дык, куда смотреть? На сфероконей или реальную Сингулярити? Или ты совсем потерялся?
1. Твой говноандроид вообще вскрывается на раз;
2. По безопасности кода ему до Оберона как до пекина раком;
3. По эффективности работы ему до Оберона как до Пекина раком туда и обратно;
Тупая поделка от тупых разработчиков. Сплошные глюки и тормоза. Перевод мегагцерцев на г-но, на пыль. Борьба с несуществующими ветрянными мельцами из-за собственного убожества. Примитивизм и ограниченность. Лемминги рулят, фигли.
Ладно бы ты еще привел в пример bada или MeGoo, но Андроид — это сразу в сад к нубам не задерживаясь. Но даже bada и MeGoo так же сидят на устаревшей архитектуре операционки.
И да, конфиги практически всегда надо шарить м/у приложениями. А пример сервиса конфигов мы давно видели — реестр виндов. Со всеми такими же проблемами и граблями как и с независимыми файлами, в случае надобности шарить эти конфиги м/у независимыми программами. Т.е. сама фраза "а вот тут сервис конфигов" выдает невладение предметом.
Здравствуйте, Cyberax, Вы писали:
V>>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель. C>Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем.
Прямо-таки на весь носитель??? Шарик, да ты... ну ты понял... Это не ложится на предложенную модель безопасности вообще никак. С т.з. этой модели и носителей-то никаких для юзверя нет, тома в лучшем случае.
V>>Кароч, твоя модель-фантазия не работает. Я тебя поправил важными замечаниями насчет баз, попробуй еще раз. C>Да-да. Ты придумал совершенно левый довод, и с апломбом считаешь, что все вокруг идиоты.
Ты или отвечай по делу, или не отнимай мои кванты внимания.
А чтобы тебе легче было сосредоточиться, верну-ка я скипнутый тобой неудобный момент:
Угу, особенно это будет хорошо смотреться, если у меня только консоль к базе данных с удалённой клиентской машины.
Для баз данных эти файлы создаются:
1. удаленно;
2. при этом зачастую автоматически клиентским удаленным приложением.
И для избежания разночтений, заранее поясню, что консоль к базе — это не RDP-сессия, в которой запросто можно показать диалог от имени другого юзверя (ситемной записи, типа как выскакивают диалоги в Win7), это просто соединение по TCP + аутентификация всего одним юзвером, + функциональность на основе библиотек, аналогичных SQLDMO/SQLSMO/SQLRMO.
Здравствуйте, vdimas, Вы писали:
C>>Это уже используется в реальном мире более 20 лет. V>Брехня. В реальном мире на десктопе винда, а на серваках линукса. И там и там такой функциональности НЕТ.
Я же говорю — хватит показывать своё незнание.
Изоляция процессов с помощью разграничения доступа к ресурсам путём использования неподделываемых handle'ов называется http://en.wikipedia.org/wiki/Capability-based_security . В Юниксах она частично может быть реализована с помощью запрета для процессов открывать файлы, кроме тех, дескрипторы которых получаются от доверенных процессов. Это используется на практике в юниксах уже 20 лет, для этого есть специальный механизм передачи файлов через локальные сокеты ( http://archives.neohapsis.com/archives/postfix/2000-09/1476.html ).
C>>Конкретно в десктопном сегменте — так работает Google Chrome. Процессы-рендереры могут писать только в файлы, handle'ы на которые получают от родительского процесса. V>Это уже операционка? И это точно человек на том конце интернета, а не бот?
В принципе, уже да (см. http://www.google.com/intl/en/chrome/devices/ )
V>Как GoogleChrome относится к Сингулярити? А к Оберону? Мало того, что пример своей нерелевантностью характеризует отсутствие логического мышления, дык еще у тебя хватает наглости эту нерелевантность пытаться натягивать сугубо на одну сторону спора. Хорошо себя чувствуешь? Нерелевантные аргументы априори можно натягивать с одинаковым успехом в обе стороны.
Ага, "слаботипизированный OCaml".
Тебе посчитать количество твоих увиливаний в сторону и переходов на непонятно что? Ну типа, перехода с ФВП на контроллеры с ОЗУ в 512 байт.
Здравствуйте, WolfHound, Вы писали:
V>>Насчет комбинированных интерфейсов ты ничего не ответил. Тебе нечего ответить, т.к. это противоречит твоей надуманной концепции. WH>Ничему это не противоречит. Если двум драйверам нужно работать с одной железкой, то просто заводим драйвер для этой железки и другие драйверы будут общаться уже с ним.
Не факт, что взлетит даже для аудио, а для видео точно не взлетит. Ведь общение только по каналам, я правильно понял? Пропускная способность каналов не позволит.
V>>Ты тут пытаешься читать только то, что хочешь. WH>Я читаю то, что написано. WH>Ты пытаешься всеми силами доказать что защиты бутылки и сингулярити на одном уровне. WH>Но это не так.
Я утверждал изначально о безопасности кода, порождаемого языком. Это ровно та безопасность, которая позволяет отказаться от защищенной памяти и получать целый ворох плюшек в награду. Если же рассуждать о безопасности к вирусам/атакам, то язык тут вообще не при чем. Согласен? Байткод, кстати, в бутылке тоже присутствует и тоже ровно с той же целью — для переносимости. Обсуждаемые в этой подветке вещи (типа верификации байткода) можно надстроить НАД готовой операционкой. Как пример — популярные сейчас "песочницы". Потребовала хоть одна "песочница" переделки ядра ОС? Нет, есно. Это просто специальная версия загрузчика.
V>>Утверждалась о сходной модели построения ОС. WH>Общего у них только безопасность на уровне языка.
Именно, это базис. И основные плюшки удивительно перекликаются. А остальные навороты — фактически прикладная функциональность.
WH>Но это всё равно, что утверждать, что все ОС, которые используют аппаратную защиту одинаковые.
По крайней мере в таблицах, приводимых в репортах по Сингулярити совсем разные ОС с аппаратной защитой памяти показывали удвительно похожие характеристики. Случайно? Нет, есно. Современные ОСи неплохо вылизаны и подходят к пределу производительности. Сам этот предел будет определяться базовой технологией построения ОСи.
WH>Ты нашол только ДВА драйвера в которых закладки опасны. WH>По сравнению с миллионами программ защиту, от которых можно переложить на механизмы ОС это просто ничто.
И в чем аргумент? С чего ты взял, что точно так же невозможно этой защитой наградить ту же AOS? В Сингулярити это выполняется не ядром операционки, а специальным приложением — инсталлятором. Кто мешает написать аналогичный инсталлятор для AOS? Я думаю, что этого не сделали от того, что такие ОСи используют не как ОСи общего назначения, а как специализированные, встаиваемые. Т.е. сам вопрос еще не стоял. Это не начит, что вопрос неразрешим, если вдруг встанет. Просто MS производит ОСи общего назначения, поэтому им эта тема была важна.
WH>При том, что в бутылке защиты нет совсем.
Пофиг, защита не в ядре операционки находится, а на прикладном уровне. Это принципиально. А на этом уровне можно навертеть что угодно при наличии ресурсов..
V>>IOMMU можно сказать что и нет. А как будет в полный рост — то это замена DMA. А что у нас происходит в DMA — мы знаем. У каждого производителя за несколько лет накопится целая серия спецификаций, по одной на каждую генерацию чипсета. WH>Только все они будут сводиться к тому разрешить ли доступ конкретной железке к конкретной страницы памяти. WH>Те SetAccess(device, page, access) : bool. WH>Вот и весь интерфейс IOMMU драйвера.
Ты потерял нить. Даже драйвер DMA тоже имеет простой интерфейс, речь была о том, что рано или поздно самих этих драйверов IOMMU будет много.
V>>Потому что в Windows не сложилась культура обслуживания привилегий, хотя бы на уровне Линукс. При том, что если брать не культуру, а функциональность системы, отвечающей за привилегии, то она в виндах многократно покруче будет. WH>Бла-бла-бла. WH>Ибо узел ботнета может встать и под юзером. Ему много не надо.
Прописать себя для автостарта не сможет, если правильно зону безопасности для интернета задать под виндами.
Здравствуйте, vdimas, Вы писали:
C>>Конфиги — в приватном хранилище или через сервис конфигураций (см. Андроид). Логи — в приватном хранилище или через сервис логов (см. Android). V>Дык, куда смотреть? На сфероконей или реальную Сингулярити? Или ты совсем потерялся?
Оберон — это один сплошной сфероконь. Точнее, сферическая какашка коня.
В Сингулярити, кстати, сервис логов есть.
V>1. Твой говноандроид вообще вскрывается на раз;
Программой без привиллегий? Неа, не вскрывается.
V>2. По безопасности кода ему до Оберона как до пекина раком;
Ты вообще понял о чём говоришь? В Обероне безопасности НЕТ ВООБЩЕ.
Её не то что не надо взламывать, а её НЕТ ВООБЩЕ И ПОЛНОСТЬЮ. Любой модуль может что угодно делать с системой. Показать как БлювотнуюБутылку сломать простой программой?
V>3. По эффективности работы ему до Оберона как до Пекина раком туда и обратно;
Ну раз сказал — давай бенчмарки. На ARM-устройстве.
Здравствуйте, vdimas, Вы писали:
V>>>Агащаз. Базу данных я буду хранить даже на разных жестких дисках, вынося text/blob на отдельный физический носитель. C>>Ну вот тогда ты в специальном менеджере замонтированых дисков явно дашь разрешение своей БД на работу с другим носителем. V>Прямо-таки на весь носитель??? Шарик, да ты... ну ты понял... Это не ложится на предложенную модель безопасности вообще никак. С т.з. этой модели и носителей-то никаких для юзверя нет, тома в лучшем случае.
Ну да. Подумать дальше одного шага — неее, невозможно.
Понятное дело, что можно и на часть носителя. Возможно, реализованную в виде виртуального раздела или отдельного файла/каталога. Это совершенные мелочи реализации.
V>И для избежания разночтений, заранее поясню, что консоль к базе — это не RDP-сессия, в которой запросто можно показать диалог от имени другого юзверя (ситемной записи, типа как выскакивают диалоги в Win7), это просто соединение по TCP + аутентификация всего одним юзвером, + функциональность на основе библиотек, аналогичных SQLDMO/SQLSMO/SQLRMO. V>Смогешь разрулить, как считаешь?
1) Ты сполз с обычных приложений на какие-то непонятнораспределённые системы. Далее:
- А как это делается НА ОБЕРОНЕ?
— Очень просто, так как на Обероне нет баз данных. Checkmate. Муахахаха.
2) Никаких проблем с надёжной передачей идентичности пользователя через TCP нет. Этим занимается, для примера, Kerberos и задача сводится к: "открываю на удалённом хосте консольку под местным администратором и говорю 'на носителе XX разрешить создавать базу данным пользователям группы ПОЛЬЗОВАТЕЛЬ_БД' ".
Понятно, что для обеспечения общих инвариантов безопасности будет требоваться, чтобы клиентские системы тоже были безопасными. Тогда общение через сеть будет просто частным случаем посылки сообщений.
Здравствуйте, Cyberax, Вы писали:
C>И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует.
Тебе не пофиг ли, что именно признает некий vdimas из интернета? Тебя объективная реальность интересует или чтобы тебе было в споре комфортно? Ссылки на реальные проекты уже приводил.
Здравствуйте, vdimas, Вы писали:
C>>И так, следовательно, на мою просьбу привести пример реального кода на Обероне — ты признаеёшь, что такого кода не существует. V>Тебе не пофиг ли, что именно признает некий vdimas из интернета? Тебя объективная реальность интересует или чтобы тебе было в споре комфортно? Ссылки на реальные проекты уже приводил.
Где они? Где их можно скачать и посмотреть?
Real-time tasks
Real-time tasks have highest priority
Can interrupt garbage collector
Garbage collector runs as separate thread (так как там древний как говно мамонта трёхцветный GC)
Are not allowed to modify object graph ещё бы, так как может столкнуться с GC
Are not allowed to allocate memory
Are not allowed to use thread synchronization constructs such as
EXCLUSIVE and AWAIT
May only call procedures/methods that itself do not allocate memory
Enforced by compiler directive
Здравствуйте, WolfHound, Вы писали:
V>>Правда в ИДЕ под Оберон этот SYSTEM хоть специально подсвечивается, а где такое же для модуля Obj в OCaml или unchecked (или как его там) в Haskell? WH>Ты опять сам с собой разговаривашь. WH>
WH>На паскалеподобных языках меньше делают ошибок на каждый чих, в сравнении с недотипизированными OCaml или Си.
Ну дык я видел не раз в реальных программах и библиотеках на OCaml опасные конструкции.
V>>Докажи обратное. Сценарии, где он предпочтительнее всех, я уже давал неоднократно, но ты не соизволил их проанализировать. К тому же, парсер оперативный, без откатов, поэтому на своих сценариях WH>Не давал. WH>Ни одного. WH>Только с умным видом говорил, что они есть.
Давал раз 10.
1. Парсинг потока из сети. Область деятельности — EDI. Размеры документов — мегабайты. Неоднозначность низкая, но не позволяет обходиться регулярными грамматиками. Любые парсеры с откатами в таких сценариях выглядят убого.
2. ЯВУ с высокой степенью неоднозначности, но "неглубокими" выражениями. Типичный представитель — С++. Парсеры с откатами тоже сосут не нагибаясь, поэтому LALR или GLR.
Вырезка:
C and C++ both allow the following statement:
x * y ;
It has two different parses:
It can be the declaration of y, as pointer to type x
It can be a multiply of x and y, throwing away the answer.
...
And if you cheat enough, you can make LR parsers work for C and C++. The GCC guys did for awhile, but gave it up for hand-coded parsing, I think because they wanted better error diagnostics.
There's another approach, though, which is nice and clean and parses C and C++ just fine without any symbol table hackery: GLR parsers. These are full context free parsers (having effectively infinite lookahead). GLR parsers simply accept both parses, producing a "tree" (actually a directed acyclic graph that is mostly tree like) that represents the ambiguous parse. A post-parsing pass can resolve the ambiguities.
We use this technique in the C and C++ front ends for the DMS Software Reengineering Tookit. They have been used to process millions of lines of large C and C++ systems, as well as dozens of other languages.
V>>он крайне популярен. В комфортных для себя сценариях работает со скоростью лексера, только даже еще быстрее в несколько раз (в переводе на мегабайты исходного текста). Почему так — предлагаю догадаться самому. WH>В комфортных это на LR(0) грамматике?
Дык, чтобы ему сравнять по скорости хотя бы с лексером, надо до десятка одновременных веток протягивать до конца. А по опыту реального использования — в среднем болтаются 2-4 ветки на тех коротких участках, где этих веток больше одной. В приведенном примере в точке ';' опять наступает однозначность. А все неумершие варианты хранятся очень эффективно, переиспользуя общие части дерева разбора.
V>>Если есть что по-существу — ответь там и кинь мне ссылку. WH>Я тебя отправил читать про альфабленд. WH>Вот и почитай. WH>И подумай, как это относится масштабированию. WH>И фильтр на тех картинка был строго один и тот же.
Назови просто имя алгоритма фильтрации и/или ресэмплинга. Я гуглом пользоваться умею. Либо опиши словами (можно на псевдокоде) алгоритм, я тебе скажу как он называется. Самому не любопытно разве узнать, какой именно велосипед ты самостоятельно изобрел?
Лично для меня всегда фан узнавать, что я самостоятельно изобретал, скажем прямо, нетривиальные вещи. В до-интернетныен времена такое происходило регулярно.
V>>Я видеотехнике и обработке изображений посвятил достаточно лет, мне эти темы преобазований/калибровки цветовых пространств интересны. WH>Не заметно.
Пока до технических моментов не дойдем, заметно не будет.
V>>Это не тоже самое, ес-но. Это местами эффективней, местами нет. Как раз по работе довожу эффективность различных способов передачи данных/сигналов м/у потоками. В каких-то сценариях рулят lock-free буфера (аналоги твоих каналов), а в каких-то всех заруливает обыкновенный shared доступ с короткими блокировками. Думать, что есть единое лекарство на все случаи — это ммм... как минимум непрофессионально, если не сказать покрепче. WH>Ты опять сам с собой разговариваешь. WH>Ты тут толкал мысль о том, что сингулярити и бутылка одинаковые.
Ну дык, Сингулярити ограниченее, понятно. Ограничь бутылку, например, попроси у меня качественную реализацию межпотоковой очереди с элегантно решенной ABBA-проблемой и эффективным пулом, переложи это дело на модуль Оберона, и будут в ней такие же ограниченные каналы, как в Сингулярити. Про инсталлятор с верификатором говорил уже. Это же не ядро ОС, это просто запускаемое приложение. Это инфраструктура.
V>>И да, показательно, что как только я попытался тебя сосредоточить на том, что как создаются сами каналы (не из глобальной ли кучи?), ты продемонстрировал игнор. Собсно, как и всегда, когда доходим до конкретики — тебя сразу нет. WH>Не из глобальной.
Разочарую, сами каналы создаются из глобальной кучи и регистрируются в глобальных же списках. А под сообщения в канале в Сингулярити используется простейший пул памяти. Такой пул генерили компиляторы Паскаля еще в те времена, когда я только программировать учился.
