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

Когда Гегель писал, что мир без мышления - это пустая абстракция, современники крутили пальцем у виска. Физика его эпохи оперировала твёрдыми шариками-атомами и абсолютным пространством Ньютона. Казалось, мир существует "сам по себе", а сознание - лишь пассивный зритель, который может ошибаться, но на саму сцену не влияет. Сегодня, спустя два века, картина радикально изменилась. И не потому, что Гегель был мистиком и оказался прав. А потому, что физика наконец догнала философию и показала: вопрос "что такое реальность вне наблюдения" не просто сложен. Он, возможно, некорректен.

Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!

Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?

Привет, Хабр! Меня зовут Екатерина Сивакова, я тимлид аналитики в Дзене (VK), а до этого работала в других бигтехах, и везде так или иначе сталкивалась с изучением CJM и пользовательской аналитикой. Сегодня хочу рассказать, как мы в Дзене делали единый инструмент по изучению пользовательского пути, зачем это понадобилось и что из этого вышло. А ещё о том, сколько это реально стоило по времени и ресурсам, потому что ответ отличается от первоначальной оценки примерно в 60 раз.

Текст будет вам полезен, если у вас продукт с большим количеством страниц и разветвлённой навигацией, с многочисленными однотипными переходами пользователей.

Эта статья не про бенчмарки процессоров и не про священные войны «Linux против Windows». Она для собственников и руководителей бизнеса, у которых назрел практичный вопрос: продолжать покупать свои сервера «по старинке» или уже всерьез считать переезд в облако на горизонте 3–5 лет.

Меня зовут Алексей Горюнов, руковожу проектным офисом ALP ITSM. Уже почти 20 лет занимаюсь проектированием и внедрением ИТ‑инфраструктуры: от серверных «в офисе» до облачных и гибридных решений. За это время десятки раз пересчитывал для компаний, что им выгоднее на горизонте нескольких лет — покупать свое железо, строить гибрид или переезжать в облако. В этой статье собрал практические выводы из этих проектов.

В статье разберем:

– из чего на самом деле складывается стоимость своего железа;

– почему сравнение «2,3 млн за серверы против 3,66 млн за облако» в разрезе 3-5 лет дает иллюзию экономии;

– в каких сценариях покупка сервера еще оправдана, а где лучше смотреть на облако или гибрид.

В статье мы сознательно упрощаем расчеты и оперируем усредненными цифрами — задача не в том, чтобы построить финансовую модель «до копейки», а в том, чтобы показать порядок затрат и логику сравнения своего железа с облаком. При этом для практики одного текста мало, поэтому мы приложили подробный TCO‑калькулятор: в нем можно подставить свои цены на железо, аренду, ФОТ, облако и риски и получить уже точный расчет совокупной стоимости владения на горизонте 1, 3, 5 и более лет. Калькулятор найдете в конце статьи.

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

В начале ноября 2025 года децентрализованный протокол Balancer V2 (composable stable pools) подвергся атаке, суммарные потери по разным сетям превысили 128 млн долларов. Причиной стала не ошибка доступа, не реентерабельность и не баг в проверках прав, а потеря точности при расчете инварианта из-за округления. Формально проблема сводилась к округлению при масштабировании значений и выглядела как допустимый технический компромисс. Экономический эффект, однако, оказался значительным.

Взлом Balancer, как и многие другие инциденты, уже подробно разобран в формате post-mortem — с реконструкцией того, как именно была проведена атака. В этой статье подход другой: мы посмотрим на тот же код глазами аудитора, который задается вопросом «что здесь может пойти не так?».

Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.

Всем привет! Я Лина, инженер по обеспечению качества в Команде Контента и Трафика в Банки.ру.

Я хочу рассказать, как мы работали над обновлением сложного сервиса – Народными рейтингами. В этой статье представлен каждый шаг от макетов до пострелизного теста: со своими заметками, выводами и, конечно, примерами конкретных багов, которые попадались во время работы над новыми Народными рейтингами и редизайном НРСК.  

В Bitrix24 автоматизация часто превращается в отдельный проект: приложения, OAuth, лишняя инфраструктура. Хотя многие задачи — создание сделок, уведомления, реакции на события — можно закрыть намного проще. Вебхуки дают прямой доступ к API через один URL и позволяют быстро связать CRM с внешними сервисами. Разберёмся, как это работает, где реально помогает и где начинаются ограничения.

Тот, кто был на любой технической кафедре небалованного деньгами вуза, знает, что там обязательно есть подсобка, где хранится куча старых списанных приборов. Просто потому, что пригодится: где на запчасти пойдёт для ремонта существующего («Денег нет, но вы держитесь» (с)), где-то аспирант к себе утащит переделывать для научных исследований, а где-то студентам отдать на растерзание под проект. И вот во время приборки на кафедре нашёлся вот такой странный прибор. Точнее, приборы — два блока, соединяемые толстым кабелем.

Всем привет, меня зовут Николай Голубев, я — техлид из компании HFLabs. Эта статья написана по мотивам моего выступления на конференции Saint HighLoad++.

В этой статье мы поговорим о том, как при помощи Debezium было реализовано резервирование Postgres для одного из наших заказчиков. Решение успешно внедрили и уже несколько лет оно используется в продакшене.

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

Десятилетиями мы искали жизнь не там.

Астрономы всего мира молились на один показатель — ESI (Earth Similarity Index). Если планета имела размер как у Земли и находилась в «зоне Златовласки», заголовки трубали: «Открыта Вторая Земля!». NASA радовалось, пресса ликовала, гранты выделялись.

Но всё это было иллюзией.

Индекс ESI игнорирует самое главное — то, что находится внутри планеты. Он считает «похожими на Землю» миры-океаны без суши и мёртвые железные ядра без атмосферы. В результате в списках потенциально обитаемых миров оказались планеты, где жизнь физически невозможна.

Сегодня я представляю Закон Экзолоджики — новый фундаментальный принцип, который математически перечёркивает старые списки и вводит жёсткий физический фильтр для поиска жизни. На основе анализа 42 экзопланет через систему ExoLogica AI мы доказали: обитаемость зависит не от температуры, а от плотности.

И результаты шокируют. Знаменитый Kepler-452 b («кузен Земли») вылетает из списка обитаемых миров мгновенно. Ross 508 b, Teegarden's b — тоже. Но есть и хорошие новости: настоящие кандидаты наконец-то найдены.

Приготовьтесь. Эпоха наивного поиска закончилась.

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

Для решения этой проблемы я написал пакет yx_virtual_device, который позволяет симулировать экраны различных устройств прямо во время разработки, не выходя из запущенного приложения. В этой статье — о том, что умеет этот пакет, как с ним работать, а также почему было сложно подружить его с Flutter и как в итоге это удалось сделать.

Год назад METR доказали что AI замедляет разработчиков на 19%. В феврале 2026 обновили данные - похоже на разворот к ускорению. Но об этом почти не написали. Зато «AI уволит 50% разработчиков» - в каждом втором заголовке. Полез разбираться, кому выгодна AI-паника. Нашёл CEO, которые увольняют тысячи и тихо нанимают обратно. Нашёл вендоров, которые пугают увольнениями и одновременно открывают вакансии. И курсы «защити карьеру от AI» за $23 000.

Однажды утром вы открываете задачу и понимаете: единственный человек, который знал, как это работает, вчера уволился. Знания ушли вместе с ним.

30-го марта 2026 года тихо и незаметно вышел очередной релиз популярной среди пользователей linux.org.ru библиотеки. Основные изменения из changelog характеризуются как следующие:

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

 1 апреля, libastral, opensource

Сегодня (2026.04.01) прошло ровно 9731 день с тех пор, как сообщество Python узнало об изъяне в работе со строками.

Это было так давно, что у Python еще не было мажорных версий (для холиваров приходилось использовать PHP).

Так давно, что еще не существовало ни pythonchallenge.com, ни его прародителя notpron.com - легендарных убийц времени программистов.

Это было в прошлом тысячелетии. А именно - 1999 году, когда, согласно летописям, реализовали тип string. В том же году ведущий разработчик Jim Fulton опубликовал исследование, где без купюр указал на проблему.

Как ни странно, она не решена до сих пор.

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

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

В конце прошлого года лауреатами премии стали сразу три человека: Джоэль Мокир, Филипп Агион и Питер Хоуитт. Мокир получил половину премии за выявление предпосылок устойчивого роста через технологический прогресс, Агион и Хоуитт — вторую половину на двоих за теорию устойчивого роста через созидательное разрушение.

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

В предыдущей статье я попробовала описать типы привязанности как сетевые протоколы, разобраться, как большинство из нас строит отношения. Было сделано предположение, что типы привязанности — те невидимые протоколы, по которым наше сердечко подключается к другим людям. Кто-то легко доверяет и остаётся на связи даже в шторм. Кто-то постоянно проверяет: «Ты ещё здесь?». А кто-то заранее закрывает порты, чтобы не рисковать.

И после возникает логичный вопрос: Если привязанность — это протокол, то кто его настроил?

Если у вас стоит Always On Availability Groups, вы наверняка бывали в такой ситуации: в SSMS всё зелёное, дашборд показывает «Synchronized», а пользователи звонят с жалобами на тормоза. Смотришь на secondary — а там redo_queue_size 600 МБ, реплика отстаёт на полчаса. Ни одного алерта.

У нас это случилось на продуктивном кластере с 1С: secondary молча отвалился в SYNCHRONIZING, а мы узнали только при плановом переключении. Полтора часа redo queue. Стало понятно, что встроенный дашборд SSMS — это не мониторинг. Дальше — как мы это закрыли Zabbix'ом за вечер.