Uno

гуглите "linux hardening"

после авторизации в putty нужно запускать screen и уже в нем запускать сервер.
Что бы подключиться позже к этому screen, нужно запускать его с опцией screen -rd (-d это закрытие уже открытого соединения с screen в другом окне или если оно 'повисло', например если закрыл putty не закрыв screen с помощью кнопок ctrl+a d)

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

Да, уже считал, и это действительно реально, с относительно небольшими затратами (16-20т.р.) если тебя устроит скорость исполнения в 15-30 секунд на токен (на твоем железе llama31-70b на процессоре и 64гб оперативке будет работать токен в 1-1.5 секунд).

Необходимо собрать самый дешевый pcie nvme ssd программный raid0, купив контроллер pcie-x16 3.0 или 4.0 из четырех разъемов nvme либо четыре pcie-4x дешевых 3.0 и закупить самые дешевые nvme ssd диски от 128гб (со скоростями чтения от 2гбайт/сек).

Затем собрать из них raid0 с чередованием (win/linux это поддерживают) и разместить на нем gguf файл. llama.cpp поддерживает загрузку файла с весами с диска, без выделения оперативной памяти (но она нужна на контекстное окно, в зависимости от его размера это будут десятки гигабайт). Файл будет считываться по кругу целиком, по разу на токен, а значит скорость будет определяться именно этим. 2гб/с*4 диска = 8гб/с, 256гб 4бит квантизация будет считываться за 32 секунды.

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

Ну скорее всего никак. Кому надо тот всё равно запишет, так или иначе.
Например я могу запустить ОС в вриртуалке, открыть сайт, а видео записывать средствами управления виртуализацией.. например в Vbox такое есть)

Даже на закрытых плеерах с DRM эта защита не спасает. Ничто не помешает переткнуть кабель из монитора в карту видеозахвата. Или тупо поставить перед монитором камеру.

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

4pda основан на ip.board, все загружается без танцев с бубном, только осторожно, без авторизации получаются другие страницы чуть в ином формате. Вот пример кода на основе simple_html_dom:

<?php
include('simple_html_dom.php');

// ссылка на первую страницу темы
define('START_URL','https://4pda.to/forum/index.php?showtopic=1084129');
// количество страниц &st= из ссылки » в навигаторе по страницам
define('PAGES_CNT',580);

@mkdir('data');

for($i=0;$i<=PAGES_CNT;$i+=20)
{
	// формируем url
	$url=START_URL.($i==0?'':'&st='.$i);
	// имя кеш файла чтобы не загружать повторно
	$cache_fn='data/'.md5(START_URL).'.'.$i.'.html';
	if(!file_exists($cache_fn))
	{
		// Загружаем страницу
		$data=file_get_contents($url);
		// сохраняем страницу в кеше
		file_put_contents($cache_fn,$data);
		// пауза между запросами к серверу для защиты его от ddos
		sleep(1);
	} else
	{
		// читаем из кеша
		$data=file_get_contents($cache_fn);
	}

	$html=str_get_html($data);
	$num=0;
	foreach($html->find('div[class]:not([class=""]') as $post)
	{ // перебираем посты в теме
		// пропускаем первый пост темы, он дублируется на каждой странице
		if($num++==0) continue;
		// выводим пост на экран
		$post_html=$post->find('div.post_body',0)->text();
		echo $post_html.PHP_EOL;
	}
	// вставляем разделитель между постами
	echo '<hr/>'.PHP_EOL;
	$html->clear();
}
?>

вернет на экран посты указанные в START_URL, мне лень было вычислять конец треда автоматически, бери количество постов вручную из навигатора постов.

Страницы можешь вручную указать for($i=0;$i<=PAGES_CNT;$i+=20) вместо 0 - начальный (с шагом 20) и PAGES_CNT конечный пост.

Вместо текстового представления $post_html=$post->find('div.post_body',0)->text(); можешь сложнее структуру сообщения анализировать, выявляя цитирования и к примеру исключая их из текста (они занимают большую часть всего, дублируя многократно информацию).

Конкретно этот пример не влезет в контекстное окно бесплатного claude - это 70к токенов. Поэтому дели на куски.