почему в 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?
Будем откровенны: против целевой атаки на конкретного человека защиты нет в принципе. Софт уязвим абсолютно весь, дыры постоянно находят новые, векторов атаки на данные конкретного человека намного больше чем удалённый взлом телефона - взломать можно всегда и что угодно, хоть и не всегда это можно сделать немедленно прямо сейчас.
А если атака не направлена на конкретного человека, то никто не станет заморачиваться особым способом взлома микроскопического процента тех, кто разблокирует загрузчик. Тем более, что их системы обычно защищены лучше - ведь для этого обычно его и разблокируют.
Погранцы - те да, запросто могут подключить телефон к спец.девайсу, который тупо пробует все возможные способы взлома, включая и доступ в стиле описанном в статье. Но погранцы - это же не внезапный гоп-стоп, это вполне ожидаемое явление, поэтому ехать к ним нужно с чистым телефоном в который забиты нужные в дороге контакты и всё, а после них не глядя на контрольные суммы тупо переустанавливать прошивку с данными из бэкапа всех разделов в облаке.
Помимо AFWall root нужен для: бэкапа (быстрого и полноценного, т.е. игнорирующего мнение приложений о том, можно ли их бэкапить), блокирования рекламы (hosts-файл), дополнительного контроля доступа приложений из соображений приватности (xprivacylua). И все эти 4 фичи - критичны, на мой взгляд.
Часть этих задач умеют решать rootless приложения притворяющиеся VPN, но проблема в том, что VPN-то тоже нужен обязательно, а цепочку VPN такие приложения не поддерживают AFAIK, поэтому все такие псевдо-VPN автоматически отпадают.
К сожалению, всё это звучит как "делайте хорошо, а плохо - не делайте".
В целом, конечно, идеология нужна и важна. Западу в этом качестве хватает бабок, но у нас другой менталитет. Но и Китай абсолютно не похож на что-то, что хочется скопировать себе. И обратно в СССР совершенно не хочется. Хочется в "Мир Полу́дня" Стругацких.
В Gentoo прекрасно работает Steam, и лично я ещё не сталкивался на https://www.protondb.com/ с какими-то виндовыми играми которые не идут под линухом (хотя, конечно, они наверняка существуют, просто их явно не так много, как можно подумать). Зачем вообще держать винду для игр?
Потому что 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?
Будем откровенны: против целевой атаки на конкретного человека защиты нет в принципе. Софт уязвим абсолютно весь, дыры постоянно находят новые, векторов атаки на данные конкретного человека намного больше чем удалённый взлом телефона - взломать можно всегда и что угодно, хоть и не всегда это можно сделать немедленно прямо сейчас.
А если атака не направлена на конкретного человека, то никто не станет заморачиваться особым способом взлома микроскопического процента тех, кто разблокирует загрузчик. Тем более, что их системы обычно защищены лучше - ведь для этого обычно его и разблокируют.
Погранцы - те да, запросто могут подключить телефон к спец.девайсу, который тупо пробует все возможные способы взлома, включая и доступ в стиле описанном в статье. Но погранцы - это же не внезапный гоп-стоп, это вполне ожидаемое явление, поэтому ехать к ним нужно с чистым телефоном в который забиты нужные в дороге контакты и всё, а после них не глядя на контрольные суммы тупо переустанавливать прошивку с данными из бэкапа всех разделов в облаке.
Помимо AFWall root нужен для: бэкапа (быстрого и полноценного, т.е. игнорирующего мнение приложений о том, можно ли их бэкапить), блокирования рекламы (hosts-файл), дополнительного контроля доступа приложений из соображений приватности (xprivacylua). И все эти 4 фичи - критичны, на мой взгляд.
Часть этих задач умеют решать rootless приложения притворяющиеся VPN, но проблема в том, что VPN-то тоже нужен обязательно, а цепочку VPN такие приложения не поддерживают AFAIK, поэтому все такие псевдо-VPN автоматически отпадают.
Очевидно же, скроллить табы зажав Ctrl-PgDown на 60fps. Это прям первое видео по Zed гордо демонстрирует!
Не очевидно?! Мне тоже. Но кому-то это нужно, наверное.
Впрочем, сам редактор неплохой. Не Neovim, конечно, :) но неплохой.
К сожалению, всё это звучит как "делайте хорошо, а плохо - не делайте".
В целом, конечно, идеология нужна и важна. Западу в этом качестве хватает бабок, но у нас другой менталитет. Но и Китай абсолютно не похож на что-то, что хочется скопировать себе. И обратно в СССР совершенно не хочется. Хочется в "Мир Полу́дня" Стругацких.
В Gentoo прекрасно работает Steam, и лично я ещё не сталкивался на https://www.protondb.com/ с какими-то виндовыми играми которые не идут под линухом (хотя, конечно, они наверняка существуют, просто их явно не так много, как можно подумать). Зачем вообще держать винду для игр?