0,0
рейтинг
25 апреля 2011 в 12:58

Стенограмма доклада про Фантом-ОС, сделанного Дмитрием Завалишиным на ADD-2010

Аннотация


Дмитрий Завалишин рассказал о текущем состоянии в разработке своего любимого детища — оригинальной операционной системы PhantomOS, близкой по концепции Microsoft Singularity, но при этом open-source (опубликована большая часть исходных кодов этой операционной системы).

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

Видео


Видео в HD-качестве, смотрите в полноэкранном режиме.

Скачать видео

Подкаст


Ссылка на подкаст.

Стенограмма

Стенограмму по видеозаписи записал Стас Фомин.

Как сделать так, чтобы реально было хорошо? В том смысле, что все существующее на сегодня программное обеспечение делается по принципу «Давайте возьмем то, что было, ну и как-то это все подточим, улучшим, подвинем здесь, подправим тут», и в итоге, все что у нас есть на сегодня, это legacy-legacy-legacy, какое-то старье, которое развивалось, развивалось, развивалось, и в итоге, оно все такими наслоениями, и очень сложная и тяжелая…

Я вот пользуюсь компьютерами двадцать пять лет, вы знаете, они с тех пор, в тех с которых я начинал, в них было две дискетки по 160Кб, и 48Кб оперативной памяти. Так вот, вы знаете, оно загружалось быстрее, чем то, что у меня сейчас есть, а функционально я примерно тоже самое с ней и делаю, я программы пишу на ней, редактирую какие-то тексты, и электронную почту читаю. А при этом процессор и память изменились, господи боже… я даже подсчитать-то не могу… Пять порядков, шесть порядков — куда все это проваливается? Это проваливается ровно туда, весь софт, который сегодня сделан, он сделан по принципу исторического развития, чего-то такого старого, страшного и несчастного.

«Фантом» родился по-принципу — давайте подумаем, о том, что оно было, и давайте, попробуем, сделаем с нуля, не возьмем ядро Линукса, не будем брать Яву, при всей моей любви к ней, не будем развивать существующее, стартанем с чистого листа.

Есть некоторое количество мыслей, которые лежали в основе этой самой идеи, лежали такие, например, задачи. Я рассматривал современное программное обеспечение, которое все мы с вами разрабатываем.

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

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

Как родилась операционка? Когда-то давно люди брали компьютер целиком, брали одну свою программу, и запускали. Потом выяснилось, что писать в каждой программе драйвер принтера геморройно, надо взять его сразу готовый, откуда-нибудь.

Появились библиотеки. Потом эти библиотеки превратились в ядро, которое уже запускает прикладную программу. Итак все постепенно, постепенно все и стало нарастать, в конце концов появился Юникс. Юникс, на сегодня — операционка, которая явно победила, даже Винды сделаны по образу и подобию Юникса, концепт, на котором он основан, явно является доминирующим.

Интересно, что когда Юникс появлялся, а я достаточно старый, чтобы помнить эти времена, Юникс, как операционная система, был очень странный, и сильно уступал всем существующим операционкам. Была там машина, на которой мы работали, которая называлается PDP-11 (СМ-1600), на ней была родная операционка, и был Юникс. Родная операционка работала в разы быстрей Юникса. И тем не менее, она сегодня сдохла, а Юникс существует!

Почему? Потому что Юникс совершил очень правильный шаг. Люди которые его делали, они породили очень простую идею, таких вот маленьких программ, которые обрабатывают текстовые файлы фиксированным способом, и возможности собирать все эти программы на ходу, через пайпы, или через файлы, неважно, в какие-то цепочки.

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

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

В принципе, в основе Фантома лежала довольно банальная мысль, которая начала зарождаться в районе девяностых годов. Когда появился язык C++, который появился в 1987 что-ли году, все зафанатели с объектного программирования, и возникла мысль, типа «Ну а что? Язык-то объектный, почему операционка то планарная? Надо бы и ее сделать объектной». Причем, это вообще говоря, довольно такая практичная мысль, которая не из каких-то метаний или идеализма проистекает, она проистекает из того, что реально иметь объектный интерфейс это совсем удобно. Если посмотреть на сегодняшнюю ситуацию, это очевидно так. Тот же самый C#, та же самая Ява, вполне себе оборачивают операционные системы в объектные обертки, это удобно.

Хорошо. Следующий шаг. Довольно понятно, что мы хотим, чтобы программы коммуницировали. Причем вот интересно, что … вот что я забыл сказать на этом разговоре про яву и C#, про то, что в C#, ну и вообще в виндах есть OLE. Это реально… при всей, извините, ублюдочности этого инструмента, лучше пока к сожалению нет. И этот инструмент реально решает совершенно осмысленную задачу.

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

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

Здорово, да?

Я как-то вот, в один из первых разов, когда я рассказывал про Фантом, там был большой зал, там было человек двести программистов — «Кто знает, что такое OLE?». И рук тридцать поднялось. Я спрашиваю — «А сколько на нем программируют? Реально сделали OLEшный инструмент какой-нибудь?». И такие вот, неуверенные три человека вот, причем видно, что два из них компильнули «Hello World», примерно, а третий что-то реально прорубил и сделал[1].

Почему? — Очень тяжело. Очень-очень-очень тяжело.

Вот даже если не брать OLE, брать только другие инструменты, если два процесса на одной машине или на разных машинах, возможность их реально связать по данным очень… с этим плохо.

Причем — в чем еще беда? Нормальное, естественное представление своих потрохов для программы, это граф объектов. То есть программа обычно работает с графом связных объектов, а единственный способ, которые реально работает на interprocess communication, это pipe. То есть дырочка, в которую можно байтик просунуть. То есть граф документов не пролезает никак, его можно сериализовать, но в этом случает, он оторвется от того, что у вас было, то есть его можно будет только скопировать в ту сторону. А дать куда-то реально, такой вот инструмент, чтобы можно было поработать вместе над общими данными, … ну OLE это как-то позволяет, но опять очень сложно. Но при этом, достаточно очевидно, что это ценная возможность. Почему это сложно? Потому, что много лет назад, какой-то умный человек, сказал, что операционная система, это ядро, которое запускает процессы. Процессы эти работают в отдельных адресных пространствах. И с тех пор, за ним, эту гениальную мысль постоянно повторяют. В то время, как на самом деле для managed-языков, которыми и Ява и C# являются, и вообще, все, что сейчас делается, это managed-языки, … вообще говоря, отдельные адресные пространства не нужны, потому что сами по себе managed языки — они хорошо управляют памятью, у них нет сишных проблем с убежавшим указателем, с порчей чужих данных.

Поэтому если перейти, сделать шаг к managed языкам, можно отказаться, от адресных пространств на уровне операционной системы. А дальше мысль пошла таким образом — ну хорошо, мы с вами взяли, написали, … (смотрит на экран) это Фантом там работает …
Грузится?
Нет, он уже загрузился, это он трудится.

Мы с вами взяли две программы, запустили их, и они — подружились. Одна другой какой-то поинтер послала, поскольку у нас общее адресное пространство, очень просто коммуницировать. Поинтер кинул, поменялся, за него можно дернуть, что-то забрать, что-то передать, чужие данные становятся как свои, буквально. Очень дешевые IPC. Только одна беда, вот вы вот эту программу остановили, и Pointer куда смотрит? Вроде как в никуда. Перезапустили, и даже если у вас pointer смотрит на старые данные, эта программа у вас снова запущена, данные в другом месте, связь прервалась. Я вот каждый раз, когда это рассказываю, привожу один пример. Вы когда запускаете Фотошоп, все запускали Фотошоп, там такое окошечко вылезает, начинает там бежать такая строчка — вот он вот это грузит, потом вот сюда потянулся, потом здесь что-то нашел такое, … и он делает это каждый раз.

Какого черта! Почему он не может найти это один раз, и запомнить Pointer? Потому, что операционные системы, которые сегодня существуют, они не позволяют вам каким-то образом оставить в памяти то, что один раз туда погрузили. Вы вынуждены закрывать приложение, а когда вы закрываете приложение, вся память теряется. Значит вы не можете их связать нормальным образом, только через файлы, только через странные, очень сложные вещи, которые сложно и медленно работают. Можно ли сделать так, чтобы программа не останавливалась? Да вообще-то можно. Вообще-то программа живет внутри операционной системы, и вполне может сделать вид, что операционная система живет вечно. Даже если вы ее перезагрузили и запустили снова, совершенно необязательно об этом говорить программе. Это вообще даже в Линуксе не обязательно.

Что из этого можно получить? Получить из этого можно много. Как только мне эта мысль пришла в голову, я сразу подумал, — хорошо, здорово, если так сделать, то есть программу запустил один раз, и потом она всю жизнь работает как бы, висит в памяти, и живет там.

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

Недавно пришел в голову пример: есть такие программы, которыми пользуются музыканты, называются секвенсоры. Вот все эти программы работают с двумя типами файлов — один тип свой, личный, в котором они хранят свое состояние полностью, это обычно некоторый proprietary формат, который обычно никому не известен. А второй — это какой-нибудь там «.midi». Файл, в который можно что-то записать, чтобы потом куда-нибудь можно было передать, в другую программу — это exchange format. Так вот, первого формата, в этом случае можно вообще не делать. Программа запустилась, построила свое состояние в памяти. Машинку выключили, при выключении машинка, как какбы это делается в Hibernate все это сохранила, вы включили — програмки все очнулись, как будто ничего не происходило. То есть они спокойно могут оставаться в этом состоянии, вы свою работу не потеряете, вы можете эту программу как угодно связывать, связность эта получается очень дешевой и эффективной.

Еще некоторые смешные вещи вылезают. Ну например, жизнь всех программ в одном адресном пространстве означает, что тут довольно эффективный ввод-вывод, потому что нет переключения контекстов, как это происходит сейчас, в ядре операционной системы. Из-за того, что контексты переключаются, и память программы может быть paged out, в нее нельзя делать напрямую нельзя делать напрямую ввод-вывод, его можно делать в буфер отдельно. Ну короче, есть некоторые заморочки. В этом случае, можно этого избежать. Почему этого нельзя было сделать давно? Потому, что для того, чтобы делать такие вещи, нужно иметь машины с очень большим виртуальным адресным пространством, в 32 битах Фантом не имеет большого смысла, то есть имеет, но понятно, что 32 бита, это пространство, в которое должен вписываться весь диск, а это не очень много, это всего-лишь четыре гигабайта, а дальше не влезает. Поэтому собственно, по большому счету, Фантом, как идея, ориентирован на машины 64 битные, а если 32 бита, то это видимо, телефон, или что-то простенькое, небольшое.

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

Первый путь, это нативные правила. У системы Фантом существует свой собственный байт-код, интерпретатор, который строит обьектную модель, аналогично явской и C#, под нее есть компилятор собственного языка, и в нее пишутся трансляторы из байт-кода Явы и C#. То есть теория гласит, что там Явский и C#-ный код, а также весь код, которыый написан на языках, которые компилируются в JVM и CLR, можно будет в Фантом затащить. Причем среда для него будет очень естественная, натуральная и весь этот код может взаимодействовать дешевыми способами через вот такую вот схему обмена поинтерами.

Вторая среда, которая изначально не планировалась, однако походу возникла мысль, что наверное нужно, это среда, такой POSIX-compatible, типа UNIX внутри Фантома, который мы планируем сделать в двух вариациях, одна вариация простая и элементарная. Просто запуск юниксовых приложений, скомпилированных под Фантом. То есть POSIX-среда, обычная-обычная POSIX-среда.

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

Ну и естественно, какой-то interchange между ними, который планируется сделать тоже очень интересным способом. Понятно, что современная операционная система не может не быть микроядерной, естественно, что втаскивать все в ядро может быть несерьезно, понятно, что микроядерность это в первую очередь средство коммуникации между компонентами, в том числе, ядром, драйверами и приложениями. Для этого существуют механизмы ядерного message passing'a, и выяснилось, я поисследовал этот вопрос… Вот если кто знает, была такая система операционная, называлась она BeOS. Довольно давно, французы, ушедшие из компании Apple, сделали платформу, такую вот довольно интересную, сделали для нее операционную систему, она не очень пошла, хотя где-то применялась, компания развалилась, а операционка перешла в open-source, и ее с тех пор пару раз реализовали, и сейчас она существуюет под именем Haiku.

Вот в ней, довольно такой приличный механизм, message passing'a существует, и мы собственно посмотрели на его и в Фантом его перетащили. То есть он рассматривается, как инструмент для расширения ядра компонентами, во-вторых, для взаимодействия между Си-шным кодом, и объектным кодом, потому что понятно, что message passing очень хорошо втыкается с любой стороны.

Вот. Я тут ничего не вижу, что там на экране, думаю, что вы тоже ничего не видите[2]
Все грузится?
Нет, дело вот в чем, я поясню, то, что я вам притащил, вот это ядро, это ядро, которое непосредственно вытащено из процесса разработки, ничего с ним специального не делал, а реальное, живое, разработческое ядро в него вставлено много разных проверок, затычек, и чекпоинтов, для того, чтобы в процессе разработки сразу видеть, что что-нибудь сломалось.

Но некоторые вещи делаются существенно дольше, чем должны.

Собственно, как работает ядро Фантом. Оно, в отличие от… По-простому, если вы знаете, что такое paging в Unixе, то Фантом, это операционная система, у которой консистентный пейджинг, то есть pagefile, в который сохраняется состояние виртуального адресного пространства, он при рестарте не теряется, а правильным образом, структуризуется, и при рестарте система поднимает из него все свое состояние. То есть когда она просто работает, она ничего существенно не записывает, кроме обычного пейджинга. Когда она завершается, делается снепшот, который фиксирует состояние системы, полноценное, с него же она потом и стартует, практически полностью восстанавливает свое состояние.

Тут есть два момента. Собственно очень часто спрашивают, чем это отличается от Hibernate, это отличается от hibernate тем, что hibernate нужно явно сделать, иначе вы все потеряли, а фантомовская структура памяти, она так устроена, что он время от времени сам делает снепшоты, прозрачно для вас, и достаточно безболезненно. И в принципе, если вы его просто выключите из розетки, то он после этого, при включении, снова поднимется со старым состоянием, но с каким-то отставанием, на сколько-там минут назад, секунд… зависит от многих вещей. Так вот, время snapshotа у Фантома, оно во-первых сильно отличается для первого запуска системы, и для последующих.

Если вы вообще систему, только-только, с нуля проинсталлировали, дальше ей нужно очень многое положить в snapshot, потому что у нее все новое. Если система проработала… хотя бы один snapshot сделала, то после этого у нее модификаций не очень много, и следующие snapshotы происходят очень быстро. И если убрать все наши проверки и assertы, то это наверное секунд пять происходит. Но текущее ядро, которое я вам показываю, в нем все эти проверки есть, во вторых, оно сейчас запущено так, как будто оно только что родилось, после инсталляции, соответственно снепшот занимает довольно долгое время, потому что после того, как сделан снепшот, мы его еще проверяем на консистентность, чтобы убедится в том, что система снепшотов… о умолкла, отлично … у нас будет честный эксперимент, виртуальная машина, в которой работает Фантом, почему-то решила сломаться.

Соответственно, будем считать, что его выдернули из розетки совершенно неожиданно. Сейчас она доломается, Виндовс очень задумчивая штука, она почему-то не хочет сразу это убить, вот. В чем еще одна ценность такой структуры? Дело в том, что Фантом очень быстро стартует, … что такое поднятие снепшота? Это означает, что загрузилось ядро, а ядро очень маленькое, после чего ядро нашло карту расположения памяти на диске, подняло ее в память и запустилось дальше. Все остальные обращения к диску происходят в рамках обычных pagefaults, которые вызваны обращениями к памяти, которая еще не загрузилась. Почему это важно? Потому, что современные компьютеры постоянно мигрируют мз десктопного вида ноутбуков, в какие-то встроенные приложения. В моем телевизоре есть Linux, например. Причем этот Линукс, почему-то, стартует восемь секунд, меня это жутко совершенно раздражает.

В автомобилях современных применяются компьютеры, и даже если это Линукс… если Винды, то это вообще конечно беда, очень долго поднимается. Даже если это Линукс, даже если он очень компактный, он все равно довольно долго запускается. Реально, потребность такая есть. Нужна система, которая, во-первых, быстро запускается, и которая не предъявляет претензий в плане shutdown-а. Вышел из машины, ключи так чик — зажигание выключил, положил в карман, ушел. Систему убили. Включили — система должна заработать там же, где была, потому что вы что-то с ней делали, карту там смотрели, что-то такое, какие-то операции происходили. Разумно, чтобы каждая операция была в том же состоянии, в котором вы ее и оставили. Если говорить там про какие-то серверные системы, для медицины например, вот мой любимый пример — системы искусственного дыхания — прошла уборщица, дернула за вилочку, включила обратно, а он говорит — «а я сейчас диски почекаю…, что-то там загружу, что-то еще поделаю». Человек глядишь, там уже и не дождался. Соответственно в эту область мы еще как-то стараемся попасть, я считаю, что это довольно хорошая задача для нас.

Так, винды согласились с тем, что приложение надо убить, сейчас попробуем. Вот в теории, он сейчас должен поднятся с того же состояния, в котором он был в момент, когда упал, это можно определить вот по чему. Там будет такое белое окошечко с циферками, если циферки там будут начинатся не с единички, … значит.… о, о, о…
Какая виртуальная машина?
Это TPL. Понятно, это белое окно, это собственно Фантомовское приложение, оно очень простое, там три строки у меня, там примерно
i = i + 1
print i
Но смысл в том, что по его состоянию видно, насколько … какое состояние было поднято системой. После перезагрузок видно, что она свое состояние сохраняет, и восстанавливает, … Какая? А виртуальная машина — я ответил.

Вот. В каком состоянии проект примерно? Мы этим занимаемся около двух лет, ну я не считаю, там годы раздумий, и метаний, в течении которых писались куски кода экспериментальные, которые сегодня уже все либо переписаны, либо по другой причине выкинуты из проекта. Около двух лет. Примерно год заняла реализация proof of concept, в которой я очень активно использовал внешний код, ну грубо говоря, собрал из интернета все, что подходит из стандартного колла, типа управления процессором, managementa памяти, то, что не является специфичным для Фантома, все было использовано стандартное. И поверх этого была написана операционная система, которая реализует основные идеи.

Когда мне стало понятно, что она написана, существует, работает, снепшоты отрабатывают и восстанавливаются, была поставлена задача очистить все этот от кода, который лицензии нашей не соответствует. На сегодня задача была выйти в LGPL, и примерно полгода потребовалось на то, чтобы весь чужой, GPLный и какой-то еще код со странными лицензиями, переписать, заменить на свой. И на сегодня, ядро, кроме стека TCP/IP, который взят целиком, из другой системы под нормальной лицензией, все остальные системы написаны с нуля. Сам стек TCP/IP доведен до какого-то внятного уровня, вот есть там графические драйверы, есть базовые драйверы для стандартных, наиболее популярных десять лет назад сетевых карт, типа там NE2000, или известные RTLки.

Тесты на снепшоты, разработка ядра, вообще-говоря, это все надо постоянно тестировать, мы сделали test-suite, который практически каждый build прогоняется, на предмет регресса.

Сделан компилятор собственного языка, по совпадению, тоже называется Фантом, и сейчас в работе такие вещи. Как-то долизывается ядро, хотя в целом, оно по большей части готово, и идет работа над транслятором из байт-кода Java в Фантом. Меня часто спрашивают, почему у Фантома свой байт-код, почему не взяли явский, есть масса причин, одна из них заключается в том, что фантомовский байт-код, как бы это правильно сказать, по-научному… но в Яве существуют нативные типы типа int, float, такие вот, контентные как бы типы, а в Фантоме их нет, там все объекты, совсем-совсем-совсем.

В принципе, можно от int-а наследоваться, и сделать… развить интерфейсы inta, хотя и непонятно зачем, но можно. Это было сделано в частности, в силу того, что под виртуальной машиной Фантома хотелось абсолютной надежности. Почему? Потому что Явская виртуальная машина, она по большому счету … явская, сишарпная, непринципиально, она работает в отдельном процессе, и это личная проблема этого отдельного процесса.

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

К примеру, обычная виртуальная машина, стековая, это просто стек, на котором работают все вызываемые функции. То есть вызвали следующую функцию — она в том же самом стеке работает.

В Фантоме не так, в Фантоме каждая отдельная функция, создает под себя отдельный стек, и в нем она живет. Почему? Потому что вы можете позвать метод чужого класса, и если он ошибается, что-то напортит со стеком, то это он вам испортит. То есть это будет порча между разными юзерами. Вот этого мы не хотели допустить, поэтому там все очень-очень-очень жестко разграничено, и сам по себе этот код, в виртуальной машине, он менее эффективен, чем явский, зато он очень строгий. Кроме того, я не знаю, правильно ли было это решение или нет, может мы от этого откажемся, Явская виртуальная машина она же как сделана? У нее есть фаза верификации байт-кода и фаза исполнения. Байт код загружают, она его просматривает — «так можно, так можно, так можно… а так нельзя — не будут запускать». Или «можно-можно-можно-можно, все хорошо, запускать буду». В процессе работы это все не проверяется. В Фантоме сделано по другому, в нем нет верификации вообще, но в процессе работы байт-кода проверяется все. Попытка выйти за границы массива, попытка выйти за размеры стека, все-все-все, все это проверяется на ходу. Это очевидно влияет на эффективность, и довольно заметно. Впрочем, может не надо этим сейчас заниматься, потому что в любом случае мы будем делать shipment, он сейчас в работе, понятно, что многие верификации, которые сейчас делаются в run-time, в процессе JIT-компиляции они будут сделаны статически, наверное всем это не поможет, но вот, это одна из таких архитектурных проблем, которых надо еще продумывать.

Еще одна проблема, огромнейшая, проблема, от которой я жутко страдал, потому что система была по большому счету написана, а проблема осозналась, когда система уже по большому счету работала, это вопрос garbage collection-а.

Первые полгода или даже год система работала без garbage collection-а, тратилось-тратилось-тратилось, а потом все падало. А начав делать garbage collection, я осознал неприятную вещь.

Нормальный Фантом, вот нормальный, который будет на 64 битных машинах, он будет оперировать адресным пространством, объектным, размером с диск. То есть на сегодня — терабайт, два терабайта, завтра — десять терабайт примерно. И garbage collection, который нужно провести, нужно провести на всем этом самом терабайте или десяти терабайтах.

И надо понимать, что на сегодня, никакого garbage collection не существует. Весь garbage collection, который на сегодня реализован, это сборка «хороших объектов», и выкидывание остальных. Понятно, да? То есть для того, чтобы собрать мусор, нужно обойти все нужные объекты на диске. И не существует никакой возможности, каким-то образом это дело… даже все существующие, там, частичные сборщики мусора, все равно, они либо неполные — за ними кто-нибудь да подбирает, либо они останавливают к чертовой матери всю машину, в этом случае, можно убирать и все, но и в том проблема. Казалось, что это неразрешимая проблема, потому что терабайт, и мало того, что терабайт, так ведь этот терабайт еще и не весь в памяти, на самом то деле, система ведь загружает в оперативку лишь те объекты, которые реально нужны, остальные валяются там, на диске.

Если мы начинаем делать сборку мусора, по всей этой самой катавасии, то это означает, что мы должны поднять с винта все, что на нем, вообще говоря, есть. В оперативку. Ну не полностью, ведь нас волнует в основном header объекта, но нам ведь нужно не только поднимать, но и записывать… Война и немцы! Просто, конкретно, совершенно беда.

Я стал прикидывать, ну может быть, я не знаю, ночью она будет это делать… в тихую там… Полные, жуткие страдания, я реально раздумывал, не убить ли проект, потому что непонятно, что делать. Две вещи меня спасли. Первое — я почитал про Azul, которое реально, эти ребята научились делать garbage collection на терабайте, on stock.

Даже три есть выхода из ситуации.

Второй выход из ситуации, мы его пока не приняли, потому что все эти алгоритмы они, как выяснилось, кем-то довольно злобно лицензированы, в чем тонкость? Есть очень старый, добрый, простой способ garbage collection-а. Называется он reference counting. Мы считаем число ссылок на объект, упало в ноль — объект выкинули. Твердый, дубовый, работает довольно просто, очень даже можно жить, но опять же всем известно, что он не спасает, если у вас есть циклы объектов. Сделали колечко, у всех ссылочка больше чем нолик, все они будут валятся где-то в углу, внешней ссылки на это нету, вечно потерянная память, не собирается. Есть алгоритмы, оказывается, которые называются loop-breakers. Они каким-то образом анализируют, потихонечку идут вдоль объектов в системе, и как-то приглядывают, не цикл ли это? Если цикл — то они его разрезают, а дальше обычный garbage collection добивает. Хорошая штука, но с лицензиями непонятно, поэтому тоже решили откинуть в сторону.

И третий вариант, собственно, который пришел в голову, когда я пошел искать в интернете все, что есть на тему garbage collectionа, это большая такая область, тяжелая, нашел статью, в которой автор размышлял на тему,… В чем есть самая большая проблема garbage collectionа? Если мы все можем остановить, спокойно програмку выключить, и спокойно все обойти, то очень легко сделать сборку мусора. А если программа продолжает работать, то сборка мусора может оказаться неверной, причем неверной в неправильную сторону. Ладно бы она не нашла какой-нибудь мусор, так она может еще счесть мусором какие-то правильные данные, там очень простая ситуация, которая может случится, система обходит все объекты, вот некоторые объекты, представьте себе, отсюда на него есть ссылка, система ходила-ходила-ходила, не дошла до него через, слева, пошла вправо, а это время его взяли и отдали левому объекту, который уже был обойден до этого. Она и здесь, пока ходила, его не увидела, его перекинули, она его вообще не выдала, а он при этом вполне нормальный, живой.

Чтобы, чтобы с одной стороны не стопить программу, а с другой стороны, позволить себе собрать все объекты, делают, … много разных вещей для этого применяют, например, делают такую вещь. Через систему виртуальной памяти, все объекты, к которым программа прикасалась во время работы, специально помечаются как живые. Вполне нормальная схема. Но вот, обсуждая эту проблему, автор статьи сказал следующую смешную штуку, на которой я просто подпрыгнул — «если бы у нас была полная копия всего состояния всей программы» — и тут у меня щелкнуло — «Боже мой, я же пишу операционную систему, в которой всегда есть полная копия, всего состояния, всей программы в стране». И это натуральная, естественная жизнь, этого самого компьютера, которую дополнительно реализовывать не надо.

А мысль очень простая — то, что было мусором во вчерашней версии, сегодня тоже мусор. Поэтому, если у нас есть вчерашняя версия всего состояния, то можно спокойно найти мусор, она уже стоит, она уже никуда не бежит, она уже не меняется, она валяется на диске, ее можно медленно, тихо, ночью, когда угодно, обойти, найти весь мусор, и в актуальной версии его убить.

Отсюда возникло очевидное решение. В Фантоме два garbage collectора. Сейчас пока один, второй в разработке.

Первый garbage collector сделан на ref-countах, он очень тупой, у него есть два важных свойства: он всегда коротко работает, очень маленькое, предсказуемое время нужно на проверку того, что ссылка стала нулем. Она стала нулем — убил локальный объект. Причем тоже я про это говорил, статистика говорит нам, что большинство объектов в системе создаются на короткое время и имеют одну ссылку. Поэтому refcount garbage collector очень быстро убивает коротко живущие локальные объекты. Поэтому основной оборот памяти в системе, garbage collector-ом c refcount-ом вполне себе обрабатывается. А какое-то количество долго живущих объектов с циклами, они постепенно откладываются, то есть остаются, не собираются, этим сборщиком мусора, попадают в snapshot, и после того, как случился snapshot, запускается длинный garbage collectор, который уже собственно сделанную фотографию системы медленно-медленно, спокойно ее обходит, находит в ней мусор, и его уничтожает.

Почему собственно я этого не боюсь? Когда я описывал это людям, которые занимаются garbage collectoрами, они меня спросили — вот ты не боишься, что недособранных объектов станет очень много и они всю память заполнят? Нет, не боюсь. Потому, что они заполняют виртуальную память. Ну, во-первых, диска у нас и так до хрена, во-вторых, хорошо, ну положим мы на него еще ну мегабайт, ну два, ну сто мегабайт даже, вообще говоря, современному диску это совершенно незаметно. Вот, более-менее решенная проблема.

Еще есть некоторое количество проблем, которые возникают именно в такого типа системах, в линуксах их быть не может. Например, как устроен системный вызов в обычной операционной системе? Работает программа, ей хочется сделать fileopen, она делает прерывание, попадает в ядро, … плохой пример. Скажем — read из socket-а. Попадает в ядро, начинает читать из socketа, а в socketе ничего нет! Что происходит? Она блокируется! То есть программа ушла в системный вызов, и там заснула. Когда данные появляются, она пробуждается, мы возвращаемся обратно в код, поехали дальше.

Такого в Фантоме делать нельзя. Почему? Потому что, как устроена память Фантома? Это какое-то несвоппируемое ядро, и после него, дальше, сверху, начинается эта часть памяти, которая персистентна, в ней живет вся наша обьектная…

Если она пошла в ядро, то делать snapshot нельзя. Почему? Потому что ядро может измениться, мы можем при следующем старте взять другое ядро, проапгрейдить его, да и просто даже, даже старое ядро, запустившись заново, оно находится в другом состоянии. И если мы пытаемся поднять снепшот, в котором код находится в ядре, то скорее всего он просто взорвется.

Поэтому вот правило «разработки в Фантоме» гласит, что все системные вызовы блокироваться не могут. Сходил, забрал — возвращайся.

Проблема! Ведь все-таки блокироваться как-то надо. Вот тупой совершенно системный вызов sleep, какой-нибудь, вот поспать процесс хочет, секундочку-другую, что-то надо с ним сделать. Решено следующим образом. Если процесс хочет сделать что-то такое, что может его заблокировать, то это делится на два вызова — в первом вызове он уходит и сразу возвращается, но вернувшись, тут же засыпает, там, у себя наверху, в состоянии, нормальном, полноценном, в том, которое можно зафотографировать. А ядро, если оно сделало что-то важное для него, и хочет ему об этом сообщить, оно его пробуждает, и в следующем системном вызове оно его забирает. Такая вот непростая модель.

Что еще такого, нетривиального? Ну во общем, на самом-то деле, по большому счету, нетривиальности все находятся на той стороне, на стороне ядра. Для программиста, Фантом — это очень простая вещь, система, которая такая же, как все остальные, только программы в ней живут вечно. Тоже в общем, неправильно говорю, потому что вызывает неверные ассоциации. Данные живут вечно! Программу можно убить, перезапустить, это обычный thread, который так же себя ведет. Потому что меня постоянно спрашивают — если программа вечно живет, а она сломалась, как же ее убить? Ну просто убить. Берешь и убиваешь. Тем же самым killом и убивешь, или нажатием на какой-нибудь крестик, там, в уголку. В этом плане никаких отличий нет. Просто данные, которыми она пользуется, они остались. При остановке процесса, все это остается.

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

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

Вопросы


Вопросов много, поэтому чтобы не раздувать хабратопик, мы решили их не копировать. Все они доступны здесь.

Коллеги, обращаю ваше внимание, что Дмитрий Завалишин будет выступать в ближайшую пятницу (29 апреля) на Application Developer Days в Санкт-Петербурге. У вас есть отличная возможность поговорить с ним лично. Присоединяйтесь к нам!

Примечания

  1. Стенографист был один из тех, что поднял тогда руку (было это на РИТ-2010), а делал я и OLE-объекты, и OLE-объект, который позволял запускать VB-скрипты через AXHost, а те скрипты использовали другие OLE-объекты… впрочем, было это реально давно, в 1997 году где-то.
  2. Cм. нашу видео-скринкасто-запись, там все видно.
  3. Cтраничка доклада на сайте конференции.
Андрей Майоров @AndrewMayorov
карма
51,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (117)

  • +3
    Идея довольно интересная. Давно слежу, будет круто если это во что-то выльется.
  • +17
    Проект сильно впечатлил. Вот что реально финансировать нужно. Жаль, немного таких людей…
  • +2
    Думаю, что к моменту когда её допилят, будет интересная штука. И компьютеры тогда уже будут подходящими для подобных финтов «нет-убийствам». Но вот на сервере, например, такая не особо нужна. Потому что сервер и перезапускается нечасто, и память должен беречь. А вот до десктопа ей ещё очень далеко, если какой-нибудь совместимости бинарников с популярными системами не будет.
    • +3
      DZ говорил, что первый прицел — это встраиваемые системы. Телевизоры, холодильники. Там готовые приложения не нужно тащить.
      • +2
        Не верится. Насколько я понял, ей нужно очень, ОЧЕНЬ много оперативки и хорошо если адресация 64 бит. А такой шик на холодильник не каждый производитель будет ставить. Какой-нибудь MINIX 3 будет более выгодным вариантом.
        • 0
          А зачем ему много памяти. Вроде как памяти надо ровно столько, сколько требуются работающим процессам. А 64х разрядность нужна для адресации жестокого диска, а не оперативки.
          Т.е. на втроенных системах с жестким диском (флеш памятью) до 4х гигабайт 32х разрядной системы с головой, да и оперативной памяти не больше надо, чем всем остальным системам.
          • +1
            а я вот прослушал/не услышал ситуацию когда у нас данных ну намного больше оперативы, что тогда (и поступают они, допустим, не с HDD, а с сети)?
            • 0
              А другие ОС от этого захлебываются? Повторное использование объектов и/или gc должны спасать в такой ситуации.
              А если мы, допустим, качаем 40G файл, а у нас 4G оперативы, то он постепенно начнет свопиться.
              Единственно что, если мы качаем его с торрентов маленькими перемешанными кусками. в таком случае своппинг должен сойти с ума от постоянной подгрузки/выгрузки страниц (или как у него там блоки называются).
              • 0
                вы точно на мой вопрос ответили?
                я спрашивал как это в данной ОС, а не как сейчас.
            • +1
              А тогда начнется допиливание, встраивание заплаток на основе «старья, которое развивалось-развивалось» и т.д. И получим в итоге нормальную полноценную ОСь, только с меньшим функционалом, потому-что она вынуждена догонять убежавших вперед «старичков».
            • 0
              Да, Вы правы, примерно так можно построить приложение, которое полностью повесит (засвоппирует) данную систему.
              Правда, это и для существующих осей возможно.
              Все упрется в соотношение «объема оперативки»/«оптимальность управления памятью».
              Чем больше первое и чем лучше второе, тем меньше проблема.
              А как возникнет-таки проблемка, метода известная: нужно убивать приложение.
        • 0
          Чип в телевизоре вполне может заниматься декодированием видео (и занимается уже во многих). Так что на процессорную мощь уже есть спрос.

          Про холодильник ничего дельного не скажу. Я его, видимо, зря приплел. Вообще не знаю зачем это холодильнику. :)
          • 0
            Можно будет p2p сеть для холодильников написать. Они будут обмениваться друг с другом виртуальными магнитиками и подсказывать хозяину, что нынче модно жрать у вас на раёне.
        • 0
          не нужно много оперативы, та же виртуальная память, которая свопится на диск.
  • +3
    у проекта есть какой-нибудь сайт? с кратким описанием, текущим состоянием и инструкции как присоединиться к проекту хотя бы?
  • 0
    Как-то растянуто вышло. Дмитрий Завалишин утверждает, что система написана с чистого листа, но в ходе презентации ясно дает понять, что многие моменты пособраны из других систем, тем самым legacy о котором идет речь присутствует в виде концепций, идей и прочих вещей, придуманных давно. Слышал о системе еще пару лет назад, но ее инновационность сомнительна… даже если сейчас начинать тратить миллионы на разработку и маркетинг, волна linux систем уже с десяток лет торжествует…
    • +9
      Я полагаю, что стремиться сделать что-то настолько отличное, чтобы ни одна старая концепция не подходила — это вообще неправильная цель. В конце концов, делается именно ОС — программа для управления программами. Ось построена по необычным принципам, но ее назначение вполне традиционно.
    • 0
      А никуда не денешься от подбирания и встраивания старых кусков. Операционки разрабатывались опираясь на существующую структуру железа. А она с тех пор практически не изменилась — проц+оперативка+внешнее хранилище. С появлением и развитием флэш-дисков внешнее хранилище будет все ближе к оперативке, но всеравно не догонит и структура эта будет сохраняться еще долго. Может что-то типа квантовых компьютеров изменит эту картинку, ну так для них и другая идеология построения систем будет разработана, на совершенно других логических принципах.
  • 0
    Интересно, если вынести всю эту среду в облако, наверное можно и проблемы сборки мусора решить, и снепшоты. От пользователя далеко и для него незаметно.

    Правда, встает проблема квотирования всего и вся…
    • –1
      о том же подумал. Новые ОСи для десктопа уже какбэ неактуальны, все потихоньку переезжает в веб
    • +1
      Облачные бонусы от Фантома неочевидны. Там гораздо важнее кластеризация, параллельное обслуживание запросов, нежели чем быстрый старт приложения и отсутствие возни с файлами. Наоборот, более полезна возможность прибить рабочую ноду в любой момент и начать с чистого листа.
      • 0
        Неочевидны, согласен.
        Прибить-то можно, не ноду а приложение, просто объявить все его объекты мусором и запустить новый экземпляр.
      • 0
        зато как красиво смогут взаимодействовать сервисы в одном облаке
        • 0
          Красиво, но с большим синхронизационным геморроем. Тут ведь много тредов параллельно будут работать с единым графом объектов, живущим в памяти.
          • 0
            … в памяти сразу нескольких машин?
            • 0
              Да, при этом не реплицированные, а один объект на какой-то одной машине. Нет, это точно не кластерное решение. :)
  • +4
    Может, я не прав и не знаю тонкостей, но с виду оно мне бредом кажется.
    Общее адресное пространство для всех программ имхо убивает безопасность. А выделение отдельного стека для каждой функции — просто захламит память (зачем отдельный стек функции, которая слагает два числа?).
    Постоянный сброс на диск всего содержимого оперативки с корректным ее восстановлением вряд ли возможен параллельно, так как если два процесса взаимодействуют между собой, но находятся в памяти далеко друг от друга, при восстановлении второй процесс будет получать неактуальную информацию от первого. А если какой-то процесс работал с сетью, то соединение будет утеряно и придется постоянно осуществлять проверку на это и создавать соединение заново. Хотя может быть, эти проблемы с сохранением/восстановлением как-то решили.
    Отсутствие файловой системы с хранением всех файлов в памяти, с передачей их между процессами — это мне кажется еще большим бредом. Как эти процессы будут взаимодействовать с имеющимися накопителями данных? Для этого все равно придется реализовывать нечто (модуль, процесс, драйвер — не знаю, как в этой операционке оно будет назыаться) для работы с файловой системой. Передача файлов между процессами должна затруднить их работу, так как сейчас файловые системы — один из основных способов взаимодействия программ между собой, в том числе между программами на разных компьютерах. Опять-таки непонятно, как хранятся снепшоты памяти на диске, если нет файловой системы. И тем более непонятно, откуда берутся программы, чтобы их запускать.
    Сборка мусора на основе reference counter в подобной системе — плохо, ибо не осилит циклические связи и в результате память захламится процессами/объектами с циклическими ссылками.
    Но вообще идея интересная :)
    • +4
      Насколько я понимаю, файлов там просто нет. Поэтому если вам нужно перенести документ из одной систмы в другую, надо его заэкспортить из объекта в некоторый документ, а на другой системе — проимпортить. В принципе, совершенно аналогичным образом работают со своими файлами все программы.

      Синхронизирование памяти на диск у них уже работает. Так что о невозможности говорить поздно, видимо. :)
      • 0
        В таком случае все равно получается файловая система.
        А по поводу синхронизации памяти с диском — я просто не понимаю, как оно может работать одновременно и параллельно с процессами, и корректно.
        • +6
          Если все приложения написаны на неком managed языке, то ОС контролирует все указатели. Т.е. можно, например, взять и внезапно сделать COW на всю память — заменить указатели на настоящую память другими, обращение к которым будет вызывать исключение, обрабатываемое ядром (которое будет копировать старые блоки памяти). После этого можно спокойно записать все старые блоки на диск (приложения теперь не могут портить память, которая уже записалась). А потом наложить изменённую память и высвободить ненужные старые блоки (в случае их полной замены новой версией). Остаётся проблема с сохранением целостности данных во время изменения состояния самим приложением, то тут можно поступить так же, как в современных РСУБД — ввести понятие транзакции (которые тоже можно реализовать через COW).
          • +1
            Уговорили :)
          • 0
            Да. Такое возможно только при введении понятия транзакции и введения этого понятия в систему разработки программ для Фантома. А кто забыл коммитнуть свой результат — получит на выходе пшик и больше забывать не будет.
          • 0
            Как вывод — большая вероятность ошибки в ОС, которая может привести к Privelege escalation. Т.к. в данном случае границы ОС находятся в области managed code — unmanaged code, в этот самый unmanaged код лезет дополнительно интерпретатор, бесконечные JIT, GC, etc., etc. Если надо что-то написать критичное к скорости, от gc нужно будет отказаться, что эквивалентно запуску потоков в ядре в современных ОС.

            … и я что-то не верю в быстрый GC :// Перекладывая проблему контроля ЖЦ объектов с очевидно технически оптимального места (явно, в коде, соответственно семантике ЖЦ объекта) на другое, более простое в смысле кодирования (неявно, через многочисленные алгоритмы), неизбежно получается проигрыш в ресурсах.
            • 0
              Можно придумать и ручное управление памятью для managed языков, например инвалидировать указатели и выполнять проверки в момент free (а если язык хорошо поддаётся статическому анализу, то можно проверки и опустить). А ещё можно съесть много памяти и отложить GC «на потом». Privilege escalation возможен и в случае обнаружения ошибок в процессоре — хотя, конечно же, это гораздо менее вероятное событие.
              • 0
                Вы, видимо, имеете ввиду явно дропать единственную ссылку на объект. В таком случае всё равно есть накладные расходы на подсчёт ссылок. И вообще, получается борьба «машина всё сделает за вас, ни о чем не думайте» и «не учите меня жить», которая обычно плохо заканчивается.

                Где отличие классической ОС и managed модели в смысле ошибок процессора? Если их нет, тогда зачем вообще об этом говорить?
                • 0
                  Отличие в том, что классические ОС позволяют пользовательским процессам манипулировать регистрами процессора напрямую, а также используют больше особенностей архитектуры (всё, что связано с переключением задач и защитой памяти).
          • +3
            Всё ещё проще — в r/o переключаются страницы виртуальной памяти — тот же COW, только нет никаких проблем с приложением и не нужно менять указатели. Строго говоря, персистентность памяти Фантома никак не связана с managed языками — в ней можно и юниксовые процессы запустить, и, наверное, в следующей версии мы так и сделаем. :)
    • 0
      Кстати, вот комментарии самого DZ про файлы:
      dz.livejournal.com/550453.html
    • +4
      > Опять-таки непонятно, как хранятся снепшоты памяти на диске, если нет файловой системы.
      Это можно сделать, например, так же, как в Линуксе (mkswap). Хотя swapfs и можно назвать файловой системой, но файлов там нет :)

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

      > Для этого все равно придется реализовывать нечто (модуль, процесс, драйвер — не знаю, как в этой операционке оно будет назыаться) для работы с файловой системой.
      Это значит, что это нечто можно будет легко выгрузить/обновить/загрузить обратно. Если в этой реализации драйвера ФС будет допущена ошибка, то это не приведёт к фатальным последствиям, как в «обычных» ОС.
    • +1
      >>Постоянный сброс на диск всего содержимого оперативки с корректным ее восстановлением вряд ли возможен параллельно
      Посмотрите, как быстро делает снэпшоты VMWare Workstation, а тут будет реализованно на уровне ОС. Я примерно это себе представляют, как моментальное копирование файлов в ZFS — логическое копирование происходит практически мгновенно, область памяти просто помечается, как скопированная, а физическое копирование происходит постепенно, по мере изменения данных или наличия свободных ресурсов.

      • +2
        Так и есть. Вы совершенно правы.
    • +2
      безопасность обеспечивает runtime managed языков
    • +2
      Общее адресное пространство для всех программ имхо убивает безопасность
      Не убивает — managed код, запрет на адресную арифметику — и тучи рассеиваются, мир становится солнечным.

      Меня в этом проекте больше смущает производительность, соблазн использовать винт понятен — но это ж медленно, не выкопаем ли мы себе на нем могилу?..
      • 0
        Ну тут скорее NVRAM, Flash например. То есть деления на «диск» и «не диск» просто нет.
      • 0
        Уже сейчас есть SSD, SATA III, Thunderbolt, другие красивые слова. Думаю, до сверхбыстрой персистентной памяти недолго осталось.
        • 0
          При всей красивости слов скорости по стравнению с памятью совершенно не сопоставимы.
          • 0
            Пока не сопоставимы.
            • +1
              В то счастливое время и необходимости в RAM как классе не останется. Зачем? Если ROM такая же быстрая? Тогда, простите, любые процессы в любой оси станут персистентными, и без всяких затей.

              А вот каких либо оценок производительности Фантома что-то не видно… ну кроме «это ядро такое медленное потому что девелоперское» — дык покажите недевелоперское, запустите на нем что нибудь сложнее i++, пусть память жрет, пусть снапшоты пишутся в полный рост не умирая на IO.
              • 0
                В лохматом году (около 1990) Intel сделали микросхемы NAND, по тем временам сделали резкий прорыв по скорости работы. Тоже говорили — «круто, скоро сделаем на этой технологии процы и ОЗУ — компу будет не страшно отключение питания». Где-то брошюрка даже валяется, про эти микросхемы.

                И где они, где эти компы?
                • 0
                  Ну не сравнивайте хрен с пальцем…
                  У интела и других крупных контор разработок на десятки лет вперед.
                  Только разработки стоят очень дорого, а предыдущие еще не окупились…
                  Им банально невыгодно новье производить — так как из текущих разработок еще не все деньги выжаты…
    • +1
      Общее адресное пространство для всех программ имхо убивает безопасность

      Разруливание ошибок просто надо переносить на уровень верификации кода, посмотрите как это сделано в Singularity
    • +1
      например, в гуглооблаках (appengine) нет никакой файловой системы, а вызовы open() эмулируются чем-то странным.
      не сказалбы, что существование приложений в этой среде сильно проблематично.
    • +1
      > Общее адресное пространство для всех программ имхо убивает безопасность.

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

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

      По-моему. DZ делает для себя открытие велосипеда. Он не понимает или не видит современные тенденции развития ПО. В качестве модели того, что должна предоставлять операционка:
      — Software Transactional Memory — граф объектов с транзакционным доступом. Вся память делится на репозитории, каждый из которых представляет собой граф объектов. Для доступа к каждому репозиторию извне используется SPI (Service Provider Interface), а ссылки действительны исключительно внутри графа. Persistence графа делается прозрачно внутри SPI по мере необходимости.
      — Асинхронную модель параллельной обработки на базе Actors. Отказаться от тредов и процессов как таковых, ибо они лимитированы и плохо параллелятся.
      — Единый Registry объектов и сервисов.
      — Transport SPIs — сервисы приема-передачи данных.

      А DZ зациклен на том, как посчитать сцылки и сделать вечными программы.
      • 0
        Во, разумный комментарий. Думал, что же меня смущает — после вас смог сформулировать:

        передаю я том процессу свой объект, а он грохается и его портит. И что мне делать?
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Спасибо, поправил. Стенограмма писалась на слух, так что косяки есть.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +5
    Очень понравилась и идея и то как её излагает автор.
    Некоторые высказывания ближе к концу выступления буквально заставили улыбнуться.
    Вот мне почему-то кажется, что если после всего сказанного авторы концепции с головой и также творчески подойдут к вопросам безопасности, то это будет действительно бомба. А взорвётся она в тот день, когда в архитектуре ПК по техническим причинам исчезнет разделение на быструю оперативную и медленную постоянную память. Над этим инженеры уже давно работают.
    Удачи.
  • +10
    Любопытно, что следить за этим проектом я начал с самого начала, практически когда это были еще только «мысли вслух» в очередных выпусках тогда существовавшего dz-online, страшно вспомнить как давно.

    Завалишин большой умница и упорный человек, который «хотя бы попытался», в отличие от остальных, которые на том же Хабре исписали словами «пилят, воруют, сколково» и так далее, уже не одну сотню килобайт.
    • +4
      Забавно кстати, как изменилась (в позитивно-конструктивную сторону) тональность комментариев на посты про Фантом за последние 1-2 года. Любопытно, это всё уже другие люди пишут или те же, что раньше dz поливали всякими жидкостями :)
      • +10
        «Сперва тебя игнорируют, потом над тобой смеются, потом с тобой борются, потом ты побеждаешь.» (с) Ганди
    • –3
      То что Завалишин молодец не как не отменяет того что кругом пилят, воруют и сколково — дерьмо. И то что люди это отмечают не в коем мере не говорит о том что они ничего не пытаются, даже наоборот, просто глупо молчать — видя очевидное.
      • +4
        Просто есть люди, для которых тот факт, что «воруют и пилят» есть достаточное оправдание махнуть на все рукой и не делать вообще ничего, оправдывая этим, безусловно отвратительным безобразием России, собственную неспособность ничего сделать.
  • +3
    Надо отметить что даже мне не программисту вполне понятно о чем идет речь. Вообще идея отличная и стоит того чтобы жить и разрабатываться. Честно говоря когда я с пол года назад прочитал про ФантомОС я решил, что это вообще выдумка или что-то вроде концепта, которое так и будет концептом, рад что ошибался.
    По поводу файловой системы, в данном случае, мне кажется, её лучше назвать системой хранения объектов раз вместо файлов объекты.
  • +2
    По-моему они переизобрели лисп-машины, с небольшими улучшениями.
  • +2
    Похоже на OS/400, если я правильно понимаю.
    • 0
      да, тоже отметил, что идею одноранговой памяти, никаких файлов, всё — объекты, встроенная бд я изучал еще в 199… году на курсах AS/400
    • +4
      есть на сайте в вопросах и ответах:
      — Q: Это похоже на...?

      A: Это, в зависимости от вашей религии, похоже на Java, Smalltalk, C#, Python, OS/400, iAPX432, Inferno, Grails, Singularity и т.д. и т.п.
  • +2
    Блин, предупреждать нужно, включил как радио, а это оказался сеанс гипноза!
    Идея буквально выносит мозг, когда пытаешься представить как там можно решать привычные задачи.
    Для встраиваемых устройств, это просто что-то невообразимое, и гораздо более рациональное чем всякие там андрйды…
  • +1
    Интересно, что концепция «все вызовы дико неблокирующие» вполне себе реализована в фреймворке
    Twisted.
    Возможно это одна из идеальных сред для будущего Phantom.

    Мне Phantom активно не нравится — я сужу с точки зрения безопасности и мне представляются просто стада вирусов-обьектов внутри этой системы! Но удачи Завалишину — может это как-то можно побороть.
    • 0
      Вот кстати насчет вирусов интересная тема. Да, у нас managed code и полная безопасность в юзер-моде. Но хотелось бы рассмотреть два момента:

      1. ОС будет постоянно развиваться, будут выходить всякие обновления и патчи для ядра. Значит будет механизм, позволяющий засунуть в ядро нативный код из внешнего источника. Источник можно подменить, подпись можно подделать, ключ шифрования можно подобрать или украсть.
      В итоге встает вопрос проверки благонадежности импортируемого кода, для чего потребуется интегрированный в систему антивирус.

      2. Всегда остается угроза критической уязвимости в управляющем модуле прослойки между стулом и монитором. Даже если эта прослойка не обладает админскими правами, все равно сложно помешать ей нажать «да», когда какое-нибудь приложение с непонятным, но вызывающим доверие названием в духе «глобальный супервизор безопасности» запросит доступ к объекту с непонятым именем «BrowserName::UserDataStorage->SavedPasswords».
      Это ставит вопрос о том, как не дать пользователю наломать дров, не стесняя при этом его свободы.

      Собственно тут нет ничего нового, просто интересно, как будут реализованы механизмы защиты в ФантомОС.
  • 0
    Я б выделил 2 основные идеи
    1. Full Managed OS, — единое адресное пространство, только менеджед языки для разработки итд. Фактически ОС == виртуальная машина. И я двумя руками за такое решение.
    2. Сохранение состояния обьектов, отсутствие файлов — и эта идея вызывает намного больше вопросов чем дает ответов. Звучит конечно круто, но насколько это реально?
    Будет очень обидно, если проблемы при реализации второй идеи испортят карму 1й.
    • +1
      Это реально. В смысле — сделано.
      • 0
        Что тогда скажеш, очень круто.
        У меня все время возникают вопросы в стиле «почему мы тянем за собой это гавно 40 летней давности» и я очень рад, что есть люди, которые взяли на себя грязную работу это все вычистить.
  • 0
    Присоединюсь к большинству, идея превосходная. Даже если она не выйдет на рынок в качестве реального продукта, думаю может вполне быть приобретена крупными компаниями и интегрирована в их спектр. Причём компаниями не сколько софтверными сколько производящими железо.
  • 0
    Самое главное почему-то все упускают — востребованность системы определяется наличием в ней востребованных приложений. И поэтому чаще поддерживать «старье» экономически выгодней. По этой же причине за бугром до сих пор живут тучи Cobol-программ на давно забытом, можно сказать мертвом (как латынь) языке.
    Если эта ОСь родится и даже если она будет большой конфеткой, скажите, кому она будет нужна на рынке?
    Технические идеи — это технические идеи. Но я не вижу как минимум бизнес-идеи.
    • 0
      Дык, метод проб и ошибок. Не всё меряется коммерческой выгодой, есть ведь чисто академические изыски, которые могут принести доход только в очень далёкой перспективе, или вообще не принести.
      • 0
        Вот академическая полезность, считаю, присутствует. Пусть не весь проект, но отдельные рещения могут получить право на жизнь в качестве расширений программных продуктов или даже существующих операционок.
  • –5
    lvm снапшои по крону = новая ос?
    • 0
      Ну во первых ничего общего со снапшотами lvm тут нет, а во-вторых, вы будете делать снапшоты каждые несколько секунд?
  • 0
    У кого получилось скачать видео — выложите magnet-линк, пожалуйста.
    • 0
      У вас проблемы со скачиванием с narod-а?
      По моему опыту это наиболее оптимальный файлхостинг без порнографии, в России скачивалось очень шустро.

      А если вы зарубежом, то как раз можно скачивать с Vimeo (который запрещает скачиваение для России).
      • 0
        У меня (самара) народ — самый нестабильный файлохостинг. 10 метров могут качаться два часа, а могут — две секунды. Правда работает вполне ожидаемо — в строгом соответствии с законом Мерфи: когда присылают посмотреть какую-нить хрень — загрузка на максимальной скорости, файлы от заказчиков, которые нужны прямо сейчас, делают всё возможное, чтобы ни в коем случае не попасть на мой компьютер :)
        • +1
          Грустно. Буду знать.
          Что делать правда непонятно — выкладывать записи на торренты бессмысленно, это не прон, качают их редко…
          Эта же запись «DZ про Фантом» полгода лежала на народе без единой скачки…

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

          А на остальные [варезо]файлхостинги мне этика не позволяет выложить.
          • 0
            Т.к. вы не мой заказчик, видео скачалось хорошо, спасибо что выложили! :)

            Я думаю в дальнейшем выкладывайте так же на народ. Проблемы с народом единичны, судя по отзывам знакомых, не стоит на нас ориентироваться )
      • 0
        После того как хабра-эффект спал видео удалось скачать без проблем.
  • 0
    Считаю что Фантом это фантом и регресс потому что:
    Отсутствие сборщика мусора изначально и в процессе работы.
    Сохранение данных вместо протоколов обмена.
    Отсутствие типизации данных.
    Отсутствие таймеров системы реального времени.
    Отсутствие внятной реализации на уровне языка.
    Большой объём в памяти, низкая скорость.

    Смотрим альтернативу bluebottle из Швейцарии.
    Сборщик мусора и активные объекты, которые учитывают ссылку и обеспечивают сборку мусора.
    Все понимают, кто в теме, что данные это перегрузка протокола, тоесть надо сохранять не процессы а алгоритмы разбора или деревья протокола точнее.
    (Смотрим xmpp)
    Чёткая типизация данных.
    Таймеры на месте.
    Реализация объектов, структурных типов, Активных объектов и явное присваивание (:=) на уровне языка.

    Плюс: наследование данных, выполнение любого кода написанного в любом окне, явные модули и нет проблем с областью видимости, всё само себя компилирует и занимает маленький объём. Работает быстро.

    Уд.,
    i
    • +1
      Кстати, да, удивительно, что про OBERON System и последователей никто не вспомнил ещё. А ведь замечательная вещь была, причём, насколько я помню, с конца 80х уже.
    • +7
      Откуда Вы это всё взяли??

      — сборщик мусора, конечно, есть.
      — типизация, конечно, есть.
      — приоритеты (таймеры-то тут при чём?) реального времени, конечно, есть. Таймеры, конечно, тоже.

      Остальное как-то в пользу бедных — что такое «внятная», что такое «большой» (на 64 Мб запустить можно, да и в 32 втиснуть вряд ли проблема).

      Фантом — не ЯП, а ОС. ЯП поверх можно реализовать почти какой угодно.

      PS: value assign в ЯП Фантом тоже есть, это банально. Этот ЯП там для мебели — у меня нет амбиций разработчика языка. Несмотря на то, что сделал пару, и их даже кое-где используют. :)
      • 0
        «Остальное как-то в пользу бедных» — просто проекты новых процессоров основных игроков на рынке направлены на экономию энергии и на использования встроенной памяти сенсоров. Поэтому Вы тут ошибаетесь.

        Повторяю: Данные это перегруженный непосильно протокол. Современные ОС типа Актив Оберон А2 (BlueBottle) проектируются как раз на основе созданного языка, в котором и заложены те особенности которые вы хотите создать в ОС с листа.

        Вспоминаем: Вначале Си, потом UNIX.
        Вначале компилятор и инструменты GNU, затем Линукс.
        Вначале Актив Оберон а потом уже OS A2.
        Вот без такого подхода и получается вещь в себе, которую Вы и сделали.

        Даже поверх. Net можно не что угодно реализовать, а специально созданный на деньги MS Zoonon.

        Ждём что создадут в Googl для языка — Go.
        Что за язык использует Oracle все знают.
        И все примеры со встроенным сборщиком мусора.

        Похоже у Вас концептуальная ошибка!!! Из за незнания теории проектирования инженерных систем.
        Смотрите Матлаб/Симулинк. Про проектирование FPGA Вам даже не советую смотреть. Так как там больше про реальную физику, а она однозначно указывает, для RT ОС больше подходят множество ядер или даже чипов небольших недорогих процессоров с отсутствием цикла и присутствием прерываний по таймеру для каждой задачи а не одна большая куча-помойка.

        Так что видно что Ваша система для «бедных и обречённых» :-)

        Удачи,
        ignat
        • +1
          Ну — видно и видно. Сделайте лучше.

          PS: Историю Юникса надо бы и знать — он был написан ДО появления языка Си. Натурально, на языке Би.

          PPS: Я не очень понял, с чего Вы решили, что мне незнаком матлаб и программирование FPGA. У меня несколько хобби, и программированием на верилоге я иногда занимаюсь, чего тут такого фантастического-то?

          PPPS: Да и системки я проектировал — дай бог каждому. Ничо, что я спроектировал инфраструктуру для портала Яндекса? И крупнейший сервис Яндекса после поиска? И сам портал до 2004 года вёл? Вы уж, это, как-то поспокойней с оценочками, ладно?

  • +1
    «Пользователь не заметит исчезновения файлов. Для него будут существовать папки и иконки-документы в них. Иконка будет активизировать (условно говоря — запускать метод editDocument в новой нити) объект, соответствующий документу пользователя. Просто документ будет храниться не в сериализованном «файловом» виде, а ровно в том виде, в котором он присутствует в программе и удобен для её работы. Это означает, что 1) программист больше не должен писать код записи состояния программы в файл и считывания его (это, в разных ситуациях, от 30 до 70% кода программы), 2) само «открытие документа» будет происходить существенно быстрее (нет процесса десериализации, нет никакого перемещения данных с места на место) и 3) любой документ может элементарно интегрировать в себя любой другой документ — просто добавив в себя ссылку на чужой объект.»

    Звучит революционно!
    • 0
      Чем-то похоже на Blender RNA, когда граф объектов со всем состоянием программы сохраняется на диск. И работает при открытии разными версиями программы.

  • +1
    Чем-то идеологически переплетается с идеями Раскина про будущие системы, в которых приоритетность «потока» определяет новый уровень взаимодействия, все больше воплощая тем самым идею машины для человека, а не наоборот.
  • 0
    Завалишин есть на хабре?
  • –4
    Потрясный оратор. Становится на каблук, потом ноги бубликом, туда — сюда расхаживает. Да, сложная наука программирование. Нет пределов для совершенства. Обрадовали объяснения в духе — Для того, что бы понять, кто такой Федор Кузьмич надо знать Татьяну Юрьевну.
    Короче, стоит досмотреть до места, где у него все обваливалось из-за мусора. Дальше как-то фрагментарно.
    • 0
      Вам, простите, «шашечки или ехать»?
      • –2
        А что это уже «едет»?
        Я этого не заметил.
        Некий Гуру тряся бородой ( а чем же еще) опровергает вещи достаточно проверенные и оттестированные, и на основании этого заставляет верить себе, как открывшему наконец всем Светлую Истину. В действительности он ничего не рассказывает и не объясняет. Его речь сплошные ссылки. Эти ссылки скорее всего " цикличны", что надежно забивает головы слушателей мусором.
        «… это managed-языки, … вообще говоря, отдельные адресные пространства не нужны» — я должен в это верить? На основании чего? Это что тестировалось?
        Фантом загружается быстрее любой ОС?
        А на фига?
        Я не буду рвать последние волосы и биться головой о стену, если мой компьютер грузится на пару минут дольше. В real-time (автомобили, медицина) для быстродействия ставится FPGA. Кстати ПЛИС сейчас стали такими мощными, что в них целиком заливается ANDROID, что по моему совершенно не нужно, поскольку на кой черт ОС на периферии? А вот нечто подобное Фантому наверно в контроллерах прекрасно бы подошло. Думаю, живи Завалишин в реальности, он бы давно переключился именно на контроллеры периферии. Но… Фантом должен завоевать мир!!! Не менее.
        Дальше
        Ну видел я эти «двухдисковые» компьютеры со времен которых якобы ничего не изменилось. Наверно если ты всю жизнь писал плоский текст и кодовую вермишель, то ты просто этого не заметил. Мне сейчас для того, что бы провести НИОКР достаточно двух программ CAD & MATLAB, а тогда это и не снилось. Это компьютеры, в тут пору служили исключительно предметом самой дешевой спекуляции. Их привозили первые наши Вернувшиеся, продавали за одну цену, ставили в бумагах другую, а на выручку покупали ВАЗ 2109. И еще и на месячную пьянку хватало.
        И для смеха под занавес Цитата
        Около двух третей лица Маркса покрывает борода — широкая, торжественная, густая, скучная борода, которая, вероятно, причиняла своему хозяину много неудобств в повседневной жизни. Такая борода не вырастает сама собой; ее холят, лелеют и патриархально возносят над миром. Своим бессмысленным изобилием она чрезвычайно похожа на «Капитал»; и то человеческое, что остается от лица, смотрит поверх нее совиным взглядом, словно желая знать, какое впечатление эта растительность производит на мир.
        Г Уэллс Россия во мгле.

        • –1
          0/10 Troll Harder
          • 0
            Это для всех, кто пытается усумнить?
  • +1
    Наверно самый длинный пост на Хабре который я внимательно прочитал полностью.

    Спасибо автору за статью, и спасибо Дмитрию и прочим разработчикам за реализацию этой великолепной концепции, которая просто обязана стать основой для операционных систем будущего.
  • +1
    сегодня полностью не осилил, садится батарея, но, стало интерестно, не на ЛИСПе ли пишут/мыслят разработчики? Операционка с принципами REPL и использованием одного и тогоже языка на разных уровнях (от ассемблеров до скриптования) это интересный был бы вариант. А со своим аппаратным базисом, как Lisp machines, например, только с аналогичными видяхами (имеющими, например, встроенные функции отрисовки GUI) было бы еще интерестнее. Можно было бы получить реальное микроядро и перегрузку модулей на лету, впрчем все это фантазии :(
  • 0
    Наверное, каждый на заре обучению языкам программирования встречался со своим недоумением, когда создаём переменную
    var a=0;
    а потом оказывается, что программа держит её только на время исполнения. Дальше нужны файлы или БД для хранения «души умершей программы». Устранение этого архаизма, действительно, упростило бы логику на 1-2 шага. И, конечно, повлекло бы требование правильного называния имён — что есть «а», в каком она контексте. То, что делают объекты и ООП.
  • 0
    Программу можно убить, перезапустить, это обычный thread, который так же себя ведет. Потому что меня постоянно спрашивают — если программа вечно живет, а она сломалась, как же ее убить? Ну просто убить. Берешь и убиваешь. Тем же самым killом и убивешь, или нажатием на какой-нибудь крестик, там, в уголку. В этом плане никаких отличий нет. Просто данные, которыми она пользуется, они остались. При остановке процесса, все это остается.

    Ну блин, ну если программа поломалась, то что под этим понимается? Сам-то код в памяти не портится (ну, один бит на гигабайт за месяц не считаем).
    «Программа поломалась» означает «в её данных возникли внутренние противоречия». Именно ИХ мы хотим уничтожить, и как раз для этого перезапускаем программу, чтобы начать с инициализации — с чистого листа.

    А тут данные сохранятся. Убил, запустил — а программа всё ещё глючит (данные-то остались). Перезапустил машину — а программа глючит. И, судя по всему, нет средств убить именно данные (инициализировать данные этой программы начальными значениями).

    Вообще, идея фантастически клёвая… при условии, что все программисты идеальны и не совершают ошибок. А если кто-то совершил ошибку, и его программа в какой-то момент непреднамеренно передаёт другой ложные данные — что с ней будет? Скажем, ввод от пользователя проверяется, ввод от других программ тоже проверять?
    Или вот у меня был объект, который я передавал на обработку другой программе. Она написана с ошибкой, и вернула мне объект с внутренними противоречиями. Это может привести к тому, что многие другие данные, которые зависят от этого объекта, также станут некорректными. Что делать?
    • 0
      Я так понимаю, что программа — это класс, а запущенная — это экземпляр класса. Можно создать новый экземпляр, а старый убить. Конечно, остается вопрос, что же делать с объектами, которые были порождены первым экземпляром. Убивать? А если на них есть ссылки? Соберутся с мусором? А что делать, если они как-то зависели от именно того экземпляра программы?
      • 0
        В общем, мои сомнения вкратце и в общем звучат так: концепция предполагает гораздо более тесную интеграцию различных программ в среде. Значит, они начинают сильнее друг от друга зависеть. Одна ошибка — и мы можем потерять всю среду, т.е. и все данные, и все установившиеся связи между ними. В случае не столь тесной интеграции мы теряем только блок данных и связи, непосредственно касающиеся него, остальная среда выживает.
  • 0
    Физика связана с реальностью. Пока то, что описано, согласуется с экспериментами, это — правильно. Как только перестаёт согласовываться — нужно разбираться, что не так, и дополнять теорию. Полностью не переделывают — ведь с другими, ранними, данными теория вполне согласуется, значит, она для них является верной. Новые эксперименты лишь показывают границы применимости, за которыми ту, старую теорию уже применить нельзя. Все новые концепции в физике включают в себя старые как частные случаи.

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

    • 0
      … оно само отправилось…

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

      • 0
        Фрики от физики занимаются теорией. Здесь же — сугубая инженерная практика. Ее подтвердить гораздо проще — надо сделать рабочую программу. Собственно, вот они и делают.
        • 0
          Логично, теория и практика. То, что пока слышно о фантоме — что это принципиально другая концепция, и объяснения концепции т.е. теория. Очень похвально, что это он пытается воплотить всё это в практику, я всеми руками за. Это как раз и есть проверка теории.

          Только уже который год я слышу про этот фантом, и никакой практики в руках не держал.
  • 0
    Есть ли загрузочный образ этой системы, доступный теста?
  • 0
    >> Какая виртуальная машина?
    > Это TPL.

    а что за TPL?

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