Нет, сейчас .NET Native ограничен только UWP-приложениями.
Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
По ссылке в статье на счет «халявщиков» написано так:
Windows Store for Windows 10 has seen 6X more app downloads per device than Windows 8.
В практическом аспекте: из «традиционных» приложений вы тоже можете использовать UWP API, ну и над возможностью размещения их в магазин мы активноработаем.
Большая часть статьи далеко не про DRM, если вы читали, конечно. :)
Вообще, тема защищать или не защищать контент — это философская дискуссия, в которой может быть множество аргументов как за, так и против. Лично мое мнение состоит в том, что 1) обычный пользователь при просмотре медиа-контента не должен этого замечать и 2) есть много корпоративных сценариев, в которых это является важным (по аналогии с защищенными письмами).
Стандартной альтернативы для плагинов в контексте медиа-стриминга? Это один из ключевых сценариев использования плагинов, и это существенный стопер от для отказа от них в браузерах.
Единого стандарта для организации Live/Smooth/… стриминга? Мне лично кажется слегка неудачной для индустрии ситуацией, когда вместо того, чтобы договориться, каждый вендор продвигает что-то свое. DASH является результатом попытки договориться.
Единого механизма расширения поддерживаемых типов медиа-контента? Фактически, Media Source Extensions — это способ генерировать медиа-контент на лету и реализовывать на стороне клиента кеширование/буферинг контента, а также путь для проигрывания неподдерживаемых браузером форматов. Насколько я понимаю, такими возможностями, например, пользуется HTML5-плеер на YouTube.
Или стандартных средств шифрования там, где это является требованием индустрии? Отсутствие поддержки последнего, например, является одним из ключевых стоперов, почему online-кинотеатры не могут в браузере показывать контент того же качества, какой они отдают на телевизоры.
Конкретно WOFF 2.0 — рассматривается для внедрения, то есть в соответствии с этой статье, он «Under Consideration». По остальным не могу ничего прокомментировать — можно спросить напрямую у команды Edge.
Конкретно у asm.js сейчас несколько другая ниша, но в целом любая предсказуемость поведения программы — это возможность снять дополнительные страховки в компиляторе.
Ну для библиотеки как раз это имеет большой смысл в двух аспектах: проектирование API и выставление его наружу с подсказками для редактора через .d.ts.
Никто не говорит, что UI одинаково выглядит. Речь о том, что вы создаете единое решение, которое адаптируется под разные экраны и разные способы ввода.
В практическом аспекте: из «традиционных» приложений вы тоже можете использовать UWP API, ну и над возможностью размещения их в магазин мы активно работаем.
Вообще, тема защищать или не защищать контент — это философская дискуссия, в которой может быть множество аргументов как за, так и против. Лично мое мнение состоит в том, что 1) обычный пользователь при просмотре медиа-контента не должен этого замечать и 2) есть много корпоративных сценариев, в которых это является важным (по аналогии с защищенными письмами).
Стандартной альтернативы для плагинов в контексте медиа-стриминга? Это один из ключевых сценариев использования плагинов, и это существенный стопер от для отказа от них в браузерах.
Единого стандарта для организации Live/Smooth/… стриминга? Мне лично кажется слегка неудачной для индустрии ситуацией, когда вместо того, чтобы договориться, каждый вендор продвигает что-то свое. DASH является результатом попытки договориться.
Единого механизма расширения поддерживаемых типов медиа-контента? Фактически, Media Source Extensions — это способ генерировать медиа-контент на лету и реализовывать на стороне клиента кеширование/буферинг контента, а также путь для проигрывания неподдерживаемых браузером форматов. Насколько я понимаю, такими возможностями, например, пользуется HTML5-плеер на YouTube.
Или стандартных средств шифрования там, где это является требованием индустрии? Отсутствие поддержки последнего, например, является одним из ключевых стоперов, почему online-кинотеатры не могут в браузере показывать контент того же качества, какой они отдают на телевизоры.
Вот сравнения от команды Edge: channel9.msdn.com/Events/WebPlatformSummit/2015/Chakra-The-JavaScript-Engine-that-powers-Microsoft-Edge (24:45).
Ключевой вывод: преодолели отставание IE.
W10 — приложение будет иметь доступ к функциональности WinRT, с учетом ограничений безопасности.
Вот пример ребят из Wix: blogs.msdn.com/b/typescript/archive/2015/03/17/guest-post-gil-amran-talks-about-using-typescript-at-wix.aspx. Внутренние функции хоть на голом JS, а на стыках TS.