меньшая фрагментация ПО: у вас самих написано в статье Что будет после RVV 1.0? Возможен переход сразу к RVV 2.0 без обратной совместимости с RVV 1.0 что несколько противоречит
Не вижу особого преимущества профилей над подходом, принятым в x86-64 c инкрементальным (не считая небольших различий в расширениях AMD и Intel) расширением набора инструкций: например добавлением команд для операций над векторным регистром большего размера.
Трудоемкость SW
Для простого алгоритма, как скалярное умножение, да, вектор переменной длины удобен, но большую часть жизни процессоров векторные регистры имели фиксированный размер, что значительно повлияло на алгоритмы, и переход на векторы произвольной длины требует достаточное количество усилий: перенос алгоритма с SSE/AVX на NEON на порядок проще, чем переход с NEON на SVE.
Очень полезно и правильно вы указали на недочет(=серьезная ошибка) спикера.
Но моё имхо, что такое лучше писать личным сообщением автору, с дальнейшей просьбой написать пост для передачи отрицательного опыта, может с извинениями, с ссылкой на вас.
А так же вопрос к компаниям, которые передали записи разговоров для обучения — имели ли они право передавать(а не только записывать) их, без обезличивания.
Хочу отметить очень важное доказательство того, что моё видео — действительно из приложения: на нём не видно статус-бара (строки с уровнем сотового сигнала, времени, заряда батареи), вместо него — пустое место.
Что вам мешало отрезать статус-бар ручками на пк?
Или, как уже говорили, подмена конфига от сервера могла быть с вашей стороны.
Далее:
Фреймрейт динамичный и выбирается самим AppSee автоматически, если что.
По параметрам (разрешение, FPS, битрейт) — моё видео полностью совпадает с видео, на которое…
Когда вам говорят, что битрейт отличается, вы говорите, что он динамический.Тут вы утверждаете полное совпадение.
Нужна провека\ки со стороны, хотя уже по битрейту, стоит сделать вывод о авторе.
отправку видео файла на AppSee: нельзя передавать с номером карты (PAN) дату истечения и имя владельца.Про телефон я вообще молчу. Это прямое нарушение PCI DSS в частности и здравого смысла вообще.
Цитата с хабра про PCI DSS:
PCI DSS — это стандарт безопасности, который применяется для всех организаций сферы обработки платежных карт: торговых точек, процессинговых центров, финансовых учреждений и поставщиков услуг, а также других организаций, которые хранят, обрабатывают или передают данные держателей карт и (или) критичные аутентификационные данные.
Я вам говорю, что вы проверьте, передает ли приложение эти данные, вы же говорите, что приложение что-то там нарушает передавая номер карты и тд, хотя ваших доказательств передачи нет.
Достоверность чужих — под вопросом, а значит и ваших утверждений тоже.
Хотя бы потому, что замазывание полей и качество видео не зашито в коде приложения, а получается с сервера вместе с другими настройками.
На самом деле, сложность обновления приложения(с зашитым компромитирующим конфигом), и сложность обновления конфига, поступающего от сервера не сильно отличается.
Пока опубликованы видео и с закрашенными полями, и без.
Причем версия без закрашенных полей подвергалась сомнениям из-за завышенного битрейта.
В любом случае, с вашей стороны было бы корректнее самому провести опыт, а не слепая вера и клепание поста.
Как видно из перехваченного видео — данные передаются без какой-либо обработки, а уже в самом AppSee видео обрабатывается и данные держателей карт (ДДК) закрашиваются черными квадратами, как они утверждают
Куда передаются? Поля закрашиваются на стороне клиента.
Не согласен с несколькоми пунктами таблиц:
меньшая фрагментация ПО: у вас самих написано в статье
Что будет после RVV 1.0? Возможен переход сразу к RVV 2.0 без обратной совместимости с RVV 1.0что несколько противоречитНе вижу особого преимущества профилей над подходом, принятым в x86-64 c инкрементальным (не считая небольших различий в расширениях AMD и Intel) расширением набора инструкций: например добавлением команд для операций над векторным регистром большего размера.
Трудоемкость SW
Для простого алгоритма, как скалярное умножение, да, вектор переменной длины удобен, но большую часть жизни процессоров векторные регистры имели фиксированный размер, что значительно повлияло на алгоритмы, и переход на векторы произвольной длины требует достаточное количество усилий: перенос алгоритма с SSE/AVX на NEON на порядок проще, чем переход с NEON на SVE.
Скрытый текст
я бы поспорил про 5080
Но моё имхо, что такое лучше писать личным сообщением автору, с дальнейшей просьбой написать пост для передачи отрицательного опыта, может с извинениями, с ссылкой на вас.
А так же вопрос к компаниям, которые передали записи разговоров для обучения — имели ли они право передавать(а не только записывать) их, без обезличивания.
Что вам мешало отрезать статус-бар ручками на пк?
Или, как уже говорили, подмена конфига от сервера могла быть с вашей стороны.
Далее:
Когда вам говорят, что битрейт отличается, вы говорите, что он динамический.Тут вы утверждаете полное совпадение.
Нужна провека\ки со стороны, хотя уже по битрейту, стоит сделать вывод о авторе.
Цитата с хабра про PCI DSS:
Я вам говорю, что вы проверьте, передает ли приложение эти данные, вы же говорите, что приложение что-то там нарушает передавая номер карты и тд, хотя ваших доказательств передачи нет.
Достоверность чужих — под вопросом, а значит и ваших утверждений тоже.
На самом деле, сложность обновления приложения(с зашитым компромитирующим конфигом), и сложность обновления конфига, поступающего от сервера не сильно отличается.
Причем версия без закрашенных полей подвергалась сомнениям из-за завышенного битрейта.
В любом случае, с вашей стороны было бы корректнее самому провести опыт, а не слепая вера и клепание поста.
Куда передаются? Поля закрашиваются на стороне клиента.