Здравствуйте, gandjustas, Вы писали:
CS>>managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов. CS>>Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно. CS>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
Аккуратнее со словами если хочешь чтобы тебя уважали в профессиональной среде.
Вот тебе основы: http://chaoticjava.com/posts/how-does-garbage-collection-work/
Если облом читать то можешь послушать например здесь как устроен heap/GC в V8 от Google: http://www.youtube.com/watch?v=FrufJFBSoQY
Как минимум young generation heap состоит из двух половин одна из которых не используется в отдельно взятый момент времени.
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
О, а это еще откуда? И что здесь есть N ? В managed heap N это общее количество аллоцированных (т.е. managed) объектов.
N можно сократить за счет generations но не сильно. Но в теории GC это всегда O(N). Если тебе известен другой способ — ссылку приведи.
Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника.
Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
CS>>>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>>>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>Думаешь я не знаю как работает GC?
Судя по твоей бурной реакции я подозреваю что нет.
CS>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>фрагменту RAM предварительно отобранных у системы "про запас". G>Ты про mem_reserve не слышал чтоли?
Если mem_reserve это MEM_RESERVE то упоминание этого флага можно найти здесь: http://code.google.com/p/tiscript/source/browse/trunk/int/cs_heap.cpp
Это код моего TIScript. (Credits for VirtalAlloc there go to Дмитрий Якимов)
G>>>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
CS>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
О как. Ну глянь в исходники по ссылкам вверху. Покажи мне то место где "выделение будет (N)".
CS>>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история. G>Основная проблема unmanaged heap в том что этот хип unmanaged. Единственное преимущество, которое потенциально можно получить, это использование оптимальной для задачи стратегии выделения и освобождения памяти.
Ну дык и я о чем говорю? Есть задачи для которых non-managed heap оптимален и есть задачи для которых managed heap — самое оно.
Истина в том что ты должен иметь возможность выбирать оптимальный heap manager для конкретной подсистемы.
Если кто-то говорит "мы все будем писать managed" то на таком проекте можно ставить крест. Ибо посыл неверный.
G>>>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>>>Это еще refcounting никто там не занимался. G>>>Ты такие наивные глупости говоришь.
CS>> Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого. G>Снова наивные глупости. Цена переписывания во много раз больше выгод от этого.
Тем не менее WP7 была переписана несмотря на цену. Но IE там кстати нативный.
CS>>А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?" CS>>Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да. G>Когда начинают говорить о refcounting как раз GC становится "по делу".
Одна из форм GC есть ref counting. Т.е. что ты имеешь ввиду?
CS>>В прошлую среду кстати был в Evernote. Они сделали попытку написать Evernote 3.5 в WPF/.NET. CS>>Дело закончилось Evernote 4.0 как сугубо native application. G>Ну видимо ниасилили.
Искренне желаю тебе достичь их уровня.
CS>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>Докажи выделенное. CS>>Что конкретно доказать осталось? G>Оптимальность.
Здравствуйте, gandjustas, Вы писали:
CS>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти.
CS>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>Тоже бред.
Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае).
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
Никогда он не был таким. Там всегда было амортизованное O(1).
CS>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>Думаешь я не знаю как работает GC?
Видимо.
CS>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>фрагменту RAM предварительно отобранных у системы "про запас". G>Ты про mem_reserve не слышал чтоли?
Не получится, большая часть памяти один фиг закоммитится.
CS>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>Докажи выделенное. CS>>Что конкретно доказать осталось? G>Оптимальность.
Практика...
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, gandjustas, Вы писали:
CS>>>managed heap отбирает у системы памяти заведомо больше чем нужно для представления объектов. CS>>>Как правило чтобы GC себя комфортно чувствовал он должен у системы отобрать в два раза больше памяти чем нужно. CS>>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова?
CS>Аккуратнее со словами если хочешь чтобы тебя уважали в профессиональной среде.
CS>Вот тебе основы: CS>http://chaoticjava.com/posts/how-does-garbage-collection-work/ CS>Если облом читать то можешь послушать например здесь как устроен heap/GC в V8 от Google: CS>http://www.youtube.com/watch?v=FrufJFBSoQY CS>Как минимум young generation heap состоит из двух половин одна из которых не используется в отдельно взятый момент времени.
1)MEM_RESERVE. память не обязательно отбирать у кого-либо до того как она будет использована.
2)Каков размер этого young generation heap? Я так понимаю даже мегабайта не будет.
CS>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
CS>О, а это еще откуда? И что здесь есть N ? В managed heap N это общее количество аллоцированных (т.е. managed) объектов. CS>N можно сократить за счет generations но не сильно. Но в теории GC это всегда O(N). Если тебе известен другой способ — ссылку приведи.
Для GC N — количество живых объектов. Для list-based алокатора N может быть количество выделенных блоков или количеством свободных блоков (эти величины линейно зависимы)
CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
CS>>>>>managed heap отлично справляется с аллокацией мелких объектов. Инкремент указателя фактически. Но на предаврительно и с большим запасом отобранной у системы памяти прошу заметить. G>>>>Во-первых зачем она системе? Во-вторых зачем заранее отбирать у системы больше памяти?
CS>>>Почитай основы GC, скажем http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Implementation_strategies G>>Думаешь я не знаю как работает GC? CS>Судя по твоей бурной реакции я подозреваю что нет.
Где ты увидел бурную реакцию?
CS>>>Аллокация в GC heap дешевая только тогда когда она сводится к alloactedPtr += requiredSize. Этот alloactedPtr указывает на позицию в буффере — CS>>>фрагменту RAM предварительно отобранных у системы "про запас". G>>Ты про mem_reserve не слышал чтоли?
CS>Если mem_reserve это MEM_RESERVE то упоминание этого флага можно найти здесь: CS>http://code.google.com/p/tiscript/source/browse/trunk/int/cs_heap.cpp CS>Это код моего TIScript. (Credits for VirtalAlloc there go to Дмитрий Якимов)
Ну так ты понял что заранее отбирать не надо?
G>>>>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)? (правда там N разные)
CS>>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
CS>О как. Ну глянь в исходники по ссылкам вверху. Покажи мне то место где "выделение будет (N)".
Там выделение с O(1) за счет оверхеда по памяти. Чудес не бывает, есть tradeoffs, где-то они уместны, а где-то нет.
CS>>>Основная проблема в unmanaged heap это проблема фрагментации. Но это другая история. G>>Основная проблема unmanaged heap в том что этот хип unmanaged. Единственное преимущество, которое потенциально можно получить, это использование оптимальной для задачи стратегии выделения и освобождения памяти.
CS>Ну дык и я о чем говорю? Есть задачи для которых non-managed heap оптимален и есть задачи для которых managed heap — самое оно.
Не бывает в общем случае оптимального unmanaged heap, можно сделать свой хип, оптимальный для конкретной задачи.
CS>Истина в том что ты должен иметь возможность выбирать оптимальный heap manager для конкретной подсистемы.
Да ну, 90% приложений вполне успешно будут работать с GC.
G>>>>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC? G>>>>Это еще refcounting никто там не занимался. G>>>>Ты такие наивные глупости говоришь.
CS>>> Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого. G>>Снова наивные глупости. Цена переписывания во много раз больше выгод от этого.
CS>Тем не менее WP7 была переписана несмотря на цену. Но IE там кстати нативный.
Куда переписана? Внутри там Windows CE новой версии и .NET CF. Это для разработчиков API на XNA и SL.
Как раз для того чтобы каждый кто умеет программить на C# смог писать для WP7, они об этом в открытую говорят.
CS>>>А вопрос что лучше managed или non-managed heap он имеет ту же ценность что и "мальчик, ты кого больше любишь — маму или папу?" CS>>>Т.е. и то и то хорошо если употреблено по делу — а не квадратно-гнездовым образом. Silver bullets их таки нет, да. G>>Когда начинают говорить о refcounting как раз GC становится "по делу". CS>Одна из форм GC есть ref counting. Т.е. что ты имеешь ввиду?
Да, только в нем есть критические недостатки.
CS>>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>>Докажи выделенное. CS>>>Что конкретно доказать осталось? G>>Оптимальность.
CS>Оптимальность для какой задачи?
Для того же дерева, dom или еще ченить.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
CS>>>Т.е. если у тебя есть скажем DOM tree в памяти то managed heap'у нужен space в два раза больше. G>>Ну это бред. Может у тебя пруфлинк есть, подтверждающий твои слова? C>Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти.
В среднем — да, потому что освобождение позже происходит. Но "метрвые" объекты нас не интересуют, они могу даже в своп уходить и на работе приложения это не скажется. А вот для живых объектов выделяется столько памяти сколько нужно.
CS>>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>>Тоже бред. C>Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае).
Я про выделенное.
CS>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N) C>Никогда он не был таким. Там всегда было амортизованное O(1).
Да ну?
CS>>>>>У меня есть конкретные примеры. Sciter есть система в которой используется и детерминированый heap и managed (TIScript VM). Там где они нужны и оптимальны. G>>>>Докажи выделенное. CS>>>Что конкретно доказать осталось? G>>Оптимальность. C>Практика...
Какая практика? Практика как раз показывает что в сложных системах GC рулит, а на unmanaged то утечки, то расстрелы, то тормоза.
Естественно это касается средних программистов, а не супер-гениев.
Здравствуйте, gandjustas, Вы писали:
C>>Это известный практический результат. Хороший GC работает так же быстро, как и ручное управление памятью, но требует в 2-5 раз больше памяти. G>В среднем — да, потому что освобождение позже происходит. Но "метрвые" объекты нас не интересуют, они могу даже в своп уходить и на работе приложения это не скажется. А вот для живых объектов выделяется столько памяти сколько нужно.
Не могут. Приложения с GC совершенно не дружат со свопом. Молодые поколения слишком "горячие" для свопа, а если засвопить старое поколоение, то первый же full scan убивает систему, да проверка обратных ссылкок из старшего поколения тоже не сахар.
Точнее, есть swap-friendly алгоритмы, но у них свои недостатки. В G1GC что-то на эту тему есть, надо почитать...
CS>>>>Если же размер heap равен размеру этого самого DOM tree то каждая следующая аллокация будет приводить к полномоу GC. Т.е. O(N) операция. G>>>Тоже бред. C>>Ничуть. Сложность GC — это O(N), где N — это количество выживших объектов (в лучшем случае). G>Я про выделенное.
Почему? Это вполне реальный вырожденный случай. Скажем, Java в таких случаях после пары минут работы падает с исключением, что максимальная доля времени GC превышена.
CS>>>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>>>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N) C>>Никогда он не был таким. Там всегда было амортизованное O(1). G>Да ну?
Ну да. Читай исходники, они рулез.
CS>>>>Что конкретно доказать осталось? G>>>Оптимальность. C>>Практика... G>Какая практика? Практика как раз показывает что в сложных системах GC рулит, а на unmanaged то утечки, то расстрелы, то тормоза.
Руки надо править, значит. GC хорош для сложных модульных приложений, где схема владения объектами неясна.
Здравствуйте, gandjustas, Вы писали:
g> CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. g> CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
g> Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Здравствуйте, hattab, Вы писали:
H>Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Мы делали на своем аллакаторе сбор статистики и по результатам прогонов на реальных данных корректировали размеры блоков и пулов, оверхед максимум 10% получался. Кстати на мелких объектах (4 — 16 байт) памяти кушалось меньше чем стандартным аллакатором.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> CS>Вот тебе имплементация быстрого thread local allocator http://www.garret.ru/threadalloc/readme.html от Константина Книжника. g>> CS>Там все просто и прозрачно. Можно посмотреть Doug Lee malloc. В целом работа malloc() и free() функций в C/C++ не зависит от количества аллоцированных объектов. Вернее если и зависит то весьма незанчительно. Во всяком случае далеко не O(N).
g>> Если не O(N) тогда оверхед по памяти большой. Например на выделение блоков по 68 байт будут реально расходоваться блоки по 128.
H>Не гони. Никто не будет делать пулы с блоками дающими 50% оверхед. У дельфийского fastmm градация пулов для мелких (<= 156) блоков всего 8 байт, потом (<= 348) 16 байт, затем 32 байта и т.д. (но градация не в геометрической прогрессии), чем больше градация тем меньше пулов на этом промежутке. У fastmm всего 55 пулов, плюс 2 пула для средних и больших (> 256Kb) блоков. Я тебе уже как то говорил, что в работающем, нагруженном delphi-приложении эффективность расходования памяти составляет 95% (это мониторится средствами самого fastmm).
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Чтото я не понял что МС собирается с сильверлайтом сделать? Примораживают разработку в пользу хтмл5? S>Я просто в англицком не очень...
Так и есть. Флеш простудится на похоронах Сильверлайта.
Здравствуйте, Niemand, Вы писали:
VV>>Не понятно откуда вы это взяли. Написано англиским по белому. Сильверлайт никто не кидает, но в связи с выходом html5 сменился фокус на реально кроссплатформенную платформу ( ). А сильверлайт так и остается.
N>макрос "а Х так и остается" — один из любимых у майкрософта. Лично я утратил веру когда они выпустили бэту winFS, а потом сказали "а winFS так и остается, только войдет в другие проекты, а не будет самостоятельным продуктом". И ни гу-гу с тех времен. Вот и сильвер для веба "так и остается"
Из ВинФС к нам пришли FILESTREAM блобы в SQL 2008!
И по мелочевке в Win7 типа libraries.
Здравствуйте, c-smile, Вы писали:
CS>Но вот что интересно. Примерно на одном и том же железе iPhone (native code) как-то по ощущениям лучше работатет чем Android (Java). CS>В свете последних событий я так понимаю Oracle дожмет Google и последний будет вынужден перейти на Android на С или что-то близкое ему.
Здравствуйте, midcyber, Вы писали:
M>Только пацанам не говори, что у них в социальных сетях весь медиаконтент на флеше, ок?
Социальные сети от порнобаннеров не далеко ушли.
Здравствуйте, gandjustas, Вы писали:
G>Ниче что аллокация и освобождение памяти в unmanaged heap чаще всего тоже O(N)?
Опять ты гонишь пургу? В каком это промышленном unmanaged heap операции O(N)?
G>(правда там N разные)
Чего???
G>Ниче что конкретная реализация heap в windows сосет на массовых выделениях-освобождениях памяти по сравнению с .NET GC?
Ты смотри, уже научился хоть где то не писать фигню про generic аллокатор.
G>Ты такие наивные глупости говоришь.
В плане знаний об unmanaged ты ничуть не отстаёшь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
CS>>Что явно больше чем в C heap где аллокация стоит от O(1) до O(log(N)) (очень крайний случай). G>Что такое C heap? Вот компилятор MS использует виндовый хип, который еще пару лет назад был очень даже O(N). GCC видел очень давно, но там тоже ,sk хип с асимптотикой O(N)
Пару лет это 2 года.
Тот же LFH появился в WinXP, т.е. в 2002м году. Т.е. 8 лет назад уже в винде аллокация была на пулах.
CS>>Тебя обманули. Освобождение памяти в unmanaged heap это опреация O(1) — удалить элемент из одного двухсвязанного списка и поместить в другой (free blocks list). Если при этом еще исполняется объединение блоков то больше чем O(1). То же самое или близкое к тому и с выделением. G>Даже если использовать двусвязный список все равно выделение будет (N). Кроме того двусвязный список дает больший оверхед.
Иди учи алгоритмы. Или ты кроме тупого перебора никаких других алгоритмов выбора оптимального блока не знаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, olegkr, Вы писали:
M>>Только пацанам не говори, что у них в социальных сетях весь медиаконтент на флеше, ок? O>Социальные сети от порнобаннеров не далеко ушли.
Ну тогда не говори, что "Флеш уже сдох везде". Не сдох, и в ближайшее время, похоже, не сдохнет. Смартклиенты, сильверлайты, вэпээфы и джава эфиксы приходят и уходят, в флеш-курилка жив, только простужается иногда на похоронах очередных "убиец флеша".
Я не один такие глупости говорю. Скажем разработчики Windows не стали писать систему на .NET. Хотя у них все инструменты есть для этого.
