Опубликовано 09 июля 2010 года
Создание операционной системы - дело серьёзное. Не каждый способен найти средства и силы взяться за него, мало кто в состоянии довести дело до какого-то результата, и уж тем более единицы добиваются успеха на этом поприще. Множество прекрасных разработок в этом направлении были начаты и заброшены на том или ином этапе: Xerox Star, Plan 9, PenPoint, Magic Cap, BeOS... Все их объединяет то, что они никогда не занимали сколько-нибудь заметной доли рынка, не дожили до наших дней и в большинстве своём так и остались утопическими проектами. Можно ли поверить, что вещи, на которых споткнулись такие компании как Xerox и Bell Labs, вдруг будут реализованы небольшой российской компанией?
Эта смелая компания называется Digital Zone. Её основатель Дмитрий Завалишин считает, что это вполне возможно, и прилагает все усилия для того, чтобы осуществить свою мечту - сделать операционную систему, в которой не было бы разницы между запущенной и незапущенной программой. При написании приложений для неё программистам не придётся заботиться о сохранении данных, а научить две программы обмениваться сложными структурами будет не сложнее чем передать простой текст.
Очередная утопия? Вовсе нет. Разработчики "Фантома" уже доделывает ядро ОС и экспериментирует с графической оболочкой. Дмитрий Завалишин рассказал нам подробности.
- Расскажите для начала о своей карьере.
- Начинал я в Советском Союзе в ЦСУ СССР (Центральное Статистическое Управление). Это была крупная организация с хорошими деньгами, у них было всё самое новое. Поэтому было интересно, и надо сказать, что ещё тогда были новые проекты, связанные с коммуникациями. Модемы только появлялись, и всё это было очень "вкусно" и интересно. Собственно, с тех пор и по сей день я занимаюсь разработкой программного обеспечения, за исключением того небольшого периода, когда я работал в компании "Компьютерра" редактором.
Если говорить о самых интересных вещах, которыми я занимался, то это проект, который назывался "Русский интернет" в 1990 году. Я работал с "Демосом" и Курчатником и занимался связью между интернетом и ФИДО, которое в ту пору было достаточно популярно и составляло существенную часть коммуникаций в России.
В двухтысячном году - это компания "Яндекс", в которой я проработал четыре года и занимался архитектурой портала "Яндекс". Наверное, именно это меня навело на мысли о собственной компании, потому что "Яндекс" развивался достаточно... не сказать "хаотично", но по факту наличия некоторых потребностей. Процессы строились не в силу осознания их необходимости, а в силу того, что упирались в отсутствие этих процессов и в живую потребность. Это не соответствовало моим идеалам, и у меня возникло ощущение, что, наверное, в мире существует более чёткое понимание того, как устроена разработка софта, и, может быть, ей можно научиться. После чего я пошёл поработать в нескольких компаниях, в том числе в одну западную, чтобы посмотреть, как это делается в тех местах, где разработка софта не вторичная часть бизнеса, а первичная. И в силу этого она более критична по стоимости, по срокам и по качеству.
- И вы решили сделать такую компанию?
- Я решил посмотреть, как это сделано у других, чтобы выяснить, какие в этом месте существуют правила и наработанные практики. И сделать такую компанию. У меня есть некоторый опыт разработки в области как веб-систем, так и многого другого. И было ощущение, что это востребовано. И действительно, так оно и есть в известной степени.
- Судя по вашему сайту, у компании достаточно загадочное и сложное занятие.
- Да на самом деле ничего загадочного. Мы действительно занимаемся портальной разработкой.
- Но написано, что вы берётесь за самое интересное и сложное, что только можете найти.
- Это действительно так. Я приведу несколько примеров, и вы увидите, что они действительно интересные и сложные, но по областям достаточно разные. Один из этих примеров - крупный портал для системы e-commerce - торгового интегратора класса "Яндекс.Маркета" (собственно, "Яндекс.Маркет" - тоже мой проект - им я занимался в компании "Яндекс", и можно сказать, что это моё детище). В нашей компании мы сделали аналогичный проект, даже в чём-то более сложный. Это если говорить про веб-направление.
Второй пример - это "Гардемарин", который с вебом никак не связан. Это достаточно серьёзный софтверный проект, он ориентирован на мониторинг судовых систем. По-другому мы его называем electronic dashboard для судна. Это достаточно современная тенденция, она постепенно вытесняет классический подход, когда существуют отдельные приборы на панели, отдельным образом соединённые с устройствами в машинном отделении. Мы их заменяем на централизованную систему, которая связана по Ethernet с машинным отделением, получает оттуда данные и отправляет управляющее воздействие. Опять же, это довольно крупная система, сложная и довольно интересная. Но к вебу никакого отношения не имеет.
Третий пример - это наша работа с "Мосводоканалом". Мы с ними разрабатываем систему, которая поможет "Мосводоканалу" быстрее реагировать на информацию об авариях и получать более точное представление о месте аварии. У "Мосводоканала" по городу есть множество датчиков, но при этом до сегодняшнего дня интерпретация показаний с них происходила в "человеческом режиме". Сидели некие опытные люди, которые знали, что, к примеру, если сработал восьмой датчик и двадцать пятый, то, скорее всего, там протечка или здесь прорвало трубу. Поскольку это эзотерическое знание очень трудно передаётся от человека к человеку, от того, какая смена сидит в диспетчерской, зависит качество реакции на информацию об аварии. Было решено реализовать систему, которая бы это автоматизировала. Сейчас у нас есть представление о том, как анализировать информацию с датчиков, есть картографическая система, которая отображает эту информацию. Анализируя известные нам паттерны аварийных ситуаций, можно давать более точные указания на то, где искать аварии. Это довольно практическая задача - свести время реакции на аварию до получаса. Это критично, важно и полезно.
Четвёртый пример - собственно, операционная система, которая находится совсем в другой области, и тем не менее - очень интересный и амбициозный проект.
- Но что вас вдруг натолкнуло на мысль делать собственное ядро ОС? Какие-то нужды по другим проектам? Неудовлетворённость существующими системами?
- О, совсем не вдруг! Эта идея зрела давно. Она - результат многолетнего опыта работы в софтверном бизнесе и довольно обширных представлений о том, что происходит в самых разных областях разработки софта, и представлений о том, как устроены существующие операционные системы. Дело в том, что в советское время, когда я только начинал всем этим заниматься, я был очень активным юниксоидом. В восьмидесятые годы я пропагандировал Unix - тогда это была сверхмодерновая, никому не известная операционная система, которая только начинала свой путь. И в мире-то начинала, а в СССР это была совсем фантастика. Я довольно хорошо её знал, был системным программистом, занимался разработкой драйверов и существенно касался ядра операционной системы.
Потом, когда появился MS-DOS, он очень сильно уступал "Юниксу". Зачастую приходилось писать программы, функциональность которых находилась в рамках компонента операционной системы. То есть, скажем, мы под свои задачи писали такие вещи как многозадачность - для MS-DOS. Причём такие вещи делал каждый десятый программист, работающий с MS-DOS. Это сложно, но вполне достижимо.
Когда мы это делали, мы понимали, какие задачи мы при этом решали и откуда такие потребности возникают. Однажды у нас была очень смешная практическая работа. Когда появилась одна из первых 386-х машин, они были бешено дорогие и никто не понимал, зачем они вообще нужны. Потому что DOS на них работал как на обычных 286-х. Разницы не было, и никто не понимал, зачем там ещё какие-то восемь мегабайтов.
У меня был начальник, который ко мне пришёл и сказал: "Слушай, ты понимаешь, что с ней можно сделать?". Я говорю, что в принципе к ней можно подключить несколько терминалов. Он говорит "Да? Здорово. А как?", я отвечаю: "можно плату такую купить, вставить процессор в неё, подключить к ней терминалы СМ ЭВМ - они ещё были на рынке, - Но операционка этого не поддерживает, ничего с этим сделать нельзя". "А можешь что-нибудь сделать, чтобы она поддерживала этот терминал?". "Могу - говорю, - могу сделать систему, которая позволяет текст на них на всех редактировать". "Здорово! Под это есть задача, давай". И мы сделали продукт, который позволял подключить восемь терминалов к 386 машине, под DOS написали многозадачную среду, в которую встроили приложения - текстовый редактор и прочую мелочёвку. Из этого получилась некоторая инфраструктура для подготовки документации. Были клиенты, которые ей пользовались. Это был некоторый прямой опыт создания - если не операционной системы, то близкой вещи, и её компоненты там присуствовали.
Дальше разработка самых разных приложений и задач в основном компонентного характера наводила на мысль о том, как бы это делать правильно, и в девяностых годах начали бродить в голове и осмысливаться первые идеи, которые легли в основу "Фантома". Я много об этих идеях говорил, общаясь с разными людьми, с сотрудниками разных крупных софтверных компаний - это интересная тема, которая обсуждалась. И где-то лет пять назад один из моих знакомых мне сказал: "Давай, Дим, ты что-нибудь уже сделаешь, потому что, вроде, интересная тема". А я очень боялся, потому что тема-то на самом деле неподъёмная и, честно сказать, не мог подумать пять лет назад, что ОС у меня будет запускаться и работать.
Я стал пробовать, делать какие-то наброски, пытаться сделать то один, то другой кусочек - посмотреть работает или не работает та или иная вещь. Компилятор вот написал тестовый, систему виртуальной памяти. Оно начало оживать постепенно и двигаться. Финальный шаг - когда я сказал себе, что эти куски мы действительно будем собирать в ядро операционной системы.
Отчасти процесс пошёл потому, что случился информационный прорыв. Мы, на самом деле, его не планировали, но уже пытались делать какое-то ядро. Полтора года назад случилась эта история с публикацией в западном журнале. Случилось абсолютно спонтанно, не планировалось вообще. У одного из наших сотрудников был друг за рубежом, он ему рассказал, что, знаешь, у нас тут ребята операционку потихонечку клепают. "Да, правда? Расскажите. Написал письмо, мы кинули ему внутренние рабочие материалы, идеи, и через неделю вылетела статья, от которой мы сами были в лёгком шоке. Эта статья была перепечатана множество раз - на сотой перепечатке мы просто перестали считать. До этого нас, конечно, воодушевляло - было интересно: японский, китайский языки, европейские языки, прибалтийские языки, дискуссия где-то в Эстонии о том, что русские подкопаются под Эстонию через операционную систему, которую они разрабатывают! Феерическая, конечно, реакция.
- Когда это было?
- Полтора года назад где-то. Зимой прошлого года. Если бы не это, может, ещё года два всё бы шло на тормозах. Но тут как-то так получилось, что мир про это узнал и среагировал не очень благожелательно. Были люди, которые говорили: "Да, здорово, интересно, слава богу, что вы так смотрите на вещи нестандартно, пытаетесь что-то сделать нетипичное". Были люди, которые говорили: "Да это всё сто раз уже было". И они отчасти правы, потому что концепцию, которая у нас есть, по частям можно найти в разных работах разных времён. Третьи говорили: "Да вообще, козлы, куда вы лезете, какие вам операционные системы, вы же там какие-то сайтики программируете". Да, понятно, что моя компания занимается разработкой веб-систем довольно много, поэтому люди говорят "сайтописатели операционку делают, да кто они такие?!". Естественного скепсиса хватает, но он и у меня вообще-то есть.
Мы люди адекватные и понимаем, что создать операционную систему, во-первых, сложно, во-вторых, крайне сложно выйти с ней на рынок, хотя бы на какой-нибудь. Тем не менее, меня много спрашивают: "Почему ты за это взялся? Насколько это всё реально?" Я отвечаю, что если бы я просто не стал бы этого делать, мне бы стало стыдно, что не попробовал.
Так что мы понимаем - это большая и сложная задача. Тем не менее, в последнее время появилось некоторое ощущение того, что наша работа действительно востребована. Во всяком случае, в некоторых ситуациях я встречаюсь с людьми, которые выражают желание либо просто попробовать другую операционную систему, либо явно указывают, что то, что мы сделали, им интересно, потому что в "Фантоме" есть те или иные специфические свойства, которые отвечают их потребностям. Причём есть люди, с которыми мы общаемся по поводу этой операционки, и они говорят: "Ребята, нас очень радует то, что она простая". Даже это уже важно.
- А можете как-нибудь сформулировать, что отличает "Фантом" от других существующих ядер?
- Конечно. У меня есть хорошая, как мне кажется, иллюстрация к этому. Почти все люди в этой стране хоть раз видели икеевскую мебель и хоть раз в жизни собирали её. Представьте себе, что вы вынуждены каждый вечер, приходя домой, собирать эту мебель, а утром снова разбирать и класть в ящики. Это иллюстрация того, как работают все без исключения современные программы. Программа в силу некоторого стереотипного мышления разработчика операционных систем вынуждена, поработав какое-то время, всё своё внутреннее представление о предмете, с которым она работает, разбирать и складывать в файлы. Это достаточно болезненный, странный и ненужный процесс. Первое, что делает "Фантом" - это избавляет программиста от необходимости этим заниматься.
Из этого проистекает достаточно много вещей - от приятных до фантастически хороших. Самая простая и очевидная - то, что в силу этого факта фантомовские программы не замечают перезагрузки операционной системы. Этому все так радуются в Firefox, который, как известно, способен запомнить состояние и при загрузке его "поднять". Но Firefox делает это вручную, а "Фантом" гарантирует такое всем работающим программам, перманентно и без какой-либо поддержки с их стороны. Выключил-включил - всё осталось как прежде и поехало дальше.
Обратим внимание на то, что чтобы это делать, Firefox при перезагрузке перескачивает данные со всех сайтов. Для моих пятидесяти вкладок это вполне ощутимо. Перезагружаешь систему, и начинается война за канал - уходят минуты на то, чтобы всё это выкачать.
Ещё вчера был отличнейший пример, я просто счастлив, что на семинаре мне его подсказали. Был человек, который занимается пожарными системами. Он рассказывает про совершенно живую ситуацию: бросок питания - миллисекундный, но вызывающий сбой на процессоре. И после этого охранная система тратит пятнадцать минут на пересчёт датчиков. С "Фантомом" после сбоя питания и перезапуска система будет иметь то же состояние, и датчики пересчитывать уже не надо.
Или вот у вас стоит система, которая занимается жизнеобеспечением больного в больнице. Бросок питания - она перезапустилась и снова должна переинициализировать своё состояние, а больной до этого может просто не дожить. "Фантом" гарантирует ей перезапуск в рабочем состоянии. Оно может быть не вполне тем же самым, что и до выключения, но начнёт система не с нуля, а с полного состояния.
Есть ещё хороший пример того, где это важно (причём я не выдумываю их - это примеры, с которыми к нам приходили люди) - компания, которая делала "Марусю". У них там три или четыре компьютера в машине, при выключении зажигания их нужно выключить, потому что иначе они сожрут аккумулятор мгновенно. При включении зажигания они должны включиться. Сейчас при включении зажигания начинается загрузка - это процесс, который занимает минуты. То, что мы делаем, для них крайне актуально. Система, которая при выключении может "сфотографироваться" и лечь на диск, а при включении подняться в готовом состоянии, - точно соответствует запросам.
Стандартный вопрос, который мне задают: "А как же hibernate?". Во-первых, hibernate требует ручного указания на то, что его надо сделать, во-вторых, он ненадёжен (мы все знаем, что с какой-то вероятностью он не поднимается), потому что это не имманентное свойство системы, а он к ней привинчен снаружи. И третье - он не спасает ситуацию, когда электричество кончилось или произошёл сбой. То есть какая-то ситуация, когда компьютер перестал работать без создания образа.
Опять же, это свойство, которое все понимают, которое вроде как является главным для "Фантома". На самом деле, нет. На самом деле, важнее те вещи, которые проистекают из этой консистентности в программной среде. Что они означают? В современной операционной системе - будь то Unix или Windows, взаимодействие двух программ очень сильно осложнено по массе причин. Во-первых, в силу того, что структура системы построена по принципу раздельных адресных пространств, и они находятся за очень толстой стенкой. Они могут общаться только, грубо говоря, кидаясь друг в друга записочками, причём "записочки" - это довольно дорого, и в эту записочку не запихнёшь сложные структуры, которыми оперируют современные программы.
Во-вторых, нельзя установить долговременные отношения между программами. Оба приложения запускаются и останавливаются. И это обычное дело. Поэтому нельзя сказать "я с тобой буду дружить надолго", потому что он умрёт через пятнадцать минут и запустится уже в другом качестве. Это будет другая копия этой программы, с ней нельзя работать так же. Очень простой пример - запуск Photoshop. Он запускается и начинает сканировать шрифты, плагины, цветовые профили и всё это дело инициализирует при каждом запуске. Почему? Потому что среда не персистентна, он не может просто запомнить указатель на какой-то объект и потом снова пользоваться. Объект может пропасть, не пропасть, его нужно загрузить обязательно. "Фантом" представляет собой среду, в которой "Фотошоп" мог бы один раз найдя шрифт, потом мгновенно запускаться и сразу начинать им пользоваться, имея непосредственный указатель на этот самый шрифт.
- Не нужно ли проверить, не исчезли ли шрифты?
- Они не могут исчезнуть в "Фантоме" в силу того, как работает система сборки мусора. Пока существуют те вещи, которыми пользуются, они будут оставаться. Это вторая интересная особенность "Фантома". Если заглянуть в папку временных файлов любой Windows через год-два работы системы, то выяснится, что там миллионы страшных вещей, которые просто так валяются.
- Хорошо, но если я захочу стереть шрифт?
- Тут вот какая штука. Дело в том, что в той схеме, в которой работает "Фантом" шрифт - это объект, находящийся в рабочем пространстве системы, на который есть ссылка, во-первых, из каталога, в котором он лежит как видимый пользователю, и, во-вторых, из всех тех мест, которые им пользуются. Поэтому если вы сотрёте, он пропадёт из каталога, но пока им пользуется хоть одна программа, он будет фактически присутствовать. Скажем так, пока он будет присутствовать в документах - он будет существовать. Как только исчезнут все документы, которые им пользуются, он будет автоматически уничтожен. И это относится ко всему, что существует в системе. Если поставили новую версию чего бы то ни было, старая версия исчезнет сама, как только в ней исчезнет необходимость. И напротив, она не сможет исчезнуть, убив работу какой-нибудь программы, пока программа в этом нуждается. То есть у пользователя нет возможности испортить работу среды, сломав что-нибудь руками.
- Как на практике происходит это сохранение состояния? Система просто сохраняет всё на диск время от времени? Или как-то более хитро?
- Люди, которые занимаются операционками, довольно быстро понимают, как всё это устроено. Простыми словами рассказать это сложно, но давайте попробую. Дело в том, что состояние на диске уже лежит. В момент сохранения снэпшота происходит запись только тех данных, которые изменились с момента предыдущего снэпшота. Как правило, для обычной системы их не много. Это означает, что снэпшоты можно делать достаточно часто, а при сбое система восстановит состояние довольно близкое к тому, что было раньше.
- А программа сама контролирует, когда её объекты сохраняются?
- Нет. Этого программе вообще не видно. С точки зрения программы, она существует в системе, которая живёт вечно - для неё ничего не меняется. Я полагаю, что современные операционные системы требуют слишком обширных знаний от разработчика, и стремлюсь сделать систему, в которой многие вещи делались бы настолько прозрачно и незаметно, что просто не требовали бы даже думать о них. Это одна из причин, почему ОС называется "Фантом". В "Фантоме" автор программы вообще не должен знать, что такое диск. Он её просто пишет, она просто существует. И часть задачи просто отпадает.
Скорость, с которой система делает снэпшоты, регулируется. Можно сказать - раз в минуту, можно - вообще непрерывно. Закончился один и сразу пошёл другой. Более того, у нас есть желание сделать версию для специальных применений, в которой это будет делаться со скоростью порядка миллисекунд. То есть система будет хранить очень подробную запись того, что происходило, по методу журналирования. Раз в минуту будут делаться полные срезы, а между ними будет вестись список частых изменений. Это позволит получить на обычном "железе" систему, которая сможет восстанавливать очень близкое к моменту сбоя состояние. Но принципиально программа для этого ничего не должна делать.
- Эта непохожесть "Фантома" на другие среды означает, что старые компоненты систем Unix нельзя будет использовать? X Window, к примеру, или OpenGL.
- Вовсе нет. OpenGL у нас даже в каком-то виде сейчас есть в системе. В довольно сыром, правда.
- И это не собственная реализация, а оригинальный код, скомпилированный под "Фантом"?
- Да. Здесь есть две стороны жизни: есть объектная персистентная среда, которую "Фантом" предлагает в качестве родной. Под неё мы собираемся построить способ миграции, который позволил бы втаскивать на неё код, написанный на современных языках - на Java, Python, C#. Это очень большой объём кода, и он, на самом деле, превосходит то, что сделано для Unix. Мы считаем, что это основное направление, в котором нужно двигаться. Конечно же, мы не хотим сделать систему, для которой всё придётся писать заново. Это не оставило бы мне абсолютно никаких шансов.
С Unix ситуация вот какая. Изначально вообще не планировалось поддерживать юниксовый код, потому что родная среда "Фантома" не позволяет поддерживать старые языки программирования - такие как C и Pascal. Есть очень чёткое разделение: есть managed языки и не-managed языки. Managed-языки мы напрямую не поддерживаем. Это совершенно не проблема для современной разработки, потому что сейчас всё делается уже на managed-языках. Но есть довольно большое количество старого кода, написанного на C, на Pascal, на C++.
Изначально я предполагал, что им не нужно заниматься, ещё и потому, что за то время, которое мы будем делать стабильную версию "Фантома", мир ещё раз шагнёт вперёд, и всё старое наследние окажется совершенно неактуальным. Тем не менее, в сегодняшней стадии в "Фантоме" делается Unix-подсистема, которая позволит запускать под ним более или менее немодифицированный Unix-код, хотя X Window мы, наверное, не будем туда затаскивать.
- То есть будет собственная оконная система?
- Да. Она уже в какой-то степени есть, и не так уж много кода X Window, который было бы интересно в неё тащить. А делать X Window - это довольно серьёзная задача, которая, я боюсь, не окупится. Ну и, кроме того, есть довольно много кода, написанного под вещи типа SVGALib, который вполне можно портировать под "Фантом". То есть framebuffer и прочие инструменты обмена мы сделаем.
- Но программы, написанные под X Window, придётся модифицировать?
- Придётся модифицировать, да. В текущей ситуации мы не видим достаточной необходимости делать эту часть работы. Мы больше ждём, что программы, написанные за последнее время будут реализованы скорее для Java SWING, чем для X Window.
- Но у такого подхода должны быть и плюсы. Вы говорите, что под "Фантом" легче писать программы. Легче и дешевле. Кроме сохранения состояния это в чём-то проявляется?
- Это дешёвая компонентность. Собственно, вся история программных инструментов, если взять некоторую стартовую точку - когда появился первый компьютер и за него сел первый программист, написал для него первую программу. (Эта программа была написана в некоторой модели, в которой есть только этот программист, только эта программа и этот компьютер, который полностью ей отдан.) Начиная с этой точки и до сегодняшнего дня всё, чем занималось программистское сообщество - это развитие модели, при которой программист может писать меньше и использовать больше чужого. Современные языки программирования, языки программирования вообще, библиотеки, фреймворки, операционные системы - всё это было сделано для решения ровно одной вещи - сделать так, чтобы можно было написать три строки кода, а 333 строки были бы чужими. Это делается всегда ровно одним способом (хоть он и по-разному реализован в разных местах) - дать программисту компоненты, которые он воткнёт в свою программу.
Собственно, я считаю, что успех Unix как операционной системы связан в первую очередь с тем, что Unix предложил возможность сборки утилит командной строки в "пайпы". Таким образом он породил первую командную среду в истории разработки софта. Хоть до него и были библиотеки, но он стал первой средой, где этим мог управлять пользователь. То есть можно взять две вещи, написанные разными людьми, и склеить их воедино, чтобы решить свою третью задачу. Причём, опять же, это не некоторая абстракция. Даже в те годы в ЦСУ СССР была реальная разработка под Unix, для которой использовали утилиты командной строки. Там была обработка статистики, которая делалась этими "грепами", "сортами" и прочими утилитами, которые позволяли данные, представленные в виде текстовых табличек как-то обсчитывать, форматировать и печатать.
То, что мы делаем - это новый шаг в ту сторону; он отличается от того, что существовало, благодаря глобальному адресному пространству. Мы говорим, что всё, что у нас есть в системе, можно использовать. То есть можно достучаться до чужих данных (с учётом желания того, кому они принадлежат, их вам отдать, конечно - в этом смысле "Фантом" система очень защищённая), но если две программы желают обменяться данными, то это можно сделать очень дёшево, очень эффективно и с произвольной степенью сложности.
В современных системах это просто невозможно. Грубо говоря, если работает программа Word, в которой существует документ, представленный в виде некоторого графа объектов, поделиться фрагментом этого графа объектов с другой программой Word не сможет. Потому что видим граф только в рамках одного адресного пространства. Word может его сериализировать, свернуть, засунуть в какую-нибудь трубочку, передать через "пайп", но это всё тяжко и требует того, чтобы обе программы понимали один протокол. Ну, к примеру в Windows есть протокол OLE, который такие возможности предоставляет. Но программ, которые его поддерживают, мало, потому что он сложный. И все такие протоколы сложны. Второй пример - это CORBA, который вообще шикарный инструмент - он платформонезависимый, но примеров его реального использования - единицы, потому что это сложно.
Та же задача в рамках "Фантома" решается одной единственной строкой кода: передачей указателя на произвольную группу объектов. После чего они напрямую доступны во всей своей сложности. То есть сложность этого "интерконнекта" мы понижаем не просто в разы, а на порядки. Мы ожидаем, что это даст существенный эффект.
Видно, что на сегодня потребность в компонентной среде велика, это решают почти все современные инструменты. Если взять сообщество Java, то оно этому посвящено почти во всех своих направлениях. Можно взять другую часть мира - Windows, C# и инструменты, которые существуют для него, - они тоже направлены на это.
- Не похоже ли это на среду Smalltalk?
- Похоже. Очень похоже. Вы абсолютно правы, это так и есть.
- Но в качестве отправной точки была избрана именно Java?
- Нет, у нас среда как раз языкоагностическая, мы не завязаны на Java. Просто Java Virtual Machine на сегодня используется для очень большого количества современных языков - более 200 языков имеют трансляторы в JVM, а это значит, что если поддержать её, то мы поддержим и это огромное количество языков. Для нас это будет наиболее эффективным путём. Поэтому дело не в самой Java, а в виртуальной машине.
- Как я понял, разработка "Фантома" пока находится на очень раннем этапе. Ядро ещё не устоялось?
- Год назад я бы сказал, что ещё на очень раннем этапе. Сейчас у меня у самого возникает ощущение, что мы уже существенно ближе к реальности. Ядро - не сказать "не устоялось" - в нём есть много вещей, которые требуют доработки, переработки или просто развития, но "не устоялось" сказать уже нельзя. Потому что если говорить про среду исполнения прикладного кода, то за последний год она не изменилась ни на байт. То есть, вообще говоря, устоялось именно с точки зрения внешнего интерфейса. От него мы существенных изменений уже не ждём.
- И вы уже не боитесь, что в погоне за идеалами окажетесь в той же ситуации, что и Столлмен со своим Hurd?
- Как вам сказать... Конечно, боимся. Это, кстати, ещё одна из причин, по которой я начал делать систему. Сложность того, что я сейчас про неё понимаю, превысила возможность головного мозга, она сегодня в него уже не вмещается. До какого-то уровня я понимаю, как и что в ней происходит, а дальше - нет. И поскольку проверить это хочется, её пришлось сделать, чтобы понять, что будет дальше.
Конечно, я могу предсказывать будущее только на какую-то глубину, а дальше может выясниться, что есть вещи, про которые я не подумал, и они каким-то образом всё загубят. Но на сегодня я таких вещей не вижу.
У нас была одна очень крупная проблема, которая меня поставила на грань вопроса о реализуемости проекта - это было год назад, и мы это место прошли. На сегодня я не знаю ни одного принципиального момента, который мог бы сделать эту задачу нереализуемой. Есть, конечно, вопрос о том, в правильном ли направлении я вообще двигаюсь. Вдруг никакого будущего у проекта нет? Думаю, что это не так.
Я абсолютно уверен, что я двигаюсь в правильном направлении - этому можно привести довольно много аргументов. Наверное, самый вразумительный из них - это то, что компания Microsoft движется в том же направлении. Я думаю, что ни у кого в этом мире нет сомнений в том, что компания Microsoft знает, где искать деньги в разработке софта. Про то, что они делают, можно говорить самые разные вещи, их можно ругать или хвалить, говорить, что есть не очень удачные инженерные решения среди принимаемых ими, но Microsoft как одна из крупнейших компаний, занимающихся разработкой софта, чётко понимает, что и как устроено с точки зрения бизнеса, где дешевизна, и как до неё добраться. То, что мы с ними существенно совпадаем, убеждает меня в том, что я прав.
Здесь, как мне кажется, правильной будет такая метафора: если какой-то человек вдруг скажет, что знает, как сделать производство автомобилей на тридцать процентов дешевле, к нему сразу же подбегут человек сто с разных сторон, попытаются порвать его на куски, и кто-нибудь один да утащит его в "Тойоту" или в "Форд", чтобы он сделал то, что хотел. Потому что все понимают, что тридцать процентов дешевизны - это значит убить весь рынок и съесть всех. В софте ситуация несколько мягче, но, тем не менее, она тоже критична.
Ещё один пример - когда лет десять назад появилась Java (как язык программирования), производительность программ на Java была катастрофически хуже, чем производительность программ на C++. Что не помешало Java "вынести" C++ просто с корнями. Можно считать, что C++ сейчас не существует, а Java сегодня - язык номер один. Если Java сегодня кому-то и сдаёт, то только C#, который, в общем-то, в существенной степени является её клоном. Почему это случилось? Потому что Java дала при провале на старте по скорости (сейчас она его уже наверстала) существенные преимущества по скорости и дешевизне разработки. И это решило спор в её пользу. Я полагаю, что у принципов, которые лежат в основе "Фантома", те же самые шансы.
Это направление более или менее неизбежно. По крайней мере я не вижу ни одного конкурента ему - ни у нас, ни у Microsoft, ни у кого бы то ни было в мире. А уж выиграет при этом "Фантом" или другая ОС того же класса - это, к сожалению, вопрос зависящий больше от финансирования, чем от идеи.
- Хорошо, про то, какие преимущества "Фантом" даст встроенным решениям, вы уже сказали. С серверами ситуация сложнее?
- На самом деле, нет, не сложнее. Вторая область, где мы можем показать преимущества "Фантома" в ближайшее время - это как раз серверы. То есть какие-то веб-системы, причём распределённые. Современные программирование уже не предполагает обособленных программ. Почти всё, что сейчас делается - это вещи, которые так или иначе ввязываются в существующую инфраструктуру. Достаточно зайти на любой проект, чтобы увидеть кнопочки "Твиттер", "Фейсбук", "Живой журнал" и т.п. Это простой пример того, что обособленно жить уже нельзя - всем требуется среда, которая легко поддерживает не просто компонентное программирование, а уходящее во врешний мир.
Мы считаем, что здесь у нас есть хорошие шансы, особенно - в разработке не очень масштабных систем. Условно - систем, которые делаются на коленке тремя программистами. То есть небольшие разработки, которые, как правило, сегодня делаются на PHP плюс MySQL. Здесь мы можем предложить PHP без MySQL. PHP и MySQL популярны, потому что их легко изучить. Если выкинуть MySQL, изучать будет ещё вдвое легче. В этом месте у нас есть шансы, хотя есть и конкуренты. Существуют среды, которые реализуют сходную с "Фантомом" персистентную функциональность не в рамках ОС, а в рамках отдельного приложения.
- Можно ли "Фантом" применять для распределённых вычислений и виртуализации?
- Можно, конечно, загнать под него монитор виртуальных машин, но я не вижу больших причин этого делать. Я не вижу особых проблем в мире виртуализации - там всё хорошо, и нам помогать нечему. Хотя к нам приходил как-то человек, который рассматривал "Фантом" как некоторое средство виртуализации, и в некотором смысле мы и будем им являться, потому что среда Linux в "Фантоме" отчасти имеет характер виртуальной персистентной среды.
Та среда Linux, которую мы собираемся сделать - она будет отличаться от обычного Linux тем, что запущенные в ней программы не будут "видеть" перезагрузки операционной системы. Это попытка сделать очень совместимую на уровне исходного кода среду, но при этом с плюсами "Фантома".
Однако когда я говорил про среду разработки в рамках нескольких компьютеров, я имел в виду несколько другое. Мы хотели бы в рамках "Фантома" реализовать достаточно прозрачный механизм дистанционного доступа к объектам на другой машине и миграцию объектов.
Я приведу пример, который в "Фантоме" можно будет реализовать не скоро, но идеологически он достижим. Вы садитесь за компьютер и начинаете работать с некой программой - не важно какой - к примеру, рисуете в CAD-е какой-нибудь проект. Он реализован как множество объектов, которые описывают проектируемую вами систему, вы видите в окне представление этой системы и работаете с ним. Поработав, вы собираетесь поехать на дачу. Вы берёте окно (подчёркиваю - окно!), кладёте его в письмо и отправляете себе на дачный компьютер. Когда вы приезжаете туда, вынимаете из письма окно, и начинаете с ним работать. Но при этом окно у вас здесь, а объекты - там.
К тому же компьютер вполне в состоянии обнаружить, что ситуация изменилась, и те лежащие дома объекты на самом деле используются с дачи. Среда в состоянии передать их вам. По мере того, как вы будете с ними работать, они будут переползать на машину, с которой вы работаете. Если вы долго проработаете, они соберутся там. Уехали в Швейцарию к другу? Они приедут за вами по мере необходимости.
Это, кстати, ответ на вопрос о том, не выйдет ли завтра так, что стоящий на рабочем столе компьютер не будет ничего содержать, а всё станет жить в сети. Может быть. Но к этому мы тоже в известной степени готовы. К тому же, какая бы сеть хорошая ни была, всё же близко находящееся эффективнее, и эта схема миграции кажется мне осмысленной и актуальной.
Даже если что-то живёт в сети, давайте мигрируем к вам то, чем вы реально сейчас пользуетесь. Поработаете с этим, дальше оно прозрачно уедет обратно. Не обязательно заставлять программу бегать непосредственно на дальний компьютер за каждым обращением к объекту. Если вы с ним работаете, можно принести его, поработать и вернуть обратно. Это достаточно эффективно - и с точки зрения нагрузки на каналы, и с точки зрения реактивности работы программ.
- Наш разговор плавно перешел к настольным применениям, но я бы сперва хотел поговорить о портативных устройствах. Сейчас активно обсуждается, как должна быть сделана многозадачность на устройствах с ограниченным количеством памяти и энергии. К примеру, в iOS 4 используется хитрая схема, позволяющая программам сперва замораживаться, затем закрываться, когда памяти не хватит. Если бы использовалось ядро "Фантома", это можно было бы сделать легче и очевиднее?
- Дело в том, что то, что вы сейчас описали, совершенно штатная ситуация для "Фантома" - там для этого не нужно предпринимать никаких специальных усилий. В отличие от Unix и Windows, в которых существует выраженные отдельные состояния запущенной и незапущенной программы, в "Фантоме" эти состояния размыты и неотличимы друг от друга с точки зрения внешнего наблюдателя. Программы переходят из более активного состояния в менее активное просто по факту того, работают они или нет. Если программа реально не работает, то подсистема виртуальной памяти "Фантома" по мере необходимости в оперативной памяти постепенно вытеснит её в дисковое состояние. Для этого не нужно ничего делать - всё происходит само собой.
То есть то, что сейчас делают разработчики мобильных ОС, у нас есть и так. Кстати, одна из причин, по которой я так уверен в правильности концепции "Фантома", - в том, что очень много частных задач здесь решается в силу естественных свойств системы. Это меня очень мотивирует. Это критерий правильности проектирования базовой идеи "Фантома".
"Фантом" - это же, собственно, программы, которые постоянно и живы и мертвы. Они лежат на диске, но как только они попытаются поработать, то непосредственная попытка обращения к программе приведёт её в оперативную память. Она может поработать частью, и именно эта часть загрузится и поработает. Как только памяти станет мало для программ, и какие-то программы станут пассивными, они вытеснятся из оперативной памяти непосредственно стандартным механизмом планирования ресурсов компьютера.
Единственное, что в случае мобильного устройства таки нужно делать - это, собственно, принимать решение о том, работает программа или нет. С этим ничего не поделаешь - это либо какое-то волюнтаристское решение операционки о том, что какая-то программа слишком много "ест", и давайте её приостановим (но это именно приостановка, а не выгрузка - выгрузка случится сама), либо это решение самой программы о том, что она находится в стеснённой ситуации и лишнего потреблять не должна.
- Переходя к десктопному использованию, представим, что "Фантом" сможет его добиться, и немножко помечтаем. У дизайнеров интерфейсов есть несколько давних мечтаний - что хорошо бы было сделать, но тяжело, и не понятно, кто бы мог это сделать.
- Если вы знаете этих дизайнеров, гоните их ко мне - с удовольствием с ними поговорю. К сожалению, на сегодня видел очень мало людей, у которых есть хоть сколько-нибудь сформулированные мечтания. Общеизвестный Раскин - это наиболее цельный пример. Хоть его представления и находятся на очень глобально-абстрактном уровне.
- Давайте я перечислю наиболее известные примеры, а вы скажете, может ли в этих случаях "Фантом" чем-нибудь помочь. Первое - это избавление от иерархической файловой системы.
- О да! Спасибо вам за этот вопрос. Это же просто мучение, ужас и кошмар. Да, конечно, может, очень хотим и обязательно сделаем. Но здесь есть некоторые проблемы. Во-первых - совместимость с предыдущим поколением пользователей, для которых мы, конечно, стандартное дерево оставим.
Но при этом смотрите, что происходит в "Фантоме": здесь нет файлов, зато есть объекты. Объекты отличаются от файлов прежде всего тем, что для них можно определить методы - то есть давать им возможность сказать системе, что с ними ещё можно сделать. К примеру, их можно искать по другим критериям; например, их можно по-другому классифицировать, и не одним способом классифицировать.
Даже если брать совершенно прямолинейный уровень: как родным для "Фантома" способом сделать приложение? Приложение - это некоторый класс, реализующий некоторую функциональность. И объекты этого класса являются документами с точки зрения пользователя. Уже сам этот факт означает, что вы можете одним движением найти все документы такого типа.
Мало того, в рамках этих документов вы можете построить свою иерархию и классификацию и потом работать с ней. Если это документы CAD (простой пример из известой области) для разработки схем и прошивок для ПЛИСов - в ней есть своя классификация: печатные платы, схемы, компоненты схем, библиотечные элементы. Операционка про это ничего не знает, но в рамках модели классов этого продукта это представление есть и его можно использовать. То есть можно не имея в операционке никакого знания о том, что бывают печатные платы, схемы и прочие вещи, сказать ей: "Знаешь, у меня тут есть дерево классов, такой-то CAD, а в нём есть такой подкласс - печатные платы, найди мне эти объекты". В данном случае используется некоторое штатное свойство операционной системы, которое не проектировалось специально под эту задачу, но оно есть и оно отражает эту задачу - что меня, конечно, очень радует.
- Но действительно ли пользователям необходима иерархическая структура данных? Логично было бы каждый вид данных хранить наиболее подходящим для него образом...
- Да, но многие люди бесятся и говорят: "Дайте мне файл, я хочу его потрогать". Я бы не хотел их этого лишать. Но в отличие от Windows и Unix, где объект не может не лежать в файловой системе, в "Фантоме" решение об этом принимает приложение. Оно может взять и скрыть от системы именования свои объекты, если считает это удобным и правильным или если это полезно с точки зрения безопасности. Одна из причин, почему в Windows так хорошо живут вирусы (да и в Unix проблема та же) - это собственная файловая система, где можно просканировать всё, что есть. "Фантом" позволяет не показывать то, что программа не хочет. При этом объект существует, доступен тому, кому он нужен по указателю и больше никому. Я полагаю, что это достаточно важный факт с точки зрения защиты от вирусов. У "Фантома" есть и другие свойства, которые сильно осложняют жизнь злоумышленникам.
- Следующая мечта - исчезновение (с пользовательской точки зрения) разницы между оперативной памятью и диском. Это бы отменило необходимость сохранять то и дело свои данные. "Фантом" от этого избавляет?
- Да, "Фантом" здесь больше всего похож на листочек бумажки - вы написали что-то - оно осталось. Хотите копию - сделайте копию. А вот команда Save здесь не нужна по определению. Даже больше скажу - в "Фантоме" нет разницы между иконкой и окном. То есть иконка, документ и окно - это, вообще говоря, одно и то же. Наличие окна, которое показывает содержимое документа - это всего лишь вопрос состояния hide или unhide. По сути дела, окно - это увеличенная иконка.
- То есть можно сделать раскинский zoomable-интерфейс?
- Да-да-да! Это в существенной мере движется именно в эту сторону. Я как раз про это и говорил - в Раскине меня как раз смущает то, что у него есть хорошее представление о том, что он хотел бы видеть, но нет хорошего представления о том, как это положить на реальную софтверную среду. У нас это представление, кажется, даже есть. Оно не вполне однозначно ложится на идеи Раскина, но я в целом вполне разделаю его мечты.
- Далее - разница между запущенной и незапущенной программой. Она тоже, как я понимаю, стирается?
- Да, в "Фантоме" это делается естественным образом. Как только программу перестают беспокоить, она перестала быть запущенной. Начали снова с ней что-то делать - она продолжила работать с того места, где её оставили. Собственно, это к тому же вопросу об иконке, документе и окне. Есть документ, состояние которого присутствует, и если убрали окно, это ни на что не повлияет. Документ останется в прежнем состоянии.
- Последнее - это возможность отмены любого пользовательского действия.
- Здесь система как таковая, к сожалению, ничего предоставить не сможет. У нас есть представление о том, как это можно сделать в рамках реализуемой объектной среды, но уже с некоторой потребностью от программиста предпринять некоторые усилия. Даже не столько усилия, сколько необходимость делать свои приложения некоторым определённым образом. Грубо говоря, если он использует немодифицируемые объекты и применяет функциональный стиль, то более или менее автоматом получается некая среда, в которой можно возвращаться к предыдущему состоянию. В этом месте мы не даём готового решения, но мы говорим, что если в нашей среде придерживаться определённых правил, это будет получаться дёшево и легко.
- Давайте теперь вернёмся к реальности. Какие короткосрочные перспективы стоят перед проектом?
- У нас сейчас достигнута ближайшая цель получить стабильно работающее ядро, в котором хорошо работают снэпшоты, в котором чётко отслеживается перезагрузка. Сейчас есть нормальное, хорошее ядро, разработку которого можно при желании и остановить, и это будет приемлемо. В ядре есть некоторое количество вещей, которые нужно обязательно доделать - они касаются некоторых тонкостей восстановления системы. В системе есть такие места, которые должны быть проинформированы о перезагрузке, и это место пока что не реализовано. Как только пройдём его, разработка ядра будет приторможена.
Следующая задача - сделать пользовательскую среду, для которой которой было бы удобно писать программы. То есть главная стоящая сейчас перед нами задача - сделать релиз, на котором средний программист мог бы уже что-нибудь написать. Строго говоря, этот релиз у нас уже есть, но человеку потребуются усилия на то, чтобы продраться через наши инструменты - способы склеивания кода, миграции, сборки. Не сказать, что они сделаны плохо - просто так, как того требовала текущая ситуация.
Ещё одна вещь, которая сейчас не готова - это графическая подсистема, которая на сегодня реализована только в ядре и почти никак не доведена до пользовательского уровня, и в ней не реализованы некоторые примитивы, которые необходимы в реальной жизни. К примеру, нет примитива, позволяющего подвинуть окно или изменить его размеры. Без этого в режиме демонстрации можно жить, но в реальной жизни хотелось бы, чтобы оно было. Вот такие вещи нужно отработать, и после этого мы бы хотели, чтобы у нас случился релиз, про который мы бы могли сказать "да, интересующийся разработчик может это взять, собрать, попробовать, запустить, написать под это какую-нибудь программку".
Для нас это важно не потому, что под "Фантом" начнут писать (всё же пока что довольно рано для этого), мы бы хотели выйти на каких-то заинтересованных разработчиков, чтобы получать отклик. Чтобы понимать, что в системе ещё сырое, что требует доработок, что неудобно или глупо сделано. И после этого следующий релиз мы бы хотели рассматривать как продакшен.
- Как я понимаю, есть и мысли о коммерческом применении?
- Конечно. Опять же, мы адекватные люди, мы не делаем операционную систему только из желания покрасоваться. Конечно, мы хотим, чтобы у "Фантома" было коммерческое применение. Есть некоторые направления, в которых ощущаются такие потребности. Есть три группы людей, которые в какой-то перспективе объявили о своём интересе. Это всё российские разработки, из совершенно разных областей. Их авторы обращаются к нам по совершенно разным причинам. Мотивация у них, надо сказать, бывает диаметрально противоположенная.
- А за рубежом, несмотря на шум в западной прессе, не интересуются?
- Интересуются, конечно. Я получил тысячи писем из-за рубежа от самых разных людей разного уровня, с разными словами. Как правило, публично ругают много, а в письмах только хвалят. Некоторое количество писем получил от людей из серьёзных компаний типа IBM, которые занимались сходной разработкой и указали на места, которые им кажутся проблемными или рекомендовали другие подходы.
Некоторые из этих писем действительно помогли. Не сказать, что мы бы без них не справились, но опыт всё же полезен. Были люди из университетов, которые предлагали как-то поучаствовать, но, к сожалению, мы слишком рано зазвучали. Тогда у нас практически вообще ничего на руках не было такого, что можно было бы отдать. Я с ними со всеми переписывался, но говорил, что по-настоящему общаться мы будем через годик-другой. Пока что все эти полтора года я эти каналы не трогаю осознанно, потому что хочется показать людям что-нибудь такое, что их бы не демотивировало.
- Но сейчас выйдет первый релиз, и команда сможет вырасти с пяти человек до большего количества?
- Я не знаю. Надеюсь. Мне очень трудно предсказывать. Пока что наш опыт показывает, что из десяти людей, выказавших желание поучаствовать, только двое чем-то помогают.
- Почему для "Фантома" выбрана именно лицензия LGPL? Это идеологический вопрос?
- К GPL я отношусь очень плохо. Наверное, для кого-то это правильно, но я считаю, что нужно либо что-то отдавать по-настоящему, либо держать при себе и никому не показывать. Ситуация, когда ты говоришь "я отдам, но только если вы тоже будете отдавать" мне неприятна - я не люблю людям руки выкручивать и очень не люблю, когда их выкручивать пытаются мне.
На практике я говорил с многими людьми из крупных компаний, которые занимаются разработкой софта и готовы были бы применять чей-то чужой код. Они говорят "GPL - нафиг! Мы совершенно не хотим вляпываться в эту проблему". И существует очень большое количество кода LGPL, который используется коммерчески и много кода GPL, который используют только в среде GPL. Получилось два разных мира.
Мне будет куда приятнее, если мой код будут использовать бесплатно чем если он потонет в пучине веков. Поэтому - LGPL. Кроме того, примеры таких проектов как MySQL, который долго был публичным, а потом стал коммерческим, нас несколько поддерживают, и мы не считаем, что открытие кода убьёт наши шансы на коммерческое использование.
- А какие вообще бизнес-модели рассматриваются для "Фантома"?
- Первое - это бесплатная система плюс консалтинг или выпуск специфических версий под потребности заказчика. Вторая - базирующиеся на открытом коде специфические реализации под определённого клиента, закрытые под него. То есть базовый код, который лежит в LGPL и доработка и изменения, сделанные под конкретную ситуацию. Есть потенциальный клиент, с которым такая ситуация рассматривается. У него своё аппаратное обеспечение и свои проблемы.
- На вашем сайте упомянута ещё и возможность сделать что-то вроде Amazon EC2.
- И такой вариант мы рассматривали. Это предоставление через Amazon, где для этого есть инфраструктура, создание образов, на которх человек может свой проект поднять и запустить.
- Именно Amazon?
- Мы рассматриваем Amazon, потому что мы с ним работаем в нашей коммерческой деятельности - в рамках разных проектов DZ. Просто мы о нём много знаем. Это не какой-то принцип, мы можем потом использовать другую среду.
- И какого уровня решение в итоге получится? К примеру, в Google App Engine достаточно закинуть только свой код, а Amazon и Azure дают лишь виртуальные серверы ("инстансы"). Фантом добавит к EC2 что-то более высокоуровневое?
- С нашей точки зрения, это инстанс, на котором запускается ядро ОС "Фантом", позволяющее положить в себя пользовательское приложение и гонять его на "Амазоне" как SaaS или какое-то дистанционно-доступное решение или просто веб-систему. Возможно, что к собственно "Фантому" мы прибавим ещё какой-нибудь фреймворк, который облегчит создание таких вещей. Это, в принципе, рассматривается как часть плана разработки "Фантома".
- Как при этом будет выглядеть монетизация?
- У Amazon есть поддержка этого, он сможет просто делиться прибылью с разработчиком среды. Если вы сейчас запускаете Linux - это стоит одних денег, если запускаете Windows - прибавится некоторая копеечка для Microsoft (причём довольно заметная). Мы будем претендовать на заметно меньшую.
- Фото: Алексей С. Ющенков.
Комментариев нет:
Отправить комментарий