Как стать автором
Обновить
356
31.6
Alex Efros @powerman

Systems Architect, Team Lead, Lead Go Developer

Отправить сообщение

Было бы интересно почитать общее сравнение разных способов реализовать балансировщик, начиная с вариантов "для бедных" вроде DNS плюс обычный nginx (через resolver a.b.c.d; и proxy_pass $backend;), встроенный балансировщик docker swarm, AWS ELB, вышеупомянутые træfik и haproxy, платный NGINX Plus, …

Мечтаю о комментаторах, которые сначала читают старые комментарии (в 4-х из которых уже упомянули XPrivacy), и только потом пишут свой.

Думаю, такие есть, но Kozel-007 описал особый кейс, который они не покрывают:


На некоторых телефонах работа с входящим звонком происходит в маленьком pop-up, и Activity игры не получает никаких уведомлений о том, что оно перекрыто и пользователь потерял контроль.

Всё вовсе не так плохо, как Вам кажется. Я очень много лет писал на Perl, последние годы пишу на Go, так что есть опыт обоих подходов. Да, на Perl случались баги, которые были бы невозможны при наличии строгой типизации, равно как и писались периодически тесты/проверки, которые контролировали тип данных. Но — баги, тесты и лишние проверки связанные с типизацией составляли настолько малый процент от всего остального, что это не было принципиально и вполне компенсировалось дополнительной гибкостью языка. Где строгая типизация действительно очень заметно помогает, так это с рефакторингом, а вовсе не с тестированием.

Это всё уже и так есть: LineageOS, F-Droid, Yalp Store. Но пользоваться всем этим пока не настолько удобно, как штатным Play Market, плюс заставить многие приложения работать без Google Play Services тоже не просто. В результате обычному юзеру такое пока не поставишь.

Это делает XPrivacy, но, по факту, обычным пользователям это делать слишком сложно. Даже я, с 30 годами опыта разработки (правда, в основном бэкенда), где-то треть вопросов XPrivacy просто не понимал, потому что я не андроид разработчик. В XPrivacyLua интерфейс упростили, стало легче (мне), но ценой этого стало отсутствие некоторых привычных фич по тонкому контролю доступа (в частности доступ к файлам либо есть либо нет, трёх котиков уже не подсунешь, и то же самое с контактами). Но обычным юзерам и упрощённый вариант XPrivacyLua будет слишком сложным/неудобным.


На мой взгляд вся система прав доступа нуждается в переработке — она сейчас реализована с точки зрения ОС, а нужно её переделать с точки зрения пользователя. Файл манифеста приложения должен описывать более детально потребности приложения, т.е. не просто "доступ к файлам", а указание к каким именно файлам/каталогам и в каком (чтение/запись) режиме — примерно как это делается для RBAC, если нужен доступ к микрофону то нужно указать либо постоянный (когда приложение в фоне), либо только когда юзер взаимодействует с приложением, etc. Это позволит часть прав контролировать на уровне магазина при публикации приложений и пользователям при установке. Некоторые другие (напр. доступ к камере/микрофону) нужно всегда контролировать вручную, чтобы юзер мог давать доступ однократно, только когда пользуется приложением. Тот же доступ к SMS-кам, если банковское приложение попросит доступ только к SMS соответствующих шаблону "БанкABC: код *" (при условии что этот фильтр указан в манифесте приложения и фильтрацией занимается ОС, чтобы приложение других SMS вообще не видело) — это совсем другое дело. Самое сложное — это местоположение, хотя бы WiFi… многим приложениям это действительно нужно для работы, но можно, например, явно указывать, что данные о местоположении (включая название подключенной точки WiFi) приложение обязуется не передавать по сети, и при выявлении нарушения удалять из маркета — это позволит пользователям разрешать доступ к местоположению без угрозы приватности.


В общем, необходимо чтобы смысл запрашиваемых прав был понятен среднему пользователю, и чтобы количество этих запросов было достаточно небольшим — иначе они не смогут этим пользоваться.

Вкусовщина отличается тем, что у предложенной альтернативы либо нет очевидных преимуществ перед текущим решением, либо эти преимущества не актуальны/критичны для данного проекта, либо преимущества не настолько сильные, чтобы оправдать затраты на переделывание готового решения. В любом случае обязанность доказывать ценность альтернативного решения лежит на том, кто его предложил, и пока он этого не сделал, то отмести его можно очень просто и быстро: ответив на предложение одним словом "вкусовщина". Если на ревью возникает конфликт (т.е. он привёл доказательства ценности своего варианта но автором коммита с ними не согласен) — привлекается техлид и делают так, как он решил. В любом случае бредовые предложения быстро затыкаются либо тем, что он не может объяснить их ценность, либо решением техлида, после чего он может возражать сколько ему угодно, но все остальные это просто игнорируют.

Может она и "держалась молодцом", но я согласен с kagarich — она не справилась с обязанностями своей роли. Тимлид должен быть тимлидом, а быть при этом ещё и молодцом — это опциональный бонус.


И зря Вы решили не давить на девелоперские "достижения" — если ситуация действительно была такова, как Вы описали, то нет ничего проще, чем тупо (т.е. не обращая внимания ни на какие возражения/обстоятельства, в т.ч. вышестоящего начальства) выдать ему задачи в том же количестве, что и другим, жестко спросить за их невыполнение в срок, и отправить в конце месяца начальству статистику (не)выполненных за месяц задач им, и, для сравнения, остальными разработчиками, с рекомендацией срочно уволить его и начать поиски нового сотрудника на замену.


Более того, если таким образом загруженный работой коллега действительно попытается эту работу сделать — у него просто не останется сил и времени на игры в офисную политику, и тогда с ним можно будет продолжать сотрудничать, просто держа его под постоянным давлением. Но более вероятно что он сам не захочет работать в таких условиях (т.е. там, где реально надо много работать) и уйдёт вполне добровольно.

Я скорее предпочту чтобы игра ставила паузу не очень надёжно, или я ставил её на паузу вручную, чем дам игре доступ к чему-либо касающемуся звонков. Если бы была возможность ограничить игру доступом к событию "пришёл входящий звонок" без подробностей (номер звонящего, продолжительность звонка) — это было бы ещё относительно приемлемо… но, по хорошему, это должно делаться иначе: нужен системный компонент, который будет в некоторых ситуациях (включая входящий звонок) рассылать всем приложениям (кроме самого "телефона") событие: встаньте на паузу, пользователь сейчас занят другим приложением.

root, Xposed, XPrivacyLua — и у Вас есть возможность обманывать приложения именно таким образом. Кроме того в LineageOS из коробки поддерживается "защищённый режим", до возможностей XPrivacyLua ему далеко, но лучше чем ничего.

А что с данными? Или там пусто (или менее 8 гиг) было?

Это не имеет значения, потому что работа RDRAND полностью контролируется одной компанией, и провести аудит как она на самом деле работает в конкретном куске кремния — крайне проблематично.

Я в курсе. И, на мой взгляд, он абсолютно прав. Что не отменяет возможности того, что RDRAND содержит бэкдор.

И как это отвечает на мой вопрос? Наличие сертификата говорит только о том, что кто-то вложил ресурсы в сертификацию. Сама по себе сертификация качество продукта не изменяет, и ничего не говорит о качестве этого продукта относительно других.

Когда неуёмный креатив команды загоняют в загончик — не важно, в виде сервиса, слоя, интерфейса, компонента или класса — это называется архитектура. И вот когда её нет — тогда команду точно ничего не спасёт.


Что до спагетти — микросервисы, в частности, хороши тем, что большинство из них маленькие. Если в нем строк 500 полезного кода — там может быть спагетти и полное отсутствие внутренней архитектуры, и при этом всем будет плевать, потому что этот бардак не сказывается на остальной системе и не сильно усложняет сопровождение данного сервиса.


Но, в целом, в Ваших словах есть доля истины — микросервисы (по сравнению с монолитом) требуют большей компетенции от архитектора и меньшей от разработчиков, так что квалификация команды действительно может быть ниже обычной. Но на проекте это сказывается скорее положительно (можно нанять больше разработчиков и сильнее распараллелить разработку проекта, плюс разработчиков легче добавлять или заменять в середине проекта т.к. ниже порог входа для новых), даже не смотря на более низкое качество кода в среднем (это компенсируется простотой тестирования API их сервисов и значительно меньшей сложностью самих сервисов).

Даже если и нет — то будут. Использовать эти уязвимости не очень просто, и потребуется время и ресурсы на то, чтобы создать эффективные эксплойты. Если сейчас атаки традиционным способом (через уязвимости софта) дешевле, то в эксплойт для Spectre могли особо не вкладываться. Но вот после таких новостей, когда становится понятно, что Spectre вряд ли когда-либо закроют, создание "вечного" эксплойта, который будет работать всегда и везде, и который невозможно заблокировать — вполне может стать достаточно привлекательным, чтобы вложить достаточно средств в его разработку.

качество уникальности генерируемых значений значительно выше

Интересно, кто и как это определил?


Вообще, как раз для криптографии очень нежелательно использовать один источник случайных чисел, особенно встроенный в процессор. Не знаю, как под виндой, но в линухе используется смесь из нескольких источников, чтобы возможные закладки в любом из них были нивелированы: вышеупомянутый RDRAND плюс события от клавы/мыши/диска/etc.

Требовать деньги угрожая чем-либо нельзя — это шантаж. Но, возможно, есть серая зона (наверное, стоит проконсультироваться с юристом): сообщить им о том, что через месяц Вы сделаете full disclosure этого бага на хабре, и, если они хотят получить информацию о нём заранее, то Вы готовы её предоставить за вознаграждение.


Дело в том, что, на мой взгляд, молчать о таком баге нельзя в любом случае — нашли Вы, мог найти ещё кто-то. Так что если молчать, то, по факту, Вы способствуете тому, чтобы другие использовали баг в своих целях неопределённое время.

Всё верно, но ведь ничего не делать со Spectre и оставить всё как есть тоже нельзя.

Полностью с этим согласен, и никогда не утверждал обратного. Я всегда говорил, что микросервисная архитектура требует намного более высокой компетенции от архитектора, что сложность никуда не исчезает, а переносится из кода на уровень связей между микросервисами, etc.


А в последнее время вообще стараюсь использовать "встроенные микросервисы", когда микросервисы проектируются так же тщательно, но при этом они остаются внутри монолита. Их реализация полноценно изолируется, другим частям монолита недоступно ничего помимо API (обычные вызовы функций, без сетевого I/O) этих встроенных микросервисов (в частности, у каждого из них своя БД), но они не выносятся в отдельные сетевые сервисы пока в этом не появляется реальная необходимость. Это значительно снижает стоимость их разработки на начальном этапе, упрощает развёртывание, сильно упрощает изменение их API при необходимости (но это не только плюс, но и минус, как я упоминал выше, так что — только под жёстким контролем архитектора). Получается монолит, который всё ещё требует такой же высокой компетенции архитектора как и микросервисы, проектирование которого требует столько же времени как и проектирование микросервисов (потому что это оно и есть), развёртывание которого немного сложнее обычного т.к. ему нужно передать много отдельных параметров для всех встроенных микросервисов (включая подключения к разным БД), но который, тем не менее, сохраняет многие плюсы микросервисов и обходится значительно дешевле полноценных микросервисов, несмотря на возможность довольно быстро на них развалиться.

Информация

В рейтинге
152-й
Откуда
Харьков, Харьковская обл., Украина
Дата рождения
Зарегистрирован
Активность