mayton2019

Существует много техник взаимодействия между процессами. Основное ключевое слово для поиска - IPC (Inter process communications). Там дальше надо выйти за границы Питона потому что эти техники немного разные для Windows/Linux. Некоторые похожие (Network Sockets).

Если надо просто вести учет строк в PIPE между процессами то можно так

bzip2 -d -k -c very_long_file.txt.bz2 | pv -l > /dev/null

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

Вот тут примеры и синтаксис пишут

https://wiki.postgresql.org/wiki/UPSERT

Маленькая ремарка.

В наше время такая метрика как количество процессоров (vCPU) - это маркетинговый обман.
Скорее всего продаются виртуалки. И когда мы спорим и обсуждаем на них цены - надо обсудить
каким образом облако их выделяет и вам предоставляет. Я думаю что режимов виртуализации
может быть много. Ядра. Треды. Процессы в докерах-кубернетисах - это тоже
в некотором роде виртуализация.

Обычно мозговые игры с шифрованием-дешифрованием выглядят так.

1) Вы пытаетесь представить открытый текст. Например он может начинаться со строки "Привет".
Или мы можем заведомо знать о том что в открытом тексте есть русский или болгарский или польский
язык и исходя из его свойств (гистограмма или биграмма) проверять гипотезы.

2) Вы начинаете перебирать все известные методы доисторической криптографии
- Шифр Цезаря (Виженнера)
- Квадрат Полибия
- Пасьянс Шнайера (колода карт)
- Палочки-веревочки и прочее
и последовательно применять их до тех пор пока не получим ответ.
Разумеется все это надо делать автоматизированно иначе это похоже на брейн-фак. А кому нужно
факать себе мозг да еще и безплатно?

В блоге Романа Душкина есть много науч-попа на эту тематику. Практически по всем темам.

3) Если к открытому тексту пременен современный метод криптографии типа AES/Blowfish
то пишите - пропало. Нет надежды на нахождение открытого текста. Можете обещать любую
денежную премию. Эти шифры слишком серъезны чтобы их пытаться угадать в хабре.

Да и ключом в таких шифрах обычно идет не парольная фраза а вполне себе длинный вектор
ключа и инициализации (256 бит например).

Это не будет работать. Base64 использует специальные символы padding в конце файла чтоб указать
какой из символов терминирует поток байтов.

Поэтому если ты просто текст base64 тупо разрежешь на 2 части то эти две части станут невалидные
с точки зрения кодировки base64. Надо примерно так

input string => base64decoder => bytearray => split_3500 => encode_each_array_base64 => save_to_files

вот на таком выдуманном всевдо-коде.

Надо ли учить PHP и MySQL?

Считается что PHP/MySQL относятся к "морально устаревшему" стеку технологий (LAMP (lin+apache+mysql+php).
(Я думаю что знания MySQL полезны. Это лучше чем "никакой" SQL.)

На смену ему должен был выйти лет 7 назад MEAN (mongo+nodejs+....e.t.c.).
Мне уже поздно переходить в MEAN. Слишком стар. Но я-бы перешел просто потому что это
более новый взгляд на старое. Новое - всегда лучше чем старое.

Учу веб-разработку для фриланса - делать сайты на заказ (знаю, что рынок супер конкурентный). По книжкам выучил JS, HTML, CSS, базовый jquery (*тут могла быть ваша шутка*), к фреймворкам и библиотекам пока не приступал.

По поводу "размещать сайт". Это вообще не твоя основная цель. Цель - набить руку в системе.
Для этого тебе не нужно иметь свои хостинги. А нужно просто влиться в систему которая уже
их делает в режиме конвейера.

По поводу "выучил по книжкам". Ты не выучил еще ничего. И дело даже
не в техниках верстки. А ты пока не понял как работает процесс коллективной разработки софта.
Это сложно. Это интересно и эффективно. И ты будешь эффективнее в команде а не во фрилансе.
Работа в команде - это не только код. Это согласование ТЗ. Документирование.
Скрам-процессы. Корпоративная этика и кодекс поведения. Это как лак для дерева.
Ты - пригож для всех корпораций после этого. А во фрилансе хоть 40 лет просиди.
Никто характеристики не даст и не впишеться.

Поэтому лучше пойди в корпорацию. Покрутись несколько лет. Получи своё видение. И потом
уже во фриланс если будет желание.

Хочу понять, насколько глубоко надо лезть в бэкэнд

На этот вопрос сложно ответить. Ты скорее сам почувствуешь. Опять-же после опыта в корпорации.
Кстати и развиваться можно внутри корпораций вполне себе хорошо. И курсы и тренинги и сертификация.
ИЧСХ тебе корпорация их и оплатит.

Очень много. Практически все современные NoSQL-in-memory-dbms используют хеш-таблицы в каком-то варианте.

Хеш-таблицы являются частью механизма буферного кеша (страничного кеша) в дисковых БД. В Oracle, Postgres e.t.c.

Сам буферный кеш включает в себя структуры данных LRU поэтому можно сказать что LRU использует хеш-таблицы.

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

В простейшем случае ты можешь сделать такую табличку

b'\x01' => '01'
b'\xff' => 'ff'

Где одному байту будет соотвествовать 2 символа.

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

Ну и API-ев богатое множество должно быть.

По поводу твоих экспериментов с utf-8. Там есть запрещенные комбинации байтов. Потому
не любой рандомный массив байтов обязан преобразовываться в символы.

В SQL - много таких особенностей. Тоже самое с group by и оконными фунециями. Надо много повторяющихся expressions написать.

Попробуй еще так написать.

WITH HT AS (
 SELECT `product_id`, MD5(`value`) AS myhash
  FROM modx_ms2_product_options
  LIMIT 10
)
SELECT * FROM HT WHERE `myhash` = 'e59253548ffcb090ecc0cd0944afd27f'

Да может. Мобильные телефоны используют уже обученные модели для коррекции лиц.

Поскольку речь идет уже об обученной модели - то от нее много не потребуется. Кроме того
в задачах работы с графикой всегда есть большая фора - разрешение картики. Если ее регулировать
то можно даже слабую конфигурацию заставить работать но она будет работать с разрешением 320х240
хотя и будет терять лица которые слишком далеко отошли от камеры.

Такое связывание специфично для Java-фреймворков а не для языка С.

Я-бы предложил обсудить вопросы безопасности. Что будет если пользователь вызовет функцию которую ему нельзя вызывать? Как мы вообще ограничиваем пользователя? Стоит-ли такая гибкость получаемого удобства? Может лучше пойти классическим путем? Перечислить все возможные варианты действий явно и в switch-case обработать?

Сравнительно недавно в Кафку завезли новый стандарт кворума на основе Raft-протокола. Это означает что Смотритель зоопарка будет скоро не нужен и его можно будет выкинуть нафик. А все ноды Кафки будут решать кворумные вопросы самостоятельно.

Тут надо сезон "разлохматить" на 4 входа. Обычно НС не работают с текстовым вводом. Поэтому
будет во входном слое 6 входов типа:
- area
- AC
- isSummer
- isWinter
- isSpring
- isAutumn

Всем сезонным факторам присваивается нолик на входе кроме текущего сезона.
Там можно дать единичку. Для признака кондиционера тоже можно брать 1.0 если он есть.

Дальше можно искать решение в виде например однослойной сети. Я-бы пошел от простого.

И данных нужно побольше. Чтоб хотя-бы была выборка учебная и контрольная.

Нормальный Б/У десктоп будет лучше чем все эти Распберри и ардуинки. Я не понимаю чем там автор хочет
заниматься но эти все просто несерьезно. Любая верстка - предполагает хорошую клавиатуру а работа
человека за столом - предполагает нормальный монитор. Все эти телевизоры и джойстики и блютус-игровые клавиатуры - дадут вам билет в хронические заболевания глаз, шеи и поясницы.

Работать нужно засучив рукава а не дурачится.

В классическом SQL нет возможности работать с массивами и списками внутри одной ячейки. Фактически - это таблица не удовлетворяющая 1НФ и поэтому она не имеет право на жизнь.

Explode. Да, верно. Функция explode разворачивает строки на 90 градусов и позволяет посмотреть на participantid как на дочерние строки от основной таблицы. Но объем обработки как-бы возрастает и если вы передаете эти развернутые стороки на клиента то соотв. растет размер трафика. И работать с такой опухолью не лучше т.к. уникальность по PK/UK переносится на эксплоднутые атрибуты.

Как с этим бороться? Никак. Надо переделывать софт.

Like не работает. Это да. Это - проблема.

Swap может быть полезен для режима Hibernate.

Сама формула расчета размера свопа была разная для разных объемов оперативки для разных линуксов. Кажется для памяти меньше чем 2Гб рекоммендовалось брать своп хотя-бы в 2 раза больше. Для иного варианта - брать хотя-бы не менее чем размер свопа.