shurshur

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

Если же захочется накостылить собственное решение, то сокеты в принципе не так уж и нужны (хотя и их возможно использовать для взаимодействия). Можно, например, сделать web-сервис, в котором передавать файл с кодом или даже архив с кодом и данными. На той стороне обработчик положит всё это во временный каталог, запустит, когда вычисления завершатся - результат сольёт обратно серверу. Примерно так:

Сервер вызывает:
POST computational-node1/task
..код и/или данные..
получаем в ответ некий id - идентификатор задания - например, 123.

После этого нода запускает вычислительный процесс. По его окончанию дёргает сервер:
POST main-server/result/computational-node1/123
..результаты..

Ещё один вариант - загружать задание также архивом по scp, потом вызывать по ssh запуск скрипта и ожидать его завершения.

Возможны десятки вариаций толщины и радиуса изгиба костылей.

Явным образом привести float с int:

int((screen.width()-size.width())/2)

Возможный вариант - Firefox с отдельными containers под каждый аккаунт для web-версии клиента.

Телеграм хранит данные в ~/.TelegramDesktop, а скачиваемые файлы по умолчанию кладёт в ~/Downloads/Telegram Desktop. Переопределить первое можно параметром -workdir при запуске, а второе - в настройках.

usermod -d /var/www/site/ru test

Тут в коде два раза создаётся TelegramClient, один из них лочит файл сессии, второй потом валится из-за того, что она залочена первым.

Например, так:

site.com##script:contains(adBlock)

Сайты, которые осмеливаются выключать адблок, должны страдать.

Задача сводится к тому, чтобы на сервере можно было бы открыть ssh-соединение до компьютера, находящегося за nat где-то в офисе. И это можно сделать! Для этого в ssh есть Port Forwarding.

Делаем так:

ssh -R 12345:127.0.0.1:22 user@example

При этом не только открывается сессия с example, но и на удалённом сервере на localhost (127.0.0.1) sshd начинает слушать порт 12345. Все коннекты на этот порт по ssh-соединению (то есть зашифрованно прокидываются на исходную машину на 127.0.0.1:22. Что и требовалось.

Например, можно на удалённой машине зайти на свою:

ssh -p 12345 me@localhost

Можно скопировать файл:

scp -P 12345 /dev/zero me@localhost

Можно даже sftp:

sftp -o Port=12345 me@localhost

Возможен проброс порта и в обратную сторону, с локальной машины на удалённую, с помощью ключа -L. Например, пусть есть сервер в офисе с внешним IP, с которого доступен внутренний адрес 192.168.1.2 с Windows и включённым RDP. Нам надо на него попасть, не заморачиваясь с поднятием VPN.

Делаем так:

ssh -L 31415:192.168.1.2:3389 user@example

Затем в RDP-клиенте вместо 192.168.1.2 вводим 127.0.0.1:31415

PS: Нужно отметить, что в настройках sshd PortForwarding может быть запрещён. Но чаще всего в конфигурации по умолчанию он включен.

Можно скомпилировать самому. Или взять из пакетов такого же дистрибутива, как на хостинге, положить к себе, через LD_LIBRARY_PATH подсунуть... Но как тут уже правильно сказали, лучше не страдать фигнёй.