mayton2019

Да. Идея хорошая включить более тихие и медленные диски на 5600. Для домашнего кинотеатра - циркулярные
пилы не нужны. Я как-то видел как инженеры по системам хранения включали хранилище Clarion на Hitachi 14 000 оборотов. Ну и блинов там в стойке было штук 20. Ну было ощущение что рядом взлетает истребитель.

По поводу 5600. Посмотри как они включены. В современных матерях стоят уже SATA 3.0 но чорт его знает. Я видел гибриды где были и новые слоты и старые.

Сколько нужно для просмотра кина в 4К качестве я не знаю. Это очень хитрый и лукавый вопрос. Дело
в том что 4К трафик сильно зависит не только от разрешения но и от того как релизер сжал кино или
сериал. Я никогда не сжимал 4К. Мне хватает FullHD для сериалов. Но я пережимаю через ffmpeg
заменяя кодек звука и видео просто на тот который подходит под 2 моих стареньких телевизора LG.
Могу показать скрипты. По сути я заменяю видеоряд AVC на libx264 и звук на mp3. Вот и 60 fps можно
тоже проредить в 2 раза. Мне вот кино привычнее смотреть так. А аниме сериалы вообще едвали
до 10 фпс доходят.

Еще есть у меня мысль что под громким маркетинговым термином 4К могут быть скрыты несколько разрешений
меньшего размера. Тут - таже история что и с Wifi/3g/4g. Эти термины созданы чтобы продавать нам
услуги но они не гарантируют полосу и не являются технической спецификацией. По крайней
мере 4К существует 2 вида.

Поэтому качайте с торрента любое разрешение и скорость. И потом за 3-4 итерации пережатия
можно всегда найти набор параметров чтоб воспроизводилось на медленных дисках. И
я готов спорить что разницу вы особо не заметите.

Татьяна. Техническое задание так не пишут. Напишите что дано. Какие стандарты и протоколы там работают.
Приведите пример данных. И пример того как оно должно быть на выходе.
Может и можно извлечь. А может и нет. Черт его знает. Но при такой постановке вопроса вы можете спршивать
гугл или чят-GPT и пробовать рецепты длиной в 1 строчку.

Заказчик сам выбирает обычно. Исходя из денег. VPS или bare-metal. Насколько амбиций хватит.
В последнее время все тяготеют к Kubernetes. Он как-то динамичнее утилизирует доступные железки.
Если VPS подняли. Поставили ОС. Поставили софт .... и побежали твои денежки к облаку.
А с кубером так. Захотел бигдату посчитать. Написал джоб. Запустил в кубере. Джоб отработал 1 час.
И ты заплатил ровно за 1 час. Дисковые хранилища там почти бесплатны. По цене грязи.
Ну з IOPS в пике можно заплатить. Но в целом пока джобы не работают ты ничего не платишь.

Вот. Еще лямбды (AWS) и clound-functions (другие облаки) тоже потребляют по 1 центу за вызов.
И при этом ее хостинг тебя не волнует. Она поднимется на любой виртуалке где есть ресурсы.

Поэтому не bare-metal -> VPS. А все еще запутанее хитрее. Железо. Виртуализация. Потом что там...
контейнеризация... Потом FAAS. Функции. Вот поэтому вопрос звучит не какие сервера поднмиаются
а какой бизнес-функционал лучше летает на каком уровне этой лестницы.

Поскольку вопрос тегирован алгоритмами - человек пытается ИХ изучать а не контракт array.sort.

В науке и технике... в качестве алгоритма сортировки любят использовать сортировку Хоара.
Она-же Quick Sort. Еще в переводной литературе ее называют Быстрая сортировка делением.

Еще я где-то читал (не помню где! блин) что ядро Linux иногда использует для своих нужд HeapSort.
Или сортировку Пирамидой. Или пирамидальную. Достаточно быстрая и не требующая дополнительной памяти
вообще. По месту сортирует.

Более полное демо по алгоритмам с визуализацией здесь

https://www.youtube.com/watch?v=kPRA0W1kECg

Какую под капотом реализует JavaScript sort - чорт его знает. Но возможно одна из самых быстрых.

Мне кажется что проблема не в телеграм библиотеках а как всегда в классических вопросах С++.
Контроль над памятью например. И если взять за формулу что ТГ-бот - это типичное реактивное
приложение то преимуществ С++ здесь вобщем-то нет. Нету задач которые бы загрузили CPU.

А если задачу развивать в части интеграции например с MQ/документными БД (Mongo) или с
веб-апи криптовалют то окажется что С++ в такой интеграции стоит еще в 2 раза дороже
и во времени разработки и в поддержке. А конечному пользователю вообще плевать на чем
бакенд бота написан.

И окажется в сухом остатке что наговнячить бота на Node или на Python будет дешевле. И поддерживать
код тоже дешевле. Вносить изменения - легче и быстрее. Для бизнеса - вообще скорость внесения
изменений в продукт - это метрика №1. Кто вышел с маркетинг акцией в срок - тот заработал денег.

Если-бы я был бизнесом и хотел бы свой ТГ-бот то я-бы не вкладывался в С++ (хотя я уважаю этот язык).
Я-бы нанял команду Ноде-Жс и все было бы норм.