Метро можно вообще не открывать. Я его открываю максимум пару раз в день — когда нужно запустить программу, которой нет в супер баре или там погоду посмотреть, которая на live tile.
Про рисовать в текстуру я тоже подумал. Наверное, рано или поздно буду так делать. Но это несколько сложнее и по идее сломает весь хинтинг.
Сейчас я создаю Direct3D10.Font, который привязывается к Direct3D10.Device1. У класса Font есть метод DrawText. Как я понял, оно рисует через ID3DX10Sprite.
Спасибо за статью. Как раз начал ковырять SharpDX и сразу же столкнулся с проблемой — не смог найти более или менее вменяемого способа нарисовать текст при использовании Direct3D11.Device. Пока что проблема решались переходом на Direct3D10.Device1, но осадочек остался.
> Этот Метро он и по сути, и технически, какбе не часть системы, а какая-то надстройка что ли.
Метро — не более надстройка, чем explorer.exe с привычными окошками. По сути и технически они оба являются нативными, только основанными на разных API (WinRT и Win32). И ни один из этих API не является надстройкой над другим.
> Первый же легальный потребитель, сохранивший файл по своей уникальной ссылке, может делать с этим файлом всё, что угодно.
После чего он перестанет быть легальным потребителем.
> Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального. Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться. Можно в личку. Беспокойство самой Мозилы я понять могу — они не принимали участия в составлении спецификации — не хорошо вышло.
> А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
Идеальной защиты не бывает. Бывает только достаточный уровень защиты. В данном случае — стрим будет работать только у легальных пользователей. Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
Я уже ответил, зачем это нужно. При использовании шифрования контента нет смысла прятать ссылку. Ее смогут увидеть все и все смогут скачать файл по этой ссылке. Но это будет зашифрованный файл.
Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может — реализации этой спецификации еще нет, соответственно дыр в ее реализации тоже. Если вы найдете предположительные дыры в самой спецификации, то, пожалуйста, сообщайте о них w3c.
> Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Спецификация не предполагает использование конкретного алгоритма шифрования. Поэтому я не могу ни подтвердить, ни опровергнуть слова представителя Netflix (если он действительно такое говорил).
> И зачем всё это шифровать?
Напомню, что предложенный черновик спецификации — это не замена HTMLMediaElement, а расширение. Если разработчику не нужно ограничение доступа к его видео — он не обязан использовать шифрование. Если нужно, то шифрование самого контента — самый очевидный способ защиты.
Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету. При этом нет возможности убедиться, что этой ссылкой воспользовался именно тот человек, кому она предназначена. Предложенный в спецификации алгоритм обмена ключами решает эту проблему.
> Где место СПО в стандарте, я вас спрашиваю?
Мне искренне жаль разработчиков проигрывателей DVD и Blu-ray, но сейчас речь не о них. Если вы уделите немного времени на прочтение самой спецификации, то убедитесь, что нет никаких причин считать, что open source разработчики будут ущемлены в правах. Спецификация не предполагает использование зашитых мастерключей, закладок и покупку сертификатов. Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
> И зачем всё это?
Затем, что стриминг видео контента может стать неплохим бизнесом и возможно даже вытеснить диски. Как я понял, предложенный черновик спецификиции может стать заменой всяческим велосипедам по организации стриминга видео по подписке или с иными видами ограниченного доступа. У разработчика будет API для реализации клиентского приложения на javascript.
> В каком месте будет находиться указанный на схеме CDM в случае СПО?
В том же месте, где находятся кодеки для воспроизведения видео.
Почему отберут? От клиента требуется лишь возможность исполнять javascript. Даже ключи и те хранятся не у клиента, а получаются по требованию от сервера. Например, только авторизованным пользователям. Так что переносить с одного компьютера на другой клиенту фактически нечего.
Вы бы сначала спецификацию просмотрели, прежде чем делать выводы — DRM это или нет. Речь идет всего лишь о возможности для всех отдавать один зашифрованный видеопоток, который расшифровать и воспроизвести смогут лишь обладатели ключей. Такая возможность востребована и сейчас ее реализуют кто как может.
Как это связано с защитой от копирования, которой DRM по сути и является, — я не понимаю. Как это сможет причинить неудобства для легальных пользователей — у меня тоже идей нет.
Обмен чего на что? Выкладывание фильма в торренты — это распространение. При том неограниченное. С юридической точки зрения это не должно отличаться от штамповки копий диска с фильмом и последующей раздачи этих копий всем желающим. При этом не имеет значения, была ли оригинальная копия фильма лицензионной — прав на распространение у владельца копии в любом случае не будет.
Отсутствие материальной выгоды у распространителя не отменяет того факта, что он нелегально использовал объект авторского права и, соответственно, нарушил закон. При наличии материальной выгоды на распространителя могут повесить еще парочку статей, которые к торрентам имеют уже слабое отношение. Например, незаконную предпринимательскую деятельность.
Распространителем в случае с торрентами является в первую очередь сидер. С админами все сложнее и, вероятно, нелегальное использование на них повесить будет очень сложно. Все остальное, что можно попытаться повесить на админов, не касается непосредственно торрента.
Как раз нет. Будешь хорошим программистом в вакууме. Не обязательно даже менять язык. Просто перейти из одной области применения в другую. Сразу потребуется изменить свое мышление, подход к написанию кода. То, что раньше было можно, сейчас уже нельзя и наоборот. То, что раньше было легко, сейчас сложно и наоборот. Похожие чувства я испытал, когда начал копать в сторону XNA, имея при этом опыт с WinForms, WPF и прочим.
Сейчас я создаю Direct3D10.Font, который привязывается к Direct3D10.Device1. У класса Font есть метод DrawText. Как я понял, оно рисует через ID3DX10Sprite.
Метро — не более надстройка, чем explorer.exe с привычными окошками. По сути и технически они оба являются нативными, только основанными на разных API (WinRT и Win32). И ни один из этих API не является надстройкой над другим.
После чего он перестанет быть легальным потребителем.
> Mozilla уже сказали своё слово, нормального ответа нет. Ни от кого, от вас в том числе.
Я обладаю той же информацией, что и вы — текст спецификации. По крайней мере я его прочитал и не увидел ничего криминального. Если вас беспокоит какой-то конкретный пункт — пожалуйста, приведите его, и мы вместе попытаемся разобраться. Можно в личку. Беспокойство самой Мозилы я понять могу — они не принимали участия в составлении спецификации — не хорошо вышло.
> А если контент будет эксклюзивным, его всё равно украдут в первые же часы, перечисленным выше способами.
Идеальной защиты не бывает. Бывает только достаточный уровень защиты. В данном случае — стрим будет работать только у легальных пользователей. Нелегальным придется довольствоваться торрентами, что, согласитесь, не так удобно, как зайти на сайт, нажать кнопку и сразу же получить контент.
Комментировать, насколько легко будет рядовому пользователю расшифровать файл и сохранить его на диск я не могу и не думаю, что кто-то может — реализации этой спецификации еще нет, соответственно дыр в ее реализации тоже. Если вы найдете предположительные дыры в самой спецификации, то, пожалуйста, сообщайте о них w3c.
> Если всё так, то зачем представитель Netflix писал об использовании не-свободных дополнений для расшифровки?
Спецификация не предполагает использование конкретного алгоритма шифрования. Поэтому я не могу ни подтвердить, ни опровергнуть слова представителя Netflix (если он действительно такое говорил).
Напомню, что предложенный черновик спецификации — это не замена HTMLMediaElement, а расширение. Если разработчику не нужно ограничение доступа к его видео — он не обязан использовать шифрование. Если нужно, то шифрование самого контента — самый очевидный способ защиты.
Поправьте меня, если я не прав, но сейчас приходится решать эту проблемы всячески скрывая прямую ссылку на видео поток или генерируюя ее на лету. При этом нет возможности убедиться, что этой ссылкой воспользовался именно тот человек, кому она предназначена. Предложенный в спецификации алгоритм обмена ключами решает эту проблему.
> Где место СПО в стандарте, я вас спрашиваю?
Мне искренне жаль разработчиков проигрывателей DVD и Blu-ray, но сейчас речь не о них. Если вы уделите немного времени на прочтение самой спецификации, то убедитесь, что нет никаких причин считать, что open source разработчики будут ущемлены в правах. Спецификация не предполагает использование зашитых мастерключей, закладок и покупку сертификатов. Она состоит лишь из алгоритма обмена ключами, API под javascript и подразумевает использование стандартных алгоритмов дешифрования, таких как AES.
Затем, что стриминг видео контента может стать неплохим бизнесом и возможно даже вытеснить диски. Как я понял, предложенный черновик спецификиции может стать заменой всяческим велосипедам по организации стриминга видео по подписке или с иными видами ограниченного доступа. У разработчика будет API для реализации клиентского приложения на javascript.
> В каком месте будет находиться указанный на схеме CDM в случае СПО?
В том же месте, где находятся кодеки для воспроизведения видео.
Как это связано с защитой от копирования, которой DRM по сути и является, — я не понимаю. Как это сможет причинить неудобства для легальных пользователей — у меня тоже идей нет.
Отсутствие материальной выгоды у распространителя не отменяет того факта, что он нелегально использовал объект авторского права и, соответственно, нарушил закон. При наличии материальной выгоды на распространителя могут повесить еще парочку статей, которые к торрентам имеют уже слабое отношение. Например, незаконную предпринимательскую деятельность.
Распространителем в случае с торрентами является в первую очередь сидер. С админами все сложнее и, вероятно, нелегальное использование на них повесить будет очень сложно. Все остальное, что можно попытаться повесить на админов, не касается непосредственно торрента.
Я что-то пропустил? Это было давно и очень не долго.