Василий Банников

Они все достоверные. Просто скорость у разных серверов действительно разная.
Это всё равно что пытаться узнать "достоверную" скорость автомобиля и жаловаться, что на разных дорогах она разная.

Маловероятно:
1. Вирус должен быть написан под конкретный МК
2. Вирус этот должен как-то включать в себя оригинальную прошивку, чтобы не нарушить видимость корректной работы девайса.
3. Вирус должен как-то обойти защиту девайса. Очень многие производители шифруют прошивку и подписывают её для контроля целостности - просто взять и перепрошить не выйдет, тк левую прошивку загрузчик откажется загружать.
Для перепрошивки загрузчика нужен будет программатор, но есть ещё п4

4. Вирус должен уметь обходить аппаратную защиту девайса.
Опять же к п3 производитель может добавить какой-нибудь второй простой чип рядом с основным МК, который будет требовать подачи определенных сигналов на определённые выводы раз в N времени, иначе - выключение на уровне питания.

Так что лучше бы указать, откуда вообще вопрос родился:
1. Если это академический интерес, то ответ "да" так как МК - это по сути тоже компьютер.

2. Если вопрос относительно конкретного устройства, которое подозревается в заражении - на вопрос можно ответить, только если укажешь, что это за устройство и его модель.

Да, можно.
https://www.bitrix24.ru/apps/dev.php

1. То что на втором скрине - это про то что у тебя не будет Copilot.

2. Нажми на текст, где написано "Введите учётные данные ещё раз"

Засунуть датчик и лазер в трубку, чтобы можно было поймать отражение только под прямым углом. Настроить порог срабатывания так, чтобы сенсор реагировал только на прямое попадание лазера на фотоэлемент

Таким образом отражение от соседнего лазера не сможет попасть в сенсор

Первая же строка в гугле с подробным разбором, что такое App Runner (для запуска приложений в контейнерах):
https://blog.awsfundamentals.com/aws-app-runner-th...
Для запуска виртуалок есть EC2

Зависит от того, зачем тебе этот ip нужен, и есть ли вообще этот белый адрес.
1. Сделать tcp-запрос на какой-нибудь свой сервер. И отправить в ответ, с какого адреса пришёл запрос.
Нужно свою инфраструктуру поднимать, либо пользоваться чужим API. (например https://ip-api.com/)
2. Явно спросить у пользователя - пользователь может любой написать, нужно проверять, если тебе именно он нужен
3. Посмотреть в какой-нибудь ipconfig - сработает только если компьютер напрямую в интернет воткнут и ему назначен глобальный ip.

В первый месяц мне дают задачу и просят дать точную оценку. А я не могу ее дать, потому что:
1. Я не понимаю еще работу действующих систем;
2. Я не понимаю какое количество систем нужно будет доработать, чтобы решить задачу;
3. Я не знаю насколько документация точно соответствует и нужен ли делать реверс-инжиниринг кода

И таких "не понимаю/не знаю" у меня первые 3-6 месяцев работы очень много

Если совсем нет инфы, то говори "мне нужно столько-то времени, чтобы дать примерную оценку, напишу позже".

Если счёт на часы - говори "пару дней".
Если счёт на дни - говори "неделю или две".
Если счёт на месяцы - говори "через год/к осени/итд"
Ибо чем больше срок - тем больше неизвестность. Чем больше неизвестность - тем выше вероятность, что срок будет расти.
Если задача много времени требует - лучше разделить на несколько более достижимых целей и давать оценку следующей, после выполнения предыдущей.

К примеру "Сколько времени займёт сделать вот такой продукт?" (на первый взгляд - дофига) - отвечаешь "Proof of concept с вот такими минимальными фичами сделаем через столько-то"

1. Не сайт, но сборник задач: Rust koans. По сути своей - интерактивный учебник по синтаксису языка.
(UPD: на самом деле я думал про rustlings - это официальный сборник задач, а не koans)
2. Когда уже уверенно можешь писать код/знаком с синтаксисом - можешь попрактиковаться на leetcode и codewars.

Ну и лучше не на сайте сидеть, а нормальный редактор на компьютер установить, который будет давать подсказки по синтаксису и API.

"самой распространённой причины" не существует. Она будет сильно зависеть от конкретного продукта и процессов разработки.

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

2. Не полная спецификация. Например в спецификации не было описано, как система будет себя вести при ошибках - разработчик при реализации решил додумать сам.
Либо ещё может произойти из-за того что спецификация сама себе противоречит или её нельзя реализовать в полной мере за адекватное время.

3. Разработчик ошибся при реализации спецификации и не достаточно протестировал перед передачей тестировщику. Например бага может не быть в happy path или каком-то определенном подмножестве данных, но при этом на каких-то граничных случаях баг происходит.

4. Регресс. Разработчик нормально реализовал спецификацию, но тестировщик проверил только новую фичу и не стал проверять регресс - в итоге новая фича работает, а какая-то старая - сломалась, из-за того что её задели при разработке.

5. Несоответствие среды выполнения на этапе разработки, тестирования и в продакшене.
Например разрабатывали и тестировали на мощном железе, а при работе на слабом - всё плохо. Или сетевые задержки приводят к ошибкам, или на целевой машине стоит старая версия ОС, браузера, каких-то ещё зависимостей и поведение совсем меняется.

6. Во время разработки у заказчика поменялись планы. Старая спецификация больше не отвечает новым требованиям. Нужны доработки.

Чтобы минимизировать вышеперечисленное, нужно:
1. Плотное общение между разработчиком, аналитиком, и QA.
2. QA должен начинать тестирование ещё на этапе спецификации
3. Разработчик должен сообщать аналитику о всех случаях, когда он не может что-то реализовать или о каких-то пробелах.
4. Разработчик должен сообщать QA о возможном регрессе в других фичах.
5. Должны быть автотесты, чтобы уменьшить нагрузку на QA и чтобы минимизировать шанс на регресс
6. Тестирование должно обязательно производиться на том оборудовании и в том окружении, на котором система будет потом работать.
7. Чем чаще релизы - тем лучше.

Google authenticator ничего не сообщает сайтам, тк он просто реализует алгоритм/стандарт TOTP.
https://ru.m.wikipedia.org/wiki/Time-based_One-tim...

Если сильно не доверяешь Гуглу - ты можешь воспользоваться другим генератором кодов (Яндекс ключ, ms authenticator, authy), или вообще можешь для интереса попробовать написать свой скрипт, который по ключу будет генерировать такие же коды.

Разница в том что есть пользовательское соглашение, которое ты принимаешь в момент регистрации и установки.

Что сайт что приложение - это ПО, хоть и с немного разным способом дистрибуции.