Дмитрий Завалишин рассказал о себе, своих взглядах на софт и, конечно, об ОС «Фантом»

«Довольноблизкое» не внушает. По идее ...

Автор там привел пример с датчиками. А вот если датчик «отвалился» в тот промежуток времени между последним сохранением и перерывом питания. .. И такое там все :)

Товарищ похоже просто развлекается «интересными проектами». Интересные проекты можно мучать вечно, одновременно рассказывая про как эти проекты накормят голодающих африки.

Кстати если смотреть в историю ИТ, видно что ИТ подобным путем развития не пошло. Я даже могу сказать почему, наверное. Персистентные системы удобны классическим горе-программистам(которые не думают что пишут), но атская головная боль админам и инженерам-интеграторам. У обычной системы есть «изменение ПЗУ» и «изменения ОЗУ», и методики их создания и обслуживания заточены под то что бы «ошибки» могли накапливатся только в «ОЗУ», но не в «ПЗУ». При чем «данные для обработки» стараются помещать в «ПЗУ» только с условием сохранения целостности. Как бы выносят хаос в контролируемый угол где его выметают из избы во время разных видов ресетов.При чем перезапуск одной программы это как раз частичный ресет.

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

К стати «ремонт» телефонов перепрошивкой тоже показывает на каком уровне такие эксперименты.

>Только вот автор для решения этой фундаментальной проблемы ничего не предложил. Писать же программы качественней нам не светит.

К стати да - больше всего портят себе данные не враги вроде пропадания света а сами программы. А учитывая что он на этой задумке хочет «легкой передачи данных» - я себе представляю - видеопроигрыватель родил артефакт на экране - решается форматированием диска:)

видеопроигрыватель родил артефакт на экране - решается

форматированием диска:)

Именно. При чем с потерей всех данных при большом артефакте вообщето - что реально заставит благодарных пользователей суперОС посылать автору пожелания ненависти и убиства :) Так как при большом артефакте внутри, у админа-эксплутационщика будет только дамп памяти. При чем не дамп СПЕЦИАЛЬНО сильно упрощенной структуры типа файлухи, а дамп живой много-процессной системы с разбросанными по структуре несериализованными, читай экстремально-эбанитоформатными, данными :):):)

Что интересно патчи линуксядра с сохранением образов процессов гуляют уже давно. Причем как я понимаю этио же можно реализовать preload библиотекой, или линковкой с соотв библиотекой на стадии компиляции.
Но чего то массового внедрения не видно. Хотя в принципе не очень большими изменениями можно добиться того же эффекта персистентности для множества процессов ОС, даже на стандартном ядре. Даже применяют иногда - в кластерах для удобства откладывания задачи. (про сохранении VM целиком я даже не говорю)

> админа-эксплутационщика будет только дамп памяти. При чем не дамп СПЕЦИАЛЬНО сильно упрощенной структуры типа файлухи, а дамп живой много-процессной системы

Ну не считай его уж совсем идиотом... я где-то читал, что файлы тоже будут. Другое дело, что это нарушает концептуальную чистоту идеи, причем настолько, что сама идея становится лишней :)

Ну не считай его уж совсем идиотом... я где-то читал, что файлы тоже

Он из тех умников которые благодаря своему умищу могут совершать поступки настолько идиотские и настолько глобальные, что простому идиоту неразу недоступные :)

будут. Другое дело, что это нарушает концептуальную чистоту идеи,

причем настолько, что сама идея становится лишней :)

Ну на самом деле все еще веселей. Я сейчас подумал что практически все что он жаждет уже есть отдельными частями под линух, и собрать это все вместе дело в общем то пары-тройки тру олдовых одминов :):):)

То есть DMTCP+chroot(+SELinux/...)+какая нибудь grid FS + NX proxy(для ускорения сетевого графического коннекта) + автоинсталляция пакетов по потребности + некие патчи с парой мелких библиотек. Подозреваю что еще понадобится демон-версионник на базе (например)git между файлухой внизу и пользовательским представлением этой файлухи вверху. Так как нам будет нужна версионность снапшотов на grid-уровне. Естественно отладка :) Как только это заработает можно писать патчи к софту(и утилиты) на тему оптимизации размера перебрасывамого с хоста на хост образа программы ну и всякие еще трюки.

И мы имеем «фантомОС» только без извращений, сразу в распределеннной среде и при сохранении всего набора существующего софта. Линукс (как наследник юникса) рулит гораздо больше чем могут себе представить неосведомленные люди. :):):) При чем иметь это все внутри любого современно линукса как опцию логина без переинсталляции.

Просто возникает вопрос - а нафига :):):) И вот тут нас ждет засада :)

>К стати да - больше всего портят себе данные не враги вроде пропадания света а сами программы. А учитывая что он на этой задумке хочет «легкой передачи данных» - я себе представляю - видеопроигрыватель родил артефакт на экране - решается форматированием диска:)

В точку. Проблема с электропитанием явно надуманная и легко решается UPS'ом, а вот баги в программах - это штука неизбежная. А уж в неперегружаемых программах...

> Подозреваю что еще понадобится демон-версионник на базе (например)git между файлухой внизу и пользовательским представлением этой файлухи вверху.

есть решения и поизящней: http://en.wikipedia.org/wiki/Nilfs

хотя я не разбирался как там с подчисткой места под ненужные фрагменты

есть решения и поизящней: http://en.wikipedia.org/wiki/Nilfs

хотя я не разбирался как там с подчисткой места под ненужные

фрагменты

У гит огромный инструментарий уже есть. Уже именно версионность уже круто оттестирована. Уже есть синхронизация с удаленными узлами. И git работает с файлами уже. То есть например для написания доп.утилит мы мы можем работать прямо на уровые репозитория с работающим инстансом системы.
Править по горячему если что - дозаливать какие то куски, например, чтото архивировать и тп. И совмещать «online» версию с правленной корректными способами.

А в случае nilfs мы будем работать с подмонтированным блобом который черный ящик для всех кроме драйвера.

Нам нужно будет fuse с user level vfs и gitfs каким нибудь.

Грубо и коротко говоря это будет состояние группы процессов создаваемое DMTCP и хранимое в git.

Все остальное будет для того чтобы обеспечить работу этой идеи -
например патчи к приложениям, для повышения корректности работы stateful протоколов. Причем ИЧСХ, эти патчи серьезно повысят качество и безглючность работы программы вне этой системы. :) То есть все шансы на то что патчи уйдут в апстрим - а это признак того что идея глубоко правильная. :)

> У гит огромный инструментарий уже есть. Уже именно версионность уже круто оттестирована. Уже есть синхронизация с удаленными узлами. И git работает с файлами уже. То есть например для написания доп.утилит мы мы можем работать прямо на уровые репозитория с работающим инстансом системы.

Маниловщина заразна походу O_o

Маниловщина заразна походу O_o

:):):)

Почему маниловщина? Обычный исследовательский проект.:) Да и я написал что он мало кому нужен. Но тем не менее. :)

Я тебе даже скажу что он реально востребован в HPC. Собственно еще лет 5 назад народ на одном из кластерных сайтов в РФ внедрял подобную (крайне примитивную конечно систему), интересный был доклад. Для гридов и кластеров подобная штука в готовом виде весьма пользительна. DMTCP тот же для этого разрабатывают.

Собственно одна из основных потребностей это освобождать узлы под более приоритетные задачи. Очень врядли что тебе выделят например полгода(месяц) компутерного времени куском. А тут в любой момент на системном уровне сохранился - запустил приоритетное чтото, потом опять загрузил длинный счет. Вручную сохранялки в своей проге обычным ученым делать геморой, при чем даже если и сделал - админу нереально разобраться в куче написанных научниками программ.

> Собственно одна из основных потребностей это освобождать узлы под более приоритетные задачи. Очень врядли что тебе выделят например полгода(месяц) компутерного времени куском.

Я не об этом, а о хранении образов процессов в гипотетической fuse-gitfs. Не говоря уже о том, что git для этого не подходит, нафига? Главная операция VCS - это merge, а здесь он никаким боком.

> Я тебе даже скажу что он реально востребован в HPC.

а еще есть контейнеры openVZ — не знаю как они к hpc, но старт/стоп/ миграция вживую делаются почти идеально — миграция по сети приводит к задержке пинга от контейнера всего на несколько секунд, и нафига тут дополнительный огород городить?

Главная операция VCS - это merge, а здесь он никаким боком.

Если у тебя система распределенная - часть процессов на одной машине часть на другой, тогда у тебя они и сохранятся будут в разных местах. То есть типичная аздача распределеннгой VCS :)

> Если у тебя система распределенная - часть процессов на одной машине часть на другой, тогда у тебя они и сохранятся будут в разных местах. То есть типичная аздача распределеннгой VCS :)

Кхм... а версии где? %)

а еще есть контейнеры openVZ — не знаю как они к hpc,

Плохо они к HPC. Они вообще ко всему плохо кроме как к бабкам и к специализированным решениям для хостеров :) Это ограниченное решение для другой задачи и для определенной бизнес модели.

Именно по этому им попасть в ядро не светит, без смены парадигмы. Скорее всего аналог vserver/openvz будет постепенно реализован для ванильного ядра, с постепенной миграцией vserver на него. Заметный шаг в этом направлении - vnamespaces.

но старт/стоп/ миграция вживую делаются почти идеально

А так же это держат VM на базе qemu и vmware. Разницу между юзкейсом стопитсот процессов на стопитсот узлах, концепцией *распределенной* виртуального сервера и несколькими виртуальным серверами на одном хардварном понимаем?

Кстати системная изоляция и vserver/openvz/freebsd jail это как раз пример этой самой юниксовой магии.

миграция по сети приводит к задержке пинга от контейнера всего на

несколько секунд, и нафига тут дополнительный огород городить?

Когда научатся держать одну виртуалку на 500узлов при этом не конфликтуя с HPC патчами на ядро и дровами например к mirynet - приходи :)

И да , не городи, я тебе не предлагаю. Я рассматриваю гипотетический проект создания на базе линукс системы со схожими(и превосходящими) фантомос свойствами. Нужность подобной ОС, в том числе и фантомос это отдельная песня. Я в начале говорил что подобной системы нет именно потому что оно не нужно(массово). :)

PS
Они в ядре довольно большим куском, при чем не модулем а патчем.

Кхм... а версии где? %)

8) ???? Ты меня удивляешь.

Пример.
Процессы 1,2,3 сохранились в ревизию А на машине h1.
Процессы 4,5,6 сохранились в ревизию B на машине h2.
То же самое как если программисты правят общий репозиторий на разных машинах . Только вместо программистов живые группы процессов.

Нам же нужно, фактически, смержить А и Б в С, так что бы в С были процессы 1,2,3,4,5,6. Таким образом что бы ревизия С была корректным общим снапшотом системы. При чем смержить минимизировав обмен между h1 и h2. При том что хостов может быть (и будет) много. И при томчто смерживание снапшотов будети естественно отставать от реального состояния.

Учти еще что с точки зрения производительности тебе будет крайне неудобно скидывать все процессы из памяти одновременно. То есть будет куча технически некорректных версий состояния и хитрые алгоритмы создания «релтизных» :) снапшотов состояния :)

Я рассматриваю гипотетический проект создания на базе линукс системы со схожими(и превосходящими) фантомос свойствами. Нужность подобной ОС, в том числе и фантомос это отдельная песня. Я в начале говорил что подобной системы нет именно потому что оно не нужно(массово). :)

вот и разговор на тему не очень нужной вещи у меня как-то плохо идет :-)

меня разве что интересует попытка «сделать надежно» — типа вот есть фильм объект, и на уровне ОС дается гарантия, что к этому объекту приложимы определенные методы, например «отобразить в последовательность двумерных RGB-массивов одинаковой размерности»

дальше, пока этот объект где-то зарегистрирован и интерфейс Playable где-то зарегистрирован, ОС удерживает от деинсталляции декодер и как минимум один из плееров

в данном случае ОС!=ядро

> А так же это держат VM на базе qemu и vmware.

ну и что мешает засаспендить выч. процессы и скопировать образы со всех машинок в файл, а в будущем запустить обратный процесс?

т.е. нафига в случае hpc сохранять образ отдельного процесса, а не всей системы?

ну и что мешает засаспендить выч. процессы и скопировать образы со

всех машинок в файл, а в будущем запустить обратный процесс?

Примерно то же самое что сейчас полететь на луну. :) Вроде и желающих полно, и в принципе ничего непреодолимого ( доказано программой Аполлон). Но чегото никто не летает :)

Можешь начать с установки qemu/vmware/oppenvz на, например, упомянутый в соседней новости новый СКИФ :):):) Потом попробуй запустить стандартный расчетный софт под получившимся гибридом(тебя ждут множество интересных сюрпризов) :) Потом померяй производительность. Потом попробуй что нибудь сохранить и загрузить....

т.е. нафига в случае hpc сохранять образ отдельного процесса, а не всей системы?

Это гораздо проще в условиях HPC кластера. Ты забываешь что все приведенные решения вроде vmware/... вообщето спецом делают под хостеров и все глюки там более менее повыкорчесваны потому что хостеров реально много.
По этому комуто может показатся что openvz/миграция это же так просто ;):):)

вот и разговор на тему не очень нужной вещи у меня как-то плохо идет :-)

Не исследователь ты неизведанного... :)

меня разве что интересует попытка «сделать надежно» — типа вот есть

фильм объект, и на уровне ОС дается гарантия, что к этому объекту

приложимы определенные методы ...

И получится система в которой работает только то о чем подумал разработчик, особенно в твоем примере с объектом-фильм :) Анти-юникс.

Практика показывает что с одной стороны, непредусмотренные случаи способны жестоко поглумится на разрабами под систему настолько, что они будут искать разные методы все твои гарантии оторвать(ну и голову тебе оторвать мечтать будут :)). А с другой стороны, «предусмотреть все» это фантастика которая бродит в головах исключительно академических грантоосвоителей и наивных юношей с захованым мозгом.

Юникс как раз придумывали исходя из противоположного принципа. Честно признались себе что НЕВОЗМОЖНО предусмотреть что юзер захочет выделывать со своими объектами и в каких позах. Что НЕВОЗМОЖНО дать на уровне ОС гарантии кроме самых самых общих. Типа обеспечения многопользовательской и многозадачной среды для выполнения программы. И что неясно нифига какие юзер вообще может захотеть гарантии. Засунули свое ЧСВ в xxx кстате - не стали рассказывать всем как Вирт и прочие гуру что типа «они знают как Правильно». Почти все в юниксе на самом деле вытекает из концепции «самая простая многозадачная мнгопользовательская ОС».

И отсюда вытек и принцип KISS. Так как если все равно ОС гарантий не дает кроме общих и примитивных, и ничего не делает кроме базовых вещей - так и способы общения с ней получаются самые общие и примитивные. Самый простой файл, самый простой способ обмена командами/данными программы и ядра(сисколлы) и тп. И даже самые небольшие сложности - опционально. Так как мы НЕ ЗНАЕМ при чем ПРИНЦИПИАЛЬНО чего юзеру надо. Не нравится - выкинет и напишет сам. Отсюда в том числе вытекло что ОС писать не на ассемблере. Что бы эту не самую эффективную систему(не шла у них речь об «идеальной супер-системе») можно было взять, портировать на свой компутер и пропатчить фишками которые нужны конкретному инженеру. Если покопатся очень оказывается смешно ;) Что линукс это не клон юникса ;) Линукс это то, чем юникс хотел стать - но злобные копирасты не дали. То есть линукс это как бы истинный юникс :) более истинный чем сам юникс ;)

И все новые наработки кстате, исходили из того же. Каждую новую фишку старались сделать максимально опциональной. Чтобы если кому она не нужно - он ее оторвал. В результате это всегда были фактически «костыли» и хаки. То есть юникс и линукс это система целиком состоящая из идеально пригнанных костылей. :) Просто внезапно оказалось что подход звучащий как бред на самом деле был высшей мудростью мироздания :) Так как правильной название системы из «кучи хорошо пригнанных костылей» это система состоящая из кубиков :)

И сейчас например, любят говорить что С это такой переносимый ассемблер. Так вот, юникс это такая софтверная часть процессора, одинаковая для всех процов разных типов для удобства. То есть юникс говорит нам «ничего не знаю ни про какую ОС, вот вам универсальный процессор(точнее компутер), дальше еб%^ как хотите» :):):)

А вот в фантомосах всяких подход другой. «Я гуру и все будет вот так. Вес остальные падать передо мной ниц и молиццо111». А точнее «Я знаю как должна быть устроена ОС, ваши данные и ваша программа и вообще все.». Это все замечательно, пока слушающий такого автора ОС человек внезапно не понимает что гуру лжет и чудес не бывает. :):):):)

> Процессы 1,2,3 сохранились в ревизию А на машине h1.

Процессы 4,5,6 сохранились в ревизию B на машине h2.

Нам же нужно, фактически, смержить А и Б в С, так что бы в С были процессы 1,2,3,4,5,6.

Здесь нет версий. На управление версиями это похоже только тем, что ты почему-то решил использовать слово «мержить».

Вот если бы у процесс 1 у тебя был на нескольких узлах, и тебе надо было объединять несколько его образов в один - это было бы управление версиями. И git тебе почти никак не помог бы :)

То есть будет куча технически некорректных версий состояния и хитрые алгоритмы создания «релтизных» :) снапшотов состояния

Сходство с управлением версиями крайне отдаленное,

> Не исследователь ты неизведанного... :)

я не R, а скорее R&D — отсюда прагматизм :-)

1. Почти все в юниксе на самом деле вытекает из концепции «самая простая многозадачная мнгопользовательская ОС».

2. А вот в фантомосах всяких подход «Я знаю как должна быть устроена ОС, ваши данные и ваша программа и вообще все.»

И завалишин вероятно обломается, так как для 2 нужно даже не «все как в яве», а «все как в хаскеле».

Теперь по делу: нужно что-то среднее между 1 и 2. Т.е. идущая из 70-х динамическая типизация точно изжила себя в большом программировании.

В программировнии в 20 строк и в принципах взаимодействия с ОС она еще держится; этому есть объективные причины, но видимо надо ее потеснить.

С тем же примером про фильмы: допустим, я копирую у знакомого фильм, но у меня нет к нему кодека; строгая ОС должна не разрешить его вообще скопировать — но это конечно маразм; более реалистично наличие неких метаданных, которые позволяют сказать «вот на этой ФС есть такие-то фильмы с неразрешенными зависимостями»

еще лучше прямо пройтись по его примеру с фотошопом:

Очень простой пример - запуск Photoshop. Он запускается и начинает сканировать шрифты, плагины, цветовые профили и всё это дело инициализирует при каждом запуске. Почему? Потому что среда не персистентна, он не может просто запомнить указатель на какой-то объект и потом снова пользоваться. Объект может пропасть, не пропасть, его нужно загрузить обязательно. «Фантом» представляет собой среду, в которой «Фотошоп» мог бы один раз найдя шрифт, потом мгновенно запускаться и сразу начинать им пользоваться, имея непосредственный указатель на этот самый шрифт.

Cценарий:

1. В фотошопе создается объект (коллаж), юзающий предоплатный шрифт со строго ограничивающей его распостранение лицензией (например, разрешается распостранение только уже растеризованного шрифта высотой не больше 35 пикселов только в составе коллажа, а коллажей этих разрешается делать не более ххх штук в месяц).

2. Объект копируется на другую фантомОС приятелю, у которого шрифта нет

Варианты:

А. поступиться принципами — у приятеля указатель на шрифт станет недействительным

В. совершить преступление — скопировать еще и шрифт

С. совершить маразм — отказать в копировании

Приятель, вполне возможно, сам *потом* докупит этот шрифт, или даже поставит бесплатно его ухудшенный бесплатный вариант (допустим, без хинтинга)

Вот если бы у процесс 1 у тебя был на нескольких узлах, и тебе надо

было объединять несколько его образов в один - это было бы управление

версиями.

Во первых если процесс 1 в стадии миграции он уже одновременно на узле 1 и на узле 2, в некотором смысле :):):) Как только ты захочешь чтобы миграция по относительно медленным каналам шла более-менее удобно(без дерганий) для пользователя, у тебя состояние «процесс 1 на обоих узлах» будет достаточно длительным и штатным.

Процессы с разных систем *взаимодействуют* в том числе через файлы. Для того что бы восстановить глде-то корректное состояние системы тебе нужна инфа не только о процессе 1 но и о процессе 2 с другого хоста, прото потому что ты не восстановишь канал их соединяющий без корректного описания их связи.

А на системе из кучи узлов с разными каналами как ты себе представляешь корректное сохранение - одновременно все процессы останавливать? В более менее реально реализации каждый процесс и его метаинформация вроде того как он коннектится к СУБД например, будет сохранятся в разное время, инкрементно и на разных хостах. А еще она иногда может пропадать. :)
Скажи мне, как такую информацию проще всего хранить? Свой формат выдумывать? А он не будет VCS на самом деле? :):):)

Или вот пример - есть огромный процесс, Опенофис чтобы конкретно :). У него часто изменяется некая область памяти. Это значит что если такой процесс куда переносить, лучше сначала перекинуть редкозменяемые куски, а потом застопать процесс и перекинуть частоизменяемый кусок.

То есть у тебя есть ревизия 1 :) которая будет синхронизироватся в бекграунде и ревизия 2, которая будет синхронизироватся при останов леном процессе, ли просто для апдейта состояния на другой машине. Естественно это нужно будет делать «патчем» что не не перегружать канал.

И git тебе почти никак не помог бы :)

Гит мне нужен только как готовый способ, отлаженный и документированный, чтобы работать с кучей файлов(и файлов дампов памяти) разных версий который будут создавать разные демоны-сохранятели состояния.

Что бы, если я знаю, что в ревизии 1, 2 и 3 нужно взять такой то список файлов(включая описание соединений из разных ревизий) чтобы сформировать корректную ревизию 4, то можно было просто использовать утилиты git. А не писать сначала свою хранилку со своим форматом, а потом утилиты работы с ней.

То есть будет куча технически некорректных версий состояния и хитрые алгоритмы создания «релтизных» :) снапшотов состояния

Сходство с управлением версиями крайне отдаленное,

Я понимаю что тебе хочется поспорить ;) но я над такими штуками на самом деле давно думаю :) Как только ты попробуешь реализовать поставленную мной задачу, ты сам напишешь VCS делая вид что это не VCS :).

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

> строгая ОС должна не разрешить его вообще скопировать — но это конечно маразм; более реалистично наличие неких метаданных, которые позволяют сказать «вот на этой ФС есть такие-то фильмы с неразрешенными зависимостями»

А чем отличается такой фильм от обычного пакета с зависимостями? Поставил кино - доустановил кодек, можешь с ключиками --no-deps && --force

Скопировать и шрифт, ибо система неподдерживает копирастинг :]

> Скопировать и шрифт, ибо система неподдерживает копирастинг :]

взрослые дяди такое юзать не будут

И завалишин вероятно обломается, так как для 2 нужно даже не «все как

в яве», а «все как в хаскеле».

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

И как только я слышу «как в хаскеле» на уровне ОС, я хватаюсь за пистолет :)

Теперь по делу: нужно что-то среднее между 1 и 2. Т.е. идущая из

70-х динамическая типизация точно изжила себя в большом

программировании.

Не нужно чтото среднее! Каждый проект сам пусть решает на чем ему там писать и как сношатся со своей типизацией :)

Пока я вижу что всю эту типизацию аля хацкелл и прочий ФП любят люди просто определенного склада ума. Плохо то что они считают свой склад ума единственно правильным, а всех остальных расово генетрически неполноценными, при том что реально людей с таким складом ума даже среди программеров единицы. :)

То есть «динамическая типизация точно изжила себя в большом программировании» это модный фанатский лозунг. Может быть обоснованный, но я в этом сомневаюсь.

В программировнии в 20 строк и в принципах взаимодействия с ОС она

еще держится; этому есть объективные причины, но видимо надо ее

потеснить.

Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор».
Вот такие люди пока защищают идею типизации :) Вы с ними ? ;) Ну это, я за вас рад :)

С тем же примером про фильмы: допустим, я копирую у знакомого фильм, но у меня нет к нему кодека; строгая ОС должна не разрешить его вообще скопировать — но это конечно маразм; более реалистично наличие неких метаданных, которые позволяют сказать «вот на этой ФС есть такие-то фильмы с неразрешенными зависимостями»

> Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор». Вот такие люди пока защищают идею типизации :) Вы с ними ? ;) Ну это, я за вас рад :)

и вот тут тебя понесло по кочкам в полный бред

посмотри хотя бы мои посты в темах про хаскель (хинт: там полно стеба над ним), да и тут я предлагал динамическую типизацию всего лишь потеснить.

и вот тут тебя понесло по кочкам в полный бред

Я предупредил когда я хватаюсь за пистолет :)

посмотри хотя бы мои посты в темах про хаскель (хинт: там полно стеба

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

Я считаю что на уровне ОС ее точно теснить совершенно незачем. Просто потому что ОС «не знает» ничего про программы кроме самых общих вещей. И не должна знать - так как это все ужасно усложняет.

Конечно есть специальные применения и отдельные механизмы. Вот на уровне отдельных отрываемых механизмов - это и сейчас делают в той или иной форме.

И какие будут твои конкрентные предложения? Что бы ты хотел типизировать нединамически?

2. Объект копируется на другую фантомОС приятелю, у которого шрифта нет

ИЧСХ Завалишин-like подходы были весьма модны до распостранения сетей и до распостранения необходимости передавать файлы на компутер друга с *другой* ОС.

Собственно как только вся эта типизация выходит из 100% контролируемой среды - например из процесса в памяти, оно все тут же идет лесом.По этому появляются попытки распостранить тотальный контроль сначала на ОС и другие программы, а потом и на всю сеть. В том числе в виде «все БУДЕТ процессом в пямяти» :)

Классическая мегаломания между прочим - подчинить всех что бы они не мешали своим не укладывающимся в схему поведением. ;):):)

> Я считаю что на уровне ОС ее точно теснить совершенно незачем. Просто потому что ОС «не знает» ничего про программы кроме самых общих вещей. И не должна знать - так как это все ужасно усложняет.

Если ты посмотришь мои посты, увидишь, что я либо писал «ОС!=ядро», либо обтекаемо говорил «на уровне взаимодействия с ОС»

мне это интересно обдумать скорее ради контраста с типизацией в программах (там совсем другая картина), хотя...

что мне *возможно* хочется от ядра и железа — это единое адресное пространство, допустим через метод типа NaCl и железные команды верификации любого джампа и ретурна на адрес, кратный 16

Конечно есть специальные применения и отдельные механизмы. Вот на уровне отдельных отрываемых механизмов - это и сейчас делают в той или иной форме.

И какие будут твои конкрентные предложения? Что бы ты хотел типизировать нединамически?

это уже завтра, щас я торможу

* единое адресное пространство всех процессов

> Собственно как только вся эта типизация выходит из 100% контролируемой среды - например из процесса в памяти, оно все тут же идет лесом.По этому появляются попытки распостранить тотальный контроль сначала на ОС и другие программы, а потом и на всю сеть. В том числе в виде «все БУДЕТ процессом в пямяти» :)

да, проблема в том, что внешняя среда не персистентна в принципе :-)

но подход managed-объектов можно ослабить и в этом виде попытаться реанимировать — реализовать что-то типа исчисления «насколько объект полон»

> взрослые дяди такое юзать не будут

VHS убьет киноиндустрию (ц)

>Может быть обоснованный, но я в этом сомневаюсь.

Не обоснованный. Просто ее готовить тоже почти никто не умеет. «Доказано библиотеками руби».

>> единое адресное пространство всех процессов

утопия

> Пока я вижу что есть группа безумны фанатов на лоре, у которых разве что пена изо рта не течет ;), которые кричат «хацкелл - будущие111», «а когда наши танки войдут в город, все будет на хацкеле а всех несогласных в биореактор».

<flame> Нет! Dependent types и Agda2 - будущее!!! А всякие статически недотипизированные Хаскеллы годятся только для прототипирования и мелких проектов. </flame>

>> единое адресное пространство всех процессов

утопия

объясни почему (и да, у меня сомнения в том, что ты меня полностью прочитал)

А всякие статически недотипизированные Хаскеллы

мы вообще-то говорим об ОС; завалишин, при том, что он четко не описывает идею, попытался, дать программе больше гарантий относительно окружения — что фактически означает какую-то статическую типизацию

понятно, что дать безусловные гарантии (как он пиарит это в статье) можно только с помощью такой строгости, что это будет маразмом; но можно попытаться спасти подход, рассмотрев типизацию в духе «если... то...» ________________________________________________________________

а хаскель действительно недотипизированный — попробуй описать на нем тип фильма Film:

существуют такие натуральные и неизвестные во время компиляции m,n (это размеры кадра), что Film является последовательностью из двумерных массивов размерности m,n

на с++ есть хорошее приближение:

template<const int& m, const int& n> class Frame {
    /// тут обертка над std::vector для организации двумерного массива
}

template<const int& m, const int& n> struct Film {
    std::vector< Frame<m,n> > value;
}

> мы вообще-то говорим об ОС; завалишин, при том, что он четко не описывает идею, попытался, дать программе больше гарантий относительно окружения — что фактически означает какую-то статическую типизацию

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

на с++ есть хорошее приближение

Помню, обсуждали это уже на ЛОРе, причём ты и начал.

Прикольная фишка, но это нифига не зависимые типы, так что С++ по сравнению с Agda тоже недотипизированный.

возможно фильмы лучше непонятного рядовому прогеру скалярного произведения

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

я тоже

но это нифига не зависимые типы, так что С++ по сравнению с Agda тоже недотипизированный.

а по длине кода (включая сюда длину кода верифицируемого ЯП) и по возможностям?

что бы ты такое предложил сделать, что на агде пишется легко, а на с++ заставит попотеть?

Сомневаюсь, что люди, для которых Жаба - венец творения, могут создать что-то путное.

блин копирайт на афоризму оформляй!!!!!! вещь сказал!!!