rPman

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

Получить доступ к данным работающего приложения без root нельзя, теоритически это можно сделать с помощью резервного копирования (сам механизм создания копии локально работает, там будет зашифрованный паролем пользователя tar архив, но восстановить ее уже не получится, android сломан гуглом специально уже почти 10 лет как, но сами данные доступны), но только если разработчики приложения не запретили это в принципе (тогда остается только рут доступ на устройстве)

p.s. на сколько я знаю эмуляторы не ограничивают доступ к данным, по этой причине приложения, которые желают защитить данные, на эмуляторах не запускаются да и рут пытаются контролировать

У вас должны быть какие то механизмы развертывания сайта на проде, не важно какие, хоть скрипты, хоть ansible, главное не вручную! Причем такие скрипты должны различать установку с нуля и обновление (обновление - отдельный разговор, к сожалению красиво и универсально с базами данных не получится, но стараться нужно, чтобы иметь повторяемость и тестируемость и получать хоть какие то гарантии того что процесс обновления ничего не сломает)

Мне нравится способ создания тестового окружения через снапшоты и репликацию...
Файлы могут попадать простым копирование (развертывание архива, rsync, набор патчей и т.п.) а база данных через поддержание онлайн реплики master->slave, на машине, где можно временно остановить slave реплику, снять снапшот с файловой системы или всей машины (например виртуализация), и поднять копию параллельно в другой сети (виртуальные машины очень красиво позволяют все это разрулить с автоматизацией).

Этот подход позволяет поднять тестовое окружение с текущей базой данных за минуты, вне зависимости от ее размера (хоть терабайты), время развертывания скорее зависит от того как долго будет останавливаться реплика (ожидание завершения текущих операций записи)

p.s. во время развертывания обновления, обычно сильно затрагивающего базы данных, советую держать 'рядом' предыдущую версию с возможностью оперативно откатиться, нервов и времени сбережете очень много

Все так, коллизия маловероятна.

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

Просто подумай, не сломается ли у тебя ничего в твоей логике, если злоумышленник такое провернет

И причем тут эластик?

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

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

Ну и само собой демон или много, берут задачи из списка воркера и ищут.

Есть старый подход к созданию web приложений на php, которому обычно учатся начинающие (я надеюсь) который подразумевает следующее - любое действие пользователя на странице отправляется на сервер запросом и о в ответ возвращает НОВУЮ страницу с новым содержимым, 'по счастливой случайности' являющейся точной копией предыдущей кроме ну например появляется div элемент с нужным содержанием.

Реализуется это следующим образом - php файл это программа, которая генерирует все формы страницы, которые могли бы быть (может быть много разных php файлов, обычно разделяемых по смыслу, например разные разделы сайта), а url в браузере (адрес этой страницы) описывает как именно нужно генерировать страницу, на практике это реализуется http GET параметрами в формате:

http://site.com/cool_prog.php?param=value&other_param=other_value

в php программе список этих параметров хранится в переменной $_GET в виде массива (кстати там возможны параметры массивы с именами типа param[]=value1&param[]=value2)

Отсюда при нажатии на кнопку у тебя должна открываться к примеру страница
http://site.com/cool_prog.php?show_div=
а в коде php, где нужно вставить какой то кусок html проверка

<?php if(isset($_GET['show_div'])) { ?>
<div>yooo!</div>
<?php } ?>

Само собой способов передать состояние приложения много, так же с помощью настроек веб сервера (у apache к примеру это .htaccess модуль mod_rewrite) можно подменить часть некрасивых к примеру &category=value на приятные глазу https://site.com/value/

Повторюсь - это устаревший подход и использовать его нужно только если есть потребность в создани веб приложения для машин, не поддерживающих javascript (такие приложения создают сильную нагрузку на сетевой трафик и сервер но зато никой нагрузки и никаких требований для клиентов)

Лучше всего на сервере реализовывать только бизнеслогику и работу с данными, а все что касается визуальной части - релизовывать на javascript в браузере у клиента.

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

Кстати не обязательно переписывать весь проект на новую архитектуру, можно по частям, сначала вот эта часть, уведомляющая об каких то изменениях реализуется рядом в виде сервиса, затем опросы базы данных подменяются колбеками между основным бакэнждом и этим сервисом (пусть временно через те же http запросы) но потом постепенно приложение может переехать полностью в эту часть.

Самое верное, реализовать свое приложение не как http rest архитектура (где каждый запрос это запуск приложения которое собирает заново свое состояние из базы данных или других мест) а как приложение и есть веб сервер, где между разными запросами оно не закрывается а значит память не очищается и состояние приложения остается постоянным. В этом случае http и websocket запросы будут идти к одному и тому же приложению, а если все изменения в данных происходят через веб, то нет нужды даже периодически перечитывать базу данных, ведь момент изменения нужных данных можно отловить и в этот же момент инициировать отсылку нужным клиентам данных.

Этот подход наиболее эффективный по всем параметрам, на порядок или даже два быстрее чем http rest (с оговорками, существуют способы ускорить его за счет рядя ограничений и нагромождений на стороне сервера), эффективный по памяти, меньше нагрузка на базу данных и прочее прочее, за счет того что все приложение крутится в пределах буквально одного приложения (некоторые даже в пределах одного потока остаются, используя асинхронные методы работы с файлами, базой, сетью).

К сожалению недостаток напрямую вытекает из этого свойства - масштабировать такое приложение тяжело. Если http rest масштабируется чуть ли не из коробки, даже почти не затрагивая приложение только со стороны администрирования продукта (накидываешь серверов, реплики базы, кеши и т.п.) то тут придется сильно менять приложение и подгонять его к работе в кластере.

Единственное скажу что 'эти проблемы' у подхода начинаются с десятков и сотен тысяч пользователей.

У javascript генерированных страниц не существует стандарта, определяющего момент, когда можно считать что страница загрузилась (там могут быть анимации например а тк же контент может подгружаться по мере скролирования или перемещения мышкой)

Универсального инструмента нет, но в частных случаях можно написать приложение, использующее headless браузер и какое то закодированное условие окончания загрузки (таймаут например) и формат, в котором сохранять страницу (например картинка, или pdf, или html дамп,..)
p.s. когда то давно я писал приложение на visual studio .net c# использующее стандартный компонент WebBrowser (это древний internet explorer, поддерживается до сих пор), так вот при запуске его в linux mono, подставляется headless firefox

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

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

Позволяет буквально, подключив несколько комплектов клавиатур, мышек и мониторов к одному компьютеру, пользоваться полученными рабочими местами независимо (не удаленно). Кстати не смотрел, что произойдет при попытке подключиться к такой машине по rdp, вполне возможно что получится и текущие сессии не закроются... в крайнем случае поставь на машину rustdesk и подключайся удаленно хоть со смартфона (видео транслируется очень даже качественно)

p.s. для linux, такой multiseat - штатный режим работы (без проблем настраивается 1 рабочее место = одна видеокарта, это решаемо конечно но уже не из коробки, в отличии от aster где не важно сколько их на машине), у меня есть конфиг, где один пользователь сидит в linux сессии, а другой под несколько программ использует виртуалку с win на своем мониторе.

боже мой, сюда то зачем контейнеризацию притянули?

тебе нужен ОДИН контейнер в который передаешь что то типа
parallel -j N < list_commands.cmd
где N это количество одновременных потоков а в list_commands.cmd в каждой строчке по команде
wget http ... -o fileXXX.log -O filename

wget тратит очень мало ресурсов, ты можешь запустить тысячу процессов и это потребует от силы гигабайт ram и совсем не затронет процессор, поэтому лимит на количество подключений определяет удаленный сервер и ширина канала провайдера

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

"SSL certificate problem: self signed certificate in certificate chain"

Запусти:
curl -vvI https://api.telegram.org/
и если ответ не будет что то типа

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=api.telegram.org
*  start date: Mar 24 15:21:45 2022 GMT
*  expire date: Apr 25 15:21:45 2023 GMT
*  subjectAltName: host "api.telegram.org" matched cert's "api.telegram.org"
*  issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
*  SSL certificate verify ok.

то поздравляю, ваш vps провайдер атакует ваши соединения атакой Man-in-the-middle

p.s. более подробно сертификат сервера смотреть можно так:

echo | openssl s_client -showcerts -servername api.telegram.org -connect api.telegram.org:443 2>/dev/null | openssl x509 -inform pem -noout -text

выполни команду на надежной машине и на твоем vps и сравни вывод

p.p.s. допускаю что на новой vps какие то проблемы с корневыми сертификатами, такое тоже возможно, если они не те что нужны а измененные, но тогда бы вообще ошибки не возникло бы (либо они забыли подменить сертификаты везде, в том числе у php-curl там кажется отдельная копия)

anydesk (кстати тоже стал последнее время просить денег, ничего не имею против, если это вопросы бизнеса), почти полная копия teamviewer
из опенсорс бесплатных и хорошей производительностью - rustdesk, но нужно ставить сервер (где то снаружи или с настроенными перенаправлениями портов)

nft решает только одну проблему - отъем денег и поддержка мошенничества, вся риторика крутится в лучшем случае вокруг супервозможностей контрактов и блокчейна в целом, но сам по себе nft тут не причем

у именно nft нет адекватного применения

Смотри $exchange->has->withdraw если true значит api биржи поддерживает вывод
Адреса для пополнения создаешь заранее и вручную контролируешь их экспирацию

к сожалению большинство бирж не поддерживают автоматизацию этого процесса

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

p.s. плохой sata кабель или засоренный разъем может заставить жесткий диск издавать шкваркающие звуки, похожие на появившиеся бэд блоки

Задачу не понял, нужно больше примеров.

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

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

p.s. суффиксное дерево, смотри там пример использования для поиска подстроки, это если у тебя БОЛЬШИЕ строки, эта структура поможет решать задачи похожие на твою