CityCat4, да, я понимаю, я работал админом в госконторе, правда в Москве, и для нас прям напрягались чтобы нам более-менее сносную зарплату сделать. Потому что все понимали, что приличные админы за гроши долго не задержатся.
gitPush, экземпляр php-интерпретатора на каждый запрос только в php-cgi, для php-fpm и всяких mod_php один процесс будет обрабатывать много запросов (как настроишь столько и будет, главное чтобы памяти хватило).
Reyn1984, в общем случае, скорее всего, ничего не получится. Ключом может выступать, например, серийник устройства или комбинация серийника и вон тех 10 байт по смещению в неочевидном месте недоступной части EEPROM плюс XOR с секретной строкой. Поэтому без устройства ключ не получишь, да и механизм его получения загрузчиком устройства может быть эзотерический.
Владислав Калужский, это нормально, я сам её никогда не читал. У нас были в университете практические занятия, где мы реализовывали какие-то методы сортировки (каждому студенту давали свой вариант), свои файловые системы (мне досталось на инодах с древовидной системой блоков), интерполяция функции одной и двух переменных, поиск собственных значений матрицы, QR/LU-разложения и всякое такое... Какие-то преподаватели давали основы TeX или сетевого взаимодествия (типа "напиши игру быки и коровы по сети"). Обучались на конкретных задачах, нередко математического содержания (по нашему основному профилю).
Олимпиадные задачки, интерфейсы, несложные игрушки, приложения для решения каких-нибудь несложных задач (ежедневник, музыкальный плеер итд итп) - этого за глаза хватит на текущем этапе. Не нужно браться за книги слишком высокого уровня.
В любой кникже по алгоритмам обязательно используются символика ассимптотики (типа O(n)), это в школе вообще никогда не проходят, кроме возможно очень крутых школ с математическим уклоном. Подобную терминологию и сопутствующую теорию надо изучать или в рамках полноценной программы высшего образования (то есть пойти в институт учиться), или осваивать самостоятельно. Но на начальном этапе это не нужно. Как-то решил задачу - уже хорошо.
Андрей Ширяев, на Android можно поменять в специальном файле только на рутованном устройстве. И то это не очень тривиально (там по-моему PDU в sqlite хранится).
Но реально, зачем это всё? Если обмануть суд - это вряд ли выйдет. Есть содержание SMS очень важно, то не будут полагаться на то, что видно на телефоне, а реально запросят оператора, который обязан всё и вся хранить три года. Если же задача другая - то расскажи, какая именно. Сейчас это очень смахивает на XY problem: вместо реальной задачи задаётся вопрос о своих попытках её решить каким-то весьма вероятно кривым способом.
oslik_ppc, вообще говоря, может быть не очень ок. Если код прям дублируется, то его лучше оформить как совместно используемый общий модуль. Но это, как обычно, не должно становиться самоцелью. Например, если у нас есть какая-то несложная функция на 10 строчек, которая тонет в 20 тыс. строчек непересекающегося кода обоих проектов, то усилия по выделению этого незначительного общего кода в отдельный репозиторий, подключаемый к этим проектам, могут быть совершенно неоправданы.
С другой стороны, наличие такого совпадающего микрокусочка кода может быть признаком либо того, что проекты принципиально разные и несвязанные между собой, либо что в них одни и те же вещи сделаны принципиально по-разному. И это может быть признаком архитектурно неудачных решений.
Например, в одном компоненте наворочено ORM, а в другом идёт работа многочисленными прямыми запросами к той же самой базе данных. Кода общего нет, но по факту есть две реализации работы с одной и той же базой. И внутри получаются почти такие же запросы, но разными способами и с излишним дублированием кода.
Или в одном компоненте всё построено на асинхронных вызовал async/await, а в другом - на синхронных задачах в тредпуле с коллбэками. То есть два архитектурных подхода, которые в итоге могут решать одни и те же задачи. Причём не всегда можно одно заменить другим. Например, если у нас в одном компоненте используется глубоко синхронная библиотека, то его может быть слишком сложно переделать на асинхронщину. Это, кстати, обычное узкое место рефакторинга: есть куча кода, который уже работает, но его архитектура не позволяет куски старого кода легко интегрировать в новую архитектуру.
Я раньше работал в организации, где делали собственную систему для решения различных задач, она была написана на php и восходила к разработке студента, который в начале нулевых писал код вообще без функций :) По мере усложнения было много боли по переделыванию этого всего на Zend Framework, классы, MVC и всё такое. И там прогеры как-то прилично усилий потратили, чтобы научиться корректно и без побочных эффектов вызывать из старого кода новый и наоборот, чтобы можно было рефакторить по частям, а не писать полностью идентичный аналог параллельно с поддержкой существующего.
Но если это собственный мелкий проект, затеваемый с нуля, то можно просто волевым решением выбирать изначальное единообразие, чтобы не создавать себе причин излишне страдать в будущем. Сразу стремиться к одинаковой работе с данными через единый модуль с ORM.
duo456, использование соли нужно не для ломания расшифровываемости, а для того, чтобы данные нельзя было подобрать по готовым таблицам.
Как это работает на простейшем примере хеширования паролей: пусть у нас используется MD5, тогда MD5("123")=202cb962ac59075b964b07152d234b70, и если у нас из миллиона пользователей 10 имеют пароль 123, то в базе будет 10 хешей с таким значением, которые легко найдутся по радужным таблицам. Но если каждый пароль будет посолен, то хеши станут разными. Например, MD5("nk4Wu3XUbNvf123")=3f39c284a3b16263ebcc50ada7148d3e и уже потребуются радужные таблицы намного большего объёма. Причём даже знание хеша+соль не поможет упростить задачу подбора.
Конкретно к шифровке-расшифровке. Мы добавляем случайную соль в исходный текст по каким-то конкретным, чтобы было понятно, где она заканчивается и как её выкинуть в итоге. Например, "соль:текст" или json'чиком {"text":"текст","salt":"соль"}. Если соль каждый раз будет случайной, то в результате расшифровки мы получаем текст с солью, которую можно выкинуть (она не имеет смысла, просто добавляется для увеличения энтропии шифротекста) и получить исходный текст. Но шифротекст при этом кардинально меняется.
Это может быть особенно ценно в протоколах, в которых передаются данные, принципиально допускающие повторения. Например, если передаются показания датчиков, то они ж могут повторяться.
Александр, у меня есть планшет Samsung 2014 года и на него довольно долго больше 4.4 нельзя было поставить. Недавно я его достал из шкафа и решил попробовать оживить. Оказалось, для него таки производитель выпустил Android 5 или 6, но на этом всё. Но умельцы делали сборку LineageOS даже на 10 андроиде, попрыгав с бубном и Heimdal, я смог это накатить, дополнить нормальным recovery, microg и всё такое. Но по отзывам пользователей эта сборка иногда ребутяется. И кажется у меня такое тоже было, видно, что пролежавший ночь планшет без запущенных накануне приложений.
Впрочем, как полноценный планшет я его всё равно не планировал использовать. Во-первых, он старый и не супер быстрый по современным меркам, хотя и не совсем тормознутый, тем более что это была не самая нищебродская модель на момент выпуска (думаю, планшет 11 года всё же будет помедленее). Во-вторых, у него сломана защёлка слота сим-карты (я пытался скотчем заклеивать, но он всё равно отваливается быстро под давлением пытающейся выпрыгнуть симки), так что стал он у меня Wi-Fi only. В-третьих, этот планшет в наше время больше ценен своим стилусом, так что его всё ещё можно использовать для рисования.
Так что отсутствие официальной поддержки новых андроидов - необязательно приговор. Надо искать, сделал ли кто работоспособную сборку. Конкретно этот мой планшет официально LineageOS не поддерживается, но вот энтузиасты сделали достаточно работоспособную сборку.
benzcrew, это новая фича, она введена в апреле 2023 как развитие switch_inline_query (которая работала только с текущим чатом). Надо смотреть, реализовали ли поддержку в библиотеках актуальных версий. Но это не добавление бота в чат, это inline mode: в строку ввода подставляется @имя_бота и произвольный текст, дальше пользователь уже сам решает, отправлять сообщение или нет. В общем-то, если используется именно эта фича, то это должен быть бот-помощник в написании сообщений.
oslik_ppc, да, примерно в таком направлении и надо мыслить. Условно, у нас есть универсальный уровень абстракции, который позволяет работать с данными и прозрачно отображать их в базу данных. И через эту прослойку работают все приложения нашего проекта. Так часто и делают.
