А направить 1 процент прод трафика на любой стенд это вообще не проблема.
Ну так и я ровно о том же (и география на этот факт особо не влияет). Полноценное зеркало прода в реальности встречается только в мелких проектах, но там это просто игрушка по сути. А в крупных никакого бюджета на это не хватит (точнее он никогда не окупится, поэтому его и выделять не станут). А без этого никакое тестирование до выката в прод не проявит некоторые типы ошибок, которые видны только под большой нагрузкой/на больших данных. Иными словами как не старайся этого избежать, сколько ни откладывай релиз, но тестирование в проде на реальных пользователях всё-равно неизбежно.
Такое вообще в прод попадать не должно.
Не должно. Но и люди и ИИ пишут код с ошибками, они же тестируют его довольно ограничено в меру собственных способностей и бюджета, поэтому кода без багов не бывает. Так что, должно или нет, но оно уже там. В мире есть не так и мало крупных сервисов с кучей девяток - но глючат и временами лежат абсолютно все.
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему? Сколько бы ни было площадок и как бы они ни были разнесены географически - это никак не мешает выкатывать в них по нескольку релизов в день.
Что до инструкций - то это нормальный подход, никто не спорит. Просто он во-первых не единственный адекватный, и во-вторых он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма. И это только креши, что вообще-то мелочь. Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД. И нередко такие баги связаны со сложной логикой или гонками (race condition), которые бывает крайне сложно поймать любыми тестами даже если точно знаешь что баг есть.
В общем, как редко не выкатывай и как не держись за "старое, проверенное временем" - надёжность 100% всё-равно не получишь. Поэтому, как я уже говорил, тут нет единственно верного ответа, нужен специфичный для конкретного бизнеса/проекта/команды баланс. И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
Это не есть что-то прям обязательное, и не то, чтобы часто используется конкретно на хабре - мой коммент был скорее шутливый, нежели серьёзной рекомендацией. Тем не менее, если погуглить site:habr.com "tl;dr" то находится достаточно примеров. Полезность TL;DR сильно зависит от содержимого статьи - и да, на мой взгляд для данной статьи это было бы полезно.
Ну… одно другому не мешает. Статья интересная, но управление ожиданиями тоже нужная вещь. И наличие TL;DR редко приводит к тому, что статью вообще не читают, разве что из него сразу видно, что тема не твоя - но тогда это к лучшему.
Ещё лично мне большую часть статьи хотелось ругаться на то, что вместо поиска реальной проблемы пошли лепить одну заплатку на другую в надежде что это поможет вместо понимания что происходит и почему. А в самом конце выяснилось, что оказывается реальную проблему всё-таки параллельно искали и таки нашли - вот что стоило это раньше сказать, и я бы читал спокойно. ;-)
Это типичная точка зрения админов, которые не видят что изменилось между версиями, и, соответственно, для них каждая новая версия это чёрный ящик и потенциальная опасность что всё сломается, причём опасность эта имеет для них одинаковую вероятность для любой версии.
Для разработчиков ситуация выглядит иначе: во-первых они видят что изменилось и могут адекватно оценивать вероятность что-то поломать для каждой версии отдельно, и во-вторых для них вероятность что-то поломать растет экспоненциально по мере увеличения времени между релизами (по ряду причин - от недостаточного тестирования до неожиданных результатов взаимодействия вроде бы не сильно связанных между собой изменений), но самое важное - когда релизится каждое мелкое изменение (отсюда и цифра про три релиза в день - по моему опыту вполне реальная, кстати), то становится на порядок проще понять какое именно изменение что-то сломало и как это чинить (что сильно уменьшает вероятность сделать некорректный фикс и снова положить прод из-за этой же проблемы).
Поэтому частые релизы, с точки зрения разработчиков, как раз способствуют увеличению надёжности выкатов, а вовсе не скорости разработки фич. Потому что эти релизы по большей части содержат не новые фичи, а внутренние изменения/рефакторинг/обновления зависимостей/мелкие багфиксы/оптимизации/etc.
Про это как раз в статье пишут. Очень высокая надежность и скорость разработки противоречат друг-другу.
На мой взгляд, в статье говорится совсем другое. Там речь про то, чтобы контролировать SLO путём заморозки релизов до конца текущего периода если значительная часть бюджета текущего периода была потрачена. Это ничего не говорит о том, с какой частотой рекомендуется делать релизы до наступления такого момента. И речь о фичах в этом контексте идёт только потому, что подразумевается, что новые релизы требует именно бизнес, соответственно его нужно уговаривать отложить эти релизы, а на желание разработчиков продолжать часто релизить мелкие изменения можно тупо забить потому что не они тут решения принимают - что не совсем корректно по сути, но в целом понятно.
На самом деле оптимальная стратегия сильно зависит от конкретного проекта, квалификации команд (причём всех отдельно - и разработчиков и админов и тестировщиков), и доступного бюджета (не ошибок, а финансов - напр. на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода). Универсального ответа подходящего всем - нет, даже если цель одинаковая и соответствует описанной в статье.
почему в grpc до сих пор нет нормального способа пользоваться им из браузерного приложения?
Потому что gRPC активно использует низкоуровневые фичи HTTP/2, доступа к которым браузер просто не предоставляет. Поэтому тут проблема не столько gRPC или HTTP/2, сколько специфических ограничений песочницы браузеров для JS. Как следствие из браузера приходится вместо настоящего gRPC использовать другие протоколы, которые можно конвертировать в/из gRPC, но этим конвертированием во-первых кто-то должен заниматься, и во-вторых использование "другого протокола" автоматически лишает возможности использовать море готовых инструментов созданных для gRPC и обычно ограничивает доступные возможности самого gRPC (напр. лишая возможности использовать двухсторонний stream и т.п.).
Я нашёл вот такое "объяснение"
Это не сам gRPC, это gRPC-Web - один из вышеупомянутых конвертеров. И да, он малополезен. На Go обычно используют https://github.com/grpc-ecosystem/grpc-gateway, и он достаточно хорош (для не-Go можно на Go написать простейший прокси-сервер на grpc-gateway, который будет принимать из веба запросы и проксировать их в реальный бэк уже по gRPC). Ещё есть Buf Connect https://connectrpc.com/ (но этим я пока не пользовался).
Плюс такого подхода - кроме мелкого модуля на grpc-gateway весь остальной бэк может быть написан на gRPC, а для фронта/браузера будет автоматически генерироваться привычный им swagger.yml (ведущий в grpc-gateway прокси). При этом мобильное приложение при желании может либо использовать тот же swagger.yml либо подключаться мимо этого прокси по обычному gRPC. Решение рабочее, удобное, но не идеальное - определённые ограничения по функционалу относительно полноценного gRPC есть, как и потеря скорости на проксировании (на сериализации/десериализации JSON).
Что значит нельзя? Это штатный процесс выката новой версии, который может происходить хоть несколько раз в день для одного микросервиса. На практике, конечно, это будет скорее один-два раза в неделю, но всё-равно - это только один из микросервисов. А их бывают тьмы и тьмы. И даже если у вас монолит, и он один, всё-равно один-два раза в неделю он должен выкатываться. Потому что если выкатывать раз в месяц или больше - то всё плохо, выкат обязательно превратят в "целый процесс", и частью этого процесса будут регулярные проблемы.
На gRPC обязательно нужно включать KeepAlive (с цифрами порядка 5-15 сек. для min_time/timeout/interval), причём делать это стоит и на клиенте и на сервере по умолчанию, не дожидаясь проблем. Если сервер мешает использовать такие KeepAlive на клиенте - нужно бить по попе его авторов. В абсолютном большинстве случаев этого будет достаточно.
Если будут проблемы то стоит задействовать встроенный loadbalance для открытия нескольких одновременных соединений, причём от этого может быть польза даже если инстанс сервера у вас один.
Если и этого окажется недостаточно, то на помощь придёт отправка нескольких запросов вместо одного с использованием первого ответа - но это в разы увеличит нагрузку на сервер и делать такое надо очень-очень осторожно.
Откат по сути это выкат - следующей или предыдущей версии это абсолютно не важно и ни на что не влияет (кроме вышеупомянутого незначительного процента случаев когда нужно уникальным образом восстанавливать БД). Соответственно, времени откат занимает ровно столько же, сколько и выкат. Не вижу тут никакой особенности или проблемы, из-за которой вместо выката нужно было бы всё выключать.
Абсолютное большинство новых релизов выглядит как выкат нового образа docker со stateless микросервисом или stateful микросервисом без изменения схемы БД - такие откатываются тривиальным запуском предыдущей версии образа docker либо автоматически (если новый образ в принципе не стартует или не отдаёт здоровый healthcheck) либо по кнопке если он выглядит рабочим но не работает корректно.
Из оставшихся релизов минимум половина изменяет схему БД обратимым образом (напр. добавляет новые таблицы/колонки), и если использовать для миграции инструменты позволяющие задать SQL-запросы отката и автоматизировать их тестирование, то такие релизы тоже элементарно откатываются (не автоматически, но буквально парой штатных команд - остановить новые инстансы, выполнить откат схемы БД, запустить старую версию - при сильном желании это тоже можно автоматизировать, но заморочиться придётся чуть больше).
И только оставшаяся часть релизов, составляющая незначительный процент, откатывается с большим трудом и медленно (или восстановление БД из бэкапа, или ручное выполнение миграции "обратно" уникальным образом, или срочный релиз новой версии работающей на новой схеме но без бага создавшего проблемы - по сути это даже не откат, но зачастую это самый эффективный способ при условии что проблемный выкат не испортил данные и реальной необходимости восстанавливать их из бэкапа нет).
Вроде нигде нет требования ссылку на "запрещена в РФ" оформлять скучной стандартной звёздочкой. Тут вот автор решил использовать более весёлый юникод в этих целях - почему нет, так всё запрещённое определённо смотрится веселее. Но вот отсутствие внизу сноски поясняющей эту звёздочку действительно странно и к этому наверняка смогут придраться желающие.
Всё это очень верно и здраво - пока цифры SLO адекватные (и соблюдаются, разумеется). Потому что очень легко нарисовать такой же график, только улетающий в небо на 95% и сказать "у нас лапки, всё что выше - это $$$$$$". Я к тому, что при этом подходе есть возможность замаскировать успокаивающими цифрами реальные проблемы.
Может быть и так, но это не отменяет и того взгляда на ситуацию, которые описал я.
И даже если в некоторых случаях он вынужден молчать когда стоило бы громко ругаться, это не отменяет того, что в тех случаях когда он позволяет себе ругаться - он ругается по делу.
Вот кстати да, странно, что Конституция ещё не в списке экстремистких материалов, хотя по факту отношение к ней давно именно такое. Надо Мизулиной идейку подкинуть…
К сожалению, почему-то никто такой функционал в AOSP добавлять не спешит. Вместо этого ситуация действительно меняется в противоположном направлении даже при работе на кастомах - тот же XPrivacyLua перестал поддерживаться автором, и некоторые приложения уже вполне успешно добираются до той же камеры мимо него. :-(
Это не так и хорошего тут мало. Всё это спроектировано так, чтобы защитить вендоров, а не пользователей. Все эти защиты обеспечивают защиту данных от всех, кроме вендора (а точнее двух вендоров - гугла и производителя телефона). Эти двое хотят иметь свободный и эксклюзивный доступ ко всем данным плюс контроль над телефоном (что можно запускать а что нет, удалённая установка и удаление приложений, удалённое получение геопозиции и блокировка телефона - вот это вот всё). Потому что если любое говноприложение из маркета через рекламный SDK сможет получить все те же данные, то данные собранные вендорами станут не такими ценными, раз эти же данные есть у всех желающих.
Мне вот понятны аргументы разрабов TWRP против добавления поддержки пароля но… По сути они заявляют буквально следующее: доверять прошитому в телефоне TWPR нельзя в принципе (потому что все минимум раз в день выпускают телефон из виду ложась спать, и кто знает, что на него в это время прошьют), не надо вообще прошивать TWPR, всегда запускайте его через `fastboot boot`, иначе есть вероятность что вы работаете (в т.ч. вводя пароль самого TWPR) в модифицированном злоумышленником TWPR.
Что интересно, на компе эта проблема легко решается паролем на BIOS/UEFI. Что мешало разработчикам Android сделать аналогичный запрос пароля ДО всего, включая загрузку режима fastboot?
Ну так и я ровно о том же (и география на этот факт особо не влияет). Полноценное зеркало прода в реальности встречается только в мелких проектах, но там это просто игрушка по сути. А в крупных никакого бюджета на это не хватит (точнее он никогда не окупится, поэтому его и выделять не станут). А без этого никакое тестирование до выката в прод не проявит некоторые типы ошибок, которые видны только под большой нагрузкой/на больших данных. Иными словами как не старайся этого избежать, сколько ни откладывай релиз, но тестирование в проде на реальных пользователях всё-равно неизбежно.
Не должно. Но и люди и ИИ пишут код с ошибками, они же тестируют его довольно ограничено в меру собственных способностей и бюджета, поэтому кода без багов не бывает. Так что, должно или нет, но оно уже там. В мире есть не так и мало крупных сервисов с кучей девяток - но глючат и временами лежат абсолютно все.
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему? Сколько бы ни было площадок и как бы они ни были разнесены географически - это никак не мешает выкатывать в них по нескольку релизов в день.
Что до инструкций - то это нормальный подход, никто не спорит. Просто он во-первых не единственный адекватный, и во-вторых он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма. И это только креши, что вообще-то мелочь. Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД. И нередко такие баги связаны со сложной логикой или гонками (race condition), которые бывает крайне сложно поймать любыми тестами даже если точно знаешь что баг есть.
В общем, как редко не выкатывай и как не держись за "старое, проверенное временем" - надёжность 100% всё-равно не получишь. Поэтому, как я уже говорил, тут нет единственно верного ответа, нужен специфичный для конкретного бизнеса/проекта/команды баланс. И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
Это не есть что-то прям обязательное, и не то, чтобы часто используется конкретно на хабре - мой коммент был скорее шутливый, нежели серьёзной рекомендацией. Тем не менее, если погуглить
site:habr.com "tl;dr"то находится достаточно примеров. Полезность TL;DR сильно зависит от содержимого статьи - и да, на мой взгляд для данной статьи это было бы полезно.Ну… одно другому не мешает. Статья интересная, но управление ожиданиями тоже нужная вещь. И наличие TL;DR редко приводит к тому, что статью вообще не читают, разве что из него сразу видно, что тема не твоя - но тогда это к лучшему.
Ещё лично мне большую часть статьи хотелось ругаться на то, что вместо поиска реальной проблемы пошли лепить одну заплатку на другую в надежде что это поможет вместо понимания что происходит и почему. А в самом конце выяснилось, что оказывается реальную проблему всё-таки параллельно искали и таки нашли - вот что стоило это раньше сказать, и я бы читал спокойно. ;-)
Это типичная точка зрения админов, которые не видят что изменилось между версиями, и, соответственно, для них каждая новая версия это чёрный ящик и потенциальная опасность что всё сломается, причём опасность эта имеет для них одинаковую вероятность для любой версии.
Для разработчиков ситуация выглядит иначе: во-первых они видят что изменилось и могут адекватно оценивать вероятность что-то поломать для каждой версии отдельно, и во-вторых для них вероятность что-то поломать растет экспоненциально по мере увеличения времени между релизами (по ряду причин - от недостаточного тестирования до неожиданных результатов взаимодействия вроде бы не сильно связанных между собой изменений), но самое важное - когда релизится каждое мелкое изменение (отсюда и цифра про три релиза в день - по моему опыту вполне реальная, кстати), то становится на порядок проще понять какое именно изменение что-то сломало и как это чинить (что сильно уменьшает вероятность сделать некорректный фикс и снова положить прод из-за этой же проблемы).
Поэтому частые релизы, с точки зрения разработчиков, как раз способствуют увеличению надёжности выкатов, а вовсе не скорости разработки фич. Потому что эти релизы по большей части содержат не новые фичи, а внутренние изменения/рефакторинг/обновления зависимостей/мелкие багфиксы/оптимизации/etc.
На мой взгляд, в статье говорится совсем другое. Там речь про то, чтобы контролировать SLO путём заморозки релизов до конца текущего периода если значительная часть бюджета текущего периода была потрачена. Это ничего не говорит о том, с какой частотой рекомендуется делать релизы до наступления такого момента. И речь о фичах в этом контексте идёт только потому, что подразумевается, что новые релизы требует именно бизнес, соответственно его нужно уговаривать отложить эти релизы, а на желание разработчиков продолжать часто релизить мелкие изменения можно тупо забить потому что не они тут решения принимают - что не совсем корректно по сути, но в целом понятно.
На самом деле оптимальная стратегия сильно зависит от конкретного проекта, квалификации команд (причём всех отдельно - и разработчиков и админов и тестировщиков), и доступного бюджета (не ошибок, а финансов - напр. на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода). Универсального ответа подходящего всем - нет, даже если цель одинаковая и соответствует описанной в статье.
Потому что gRPC активно использует низкоуровневые фичи HTTP/2, доступа к которым браузер просто не предоставляет. Поэтому тут проблема не столько gRPC или HTTP/2, сколько специфических ограничений песочницы браузеров для JS. Как следствие из браузера приходится вместо настоящего gRPC использовать другие протоколы, которые можно конвертировать в/из gRPC, но этим конвертированием во-первых кто-то должен заниматься, и во-вторых использование "другого протокола" автоматически лишает возможности использовать море готовых инструментов созданных для gRPC и обычно ограничивает доступные возможности самого gRPC (напр. лишая возможности использовать двухсторонний stream и т.п.).
Это не сам gRPC, это gRPC-Web - один из вышеупомянутых конвертеров. И да, он малополезен. На Go обычно используют https://github.com/grpc-ecosystem/grpc-gateway, и он достаточно хорош (для не-Go можно на Go написать простейший прокси-сервер на grpc-gateway, который будет принимать из веба запросы и проксировать их в реальный бэк уже по gRPC). Ещё есть Buf Connect https://connectrpc.com/ (но этим я пока не пользовался).
Плюс такого подхода - кроме мелкого модуля на grpc-gateway весь остальной бэк может быть написан на gRPC, а для фронта/браузера будет автоматически генерироваться привычный им swagger.yml (ведущий в grpc-gateway прокси). При этом мобильное приложение при желании может либо использовать тот же swagger.yml либо подключаться мимо этого прокси по обычному gRPC. Решение рабочее, удобное, но не идеальное - определённые ограничения по функционалу относительно полноценного gRPC есть, как и потеря скорости на проксировании (на сериализации/десериализации JSON).
Что значит нельзя? Это штатный процесс выката новой версии, который может происходить хоть несколько раз в день для одного микросервиса. На практике, конечно, это будет скорее один-два раза в неделю, но всё-равно - это только один из микросервисов. А их бывают тьмы и тьмы. И даже если у вас монолит, и он один, всё-равно один-два раза в неделю он должен выкатываться. Потому что если выкатывать раз в месяц или больше - то всё плохо, выкат обязательно превратят в "целый процесс", и частью этого процесса будут регулярные проблемы.
Вы бы блок TL;DR добавили в начало статьи:
На gRPC обязательно нужно включать KeepAlive (с цифрами порядка 5-15 сек. для min_time/timeout/interval), причём делать это стоит и на клиенте и на сервере по умолчанию, не дожидаясь проблем. Если сервер мешает использовать такие KeepAlive на клиенте - нужно бить по попе его авторов. В абсолютном большинстве случаев этого будет достаточно.
Если будут проблемы то стоит задействовать встроенный loadbalance для открытия нескольких одновременных соединений, причём от этого может быть польза даже если инстанс сервера у вас один.
Если и этого окажется недостаточно, то на помощь придёт отправка нескольких запросов вместо одного с использованием первого ответа - но это в разы увеличит нагрузку на сервер и делать такое надо очень-очень осторожно.
Откат по сути это выкат - следующей или предыдущей версии это абсолютно не важно и ни на что не влияет (кроме вышеупомянутого незначительного процента случаев когда нужно уникальным образом восстанавливать БД). Соответственно, времени откат занимает ровно столько же, сколько и выкат. Не вижу тут никакой особенности или проблемы, из-за которой вместо выката нужно было бы всё выключать.
Это не так. Откаты бывают разные.
Абсолютное большинство новых релизов выглядит как выкат нового образа docker со stateless микросервисом или stateful микросервисом без изменения схемы БД - такие откатываются тривиальным запуском предыдущей версии образа docker либо автоматически (если новый образ в принципе не стартует или не отдаёт здоровый healthcheck) либо по кнопке если он выглядит рабочим но не работает корректно.
Из оставшихся релизов минимум половина изменяет схему БД обратимым образом (напр. добавляет новые таблицы/колонки), и если использовать для миграции инструменты позволяющие задать SQL-запросы отката и автоматизировать их тестирование, то такие релизы тоже элементарно откатываются (не автоматически, но буквально парой штатных команд - остановить новые инстансы, выполнить откат схемы БД, запустить старую версию - при сильном желании это тоже можно автоматизировать, но заморочиться придётся чуть больше).
И только оставшаяся часть релизов, составляющая незначительный процент, откатывается с большим трудом и медленно (или восстановление БД из бэкапа, или ручное выполнение миграции "обратно" уникальным образом, или срочный релиз новой версии работающей на новой схеме но без бага создавшего проблемы - по сути это даже не откат, но зачастую это самый эффективный способ при условии что проблемный выкат не испортил данные и реальной необходимости восстанавливать их из бэкапа нет).
Вроде нигде нет требования ссылку на "запрещена в РФ" оформлять скучной стандартной звёздочкой. Тут вот автор решил использовать более весёлый юникод в этих целях - почему нет, так всё запрещённое определённо смотрится веселее. Но вот отсутствие внизу сноски поясняющей эту звёздочку действительно странно и к этому наверняка смогут придраться желающие.
Всё это очень верно и здраво - пока цифры SLO адекватные (и соблюдаются, разумеется). Потому что очень легко нарисовать такой же график, только улетающий в небо на 95% и сказать "у нас лапки, всё что выше - это $$$$$$". Я к тому, что при этом подходе есть возможность замаскировать успокаивающими цифрами реальные проблемы.
Может быть и так, но это не отменяет и того взгляда на ситуацию, которые описал я.
И даже если в некоторых случаях он вынужден молчать когда стоило бы громко ругаться, это не отменяет того, что в тех случаях когда он позволяет себе ругаться - он ругается по делу.
Вот кстати да, странно, что Конституция ещё не в списке экстремистких материалов, хотя по факту отношение к ней давно именно такое. Надо Мизулиной идейку подкинуть…
О, тут как раз 4 часа назад подъехала новость про борьбу с репаками: На Android усложняют установку приложений не из Google Play.
К сожалению, почему-то никто такой функционал в AOSP добавлять не спешит. Вместо этого ситуация действительно меняется в противоположном направлении даже при работе на кастомах - тот же XPrivacyLua перестал поддерживаться автором, и некоторые приложения уже вполне успешно добираются до той же камеры мимо него. :-(
Не всем. urxvt очень быстрый, хоть и без GPU.
Вы сильно недооцениваете количество оных гиков. Вот, последний опрос от разработчиков Go:
Как видите, среди разработчиков Go в среднем около трети регулярно используют Vim/Neovim.
Это не так и хорошего тут мало. Всё это спроектировано так, чтобы защитить вендоров, а не пользователей. Все эти защиты обеспечивают защиту данных от всех, кроме вендора (а точнее двух вендоров - гугла и производителя телефона). Эти двое хотят иметь свободный и эксклюзивный доступ ко всем данным плюс контроль над телефоном (что можно запускать а что нет, удалённая установка и удаление приложений, удалённое получение геопозиции и блокировка телефона - вот это вот всё). Потому что если любое говноприложение из маркета через рекламный SDK сможет получить все те же данные, то данные собранные вендорами станут не такими ценными, раз эти же данные есть у всех желающих.
Мне вот понятны аргументы разрабов TWRP против добавления поддержки пароля но… По сути они заявляют буквально следующее: доверять прошитому в телефоне TWPR нельзя в принципе (потому что все минимум раз в день выпускают телефон из виду ложась спать, и кто знает, что на него в это время прошьют), не надо вообще прошивать TWPR, всегда запускайте его через `fastboot boot`, иначе есть вероятность что вы работаете (в т.ч. вводя пароль самого TWPR) в модифицированном злоумышленником TWPR.
Что интересно, на компе эта проблема легко решается паролем на BIOS/UEFI. Что мешало разработчикам Android сделать аналогичный запрос пароля ДО всего, включая загрузку режима fastboot?