Армянское Радио

Это совершенно излишне. Лучше потратить время на то, чтобы правильно распределить ресурсы.

cron задание для android смартфона

Думаю, что потребуется рут (хотя сам crond должен работать с обычными правами) и busybox.

Создайте папку для файла "root", в котором будут лежать задачи, например, /data/cron/. В ней создайте файл "root". Добавьте в него задание (запуск komanda в каждую 13-ю минуту часа):

echo ' 
13 * * * * komanda' >> /data/cron/root

Запуск:

su -
crond -b -c /data/cron

Crond должен появиться в сервисах. При редактировании задания нужно грохать сервис и перезапускать заново.

Более подробная статья (про автозапуск и т.п.): https://habr.com/ru/post/468337/

есть у меня php скрипт, который хотел бы выполнять со своего смартфона каждую минуту

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

Если вам не нужны входящие подключения (только гет), то в разы проще и беспроблемнее будет купить самый дешёвый IPv6-only VPS с минимумом памяти. Он будет стоить несколько долларов в год (год!), а удобства и возможностей даст намного больше.

Есть ли такие люди, кто сам реально выучил язык программирования и работает не просто на себя, а в фирме, компании за зарплату и кодит так, как требуют, а не так , как он умеет?

Не знаю ни одного человека, за которого это сделал бы кто-то другой.
Учебник + время = выучил синтаксис.
Учебник + время + практика = выучил язык.
Учебник + время + практика + решение реальных задач = стал программистом.
Вот для последнего слагаемого другие люди действительно очень полезны. До того - никакой необходимости в них нет.

реально.
но не только лишь всем.

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

установить драйвера... с сайта производителя...
модель в студию и версию винды

Сертификатов у сайта может быть больше одного. И все могут быть валидны. Они могут быть, например, развёрнуты на разных точках входа, там их 6 штук, только в разрезе ip адресов.... В общем, всё тут ок.

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

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

Взламывают точно так же как и мелкие.
В статье описана обычная SQL инъекция, когда данные подставляются прямо в SQL запрос.

Я просто сомневаюсь, что valve может нанять таких людей в backend

Не надо сомневаться.
Нету никаких "особенных способов взлома".
А есть такое явление как "эффективные менеджеры". У которых размер премии зависит от того, сколько денег они сэкономили акционерам.

Если бы там были подготовленные выражения, то и взлома бы не было.
Но вместо подготовленных выражений в больших компаниях есть эффективные менеджеры. Которые экономят на нормальных программистах, и заказывают разработку в Индии, в штате Бангалор. Где живет какой-нибудь Хамишь Кумар, который родился в касте вычерпывателей говна из сортиров. И вот у него только один шанс не черпать говно всю жизнь - всеми правдами и неправдами научиться программировать, путь даже за еду. Сравниваем с силиконовым программером с запросами $250k в месяц. Экономия налицо!

На всякий случай напомню, для стопроцентной защиты от инъекций необходимо всегда следовать двум простым правилам:

1. данные подставляем в запрос только через плейсхолдеры
   
2. идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
   

Ключевое слово здесь - "всегда". Как только начинаются рассуждения вида "ну эти данные и так безопасные, их защищать не надо", то в этот момент мы добавляем инъекцию к себе на сайт. Следует понимать, что защищаем мы не данные, а запрос. Данные нас вообще не интересуют - какие они, откуда пришли, являются "безопасными" или нет. Важно не то откуда они пришли, а то, куда они идут. В SQL запрос? Используем подготовленные выражения, точка.

Когда нет воздействия негативных внешних факторов, на жёстких дисках информация может храниться очень долго.

Если же диск активно используется, то скорее он у вас каким-либо образом выйдет из строя, либо начнёт деградировать магнитная поверхность пластин (не размагничиваться, а именно приходить в негодность), чем начнут происходить изменения намагниченности.

Если вдруг вы всё равно беспокоитесь на этот счёт, то можете делать следующее:

• "Двигать данные" руками - создавать копии важных папок на том же диске, старую копию удалять, новую - сохранять. Либо переносить важные данные на другой носитель и обратно (убедившись, что второй носитель в полном порядке и потерь не возникнет);
  
• Время от времени запускать тесты чтения, например, в Р.тестере (детализацию можно сделать максимальной - увидите все подробности).
  

А по-хорошему, если у вас есть какие-то важные вам данные, то они должны храниться, минимум, в виде двух копий. А лучше - трёх. Бэкапы позволят забыть о различных размагниченностях.

P.S.
Кстати, с SSD дело обстоит радикально по-другому, долго хранить на них что-либо "в ящике стола" совсем не стоит.