Comments 119
Приложения работают в общем адресном пространстве, такое решение дает возможность обойтись без переключений между ядром и приложениями.
и
Базируется операционная система на управляемом коде и концепции персистентной виртуальной памяти.
Интересно как память виртуализируется, если пространство общее, и как реализована защита процессов друг от друга?
Процессы не работают напрямую с адресами памяти а только с объектами. Перечислить или как то получить объекты другого процесса не представляется возможным.
Это в теории, а как на практике устроена защита? Архитектура "колец защиты" в современных процессорах реализована хардварно. Неужели она никак не используется?
Отчего же не используется, используется, как минимум для защиты драйверов друг от друга, реализации уровней самой операционной системы.
Архитектура процессора для фантом-ос не имеет никакого значения. Считайте что API для OS это Java-машина и глубже вы никуда не можете проникнуть на уровне пользовательской программы.
К этому всему великолепию прилагается персистентность данных программ. Сразу отпадает такой атавизм как файлы данных для хранения результатов и промежуточных состояний программы.
Программа оперирует объектами-данными не имея нужды сохранять/загружать своё состояние из каких то файлов.
А просто порождая нужные и удаляя ненужные объекты.
О всём остальном заботится операционная система. делая снимки состояния процессов и сохраняя их на диск или в сеть или в любое другое энергонезависимое хранилище.
Идея сделать оригинальное API для операционной системы были не единожды, навскидку могу вспомнить планшет ASUS Eee Note, у которого всё API это Qt фреймворк.
это Java-машина
Написанная на ...? Собственная разработка или адаптированный HotSpot?
персистентность данных программ
А если софт банально вошел в неисправимое состояние? "Семь бед - один reset", помогает на практике. Без возможности сбросить внутреннее состояние софта, без адекватного контроля за местами сохранения этого состояния - софт становится неуправляемым.
Сразу отпадает такой атавизм как файлы данных для хранения результатов и промежуточных состояний программы
<sarcasm>Иногда бывает хочу файлик закинуть на флешку/телефон/облако, а потом как вспомню, что атавизм, все желание пропадает</sarcasm>. Так это работает? :) Вокруг реальный мир, в котором люди к файлам привыкли: сохранять, копировать, шарить в конце концов. Как без них?
Видимо неспроста в прошлый раз был холивар по теме, как подметил @dartraiden
Сарказм это хорошо, но кто мешает представить любой "файл" на любом носителе как объект? ЕМНИП это было ещё в OS/2.
Файлы и файлоориентированность современных ос это тяжкое наследие из прошлого века. Это факт.
Я помню что одно из преимуществ данного подхода, это отсутствие необходимости сериализации, типа в современных программах save/load занимает приличный процент кода.
Но ведь это все равно придется делать, потому что кроме внутреннего представления данных в программе, нужно же это дело как то отправлять по сети и пр.
Некоторые вообще вот так делают: https://github.com/emilk/eframe_template/blob/master/src/app.rs#L4
Вам и @impwx: давайте разбираться, о чем ведем беседу. Файлы устарели или способ работы с файлами устарел? Сами по себе файлы как сущности в окружающем нас информационном пространстве никуда не денутся в обозримом будущем. При этом с ними и правда можно работать абстрагировавшись некоторым объектным менеджером. Но атавизмом такой подход файлы не делает. Надеюсь, удалось донести мысль.
P.S. А что по остальным вопросам?
Да, имелись ввиду файлы как последовательность байт.
Ведь, согласитесь, сохранять сложную и разветвлённую структуру состоящую из множества объектов, контейнеров и зависимостей в последовательность байт -- ещё то удовольствие.
Ещё меньшее удовольствие во всей этой сериализации -- сохранять обратную совместимость.
Поэтому не проще ли вообще отказаться от самих понятий -- "сохранить в файл", "сериализовать в поток или в строку"?
Программа создавая объекты не будет беспокоиться о том, чтобы их куда-то сохранять или преобразовывать для передачи, а будет просто их создавать, ими манипулировать, передавать по сети, экспортировать доступ другим программам, удалять в конце концов?
Да, файловая система UINX, NFS, /proc и /dev это был прорыв в файловых системах. Но сами файлы и необходимость сериализации никуда не делись. Т.к. файл это не объект и не может содержать ссылок на другие файлы(объекты), а если и может то это уже не файл а (под)каталог.
Вот мне пришло на почту "КомерческаяЗаявка._слепок_памяти_состояний_.".
У меня обычная, рядовая ОС. Как мне открыть творчество ПрогрессивнойПродвинутойБезопастнойОперационнйСистемы?
По тому же текстовому файлу, сразу столько много вопросов возникает...
Я не вполне понимаю, в чем проблема. Если в вашем предложении заменить слово объекты на слово файлы, то в принципе ничего не поменяется. Ну просто, нам всё так же нужно присвоить объекту имя и найти для него свободный участок в памяти диска, никаких отличий от файла. Нам всё так же нужна система каталогов, чтобы упорядочивать эти объекты. Нам всё так же нужны кнопки сохранить и загрузить, чтобы приложения могли обмениваться данными.
Опять же, как вы собираетесь отказаться от сериализации. У вас есть какое то там сложное дерево из объектов, построенное одним приложением, вы хотите открыть его в другом приложении. Вам всё равно придется делить общий функционал по работе с данной структурой данных, от сериализации это отличается только промежуточным представлением и никакого упрощения не создает.
Опять же, есть две разные программы, которым нужна разная структура данных, упс, нам опять понадобилась возможность преобразовывать типы объектов, как и с файлами.
Ну и по поводу ссылок внутри файла. У каждого файла уникальный путь, вот вам пожалуйста и однозначная ссылка на другой файл, магия, правда.
Система каталогов не привязана к файлам ну вот никак.
Файл в каталоге вообще может не существовать на диске но при этом быть прочитанным, верно?
Далее.
Отказ от сериализации/десереализации это отказ от кода который надо поддерживать, просто взяли и выбросили. Меньше кода -- меньше проблем.
Насчёт разных программ вообще всё просто -- если программы хотят взаимодействовать друг с другом по данным им нужно определить какие характеристики объекта они считают общими и частными и соответственно изменять их не ломая совместимость друг с другом. А где тут сериализация в файл?
А не нужна она, если объект в памяти представлен "как есть", со всеми ссылками, атрибутами и прочим наполнением. Одна программа позволяет другой программе открыть указанный объект, всё. Либо программа экспортирует объект в общий реестр данных -- полный аналог современной ФС, и объект может быть открыт любой программой.
А уж что там внутри -- программа либо пользуется метаданными о типе объекта либо разбирает его самостоятельно на составляющие, благо у объекта есть для этого вся информация, например как в JSON или XML.
У каждого файла уникальный путь, вот вам пожалуйста и однозначная ссылка на другой файл, магия, правда.
Не надо ёрничать. Ссылка на один файл в другом файле невозможна без потери ссылочной целостности.
Т.к. не может быть представлена вне логики ФС.
Разве текстовый файл содержащий строки с полными путями каких либо файлов станет изменяться если будут изменяться имена этих файлов в ФС?
Очевидно что нет. Следовательно, файл не может содержать ссылки на другие файлы, это будет просто текст.
Отказ от сериализации/десереализации это отказ от кода который надо поддерживать, просто взяли и выбросили. Меньше кода -- меньше проблем.
Так я же его не руками пишу, он из библиотеки берется
Ссылка на один файл в другом файле невозможна без потери ссылочной целостности. Т.к. не может быть представлена вне логики ФС.
Разве текстовый файл содержащий строки с полными путями каких либо файлов станет изменяться если будут изменяться имена этих файлов в ФС?
Объясните, что такое переименование файла (объекта) с точки зрения фантомной ОС?
У меня файл-объект "Родительский" содержит ссылку на "Дочерний". Если я изменяю содержимое "дочернего" файла, то меняется содержимое "дочернего" объекта и заодно родительский объект увидит изменения. Если я удаляю "дочерний" файл, то его содержимое становится в некотором смысле пустым, а содержимое дочернего объекта внутри родительского тоже станет пустым. Пока вообще не вижу разницы реализовано это через файлы или объекты.
Теперь я переименовываю дочерний файл и после этого содержимое дочернего файла для родительского файла тоже становится пустым, т.к. дочерний не найден. Насколько такое поведение ожидаемо, вопрос другой. Но когда я переименовываю дочерний файл, это означает что я хочу видеть его с другим названием и при этом видеть как файл - поименованную область диска. Что такое переименование дочернего объекта для ООП?
Разве текстовый файл содержащий строки с полными путями каких либо файлов станет изменяться если будут изменяться имена этих файлов в ФС?
При переименовании файла в винде кликая на ярлык файла со старым именем винда говорит примерно, что файл был удален но потом шаманит - и файл найден. Так что прослеживание переименований вполне возможно.
Поясните, в терминах ООП, что такое родительский/дочерний файл?
Содержимое дочернего файла может иметь в себе ссылку на любой другой файл?
Или вы придумали свою реализацию объектов в файловой системе? Я к фантому никакого отношения не имею. Поэтому не могу сказать как там устроено отражение объектов на дисковую память.
Поясните, в терминах ООП, что такое родительский/дочерний файл?
Файловая система самая обычная, в которой нас интересует только что каждый файл имеет имя и путь и по своему пути файл находится однозначно (или если не находится - файла нет). Процитировал ваш пост, какую задачу для операционки с мега-объектами вы пытаетесь в нем решить?
Разве текстовый файл содержащий строки с полными путями каких либо файлов станет изменяться если будут изменяться имена этих файлов в ФС?
Я предположил, что пытаетесь решить задачу ООП вложенных объектов. Если не так, то опишите задачу.
Поясните, в терминах ООП, что такое родительский/дочерний файл?
Как раз перенес термины из ООП в файлы (логическая организация, какая ФС не важно, для ФС каждый файл сам по себе). Объект A содержит объектное поле B, а объект B сам содержит поля C,D. Для файлов внутри файла A есть полный путь файла B, внутри B - полные пути C,D. Тогда файл A называем родителем для B. В свою очередь B - родитель для C,D.
Пути к "дочерним" файлам хранятся прямо внути тел файлов. Как файловая система разбирается со связями A,B,C,D - да никак, для нее это просто файлы, к ним обращаемся по полным путям. Заниматься компоновкой файлов в единый мега-объект должна та программа что работает с такими мега-объектами.
Содержимое дочернего файла может иметь в себе ссылку на любой другой файл?
Если ключевой вопрос может ли файл иметь в себе ссылку - вы уже использовали это.
Разве текстовый файл содержащий строки с полными путями каких либо файлов станет изменяться если будут изменяться имена этих файлов в ФС?
Если ключевой вопрос "ссылку на любой другой" - то да, может, ограничений на это нет, внутрь файла можно же записать любой путь.
В том числе это может быть ссылка на себя самого, на своего родителя, множество ссылок (путей) и даже множество одинаковых ссылок. Зачем это понадобилось - нужно спросить юзера.
Отказ от сериализации/десереализации это отказ от кода который надо поддерживать, просто взяли и выбросили. Меньше кода -- меньше проблем.
А вот у меня 4к изображение несжатое в оперативке висит, его мы так же в чистом виде на диск запишем ?
Насчёт разных программ вообще всё просто -- если программы хотят взаимодействовать друг с другом по данным им нужно определить какие характеристики объекта они считают общими и частными и соответственно изменять их не ломая совместимость друг с другом.
Замечательно, это и называется сериализацией. Мы запаковываем данные в некоторое промежуточное представление, задаваемое стандартом.
если объект в памяти представлен "как есть", со всеми ссылками, атрибутами и прочим наполнением.
А вот у меня 90% ссылок используются только внутри моей программы и только в рамках текущей сессии, смысл их сохранять для всех ?
А уж что там внутри -- программа либо пользуется метаданными о типе объекта либо разбирает его самостоятельно на составляющие, благо у объекта есть для этого вся информация
То бишь нам все же нужно ручками вытаскивать нужную информацию из объектов, так же как и из файлов. Ну и чем тогда это отличается от работы с файлами, у файлов так же есть метаданные, с ними так же можно взаимодействовать.
Т.к. не может быть представлена вне логики ФС.
А вы хоть представляете себе накладные расходы на сохранение этой ссылочной целостности.
Конечно представляю.
Делал такую древовидную БД, где хранились миллионы объектов связанных друг с другом. И ссылались на себя, на соседей, на детей и потомков. И всё с учётом ссылок. Всё сидело в оперативе, и сериализация этого всего выливалась в проблему при сохранении на диск или передаче по сети. Были перепробованы различные методики, библиотеки, СУБД, но ни одна не устраивала по скорости доступа к элементам. А счёт шёл на доли микросекунд. Если бы это всё было сделано на файлах и mmap, а такой вариант персистентного хранилища в рамках этой разработки тоже был -- то ни о каких микросекундах там и не могло быть и речи.
Замечательно, это и называется сериализацией.
Это не называется сериализацией. Это передача объекта по ссылке или по значению.
такую древовидную БД, где хранились миллионы объектов связанных друг с другом. И ссылались на себя, на соседей, на детей и потомков
То есть, сперва сделали такой дизайн, который может жить только в RAM
сериализация этого всего выливалась в проблему при сохранении на диск или передаче по сети
а потом удивились тому, что создали его таким.
Nuff said.
Это не называется сериализацией. Это передача объекта по ссылке или по значению
Это в пределах одного адресного пространства работает. То есть в пределах только приложения или, в лучшем случае, нескольких приложений, поддерживающих механизм shared memory.
Как только вы выйдете за эти пределы — все, привет.
А вообще, гляньте в сторону Distributed Erlang — это, хотя бы, реальнее всепланетного финика.
Не совсем так. Файл это просто некоторое множество байтов, с которым каждый может делать все что угодно (в рамках своих прав доступа к нему).
Вот винда. Вот .exe файл. Фактически это программа. Но никто не мешает открыть ее HEX редактором и подправить в нем пару-тройку байтиков.
Объект это уже не просто множество байтов. Это во-первых, типизированное множество байтов, а во вторых, это множество байтов, для которого разрешен вполне опледеленный набор операций. И если объект имеет тип *pgm (программа), то открыть его hex редактором уже нельзя - операция редактирования для типа *pgm запрещена системой. И никакой сериализации для объекта данного типа нет и не будет.
Если у вас есть объект типа *file с атрибутом pf-dta - физический файл (хранилище) данных, то для него уже разрешено редактирование, сериализация и т.п. А если это объект типа *file, но с атрибутом lf (логический файл, определяющий порядок доступа к содержимому одного или нескольких физических файлов), то там уже свой набор операций будет.
Т.е. суть "объекта" в строгой типизации и строгом наборе разрешенных с ним действий.
Здесь понятие "объект" несколько иное чем возможность содержать ссылки на другие объекты.
Объект характеризуется именем, типом и свойствами. Имя можно менять, тип задается при создании и изменен быть не может. Свойства могут изменяться или не изменяться.
Каждому типу объекта предписан допустимый для этого типа набор операций. Например, объект типа "файл данных" может быть изменен. А объект типа "программа" изменен быт не может - операция изменения для этого типа запрещена на уровне системы.
На самом деле тут вижу попытку скрестить ежа с ужом. Есть "объектные ОС" - например OS/400 от IBM (нынче оноа называется платформа IBM i). Вполне себе живая концепция того, что "все есть объект" со своей файловой системой и т.п.
И есть микроядерные - та же QNX.
Что здесь не совсем понятно - общее пространство памяти. Что будет, если программа падает? Нагадит она остальным или ее можно безболезненно снять, как снимается задание в job isolated системах?
Файл это просто поименованная последовательность экстентов.
Будете ли вы обращаться к ней как %APPDATA%\%APPNAME%\some\long\path или как ~/$APPNAME/some/long/path или this.some.long.path или даже OS.System.AppData.(tags=('some', 'long', 'path'), mode=('rws'))— нет вообще никакой разницы.
С обращением проблем нет. Адресовать файл не сложно, сложно уложить в него структуру данных.
Хм.
С одной стороны есть теоретически неограниченное пространство от 0.
С другой стороны есть теоретически неограниченное пространство от 0.
Взять бинарь из одного, положить в другое…
Ну, окей, пусть не бинарь а объект. У которого, кстати, каждый property может ссылаться на разные куски памяти — очевидно, что его нельзя просто так взять и сохранить а потом восстановить: во-первый, это будет огромный кусок, содержащий, в основном, нули. Во-вторых, не факт вообще что у приложения в следующий раз будет выделено ровно столько памяти и она будет распределена точно так же.
Значит, его сперва надо привести к последовательно-упорядоченному виду: сложить все его потроха по порядку, друг за другом. Т.е. сериализовать. Чтобы потом менеждер памяти мог объект раскидать обратно, оставив его пригодным к использованию.
сложить все его потроха по порядку, друг за другом. Т.е. сериализовать. Чтобы потом менеждер памяти мог объект раскидать обратно, оставив его пригодным к использованию.
А зачем? Что мешает сохранять объект как есть постоянно в памяти? Вы же не разбираете пылесос после уборки? Просто ставите в шкафчик.
Аналогия полная.
То, что объект как целое это абстракция.
Разыменуйте поля/свойства/методы — и вы получите полный скаттер. То, что разыменование скрыто от программиста, это не значит, что его не происходит. По сути, вы хотите дополнительный слой абстракции, который спрячет от вас (де-)сериализацию, чтобы было удобнее всегда воспринимать объект как единое целое.
Представьте себе, что комната — это память процесса. Ее можно расчертить на квадратики, по сантиметру, пусть каждый квадрат это ячейка. Если ячейки пронумеровать, последовательно, одну за другой, вы получите уникальный адрес для ячейки.
Теперь положим в угол кусочек сантиметровой ширины ленты — это ваш объект. Точнее, это первый, видимый, его vtable. В обхекте нет данных — только числа, удивительно похожие на адреса, которыми вы пометили ячейки в "комнате". Вы берете число, находите соответсвующую ему ячейку где-то в другом углу — а там еще одна такая полоска, потому что на самом деле у вас не данные записаны, а вызывается геттер/сеттер. Найдя ленту с кодом геттера вы должны исполнить ее инструкции, и только потом получите очередной номер ячейки, из которого уже возьмете интересующее вас значение.
И это если сильно упрощать.
Ваш условный пылесос никогда не существовал как целое, понимаете?
И не будет, пока вы его не сериализуете.
Спасибо что расписали двойную косвенную адресацию, но это уже пройденный этап для меня.
Такие реализации были придуманы и довольно давно и не мной. Ознакомьтесь если интересно:
http://www.garret.ru/~knizhnik/post.html
https://github.com/knizhnik/POST--.git
http://www.garret.ru/~knizhnik/goods.html
А зачем? Что мешает сохранять объект как есть постоянно в памяти? Вы же не разбираете пылесос после уборки? Просто ставите в шкафчик.
Угу. Это если брать сферический пылесос в вакууме. Теперь берем реальный пылесос и оказывается, что ему нужно питание, а чтобы он получал питание, ему нужен шнур, включенный в розетку (условно, аналог поля с указателем/ссылкой на другой, независимый, объект, ага?). Чтобы дверца в шкафчике закрывалась, шнур надо выключать из розетки и сматывать, а при повторном использовании пылесоса - соответственно, разматывать и подключать. Вы можете, конечно, никогда его не выключать, сделать специальную прорезь для шнура в дверце, и считать, что проблема решена... До тех пор, пока вам не потребуется перевезти пылесос в другую квартиру и подключить его к местной розетке.
А объект в памяти это не сферический пылесос? Зачем тут лишние вводные типа шнура? Вы объекты в памяти в розетку не включаете ведь.
В природе он не существует, зачем его разбирать? А вот только для того, чтобы было удобнее его хранить в последовательности байт, с адресацией отличной от той в которой он был порождён?
Это же лишний слой хранения пылесоса который по возможности нужно убирать. Что и демонстрирует нам Фантом-ОС.
Зачем тут лишние вводные типа шнура? Вы объекты в памяти в розетку не включаете ведь.
Это для теоретиков - больших любителей сферических объектов в вакууме (Спольски называл таких "архитектурными астронавтами") они "лишние", а в реальности ситуация, когда частью инварианта объекта является ссылка/указатель на другой объект, отнюдь не редки. И этот инвариант надо поддерживать. Сохранения объекта просто в виде кучки байтиков для этого совершенно недостаточно.
Что и демонстрирует нам Фантом-ОС.
Фантом-ОС пока ничего толком не демонстрирует. Очередной теоретический долгострой от энтузиаста с весьма туманными перспективами.
Если для данной системы существует некий "объектный менеджер", который может просматривать \ изменять \ копировать \ удалять произвольные объекты, так же как в обычной системе файловый менеджер может делать все это с файлами — почему нет?
<nosarcasm>Недавно нашёл на шкафу флешку. Сперва даже не понял, что это, а потом долго вспоминал, когда в последний раз я её вставлял в комп. Решил посмотреть, что на ней, а все файлы битые, такое ощущение, что сама память размагнитилась )))</nosarcasm>
глубже вы никуда не можете проникнуть на уровне пользовательской программы.
Это пока кто-то не найдет дыру, позволяющую читать/писать по абсолютному адресу. Учитывая, что без интеропа с сишным кодом не обойтись — такая возможность рано или поздно появится.
С другой стороны — это не general purpose OS, так что это не особенно страшно. Так понимаю, там будет запускаться строго ограниченный набор софта, без возможности установки пользователем чего-либо.
А разве в управляемом коде есть возможность работать с адресами напрямую? Вроде нет, да и изоляцию процессов никто не отменял. Ну был же симбиан, полностью java-os, таких проблем не наблюдалось.
Ну был же симбиан, полностью java-os, таких проблем не наблюдалось.
Вы что-то путаете. Symbian был вполне классической ОС с вытесняющей многозадачностью и защитой памяти различных процессов друг от друга.
Ну прямой возможности — нет. Поэтому я и говорю про дырку. Где-то забудут проверить границы массива, например.
А насчёт изоляции процессов — так пишут же что все приложения работают в общем адресном пространстве.
В целом — норм, только, как обычно, работать все это будет небыстро
Не очень понятна концепция "всё есть объект". Означает ли это, что физически файлы на диске не хранятся? Если так, восстановление данных с дисков такой операционки представляется сущим адом.
Если же файлы на диске всё-таки хранятся в стандартном для файлов формате, тогда выходит не "всё есть объект".
Кстати любопытно, а используются ли кольца полноценно в других операционках. На сколько я знаю (на начало 2000х), на практике использовалось только 0 и 3 кольцо, а 1 и 2 не нашло применение в меинстриме, хотя Интел их и тащит для обратной совместимости.
Насколько я помню -- JIT компиляция. Вообще строго говоря, таким образом можно построить систему обеспечивающую изоляцию процессов на процессоре не обладающем аппаратными механизмами защиты. Идея в том, что компилятор просто не генерирует "недопустимого" кода.
Да, код может будет не очень эффективный компилироваться, но с другой стороны такой процессор может быть проще устроен и работать на более высокой частоте, или иметь больше ядер, или исполнять большее количество инструкций впраллель...
Лично моё мнение -- будущее может быть таким, что "кругом будет сплошной webassembly". Может не именно webassembly, но какая-то похожая технология. Аппаратно-зависимый машинный код останется только в JIT-компиляторе и драйверах совсем низкого уровня. И гегемония интела на этом может кончится. Будут процессоры на совершенно разных архитектурах, но при этом будет некий единый managed-рантайм. Вряд ли .NET или Java, скорей что-то, что станет международным стандартом, что нельзя запатентовать и обложить данью. Что все могут без ограничений использовать в своих продуктах. Пока на это больше похож webassembly. Для программиста там будет тот же C++, C#, что угодно. Важно что целевая платформа у всех будет единая, стандартная, виртуальная и не соответствующая аппаратной платформе. И у каждой аппаратной платформы свой JIT-компилятор.
Ну примерно так https://habr.com/ru/post/579876/
Ну, она может запустить Quake. Неплохо :)
KolibriOS тоже это умеет из коробки. 😋
Сохранить состояние в середине транзакции умеет CRIU в линуксе, например. Ну не совсем полностью конечно, впрочем как и Phantom OS видимо (т.к. для сетевых соединений решение с персистентностью просто невозможно). gdb умеет записывать состояние и откатывать назад. Идея персистентности на уровне отдельного процесса не требует специальной отдельной ОС. Да в конце концов VirtualBox умеет снапшоты записывать...
Думаю, тут всё же не полная аналогия.
Virtualbox'у, чтобы сохранить снепшот, нужно определённое время, прямо пропроциональное объёму памяти виртуальной машины. Если правильно понимаю, в статье подразумевается чуть ли не фоновое сохранение, без ущерба быстродействию.
UPD: Т.е.:
>Снимки состояния выполняются в асинхронном режиме без приостановки
работы виртуальной машины. В снимке фиксируется единовременный срез.
Linux слишком плохо развит чтобы на нем можно было делать чтолибо серьезное.
«Невозможно конкурировать с Windows, повторяя её. Невозможно
конкурировать с Windows, создавая функционально более слабую систему,
такую, как Linux.»
цитата с той статьи. Что-то они ошиблись. Сильно ошиблись. Сейчас уже (моё мнение) развитие линукс и виндов идёт в сторону сближения, и вероятно когда-то родится их полный гибрид. И уж точно нельзя говорить, что линукс плохо развит. Даже тогда, в 2009 году, я уже как пару лет на домашнем ПК сидел под линуксом. Без винды и дуалбута.
Может быть, я сейчас так же ошибусь, если повторю на новый лад ту цитату: Phantom слишком плохо развит, чтобы на нём можно было делать что-либо серьёзное. Невозможно конкурировать с Linux, повторяя каждые 10 лет, что вышла новая операционная система (а, не так - "готовится к выходу"). Невозможно конкурировать с Linux, создавая функционально более слабую систему, такую, как Phantom.
P.S. Пусть это будет моей ошибкой, и через 10 лет я ещё раз переделаю свою же цитату :)
линукс и виндов идёт в сторону сближения
Не совсем так. Майки хотят сделать так, чтобы линукс был не нужен в качестве самостоятельной системы, включив его в Windows.
Всё по классике: не можешь победить - возглавь.
Майки хотят сделать так, чтобы линукс был не нужен в качестве самостоятельной системы
Мне кажется правильнее так: чтоб разрабатывать под линукс было удобнее сидя в винде. А с серверов вытестить линукс они больше даже и не пытаются, наоборот, активно развивают свой .net core под линукс.
P.S. Вот если данные Линукс программы массово станут собирать софтом от MS может стать, возможно, реальной бедой.
А, не для того, чтобы запускать Линукс программы в рамках Windows?
Я, конечно, не знаю точно об их планах. Но со стороны это выглядит как попытка пересадить линуксоидов на винду, потому что нет смысла пользоваться одним линуксом (если только вы не евангелист какого-то дистрибутива).
Почему нет смысла? У нас в компании разработчики, бухгалтерия, техподдержка использует Linux. Потому что Windows не бесплатен, требователен к ресурсам, а весь софт работает или портирован, или работает на браузере.
Дома у меня лично Windows как вторая система по одной причине - гейминг.
Почему нет смысла? У нас в компании...
Я говорил про домашнего пользователя, а на работе
У нас в компании разработчики, бухгалтерия, техподдержка использует Linux. Потому что Windows не бесплатен
Windows стоит копейки для предприятия, если брать уже с системным блоком (если конечно же предприятие это не 10 человек). Самое главное, админов винды можно нанять за миску супа, линукс же просят уже деньги. Год работы Linux админа и на разницу зп можно уже сотню лицензий купить.
требователен к ресурсам
Возможно, но, можете меня назвать зажравшимся, если у вас проблемы с производительностью ос на работе, то, как правило вашему пк больше 6 лет и его хорошо бы обновить.
а весь софт работает или портирован, или работает на браузере.
Логично, что вам тогда можно юзать Linux, но вот некоторые пользуются продуктами Autodesk и тут засада.
Дома у меня лично Windows как вторая система по одной причине - гейминг
У меня также было, но потом подумал, зачем мне дуалбут, если есть wsl2? Не поймите меня неправильно, я не топлю за винду, но майки избавили меня от необходимости держать две системы и подкупили удобством.
У меня также было, но потом подумал, зачем мне дуалбут, если есть wsl2?
А я не понимаю, зачем нужен дуалбут, когда есть Proton. Сближение по факту идёт с обеих сторон, и зачастую уже можно просто использовать ту ОС, которая лично вам удобнее.
У меня также было, но потом подумал, зачем мне дуалбут, если есть wsl2?
Все просто, многие игры устанавливают античиты, да и в принципе многие издатели были замечены за подозрительной активностью на ПК. Поэтому Windows — песочница, где можно запускать все для развлечений.
Но серьезные данные — только на зашифрованной системе с Linux, где запускаются более-менее доверенные приложения.
У меня создается ощущение, что Windows больше не в приоритете у MS: главное для них облачные технологии. Поэтому они начали раскручивать проекты типа Microsoft 365 (не путать с Office 365) и портировать софт на Linux.
Уже не найду, но проскакивала инфа, где MS получает большинство доходов как раз с офиса.
Это давно было. Где-то в начале века. А последние годы клауд в топе. Если я правильно понимаю этот отчет https://www.microsoft.com/investor/reports/ar21/index.html, то направление "Intelligent Cloud" дает 42% Income и 24% Revenue.
Почти Plan9 только с концепцией, "все есть объект"?
Собственно, сам dzavalishin иногда пишет про Фантом на хабре:
Вся эта локальная персистентность - это, конечно, очень актуально в эпоху, когда все распределенное и доступность меряют стойками, очередями и целыми датацентрами
И поверх всего этого добра запускают виртуалки с кубернетисами, для того, чтобы в первую очередь достигнуть декларативно описанного состояния системы (то есть абстрагироватся от всех этих файлов, виртуалок, стоек, очередей и датацентров) (а во-вторую - получить авто-скалирование в ширину).
Мне кажется персистентные (а в идеале иммутабельные) обьекты и программы из них идеально ложатся на параллельно-распределенные вычисления (и потому для таких задач и популярны хаскель, скала и эрланг).
Хорошо абстрагироваться получается только для стейтлесс нагрузки.
А вот когда появляется (многотерабайтный) стейт, внезапно оказывается, что компьютеры ломаются, сеть не очень-то и быстрая, да и вообще скорость света на масштабах континента не очень-то и большая. Тут-то все красивые абстракции и начинают яростно течь :)
А вот когда появляется (многотерабайтный) стейт
А кто виноват?
Вселенная. Стейт бывает большой по объективным причинам.
Тот, кто решил вместо файла-вебстранички сохранить все 60ГБ, съеденные хромым, сохранить, очевидно.
Я имею в виду "стейт" в самом широком понимании. БД, которой пользуется приложение - это тоже его стейт, только вынесенный наружу.
От данных, очевидно, никуда не деться - программы их обрабатывают :)
Маленький пример — почтовый сервер, с несколькими пользователями, у каждого архив почты лет так за 10 (под сотню тысяч сообщений+аттачи).
И сколько это в сумме занимает? А если надо искать и фильтровать?
Если несколько пользователей — то тут не терабайты, а вот если несколько сотен пользователей то уже появляются терабайты.
Большой пример — Например желающие иметь свой поисковик по хотя бы паре десятку миллионов документов. Лучше — больше. И нужно индекс обновлять, показывать превьюшки, искать наконец по нему.
И нет, "возьмите реляционную базу данных" это не ответ, тут специальные структуры (Hadoop/HDFS изначально под подобную задачу в рамках проекта Nutch был создан)
Код проекта распространяется под лицензией LGPL, но последнее изменение в основном репозитории датировано ноябрём 2019 года. Связанная с проектом публичная активность сосредоточена в репозитории с форком для Genode, который с декабря 2020 года поддерживает Антон Антонов, студент из университета Иннополис.
Главная особенность ОС — использование концепции «все есть объект» вместо «все есть файл».
Неужели python? :)
P.S. Неизвестный Smalltalk
Автор этой статьи на нём сделал программу FlProg (среда разработки VisualWorks)
(файлы проектa flp в формате текстовых sixx файлов для хранения объектного представления схемы)
для PDP-11 была сделана и вроде объектная ОС на Smalltalk (DCIM?)
А работает так же быстро как питон? На ум почему-то приходит Temple OS.
Приложения работают в общем адресном пространстве, такое решение дает возможность обойтись без переключений между ядром и приложениями.
Так можно делать, только если написано на безопасном языке.
Интересно, как персистентность сочетается с необходимостью в периодическом сбросе состояния системы (перезагрузке и т.д.)
Так же, как персистентность файлов в привычных нам ОС сочетается с необходимостью в периодическом сбросе состояния системы путём её переустановки.
Я же правильно понимаю что если я диск с этой системой вытащую из машины с AMD Ryzen 5 1600 (6C/12T) и 64 Gb RAM, и воткну в китайскую двухсокетную мать с двумя Xeon'ами (28C/56T) то она спокойно заработает без проблем?
Нет? Как это нет? Намного более примитивная Win11 это почти нормально перенесла.
Есть пара вопросов:
Что является исполняемым кодом и на каком языке его пишут для ОС Фантом ? Если это байт-код ориентированная VM (как например Inferno и его Limbo), то все как бы понятно. Но если это настоящий машинный код компилированный из C/C++, то совсем не понятно.
Как достигается контроль за исполнением кода и какой у этого дела оверхэд ?
UPD: Прочитал первоисточник, вопросы отпали.
Насколько, интересно, персистентность совместима с тем фактом, что любая программа имеет по меньшей мере одну ошибку (вроде, (C) Дейкстра) и, следовательно, рано или поздно -- развалится.
Или хуже того, будет память утекать. Или ещё что-нибудь утекать. Файл дескрипторы, ресурсы какие-нибудь, да мало ли что. Смешно сказать, но у Java/C# тоже есть утечки. Не явные, но есть. Какие-нибудь там ключи в ассоциативном массиве, строки и т.п.
В итоге значительная часть программ, не зависимо от языков программирования и сред разработки вынуждена периодически перезапускаться. Иначе что-нибудь сломается. Потому, что программы не абсолютно идеальны, а скорей каждая программа имеет какие-то проблемы, которые на сколько-нибудь заметно большом сроке работы скорей приведут к аварийному завершению.
В каком-нибудь линуксе с этим просто. Отработала программа и на выход. А потом всё с начала. Благо программы умеют какую-то выжимку из своего внутреннего состояния записывать в файл. И потом другая, новая, исправленная версия программы может этот файл проинтерпретировать и продолжить работу, например.
А тут, в Phantom OS как? Если нет файловой системы? Один раз запустили -- и это на всю жизнь? Ни обновить, ни перезапустить? Мне кажется файловая система, база данных или что-то вроде того неизбежно появится.
Тогда зачем персистентность, если программы можно просто перезапустить? Тем более, что вот такое волшебное восстановление после выключения питания, например, оно и не особо нужно, всё равно многим потребуется какое-то событие, сигнал, чтоб адекватно продолжить работу. Те же сетевые соединения -- давно разорваны и их не восстановишь, время -- перескочило вперёд... Просто восстановить замороженное состояние -- мало кому нужно, многим нужны свои специфические механизмы восстановления состояния (заново открыть сетевые соединения, а там протокол какой-то свой специфический, да масса всего).
В итоге персистентность и отсутствие файловой системы каждутся конечно интересными идеями, но больше для научно-исследовательских задач, чем для практических.
Утекать может и место на диске. Наверняка у вас где-нибудь в $HOME/.config/ и $HOME/.local/share/ есть целые директории, которые созданы программами, которые больше не установлены в системе. И ошибки тоже могут накапливаться (хотя и с меньшей вероятностью, так как кода, меняющего персистентное состояние меньше), если они являются частью персистентного состояния - чтобы бороться с этой проблемой, Firefox при восстановлении после сбоя каждый раз спрашивает, хочет ли пользователь восстановить ранее открытые вкладки.
Если у программы есть два места, в которых хранится состояние - персистентное (диск) и оперативное (регистры, память, состояние объектов ОС), то программисту каждой такой программы придётся заботится о явной синхронизации этих мест. Ошибки её реализации возникают настолько часто, что у спидраннеров есть даже специальный термин - save/load abuse.
Вместо перезапуска программы будет её переустановка. Сериализуется объект "настройки" куда-нибудь (в какой-нибудь системный "реестр" или "хранилище настроек"), программа переустанавливается и новая версия подтягивает этот объект.
Это же какой объём оперативной памяти надо, чтобы держать всю систему, включая программы и их данные, в ней. Да и со слепками не очень ясно. Если они постоянны, то будет генерироваться огромный i/o, что довольно быстро выведет из строя SSD
То есть, если что-то зависнет, перезагрузка уже не поможет. F.
Ставлю автору ОС самый жирный лайк из всех возможных. И желаю , чтобы юрисдикция его компании была безопасной.
Критики подхода как-то забывают что вот такие приложения с перситентностью окружают нас везде. И имя им: веб-приложения. Практически тот же подход — получаем каким-то образом (окей, по сети, но современные фреймворки абстрагируют это) граф объектов, работаем с ним, сохраняем обратно.
Я не помню что-бы тот же Gmail работал с файлами. У него есть объекты-адрессаты, объекты-письма, объекты-аттачи. И ничего, работает же. Та же фигня с мобильными приложениями: мало какой софт показывает юзеру ФС. Есть целые онлайн-CAD, хранящие сложные документы перситентно. Про Google Docs я вообще молчу.
В общем, на самом деле идея вполне себе рабочая. И довольно близка текущему поколению пользователей.
Персистентность означает, что приложение запускается один раз за всю жизнь.
Если жизнью считать исключительно срок жизни вкладки до засыпания — то вы правы.
Но тогда персистентны даже программы под DOS ))
Персистентность означает, что приложение запускается один раз за всю жизнь.
Если жизнью считать исключительно срок жизни вкладки до засыпания — то вы правы.
Да нет, почему же. Я могу открыть вкладку c Google Document вообще на другом компьютере и продолжить писать ровно с того места где я закончил на другой машине. Он подтянет все состояние документа кроме разве что позиции курсора. Почти 100% персистентность. Не только во времени, но и в пространстве.
Не совсем.
Если у вас пропадет сеть, то вы не сможете продолжить писать ровно с того места где я закончил на другой машине.
Потому что SPA запущенные на разных устройствах вообще ничего не знают друг о друге и общего у них — только сериализованный стейт, синхронизирующийся посредством третьего участника: облака.
У него есть объекты-адрессаты, объекты-письма, объекты-аттачи. И ничего, работает же.
Так сериализация-десериализация во все поля. Никакой передачи объектов напрямую, все через json — и это отлично видно в dev-console браузера.
Мобильные приложения вообще мимо: во-первых, у них есть доступ к файлам. Во-вторых, они хранят свои данные в БД, зачастую в нескольких.
Так сериализация-десериализация во все поля. Никакой передачи объектов напрямую, все через json — и это отлично видно в dev-console браузера.
Ну это терминологический спор уже. С одной стороны само название JSON говорит что он Object. С другой - сериализация\десериализация скрывается где-то на нижний слоях, бизнес-логика про нее ничего не знает.
Это фундаментальные различия, скрытые под слоем сахара.
Фактически, это разница между синхронизацией представлений фуллстейта одного приложения (ближайший аналог — передача снепшотов ОЗУ, вам нужен InfiniBand для этого) и передачей абстрагированного сериализованного представления модели, из которой этот фуллстейт может быть восстановлен.
Разницы как между Колизеем и его чертежом.
Сишного кода в репозитории 94%, так что я не понимаю о каком управляемом коде идёт речь. В сравнении например с такими проектами как singularity, midori, verve, cosmos
Меня в чисто-объектной архитектуре смущает ряд вопросов:
Базы данных. Несколько террабайт - это как? А я нарывался.
Ссылочная целостность. Например, передать объект - куда-то наружу, а там ссылки на другие объекты, и как? Да даже в рамках одной железки, сделать копию объекта - можно казусов наловить "мама не горюй"
Идеи то не то что бы новые, тут правильно oberon, plan9 и inferno вспоминали. Inferno доступна под MIT лицензией. Она, насколько я понимаю, прекрасно в целом работает. Имеет хорошую чистенькую кодовую базу, с которой можно работать, было бы желание.
Но толпы желающих почему-то не наблюдается. Когда кому-то нужна ОС, все тащат либо линукс, либо какой-то юникс помельче. И всех всё устраивает, и никому ничего не надо.
Phantom OS is an operating system (OS) made by mostly Russian programmers (with help of some Uzbeks).
omg...
Операционная система Phantom от российского разработчика: возможности и нюансы