Алексей Черемисин

Нет ПК не заработает, либо Вам надо эти ножки аккуратно поднять или же покупать новую мать. Надеюсь помог.

Работают они очень просто: рисуют красивую анимацию и пишут «ваш комплюктер ускорен на 10000%», а сами тем временем подсаживают какую-нибудь малварь.

В любом нормальном клиенте есть аналогичная функциональность. В DBeaver, например.

Тупо при запуске программы создай /tmp/procname.pid в которой впиши pid .
При запуске проверяешь наличие файла, смотришь в него и убеждаешься что по такому pid процесс живой.
При закрытие программы удаляешь файл.
Другими приложениями просто смотри наличии файла и то что процесс живой.

Так просто прочитайте устройство стандартной POSIX файловой системы, та же ext2 - ext3
Когда основные термины и представление будет в голове, новые фичи легко кладутся на базовое понимание.
Ваши RecordIO и webdataset по сути ничем сильно не отличаются от любого другого контейнера, где данные хранятся в упакованном виде. И собственно понимание как хранится один единственный файл в любой файловой системе дает также интуитивное в чем преимущество контейнеров.
Еще хороший вариант, прочитать как устроена FAT16, и сравнить с тем как устроена EXT3

Годится самый обычный, лишь бы винт побольше, чтобы дуалбутом стояла винда с линухом (hint - не kali).

Желание заниматься ИБ - это примерно как желание водить автомобиль - в ИБ направлений ничуть не меньше, чем марок автомобилей :)

Правда, сразу надо сказать, что желание поставить kali выдает не желание заниматься ИБ, а желание понтоваться тем, что занимаетесь ИБ :) Впрочем, если сможете одолеть установку самостоятельно, не спрашивая здесь ничего - может из Вас чего толкового и получится :)

Нет. Внешний KVM можно сколхозить из IP-KVM, но поддержка мониторинга должна обеспечиваться матерью. Лучше "собери комплект" из бу серверной платформы, которую за недорого можно купить на ittelo.ru, например. Она, конечно будет 5 - 10 летней давности, но в ней будет встроенное IPMI.

Из собственного опыта: в 2018 году купил там ASUS RS-500-E6/PS4, сборки аквариуса (на шильдике надпись "Aquarius Telecom server"). Этот самый сервер практически без обслуживания отпахал пять лет (причем год в очень тяжелых условиях - грязь, жара, сто тысяч тараканов), после чего у него сдох БП. БП у него фирменный, замена стоит 18 тыс.
Новая платформа такая же (корпус, ризер, БП, мать, два ксеона похуже чем у меня) - 20 тыс. Правильно - я купил новую платформу и она сейчас пашет.

Кину 5 копеек по поводу работы с датами. Да это зло. Работа с датами в современном API это
самый большой технический долг начиная с Unix, когда дата представлялась секундами с 1970 года
в виде DWORD. Я не встречал ни одного языка программирования и ни одной DBMS где изначально
была-бы какая-то очень строгая и математичная концепция работы с временем. Везде были ограничители
в основном завязанные на примитивные типы либо на строки вариативной длины. В Java например
долгое время экплуатировался тип java.util.Date который сегодня считается дыркой (мутабельность)
и неточным и его заменяют на java.time.* семейство типов. Параллельно с ним где-то в космосе
висит java.sql.Date который декларирован в интерфейсах JDBC как основа для БД. С ним-же и работают
все драйвера реляционных бд.

По поводу вычислений на application tier. В последнее время DBMS девальвировали. И в основном
используются в микросервисах как хранилище таблиц без особой логики. В этом есть свои смыслы.
Например удобнее тестировать и хранить 100% кода в языках Java/Node/C#. Это создает гомогенность
языка в проекте. В противном случае логику пришлось бы неизбежно резать на 2 слоя и хранить
половину в application и другую половину деплоить через flyway/liquibase в БД при этом еще и
не забыть тестировать 100% совместимость тех-же функций для работы дат-времени (никто
кстати невкурсе что в Oracle год может быть 9999 а java.util.Date мне удалось сгенерировать
такую Aug 17 09:12:55 EET 292 278 994. .. оптимистичненько доживем до 290 миллионов
лет хотя проблема comparison этих типов остается) Стандарты ISO помогают но они скорее
декларируют намерения сохранить нужное значение. Вот и если вы новичек - то я гарантирую
что вы словите кайф в попытке в Java разобраться в проекте какой тип дат вам брать. И еще
помножите это все на типы данных БД (их там будет 4 штуки обычно. Парочка для зональных
и парочка для локальных).

Использовать или нет функции PG? Ответ - it depends. В некоторых случаях оптимизатор не видит
индекса если ты делаешь неявный кастинг из строки в дату например. Я тут не уверен надо проверять.
Но есть старая админская поговорка. Плохой execution plan - проверь типы данных в предикатах.
Беда реально существует для Spark/Databricks и даже включена в учебный план. По крайней мере int/Long
различается на уровне Catalyst-optimizer. Вобщем если вы - лентяй то можете лупить строки вместо дат
и надеятся что SQL машина правильно интерпретирует. Если вы хотите быть точным то делайте CAST или
to_date с явным описаловом YYYY-MM и т.д.

Еще один поинт в части где хранить логику. Это я пишу просто для кругозора. Чтобы топик
не циклился вокруг Постгреса а люди видели пошире. В классических БД данные качаются
к клиенту. Тоесть делаете SELECT * из миллирад строк - и этот миллиард будет прокачан до конца
когда вы читаете резалт-сет по сети. Такова парадигма. Или курсор. Но суть таже. А в BigData данные
лежат на месте но к ним "ходит" код. Вот такой метафизический парадокс. Сами понимаете что
тут получается что встроенных функций даже как бы ... и нет. Подчеркиваю разницу.

Навскидку:

1. Звезда - плохо. Случись что, и сегмент отвалится. Я бы делал как минимум кольцо, и в него ERPS или RSTP (ещё лучше - кольцо на ERPS, а дальше RSTP). Ещё лучше - два кольца. И из тех же соображений надёжности - минимум два магистральных коммутатора на площадку/здание.
2. Неуправляемые коммутаторы - забудьте как страшный сон. Например, надо перестартовать камеру по питанию - что, бежать к камере? да даже элементарно посмотреть статус коннекта... ставьте PoE L2.
3. Транки я бы делал 10G.
4. Оптический коммутатор в центре достаточно L2 или L2+. У него вообще все порты будут в транке (tagged).
5. По части подсетей - для указанного количества оборудования я бы брал подсети /23 или /22 из 172.16. Избыток адресов ни на что не влияет, а их недостаток - это по определению геморрой. Оно надо?
6. Если подсеть исчерпала адреса - то перестраиваешь DHCP-сервер, раздающий адреса. Либо расширяешь подсеть, либо добавляешь ещё один скоп и организуешь маршрутизацию. Второе правильнее - ибо в любом сегменте найдётся оборудование со статическим назначением адресов (не статическое резервирование!), при изменении маски их придётся перенастраивать.
7. И я как-то не увидел управляющего VLAN, в котором будут только административные адреса коммутаторов.

является.
но для новичков обычно лучше начинать с linux mint \ ubuntu

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