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

>>а зачем нужен линукс когда есть винда?

Ааа, лавры Торвальдса не дает покоя? Скучно. Время уже не то.

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

>нет ядро Дмитрий пишет сам

ничего от линукса там нет
как и от бсд тоже

А как же это:

http://code.google.com/p/phantomuserland/source/browse/trunk/oldtree/kernel/p... - в самом низу

http://code.google.com/p/phantomuserland/source/browse/trunk/include/i386/vesa.h

И это:

http://code.google.com/p/phantomuserland/source/browse/trunk/oldtree/kernel/p...

http://code.google.com/p/phantomuserland/source/browse/trunk/include/i386/vesa.h

и т.д.

П.С. Дмитрий залогиньтесь!

>сингулярити если разберетесь в ней

Да, я активно следил за ходом разработки этой ОС потому что её писали настоящие пофессионалы.

Признайтесь, вам либо 13 лет либо вы ооочень толстый троль. Стиль письма, поразительная осведомленность вас выдают.

> Все контраргументы - полная фигня, автор прав.

Опять повылезли фанатики managed-языков.

Схема «ссылки и GC на все» обломается на 2 моментах:

1. утечки памяти и перерасход памяти, несмотря на GC — что привело к необходимости создать weak/soft/phantom ref. в яве — про утечки тут http://weblogs.java.net/blog/2006/05/04/understanding-weak-references

2. managed-языков *недостаточно* — т.к. состояние хранится «распределенно и смешанно» — т.е. клиент какого-то сервера взаимодействует по протоколу, и состояние этого взаимодействия хранится частично и на сервере, причем на сервере может хранится одновременно состояние взаимодействия одновременно с несколькими клиентами, причем не в разных нитях (по одной на клиента), а в одной структуре данных на все нити (а еще может даже poll/select без нитей вообще!)

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

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

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

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

>Признайтесь, вам либо 13 лет либо вы ооочень толстый троль. Стиль

письма, поразительная осведомленность вас выдают.

LOR такой LOR
уважаемый баран(theos) который себя называет умным человеком
который следил за развитем Сингулярити

давайте вы найдете файлик в Сингулярити
и скажете на каком языке это писано?

и после этого закроете свою тупую варежку
и предже чем что то вякать будете проверять
ок?

языка С я здесь не вижу, а это если вы не слепой, драйвер

Singularity\base\Drivers\Vesa\Vesa.sg


////////////////////////////////////////////////////////////////////////////////
//
// Microsoft Research Singularity
//
// Copyright (c) Microsoft Corporation. All rights reserved.
//
// File: Vesa.sg
//
// Note:
//

using System;
using System.Collections;
using System.Configuration.Assemblies;
using System.Runtime.InteropServices;
using System.Runtime.Remoting;
using System.Text;
using System.Threading;

using Microsoft.SingSharp;
using Microsoft.Contracts;
using Microsoft.Singularity;
using Microsoft.Singularity.Channels;
using Microsoft.Singularity.Extending;
using Microsoft.Singularity.Directory;
using Microsoft.Singularity.Io;
using Microsoft.Singularity.Configuration;

using Microsoft.Singularity.V1.Services;
using Microsoft.Singularity.V1.Threads;
using Allocation = Microsoft.Singularity.V1.Services.SharedHeapService.Allocation;

namespace Microsoft.Singularity.Drivers.Vesa
{
// create the resource object for CTR to fill in
[DriverCategory]
[Signature(«/pnp/vesa»)]
internal class VesaResources : DriverCategoryDeclaration
{
[IoMemoryRange(0, Default = 0xf8000000, Length = 0x300000)]
internal IoMemoryRange frameBuffer;

[ExtensionEndpoint]

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

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

>языка С я здесь не вижу

Молодец, и джаву тоже не видешь. Это язык S#. Где тут Java???

> То что вы думаете что это «на уровне хака» показывает что вы ничерта не смыслите в архитектурах ос.

оно принципиально будет «на уровне хака» независимо от архитектуры ОС — проблема именно в способе хранения состояния в протоколах и архитектуре *приложений*

> Если ты видишь спорные моменты - удели этому 10-20 минут и напиши подробный и развернутый ответ, мне было бы очень интересно почитать и ознакомится с противоположной точкой зрения

я вижу, вот: http://www.linux.org.ru/jump-message.jsp?msgid=5096258&cid=5100437

твои гуевые идеи однозначно требуют реализации в виде патчей для Qt, собственный твой тулкит их вероятно только похоронит

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

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

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

> и в 90% случаев потянет за собой ещё и libstdc++, про который я уже писал.

К.О. спешит напомнить, что SGI's STL is rigidly specified as a set of headers

> стандарт на данные гораздо проще, потому что он обычно не зависит от языка программирования.

действительно проще... но вот почему — это интересный вопрос

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

Большинство и вас рассуждает о том чего никогда не пробовали, альтруизм хорош, когда не на войне. GPL - я относиился к нему гораздо лучше, до того как стал писать одну большую софтину, я не против выложить некоторые части кода, но я не могу выкладывать весь исходный код продукта, который должен бы меня кормить. Потому и сам использую только либы MIT/BSD и выкладываю чтолиюо под ними. Но не ГПЛ - Завалишин полный болван - только изза того что считает C++ мертвым, но на счет GPL/LGPL - я с ним согласен.

> Но вот авторы другого мнения, они считают, что можно сделать кэширование памяти в память :)

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

GPL - я относиился к нему гораздо лучше, до того как стал писать одну большую софтину

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

> Потому, как нет разделения на программу и данные.

А если разделение будет, то это будет та же бд, только этим будет заниматься ОС, а не программа.

Прозреваю, что будет некий глобальный объект storage (та самая база данных внутри ОС), который и будет собирать все наработанное. Через него же интеграция с внешней средой, такой как флешки и интернеты, чтение/запись различных файловых форматов (привет трансляторам из беос/хайку). Захотел ты написать блокнот, а автосохранение, пачка файловых форматов и сохранение позиции в документе - уже реализовано.

> а на эти чистые данные то-же будет некий стандарт - те тулкит - те все то-же самое)

Стандарт на данные создать и поддерживать гораздо проще, нету привязок к конкретным реализациям и их внутренним моделям, нету ломаемого API и прочих «вкусностей», да и пайпы существуют далеко не один год

> Проблема в том, что не для каждого приложения это и нужно, а у пользователя/разработчика, похоже, такого выбора в Фантоме не будет.

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

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

> твои гуевые идеи однозначно требуют реализации в виде патчей для Qt, собственный твой тулкит их вероятно только похоронит

Мне неинтересно помогать кутешникам, можешь считать это тяжелой формой NIH.

> Стандарт на сети?

На сетевые протоколы.

это ты про два пакета и три формата?

Нет, а ты?

И еще. <window><button>hello!</button><label>world</label></window> - вот тебе формат данных.

И? Развей мысль, если можешь.

Посмотри наконец на Qt4 дизайнер.

И что я там должен увидеть?

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

>linuxядро <-> java машина <-> приложения
и работает только на карманникакх

Не только.

с jit

В 2.2 jit искаробки

лисапед устарел не успев поехать :))

Схема «ссылки и GC на все» обломается на 2 моментах:

что привело к необходимости создать weak/soft/phantom ref

привело не это, а то, что существуют unmanaged ресурсы и для того, чтобы ими управлять, необходимо встраиваться в систему сборки мусора. Слабые ссылки - это способ встраивания. Иначе пришлось бы дублировать функциональность в GC. В .Net есть это все тоже. К слову, я Sun Certified Java Programmer как раз по платформе 1.2

так как в системе Завалишина нет unmanaged ресурсов, то и проблема такая там не стоит, а если и встанет (из-за совместимости), то решение есть и проблем нет.

утечки памяти и перерасход памяти, несмотря на GC

такое тоже бывает, но ничего из этого не следует

2. состояние хранится «распределенно и смешанно»

Второй аргумент прошу пояснить. Есть же stateless-протоколы? В statefull есть лизы и таймауты как в .Net Remoting. В чем проблема-то?

главное, я пока не вижу,

как сохранение состояния реализовать независимо от прикладных программ

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

>а в одной структуре данных на все нити

бредово.

(а еще может даже poll/select без нитей вообще!)

другое дело.

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

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

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

снепшот. протокол сериализации состояния приложения и демон.

оно принципиально будет «на уровне хака» независимо от архитектуры ОС

 — проблема именно в способе хранения состояния в протоколах и

архитектуре *приложений*

Какая конкретно проблема в способе хранения и архитектуре? Вот есть SIGSTOP/SIGCONT. Приложение корректно засыпает и просыпается по ним, это юникс стандарт. Что мешает его(приложение) сохранять на диск когда оно остановлено? :)
PS
Какая часть процесса не сохраняется DMTCP, например, кроме состояния других приложений не входящих всохраняемое множество ;)?

> ох ты йожик! засирал хаскел а тут нате, понадобился...

мне — не понадобился, а вот завалишину и К, пытающимся сохранять состояние — может понадобиться для первоначального вдохновения;

впрочем, всякие stateless протоколы — вещь очень интересная и полезная, особенно без хаскеля :-)

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

снепшот. протокол сериализации состояния приложения и демон.

и где тут независимость от прикладных программ в условиях stateful protocol?

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

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

фрагменты

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

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

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

все это кошер, GPL, по словам столмана же - тоже плоха, но это лучший способ воевать с миром несвободного софта на их же поле.

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

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

и где тут независимость от прикладных программ в условиях stateful protocol?

Ты понимаешь что корректно написаая работа со stateful протоколом должна нормально отрабатывать ситуацию «канал сдох, надо переконнектится» :):):)?

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

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

>Слабые ссылки - это способ встраивания.

Охтыж е-мае, а еще так пафосно «я сертифицированный специалист!!!111». Дам намек что бы ты осознал ошибку - класс WeakHashMap. Возможно он нужен не только «для встраивания».

> так как в системе Завалишина нет unmanaged ресурсов, то и проблема такая там не стоит, а если и встанет (из-за совместимости), то решение есть и проблем нет.

что значит «unmanaged ресурс» в контексте (предполагаемой) системы Завалишина? (поточнее)

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

Анализ, думаю, надо провести, вот только где Завалишин это предлагает?

И кстати, после проведения такого анализа придется переписывать все проги под другие протоколы — одной ОС ну точно не обойдешься. А у него ОС-ОС-ОС.

Второй аргумент прошу пояснить. Есть же stateless-протоколы?

для всего? насколько распостранены?

В statefull есть лизы и таймауты как в .Net Remoting

и?

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

:):):)

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

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

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

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

Если ты правообладатель этой программы, то тебе никто не запрещает двойное лицензирование. Ну а если ты хочешь выложить часть кода, чтобы в нём сообщество фиксило баги, а потом включать эти наработки в проприетарную версию — то извини=)

> Ты понимаешь что корректно написаая работа со stateful протоколом должна нормально отрабатывать ситуацию «канал сдох, надо переконнектится» :):):)?

это, как я понимаю, только сетевые протоколы типа tcp/ip, и вряд ли протоколы поверх него анализировались на извращенные сценарии «канал сдох, мы перехали, и так 200 раз в секунду»

>> твои гуевые идеи однозначно требуют реализации в виде патчей для Qt, собственный твой тулкит их вероятно только похоронит

Мне неинтересно помогать кутешникам, можешь считать это тяжелой формой NIH.

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

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

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

> Ты понимаешь что корректно написаая работа со stateful протоколом должна нормально отрабатывать ситуацию «канал сдох, надо переконнектится» :):):)?

с сетью видимо проблем действительно почти не будет;

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

в общем, проблема посредников, которые юзают ресурсы фактически от имени одного из приложений, но ОС этого не видит; mysql многотредовый, и я, вопреки AVL2, не поверю, что в mysql нет структур данных, общих для всех нитей!

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

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

Вот прочитал, в очередной раз, ну хочет человек реализоваться в современном ИТ обществе. Дмитрий монстр - во всех смыслах, сетей времён фидонетов :) а всё меняется ... а плавать то как то надо :)

>Нет. Сравни положение в области сетей (где как раз стандартизуют чистые данные) и в области тулкитов.

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

Охтыж е-мае, а еще так пафосно «я сертифицированный специалист!!!111». Дам намек что бы ты осознал ошибку - класс WeakHashMap. Возможно он нужен не только «для встраивания».

ну вот, вспугнул сертифицированного специалиста :-)

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

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

но для полноценной системы — вряд ли: например, в дебиане (и не только) имеются циклически зависимые пакеты, и ЕМНИП apt ставит их, вызывая dpkg с ключиком --force-

>файлов кэша веб-браузера

Да вобщем-то для кешей любого типа.

разные слабые ссылки + GС

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

это, как я понимаю, только сетевые протоколы типа tcp/ip, и вряд ли

протоколы поверх него анализировались на извращенные сценарии «канал

сдох, мы перехали, и так 200 раз в секунду»

Не понимаете вы нев^%^й крутости нашего с вами линукса/юникса. :):):)

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

В случае разделяемой памяти немного сложнее - получите сигнал. Который во вменяемом протоколе типа X11 очень даже УЖЕ есть и осмыслен. Так как X11 РАССЧИТАН на то что и сервер и клиент могут пропадать :):):) По этому на это должна быть рассчитана корректная реализация MIT-SHM расширения.

Понимаете, все классические архитектурные подходы в юникс просто за счет своей немеряной трушности :) УЖЕ готовы можно сказать. Корректно работающие программы в юникс архитектуре можно сохранять и восстанавливать УЖЕ. Написаны они так. Сохранение процессов в юникс - это не хак. Это та самая настоящая «магия юникс» :)

И правильный юникс-подход к программированию это не только пайпы , все эти рассказы «юникс это *только* пайпы» это бред. Это например и группа юниксовых демонов обменивающихся через сокеты по грамотныим протоколам. И если через пайпы опенофис например не реализовать это не значит что нельзя сделать опенофис реализованный в юникс парадигме. :) Я бы даже сказал что есть потребность в опенофисе реализованном в юникс парадигме :)

>>Это та самая настоящая «магия юникс» :)

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

Слово «Вендекапец» начало появляться на ЛОРе в позитивном смысле. Так что терпи :)

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