Администрирование

Не так давно я поймал себя на мысли, что работа в Altium Designer перестала "доставлять".

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

Итак! подоплека простая. Мне лень склеивать локальные библиотеки! На этот факт повлияла работа в АО Лазерные системы с уважаемыми людьми, которые внедрили Союз PLM от КБ 2.0 (если все верно помню) и за год плодотворной отладки системы... я убедил себя в том, что работать нужно не 12 часов, а головой!

Внезапное, однако, озарение. И так уж сложилось, что моя супруга пожелала съехать из квартиры в Санкт-Петербурге в другую. В квартиру в Москве! И вот мы уже в Златоглавой и белокаменной, кайфуем и переезжаем с района в район чтобы прочувствовать WIBES и подобрать себе по душе местечко. Работу нашел как раз для души в RQC в хорошей компании, занимающейся лидарами как и ЛС (Laser systems).

У большинства команд CI/CD уже есть пайплайны, мониторинг и «безостановочные» релизы, но как только приближается крупное событие, чёрная пятница или просто длинные праздники, внезапно выясняется, что надёжного способа одновременно «заморозить» деплой десятков сервисов нет. GitLab умеет freeze-периоды на уровне проекта, но в мире микросервисов и сотен репозиториев это быстро превращается в ручной квест и источник случайных выкатов в прод.

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

Вам нужно было хоть раз запускать x64 программы под Linux на ARM платфоме? Если да - это статья для вас. В ней я рассказываю про способы запуска программ с другой архитектуры на ARM.

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

Привет, Хабр!

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

Недавно писал о настройке USB‑модема Olax для подключения интернета — но у этого модема есть и другая полезная функция: получение и отправка СМС.

Несмотря ни на что, до сих пор эта функция бывает востребована — от получения всяких кодов до информации о «выгодных предложениях» операторов.

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

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

Много лет пользовался проектом https://github.com/antirek/alarmo для отправки сообщений с идентификацией по номеру телефона в viber и telegram. Но современные реалии диктуют новые условия и пришлось потратить время чтобы сделать аналогичное решение для нового мессенджера MAX. В текущем моменте регистрация ботов доступна только для корпоративного сегмента, но я думаю это не проблема.
Готового решения я не нашел, поэтому сделал на коленке свое, буду надеяться что кому-нибудь поможет и пригодится. Как поставить Docker и Docker-compose я думаю каждый найдет в интернете, а вот с новинкой в виде MAX пока информации маловато.

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

Привет, я Павел Мохляков. Вообще я Data Science-инженер в Cloud.ru, но сегодня решил, почему бы не рассказать как с помощью LLM-шлюза можно использовать несколько LLM через один API и при этом снизить риск утечки данных, контролировать расходы и соблюдать требования №152-ФЗ. Кроме того, покажу пример тестового подключения и объясню, что делать на каждом этапе.

Сразу оговорюсь, что статья будет полезна, скорее всего, инженерам, архитекторам, да и просто человекам-оркестрам из средних и малых компаний, которым нужно относительно быстро и безопасно внедрить у себя LLM. А вот для крупного бизнеса или, например, КИИ явно нужно что-то другое — посерьезнее и понадежнее.

В данной статье я покажу, как на Windows развернуть кластер Kubernetes из одного узла с поддержкой GPU и time-slicing, используя WSL.

В итоге получится удобная домашняя Kubernetes-лаборатория.

Эффективная пагинация — не просто удобство, а необходимость. Анализ нагрузочного тестирования, метрик системы и планов выполнения показывает, что выбор неправильного метода может замедлить приложение в 15 раз, создавая катастрофическую нагрузку на СУБД. Одни методы работают с молниеносной скоростью, а другие превращаются в «убийц производительности».

Всем привет! Часто требуется поднять свой проект на VPS/VDS. Именно это я и покажу в статье.

Мы настроем сервер, NGINX, выпишем SSL-сертификат и развернём код тестового приложения.

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

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

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

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

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

Логическая часть меня колебалась, но любопытный ребенок внутри хотел попробовать в любом случае. В конце концов, разве не лучший способ учиться — это совершать ошибки? Итак, вот как я развернул email-сервер с Mailcow, со своей долей проб и ошибок.

Когда мобильная связь подводит, особенно важно оставаться на связи с близкими. Почему бы тогда не организовать собственную телефонную сеть на основе VoIP? Меня зовут Дима Абакумов, и под катом расскажу, как я решал эту задачу и с какими трудностями столкнулся

Доступ к интернету в наши дни напоминает игру в «Сапёра»: никогда не знаешь, где рванёт и какой репозиторий отвалится завтра. Утром ты сеньор-помидор, а к обеду не можешь стянуть дистрибутив, потому что чей-то IP попал под горячую руку регулятора.

Если вы давно живёте в терминале, скорее всего всё это знаете - этот текст для тех, кто ещё не использовал SSH как SOCKS5-прокси.

Конечно, можно развернуть VLESS с XTLS-Reality, обернуть это в CDN и присыпать сверху магией, но иногда нужно решение в стиле «тяп-ляп и в продакшен».

Встречайте: SOCKS5 поверх SSH. Дешево, сердито и работает (если ваш провайдер еще не научился вскрывать SSH-пакеты зубами).

Имея VPS за пару долларов, вы можете вернуть себе доступ к документации (и, чего уж греха таить, к котикам в Instagram) буквально одной командой.

Привет, Хабр! Хочу поделиться опытом разработки такой системы. Определяющими параметрами проблемно‑ориентированной системы являются.

Без объяснения заголовок этой статьи может показаться настоящей задачкой на сообразительность, а проверить результат можно (например) при помощи встроенного в Windows инструмента subst.

Вот как создать диск +:\ в качестве псевдонима для каталога, находящегося по адресу C:\foo:

Ремейк приложения SqStat, читаем access логи по UDP. Пока анализируем не более часа, а нужно ли больше? В наше время есть GrayLog, ELK c AI-агентами. Нужен ли нам звёздный крейсер? Статья про Squid в Docker, SSL bump, анализ access-логов, Bun, Elysia, Redis, Vue. Всего по чуть-чуть.

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

И если всё это звучит как безумная смесь олдскула, низкоуровневой магии и настоящего инженерного кайфа? Вы правы! В статье я подробно рассказываю, как от студенческого мини приложения дошёл до своего кодека и p2p-звонилки, почему отказался от готовых решений, что пришлось invent-ить с нуля и какие открытия ждали на каждом шаге. Если хочется увидеть, как «а вдруг?» превращается в работающий проект, милости прошу внутрь.

История удаленного управления серверами — это история борьбы с расстоянием. С момента появления первых дорогостоящих мейнфреймов, работавших, дай бог, на перфокартах, инженеров стал волновать вопрос — как контролировать критически важное оборудование, не находясь рядом с ним 24/7? Ответом стала череда технологических решений: от примитивных терминалов на выделенных линиях до сложных сетевых архитектур и, наконец, интеллектуальных встроенных контроллеров. В этой статье рассмотрим ключевые этапы этого пути — от проприетарных систем 1970-х (IBM SNA) через трансформацию 1990-х к рождению универсального стандарта IPMI. Мы постараемся как можно интереснее рассказать об ИТ-ландшафте, заложившем основу для современных инструментов управления серверами. Где-то пройдемся по верхам, где-то остановимся чуть подробнее.

Если вы используете NCALayer в многопользовательской инфраструктуре — не полагайтесь на его поведение по умолчанию. Без правильной настройки он станет источником сбоев в критически важных системах.