Раньше я мог быть уверен, что к пользователю попал ровно тот код, который я подписал и залил в магазин
И что вам придавало такую уверенность?
Все публичные ключи и сертификаты для проверки подлинности апк конечный юзер получает (и получал) в самом апк, загруженном со стора. Т.е. от гугла, а не от разработчика.
В теории гугл запросто мог и раньше перед отдачей на девайс модифицировать апк и, например, банально переподписывать его своим ключом. Левый апдейт конечно так не подсунешь, но если с первой установки отдавать переподписанные апк, то вообще никто ничего не заметит (ну ок, разве что автор кинется сверять подписи, но тут как бы уже история с Боржоми и почками). Ну или если совсем по беспределу, то пойти дальше и выпустить OTA апдейт ОС, отключающий верификацию подписей вообще.
Единственное, на чем строится вся уверенность - это доверие к гуглу и тому, что он не будет беспределить. Что тогда, что сейчас. Не вижу, что здесь принципиально поменялось.
Автор комментария, на который вы ссылаетесь, либо вообще не имеет понятия, что он делает и что измеряет, либо очень умело притворяется. Не повторяйте его ошибок.
Не нужно быть экспертом, чтобы увидеть, что GCC выдает абсолютно одинаковый ассемблерный код сортировки и с -О2, и с -О3. Разница в измерениях объясняется тем простым фактом, что godbolt - это и близко не инструмент для проведения каких бы то ни было бенчмарков.
Не уверен, что в этом есть смысл, но все же отвечу на это ёрничанье по существу, насколько это возможно.
https://godbolt.org/z/8qe454f4z компиляешь с максимальными оптимизациями -O3 а результат хуже чем с -O2 в два раза - 3.3 такта против 1.75
Если внимательно посмотреть, то можно заметить, что ассемблерный код сортировки для -О2 и -О3 одинаковый. Отличается только код print_array, выполнение которого не замеряется. Так что разброс значений объясняется не ненадежностью чего бы то ни было, а банально плавающей нагрузкой на сервера godbolt и и/или выполнением кода разными машинами. Да, такое бывает. Поэтому мерять производительность чего угодно на shared хостинге (и даже на VPS) - изначально глупая затея. Приводить результаты этих измерений в качестве аргумента, когда они отличаются даже не на порядок, а всего на 1,5 такта - затея еще более глупая.
Он же ОоО суперскаляр, у него все есть в железе и ему не нужно полагаться на компиляторы как какой нибудь там тупиковый VLIW.
А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию. Ну ты понял наверное. Прям как в статье.
Истории 90, если не 99% разводов звучат очень глупо.
Но стоит помнить, что во-первых пост-фактум все умные. А во-вторых - людям свойственно ошибаться и причина далеко не всегда в глупости или других личных качествах. Иногда это просто случайность, вызванная обстоятельствами. Даже если вам кажется иначе.
А в какой части исследования вы планируете перейти от стучания по доскам, снятого пьезо-датчиком, к чему-то, что чуть больше напоминает электрогитару? Ту самую, где звук снимается не пьезой, а электромагнитными звукоснимателями и не с досок, а со со струн.
Вы делаете далекоидущие выводы, вроде
Глухое ватное звучание белого дерева вава нельзя назвать предпочтительным для электрогитарной деки, но звонкий топ исправит положение.
к которым нет ни одной предпосылки в этой или предыдущих частях вашего исследования. Пока-что все что вы показали - это то, что "глухое ватное звучание белого дерева вава нельзя назвать предпочтительным для электрогитарной деки стучания по нему молоточком с целью получить звук электрогитары".
У вас и в первых двух частях неоднократно закидывались тезисы, очень недвузначно намекающие на то, какой результат вы планируете получить в вашем исследовании и какой уровень беспристрастности экспериментатора (никак не ослепленного, к слову).
Но в первых частях, несмотря на все методологические проблемы, проглядывалась нормальная идея: показать АЧХ досок, чтобы затем продемонстрировать, сколько из их АЧХ остается в финальном звуке гитары (снятом в разных местах тракта, с разной степенью обработки и т.д.). Ок. Вполне резонная задумка. Все таки корпус гитары - это действительно не идеальное крепление. Струны заставляют дерево вибрировать и часть этих вибраций оно возвращает обратно в струны. Какие-то частоты больше, какие-то - меньше.
Но какой вообще смысл пускать через гитарный тракт звук стука по дереву? Что это должно показать или доказать? В гитарный тракт не идет стук по доскам. Туда идут колебания струн. С тем же успехом можно через усилок с кабинетом пропустить звук пилы, которой доски для корпуса нарезали. Обязательно с подписью "глухое ватное звучание рейсмусового станка нельзя назвать предпочтительным для производства электрогитарной деки, но звонкая ручная циркулярка исправит положение."
Однако при желании можно найти видео струны в замедленном времени, например.
А можно пойти чуть дальше и найти видео струны, которую дернули и оставили в покое (прям как на гитаре), и убедиться, что эти гуляющие по струне волны очень быстро затухают при отсутствии смычка, посылающего их снова и снова.
И остаются лишь те самые стоячие волны основного тона и гармоник.
Обычно, когда вы видите этот контекст, вы можете определить во время компиляции, по какому пути пойдет код. Если это так, то всегда используйте этот паттерн.
Так это технологии производителей видеокарт, к мониторам имеют опосредственное отношение.
К мониторам они все же имеют достаточно прямое отношение, т.к. монитор должен поддерживать variable refresh rate на входе. Если он не поддерживает ни G-Sync, ни FreeSync, ни HDMI 2.1, то ни одна видеокарта ему не поможет.
Уже достаточно давно не нужно платить никакие "прибыль в $100лямов за то, чтоб пользователи могли запускать свои приложения на своих девайсах". Да, есть ограничения по сравнению с полноценным членством в программе, но они ни разу не критичны для "запускать свои приложения на своих девайсах".
В основном они сводятся к тому, чтобы помешать распространению приложений, а не их запуску (ограничения на макс. кол-во девайсов, сильно ограниченное время жизни provisioning profile и т.п.).
Ага. И я так понимаю, получить эту информацию товарищу майору поможет доступ к IMEI (или к IDFA?) у каких надо приложений, верно? Давайте может с конкретикой? Что это за приложения-Волдеморты, которые нельзя называть? И каким образом доступ к IMEI в них поможет отслеживать активность в других приложениях? И какие есть подтверждения наличия этих особых доступов? Только "ну да, так мы и поверим эпплу" или что-то более конкретное?
Да-да, а еще 5G вышками чипируют всех, кроме каких надо пользователей.
Попробуйте как-нибуть на досуге задуматься, какой в этом смысл. Что толку рекламной сетке от того, что в каких надо приложениях у нее есть доступ к какому-то айдишнику, если этот айдишник нельзя сопоставить ни с чем?
Прелесть фингерпринтинга как раз в том, что можно отслеживать активность пользователя во всех приложениях. Что есть общий одинаковый айдишник, доступный везде, во всех приложениях, а не только в парочке каких надо.
Да, влияет. Ко всяким IMEI, IMSI, UDID и прочим уникальным идентификаторам доступа нет уже довольно давно. К большинству хоть сколько-нибудь точных косвенных способов фингерпринтинга доступ нужно либо выпрашивать у Apple (вот прям человеку доказывать, что например получение списка доступных wifi сетей необходимо для работы приложения), либо же выпрашивать их у юзера (это напр. если хочется получать список устройств в локальной сети).
Так что да, IDFA в последнее время был по сути единственным способом надежного фингерпринтинга.
Ну и если выйти за рамки чисто технических решений — за попытки использования обходных путей для трекинга юзеров, отказавшихся предоставить доступ к IDFA, есть все шансы вылететь со стора, и Эппл об этом открытым текстом предупреждали. Т.к. диалог не спрашивает юзера "дать ли приложению доступ к IDFA?". Он спрашивает "разрешить ли приложению тебя трекать?".
Куча причин может быть. Начиная от банального "чтобы облегчить параллельную разбаботку таскбара и эксплорера, сделав их более независимыми", заканчивая "чтобы позволить динамически подгружать разные таскбары в зависимости от форм-фактора девайса/соотношения сторон экрана/положения звезд на небе". Для этих целей отдельный dll действительно будет полезен, в отличие от цели "разделить на 2 процесса".
Я еще раз повторюсь, вынесение части кода в dll ничем не помогает в вынесении этого кода в отдельный процесс. Ничего не мешало и раньше иметь 1 процесс explorer.exe, выполняющий код, который теперь переехал в taskbar.dll и другой explorer.exe, выполняющий все остальное.
Кроме того, пользователь Twitter Albacore также заметил, что панель задач будет выделена в отдельный процесс. До сих пор панель задач была частью explorer.exe, но после сборки 21343 процесс был перемещен в taskbar.dll.
Пользователь ничего такого не замечал. В его твитах нет ни слова об отдельном процессе. Только о появлении DLL с кодом таскбара. Отдельный DLL и отдельный процесс — это вещи абсолютно перпендикулярные. Можно иметь кучу DLL в одном процессе и кучу процессов из одного DLL/EXE.
С другой стороны, я покупаю изделие, и с фига ли производитель решает что мне на ней делать и как.
Странная какая-то предъява. То есть производитель произвел изделие. Обозначил, для чего это изделие подходит, а для чего нет. Вы его купили, чтобы делать на нем то, для чего оно не подходит. И виноват в этом производитель. Я ничего не упустил?
Когда оказывается, что Smart ездит по лесам и полям хуже, чем полноприводный внедорожник, то это тоже виноват производитель смартов, который решает что на них делать и как?
Конкретно в этом случае сложно что-то комментировать, т.к. тут мало того, что нет ссылки на тест, так еще и результаты по сути не указаны, лишь загадочное "Не просто отстает, а очень серьезно".
Но в целом — нет, вы не особенный. Об этом задумывались многие. И именно поэтому в большинстве тестов (во всяком случае тех, на которые я натыкался) сравнивается именно кросс-компиляция для одной и той же целевой платформы. Либо под iOS (т.е. целевая архитектура arm64), либо Universal binaries под macOS (т.е. целевые и arm64, и x86_64).
И что вам придавало такую уверенность?
Все публичные ключи и сертификаты для проверки подлинности апк конечный юзер получает (и получал) в самом апк, загруженном со стора. Т.е. от гугла, а не от разработчика.
В теории гугл запросто мог и раньше перед отдачей на девайс модифицировать апк и, например, банально переподписывать его своим ключом. Левый апдейт конечно так не подсунешь, но если с первой установки отдавать переподписанные апк, то вообще никто ничего не заметит (ну ок, разве что автор кинется сверять подписи, но тут как бы уже история с Боржоми и почками). Ну или если совсем по беспределу, то пойти дальше и выпустить OTA апдейт ОС, отключающий верификацию подписей вообще.
Единственное, на чем строится вся уверенность - это доверие к гуглу и тому, что он не будет беспределить. Что тогда, что сейчас. Не вижу, что здесь принципиально поменялось.
Автор комментария, на который вы ссылаетесь, либо вообще не имеет понятия, что он делает и что измеряет, либо очень умело притворяется. Не повторяйте его ошибок.
Не нужно быть экспертом, чтобы увидеть, что GCC выдает абсолютно одинаковый ассемблерный код сортировки и с -О2, и с -О3. Разница в измерениях объясняется тем простым фактом, что godbolt - это и близко не инструмент для проведения каких бы то ни было бенчмарков.
Не уверен, что в этом есть смысл, но все же отвечу на это ёрничанье по существу, насколько это возможно.
Если внимательно посмотреть, то можно заметить, что ассемблерный код сортировки для -О2 и -О3 одинаковый. Отличается только код
print_array, выполнение которого не замеряется. Так что разброс значений объясняется не ненадежностью чего бы то ни было, а банально плавающей нагрузкой на сервера godbolt и и/или выполнением кода разными машинами. Да, такое бывает. Поэтому мерять производительность чего угодно на shared хостинге (и даже на VPS) - изначально глупая затея. Приводить результаты этих измерений в качестве аргумента, когда они отличаются даже не на порядок, а всего на 1,5 такта - затея еще более глупая.Соломенное чучело уничтожено! Поздравляю!
А теперь включи оптимизации как в статье (-O2 или выше), выбери компилятор как в статье (gcc 7.5, а не кланг) и внезапно получишь во-первых ассемблерный листинг как в статье (а не колбасу на 30+ инструкций), а во-вторых - не поверишь, 2-4 такта на итерацию. Ну ты понял наверное. Прям как в статье.
https://godbolt.org/z/KE5hqjsqP
Ну и плавающие 2-4 такта - это на godbolt. На реальном железе с +/- стабильной нагрузкой у меня 1.7-1.8 тактов. Zen 2
Истории 90, если не 99% разводов звучат очень глупо.
Но стоит помнить, что во-первых пост-фактум все умные. А во-вторых - людям свойственно ошибаться и причина далеко не всегда в глупости или других личных качествах. Иногда это просто случайность, вызванная обстоятельствами. Даже если вам кажется иначе.
А в какой части исследования вы планируете перейти от стучания по доскам, снятого пьезо-датчиком, к чему-то, что чуть больше напоминает электрогитару? Ту самую, где звук снимается не пьезой, а электромагнитными звукоснимателями и не с досок, а со со струн.
Вы делаете далекоидущие выводы, вроде
к которым нет ни одной предпосылки в этой или предыдущих частях вашего исследования. Пока-что все что вы показали - это то, что "глухое ватное звучание белого дерева вава нельзя назвать предпочтительным для
электрогитарной декистучания по нему молоточком с целью получить звук электрогитары".У вас и в первых двух частях неоднократно закидывались тезисы, очень недвузначно намекающие на то, какой результат вы планируете получить в вашем исследовании и какой уровень беспристрастности экспериментатора (никак не ослепленного, к слову).
Но в первых частях, несмотря на все методологические проблемы, проглядывалась нормальная идея: показать АЧХ досок, чтобы затем продемонстрировать, сколько из их АЧХ остается в финальном звуке гитары (снятом в разных местах тракта, с разной степенью обработки и т.д.). Ок. Вполне резонная задумка. Все таки корпус гитары - это действительно не идеальное крепление. Струны заставляют дерево вибрировать и часть этих вибраций оно возвращает обратно в струны. Какие-то частоты больше, какие-то - меньше.
Но какой вообще смысл пускать через гитарный тракт звук стука по дереву? Что это должно показать или доказать? В гитарный тракт не идет стук по доскам. Туда идут колебания струн. С тем же успехом можно через усилок с кабинетом пропустить звук пилы, которой доски для корпуса нарезали. Обязательно с подписью "глухое ватное звучание рейсмусового станка нельзя назвать предпочтительным для производства электрогитарной деки, но звонкая ручная циркулярка исправит положение."
А можно пойти чуть дальше и найти видео струны, которую дернули и оставили в покое (прям как на гитаре), и убедиться, что эти гуляющие по струне волны очень быстро затухают при отсутствии смычка, посылающего их снова и снова.
И остаются лишь те самые стоячие волны основного тона и гармоник.
https://www.youtube.com/watch?v=_X72on6CSL0
https://www.youtube.com/watch?v=3ATVOTJfkg8
К мониторам они все же имеют достаточно прямое отношение, т.к. монитор должен поддерживать variable refresh rate на входе. Если он не поддерживает ни G-Sync, ни FreeSync, ни HDMI 2.1, то ни одна видеокарта ему не поможет.
Python — это не только Jupyter
Уже достаточно давно не нужно платить никакие "прибыль в $100лямов за то, чтоб пользователи могли запускать свои приложения на своих девайсах". Да, есть ограничения по сравнению с полноценным членством в программе, но они ни разу не критичны для "запускать свои приложения на своих девайсах".
В основном они сводятся к тому, чтобы помешать распространению приложений, а не их запуску (ограничения на макс. кол-во девайсов, сильно ограниченное время жизни provisioning profile и т.п.).
Качали/распаковывали данные, как вариант.
Ну или замените numpy на pyplot. Он довольно часто оказывается нужен именно в таком сценарии, когда все уже посчитано.
Ага. И я так понимаю, получить эту информацию товарищу майору поможет доступ к IMEI (или к IDFA?) у каких надо приложений, верно? Давайте может с конкретикой? Что это за приложения-Волдеморты, которые нельзя называть? И каким образом доступ к IMEI в них поможет отслеживать активность в других приложениях? И какие есть подтверждения наличия этих особых доступов? Только "ну да, так мы и поверим эпплу" или что-то более конкретное?
Да-да, а еще 5G вышками чипируют всех, кроме каких надо пользователей.
Попробуйте как-нибуть на досуге задуматься, какой в этом смысл. Что толку рекламной сетке от того, что в каких надо приложениях у нее есть доступ к какому-то айдишнику, если этот айдишник нельзя сопоставить ни с чем?
Прелесть фингерпринтинга как раз в том, что можно отслеживать активность пользователя во всех приложениях. Что есть общий одинаковый айдишник, доступный везде, во всех приложениях, а не только в парочке каких надо.
Эмм… А в каком месте там ответ хоть на один из вопросов akuranda? Что именно хорошо объяснено?
Да, влияет. Ко всяким IMEI, IMSI, UDID и прочим уникальным идентификаторам доступа нет уже довольно давно. К большинству хоть сколько-нибудь точных косвенных способов фингерпринтинга доступ нужно либо выпрашивать у Apple (вот прям человеку доказывать, что например получение списка доступных wifi сетей необходимо для работы приложения), либо же выпрашивать их у юзера (это напр. если хочется получать список устройств в локальной сети).
Так что да, IDFA в последнее время был по сути единственным способом надежного фингерпринтинга.
Ну и если выйти за рамки чисто технических решений — за попытки использования обходных путей для трекинга юзеров, отказавшихся предоставить доступ к IDFA, есть все шансы вылететь со стора, и Эппл об этом открытым текстом предупреждали. Т.к. диалог не спрашивает юзера "дать ли приложению доступ к IDFA?". Он спрашивает "разрешить ли приложению тебя трекать?".
В том то и дело, что она не особо логичная.
Куча причин может быть. Начиная от банального "чтобы облегчить параллельную разбаботку таскбара и эксплорера, сделав их более независимыми", заканчивая "чтобы позволить динамически подгружать разные таскбары в зависимости от форм-фактора девайса/соотношения сторон экрана/положения звезд на небе". Для этих целей отдельный dll действительно будет полезен, в отличие от цели "разделить на 2 процесса".
Я еще раз повторюсь, вынесение части кода в dll ничем не помогает в вынесении этого кода в отдельный процесс. Ничего не мешало и раньше иметь 1 процесс explorer.exe, выполняющий код, который теперь переехал в taskbar.dll и другой explorer.exe, выполняющий все остальное.
Пользователь ничего такого не замечал. В его твитах нет ни слова об отдельном процессе. Только о появлении DLL с кодом таскбара. Отдельный DLL и отдельный процесс — это вещи абсолютно перпендикулярные. Можно иметь кучу DLL в одном процессе и кучу процессов из одного DLL/EXE.
Странная какая-то предъява. То есть производитель произвел изделие. Обозначил, для чего это изделие подходит, а для чего нет. Вы его купили, чтобы делать на нем то, для чего оно не подходит. И виноват в этом производитель. Я ничего не упустил?
Когда оказывается, что Smart ездит по лесам и полям хуже, чем полноприводный внедорожник, то это тоже виноват производитель смартов, который решает что на них делать и как?
Конкретно в этом случае сложно что-то комментировать, т.к. тут мало того, что нет ссылки на тест, так еще и результаты по сути не указаны, лишь загадочное "Не просто отстает, а очень серьезно".
Но в целом — нет, вы не особенный. Об этом задумывались многие. И именно поэтому в большинстве тестов (во всяком случае тех, на которые я натыкался) сравнивается именно кросс-компиляция для одной и той же целевой платформы. Либо под iOS (т.е. целевая архитектура arm64), либо Universal binaries под macOS (т.е. целевые и arm64, и x86_64).