d'Ivan

Данная технология называется OCR.
Можно использовать OCR движок для распознавания например tesseract-ocr
Со списком команд и как экспортировать текст из PDF в TXT ознакомься уже сам )

Пишешь скрипт который будет отправлять страницы с изображениями в OCR, далее так же скриптами на выходе склеиваешь обработанный текст с уже имеющимся.

Не читал, но не осуждаю)

Я считаю, что если многие советуют, то можно брать, если хотите.

Go - язык немного особенный в плане устаревания информации. Если, например, купить книгу по JavaScript того года, то это будет супер-вредно, потому что в те времена это был чуть ли не другой язык.

А создатели Go с самого начала заявили, что обратная совместимость будет одной из основных характеристик языка. Роб Пайк вообще говорил, что Go 2 никогда не будет.

Так же, из-за простоты языка существует великолепный феномен, когда разные программисты, решающие одну и ту же задачу, напишут практически одинаковый код.

Всё вышеперечисленное позволяет мне, даже не читавшему эту книгу, заявить, что вреда она вам точно не причинит, и предположить, что принесёт пользу.

P. S. Совет лично от меня: читайте книги по программированию на английском. Очень часто переводчики просто бредят как ChatGPT, и некоторые книги просто невозможно читать.

Безотносительно к способу создания exe из python, рассылка exe по почте это уже маркер для антивирусов, это классический путь распространения вредоносов и нормальной практикой вообще считается блокировка этого типа контента.

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

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

Так же, помимо получения цифровой подписи, настоятельно рекомендуется распространять свое приложение не в виде exe файла а в виде установочного пакета (например как приложение microsoft store или msi). При использовании microsoft store за обновлением приложений будет уже отвечать операционная система, т.е. доставкой и переустановкой пользователю не придется заниматься (на самом деле придется, но значительно проще, ведь автообновление не моментальное, а значит топать в настройки обновлений и кликать кнопку - скачать обновления) но это правильный способ.

upd. https://learn.microsoft.com/ru-ru/windows/apps/pub...

Используй утилиту cut, она идеально подходит для решения твоей задачи
cut --delimiter=; --fields=1 input_file.csv
Результат будет выведен в консоль, можно перенаправить в фай, добавив в конец строки
> out_file.txt

https://github.com/dataegret/pg-utils/blob/master/...

Вот популярные системы в порядке понижения функционала:

Xen — на порядок сложнее и функциональнее, имеет помимо режима паравиртуализации (как openvz) режим полной виртуализации (в т.ч. поддержка соответствующих фич процессоров), есть механизмы переброса железа внутрь виртуалки (например, поддержка не самых слабых intel видеокарт), снапшоты, миграция,… много много вкусных фич.

VMWare — как и xen, сложен, наворочен, приправлен соответствующей инфраструктурой и хорошими забористыми ценами :) режима полноценной паравиртуализации не имеет

kvm/qemu — полная эмуляция процессора (а так же виртуализация через поддержку процессорами), есть вкусности от 'старших братьев' вида миграция запущенной виртуалки по сети, переброса железа (сильно хуже поддержка чем xen/vmware) и т.п. можно считать бакэндом, так как GUI в идеалогии не имеет, оно пилится желающим

VirtualBox — эмуляция процессора, в т.ч. использование поддержки виртуализации процессоров, идеален как отдельное десктопное приложение, миграции по сети нет, есть снапшоты, некоторые вкусности скрыты от GUI в коммандной строке

OpenVZ — это работа всех машин на одном ядре (патчи к нему так и зовутся openvz), нет виртуализации, максимальная скорость (так как фактически это расширенный chroot с изоляцией). Для запуска модуля ядра на поклон нужно идти к хост системе и ее администратору (например tun/tap адаптер у firstvds дают по запросу)
Снапшотов нет (но их реализуют через lvm), миграция есть, есть сброс состояния контейнера на диск и возобновление работы…

Lxc — еще проще чем openVZ, нет даже грамотной изоляции (если подсуетиться, можно, имея рут в контейнере, выйти в хост систему с рутовым доступом), прямой аналог jail во freebsd, имеет смысл для хитрых сетевых конфигураций, тестов и т.п.

Chroot — это даже не виртуалка, это просто простейшая изоляция в пределах файловой системы, подмена путей в вызовах функций работы с файлами.
p.s. lxc называют еще 'chroot на стероидах'

OpenVZ/lxc/chroot поддерживают почти полноценное каскадирование виртуалок (т.е. к примеру можно внутри контейнера openvz запустить kvm/virtualbox при наличии модулей, даже с поддержкой аппаратного ускорения)

Это зловред

Так как вопрос общий и не конкретизирует будущую работу и выбор ОС, то настоятельно рекомендую почитать про сети и типовые конфигурации, с ними больше всего работы и она универсальна, для любой ОС.

Следующий кандидат на изучение IPC (Inter Process Communication), мультипоточность, синхронизация, семафоры, мьютексы и т.п. Можно полистать про пайпы, они по разному работают в разных ОС т в каком то смысле это одновременно и сети и IPC.

До кучи - работа со временем, не совсем ОС но она чуть чуть может отличаться от ОС или выбранного фреймворка.

Ну и совсем голая практика - работа с GUI, базовые отличия и особенности (например почему в linux GUI это сервер, или почему в windows, 'схватив' заголовок окна мышкой, можно поставить на паузу стартовый поток).

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

Ничего не пишите, поставьте minio.

До нескольких терабайт, при условии что сайтом очень активно пользуются, сотни мегабайт трафика и т.п. - самое дешевое это использовать свое хранилище, на основе hdd (при большой нужде - ssd), настраивать raid1 или raid5, используя минимально возможное количество дисков на массив (т.е. если 10 дисков то делать либо 2 рейда по 5 дисков либо три по 3 диска, не делать один огромный рейд - особенно если это hdd, он будет медленный). Хранить в виде файлов как они должны отдаваться, метаинформацию - в базе данных.

Если дисков в своем хранилище больше 20, или если сетевой трафик очень маленький, условно за сутки один-два пользователя смотрят фоточек на десяток другой гб. либо если суммарно хранимый объем превышает десятки-сотни терабайт, то строить свое хранилище становится значительно дороже и лучше идти в облака. Самое популярное это амазон s3, в его формате такие услуги предлгают и российские провайдеры типа селектела или яндекса. Тарификация там двойная - за сетевой трафик (по разному на загрузку и выгрузку) и за хранение от объема.

Серверу пофиг по какому домену он отвечает. соединение идёт по айпи адресу. Какому адресу соответтсвует тот или иной домен хранится в днс-сервере.
Можно сколько угодно доменных имен присвоить одному адресу вашего сервера. Дополнительной нагрузки вы от этого никакой не получите.
Единственное, что для описанной вами задачи важно, это по имени домена чтобы ваш сервер понимал какой контент отдать.
То есть обращние идет по айпи адресу, но имя домена все же передается в параметрах http-запроса.
Почитайте как работает HTTP протокол.
Вот вы можете на любые обращения к вашему серверу отвечать одним и тем же бэкендом, а он по имени домена из запроса будет понимать какой контент отдавать.

Rust currently provides only the bare essentials for writing async code. Importantly, executors, tasks, reactors, combinators, and low-level I/O futures and traits are not yet provided in the standard library. In the meantime, community-provided async ecosystems fill in these gaps.

There is no asynchronous runtime in the standard library

Из документации.

Перед отправкой текста на машинный перевод заменяй блоки кода и форматирования на непереводимые токены: блок с кодом целиком, а у форматирования заменяй управляющие символы. После машинного перевода делай обратную замену.

Берёте исходники самой старой версии ФФ, которую найдёте, собираете. Оно, разумеется, не запустится. Патчите все возникающие ошибки, собираете. Если сил хватает, делаете то же самое для более новой версии. Повторить.

Зачем хранить образы после сдачи проекта? У вас есть Dockerfile, в случае чего ничего не стоит развернуть всё заново.

Если же вы про какие-то сакральные данные - как их хранить, после сдачи проекта решает клиент. Тратить на это свои деньги, конечно же, не стоит.

как объяснить программе, что на снимке снег, а что облака

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

Примеров подбирай по больше, тысячами. Старайся чтобы количество с облаками, со снегом и без них было примерно одного количества. Яркость изображений нормализуй, сохраняй пометку об исходном уровне света (по текущей долготе и времени съемки можно понять день, вечер, ночь, утро...), кстати от времени года и высоте над уровнем моря наверное тоже можно понять, имеет ли смысл искать тут снег или нет. Затем увеличивай обучающую выборку вращением исходных примеров и запускай на обучение.

Вся работа тут - формирование обучающей выборки и подбор гиперараметров нейронной сети.