Давно хотел настроить вход и sudo по отпечатку пальца, но, как известно, в линях это проблема - поддерживается небольшое количество сканеров. Большинство того, что есть на рынке - не поддерживается из коробки. На предыдущем ноуте был встроенный сканер, в винде он отлично работал, в линях - нет. В этом ноуте встроенного сканера нет, покупал USB. Ссылку на него оставлю в комментах.
Я попросил ИИ-шку помочь с настройкой, и вот что получилось:
Сразу предупреждаю - действий много нужно сделать - 22 листа инструкция
Важное замечание: я сам по инструкции не делал, делал все ИИ-агент подключившись по SSH к моему ноуту, так что рекомендую протестить на виртуалке сначала. Агент тоже сначала тестил на виртуалке (сканер замечательно пробросился и заработал).
Был серьёзный перерыв, потеря мотивации и всё такое, с момента последнего поста углубился в работу с консолью, поставил две виртуалки дебиан, одну кде, другую hyprland, обе снёс из за того что надоел весь этот сахар, сегодня более или мненее разобрался с psutils, написал что то типа мини утилиты для бекапа системы, не на что не претендую, писал не для использования а для освежения навыков и изучения библиотеки, вот код и вывод:
В ИТ-индустрии существуют вещи, само существование которых давно стало красивым мифом, о котором принято вспоминать лишь шепотом и закатывая глаза от благоговения.
Настоящий Cray.
Cray
На сегодняшний день, во всем мире осталось наверное не больше пары сотен инженеров, заставших «те времена» и имевших возможность прикоснуться к легенде.
Лишь единицы из них еще могут что-то рассказать.
То что описано в этой статье — редчайшее знание, которое совсем недавно было доступно горстке избранных, с ученой степенью, специальной подготовкой и допусками к такому оборудованию.
Огромное, древнее чудовище из далекого прошлого, из времен мифов и легенд ожило и вернулось к жизни.. руками фанатов.
Дав возможность и простым людям прикоснуться к легенде.
Seymour Cray на фоне собственного суперкомпьютера.
Легенда
Персона Сеймура Крэя навсегда останется в анналах истории компьютеров, поскольку созданные его руками машины неоднократно признавались самыми быстрыми на планете.
Создаваемые полностью вручную (некоторые модели — вплоть до чипов) и имевшие цену в десятки миллионов долларов, суперкомпьютеры Cray поставлялись в исследовательские лаборатории, крупные датацентры и конечно же в разведывательные управления разных стран.
Про последнее стоит рассказать подробнее:
суперкопьютеры Cray всю историю плотно ассоциировались именно с секретными проектами, поскольку действительно часто использовались для взлома секретных кодов, паролей и шифров.
Что характерно, сам Крэй начинал карьеру во флоте (US NAVY) и работал над взломом японских шифров времен второй мировой войны, по всей видимости сохранив с тех лет хорошие отношения с главным разведывательным управлением.
У вас же, дорогой читатель шанс увидеть суперкомпьютер Cray был лишь в кино, где они довольно часто мелькали в качестве реквизита:
Ни о работе с такими машинами, ни тем более о разработке под них простым обывателям не стоило даже мечтать, даже если они родились и выросли в США. Допуски, специальное обучение с сертификацией и чаще всего наличие PhD — вот что обычно требовалось от «пользователей» подобного оборудования.
В Россию суперкомпьютеры Cray предсказуемо завозились с очень большими препонами и исключительно простые модели. В частности в Росгидромете была практика использования таких машин, начавшаяся еще в 90е.
Как бы то ни было, простому обывателю доступ к суперкомпьютерам Cray был заказан.
Я сам, несмотря на двадцать лет практики в разработке ПО, о них лишь слышал краем уха, да видел пару картинок в сети, вроде такой:
Производство суперкомпьютеров Cray-1
Тем удивительней оказывается история, рассказанная ниже.
Так выглядел случайно найденный бекап от суперкомпьютера.
Симулятор
История создания симулятора Cray за авторством Andras Tantos сама по себе достойна голливудской экранизации, поскольку являет собой победу инженерного духа над всеми преградами и трудностями:
So it’s settled. I’m building a Cray-1.
Крайне рекомендую ознакомиться со всей этой историей, поскольку по накалу повествования описываемые события сильно напоминают историю изучения египетского письма или попытки расшифровать немецкие шифры времен второй мировой.
Для примера, чтобы только прочитать данные со случайно обнаруженной ленты, автору пришлось реализовывать специальный драйвер для виртуального контроллера, полагаясь на такие картинки:
Затем пришлось вручную восстанавливать последовательность загрузки:
Разбираться с багами загрузчика и эмуляцией сети — не забываем что речь идет про суперкомпьютер, все основные части которого были связаны между собой по сети.
Andras провел чудовищную по объему и сложности работу, в успех которой к тому же никто особо не верил.
Именно поэтому результат его трудов настолько впечатляет.
Фронтальная панель суперкомпьютера Cray и индикаторы стадий запуска. Сверху кнопка включения.
Оживляем легенду
Симулятор использует внешние приложения для работы: xterm, telnet, tmux
Все это необходимо установить на хосте до первого запуска симулятора.
Дополнительно я использовал cool-retro-term для наведения красоты, чтобы снимки экрана выглядели еще эпичнее.
Важное уточнение:
несмотря на использование сетевого telnet, полноценное взаимодействие с запущенной UNICOS придется настраивать позже и отдельно — запускаемый при старте telnet-клиент на самом деле подключается к портам симулятора, через которые происходит трансляция консольных команд в виртуальную ОС и обратно.
Настоящее сетевое подключение к UNICOS требует специальной настройки на хосте, а поскольку инсталляция происходит по сети — сей шаг является обязательным.
Настройка выглядит следующим образом:
brctl addbr craybr ip tuntap add mode tap tap1 ifconfig tap1 up brctl addif craybr tap1 ifconfig craybr 172.16.0.1 netmask 255.255.255.0
Несмотря на всю внешнюю монструозность, ничего сложного тут нет:
создается новый мост с именем craybr, затем создается виртуальный сетевой интерфейс tap1, которому назначается IP-адрес 172.16.0.1.
Последним шагом этот интерфейс добавляется в мост.
Название интерфейса указывается в конфигурационном файле симулятора, который называется unicos.cfg, выдержка:
.. EthInterfaces {
en0 {
InterfaceNameLinux tap1
InterfaceNameWindows "Cray Ethernet"
SimMacAddr 0x020143524159
Channel 020
IopNumber 0
}
}
..
IP-адрес должен быть именно 172.16.0.1, поскольку внутренний интерфейс в UNICOS указан как 172.16.0.2 и поменять его достаточно проблематично.
Можно зайти и немного дальше, включив роутинг наружу:
В случае Mageia исходящий интерфейс будет называться по-другому, что-то вроде wlp4s0.
На стороне UNICOS в симуляторе необходимо выполнить команду:
route add default 172.16.0.1
Ну и радоваться — ведь вы только что выпустили в сеть суперкомпьютер Cray, пусть и виртуальный:
Все что вы видите в консоли выше - оригинальный софт от Cray, для суперкомпьютеров Cray.
Готовая сборка
Существуют готовые сборки симулятора Cray для 64-битного Linux, c уже установленным UNICOS версий 10.0.0.2 и 10.0.1.2, созданные известным в узких кругах камрадом neozeed.
Проблема в том, что эти сборки на момент написания статьи успели устареть (от 2022 года) и не факт что заработают в вашей системе.
А планов по обновлению у их автора нет.
Запускается симулятор из этих сборок с помощью стартового скрипта:
./unicos
Не забудьте что перед запуском необходимо выполнить скрипт для настройки сети (см выше).
Так выглядит запуск UNICOS 10.0.1.2 в симуляции суперкомпьютера Cray J90:
Я заменил стандартный xterm, используемый симулятором по-умолчанию на cool-retro-term для большей эпичности скриншотов.
Но конечно у настоящего Cray J-90 не было настолько древних мигающих терминалов и все выглядело куда современне:
Если приглядеться, можно заметить на мониторе рабочей станции, характерные квадратные окна 4dwm — оконного менеджера SGI Irix.
Все потому, что в разные исторические периоды для суперкомпьютеров Cray использовались разные терминальные системы — SunOS, Irix и даже Mac:
Чтобы добиться такого же эффекта, измените поле настройки NewTerminalCommand в файле unicos.cfg:
Так выглядит UNICOS в запущенном состоянии:
Согласно описанию автора, в системе есть следующие учетные записи:
The root password is 'password' and I've created a neozeed user with the password of 'password' so you can telnet in
Входим от root:
Если вы все настроили правильно, также заработать сеть между симулятором и хостом, в обе стороны.
Появится возможность войти уже по сети, непосредственно на машину Cray:
Для завершения работы симулятора, введите команду exit в нижней консоли основного приложения и нажмите Enter:
То что нижний блок - тоже терминал, причем допускающий ввод, я догадался не сразу.
В принципе даже этой версии хватит для последующих развратных действий с участием компилятора (см. ниже).
Если у вас успешно заработала готовая сборка и нет настойчивого желания «собрать из исходников» — следущий шаг можно пропускать и переходить сразу к стадии действительно изысканных приключений.
Первые суперкомпьютеры Cray были обшиты натуральной кожей убитых инженеров.
Сборка из исходников
Несмотря на то что сие занятие — точно не для всех и любимый ChatGPT врядли подскажет что-то разумное по этому проекту, сделать все же стоит — для большего погружения.
Симулятор написан на C++, с использованием библиотеки Boost, поэтому компиляция из исходников протекает.. весьма неспешно.
Перед тем как запускать сборку необходимо установить следующие зависимости, версия для Ubuntu:
g++ make libboost-all-dev libncurses-dev libgpm-dev
Для Mageia:
gcc-c++ make lib64boost-devel lib64ncurses-devel lib64gpm-devel
Исходный код находится в каталоге simulator, поэтому сборка проекта также запускается именно оттуда, а не из корня репозитория.
Поскольку в пакетах Mageia нет статической версии библиотеки Boost, а для сборки Boost из исходниокв не хватило размеров статьи свободного места, я использовал динамическую линковку:
make LINK_TYPE=dynamic build
В Ubuntu сборка будет работать и вот так:
make build
Готовые бинарники будут находиться в каталоге simulator/_bin, но управляющие скрипты об этом знают, поэтому в ручную ничего перекладывать не надо.
Завершение установки на одном из сохранившихся Cray Y-MP, консоль - реальный терминал Wyse тех лет.
Установка UNICOS
Теперь самая интересная стадия, которую вы пропустите если остановитесь на готовой сборке:
установка операционной системы UNICOS в симуляторе суперкомпьютера Cray из оригинальных образов CD-дисков.
Когда-то, за процесс ввода суперкомпьютера в эксплуатацию, отвечала целая команда высококлассных и сертифицированных инженеров, которые тщательно оберегали свои секреты.
Но благодаря любопытным фанатам, теперь наконец и вы сможете в этом поучаствовать.
Как уже описывал выше, два случайно обнаруженных диска оказались единственными сохранившимися носителями загрузочного образа UNICOS и без них судьба симулятора сложилась бы совершенно иначе.
Оба диска являются загрузочными, первый содержит UNICOS версии 10.0.0.2 для модели Cray J90, второй — UNICOS 10.0.1.2 для Cray SV1.
Шаги установки полностью совпадают, но устанавливать я буду более свежую версию 10.0.1.2, со второго ISO‑образа. Несмотря на то что разные версии этой ОС предназначены для установки на разные суперкомпьютеры, в условиях симулятора все отлично работает.
Так выглядит модель Cray SV1
Инструкция по установке от автора симулятора, находится тут, но к сожалению она успела немного устареть, поэтому придется использовать описанные в ней шаги с небольшими изменениями.
Напоминаю, что все команды ниже, выполняемые с хоста, как и управляющие скрипты симулятора подразумевают использование bash.
Со стороны UNICOS используется ksh, но для стадии установки это не особо важно.
Для упрощения вводимых команд, зададим две переменные окружения:
В корневом каталоге симулятора появятся несколько новых файлов, нужный нам называется unicos.generic — то самое ядро.
На этой стадии можно наконец запустить симулятор, но пока с использованием образа RAMFS, который мы только что скопировали с установочного диска:
./unicos_ramfs
Запустится симулятор и появится терминал с подключением к UNICOS, запущенной в single user mode:
Кто бы мог подумать, что смогу запустить в Single User Mode ОС для суперкомпьютеров Cray!
Теперь настраиваем сеть на стороне UNICOS, поскольку следующим шагом необходимо копировать системные файлы с примонтированного ISO-образа.
Напомню что подключение через telnet происходит на самом деле к самому симулятору, не к эмулируемой ОС внутри.
Вводим в консоли UNICOS:
ifconfig en0 172.16.0.2
После выполнения команды должна отрабатывать команда ping до хоста:
Дальше начинается еще один интересный этап, полный боли и страданий, поскольку придется встретиться с одной очень древней технологией передачи файлов между компьютерами — rcp.
UNICOS, который мы с вами запускаем это система из далекого 1997 года и ничего другого для передачи файлов в ее загрузочном образе просто нет.
Когда-то предполагалось, что весь процесс установки и запуска в эксплуатацию суперкомпьютера — строго секретный, поэтому с «usability» не заморачивались.
Есть еще один важный нюанс:
единственная доступная в образе утилита для передачи файлов на расстояние это клиент.
Для того чтобы подключиться с его помощью и скачать файл, надо поднимать сервер, сервер древнего rcp и на современном линуксе.
Ввиду своей древности, rcp в любом виде (как клиент и как демон) давно отсутствует по-умолчанию в любых линуксах и BSD, а его установка и запуск в современном окружении требует «особой уличной магии».
Для Ubuntu вам будет необходимо установить пакеты:
rsh-client rsh-server
Для Mageia:
rsh rsh-server
В последней запуск rsh-сервера происходит через демон xinetd, который по-умолчанию отключен и попытка запуска будет выдавать ошибку:
xinetd.service is not active, cannot reload.
Поэтому сначала запускается xinetd, затем rsh:
service xinetd start service rsh start
Следующим шагом необходимо разрешить использование демона rsh по сети (входящие подключения), для Ubuntu необходимо добавить строку в файл /etc/hosts.equiv:
172.16.0.2 +
Для Mageia используется файл ~/.rhosts.
Это позволит подключиться к хосту и скопировать стартовый скрипт инсталляции в запущенную UNICOS.
Но прежде чем копировать, скрипт необходимо немного изменить.
Открываем файл install (находится в корневом каталоге симулятора) любимым редактором vi и заполняем значения переменных:
LOCAL_LOGIN = имя пользователя на хосте
ISO_MNT = /полный/путь/к каталогу с образом UNICOS
Также добавляем новую переменную SIM_LOC, которой устанавливаем значение в виде полного пути к каталогу с симулятором.
Заранее предупреждаю, что в скрипте инсталляции есть небольшая ошибка, связанная с определением версии устанавливаемой системы. На процесс инсталляции она не влияет, но бесит и раздражает, поскольку появляется в самом начале.
Чтобы ее избежать, необходимо задать еще одну переменную:
UNICOS_EXE=UNICOS_exe
В результате всех описанных выше правок должно получиться такое:
Финальный скрипт установки операционной системы Cray, мама будет вами гордиться ;)
Cохраняем изменения, затем на стороне UNICOS вводим команды, заменив предварительно имя пользователя и путь к симулятору:
cd / rcp alex@172.16.0.1:/opt/work/cray/cray_sim/install .
В результате выполнения команды файл install будет скопирован с хоста и появится в корне файловой системы UNICOS:
Появится сообщение с перечислением введенных параметров:
Нажимаем любую клавишу и запустится увлекательный процесс установки операционной системы для суперкомпьютера Cray:
Несмотря на эпичность, это всего лишь копирование файлов по сети.
Процесс достаточно длительный и занимает несколько часов, вне зависимости от мощи вашего оборудования, так что вполне успеете принести кровавую жертву темным богам выпить чаю в хорошей компании.
В самом конце установки, будет предложено установить пароль для суперпользователя, а также будет запущен диалог создания учетной записи обычного пользователя.
После чего установка наконец будет завершена:
Да, вы только что установили ОС на суперкомпьютер Cray, пусть и виртуальный.
Во время установки UNICOS происходит один очень важный шаг, о котором стоит рассказать — линковка ядра.
Эта практика происходит из времен первых UNIX, когда архитектур было много а стандартов мало. Совместимость оборудования хромала, поэтому такая линковка использовалась в качестве своеобразного финального теста системы.
Из современных операционных систем, эту практику сохранила например OpenBSD, хотя и по другой причине.
Останавливаем симулятор командой exit и убеждаемся, что основное ядро UNICOS успешно слинковано — должен появиться файл unicos.ymp.10012:
После этого, проверяем файл unicos.cfg, в котором должно появиться указание на новое ядро:
Если все хорошо и ссылка на свежее ядро на месте, запускаем полноценную симуляцию:
./unicos
Так выглядит полностью запущенный симулятор суперкомпьютера Cray J90 с только что установленной UNICOS:
Если на стороне UNICOS прописать маршрут по-умолчанию, такой же командой как и в готовой сборке:
route add default 172.16.0.2
..получим выход в интернет.
Прямо с суперкомпьютера Cray, вы правильно поняли:
Мам, я вывел суперкомпьютер Cray в интернет!
Вы же не думали, будто на этом я успокоюсь, открою шампанское, вызову девок и уйду в загул? Конечно же нет и впереди ждет еще много интересного и удивительного.
Графический интерфейс, на суперкомпьютере
В найденных образах UNICOS, один из которых мы только что использовали для установки, была обнаружена работающая клиентская библиотека для протокола X11.
Самого X-сервера внутри разумеется нет, поскольку далекие предки использовали специальные управляющие терминалы с SGI Irix:
Зато есть возможность пробросить отображение приложения с поддержкой протокола X11, чтобы оно отрисовывалось на запущенном современном Xorg-сервере хоста.
Что автор немедленно и проделал:
Часики, которые тикают прямо на суперкомпьютере Cray.
Два приложения на скриншоте выше xterm и xlock — запущены из работающей UNICOS и отображаются в Xorg-сервере на Mageia Linux.
Чтобы это повторить, необходимо принести кровавую жерт.. ээ выполнить три простых шага, описанные ниже.
Запуск Xorg-сервера с поддержкой сети
По-умолчанию и очень давно, даже в самых олдскульных дистрибьютивах вроде Slackware, X-сервер запускается с параметром -nolisten, запрещающим удаленное подключение по сети.
Чтобы в этом убедиться, достаточно выполнить команду на хосте, которая покажет запущенный X-сервер со всеми параметрами:
ps -ax |grep X
Запускается X-сервер из специального приложения «display manager» (dm), который ответчает за красивое графическое окно авторизации, поэтому параметры запуска X-сервера указываются в настройках этого менеджера.
Поскольку в моей системе используется LightDM, для того чтобы X-сервер начал прослушивать сетевой порт, я добавил следующую настройку в раздел [Seat:*] в файл /etc/lightdm/lightdm.conf.d/49-mageia.conf:
После чего сервис lightdm необходимо перезапустить:
service lightdm restart
Естественно вас в этот момент выбросит из системы, так что будьте готовы и остановите заранее симулятор, если он был запущен.
Разрешение удаленного доступа без авторизации
Следующим шагом необходимо отключить авторизацию при подключении к X-серверу по сети.
Для этого авторизуйтесь с помощью DM и запустите графическое окружение — как вы обычно это делаете, затем введите в консоли:
xhost +
Выглядит это так:
После выполнения этой команды будет доступно удаленное подключение к вашему X-cерверу с любого хоста.
Что конечно считалось опасным еще лет двадцать назад, но в нынешние продвинутые времена (с Wayland вместо Xorg), когда о самой возможности такого удаленного подключения уже мало кто помнит — не стоит заморачиваться:
все, кто теоретически смог бы таким образом подключиться к вашей машине давно умерли или наслаждаются маразмом.
Кроме автора, разумеется.
Указание адреса удаленного X-сервера
Наконец последним шагом необходимо указать адрес удаленного X-сервера на стороне UNICOS. Делается это командой (не забываем о ksh по-умолчанию):
setenv DISPLAY 172.16.0.1:0.0
Набор софта с графическим интерфейсом находится в каталоге /usr/bin/X11, так для примера выглядит запуск xterm:
"This is a private computer facility" - самое возбуждающее приглашение на свете.
Если вы выполнили все шаги правильно, появится графическое окно, с запущенным приложением, работающим в среде суперкомпьютера:
И.. нет, это еще не конец.
Особенные радости, для особенных
Вместе с симулятором поставляется интересный архив goodies.tar, собранный оригинальным автором симулятора, который можно найти в каталоге unicos_tools.
Архив содержит несколько известных утилит, собранных для UNICOS, без которых жизнь юниксоида сера и уныла — bash и midnight commander.
Узрите смертные, ибо так выглядит ваш любимый mc , запущенный на суперкомпьютере Cray:
Страшно? А мы предупреждали.
Копируется сей замечательный архив с помощью уже известного по процессу установки rcp:
Телеграм, ВКонтакте, Дзен, Макс — площадок становится все больше, а вот внимание аудитории по-прежнему ограничено. Что делать? Продвигать!
На Пикабу можно рекламировать свои каналы прямо в лентах сайта. Находите новую аудиторию и получайте живые переходы без сложных рекламных кабинетов.
Подойдет для:
авторских и экспертных блогов
бизнеса
медиа и новостных каналов
мемных и развлекательных сообществ
Запускается просто: добавляете ссылку, пишете заголовок и краткое описание и выбираете географию для показов. А дальше о вашем канале узнают тысячи пользователей Пикабу!
Привет, Пикабу! Я отвечаю за ИТ и цифровую трансформацию (CDTO/CIO) на крупном промышленном предприятии. Если вы работаете в энтерпрайзе, то наверняка знаете эту боль: бизнес приходит и говорит «Хотим свой ChatGPT, чтобы он читал наши чертежи и оптимизировал производство!». А следом приходит служба информационной безопасности (ИБ) и молча кладет на стол регламенты.
В нашей реальности облачные LLM (будь то зарубежные или отечественные по API) мертвы по определению. Коммерческая тайна, строгая регуляторика, жестко изолированный контур (air-gapped сети) и гетерогенный парк на базе Astra Linux диктуют свои правила. Нам нужен локальный, полностью суверенный ИИ.
Важная оговорка: всё, о чем пойдет речь ниже — это результаты моего независимого исследования. Я собрал локальный стенд на собственном оборудовании, сфокусировавшись на типовых проблемах промышленности, но без использования служебных данных и корпоративной инфраструктуры. В этой статье я расскажу, как уйти от игрушечного «промт-инжиниринга» к распределенным мультиагентным системам, как математически обосновать закупку GPU-кластера и как заставить локальные модели работать быстро, не выжигая железо. Будет много технического мяса.
1. Иллюзия монолитных запросов и переход к мультиагентности
Если попытаться развернуть большую локальную модель (70B+) и «скормить» ей в контекст гигабайты нормативки, результат предсказуем: модель либо захлебывается (out of memory), либо начинает галлюцинировать, придумывая несуществующие пункты регламентов. Монолитные LLM хороши для генерации писем, но для сложных промышленных задач они непригодны.
Я спроектировал архитектуру на основе мультиагентных систем (MAS). Вместо одного «всезнающего» ИИ работает рой небольших специализированных моделей (14B-32B).
Как заставить их договариваться?
Чтобы агенты (например, «Агент-Технолог», «Агент-Нормоконтролер» и «Агент-Планировщик») не спорили бесконечно, их координация формализуется как децентрализованный частично наблюдаемый марковский процесс принятия решений (Dec-POMDP). Каждый агент видит только свою часть производственной задачи, но максимизирует общую функцию полезности.
Для согласования ответов экспертных агентов я применил математический аппарат нелинейной динамики Хегсельмана-Краузе (Hegselmann-Krause). В классической модели Х-К мнения агентов сходятся, если они находятся в пределах «радиуса доверия». Для LLM это выглядит так: если эмбеддинги ответов агентов находятся близко в векторном пространстве, они сливаются в единое решение (консенсус); если мнения полярны — запускается арбитражный агент, который вызывает внешние инструменты проверки.
Пример из практики: мы используем открытые веса эффективных моделей семейства Qwen (например, Qwen 2.5 на 14B-32B параметров). При проверке легальности, нормативного соответствия или подборе сложных кодов (технологических или таможенных) один Агент-Эксперт генерирует гипотезу, а другой, Агент-Нормоконтролер, жестко сверяет ее по RAG-базе локальных ГОСТов. Динамика Х-К позволяет им достичь консенсуса, исключая галлюцинации: если первый придумывает несуществующий пункт, второй не принимает этот токен (их мнения полярны), и арбитр запрашивает перегенерацию с прямой выдержкой из PDF.
Безопасность и верификация графа
В промышленности цена ошибки ИИ — это остановка линии или брак партии. Поэтому необходим жесткий контроль пайплайнов с помощью раскрашенных сетей Петри (Colored Petri Nets, CPN).
CPN позволяет статически верифицировать граф исполнения агентов до его запуска. «Фишки» (токены) в сети несут в себе типизированные данные (json-объекты с контекстом), и мы математически гарантируем, что агент не сможет передать секретный чертеж агенту, у которого нет нужного уровня допуска (аналог мандатного доступа Astra Linux), а также то, что процесс не уйдет в бесконечный цикл (deadlock).
2. Выживание на одной RTX 3090: как впихнуть невпихуемое
Давайте без иллюзий. Когда мы говорим «ИИ для энтерпрайза», многие представляют себе стойки с H100. Но в реальности тестирование гипотез, RAG-конвейеров и парсинга нормативки (для моих pet-проектов) происходило у меня дома, на одной-единственной десктопной RTX 3090 с 24 ГБ VRAM.
В 24 ГБ VRAM физически не влезает неквантованная модель на 32B, не говоря уже про контекст в 100k-200k токенов (а приказы и ГОСТы, которые я загружал в прототипы, легко съедают этот объем). Оптимизация инференса здесь — вопрос выживания, а не красивых графиков.
Я профилировал работу моделей через двухфазную модель Roofline:
Prefill-фаза (когда модель «проглатывает» промт с кучей документации): мы упираемся в вычислительную мощность (compute-bound).
Decode-фаза (когда модель отвечает): мы упираемся в пропускную способность памяти (memory bandwidth-bound).
Самой большой болью стал KV-кэш. При потоковой обработке документов в `vLLM` с окном контекста в 128k–262k токенов кэш мгновенно выедал всю оставшуюся видеопамять (OOM).
Мой стек оптимизации для RTX 3090:
Квантование: Я перешел с тяжелых весов на GGUF и AWQ (FP8). Это позволило уместить веса хорошей модели семейства Qwen в ~12-14 ГБ VRAM, оставив место под контекст.
Heavy Hitter Oracle (H2O): Для сжатия KV-кэша. В механизме внимания не все токены одинаково полезны. H2O динамически оценивает «важность» токенов в кэше и безжалостно отбрасывает (evict) лишние, оставляя только Heavy Hitters (токены, на которые опирается смысл) и небольшое окно свежих токенов.
Разделение нагрузок: В проектах я вынес генерацию векторов (эмбеддингов) и задачи OCR в ONNX-рантайм (только CPU/RAM), чтобы полностью отдать дефицитную видеопамять под `vLLM` сервер.
Именно эти суровые "домашние" ограничения научили меня делать по-настоящему эффективные локальные архитектуры, которые на заводах смогут работать не на суперкомпьютерах, а на обычных серверах с бытовыми или полупрофессиональными GPU.
3. FinOps: Как защитить бюджет на GPU-кластер
Финдиректору плевать на H2O и сети Петри. Ему нужны цифры. Инвестиции в локальные GPU — это тяжелый CapEx.
Чтобы обосновать размер кластера, я предлагаю использовать теорию массового обслуживания (СМО). Локальный API моделируется как система типа M/M/c, где:
пуассоновский входной поток заявок (λ) — это запросы от ИТР (инженерно-технических работников);
экспоненциальное время обслуживания (μ) — это время инференса;
c — количество параллельно работающих GPU/инстансов моделей.
Построив график вероятности ожидания в очереди P(W>0) в зависимости от количества видеокарт, можно найти точку экстремума, где добавление новых GPU уже не дает существенного прироста утилизации (закон убывающей отдачи). Это дает точное понимание, сколько железа брать в первую очередь, не переплачивая за простаивающие мощности.
Далее это упаковывается в финансовую модель:
Считается ROI (Return on Investment) и NPV (Net Present Value) проекта на горизонте 3 лет.
В графу доходов закладывается не мифическая «инновационность», а конкретные FTE (Full-Time Equivalent): сколько человеко-часов высокооплачиваемых инженеров высвобождается от рутинного поиска по документации и формирования отчетов.
Учитывается стоимость рисков: штрафы за утечку коммерческой тайны (если бы мы пошли в публичное облако) и экономия на штрафах от надзорных органов благодаря снижению ошибок в проектной документации.
При грамотном расчете NPV выходит положительным, и проект окупается.
4. Практика: что ИИ реально может делать на заводе?
На базе моих тестов и прототипов можно выделить следующие сценарии применения в air-gapped контуре:
Парсинг и аудит техзаданий по ГОСТ 34 и ГОСТ 19
Инженеры загружают в систему сырые требования заказчика. Агенты автоматически разбивают их на атомарные пункты, проверяют на противоречия (через динамику Хегсельмана-Краузе) и генерируют драфты ТЗ, спецификаций и программ испытаний, строго форматированные по ГОСТам. То, на что уходили недели рутины, может делаться за часы.
Анализ нормативной документации (RAG-система)
Сборка локальной базы векторного поиска по внутренним СТО, регламентам и инструкциям. Технолог спрашивает: «Какой допуск по шероховатости для детали Х при обработке на станке Y согласно регламенту от 2023 года?». Модель выдает точный ответ с прямой ссылкой на абзац в PDF.
Анализ исторических логов АСУ ТП и журналов дефектов. ИИ (в связке с классическим ML) может анализировать текстовые записи операторов и телеметрию, выявляя скрытые паттерны, предшествующие поломке оборудования.
Оперативное планирование
Планировщик в цехе общается с ИИ-агентом на естественном языке, чтобы перестроить маршрутные карты при внезапной поломке станка. ИИ опрашивает ERP-систему (через API по строгому графу CPN), анализирует свободные мощности и предлагает варианты перестроения плана.
Заключение
Проектирование локального ИИ для сурового энтерпрайза — это не про то, как написать красивый промт. Это про математику, инженерию (сжатие кэшей, расчет СМО), информационную безопасность на уровне мандатного доступа и архитектуру агентов, которые не имеют права на галлюцинации.
Облака — это здорово и удобно. Но когда речь заходит о ядре промышленности, суверенитет и безопасность данных не имеют цены. И, как показывают мои исследования, архитектура локальных ИИ-кластеров сегодня уже способна решать тяжелые производственные задачи, математически обосновывая свою окупаемость.
А как вы решаете проблему ИИ в закрытых контурах? Пытаетесь пробить файрвол к облакам или собираете свои локальные кластеры? Делитесь в комментариях!
я сидел на Винде, выжимал все соки, и ставил 2 винды и Линукс как на попробовать, потом решил удалить 2 Винду и оставить только Винду и Линукс (я знаю что Линукс это ядро а дистрибутивы это система и бла бла бла) а удалить 2-рую Винду решил через винпе с дискпарт, в итоге удалил разметку диска... 3 дня восстанавливал, и восстановил только диск C и так с поломаной fs (файловой системой), решил установить систему которая была, а на флешке с Ventoy был только тот Линукс на потестить, в итоге поставил, был как пример 2+2=5, тупо и не понятно, всё спрашивал у ии, потом начал осваиваться, пользоваться терминалом чаще, изучал TTY и русский язык в нём, долго настраивал систему, потом залез в винпе и снова случайно переразметил диск... (да, я не учусь на ошибках) решил снова накатать Линукс, сделал всё почти так же, сделал даже свой сайт, и полез в загрузчик (grub) в итоге загрузки системы не было, а было только grub recap, и строка, я загрузился через команды в грабе и сделал sudo update-grub, всё заработало, потом установил граб на хдд, старый но рабочий, сам начал прописывать всё через пункты menuentry, не без помощи ии но я только обучался, и после 3 системы через пункты и загрузки ИСО (через loopback) я начал подозревать себя в дистрохопинге, я угадал, 13 систем это не "просто покатать" а потом и 17, начал изучать и устанавливать систему через ручную настройку и filesystem.squashfs (в исо файле) распоковывал на диск и делал базовые настройки, загружался и настраивал уже не через chroot, всё давалось тяжело, но я быстро запоминал команды и начал пользоваться TTY даже для выключения ноута (poweroff), даже взломал брата через локальную сеть и авто загрузки скрипта, сделал "хоррор" сообщения основные на песне по кинито пет, управлял его ноутом, а сейчас настроил и собрал другой слабый ПК который теперь выдаёт 80-100 фпс в 1.21.8, я мало играю в игры, больше пытаюсь найти новые ИСО образы и прописать их в граб (grub.cfg), а вот главная часть, мне было 11 когда слетела винда, а сейчас 12, да, я прошёл это за год, и много деталей умолчено так как я их не особо помню
если попросите могу скинуть сюда конфиг из grub.cfg
ладно скину сразу: insmod ext2
insmod ntfs
insmod fat
insmod part_gpt
insmod part_msdos
insmod loopback
insmod chain
insmod search_fs_uuid
insmod chainloader
menuentry "MX-23.3 ISO Custom Persistence" {
set isofile="/MX-23.3_x64.iso"
search --no-floppy --fs-uuid --set=root 2A82-F516
loopback loop ($root)$isofile
linux (loop)/antiX/vmlinuz fromiso=$isofile buuid=2A82-F516 boot=live persist_all home=2A82-F516 quiet splash
initrd (loop)/antiX/initrd.gz
}
menuentry "Tiny Core Pure 64 (Graphics-RAM)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/TinyPure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3 tce=UUID=2A82-F516 waitusb=12
initrd (loop)/boot/corepure64.gz
}
menuentry "Core Pure 64 (Console-RAM)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/CorePure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3
initrd (loop)/boot/corepure64.gz
}
menuentry "Tiny Core Pure 64 (ext4-Graphics)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/TinyPure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3 tce=UUID=48a15c2f-33d7-4573-9147-c0c7cb03d22d waitusb=12
initrd (loop)/boot/corepure64.gz
}
menuentry "l24amd64" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/l24amd64.iso"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile rootwait quiet splash
initrd (loop)/casper/initrd
}
menuentry "l18amd64" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/l18amd64.iso"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile toram rootwait
initrd (loop)/casper/initrd
}
menuentry "debian (LXDE)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/d-live-13-64l.iso"
loopback loop ($root)$isofile
linux (loop)/live/vmlinuz-6.12.73+deb13-amd64 boot=live findiso=$isofile toram rootwait
Каждый раз, когда нужно перекинуть файл, код или ссылку с ПК на телефон (или другу в той же Wi-Fi сети), начинается классическая возня. Либо гоняешь через «Избранное» в мессенджерах (где режется качество и файлы вечно висят в облаке), либо поднимаешь локальные веб-серверы через консоль. Мне это надоело, и я решил написать свою утилиту — FlashStash.
Основная идея: софт должен запускаться в один клик, работать без интернета внутри локалки, иметь всеядный предпросмотр файлов прямо в браузере и не требовать от пользователя установки Питона или настройки окружения.
После нескольких итераций проект дорос до версии 1.6, и я хочу поделиться тем, как устроена утилита изнутри и с какими техническими проблемами пришлось столкнуться.
Что под капотом и как это работает
Бэкенд написан на Python + Flask, а фронтенд работает на чистом JS. Процесс использования максимально упрощен:
Запускается один исполняемый файл FlashStash.exe.
Программа сама определяет локальный IP-адрес компьютера, поднимает сервер и автоматически открывает веб-интерфейс в браузере хоста.
Чтобы подключить смартфон или другой ПК к общему пространству, нужно просто ввести в адресную строку браузера IP-адрес, который отображается в консоли сервера.
При этом для каждого загруженного файла в интерфейсе генерируется отдельный QR-код — это позволяет мгновенно скачивать конкретные файлы на телефон через камеру, не вбивая ссылки вручную.
Проект собран как Zero-Dependency Portable Build. Внутри архива лежит скомпилированный .exe файл со своей иконкой и встроенное портативное ядро Python. То есть утилиту можно закинуть на абсолютно «голую» Windows (желательно прямо на Рабочий стол), кликнуть, и всё сразу заведётся.
Как развивался проект: от костылей к нормальной архитектуре
В процессе разработки вылезло несколько неочевидных проблем, которые пришлось оперативно закрывать.
1. Борьба с «одноразовой» безопасностью
Изначально я добавил функцию защиты файлов паролями при загрузке. Но в первых версиях все пароли хранились в обычном Python-словаре в оперативной памяти. Стоило перезапустить сервер, как словарь очищался, файлы оставались в папке, но скачать их мог любой желающий без всякого пароля.
В версии 1.6 я переписал эту логику. Теперь все хэндлы, пароли файлов и история текстового буфера обмена намертво пишутся в локальные JSON-файлы. Данные идеально выдерживают перезапуск сервера и не нагружают систему лишними тяжелыми СУБД.
2. Закрытие уязвимости Path Traversal
Когда пишешь локальный веб-сервер для обмена файлами, легко забыть про базовую безопасность путей. В первых билдах бэкенд принимал имя файла из адресной строки практически «как есть».
Продвинутый пользователь в локальной сети мог провернуть атаку Path Traversal, отправив запрос вида ../, выйти за пределы папки обмена и стянуть системные файлы с хост-машины. Чтобы это исправить, я внедрил жесткую фильтрацию и санитаризацию входных путей через os.path.basename. Теперь бэкенд отсекает любые попытки побега из папки shared_files.
3. Всеядный предпросмотр (All-in-One)
Мне не хотелось, чтобы пользователь скачивал файл только ради того, чтобы узнать, что внутри. Поэтому фронтенд получил встроенные плееры для аудио и видео, просмотрщик картинок и текстовых документов. Из интересного — добавил просмотрщик архивов: структура файлов внутри .zip и .rar отображается прямо на веб-странице до скачивания самого архива.
Наведение порядка: Wipe_All_Data
Поскольку Питон при работе создаёт скрытый кэш (__pycache__), а папка shared_files постепенно забивается реальными файлами, перед заливкой проекта на GitHub или передачей папки другу её нужно как-то чистить. Сам запущенный Питон свои процессы и кэш удалить не может (Windows выдаёт Access Denied).
Для этого я написал отдельный служебный батник Wipe_All_Data.bat на английском (чтобы кодовая база репозитория выглядела аккуратно). Он делает три вещи:
Жестко тушит активные процессы сервера через taskkill.
Под ноль вычищает папки с файлами, паролями и текстами.
Сканирует дерево директорий и сносит весь кэш компилятора Питона, сжимая вес папки до исходного минимума.
Итоги
Проект получился именно таким, каким я хотел его видеть в повседневной жизни — легким, быстрым и независимым. Исходный код полностью открыт, пощупать портативный билд v1.6 и оценить реализацию можно на гитхабе.
Как я собрал бесплатный домашний кинотеатр без лагов: связка Lampa + TorrServer на сервере
Всем привет! Сегодня хочу поделиться рабочим решением наболевшей проблемы: как смотреть фильмы и сериалы на Smart TV в максимальном качестве (вплоть до тяжелых 4K HDR релизов), не платя за кучу разрозненных подписок и не мучаясь с постоянными тормозами.
Мы соберем связку из двух бесплатных программ: Lampa и TorrServer, но с одним важным нюансом — сам движок TorrServer мы запустим не на слабеньком процессоре телевизора, а вынесем его на домашний сервер (или старый мини-ПК/ноут, который валяется без дела).
Ниже — простая и понятная инструкция, как это сделать и почему это спасет ваш телевизор от тормозов, а роутер — от зависаний.
---
=== В чем проблема настроить всё прямо на телевизоре? ===
Обычно в интернете советуют самый простой путь: поставить Lampa на ТВ, туда же накатить Android-версию TorrServer, запустить его и смотреть.
Я тоже сначала так сделал. Результат — смотреть невозможно. Картинка фризит, звук заикается, а пульт реагирует на нажатия секунд через 5 после того, как ткнешь кнопку.
Почему так происходит?
1. Железо телевизора слишком слабое. Бюджетные Smart TV (типа Xiaomi, Hartens, TCL и прочие) имеют очень слабые процессоры и крошечный объем оперативной памяти (обычно около 1-1.5 ГБ). TorrServer — это полноценный торрент-клиент. На раздаче 4K-фильма он начинает открывать сотни сетевых соединений и активно кушать процессорное время. Телевизор банально перегревается, частота процессора падает (троттлинг), и всё начинает жутко тормозить.
2. Wi-Fi чип захлебывается. Слабый беспроводной модуль телевизора не справляется с одновременным скачиванием торрента от десятков пиров и передачей видеопотока.
3. Android «убивает» плеер. Когда TorrServer забивает всю оперативную память телевизора буфером видео, Android видит нехватку RAM и просто аварийно закрывает видеоплеер прямо посреди просмотра.
Решение: Выгрузить TorrServer с телевизора на домашний сервер или старый компьютер. Пусть сервер делает всю грязную работу (качает торрент, собирает пакеты, держит буфер), а телевизор будет получать чистый, легкий видеопоток по локальной сети, как с обычного YouTube.
---
=== Шаг 1. Запуск TorrServer на домашнем сервере ===
Для сервера подойдет любое устройство, которое работает круглосуточно: домашний NAS, мини-ПК, старый ноутбук или одноплатник типа Raspberry Pi.
В моем случае TorrServer крутится в легковесном Debian LXC-контейнере на сервере виртуализации Proxmox VE. Ему выделено 2 ядра процессора и 2 ГБ оперативной памяти (этого хватает с огромным запасом).
Установить TorrServer на сервер с Linux (Debian/Ubuntu) можно буквально в пару команд.
*(Для постоянной работы лучше оформить запуск через systemd-сервис, чтобы служба автоматически поднималась после перезагрузки сервера).*
---
=== Шаг 2. Важнейшая настройка: Сберегаем диск (RAM-кэш) ===
ВНИМАНИЕ! Этот пункт обязателен для выполнения, иначе вы убьете накопитель вашего сервера.
========================
По умолчанию TorrServer может использовать жесткий диск или SSD для кэширования видео. Если вы посмотрите фильм в 4K объемом 60 ГБ, TorrServer запишет эти 60 ГБ на ваш SSD. При частом просмотре за пару месяцев вы легко накрутите несколько терабайт перезаписи, что быстро прикончит накопитель.
Нам нужно настроить TorrServer так, чтобы он кэшировал данные только в оперативную память (RAM). Оперативка рассчитана на бесконечное количество циклов перезаписи и работает в сотни раз быстрее любого диска.
Открываем браузер на компьютере и переходим в настройки TorrServer: http://<IP-вашего-сервера>:8090 (в моем случае это http://192.168.188.65:8090).
Переходим в раздел настроек и выставляем следующие параметры:
- Тип кэша: Выбираем Memory (Оперативная память). Никаких дисков!
- Размер кэша: Ставим 512 МБ (536870912 байт). Этого буфера идеально хватает, чтобы сглаживать любые просадки скорости интернета во время воспроизведения.
- Буфер предзагрузки: Ставим 30%. Плеер начнет играть кино только тогда, когда скачает первые 150 МБ фильма в оперативку. Это гарантирует отсутствие заиканий на старте.
- Лимит соединений: Ставим 200. Больше не нужно, иначе слабый домашний роутер начнет перегружаться от обилия торрент-сессий и вешать интернет остальным домочадцам.
Нажимаем «Сохранить». Всё, сервер готов к работе и находится в полной безопасности.
---
=== Шаг 3. Установка и настройка Lampa на Android TV ===
Теперь переходим к телевизору.
1. Устанавливаем официальное приложение Lampa на телевизор (его можно найти в RuStore, Android TV Market или скачать APK-файл напрямую с GitHub).
2. Запускаем Lampa, заходим в Настройки (значок шестеренки) -> TorrServer.
3. Меняем Тип подключения на Основное.
4. В строке Адрес TorrServer вписываем сетевой адрес нашего сервера: http://<IP-сервера>:8090 (например, http://192.168.188.65:8090).
5. Нажимаем кнопку Проверить. Если всё сделано верно, статус сменится на зеленый «Подключено», и покажется версия сервера.
---
=== Шаг 4. Настраиваем поиск фильмов (Парсер) ===
Lampa сама по себе — это просто красивая афиша с описанием фильмов и актерским составом. Чтобы внутри карточки фильма появились кнопки для просмотра торрентов, нужно включить парсер (поисковик по торрент-трекерам).
1. В Lampa заходим в Настройки -> Парсер.
2. Включаем пункт Использовать парсер (ставим галочку «Да»).
3. В поле Адрес парсера вписываем проверенное рабочее зеркало Jackett-поисковика: jac.red (это бесплатный публичный враппер, который ищет раздачи по всем популярным трекерам).
4. Убеждаемся, что включен поиск торрентов по всем доступным категориям.
---
=== Проверяем результат ===
Возвращаемся на главный экран Lampa, выбираем любой фильм, который хотели посмотреть. Заходим в его карточку. Снизу под описанием, рядом с кнопками трейлеров, у нас появится новая вкладка «Торренты».
Кликаем на нее — Lampa мгновенно выдает список доступных раздач с указанием качества (1080p, 4K, HDR, Dolby Vision), размера файла и количества раздающих (сидов).
Выбираем нужную раздачу (например, 4K HDR на 45 ГБ), нажимаем ОК. Проходит 3–5 секунд (сервер забивает буфер в оперативную память), и начинается фильм. Перемотка вперед-назад работает плавно и без зависаний. Телевизор при этом абсолютно холодный, интерфейс летает, а качество картинки — максимальное, без какого-либо пересжатия.
Для надежности мы также настроили на сервере простой watchdog-скрипт. Если служба TorrServer по какой-то причине зависнет из-за битого торрент-файла, сервер сам автоматически перезапустит ее в течение 2 минут. Всё работает полностью автономно по принципу «один раз настроил и забыл».
Делитесь в комментариях, как вы организовали домашний просмотр фильмов и какие плееры/сервисы используете! Если возникнут трудности с настройкой — пишите, постараюсь помочь в комментариях.
Пишите на какие темы еще бы хотели увидеть статьи - с радостью с вами поделюсь и отвечу на ваши комменты !
