rPman

В конечном счете все решает стоимость решений

Выделенный сервер (dedicated server upd или bare metal) - это буквально физический сервер, мощности которого принадлежат тебе и твоим программам
Виртуальный сервер (virtual private server) - это когда физический сервер делят на части и продают по отдельности, что сильно дешевле, и удобнее хостеру (он может перекидывать виртуальные машины между физическими, оптимизируя нагрузку), мало того он может оверселить, продавая и обещая больше мощности чем доступно в среднем, надеясь что пиковую нагрузку сервис клиента будет давать редко а остальное время она будет низкой (так обычно и бывает), такие машины обычно самые дешевые (когда видишь предолжения ниже ~30$ это оно самое)

Кстати нормальная практика даже для dedicated server жесткие диски заменять на NAS например iscsi, а реальный диск предлагать как опцию. Сетевые накопители обычно медленней но сильно дешевле для хостера, так как их так же можно делить, снапшотить (например за их счет делать дешевый бакап) и оверселить (а главное централизованное обслуживание, так как диски чаще всего выходят из строя).

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

Но нужно понимать что фишки гибкой конфигурации даются не бесплатно и если у тебя постоянная нагрузка, VPS оказываются дороже dedicated server. Правильный подход кроется в комбинировании.

И еще одна услуга у хостеров - предоставление не сервера а услуги - доступа к програмному обеспечению по какому то внутреннему алгоритму тарификации (Software As A Service). Например можно приобрести услугу http сервера (или к примеру хостинг nodejs бакэнда, отдельно базы данных, сервиса бакапов и т.п., такие точно есть), без покупки самой машины, с тарификацией по запросам, трафику или по внутренним cpu тикам, при этом пользователю не важно, сколько там в реальности задействовано серверов, хостер будет обеспечивать заказанный трафик с обещанной скоростью, только плати. Такие крупные провайдеры как гугл или амазон могут встраивать в свои прайсы на такие сервисы ловушки, не изучив и не подготовившись как следует к которым можно попасть на значительное повышение стоимости, к тому же часто такой доступ еще и привязывает клиента к конкретному провайдеру, так сильно что когда придет известность и нагрузка, может не получиться легко сменить хостера на более оптимальный.

Самое простое и правильное - в файле, как есть, для удобства обслуживания в файловой системе, контейнер которой отделен от всего остального (лучше отдельный раздел или диск, но при особой бедности - файл, который можно примонтировать в любой фс, например в windows это .vhd/.vhdx образы, а в linux вообще просто образ диска в raw формате), зачем отдельное устройство? - для упрощения обслуживания, когда там будет миллион файлов... в linux настоятельно рекомендую пользоваться cow fs (btrfs/zfs/xfs) ради встроенных бесплатных транзакций на основе снапшотов, плюс инкрементальные бакапы эффективно делать.

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

Во многих случаях рекомендуется не хранить много (десятки тысяч) файлов в одном каталоге, отсюда сразу напрашивается способ - если имя файла состоит из цифр (или hex или вообще base64, на выбор) то разбив его на фиксированной длины части можно использовать их как имена каталогов, последняя часть - имя собственно файла в них (типа /datastore/0d6a/011fc/0012.jpeg).

Достоинства
- для web, файлы очень эффективно могут быть отданы веб сервером (при необходимости права доступа разруливаются basic auth либо временными симлинками, хз что дороже)
- с файлами могут работать огромное количество утилит, поиск, копирование, редактирование, просмотр.. напрямую, когда как с любым другим хранилищем сначала файл придется от туда извлечь, т.е. понадобится соответствующий инструмент

Недостатки
- наверное единственный заметный - файловая система не интегрирована с sql базой данных, а это значит при возникновении каких либо проблем, например удаляли файл в базе, но из-за ошибки или сбоя какого-либо, на диске файл не удалили, и он остался так висеть, обнаружить такое, на особо больших хранилищах - дорого
- если файлы раскидывать по подкаталогам (имя - идентификатор файла) то сама по себе эта операция не бесплатная и при большом количестве вложенностей повышает нагрузку на процессор и накладные расходы на диск, незначительно но заметно на больших архивах (такова цена за бесплатный key-value индекс), в некоторых ситуациях можно этого не городить, храня файлы в одном каталоге, но миллион файлов могут создать проблемы привычным утилитам.

p.s. ну или вот qna.habr.ru/q/10694/#answer_46206

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

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

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

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

Из минималистичных и вполне функциональных DE можно предложить еще какой-нибудь openbox, его можно настроить так чтобы вообще никаких 'пуск' и списка задач не было, а только иконки и приложение на весь экран. Но пользователь сможет добраться до редактирования меню и запустить любое приложение, т.е. это не для kiosk mode

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

На самом деле процесс запуска DE стал очень замудреный, его запутали несколько поколений разработчиков и выпутывать не желают, но обычно все это критично для тяжелых DE типа KDE, а что то простое и легкое с приложениями на gtk работает и так

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

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

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

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

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

lvm? lvextend