Kurgan-Telecom Ru | Информационные технологии

Как говорится, если не можешь найти необходимую приблуду, возьми напильник, изоленту, молоток и выпили себе что хочешь. А в наш просвещенный век самосмывающихся втулок и дофига умных нейронок вообще как два бита об асфальт. Увидела я сколько придется править руками при конвертации следующей книги, спасаемой в рамках проекта «Спасение книг», так лень и победила трудолюбие. Поэтому написали мы значит с ИИшкой конвертер вордовских файлов в fb2-формат. Ну как написали, писал ChatGPT, а я капризничала составляла ТЗ и вносила правки. Долго-долго мы фиксили баги, а потом еще дошлифовывали некоторые фичи, и вот наконец я зарелизила супер-пупер-конвертер:

Скачать с Телеграм || Скачать с GitHub

Там в README.txt есть инструкция, но если, прочитав ее, вы ничего не поняли, то вот вам гайд для дебилов:

0. Если третий питон не установлен, то установите, pip — тоже. Гугл в помощь.

1. Еще надо заинсталлить библиотеку lxml (если у вас ее нет): python -m pip install lxml

2. Вордовский файлик следует подготовить правильно: все главы и подглавы сделать соответствующими заголовками, а не просто жирным шрифтом. Сноски замутить квадратными скобками: «термин[12]» и в глоссарии тоже: «[12] Определение термина». Изображения должны быть в файле (если они есть), но не обложка.

3. Потом берете книгу, именуете ее book.docx и кладете в папку скрипта (KONVERT).

4. Обложку, нареченную cover.jpg, фигачите туда же.

5. В metadata.txt пишете метаданные: название книги, автор в формате «Имя Фамилия», жанр, язык, год издания, аннотация и т.д. Если в аннотации нужны абзацы то добавляете их специальным символом: || но в файлике сам текст аннотации должен быть написан в одну строку.

Продолжаем серию о type-driven development в Rust — подходе, при котором правила предметной области выражаются в типах, а код, нарушающий эти правила, не компилируется. Рассказывает Никита Тимофеенко, разработчик команды MXDR компании F6.

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

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

Yahoo! — древний, даже среди других динозавров, ящер, прямиком из палеозоя. Когда-то он, можно сказать, и был интернетом, но время беспощадно, и сейчас от былого гиганта осталась лишь блёклая тень. Посмотрим, где же он напортачил, и выпишем себе на поля пару показательных ошибок. Авось, есть чему поучиться.

Привет!

В стандартной библиотеке лежит макрос pin!. Стабильный с версии 1.68, живёт в core, зовёт его каждый, кто хоть раз закреплял футуру на стеке. Значащая для нашего разговора строчка внутри у него одна, и повторить её у себя не выйдет: конструкции, на которой она держится, в языке официально нет.

Случай не единственный, второй лежит вообще на виду. Откройте объявление Vec и посмотрите внимательно: там не Vec<T>, а Vec<T, A = Global>, два параметра. Попробуйте назвать второй своими руками, и на пять строк кода прилетят три ошибки, потому что Global нестабилен.

Прикол в том, что на фичах, которых в стабильном Rust как бы нет, держится куча всего, чем мы пользуемся каждый день. В первой части так вышло с gen-блоками, pattern types, специализацией, become и #[loop_match]. Сегодня разберёмся, зачем pin! выписал себе особый пропуск. Почему второй параметр Vec сидит под замком дольше всех остальных. Как компилятор посчитает вашу корзину до копейки ещё до запуска программы. Что лежит внутри толстого указателя, если раскрутить его на запчасти. И почему SIMD руками обгоняет автовекторизацию только до того момента, пока вы не разрешите компилятору лишнего.

Детектор нашёл телефон. Шлюз его скрыл. Агент вызвал CRM и не нашёл клиента. Проверка пройдена, задача провалена. Как так получается и почему тысячи размеченных примеров могут не показать эту поломку? Разбираем на открытых корпусах и собственных прогонах.

Окна открываются по расписанию, ночная подсветка загорается на 10% яркости, а настенные клавиши работают даже при выключенном контроллере. В квартире площадью около 175 м² интегратор объединил проводную автоматику и беспроводные устройства, а владельцу оставил возможность самому менять сценарии. Заглянем в щит, разберем световой потолок на 800 Вт и посмотрим, какие задачи решает автоматика после переезда — и что еще предстоит настроить.

Фёдор Боков, Security Vision

В прошлых статьях мы говорили о роли актива как ключевом элементе контекстной автоматизации. Но возникает вопрос: как сделать так, чтобы система сама понимала, какие роли назначать, как часто проверять активы и с какими данными устанавливать агентов? Ответ — «Глобальные политики». Это своего рода «конституция» вашего Security Vision Asset Management: вы один раз прописываете правила, и модуль живёт по ним, избавляя вас от рутины.

Ниже разберём каждый параметр глобальных политик на примерах из реальной жизни. Вы увидите, как эти настройки делают работу с активами не просто автоматизированной, а по-настоящему удобной.

С помощью Python исследовал творчество Геннадия Шпаликова и установил, как поэт достигает "кинематографической простоты" своей поэзии.

Публикуем традиционный ежеквартальный дайджест регуляторных инициатив. В этом выпуске – новое за июль-сентябрь: ФСТЭК готовит замену приказу № 21, вводит правила для ИИ в госсистемах и методику оценки ИБ-зрелости, Минтруд утвердил профстандарт для ИБ-специалистов КИИ, а московский суд впервые признал утечкой передачу данных в ИИ-сервис.

У меня блог на 78 markdown-файлах, и руками я его не публикую уже больше недели. Статья выходит, когда наступает дата в её шапке: сборщик в тот день включает её в сайт, сервер замечает новую страницу, пишет о ней поисковику и обновляет sitemap с RSS. Ниже разбираю, как это собрано, и три места, где всё ломалось. Фреймворка тут нет, только один Python-файл примерно на 800 строк, bash-скрипт на 30 строк и cron.

Весь код упрощён, домен заменён на example.com, пути на /srv/blog и /srv/www.

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

Вышел llmhost — локальный хостинг LLM с автоматическим управлением памятью и спекулятивным декодированием. Планировщик сам выбирает форму загрузки: целиком на карту, эксперты MoE в RAM или частичный сплит, подбирает контекст от свободной VRAM и запоминает живой замер памяти после каждой загрузки, чтобы следующий план был точнее. MTP-головы цепляются автоматически с проверкой совместимости по GGUF-мете. Всё, что автоматика решает сама, переопределяется в llmhost.conf на лету.

( читать дальше... )

 c++, llama.cpp, openai, искусственный интеллект

Народный рейтинг Банки.ру публикует агрегаты по отзывам о каждом банке: сколько, о чём, с какой оценкой, как быстро отвечает банк. Я собрал эти агрегаты за 2019–2026 годы по 30 крупнейшим банкам в открытый датасет, добавил ключевую ставку и отчётность и проверил восемь гипотез о том, что отзывы говорят о деньгах банка: резервах, портфеле, марже. Часть гипотез подтвердилась, часть развалилась после поправки на объём. Ниже метод, цифры и код.

На прошлой неделе я перенес форк Apache Cloudberry на PostgreSQL 19 в виде набора расширений и рассказал, где этот порт проигрывает оригинальному форку. Впрочем как и Cloudberry на ClickBench современные колоночные движки обгоняют его на порядок. И дело тут не в реализации MPP, а в исполнителе PostgreSQL - он работает с кортежами в памяти СУБД. Каждый кортеж проходит отдельно, значение проходит через fmgr, а сегменты кластера лишь добавляют число процессоров на котором крутится тот же самый цикл по строкам таблицы.

Следующий логичный шаг для ускорения - векторизованный исполнитель в PostgreSQL. В открытом коде Apache Cloudberry его нет: от закрытого движка в репозитарии остались только следы - флаг create_vectorization_plan, который планировщик всегда передает как false, а также узел WindowHashAgg без реализации и адаптер PAX под VEC_BUILD, который не компилируется. Проектировать придется самому и, конечно, снова в виде расширения постгреса. Так появился pg_vexec - набор расширений для PostgreSQL 19.

Проект не требует модификации ядра PostgreSQL даже при использовании планировщика ORCA в одноузловой конфигурации без координатора на ванильной сборке PostgreSQL. Модуль gp_orca из порта Cloudberry теперь собирается без pg_core и прочих потрохов greenplum и патчей ядра СУБД, а vexec превращает ORCA в векторный планировщик с исполнителем в “одном флаконе”: его оптимизатор оценивает стоимости теперь и векторных узлов, а транслятор генерирует эти узлы в плане. Патчи ядра не нужны, только если не нужна функциональность и колоночное хранение данных таблиц из Cloudberry. Если же загрузить расширение Cloudberry на пропатченном ядре постгреса, то vexec может более эффективно читать и писать колоночные PAX и ao_column, без лишних конвертаций из и в строки, а Motion тогда может передавать между сегментами данные сразу в колоночном формате Arrow IPC.

И к постгресу можно подключаться как по привычному pgwire протоколу, так и по более современному Flight SQL, что могут оценить те кто будет запускать ML модели на данных из PostgreSQL. Как минимум при загрузке данных в polars скажут мне спасибо!

Cal AI, Rork и Base44 выглядят как тот самый успешный успех вайбкодинга. Школьник разгоняет приложение до десятков миллионов долларов, два фаундера с долгами получают $2.8 млн инвестиций, а соло-разработчик за полгода продает продукт Wix за $80 млн.

Звучит так, будто достаточно открыть Claude Code, нагенерить SaaS и ждать, когда понесут деньги.

Я полез смотреть, что было за кадром. А за красивой историей: опыт, прошлые провалы, деньги, маркетинг, команда. Вайбкодинг тут только часть успешного успеха.

По телеграм-каналам прокатилась очередная волна. Ученые нашли в LLM вектор боли. ИИ способен страдать. Насколько искусственен искусственный интеллект? Должны ли мы установить этические правила обращения с ИИ?

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

За последний год в новостной ленте сложился отдельный жанр коротких историй, у которых почти всегда одинаковое начало и подозрительно похожий конец. Сначала кто-нибудь рассказывает, как за выходные собрал приложение, ни разу не открыв учебник и просто объясняя нейросети словами, чего он хочет, а через пару недель в той же ленте всплывает заметка, что из этого приложения утекли данные пользователей или что сервис лег и никто толком не понимает почему, потому что этот код из живых людей никто и не читал.

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

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

Представьте кластер Kubernetes, в котором нет ни одной сетевой карты. Его узлы ничего не знают ни о TCP/IP, ни даже об Ethernet и перекликаются по радио короткими пакетами по 32 байта, как прорабы по рациям на стройке. Управляющий слой написан на языке конца восьмидесятых и вместе с сетевым протоколом занимает около 1250 строк. Чтобы запустить под, ничего не нужно скачивать: узел просто загружает модуль и вызывает в нём процедуру. А главное, всё это открывается во вкладке браузера: можно выдернуть узел из розетки, заглушить эфир, подсунуть кластеру поддельную команду и посмотреть, что из этого выйдет.

Такой кластер я собрал за последние несколько недель и назвал его Kube. Это управляющий слой Kubernetes, написанный на Обероне, языке Никлауса Вирта, и работает он на машинах Оберона, то есть на процессоре и операционной системе, которые Вирт спроектировал сам, от схемы до окон на экране. Узлы Kube тоже машины Оберона, и разговаривают они по радиосети из той же книги: Вирт написал эту сеть для своих рабочих станций ещё в конце восьмидесятых, а в новой редакции проекта её перевели на дешёвый радиомодуль.

Доброго времени суток, уважаемые посетители Habr!
Данная статья будет короткой, но полезной.

В одной из предыдущих статей, уже описывал вычисление sin(x)/cos(x) с применением разложения в ряд Фурье с фиксированной точкой. Вычисление тригонометрических функций, в моем случае занимало порядка 125-130 тактов на пару (sin+cos) на процессорном ядре Cortex M7 (STM32H750). При этом, код компилировался для архитектуры Cortex M3. Точность sin/cos просчитанного таким образом составила менее 1.5LSB. Google посчитал ее как 1.2-1.3LSB, с минимальной дисперсией. Это уже дало динамический диапазон ~183dB. Для сравнения, полный динамический диапазон человеческого уха 120dB от болевого порога до шелеста листвы. А динамически диапазон звука который человек слышит одновременно порядка 40-60dB. Несколько позже поясню для чего приведено сравнение.

В общем и целом такого динамического диапазона и скорости уже достаточно чтобы производить операцию квадратурной свертки сигнала с частотой дискретизации до 450-500KHz. Кстати, на STM32F103C8T6, это заняло бы ~1.8uS на квадратурный отсчет. Т.е. с отключенными прерываниями процессор бы успел выполнить расчет одного бина честного преобразования Фурье в реальном времени. Это эквивалентно квадратурной демодуляцию на одной произвольной поднесущей до частоты 250КГц (хотя лучше брать Fsample/4 ), что позволяет работать с полосой до 125КГц, на простом контроллере в реальном времени.

Однако, этого мало для полноценной обработки сигналов. И тут я задумался. Как можно значительно повысить скорость работы и почти не потерять в точности? Первое что сделал,- разбил преобразование на блоки, фаза которых непрерывна. Это позволило работать с блоками отсчетов, которые, затем можно суммировать скользящим окном со сложностью O(1). Это привело к эффекту квадратурной демодуляции сигнала и без повышения сложности позволяло работать с малыми временными сдвигами. Фактически пришел к поблочной корреляция. Нечто вроде временного Rack-приема.

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

Пока серверов было меньше десятка, а хостингов — от силы два, мне было несложно раз в неделю сверять информацию в таблице с DNS-серверами, хостингами и собственным бэкендом.

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