Так какие это реалии? Блюрей что ли готовят из уже пережатого? Стриминговое видео для iTunes, Netflix из уже пережатого готовят? А больше ничего интереса и не представляет в данном контексте.
А при чем здесь подготовка к раздаче ворованного контента и котиков на ютубе? h.264 это кодек, который используется в блюреях и для раздачи стримингового кино — т.е. жмется исходник. Так зачем сравнивать непонятно что, если h.265 призван его заменить? Такие статьи всегда весело читать, потому что они сравнивать не пойми что и из этого делают далеко идущие выводы о таких серьезных вещах как новый индустриальный стандарт кодирования видео.
Тут больше проблема не во мнении самом, а в том, что вы пытаетесь говорить за других. Разработчик выбрал как раз тот путь, о котором мы говорим www.virtualbox.org/wiki/Changelog-4.3 То, что они делают это не слишком успешно, уже другой вопрос.
Путем сильного переписывания драйвера под абсолютно новый API — у той же AMD даже DX11 игры серьезный прирост получили с Win10 драйверами, не говоря уже о DX12, который с прошлой версией ничего общего не имеет.
Что до андроида, то беты iOS для того и предназначены, чтобы у людей уже все работало, а не приходили такие вот разработчики — а нафиг оно мне надо, оно еще не вышло и 10 раз поменяется. Про консоли тем более хороший пример — там предварительные dev-киты очень сильно меняются и порой разработчики ловят много проблем, а ведь вначале они вообще для ПК со схожей производительностью пишут, а не для хотя бы тестового железа консоли, но по-другому никак. Игры и платформа должны выходить одновременно.
Все оказалось намного проще. Из интернета загружаются только JSON, внутри которых нет функций — просто набор HTML тегов и их атрибуты. Все, что содержит код, скачивается вместе с приложением и лежит среди ресурсов. Все как требует Apple.
Противоречие тут в другом. Вместо того, чтобы выбрать простой и надежный путь — взять один из тучи скриптовых языков, который бы сделал все тоже самое, люди создали свое уродство из того, что для задачи изначально вообще не предназначено. Весело, интересно, но мне всегда интересно — зачем? Ведь оно рождено умереть. Я специально сейчас пробежался в гугле — такое ощущение, что интернет вообще не знает про это приложение. При этом, автор, судя по всему, надеется привлечь к созданию карточек других людей. Это — правильно. А вот ставить задачу перед ними учить такую вот ужасть — совсем неправильно.
Есть какие-то правила? Я нигде их не видел. На уровне API порядок есть. Есть сетевой стек, есть технологии шифрования, аутентификации и контроля целостности. Выбирай что хочешь. Единственное, что в этой ситуации можно делать, это вводить ограничения на определенный вид приложений, которые работают с персональными данными. С учетом того, что проблемы защиты канала данных известны с самого дня их появления и Apple явно о них тоже знают, у меня большие сомнения что спустя такое время какие-либо существенные ограничения вдруг появятся.
когда на уровне ОС есть механизмы принудительного регулирования. Они должны быть.
Они есть — механизмы аутентификации на уровне API. Никто не будет вводить ограничения на сетевой стек, это нереалистично. Максимум это ввод гайдлайнов для разработчиков. Канал данных между приложением и внешним миром это забота разработчика и только разработчика. Это как раз наша с вами реальность.
В смысле нет? В каждое приложение под swift же сейчас кладется пачка динамических библиотек, где все богатство и реализовано. Вскоре планируется включить это все в iOS, чтобы не тащить с каждым приложением из AppStore
Swift точно так же полностью полагается на рантайм и без него бесполезен. Просто в данном случае помимо компилятора будут открыты и библиотеки со всем добром, в отличие от Obj-C
Swift выглядит как просто велосипед от Apple для своих собственных платформ. За пределами этих платформ язык выглядит довольно странно и, в общем-то, не особо нужен. Да даже на своих платформах — сколько читаю про язык, не появилось и мысли, чтобы слезть с obj-C. Ну нет там просто ничего, что бы меня мотивировало. Тем более он до сих пор не дорос до стабильного состояния.
А чем эта модульность так уж принципиально отличается от модульности в виде динамических библиотек С/С++? Точка входа есть, динамическая загрузка в память, поиск и выполнение процедур есть, что тоже реализуется библиотечными вызовами линкера. С++ даже метаинформацию кодирует за счет name mangling.
Единственно, хэш зависимостей, который, по сути, убивает всю суть модульности, если я правильно ее понимаю тут. Т.е. обновился модуль, интерфейс его остался прежним, хэш изменился, а наша программа отказывается почему-то с ним работать, хотя причин для этого никаких нет.
Раз уж пишите про Private APIs, то пишите уже до конца:
1. Их применение ограничивает песочница
2. Их применение ограничивают entitlements (аналог permissions из Android)
Второе самая большая проблема — большинство критических для безопасности API защищено ими, а те, которые остаются, через какое-то время все таки закрываются. И с этим ничего не сделать без jailbreak — entitlements подписываются вместе с кодом, а их список четко ограничен теми entitlements, которые находятся в provisioning profile. Последний, в свою очередь, Apple подписывает своим ключом на сервере, что не позволяет туда добавить ничего лишнего. Да, добавить какие-то угодно entitlements в приложение можно, но iOS при запуске всегда проверяет их соответствие provisioning profile и убьет приложение, если что-то не так.
Раз уж вы о теории, то сколько бы не написали таких вариантов кода для разных входов, все равно их все можно восстановить и вся программа будет как на ладони. Ваш пример это ровно тоже самое, что рядом с шифрованным блоком данных положить ключ. В итоге это вырождается в обычный обфусцированный код с кучей мусора, который нормальным специалистом так или иначе отсеивается.
А если мы учтем практичность, то количество комбинаций вход-код будет очень мало, поэтому все становится просто элементарным.
Именно поэтому единственные варианты, которые до сих пор применяют серьезные конторы это:
-ключ приходит по сети
-ключ находится в самом кристалле процессора
Но это все тоже самое security through obscurity и в конечно итоге все выплывает наружу.
Не замечал подобного за время пользования. Симпатично — да. Образец — навряд ли, все как у всех. А в последней версии даже симпатичность решили поубавить.
Почему бы и нет? На блюпринтах успешно пишут и системы анимации со своими стейт машинами. В редакторе для этого полно инструментов. Тут конечно уже тонкая грань из-за этих блюпринтов — на них это все успешно пишется и не выглядит ужасающе громоздко. Хотя, если отбросить все эти упрощения блюпринтов, подобная логика действительно более уместно смотрится в ядре, где скриптам не место.
А зачем в играх скриптовые языки используют? Чтобы дать работу дизайнерам, которые и будут заниматься игровой логикой без того, чтобы сидеть и читать Страуструпа. В анриле блюпринты — по сути, это та самая скриптовая система. Весь критический к производительности код можно убрать в плюсы, а снаружи делать блюпринтами. Программисты хороши там, где есть задача и можно написать и забыть. Блюпринты и скриптовые языки хороши там, где задача именно постоянно меняется, нужно что-то постоянно твикать, отлаживать, подправлять. В плюсах этим не занимаются даже ААА студии, у них скриптовые языки для этого отведены. Важнее сделать процесс быстрым и легким, а не гнаться за тактами, которые плюсы выиграют против скриптов
Что до андроида, то беты iOS для того и предназначены, чтобы у людей уже все работало, а не приходили такие вот разработчики — а нафиг оно мне надо, оно еще не вышло и 10 раз поменяется. Про консоли тем более хороший пример — там предварительные dev-киты очень сильно меняются и порой разработчики ловят много проблем, а ведь вначале они вообще для ПК со схожей производительностью пишут, а не для хотя бы тестового железа консоли, но по-другому никак. Игры и платформа должны выходить одновременно.
Прошу прощения, это ответ rumkin выше.
Они есть — механизмы аутентификации на уровне API. Никто не будет вводить ограничения на сетевой стек, это нереалистично. Максимум это ввод гайдлайнов для разработчиков. Канал данных между приложением и внешним миром это забота разработчика и только разработчика. Это как раз наша с вами реальность.
Единственно, хэш зависимостей, который, по сути, убивает всю суть модульности, если я правильно ее понимаю тут. Т.е. обновился модуль, интерфейс его остался прежним, хэш изменился, а наша программа отказывается почему-то с ним работать, хотя причин для этого никаких нет.
1. Их применение ограничивает песочница
2. Их применение ограничивают entitlements (аналог permissions из Android)
Второе самая большая проблема — большинство критических для безопасности API защищено ими, а те, которые остаются, через какое-то время все таки закрываются. И с этим ничего не сделать без jailbreak — entitlements подписываются вместе с кодом, а их список четко ограничен теми entitlements, которые находятся в provisioning profile. Последний, в свою очередь, Apple подписывает своим ключом на сервере, что не позволяет туда добавить ничего лишнего. Да, добавить какие-то угодно entitlements в приложение можно, но iOS при запуске всегда проверяет их соответствие provisioning profile и убьет приложение, если что-то не так.
А если мы учтем практичность, то количество комбинаций вход-код будет очень мало, поэтому все становится просто элементарным.
Именно поэтому единственные варианты, которые до сих пор применяют серьезные конторы это:
-ключ приходит по сети
-ключ находится в самом кристалле процессора
Но это все тоже самое security through obscurity и в конечно итоге все выплывает наружу.