Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FR, Вы писали:

WH>>>Это смотря кто пишет. Если комманды сравнимой квалификации то будет именно так как я описал. А если комманды разной квалификации то сранения теряет смысл.

FR>>Для рынка не теряют.
FR>>И зависит не только от квалификации но и от опыта команд
WH>Гм... опыт и квалификация корелируют ну очень сильно.

Опыт бывает разный, например много лет на C++, и переход такой команды на тот же NET может ничего ни дать.

FR>>и их (не)желания переучиватся.
WH>Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...

Какой процесс?

WolfHound wrote:
> В любом случае ты не понял главного: Такие ОС нужны для обеспечение
> стабильной работы системы, а не для того чтобы небыло переключения
> контекстов.
ОС со стабильной работой даже в присутствие _аппаратных_ сбоев уже лет
30 существуют.

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

Так что проблема надежности уже давно решена. Остается проблема скорости
— в этом направлении сейчас тоже активно копают, можно почитать ответы
Таненбаума Линусу. Возможно, скоро Mac OS X станет первой
consumer-версией ОС с микроядром.

WolfHound wrote:
> C>А почему "в сад" должен отправляться D, а не C#?
> По тому что C# (если не использовать конструкцию unsafe которая на
> практике нафиг не упала) в отличии от D safe.
Где он safe??? В нем же есть race condition'ы!!! Все надо писать
исключительно на Erlang — там RC нет.

> Допустим появились два приложения одно чуть быстрее, ест меньше памяти и
> иногда падает и второе чуть медленней, ест несколько больше памяти и
> работает стабильно.
Нет. "Допустим появились два приложения одно чуть быстрее, ест меньше
памяти и иногда падает и второе чуть медленней, ест несколько больше
памяти и иногда падает". Ну не вижу я, что увеличение безопасности языка
приводит к менее глючному софту.

Например, у меня Eclipse для С++ глючит примерно так же как и Студия.
Eclipse написана на Java (если не считать 100Кб кода на С для SWT).

> C>А зачем вообще нужен .NET?
> Чтобы проще и быстрее создовать болие качественные программы.
Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил, но
в других случаях (типа моего приложения) затраты на оптимизацию на C#
съедают все приросты в скорости разработки.

Здравствуйте, FR, Вы писали:

FR>>>и их (не)желания переучиватся.
WH>>Вот те которые не желают переучитваться (не буду показывать пальцем но тут таких много) и тормозят процесс...

FR>Какой процесс?

Да нет никакого процесса, мы все здесь силно заняты, однако заняты ничем.
В суете бесконечной увязнув, что затихнет лишь с гибелью мира... (Бхагават Гита)

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

Здравствуйте, Cyberax, Вы писали:

C>Андрей Хропов wrote:
>> C>Программист. Если хочет — пусть пишет хоть на brainfuck'е в новой
>> C>супербезопасной EverFuckVirtualMachine от MS. Главное, чтобы остальным
>> C>это не мешало.
>> Ответил здесь <http://rsdn.ru/forum/Message.aspx?mid=1912518&amp;only=1&gt;

Автор: Андрей Хропов
Дата: 23.05.06

.
C>А как насчет D, например?
Ну он старый-добрый native code.
Даже с asm встроенным.
Очень неплохо для многих применений, если его доделают
+ портабельный с GCC backendом.

C>Он тоже под SuperManagedOS работать не будет.
В таком виде как сейчас не будет.
Но это ж open-source.
Можно как в C# сделать safe/unsafe mode, если люди захотят.
Там просто люди в основном старой C++ школы, для них это не приоритет на данный момент.

>> А вообще есть классический пример: Re: Частые вычисления по
>> неопределенной формуле!!!
>> <http://rsdn.ru/forum/Message.aspx?mid=630887&amp;only=1&gt;

Автор: VladD2
Дата: 07.05.04

.
C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда
C>такое понадобилось.
Тем не менее, встроенный компилятор под рукой — удобно.
Что грамотно использовали разработчики Nemerle при создании системы метапрограммирования.


C>Сингулярити не позволяет НАПРЯМУЮ использовать:
C>1. Машинный код и языки компилирующие в него.
Много языков уже перевели на .NET.

C>2. Ручное управление памятью.
В некоторых случаях это действительно недостаток,
но в любом случае Singularity — это только прототип.

Андрей Хропов wrote:
> Можно как в C# сделать safe/unsafe mode, если люди захотят.
Ты не понял. Singularity ВООБЩЕ запрещает unsafe. В любом его виде.

> C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда
> C>такое понадобилось.
> Тем не менее, встроенный компилятор под рукой — удобно.
Boost.Python, и ващи волосы будут мягкими и щелковистыми.

> C>Сингулярити не позволяет НАПРЯМУЮ использовать:
> C>1. Машинный код и языки компилирующие в него.
> Много языков уже перевели на .NET.
И все они изоморфны C# или сделаны через полную Ж.

> C>2. Ручное управление памятью.
> В некоторых случаях это действительно недостаток,
> но в любом случае Singularity — это только прототип.
В fully managed OS типа Singularity в принципе не может быть unsafe.

Здравствуйте, Cyberax, Вы писали:

C>Где он safe??? В нем же есть race condition'ы!!! Все надо писать
C>исключительно на Erlang — там RC нет.
Осталось понять как RC может испортить память.

C>Нет. "Допустим появились два приложения одно чуть быстрее, ест меньше памяти и иногда падает и второе чуть медленней, ест несколько больше памяти и иногда падает". Ну не вижу я, что увеличение безопасности языка приводит к менее глючному софту.
А я вижу.

C>Например, у меня Eclipse для С++ глючит примерно так же как и Студия.
C>Eclipse написана на Java (если не считать 100Кб кода на С для SWT).
Теперь осталось сравнить сколько сил вложили в Eclipse и студию.

C>Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил, но в других случаях (типа моего приложения) затраты на оптимизацию на C# съедают все приросты в скорости разработки.
Пока я не видел ни одного случая который нельзя былобы легко оптимизировать.

Здравствуйте, Cyberax, Вы писали:

C>Защита достигается разделением и максимальной изоляцией всего, что только разделяется и изолируется. В качестве примера я уже приводил QNX — его используют на ядерных электростанциях, а его ядро представляет из себя небольшой кусок кода.
Блин. ОС для ядерных станций. Болие тепличных условий придумать нельзя. Тем весь код тестируют (а то и доказывают) так что никакой другодй системе и не снилось. Плюс там не вирусов и прочих хакеров.

C>Так что проблема надежности уже давно решена. Остается проблема скорости — в этом направлении сейчас тоже активно копают, можно почитать ответы Таненбаума Линусу. Возможно, скоро Mac OS X станет первой consumer-версией ОС с микроядром.
И как это спасет от внедрения вредоносного кода через переполнение буфера?

Здравствуйте, Cyberax, Вы писали:

C>В fully managed OS типа Singularity в принципе не может быть unsafe.
В принципе они могут создавать песочници при помощи все тойже виртуализации адресных пространств.

Kluev,

FR>>Какой процесс?

K>Да нет никакого процесса, мы все здесь силно заняты, однако заняты ничем.
K>В суете бесконечной увязнув, что затихнет лишь с гибелью мира... (Бхагават Гита)

K>З.Ы. Сколько раз я не пытался завязать с программированием и просто спокойно кодировать, ничего не выходило остается надеятся, что со временему уму это надоест и все само собой отвалится.

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

Другое дело, что можно научиться управлять своим огнём, и тут нужен качественный шаг, а не ещё один ЯП/ОС...

WolfHound wrote:
> C>Где он safe??? В нем же есть race condition'ы!!! Все надо писать
> C>*исключительно* на Erlang — там RC нет.
> Осталось понять как RC может испортить память.
Да как два пальца:

public class A
{
    public A someVar;
};
A.someVar=someAClass;

на 64-битных машинах с неатомарными 64-битными операциями. Для JVM даже
такой эксплоит на Sparc'е был.

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

> C>Например, у меня Eclipse для С++ глючит примерно так же как и Студия.
> C>Eclipse написана на Java (если не считать 100Кб кода на С для SWT).
> Теперь осталось сравнить сколько сил вложили в Eclipse и студию.
Ты сам это сказал. Глючность программы зависит от вложенного труда.

> C>Не вижу этого. .NET заменяет С++ там, где С++ раньше плохо подходил,
> но в других случаях (типа моего приложения) затраты на оптимизацию на C#
> съедают все приросты в скорости разработки.
> Пока я не видел ни одного случая который нельзя былобы легко оптимизировать.
Я тебе его показал.

WolfHound wrote:
> Блин. ОС для ядерных станций. Болие тепличных условий придумать нельзя.
> Тем весь код тестируют (а то и доказывают) так что никакой другодй
> системе и не снилось. Плюс там не вирусов и прочих хакеров.
В QNX в нулевом кольце выполняется около 100Кб кода. Его можно под
микроскопом посмотреть и доказать корректность — все остальное работает
как пользовательские процессы (включая драйвера устройств).

> C>Так что проблема надежности уже давно решена. Остается проблема
> скорости — в этом направлении сейчас тоже активно копают, можно почитать
> ответы Таненбаума Линусу. Возможно, скоро Mac OS X станет первой
> consumer-версией ОС с микроядром.
> И как это спасет от внедрения вредоносного кода через переполнение буфера?
Делаем Code Access Security с гранулярностью равной процессу, и пусть
оно себе переполняет что хочет.

WolfHound wrote:
> C>В fully managed OS типа Singularity в принципе не может быть unsafe.
> В принципе они могут создавать песочници при помощи все тойже
> виртуализации адресных пространств.
И для этой песочницы придется делать свою ОС (так как песочница должна
быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян?

Здравствуйте, Cyberax, Вы писали:

C>на 64-битных машинах с неатомарными 64-битными операциями. Для JVM даже такой эксплоит на Sparc'е был.
Мда... автор этой железки зажигает... а ты говоришь проверки в железе реализовать...

C>Да и вообще, ведь RC и дедлоки на многопоточных приложениях приводят к сложноуловимым ошибкам. Так что все обязаны использовать Erlang. Или ты любишь глючный софт?
Нет всем переходить под сингулирити. Там тоже общение через асинхронную посылку сообщений происходит.

C>Ты сам это сказал. Глючность программы зависит от вложенного труда.
Это отрицать также глупо как отрицать зависимость качества софта от инструмента на котором этот софт изготовлен.

C>Я тебе его показал.
Ты показал мааленький кусочек программы. Тут нужна оптимизация на архитектурном уровне. И той информации что ты дал совершенно не достаточно.
Примерно как в этом

Автор: Fahrain
Дата: 13.05.06

случае. Пока из братка информацию не вытянул как отимизировать было непонятно.

Здравствуйте, Cyberax, Вы писали:

C>Андрей Хропов wrote:
>> Можно как в C# сделать safe/unsafe mode, если люди захотят.
C>Ты не понял. Singularity ВООБЩЕ запрещает unsafe. В любом его виде.
Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать
на Managed OS, достаточно будет переписать только unsafe кусок
(который, если грамотно делать, будет небольшим).
Что видимо и будет происходить с C# приложениями при возможном переходе на fully managed OS.

>> C>Ну и как часто это надо? Я в своей практике не помню ни разу, когда
>> C>такое понадобилось.
>> Тем не менее, встроенный компилятор под рукой — удобно.
C>Boost.Python, и ващи волосы будут мягкими и щелковистыми.
Ну и что умеет компилировать boost.python ?
Он позволяет писать скрипты, использующие C++ классы/функции, это другое.
Да и то придется работать со всякими PyObject.

Для примера можешь привести реализацию того примера на boost.python
с временными характеристиками, было бы интересно.

>> C>Сингулярити не позволяет НАПРЯМУЮ использовать:
>> C>1. Машинный код и языки компилирующие в него.
>> Много языков уже перевели на .NET.
C>И все они изоморфны C# или сделаны через полную Ж.
Насколько я знаю IronPython тормозит по сравнению с нативным
(и тем более Psyco), значит (пока ?) да.
Может люди знающие что-нибудь скажут про F# (суть OCaml) и про другие?

WolfHound,

C>>Где он safe??? В нем же есть race condition'ы!!! Все надо писать
C>>исключительно на Erlang — там RC нет.
WH>Осталось понять как RC может испортить память.

RC — это пример логической ошибки. Никакой рантайм не спасёт от логических ошибок.

Я приведу простейший пример:

drawRect(100, 200, 300, 400); // вызывается эта функция, но что же нарисуется?
//
drawRect(int x, int y, int w, int h);
drawRect(int x0, int y0, int x1, int y1);
drawRect(int x0, int x1, int y0, int y1);

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

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

Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме.

PS: Плюс Киберакс писал, что N(RE) можно сколь угодно приблизить к нулю с помощью современных средств разработки и отладки.

Здравствуйте, Cyberax, Вы писали:

C>И для этой песочницы придется делать свою ОС (так как песочница должна быть ПОЛНОСТЬЮ отделена от основной ОС). Вопрос: нафига козе баян?
А вот это уже не факт. Все что нужно это обеспечить поддержку типизированных каналов.
Да по сраврению с чистой управляемой ОС придется несколько усложнить менеджер памяти и систему управления потоками. Но писать ОС с нуля ненужно.
Общение между песочнецой и другими процессами будет конечно несколько медленней чем эти процессы общаются между собой но это плата за нативный код.

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

Здравствуйте, Cyberax, Вы писали:

C>В QNX в нулевом кольце выполняется около 100Кб кода. Его можно под микроскопом посмотреть и доказать корректность — все остальное работает как пользовательские процессы (включая драйвера устройств).
Атаковать само ядро не обязательно.

C>Делаем Code Access Security с гранулярностью равной процессу, и пусть оно себе переполняет что хочет.
Ну оно и в современных ос так только вто что-то вирусам на это начхать.

Андрей Хропов wrote:
>> > Можно как в C# сделать safe/unsafe mode, если люди захотят.
> C>Ты не понял. Singularity *ВООБЩЕ* запрещает unsafe. В любом его виде.
> Регулятор safe/unsafe позволяет разделить код и, если надо будет портировать
> на Managed OS, достаточно будет переписать только unsafe кусок
> (который, если грамотно делать, будет небольшим).
> Что видимо и будет происходить с C# приложениями при возможном переходе
> на fully managed OS.
А что будет с С++-приложениями? Или с вполне безопасными Python и
Ruby-приложениями, для которых нет нормальных интерпретаторов под .NET?

> C>Boost.Python, и ващи волосы будут мягкими и щелковистыми.
> Ну и что умеет компилировать boost.python ?
Он умеет запускать скрипты.

> Он позволяет писать скрипты, использующие C++ классы/функции, это другое.
> Да и то придется работать со всякими PyObject.
Вот из примера:

   // A friendly class.
   class hello
   {
     public:
       hello(const std::string& country) { this->country = country; }
       std::string greet() const { return "Hello from " + country; }
     private:
       std::string country;
   };

   // A function taking a hello object as an argument.
   std::string invite(const hello& w) {
     return w.greet() + "! Please come soon!";
   }

...

BOOST_PYTHON_MODULE(getting_started2)
{
     using namespace boost::python;
     class_<hello>("hello", init<std::string>())
         // Add a regular member function.
         .def("greet", &hello::greet)
         // Add invite() as a member of hello!
         .def("invite", invite)
         ;

     // Also add invite() as a regular function to the module.
     def("invite", invite);
}

Основные классы не затрагиваются, обертка для Python абсолютно
неинтрузивная (и может быть сгенерирована автоматически с помощью Pyste).

Я могу создать нужный мне код в виде скрипты на Python, экспортировать в
него нужные мне объекты и запускать его. Так поступает CivIV, например.

> Для примера можешь привести реализацию того примера на boost.python
> с временными характеристиками, было бы интересно.
А зачем?

> C>И все они изоморфны C# или сделаны через полную Ж.
> Насколько я знаю IronPython тормозит по сравнению с нативным
> (и тем более Psyco), значит (пока ?) да.
> Может люди знающие что-нибудь скажут про F# (суть OCaml) и про другие?
F# работает быстро, но вот Haskell даже портировать не пытаются. На CLR
вообще нельзя эффективно делать динамические языки (например, если
JITить код из динамического языка в CLR, то можно очень быстро занять
всю память — так как код не собирается GC).

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Ну и на последок вишенка на тортике: для сложных систем существует закон "сложную систему невозможно формализовать полностью". А это значит, что соотношение N(LE)/N(RE) будет стремиться к бесконечности в любом рантайме.
С этим спорить также глупо как спорить с тем что при плохом рантайме система будет стремится к неуправляемому состоянию гораздо быстрее.

Ксати что за магия:N(LE)/N(RE)?