>а на практике цикл от 1 до 2000( внутри только вывод на экран значения ) выполняется 10 минут

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

Чего ж тогда Ubuntu bug #1 то не закроют никак?

Что еще за баг номер 1 в этой вашей убунте :)?

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

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

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

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

> Мне тоже такая структура симпатична, но с идеологической точки зрения: таким образом явно декларируется время жизни объекта. Достаточно посмотреть на типы, а не на код что бы проследить время жизни объектов.

*тут*, внутри «ОС+диски+админ», ситуация совсем не та, что внутри программы (и это надо обдумать — в т.ч. в аспекте «где кончается детерминированность программы и начинается своевольство админа, ее модифицирущего»)

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

и более того,

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

и вот тут может случиться облом!

рассмотрим например прогу «плеер фильмов» и ее сохраненные объекты «фильмы»; вероятно еще будут зависимости от кодеков-декодеров для фильмов (предположим, все декодеры бесплатны)

1. как насчет другого плеера фильмов? допустим, он понимает эти объекты как свои

2. как насчет редактора фильмов? при осложняющем обстоятельстве — 1 кодек-энкодер для фильма является платным и стоит 1000 баксов

таким образом, объект-плеера-фильма не всегда является объектом-редактора-фильма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Насколько обосновано его утверждение, что всё можно перенести с X Window на SVGAlib? SVGAlib ещё живо?

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

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

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

> Ура, да здравствуют вирусы! Программы могут вступать в произвольные бесконтрольные связи, результаты врастают в бекап и однажды наступает абзац - вынужденная перезагрузка с потерей всех данных. Система требует внутреннего или внешнего антивируса. В случае внутреннего можно делать ось бесплатной и трясти бабло за антивирусные обновления! Сообщество GPL нервно кусает локти.

Ага, печальный опыт PalmOS человека ничему не научил :(

а вот как с миграцией приложений?

Как,как. Нетривиально и с огоньком :)

якобы «послал приложение по е-мейл»

Ну ты духовного папика Дениса Попова , по имени Завалишин, слушай осторожно :) Это клоун класса «зубр». Точнее класса «Бабаян» :):):)

 — а оно взаимодействует с sql-сервером, который взаимодействует с

десятком других приложений — вот и придется слать все сразу, хотя

для этого приложения открыта всего одна база из 10

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

Во первых, ты все равно будешь «слать email» в пределах одного системного контекста, одной распределенной виртуальной машины. Это значит что система-«получатель-emeil» будет знать что fd 15(например) это «наш родный» mysql сервер с нашего же виртуального распределенного хоста.
во вторых - кластеризация есть уже во всех фришных СУБД, при чем несколькими способами, а в оракле даже грид эдишн есть :)

По этому если процесс требующий наш мускул мигрирует на ноду где его(мускула) пока нету, системный демон миграции/конфигурации сделает следующее(например). Во первых запустит ноду mysql кластера(иди даже грида :)) с дефолтными параметрами. Она естественно приконнектится к mysql кластеру нашей виртуальной распределенной машины. Собственно так системный mysql сконфигурен в репозитории нашей системы. Сразу стартовать в режиме «кластер». Конфиги узлов генерит наш демон состояния системы. И изменяет/донастраивает mysql в случае появления новых узлов.
Затем выставит fd 15 состояние «сбой сервера». Или еще как сообщит, так как рестарт СУБД штатная операция в линуксе. И запустит программу.

Программа на следующей операции получит сбой - ошибка коннекта к mysql. Попробует переконнектится с теми же параметрами. Естественно это получится - свеженький mysql только и ждет коннекта. Кстати, имхо, рестарт сервера поддерживается в самой mysql либе.

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

Или, кстати, вообще не мигрировать процесс а дать через сеть коннект к СУБД на той машине с которой мы только что мигрировали. Нам очень не всегда нужен сервер именно на той машине с которой мы работаем. Это наверное даже могут делать эвристические алгоритмы в демоне миграции.

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

в общем, проблема посредников, которые юзают ресурсы фактически от

имени одного из приложений, но ОС этого не видит;

А в любом случае тут нужно влезать в черный ящик. И придумывать способы чтобы ОС, точнее ее часть, увидела то что нужно.

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

mysql многотредовый, и я, вопреки AVL2, не поверю, что в mysql нет

структур данных, общих для всех нитей!

Есть. :) Но запускать mysql в кластерном и грид режимах нужно много кому - это довольно востребованная область. По этому есть штатные решения обходящие тем или иным способом эту проблему.

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

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

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

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

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

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

>>>> К слову, я Sun Certified Java Programmer как раз по платформе 1.2

ох емаё! это ж 12 лет назад было!

> а и вообще нереально сделать че-то новое в гуе, не зная хотя бы кути.

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

втыкались в готовые кутешные модели

А вот это невозможно на уровне самой идеи. Идея состоит не в том, что «вау, какие у нас скучные listview! Давайте туда картинок и видео добавим и будем переключать!». Идея в том, что пользователь сам не только полностью определяет как внешний вид/управление, так и обработку данных, которую могли не предусмотреть разработчики. Плагинное АПИ на уровне междумордия, если угодно, само приложение про него и знать не будет. И как это реализовать, не сломав привязку к WIMP-модели кутешников (или gtk/winapi/cocoa) я не знаю. А вот приложения вроде mpd (работает через сокет) или полностью управляемые через dbus будут как родные.

твоя работа легко нашла бы применение (хотя бы для мобильных версий декстопных приложений — а там светит бабло)

Самая первая причина, с которой я и начал городить огород - это и было мобильное применение (ui + storage по идее раскина + некоторое подобие kio/kio-slaves для него + пара идей из Plan9). Но что бы я не делал - все время получается ui-тулкит :]

> а вот как с миграцией приложений? якобы «послал приложение по е-мейл» — а оно взаимодействует с sql-сервером, который взаимодействует с десятком других приложений — вот и придется слать все сразу, хотя для этого приложения открыта всего одна база из 10

Вариант:

1. Приложению делается stop_and_getSnapshot(), полученный образ перетекает в почту (хотя я уверен, речь шла про простые ссылки, но предположим что есть образ)

2. ОС на оригинальном хосте рвет коннект между sql-сервером и приложением, помечая его как открытый, сохраняет его стейт (нужен будет аналог kio-slaves для каждого протокола) и помещает как метаданные в образ. Аналогично помещаются ссылки на внешние ресурсы

3. На хосте-приемнике ОС читает метаданные и открывает сокет до sql-сервера, восстанавливает его стейт

4. Развертывается образ, для которого сокет все еще открыт и с которым можно работать.

В качестве плюшек такого подхода мы можем иметь компрессию/шифрование прозрачно для любых протоколов. Если же говорить непосредственно о sql или всяких хранилищах, то ОС может реализовывать дополнительные врапперы для оффлайн-хранилищ и последующей синхронизации, версионироние и кеширование данных, возможно распределенные хранилища. Ну по крайней мере я к этому пришел, что будет у Завалишина я не знаю

> я к тому что для реализации стандарта на данные (упаковка/распаковка) будет создан некий тулкит

1. Скорее всего только набор соглашений (как сегодня существуют пайпы)

2. К современному представлению UI это не будет иметь никакого отношения

3. Если уж так сильно будет гореть, то можно придумать что-то более семантическое, нежели stdout + stderr и использовать их без страха что-то нарушить - да, это будет тулкит-обертка, однако использовать его уже никто не заставляет

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

Кстате, очень бесит то, что приложение обычно обрабатывает ошибку как «ой, случился большой ужас, я закроюсь!». Да, это недостаток кривых рук программиста, который (не) делал обработчик ошибок. Но разве не лучше, когда сама ОС приостановит приложение и не спросит, что делать ему дальше (как это было во времена msdos?). Если мы переваливаем на ОС задачи типовых компонентов приложений, то зачем заниматься рутиной самостоятельно? Пусть сама ОС и заботится как о «данных в дескрипторах», так и о ошибках при работе с ними, при необходимости сама поднимает упавшие сокеты или просит воткнуть нужную флешку (или через сигнал в UI, или через сигнал для податчика кассет стриммера)

Это например и группа юниксовых демонов обменивающихся через сокеты по грамотныим протоколам

Еще одна моя мечта - выпиливание всего этого зоопарка и работа через что-то одно, например dbus или amqp

> 1. как насчет другого плеера фильмов? допустим, он понимает эти объекты как свои

Другой плеер или вызывает Phantom_get_pizdato_decoder(«porno.avi») и показывает кино (так поступает куча плееров на DirectShow), или реализует кодеки самостоятельно, или, что нереально, по по идее самый лучший вариант - устанавливает кодеки в систему и делает Phantom_get_pizdato_decoder(«porno.avi», myCoolCodecs), дабы в другом плеере эти кодеки тоже можно было использовать

таким образом, объект-плеера-фильма не всегда является объектом-редактора-фильма

Читай Раскина, на которого дрочит Завалишин. И плеер, и редактор - это «действия» для объекта типа «мультимедия/кино». Установили первый кодек? Можно грабить корованы^W^Wискать по не_файлам что-то вроде мультимедия/кино/размер_кадра_720х576 - система расширяема

Ахренеть. У него же мозга нет, как он может что-то создать? Язык как у Попова.

Н-да. Завалишин, человек известный и уважаемый. Да, ещё с 93 - 2000 гг., по фидошке. Отличный знаток OS/2, а «факи» имени DZ, это вообще было нечто весьма полезное.

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

Особо сильное впечатление производит пассаж о ненужности протоколов сериализации (ну да-да, я понял — вся память шаренная, хорошо. А как отдельные программы будут разбираться в этой куче хлама, без оговоренного протокола взаимодействия? Или подразумевается «монолит», в котором все возможные приложения написаны в единой среде, по единственному протоколу, типа смоллтолк-системы? И «наследуют» от единого системного корня-объекта? Но тогда это уже не ОС общего применения... и что делать с накоплением энтропии этим ужасом?

Человек пишет о плохой работе «гибернации», и ни слова не говорит, а *почему, собственно* гибернация работает скверно. Ни единой строчки о граблях взаимодействия сохранённого состояния и внешней среды... И так далее, придираться можно бесконечно.

Короче, или от автора нужна развёрнутая статья, и не для домохозяек и вельмож имени Сколково, или всё это приходится признать большим пуком в лужу. Уж извините.

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

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

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

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

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

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

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

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

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

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

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

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

> Что еще за баг номер 1 в этой вашей убунте :)?

Меня тоже заинтересовало, но я умею:

http://yandex.ru/yandsearch?text=Ubuntu+bug+%231

https://bugs.launchpad.net/ubuntu/+bug/1

Это например и группа юниксовых демонов обменивающихся через сокеты по грамотныим протоколам

Еще одна моя мечта - выпиливание всего этого зоопарка и работа через

что-то одно, например dbus или amqp

Вера в существование идеального протокола взаимодействия :) У вас детская болезнь «какие все идиоты, это же так просто1111».

Этот зоопарк по этому и существует что условия настолько разные что придумать нечто хорошо подходящее всему скорее всего невозможно. А попытки обычно приводили к ужосу. Например corba/DCOM системы ;)

в ходе некоего естественного развития конечно останется некое множество протоколов. Но ничего универсального, боюсь, не будет.

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

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

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

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

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

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

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

Суровый диагноз по Фрейду

Назвав свою ОС фантом автор пытается сообщить нам мысль о том что изучение основ linux и posix для него - недосягаемая «призрачная» высота. Что подтверждают его слова, сказанные какбе совсем о другом
"- О да! Спасибо вам за этот вопрос. Это же просто мучение, ужас и кошмар".
А вообще в компутерре мало кто мог осилить нормальный linux, поэтому их всегда волновали там какое-либо написание велосипедов и создание обходных путей. Мало когда в этом журнале относились всерьёз, одно лишь убегание и отрицание.
А вот ещё одно доказательства того что он назвал свою ОС, руководствуясь своими сексуальными фантазиями, которые он не смог осуществить из-за проблемы освоить ОС :«Дайте мне файл, я хочу его потрогать», «способы склеивания кода»
Ещё в пользу этого говорит совершенно ясно выраженное стремление перейти от структуры, к одним лишь объектам то есть символам: иконки, значки, окна. Что есть очевидное ООП головного мозга.

BTW

http://www.computerra.ru/readitorial/449624/

Этому я учился у мастера!

>Что еще за баг номер 1 в этой вашей убунте :)?

Безумный тайкунавт и название дистра.

> У вас детская болезнь «какие все идиоты, это же так просто1111».

Да, именно эта болезнь, правда я предложил использовать уже существующие методы, а не городить новые. Я против самого зоопарка.

Этот зоопарк по этому и существует что условия настолько разные что придумать нечто хорошо подходящее всему скорее всего невозможно. А попытки обычно приводили к ужосу. Например corba/DCOM системы ;)

«нет ничего более постоянного, чем временное». И практика показывает, что приживаются самые примитивные решения, нежели более проработанные, что заставляет меня сильно грустить.

Тут Завалишин: http://www.computerra.ru/upload/dz.jpg

Тут Петрик: http://gdb.rferl.org/62CC77EC-AA08-4E35-AA02-9426698A3BC8_mw800_mh600_s.jpg

Практически отец и сын.

> Кстате, очень бесит то, что приложение обычно обрабатывает ошибку как «ой, случился большой ужас, я закроюсь!». Да, это недостаток кривых рук программиста, который (не) делал обработчик ошибок. Но разве не лучше, когда сама ОС приостановит приложение и не спросит, что делать ему дальше (как это было во времена msdos?).

это должно делать не приложение и не ОС, а шелл — т.к. вопрос в терминале и в Х-ах должен выглядеть по-разному; без шелла приложение может просто закрыться

ОС должна реализовывать единый механизм для этих «кросс-процессных исключений/рестартов»

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

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

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

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

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

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

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

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

> И плеер, и редактор - это «действия» для объекта типа «мультимедия/кино».

ни разу — фактически мы имеем тип допустим Mulimedia::Film<Decoder::x264>, но никак не просто Mulimedia::Film

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

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

Cценарий:

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

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

Варианты:

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

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

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

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

> ...он назвал свою ОС, руководствуясь своими сексуальными фантазиями, которые он не смог осуществить из-за проблемы освоить ОС...

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

:«Дайте мне файл, я хочу его потрогать», «способы склеивания кода»

Явная кинестетика.

П.С. Удивляет то, что какие-то куски кода есть, хоть и чужого. С таким названием реально существующих систем не делают обычно :)

>Какая разница, если мы сохраняем данные на диск и кто-то другой может их прочитать/модифицировать? Мы по сути только заменяем дисковые иноды на указатели в памяти.

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

И да, таких приложений крайне мало, не думаю, что «пересылка почтой» такого приложения чем-то будет отличатся от пересылки 1.5 гигового PSD-файла

ты идиот, пересылать 1 гб приложения нормально, а файл нет, дада - файлов то нет в этом твоем попиле, ну фантомосе.

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

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

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

версиями.

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

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

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

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

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

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

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

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

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

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

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

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

> это должно делать не приложение и не ОС, а шелл

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

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

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

А кто сказал, что фильм надо обязательно декодировать, да и только одним возможным кодеком? Я вот когда-то писал утильку, которая из AVI делала слайдшоу без перекодирования, вся реализация занимала сотню строк на перле. Поэтому именно Mulimedia::Film, далее возможны стандартные интерфейсы вроде play() или даже getCompressor()

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

> Если все приложения работают в одном адресном пространстве то ты никак не в состоянии отследить доступ из одного приложения к другому - учи матчасть

Рекомендую это сделать тебе, особенно изучить особенности работы с памятью в JVM

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

В оригинальной JVM - нельзя.

ты идиот, пересылать 1 гб приложения нормально, а файл нет, дада - файлов то нет в этом твоем попиле, ну фантомосе.

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

А теперь друкх - давай в мат часть, как там драйверы будут работать?

Микроядра и драйвера в юзерспейсе никто не отменял

некоторые, да даже многие железки надо инициализировать при старте, опять же - что делать в этом случае с прерываниями ? а с dma ?

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

а если нет файловой подсистемы то как ты это поделие прикрутишь к существующей инфрастуктуре ?

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

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

Вы слишком сильно нервничаете, наверное это следствия жары или недосыпания.

Чего только компутерровцы не выдкмают, лишь бы линакс не использовать...

Компьютерре-онлайн опубликовано интервью с Дмитрием Завалишиным - создателем ядра операционной системы

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

>Рекомендую это сделать тебе, особенно изучить особенности работы с памятью в JVM

как раз тебе, или там все будет на жабке ? тогда это клево, ошибка в jvm (а это неудивительно) и привет системе.

Микроядра и драйвера в юзерспейсе никто не отменял

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

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

Какой ты смелый поколе некомпетентный - я даже комментировать не хочу это.

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

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

Вы слишком сильно нервничаете, наверное это следствия жары или недосыпания.

Я спокоен, очень спокоен, просто называю вещи своими именами, идиотов идиотами, фриков фриками, поделки поделками, попилы попилами и тд и тп

>Вауу. И сколько же, мм хотя бы десятков человек поддерживает его проект? Неет, не за деньги, а именно потому что он того стоит и представляет из себя что то интересное.

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

> Поэтому именно Mulimedia::Film, далее возможны стандартные интерфейсы вроде play() или даже getCompressor()

тогда уж вообще Data::File

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

Я вот когда-то писал утильку, которая из AVI делала слайдшоу без перекодирования

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

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

впрочем, если поднапрячься, то может и интересно будет придумать некую (возможно сложную) систему типов, поверх которой можно уже будет наладить учет ссылок (и сборку мусора); однако она отнюдь не столь примитивна, как «мультимедия/кино», и там *должен* быть столь нелюбимый завалишиным Data::File :-)