концепция интересная.. но чтото мне кажеца что без железа соответствующего — все это будет тормозно..
(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было).
Здравствуйте, fgrdn, Вы писали:
F>(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было).
Зачем хранить снимок экрана?
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, fgrdn, Вы писали:
F>>(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было). DOO>Зачем хранить снимок экрана?
Очевидно же, что бы с ним работать, модифицировать, etc...
Здравствуйте, fgrdn, Вы писали:
F>концепция интересная.. но чтото мне кажеца что без железа соответствующего — все это будет тормозно.. F>(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было).
У меня линух давно так работает. Это называется compositing window manager. Некоторые вещи даже быстрее получаются. Например, таскать окошки с места на место, поскольку не надо беспокоить программы, к которым относятся затронутые этой деятельностью окошки. Насколько я понимаю, новомодные интерфейсы в Висте и Маке работают примерно так же.
У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
Здравствуйте, Nik_1, Вы писали:
N_>http://www.computerra.ru/interactive/546249/
А почему в КУ? Концепция очень оригинальная, сам Дмитрий производит впечатление очень квалифицированного специалиста, который даст фору многим. Работа, которая уже проделана — вызывает огромное уважение, причем сделано все на энтузиазме. Может и выстрелить, если повезет — далеко не тот случай, чтоб смеяться.
E>Здравствуйте, Nik_1, Вы писали: N_>>http://www.computerra.ru/interactive/546249/ E>А почему в КУ? Концепция очень оригинальная, сам Дмитрий производит впечатление очень квалифицированного специалиста, который даст фору многим.
Человек, с нулевым системным бэкграундом, совсем не производит впечатление, даже борода не спасает.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, elmal, Вы писали: E>сам Дмитрий производит впечатление очень квалифицированного специалиста, который даст фору многим.
Ну ну)) А помоему чел вообще оторван от мира и живет в своей паралельной реальности
С Unix ситуация вот какая. Изначально вообще не планировалось поддерживать юниксовый код, потому что родная среда "Фантома" не позволяет поддерживать старые языки программирования — такие как C и Pascal. Есть очень чёткое разделение: есть managed-языки и не-managed языки. Не-managed-языки мы напрямую не поддерживаем. Это совершенно не проблема для современной разработки, потому что сейчас всё делается уже на managed-языках. Но есть довольно большое количество старого кода, написанного на C, на Pascal, на C++.
Ещё один пример — когда лет десять назад появилась Java (как язык программирования), производительность программ на Java была катастрофически хуже, чем производительность программ на C++. Что не помешало Java "вынести" C++ просто с корнями. Можно считать, что C++ сейчас не существует, а Java сегодня — язык номер один.
O>>Кстати концепция какаято знакомая, гдето когда то давно я уже читал такие идеи ("персистное" окружение). К>Smalltalk, например. Всю среду ношу с собой.
Не, я читал это именно в качестве фичи ОС. Кстати мб это и был фантом, в таком случае наверно он очень баянист
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>Кстати концепция какаято знакомая, гдето когда то давно я уже читал такие идеи ("персистное" окружение).
К примеру, EROS, Coyotos и подобные им системы.
Здравствуйте, ononim, Вы писали:
К>>Smalltalk, например. Всю среду ношу с собой. O>Не, я читал это именно в качестве фичи ОС. Кстати мб это и был фантом, в таком случае наверно он очень баянист
Ну, смолток предполагает гомогенное окружение — смолточья виртуальная машина. Чем не ОС?
Опять же, обероновские блэкбоксы и блуботлы...
Или вот у вас стоит система, которая занимается жизнеобеспечением больного в больнице. Бросок питания — она перезапустилась и снова должна переинициализировать своё состояние, а больной до этого может просто не дожить. "Фантом" гарантирует ей перезапуск в рабочем состоянии. Оно может быть не вполне тем же самым, что и до выключения, но начнёт система не с нуля, а с полного состояния.
3V>Или вот у вас стоит система, которая занимается жизнеобеспечением больного в больнице. Бросок питания — она перезапустилась и снова должна переинициализировать своё состояние, а больной до этого может просто не дожить. "Фантом" гарантирует ей перезапуск в рабочем состоянии. Оно может быть не вполне тем же самым, что и до выключения, но начнёт система не с нуля, а с полного состояния.
Остапа несет Но у меня есть ощущения что либо в виде тушки либо в виде чучела он фантома сделает.
Здравствуйте, ononim, Вы писали:
O>Человек, с нулевым системным бэкграундом, совсем не производит впечатление, даже борода не спасает.
Вопрос такой — знаком лично с автором, или судишь по статье? Я, например, в свое время, не поленился, и сходил на его презентацию, было весьма интересно. Подробности, блин, уже забыл, к сожалению. Рассказывал он не только про свою ОС, а еще и про разработку high load приложений, чем и занимается в основном. ОС это у него типа хобби, если что. Ну а относительно нулевого системного бэкграунда, я не знаю, какой он у тех, у кого не нулевой, но что-то у меня сомнения, что много народу могут похвастать тем, что они написали ядро ОС, которая мгновенно сохраняет содержимое памяти на диск, не тормозя выполнение программ. Сам он, кстати, вполне признает, что да — его обвиняют в том, что он пытается создать православную ОС, что пилит деньги из буджета и т.д. Так вот — выглядит более чем вменяемым, технически более чем грамотен, на вопросы отвечает весьма неплохо — делеко не тот, над кем стоило бы смеяться. Это явно не Петрик, Горлов и Денис Попов.
Здравствуйте, Nik_1, Вы писали:
N_>Ну ну)) А помоему чел вообще оторван от мира и живет в своей паралельной реальности
Эээ, а можно спросить — какая сейчас правильная реальность ? А то, в этой параллельной реальности, минимум половина RSDN живет, если что. А некоторые в еще более параллельной реальности живут, для них функциональные языки актуальны.
O>>Человек, с нулевым системным бэкграундом, совсем не производит впечатление, даже борода не спасает. E>Вопрос такой — знаком лично с автором, или судишь по статье?
По статье:
— "Я приведу несколько примеров, и вы увидите, что они действительно интересные и сложные, но по областям достаточно разные. Один из этих примеров — крупный портал для системы e-commerce — торгового интегратора класса "Яндекс.Маркета" (собственно, "Яндекс.Маркет" — тоже мой проект — им я занимался в компании "Яндекс", и можно сказать, что это моё детище)."
— "Второй пример — это "Гардемарин", который с вебом никак не связан. Это достаточно серьёзный софтверный проект, он ориентирован на мониторинг судовых систем"
— "Третий пример — это наша работа с "Мосводоканалом". Мы с ними разрабатываем систему, которая поможет "Мосводоканалу" быстрее реагировать на информацию об авариях и получать более точное представление о месте аварии."
Заглянул еще на сайт его компании — Digital Zone — судя по списку проектов http://www.dz.ru/portfolio/clients/ — контора полностью ориентирована на web. А фантом и статьи про него — просто PR для этой конторы.
То есть в качестве профессионально выполненного порфтолио у него строго прикладные апликухи. В области безопасности, разработки кросс-платформнных нативных приложений, разработки библиотек для 3rd party использования — пусто. Потому боюсь что так же пусто будет в его ОС в этих наиболее критичных для современных ОС областях.
E>Я, например, в свое время, не поленился, и сходил на его презентацию, было весьма интересно. Подробности, блин, уже забыл, к сожалению. Рассказывал он не только про свою ОС, а еще и про разработку high load приложений, чем и занимается в основном. ОС это у него типа хобби, если что. Ну а относительно нулевого системного бэкграунда, я не знаю, какой он у тех, у кого не нулевой, но что-то у меня сомнения, что много народу могут похвастать тем, что они написали ядро ОС, которая мгновенно сохраняет содержимое памяти на диск, не тормозя выполнение программ.
Системный бэкграунд — это не ядро ОС. Это разработка приложений, которые сами по себе не просто выполняют какую либо прикладную задачу, а являются этакими system-wide хелперами для остальных приложений и ОС. Это антивирусы, файрволлы, системы хранения и резервного копирования данных, библиотеки реализующие некий прикладной функционал но при этом предоставляющие широко используемый приложениями других производителей API. Ну и понятное дело всякие драйвера
E>Сам он, кстати, вполне признает, что да — его обвиняют в том, что он пытается создать православную ОС, что пилит деньги из буджета и т.д. Так вот — выглядит более чем вменяемым, технически более чем грамотен, на вопросы отвечает весьма неплохо — делеко не тот, над кем стоило бы смеяться. Это явно не Петрик, Горлов и Денис Попов.
Вот для этого он и это признает — дабы его не сравнивали с "Петрик, Горлов и Денис Попов". Просто немного больше наглости и все.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, skeptic, Вы писали:
S>Здравствуйте, DOOM, Вы писали:
DOO>>Здравствуйте, fgrdn, Вы писали:
F>>>(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было). DOO>>Зачем хранить снимок экрана?
S>Очевидно же, что бы с ним работать, модифицировать, etc...
Модифицируют данные которые отображаются на экране, а не содержимое экрана.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Nik_1, Вы писали:
N_>>Ну ну)) А помоему чел вообще оторван от мира и живет в своей паралельной реальности E>Эээ, а можно спросить — какая сейчас правильная реальность ? А то, в этой параллельной реальности, минимум половина RSDN живет, если что. А некоторые в еще более параллельной реальности живут, для них функциональные языки актуальны.
Можно считать, что C++ сейчас не существует,
Т.е. тебя совсем не смущает эта фраза и в твоей реальности его давно уже нет?
На нече так что 90% используемого нами ежедневно софта написаны на несуществующем языке
Здравствуйте, elmal, Вы писали: E>что много народу могут похвастать тем, что они написали ядро ОС, которая мгновенно сохраняет содержимое памяти на диск, не тормозя выполнение программ.
А ты или еще кто её в глаза вообще видели? Эта ось существует еще гдето за пределами его воображения и её можно запустить и пощупать? А то помойму пока она вполне оправдывает свое название
Здравствуйте, Nik_1, Вы писали:
N_>А ты или еще кто её в глаза вообще видели? Эта ось существует еще гдето за пределами его воображения и её можно запустить и пощупать? А то помойму пока она вполне оправдывает свое название
На виртуалке она работает, если что, так что видел. Естественно сырая, полюбовался на отладочную инфу и т.д. Тут дело такое — эта ос не позиционируется как десктопная, если что. Реальное применение — встраиваемые системы — бортовые компьютеры, навигаторы и т.д. Заточена исключительно под управляемый код. Нет, конечно автору б хотелось, чтоб она на каждом десктопе стояла, но не думаю, что он сам в это верит, а вот там, где он ее позиционирует — почему нет?
Здравствуйте, Nik_1, Вы писали:
N_>http://www.computerra.ru/interactive/546249/
Первое впечатление, что декларируемая задача в императивной парадигме не решаема. Как бы не желалось, а команды выполняются в памяти, и только там. Адресовать все доступное пространство единым гиперадресом утопия. При реализации, по любому прийдется создавать копию в памяти. А тут архитектура компа и императивная концепция программирования позволяет изменить все. Вот косвеной адресацией, да еще со смещением прибавили единичку бог знает где в памяти и что делать? После каждой команды сохранять всю доступную память? Чушь. Делать это в контрольных точках, так как быть с копией на диске? Там другая структура файла. Напомню, что при загрузке понадобится связывание, т.е. формирование адресов.. Что уже изменит программу и она будет отличаться своей структурой от копии на диске..А во время выполнения она совсем будет иметь мало общего со своей копией оставшейся на диске.. А данные тем более. Если они изменились? То установить когда их можно сохранять (в смысле угадать момент когда мы можем сохранить что-то осмысленное) может только программист. Ну, возьмем, к примеру, сортировку. Хотя нет. Сортировку можно продолжить хоть с начала. А вот складываем каждый элемент массива с предыдущим! ну, и прервалось.. Что будем делать? Никакая умная система не подскажет момент, когда можно начать сохранять и что, для того что бы беспроблемно восстановится. Единственный вариант, это полный дамп страницы, и среды. Т.е. всего доступного для программы пространства. Но это придумано давно.
Реально создать такую фишку в функциональной парадигме. Там не допускается изменение внешней среды (во всяком случае в рамках парадигмы). Но, нужно что б система быстро и единым алгоритмом опознала и выделила объекты для сохранения (кстати, такой вариант у меня проработан). Есть еще проработаные вещи которые можно было бы (и нужно) использовать.
Но, вот чем иерархия не угодила? Это ж природа объектов. Внутри комнаты мебель, в документе буквы и слова, среди черных туфель есть мужские и женские. Другой вопрос что иерархия должна быть множественой. Потому что среди мужских туфель есть и черные и коричневые. И доступ должен быть по любой из актуальной для пользователя иерархий. Толи сначала по цвету, а потом по моделям, а можно и наоборот. Среди моделей искать требуемый цвет.
Хранить данные в наиболее подходящем для них виде, это одобряю. Делается легко. Формат объектов (в виде классов) должен находится в самом файле. И не нужны расширения. Но тогда столько проблем вылезетНе только в виде не приятия.. Испытал на себе.. Уже предлагал.. Это совсем новые не стыкующиея ни с чем уже созданым файлы. Зато в перспективе глобализации самое то! Единый редактор (он же браузер, он же транслятор и т.д.) хавает все файлы. Это же формат служит протоколом обмена. Забываем вообще про загрузку и сохранение фалов. На основе единого формата система все сама загрузит и сохранит.
А вообще интересно было бы с ним пообщаться. Может он чего-то придумал и не делится. В лоб эта проблема не решается. Как быть с языками типа Си, джавы.. они ж императивные..
Как говорят либо гений, либо мошенник Хотелось бы что бы первое!
Здравствуйте, batu, Вы писали:
B>Здравствуйте, Nik_1, Вы писали:
B> Хранить данные в наиболее подходящем для них виде, это одобряю. Делается легко. Формат объектов (в виде классов) должен находится в самом файле. И не нужны расширения. Но тогда столько проблем вылезетНе только в виде не приятия.. Испытал на себе.. Уже предлагал.. Это совсем новые не стыкующиея ни с чем уже созданым файлы. Зато в перспективе глобализации самое то! Единый редактор (он же браузер, он же транслятор и т.д.) хавает все файлы. Это же формат служит протоколом обмена. Забываем вообще про загрузку и сохранение фалов. На основе единого формата система все сама загрузит и сохранит.
Этот же формат объектов позволяет передавать объекты между приложениями вместо OLE
Здравствуйте, 3V, Вы писали:
3V>Здравствуйте, Nik_1, Вы писали:
3V> Или вот у вас стоит система, которая занимается жизнеобеспечением больного в больнице. 3V> Бросок питания — она перезапустилась и снова должна переинициализировать своё состояние, 3V> а больной до этого может просто не дожить. "Фантом" гарантирует ей перезапуск в рабочем
не фиговая у людей трава. после броска питания вся электроника в хрен знает каком состоянии, а при отключении питания фантом сдохнет раньше больного. вот потому медицинское оборудование снабжено бесперебойниками, да и запитывается хитрым образом. и дизель там есть.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Pzz, Вы писали:
Pzz>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
Здравствуйте, DOOM, Вы писали:
DOO>Здравствуйте, fgrdn, Вы писали:
F>>(постоянно снимок экрана где то надо хранить, с ним работать, модифицировать, и чтобы это все быстро было). DOO>Зачем хранить снимок экрана?
блин ну очепятолся! с работы постил %)
ессно имелось ввиду памяти а не экрана
Здравствуйте, master_of_shadows, Вы писали:
__>Здравствуйте, Pzz, Вы писали:
Pzz>>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
__>Как же нет, когда есть: http://www.dz.ru/solutions/phantom#13
тут написано, что "Основное know how Фантома состоит именно в умении дёшево создавать мгновенные снимки состояния системы, не останавливая её и не внося серьёзных возмущений в работу", т.е. заявляется, что главное достоинство только одно. само достоинство, действительно, интересное, но тут же возникает куча вопросов и первый из них -- а работает ли это или только заявляется, что оно работает? каких усилий оно требует от программиста? как на счет железа? у винды с этим огромные проблемы. по выходу из спячки не все настройки восстанавливаются. скажем, какой-то драйвер за какой-то надобностью изменил частоту системного таймера (грубый пример, но для примера сойдет). а при усыплении никто не позаботился о том, чтобы опросить новую частоту и потом ее перепрограммировать. а если кто-то побаловался недокументированными настройками, то все пропало.
а это точно ноу-хау? варя тоже делает слепки дешево и сердито, причем без отрыва от процесса работы. и, кстати, без необходимости создания новой оси. тогда уж лучше написать свой виртуализатор и пускать в нем вынь и никсы, сохраняя состояние в виртуализаторе и не трогая ось.
как соотносятся снимки с релтаймом?! тут один сборщик мусора в общем случае не может применяться в реалтаймовых системах, а прикиньте какие задержки может вносить в работу создатель снимков? где гарантия, что все не развалится?
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
Pzz>>>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
__>>Как же нет, когда есть: http://www.dz.ru/solutions/phantom#13 М>тут написано, что "Основное know how Фантома состоит именно в умении дёшево создавать мгновенные снимки состояния системы, не останавливая её и не внося серьёзных возмущений в работу", т.е. заявляется, что главное достоинство только одно. само достоинство, действительно, интересное, но тут же возникает куча вопросов и первый из них -- а работает ли это или только заявляется, что оно работает? каких усилий оно требует от программиста? как на счет железа? у винды с этим огромные проблемы. по выходу из спячки не все настройки восстанавливаются. скажем, какой-то драйвер за какой-то надобностью изменил частоту системного таймера (грубый пример, но для примера сойдет). а при усыплении никто не позаботился о том, чтобы опросить новую частоту и потом ее перепрограммировать. а если кто-то побаловался недокументированными настройками, то все пропало.
М>а это точно ноу-хау? варя тоже делает слепки дешево и сердито, причем без отрыва от процесса работы. и, кстати, без необходимости создания новой оси. тогда уж лучше написать свой виртуализатор и пускать в нем вынь и никсы, сохраняя состояние в виртуализаторе и не трогая ось.
М>как соотносятся снимки с релтаймом?! тут один сборщик мусора в общем случае не может применяться в реалтаймовых системах, а прикиньте какие задержки может вносить в работу создатель снимков? где гарантия, что все не развалится?
Ну навалил ... Я ответил на выделенное болдом. У ФантомОС есть килерфича. Вопрос реализации — это уже второй вопрос.
Здравствуйте, master_of_shadows, Вы писали:
Pzz>>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
__>Как же нет, когда есть: http://www.dz.ru/solutions/phantom#13
Ну это какая-то высосаная из пальца полезность, IMHO.
Здравствуйте, мыщъх, Вы писали:
М>тут написано, что "Основное know how Фантома состоит именно в умении дёшево создавать мгновенные снимки состояния системы, не останавливая её и не внося серьёзных возмущений в работу", т.е. заявляется, что главное достоинство только одно. само достоинство, действительно, интересное,
Это достоинство, по-моему, интересно только в научно-познавательном смысле.
И кстати, довольно очевидно, что совершенно не обязательно делать постоянные снимки программы, если существует возможность вместо этого запомнить последовательность событий, которые видела программа, от момента последнего снимка (событий в широком смысле слова. Т.е., если она на часы посмотрела, это тоже событие).
Тогда достаточно восстановить последнее запомненное состояние и промотать у нее перед носом все события после того.
Я вот только не понимаю, нафиг это надо. Т.е., я могу себе представить случай, когда такое может быть полезно, но подавать это как панацею от всего...
Например, зачем мне персистентность, если программа сошла с ума? Мне надо перезапустить ее с разумного места, дав ей на вход еейные файлы в том состоянии, когда я еще знал, что они не поломаны. А у Завалишина и файлов-то не предполагается, как я программу-то перезапущу? С момента ее инсталляции? Вот щастье-то...
Здравствуйте, Pzz, Вы писали:
Pzz> Я вот только не понимаю, нафиг это надо. Т.е., я могу себе представить случай, Pzz> когда такое может быть полезно, но подавать это как панацею от всего...
угу. особенно в критических областях типа мед. оборудования. а у "абрасма" если не наврали его разработчики после каждого выстрела из танка был штатный перезапуск.
Pzz>Например, зачем мне персистентность, если программа сошла с ума? Pzz>Мне надо перезапустить ее с разумного места, дав ей на вход еейные файлы в том состоянии, Pzz>когда я еще знал, что они не поломаны. А у Завалишина и файлов-то не предполагается,
кстати, горящий лис, автоматически восстанавлищий себя после падения, заставляет меня ругаться матом, ибо после падения он обычно падает снова, особенно если нас занесло на вредоносный сайт. так что тут нужно четко продумать как делать "откат" к реально стабильному состоянию.
Pzz> как я программу-то перезапущу? С момента ее инсталляции? Вот щастье-то...
это меня тоже интересует. я, ксати, до сих пор не пользуюсь "сном" (даже на ноутах), предпочитая штатную загрузку, ибо со сном то там, то тут вылезают разные косяки (ну вот мой делл очень некорректно обрабывает выход из сна при подключении его в спящем состоянии к док-станции).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
Pzz>> Я вот только не понимаю, нафиг это надо. Т.е., я могу себе представить случай, Pzz>> когда такое может быть полезно, но подавать это как панацею от всего... М>угу. особенно в критических областях типа мед. оборудования. а у "абрасма" если не наврали его разработчики после каждого выстрела из танка был штатный перезапуск.
Ну, Завалишин-то попсу пытается делать, а не ОС для "абрамса".
М>кстати, горящий лис, автоматически восстанавлищий себя после падения, заставляет меня ругаться матом, ибо после падения он обычно падает снова, особенно если нас занесло на вредоносный сайт. так что тут нужно четко продумать как делать "откат" к реально стабильному состоянию.
Я помню, OS/2 древняя тоже после падения пыталась все открытые окна вернуть на место. С предсказуемым результатом
М>это меня тоже интересует. я, ксати, до сих пор не пользуюсь "сном" (даже на ноутах), предпочитая штатную загрузку, ибо со сном то там, то тут вылезают разные косяки (ну вот мой делл очень некорректно обрабывает выход из сна при подключении его в спящем состоянии к док-станции).
В венде у меня тоже сон не работает толком. А в линухе работает очень гладенько, прям на удивление. На делловском лабтопе.
Здравствуйте, Pzz, Вы писали:
Pzz>Например, зачем мне персистентность, если программа сошла с ума? Мне надо перезапустить ее с разумного места, дав ей на вход еейные файлы в том состоянии, когда я еще знал, что они не поломаны.
Зависит все от реализации на деле. Но если сошла с ума — программа может имплементить интерфейс рестарта, например. Соответственно, в случае проблем — дернул этот интерфейс, и все ок. Не знаю как Завалишин это рассматривает, но я б просто для таких случае интерфейс рестарта имплементировал.
Здравствуйте, мыщъх, Вы писали:
__>>Как же нет, когда есть: http://www.dz.ru/solutions/phantom#13 М>тут написано, что "Основное know how Фантома состоит именно в умении дёшево создавать мгновенные снимки состояния системы, не останавливая её и не внося серьёзных возмущений в работу", т.е. заявляется, что главное достоинство только одно. само достоинство, действительно, интересное, но тут же возникает куча вопросов и первый из них -- а работает ли это или только заявляется, что оно работает? каких усилий оно требует от программиста?
Не в OS как уже писали выше это все давно уже реализовано, практически все Smalltalk системы так живут и на них было написано немало промышленного кода. В общем концепция вполне рабочая и плюсов у нее немало, а вот смогут ли нормально реализовать не известно.
Здравствуйте, Pzz, Вы писали:
Pzz>Например, зачем мне персистентность, если программа сошла с ума? Мне надо перезапустить ее с разумного места, дав ей на вход еейные файлы в том состоянии, когда я еще знал, что они не поломаны. А у Завалишина и файлов-то не предполагается, как я программу-то перезапущу? С момента ее инсталляции? Вот щастье-то...
Ну в тез же Smalltalk системах есть версионность, да и точки сохранения сделать вполне возможно, хотя конечно дисковой памяти будет нужно больше чем для обычных OS.
Здравствуйте, Pzz, Вы писали:
Pzz>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать.
Собственно, насколько я понимаю, он хочет сделать ОС на управляем коде. Ничего нейтивного вообще — нейтив только после JIT компиляции, это уровень виртуальной машины, а не ОС. Проблемы — плохая ситуация с компонентностью в существующих системах. В юниксах каша, а винде ситуация получше, но тоже не очень хорошо. Соответственно 2 мегафичи у него, насколько я понимаю — персистентность очень оригинальная, и прекрасная компонентность и реюз существующих компонентов. Не очень уверен, что я правильно понял за счет чего она достигается, но насколько я понимаю — все просто. Программа — это обычный объект виртуальной машины. Память линейная, процессы не изолированы, адресное пространство едино, потому — если что кому понадобилось — может без проблем обратиться, причем никаких маршаллингов и тому подобное не требуется. Согласен, что такое решение выглядит очень спорно, но чтоб осуждать это — надо получше понимать концепцию, про детали я не знаю, возможно у него и есть решение относительно проблем безопасности и надежности, тут надо у него спрашивать. Помню спрашивали у него на конференции, он что-то отвечал на этот счет, но уже не помню детали, как обойти проблемы у него вроде есть решение. Лично мне представить это все на десктопе крайне сложно, а вот для нишевых решений плюсы могут перевесить минусы. Безопасность далеко не факт, что у него продумана, возможно идеи у него есть на этот счет, но я не в курсе.
Здравствуйте, elmal, Вы писали:
E>Зависит все от реализации на деле. Но если сошла с ума — программа может имплементить интерфейс рестарта, например. Соответственно, в случае проблем — дернул этот интерфейс, и все ок. Не знаю как Завалишин это рассматривает, но я б просто для таких случае интерфейс рестарта имплементировал.
Настоящий рестарт тем и хорош, что туда разработчики программы не могут сунуть свои грязные пальчики. Поэтому он работает с гарантией. А "интерфейс рестарта", я представляю, чего туда будут совать. Из лучших побуждений, разумеется.
Здравствуйте, Nik_1, Вы писали:
N_>http://www.computerra.ru/interactive/546249/
Интересно а автору не приходило в голову что файлы на диске как правило занимают много меньше места чем тоже самое в памяти программы.
Наиболее яркий пример это сжатые медиаформаты.
Еще очень хороший пример это исходный код и то сколько памяти выжерает IDE для того чтобы обеспечить навигацию итп.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, elmal, Вы писали:
Pzz>>У Завалишина, по-моему, проблема в другом: у него нет ясного ответа, зачем нужна новая ОС, какие проблемы она должна решать. E>Собственно, насколько я понимаю, он хочет сделать ОС на управляем коде.
Осей на управляемом коде хоть попом кушай. Среди них есть и поинтереснее, чем завалишинских hibernate на стероидах. Та же Inferno, например. Но никакую революцию они не произвели. Так что нафиг-нафиг.
E> Помню спрашивали у него на конференции, он что-то отвечал на этот счет, но уже не помню детали, как обойти проблемы у него вроде есть решение. Лично мне представить это все на десктопе крайне сложно, а вот для нишевых решений плюсы могут перевесить минусы. Безопасность далеко не факт, что у него продумана, возможно идеи у него есть на этот счет, но я не в курсе.
Для нишевых решений хочется производительности, надежности, массштабируемости в обе стороны и т.п. А не того, с чем носится Завалишин
N_>Т.е. тебя совсем не смущает эта фраза и в твоей реальности его давно уже нет? N_>На нече так что 90% используемого нами ежедневно софта написаны на несуществующем языке
Потому что 90% этого софта использует код, написаный как раз лет 10-15 тому назад, когда Java только появлялась. Legacy такой legacy.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, мыщъх, Вы писали:
М>>тут написано, что "Основное know how Фантома состоит именно М>>в умении дёшево создавать мгновенные снимки состояния системы, FR>Не в OS как уже писали выше это все давно уже реализовано,
а тут говорится, что реализовано в ОС, то есть дается понять, что ОС знает как себя вести с железом. современное железо формально поддерживает сохранение/восстановление своего состояния при усыплении/пробуждении, но глючным образом и далеко не дешево и тем более не мгновенно.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, ononim, Вы писали: O>Человек, с нулевым системным бэкграундом, совсем не производит впечатление, даже борода не спасает.
Даже не надо задавать вопрос: А судьи кто?.
Человек с НЕ нулевым ... бэкграундом ни когда не напишет цитируемого поста.
Такой человек прекрасно понимает, что сделано, и что такое, хоть что-то сделать.
Знаком с DZ, мало того, идея "персистентности" лежит в основе разработанной нами технологии программирования Флора.
Правда у нас не ОС, а среда разработки и исполнения приложений. Есть много идеи и проблем, которые мы одинаково понимаем.
Понимаем их значимость и сложность.
В идеале было бы интересно сделать среду разработки для Фантома основываясь на Флоре.
Lever,
L>В идеале было бы интересно сделать среду разработки для Фантома основываясь на Флоре.
Скажи пожалуйста, где можно почитать про Флору (я так понял это IDE вкупе с компилятором). Интересует, какие задачи она решает, и какие подходы применяются для решения задач и в чём отличия от существующих подходов, скажем IBM/Rational. Читал http://www.inno.ru/project/14757/ но не нашёл ответов на вопросы выше.
Спасибо.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Скажи пожалуйста, где можно почитать про Флору (я так понял это IDE вкупе с компилятором).
Лет десять назад мы активно пропагандировали Флору: выступали на конференциях, писали статьи, делали презентации...
Это было время, когда мы надеялись, распространять Флору как самостоятельный продукт, как технологию, как среду разработки.
По многим причинам, зависящим не только от нас, это не получилось. Просто сложно тогда было, да и сейчас тоже, продавать среду разработки и продвигать технологию, которые требовали кардинального изменения представления о программировании и процессе создания программ.
Поэтому было принято решение продвигать не технологию Флора, а продукты созданные с ее помощью.
По большому счету Флора — это технология одного продукта — TranzWare, интересующихся отсылаю на наш сайт.
Технология одного продукта — это с одной стороны не совсем лестная характеристика. С другой стороны, если Флора развивается в течении полутора десятка лет, а продукт, созданный с ее помощью, конкурентный на столько, что позволяет ее развивать, то вернее всего, при проектировании Флоры были выбраны удачные решения.
Рассказывать про Флору просто НЕпрограммистам, потому что процесс проектирования приложений и сам вид приложений соответствуют представлениям этих людей. Создание приложений происходит методом сборки с помощью специальных редакторов, эти приложения это в чистом виде Объектная модель. Весь жизненный цикл эти приложения находятся под полным контролем проектировщика, доступны любые данные, можно выполнить с приложением любые действия.
Рассказывать про Флору сложно программистам, потому что процесс проектирования приложений и сам вид приложений НЕ соответствуют их представлениям и знаниям.
Примером может служить цитата: IDE вкупе с компилятором. И да, и нет.
Это среда разработки и среда исполнения, а видимая часть IDE сама создана на Флоре и работает под ее управлением.
Да в ядре есть компилятор, но компиляция это только оно из действий, доступное над некоторыми объектами. Программы как таковой нет, есть объекты, которые отвечают за поведение Объектной модели. Некоторые из этих объектов содержат текст на неком С — подобном языке, у которого нет декларативной части.
Одной фразой. Флора — это НЕязыковая реализация Объектной парадигмы.
Флора похожа на Smalltalk своей НЕпохожестью на другие.
Можно найти много общих черт у Флоры и Фантома. Некоторые общие основополагающие концепции мы применили во Флоре, можно посмотреть что они дали и во что обошлись.
Можно об этом поговорить, если будет спокойная атмосфера.
Здравствуйте, Lever, Вы писали:
L>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>Скажи пожалуйста, где можно почитать про Флору (я так понял это IDE вкупе с компилятором).
L>Лет десять назад мы активно пропагандировали Флору: выступали на конференциях, писали статьи, делали презентации...
[cut]
Мне одному показалось, что сказано довольно много, но практически ничего похожего на ответ на конкретный вопрос(просьбу)?
Здравствуйте, Курилка, Вы писали:
К>Мне одному показалось, что сказано довольно много, но практически ничего похожего на ответ на конкретный вопрос(просьбу)?
Просто на конкретный вопрос не ответишь. Ответить можно, но на сколько у спрашивающего увеличится объем информации о Флоре?
Своим постом я хотел показать, что я с удовольствием буду рассказывать про Флору. С другой стороны я хотел показать, что при разговоре о Флоре нужно помнить о ее принципиальных отличиях. В свете этих отличий большинство общепризнанных терминов и понятий имеют совершенно другую окраску.
Аналогия прослеживается, после отбрасывания нетехнических вопросов, и в дискуссии о Фантоме. DZ говорит о персистентности пытаясь сказать как много это значит для процесса проектирования, а слышат ли его?
К стати, на примере Флоры можно это увидеть воочию. Тоже можно и сказать об управлении объектами, действия над ними не сводятся только к конструктору и деструктору и, само собой, вызовам методов.
Пример с компонентностью, на древовидной управляемой памяти она, компонентность, реализуется в легкую.
Очень неоднозначные впечатления от прочитанного.
С одной стороны, это амбициозный проект с интересными архитектурными решениями.
С другой — трудно представить работоспособную архитектуру, которая не поддерживается
аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и
вообще системные сервисы типа переключения контекстов или управление виртуальной
памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни.
Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ?
Разработчики современных архитектур тоже не дураки ведь.
И мне кажется, что идея персистентности, если она вообще математически корректна,
способна работать только в теории, ибо на практике это означает требование обеспечения
возможности любого устройства или программы свободно прерывать и восстанавливать поток
данных в произвольный момент времени, причем согласованно и единообразно, как транзакция.
Короче, требование полной когерентности.
Как на таких архитектурах смогут работать асинхронные механизмы или
кэширование ? Что, если состояние приложения A напрямую зависит от состояния приложения B,
а их "commit-ы" относится к разным "ревизиям" ?
В моей программе в каждый момент времени крутятся десятки циклов, сотни переменных постоянно
меняют значение, происходит обращение к внешним данным и происходит много всего другого.
Реален ли сценарий, при котором процесс операционной системы без существенных потерь
будет фиксировать все происходящее, да так, чтобы связанные компоненты оставались в согласованном состоянии ?
Ну открыл я сокет, отправил по нему данные и жду. Тут система падает и ответ сервера приходит,
пока она восстанавливается. Собственно, должны восстановиться не только такие данные,
как валидный дескриптор сокета или содержимое буфера, но и показания тайм-аута,
состояние ожидание какого-нибудь объекта синхронизации, различных структур ядра,
внутренние состояния сетевого адаптера, стек TCP-пакетов и еще много-много другого.
Короче, все упирается в реализацию и множество деталей, как всегда. Я уже не говорю про ошибки,
которые есть в каждом экземпляре ПО.
Тут нужна конкретная смена парадигмы программирования и вообще, вся эта "кухня" должна
поддерживаться аппаратно, поставщиками устройств и разработчиками драйверов.
Но даже на современных, проверенных десятилетиями архитектурах, ситуация такая, что завалиться можно
даже на банальном hibernate или броске питания, как точно отметил мыщъх.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, Nik_1, Вы писали:
N_>>http://www.computerra.ru/interactive/546249/
O>Очень неоднозначные впечатления от прочитанного. O>С одной стороны, это амбициозный проект с интересными архитектурными решениями.
O>С другой — трудно представить работоспособную архитектуру, которая не поддерживается O>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и O>вообще системные сервисы типа переключения контекстов или управление виртуальной O>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни. O>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ? O>Разработчики современных архитектур тоже не дураки ведь.
Ну кстати предложенный вариант очень сильно напоминает Singularity от МС.
O>Так что время покажет.
Здравствуйте, okman, Вы писали:
O>С другой — трудно представить работоспособную архитектуру, которая не поддерживается O>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и O>вообще системные сервисы типа переключения контекстов или управление виртуальной O>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни. O>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ? O>Разработчики современных архитектур тоже не дураки ведь.
Главное преимущество managed кода знаешь?
Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).
Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.
Здравствуйте, batu, Вы писали:
B>Первое впечатление, что декларируемая задача в императивной парадигме не решаема.
... B>Реально создать такую фишку в функциональной парадигме.
Поддерживаю 100%.
B>Как быть с языками типа Си, джавы.. они ж императивные..
ПисАть на них чистые функции. Скажем, компилятор легко оформляется в виде функции текст->код.
Конечно, мы не сможем сохранять промежуточное состояние в процессе компиляции (точнее сможем с большим трудом и негрантированым результатом — так что лучше и не пытаться). Но зачем, если компиляция одного текста длится миллисекунды, максимум — секунды.
При перезапуске начнем снова. А утилиту make (или ant) — напишем заново.
Собственно, этот пример не совсем удачный, так как связка make — компилятор и сейчас обеспечивает сохранение основного объема работы при сбоях. Но эта функциональность базируется на шатком основании — времени модификации файлов. Дело за тем, чтобы найти более прочный фундамент. Можно, например, оттолкнуться от баз данных и встроенных процедур.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, okman, Вы писали:
O>>С другой — трудно представить работоспособную архитектуру, которая не поддерживается O>>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и O>>вообще системные сервисы типа переключения контекстов или управление виртуальной O>>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни. O>>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ? O>>Разработчики современных архитектур тоже не дураки ведь.
G>Главное преимущество managed кода знаешь? G>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
G>Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).
G>Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.
G>Так работает Singularity.
Если бы драйвер не делал ничего потенциально криминального, его не надо было бы и компилировать как то отлично от другого кода. Вообще бы не нужно было делать различия на программы и драйверы.
А если его компилировать статически в нативный код, то верификацию произвести не получится.
В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.
Некоторые (не помню кто) на этом форуме считают, что и x86 код можно верифицировать, но это не правда.
Так что по любому в драйвере будут потенциально опасные места.
Здравствуйте, Aleх, Вы писали:
A>Некоторые (не помню кто) на этом форуме считают, что и x86 код можно верифицировать, но это не правда.
Можно верифицировать жестко ограниченное подмножество x86 кода и это уже сделано например тут http://code.google.com/p/native-nt-toolkit/ но боюсь драйверы на таком подмножестве тоже не особо попишешь.
FR>Можно верифицировать жестко ограниченное подмножество x86 кода и это уже сделано например тут FR>http://code.google.com/p/native-nt-toolkit/ но боюсь драйверы на таком подмножестве тоже не особо попишешь.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, okman, Вы писали:
O>>>С другой — трудно представить работоспособную архитектуру, которая не поддерживается O>>>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и O>>>вообще системные сервисы типа переключения контекстов или управление виртуальной O>>>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни. O>>>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ? O>>>Разработчики современных архитектур тоже не дураки ведь.
G>>Главное преимущество managed кода знаешь? G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
G>>Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).
G>>Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.
G>>Так работает Singularity.
A>Если бы драйвер не делал ничего потенциально криминального, его не надо было бы и компилировать как то отлично от другого кода. Вообще бы не нужно было делать различия на программы и драйверы.
Еще раз: чтобы провести верификацию нужно поднять райнтайм, чтобы поднять рантайм нужен драйвер.
Твои предложения?
A>А если его компилировать статически в нативный код, то верификацию произвести не получится.
Верификация делает перед компиляцией в нативный код.
A>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам.
С чего ты взял?
A>Так что по любому в драйвере будут потенциально опасные места.
Не увидел обоснования.
Здравствуйте, gandjustas, Вы писали:
G>Главное преимущество managed кода знаешь? G>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
Аппаратные средства нужны для поддержки механизмов Фантома, о которых рассказывал Д. Завалишин.
Для таких сакральных вещей, как переключение контекста или сброс страниц памяти в файл подкачки,
в большинстве современных компьютерных архитектур поддержка заложена на уровне железа.
Без этой поддержки все держалось бы на честном слове.
Как-то не верится, что архитектурные решения Фантома можно качественно реализовать
исключительно программно.
А Singularity — это все-таки немного другое.
И, кстати, я не согласен с тем, будто managed-код исключает возможность "отстрелить себе ногу"...
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Aleх, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, okman, Вы писали:
O>>>>С другой — трудно представить работоспособную архитектуру, которая не поддерживается O>>>>аппаратно и вообще базируется на виртуальных машинах. А как же драйверы устройств и O>>>>вообще системные сервисы типа переключения контекстов или управление виртуальной O>>>>памятью ? Это тоже отдается Java ? Наверное, я отстал от жизни. O>>>>Нет ни безопасности, ни переходов в режим ядра. Ну и что в этом хорошего ? O>>>>Разработчики современных архитектур тоже не дураки ведь.
G>>>Главное преимущество managed кода знаешь? G>>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
G>>>Остается в таком случае одна проблема, которая сродни первенству яйца или курицы. Драйверы должны подниматься до виртуальных машин, но для управляемого кода нужна та самая виртуальная машина. Это решается статической компиляцией в нативный код (с той же самой верификацией) при установке драйвера. В итоге драйвер нативный, но при этом гарантированно не делает ничего криминального (и не может порушить работу системы и других драйверов).
G>>>Конечно часть ОС останется написана на низкоуровневом языке, но довольно малая часть по сравнению с современными ОС.
G>>>Так работает Singularity.
A>>Если бы драйвер не делал ничего потенциально криминального, его не надо было бы и компилировать как то отлично от другого кода. Вообще бы не нужно было делать различия на программы и драйверы. G>Еще раз: чтобы провести верификацию нужно поднять райнтайм, чтобы поднять рантайм нужен драйвер. G>Твои предложения?
Драйвер отвечает за верификацию? В общем я эту фразу не понял.
Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения.
Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее.
A>>А если его компилировать статически в нативный код, то верификацию произвести не получится. G>Верификация делает перед компиляцией в нативный код.
Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов.
A>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам. G>С чего ты взял?
Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать?
Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов.
A>>Так что по любому в драйвере будут потенциально опасные места. G>Не увидел обоснования.
Здравствуйте, okman, Вы писали:
O>Здравствуйте, gandjustas, Вы писали:
G>>Главное преимущество managed кода знаешь? G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
O>Аппаратные средства нужны для поддержки механизмов Фантома, о которых рассказывал Д. Завалишин. O>Для таких сакральных вещей, как переключение контекста или сброс страниц памяти в файл подкачки, O>в большинстве современных компьютерных архитектур поддержка заложена на уровне железа. O>Без этой поддержки все держалось бы на честном слове. O>Как-то не верится, что архитектурные решения Фантома можно качественно реализовать O>исключительно программно.
Страничная адресация — то что должно поддерживаться железом, желательно чтобы для кода (в том числе изкоуровневого) была иллюзия непрерывного бесконечного адресного пространства.
А вот насчет переключений — сейчас гораздо эффективнее работают планировщики пользовательского режима (см erlang), с управляемым кодом можно такую же парадигму вынести на уровень всей ОС.
O>А Singularity — это все-таки немного другое. O>И, кстати, я не согласен с тем, будто managed-код исключает возможность "отстрелить себе ногу"...
Он не исключает, об этом никто и не говорит, но очень сильно усложняет эту возможность, особенно случайных ошибок.
Аппаратные механизмы защиты тоже не очень-то защищают от преднамеренных атак.
Здравствуйте, Aleх, Вы писали:
A>Драйвер отвечает за верификацию? В общем я эту фразу не понял.
Нет, за верификацию отвечает рантайм (CLR\JVM\еще_что_то).
A>Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения. A>Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее.
А в Singularity прокатила.
Причем это рабочая ось, которую можно скачать и пощупать.
A>>>А если его компилировать статически в нативный код, то верификацию произвести не получится. G>>Верификация делает перед компиляцией в нативный код. A>Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов.
Это ты предполагаешь не подтверждая формальными выкладками или фактами.
A>>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам. G>>С чего ты взял? A>Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать?
Мда...
Элементарно решается, все опасные вызовы упаковываются в библиотеки, а доступ к ним регулируется специальными правами. Даже сейчас так работает.
Ассемблера в принципе не должно быть в управляемом коде, так как он должен абстрагировать от конкретной физической архитектуры.
A>Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов.
Применение С и ассемблера в особо впечатлительном возрасте видимо дает серьезный эффект.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Aleх, Вы писали:
A>>Драйвер отвечает за верификацию? В общем я эту фразу не понял. G>Нет, за верификацию отвечает рантайм (CLR\JVM\еще_что_то).
A>>Я имел ввиду вот что. Если же драйвер не делает потенциально ничего опасного, то его можно написать на управляемом языке. И точно также как и пользовательский код запускать с помощью JIT-а (базовые возможни которого работают без драйверов), и всё это будет под управлением минимального ядра (написанного на нативном языке). Но с одним отличием — у драйвера будет просто больше прав чем у обычных приложений. Когда все драйвера загружены можно загружать пользовательские приложения. A>>Но я хотел сказать, что и эта схема всё равно не прокатит. Об этом далее. G>А в Singularity прокатила. G>Причем это рабочая ось, которую можно скачать и пощупать.
A>>>>А если его компилировать статически в нативный код, то верификацию произвести не получится. G>>>Верификация делает перед компиляцией в нативный код. A>>Чтобы верифицировать высокоуровневый язык, он тоже должен обладать некоторыми свойствами, которые могут быть непремлимы для драйверов. G>Это ты предполагаешь не подтверждая формальными выкладками или фактами.
A>>>>В общем то верификацию байт кода можно сделать только тогда, когда байт код для неё предназначен (специально разрабатывался для верификации). А когда он для неё предназначен, в нем нет тех фитчей, которые нужны драйверам. G>>>С чего ты взял? A>>Например, в драйвере используется какая нибудь особенная комманда процессора, которая языком поддерживается не может. Следовательно в языке должен быть ассемблер. И как предлагается его верифицировать? G>Мда... G>Элементарно решается, все опасные вызовы упаковываются в библиотеки, а доступ к ним регулируется специальными правами. Даже сейчас так работает. G>Ассемблера в принципе не должно быть в управляемом коде, так как он должен абстрагировать от конкретной физической архитектуры.
Гы, ну я так и думал, что это будет предложено. Только вот проблема в том, на чем ты эти библиотеки напишешь? Тоже на управляемом коде?
A>>Таким образом получается, что во первых, высокоуровневый язык, если он содержит ассемблер, не получится верифицировать. А во вторых не получится написать драйвер на управляемом языке потому что он не будет содержать ассемблера, необходимого для драйверов. G>Применение С и ассемблера в особо впечатлительном возрасте видимо дает серьезный эффект.
Здравствуйте, Aleх, Вы писали:
A>Гы, ну я так и думал, что это будет предложено. Только вот проблема в том, на чем ты эти библиотеки напишешь? Тоже на управляемом коде?
Можно на управляемом коде, но тогда вопрос генерации нативного кода ложится на рантайм.
В любом случае часть кода рантайма будет нативной и верифицироваться будет только вручную.
Почитай про Singularity, много интересного узнаешь.
Здравствуйте, rfq, Вы писали:
rfq>Здравствуйте, batu, Вы писали:
B>>Первое впечатление, что декларируемая задача в императивной парадигме не решаема. rfq>... B>>Реально создать такую фишку в функциональной парадигме. rfq>Поддерживаю 100%.
Я не помню по какому поводу я писал. Здесь недавно и не знаю как восстановить последовательность сообщений. Спасибо за поддержку.
B>>Как быть с языками типа Си, джавы.. они ж императивные.. rfq>ПисАть на них чистые функции. Скажем, компилятор легко оформляется в виде функции текст->код.
"Чистые функции" отличаются из императивных только доступом к внешним объектам. У себя в языке я сделал оператор легализации "With". Синтаксис следующий
"With" Имя Путь_к_внешней переменной [Легализация].
Дальше, очевидно, имеем возможность анализировать. Кстати, этот оператор может использоваться просто для сокращения текста и с внутренними переменными. rfq>Конечно, мы не сможем сохранять промежуточное состояние в процессе компиляции (точнее сможем с большим трудом и негрантированым результатом — так что лучше и не пытаться). Но зачем, если компиляция одного текста длится миллисекунды, максимум — секунды. rfq>При перезапуске начнем снова. А утилиту make (или ant) — напишем заново. rfq>Собственно, этот пример не совсем удачный, так как связка make — компилятор и сейчас обеспечивает сохранение основного объема работы при сбоях. Но эта функциональность базируется на шатком основании — времени модификации файлов. Дело за тем, чтобы найти более прочный фундамент. Можно, например, оттолкнуться от баз данных и встроенных процедур.
Я предложил другой вариант. Создать такой формат, что и после трансляции сохранить прямую связь "оттранслированые объекты"-"Объекты текстовые программы". Если я правильно понял проблему. Вообще я против модификации файлов в результате трансляции. Есть вариант архитектуры машины с дополнительной адресной лентой. Тогда порядок физический размещения объектв остается неизменным, а выполнение происходит в порядке необходимом по результату трансялции. Там еще есть всякие подроности и их много.. Их так много.. что мою идею мало кто понял. Начиная с букв, групп, представлением объекта и т.д..
Здравствуйте, Mamut, Вы писали: M>Потому что 90% этого софта использует код, написаный как раз лет 10-15 тому назад, когда Java только появлялась. Legacy такой legacy.
О, так на твоем любимом айфоне уже появилась жава?
M>>Потому что 90% этого софта использует код, написаный как раз лет 10-15 тому назад, когда Java только появлялась. Legacy такой legacy. N_>О, так на твоем любимом айфоне уже появилась жава?
Здравствуйте, gandjustas, Вы писали:
G>Главное преимущество managed кода знаешь? G>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
А что именно значит "ничего криминального"? Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль? Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы? Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?
Возможности статической верификации настолько ничтожны, что я вообще с трудом представляю, от каких же вещей она способна защитить.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, gandjustas, Вы писали:
G>>Главное преимущество managed кода знаешь? G>>Это простая верифицируемость на клиенте. То есть непосредственно перед исполнением можно статически проверить что код не делает ничего криминального. Таким образом не нужны становятся аппаратные средства защиты, так как они рассчитаны на отлов тех же самых проблем, но в процессе исполнения.
DM>А что именно значит "ничего криминального"?
Я с теорией верифцирования не сильно знаком, но верификация и сейчас производится.
DM>Если программа делит единицу на миллиардный по счету бит числа пи, как верификатор поймет, что там деление на ноль?
Вряд ли, верификатор не будет арифметические ошибки ловить.
DM>Если идет обращение к массиву с нетривиально вычисляемым индексом, как верификатор угадает, нет ли выхода за пределы?
Это не верификатора работа, а реализации "массива", а верификатор удостоверится что реализация массива гарантирует что не будет обращения к памяти за пределами выделенной.
DM>Если идет загрузка модуля с вычисляемым именем и вызов функции из него, как статический верификатор узнает, что за функция будет вызвана?
А если не надо знать, ему достаточно знать что вызываемая функция тоже ничего "криминального" не делает.
DM>Возможности статической верификации настолько ничтожны, что я вообще с трудом представляю, от каких же вещей она способна защитить.
Это они в твоей голове ничтожны, а люди умудряются даже C_шый код верифицировать.
Смотри nativeclient и vcc.
Верификация не обязана проверять твою программу на соотвествие спецификации (у верификатора чато и нету спецификации), но верификатор может проверить программу на отсутствие нарушений памяти, обращений по невалидным указателям итп.
Причем если две программы гарантировано не будут обращаться к не своей памяти, то они вполне могут работать в одном адресном пространстве, без аппаратных средств защиты.
On 30/07/10 21:56, D. Mon wrote: > А что именно значит "ничего криминального"?
Если вспомнить, что такое защищённый режим процессора, то становится понятно.
В кратце: есть 2 набора инструкций процессора — защищённый набор и общий. В защищённый набор обычно входят всякие плохие вещи, типа управление портами, памятью, ресурсами и т.п., которые необходимы для работы компьютера, но должны строго контролироваться операционкой.
Зачем вообще этот защищённый режим? А чтобы обеспечить защиту, как ни странно. Т.е. обычные приложения запускаются в общем режиме. Если приложению требуется обращение к порту, то оно делает системный вызов, вызов функции операционной системы. А ОС уже может по всяким хитрым условиям проверить легальность вызова.
В итоге получается — можно загрузить произвольную последовательность байт в память и начать его выполнение. Всё нелегальное отлавливается аппаратной защитой CPU (проц тупо отказывается выполнять инструкцию, если её код из защищённого набора), и программно — системным API (операционка проверяет, что юзер правильный, есть права, и т.п.).
Притом, без аппаратной защиты такая схема работать не будет. Т.к. последовательность байт может содержать любую инструкцию процессора, или (в фон-неймовской архитектуре) сгенерить в процессе вычислений новый код и выполнить его. И нет даже теоретической возможности узнать, может ли данная последовательность байт в процессе выполнения сделать что-то плохое, например, обратиться к порту.
Так что же такое верифицируемый код. Это когда на выполнение берётся не произвольный набор байт, а программа на некоем низкоуровневом языке типа ассемблера. И этот язык спроектирован таким образом, что его очень легко проверить на наличие плохих вещей. Т.е. это избавляет от необходимости аппаратной защиты. Например, отсутствие адресной арифметики и указателей, даёт контроль над адресным пространством. Это избавляет от необходимости иметь аппаратную защиту. Загружаем байт-код, верифицируем, если всё ок — можно быть уверенным, что непра�
�ильных инструкций нет, никто в порт не залезет.
Вот примерно так, на пальцах.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Nik_1, Вы писали:
N_>Ещё один пример — когда лет десять назад появилась Java (как язык программирования), производительность программ на Java была катастрофически хуже, чем производительность программ на C++. Что не помешало Java "вынести" C++ просто с корнями. Можно считать, что C++ сейчас не существует, а Java сегодня — язык номер один. N_>[/q]
Вау, кул и всё такое. А потом просыпаешься и снова идешь программировать на C++ и C#
Перекуём баги на фичи!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
