Записки IT специалиста

Сломает ли ИИ рынок труда? IT-инженеров не будет? Уже длительное время коллеги по цеху задаются интересным вопросом: «Заменит ли ИИ программистов?». Эта тема хайповая, вопросы по ней провокационные, а ответы на них поляризованы. Я же постараюсь найти истину в не самом тривиальном исполнении и с опорой на хоть какие-то исследования... IT, бизнес, экономика и политика... https://t.me/+K9YHFEuzZRI0OTIy?erid=2W5zFGQ26Uy Реклама. Дегтярев Г.М. ИНН 643910922420.

PHP2Shell   Второй день все сообщество гудит как растревоженный улей по поводу уязвимости PHP2Shell. Кто-то в панике обновляется, кто-то патчится, кто-то прикручивает костыли и судорожно прикидывает как жить дальше.   Под именем PHP2Shell скрываются две связанные уязвимости - CVE-2026-109618 и CVE-2026-109619, затрагивающие непосредственно сам интерпретатор PHP. Эксплуатация этих брешей позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом выполнить произвольный код (RCE) в контексте любого уязвимого PHP-приложения.   Не важно, насколько хорошо написан код вашего приложения, если оно работает на уязвимой версии интерпретатора, то под угрозой даже элементарный «Hello World».     Основная проблема в том, что уязвимыми оказались все версии начиная с PHP 5.4 и этот скриптовый язык используется примерно на 70% сайтов в интернете, т.е. касается буквально каждого.   Хотя, если посмотреть на ситуацию со стороны, то в наш век развитого ИИ ничего удивительного в этом нет, подобные уязвимости находят практически каждый день везде, начиная от ядра Linux и заканчивая какими-нибудь библиотеками.   Но в данном случае попадание пришлось в крайне уязвимое место и теперь главное трезво оценить ситуацию и сделать правильные выводы.   А именно проанализировать реакцию на это событие. Разработчики PHP оперативно выпустили патчи для версии 8.2 – 8.5, для версий 7.4 – 8.1 патч доступен только в виде исходного кода.   Фактически разработчики оставили поддержку только актуальных версий, которые будут поддерживать и собирать. Для не сильно устаревших патч в сорцах, собирайте сами. Ну а старые версии полностью списаны в расход.   В Ubuntu сами пропатчили все пакеты до 5.х включительно и обновления получат все дистрибутивы на официальной поддержке, включая 20.04 LTS и 26.10. Пользователи 14.04 LTS, 16.04 LTS и 18.04 LTS получат патчи при наличии подписки Ubuntu Pro (ESM).   В Debian патчи получат пользователи Debian 12 и Debian 13. Для Debian 11, чей пятилетний цикл завершился в августе 2026 года, обновлений нет, закрытие бреши ложится исключительно на плечи команды Extended LTS (ELTS) от Freexian, если на пакет PHP найдутся спонсоры.   В экосистеме RHEL-совместимых дистрибутивов (AlmaLinux и Rocky Linux) ситуация решается через AppStream-модули и оперативную пересборку апстрим-исправлений. Пропатчены стримы в релизах EL8, а также ветки PHP в EL9 и EL10. Для EL7 обновлений нет и не будет.   Что касается популярных репозиториев отдельных энтузиастов, то тут все зависит от них самих, так Ондрей Сури (Debian/Ubuntu) пакеты оперативно пропатчил, а вот Реми Колле (RHEL) уехал в отпуск как раз перед обнаружением уязвимости и все, кто использовал его репозитории в продакшене будут под ударом пока автор не вернется с отдыха.   А так как таких ситуаций с каждым днем будет все больше и больше, то ставить в продуктовые среды продукты одиночек-энтузиастов становится неоправданным риском и, по сути, ставит крест на небольших проектах, авторы которых просто перестанут успевать патчить свои сборки.   Также надо гораздо более тщательно подходить к выбору ОС, хороший пример – это Debian и Ubuntu, хотя и там, и там, казалось бы, по «5 лет» поддержки.

⚡ Переходите на Dr.Web с других антивирусных решений со скидкой 50% ! Обеспечьте безопасность ваших персональных данных, банковских операций, онлайн-покупок и платежей. Подробнее #реклама О рекламодателе

Принцип Питера   Принцип Питера сформулирован в 1969 году канадским педагогом и психологом Лоуренсом Дж. Питером, у нас он известен как часть Законов Мерфи.   Принцип Питера гласит:  

В иерархии каждый сотрудник имеет тенденцию подниматься до своего уровня некомпетентности.

  Следствия принципа Питера:  

🔸С течением времени каждая должность будет занята сотрудником, который некомпетентен в выполнении своих обязанностей.   🔸Работа выполняется теми работниками, которые ещё не достигли своего уровня некомпетентности.

  Многие считают это всего лишь шуткой, но на самом деле подобные тенденции имеют место быть и гораздо шире, нежели этого бы хотелось.   Причина в современной корпоративной культуре, не важно – нашей или западной – вся она завязана на некоторую «эффективность» сотрудника, которая является одним из проявлений «успешного успеха».   «Эффективный» сотрудник просто не может сказать – я не готов к повышению, я что-то не знаю и не умею, мне нужно подучиться. Потому что в этом случае он остановился, когда другие продолжают бежать вперед, он теперь просто неудачник.   При этом реальной компетентности на новой должности уже не хватает. Но если можно заменить работу красивыми отчетами и плавно делегировать ее вниз – то проблемы нет.   А показав «успехи» и на этой должности можно и дальше пробиваться вверх по карьерной лестнице, до тех пор, пока выше вы не сможете вообще ничего, даже писать красивые отчеты.   В этой точке сотрудник поднялся до своего уровня некомпетентности и занял соответствующую ей должность.   Тут может быть смешно, но часто именно так оно и происходит. Потому что руководителю не обязательно знать современные технологии, языки программирования и вообще разбираться в предмете. Ведь у него есть опыт, он лоялен фирме и т.д. и т.п.   В результате должность занимает абсолютно некомпетентный человек, который хорошо, если просто не мешает остальным работать, а не тормозит развитие на своем уровне представления о прекрасном.   И хорошо, если на этом все заканчивается, практика показывает, что нет, особенно явно это проявляется в госах. Осознавая собственный уровень некомпетентности, такой руководитель никогда не будет повышать компетентных сотрудников.   Почему? Потому что они будут представлять непосредственную угрозу его должности, потому что их потолок некомпетентности выше и могут еще расти, а он уже нет. А место теплое и хлебное, рынок труда для него – это какой-то восточный базар в арабской стране: прикольно, интересно, но абсолютно ничего не понятно, что они там лопочут.   И на нижестоящие должности также ставятся некомпетентные сотрудники, зато лояльные и безопасные, обладающие ценными навыками рисовать красивые отчеты и не менее красиво наводить тень на плетень.   Вы думаете им нужны толковые заместители? Вовсе нет. Ну вы поняли. Система самоцементируется сверху вниз, заполняя все уровни некомпетентными сотрудниками.   Погодите, а кто же будет работать? Если это гос, то возможно даже никто, гос не обанкротится, его финансирует бюджет, а все остальное они нарисуют. И такое, к сожалению, имеет место быть, когда элементарные вопросы решаются с огромным скрипом и очень долго.   Если же работать все-таки надо, то работают линейные сотрудники, тоже невысокой компетенции, чтобы даже не думали прыгать выше головы, потому что прыгать в такой системе некуда. Получаем типичную «потогонку» или «галеру» и пока такой бизнес приносит средства для кормления всей этой руководящей пирамиды – никто ничего менять не будет.   А сегодня для принципа Питера открылось второе дыхание – нейросети, которые помогают поддерживать и даже повышать свой уровень некомпетентности, причем на всех уровнях. Что с этим делать? Ничего, принимать как данное, ибо нейросеть просто инструмент, а поведение человека складывалось веками. Но умение распознавать подобные организации и стараться обходить их стороной – навык полезный.

«Скинь ещё раз файл» — самая дорогая фраза в бизнесе Потому что за ней — потерянные минуты совещаний, лишние итерации и сдвинутые дедлайны. Хорошая новость: на платформе МТС Линк появились новые инструменты для создания и управления контентом. Теперь можно: ✅ хранить, редактировать и делиться всем этим в облачном Диске ✅ набрасывать идеи в Заметках ✅ визуализировать данные в Таблицах ✅ видеть, кто вносил правки в Документах Главная фишка— бесшовность. Сервисы работают прямо внутри единого приложения отдельными вкладками, так что переключаться между задачами стало намного проще Подать заявку #реклама 16+ mts-link.ru О рекламодателе

AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:

apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"

Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение. Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует. В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума. Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:

journalctl -f

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

systemctl stop rsyslog 
systemctl mask rsyslog

Затем создадим директорию

mkdir -p /etc/systemd/journald.conf.d

А в ней создадим и откроем на редактирование файл:

nano /etc/systemd/journald.conf.d/00-journal.conf

В который внесем следующее содержимое:

[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no

Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ). Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие. Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах. Сохраняем содержимое файла и перезапускаем службу:

systemctl restart systemd-journald

Проверяем, AppArmor-шум должен полностью прекратиться, а логи теперь собираются в оперативную память и не расходуют ресурсы хоста.

Безопасность контроллеров домена Контроллер домена фактически находится в центре инфраструктуры Active Directory. Если злоумышленник получает над ним контроль, под угрозой могут оказаться учётные записи, доступы и другие критичные ресурсы компании. 29 октября | 14:00 (МСК) На вебинаре разберём, как защитить контроллеры домена и какие риски важно учитывать при их настройке и эксплуатации, а также: 🔻что хранится в NTDS.dit и кто может получить к нему доступ 🔻какие риски возникают при виртуализации и размещении КД в облаке 🔻как безопасно организовать резервное копирование 🔻чем отличаются LDAP Signing, Sealing, Simple Bind и LDAPS 🔻как использовать Security Compliance Toolkit для усиления конфигурации Вебинар будет полезен тем, кто работает с Active Directory и хочет лучше понимать риски, связанные с контроллерами домена. Регистрация на вебинар, также подписывайтесь на наш ТГ канал!

🤌🏻ОСВОЙ ИИ И СТАНЬ ВОСТРЕБОВАННЫМ СПЕЦИАЛИСТОМ В ИНЖЕНЕРИИ Ребята из «Аэромобильности МАИ» открыли набор на курс «Технологии искусственного интеллекта для инженеров». Здесь ИИ — не просто теория: ты научишься применять ML, компьютерное зрение и языковые модели в реальных инженерных задачах. Только в октябре: используй промокод «IT» и получи доступ к блоку любого понравившегося курса в подарок. ⏰Успей воспользоваться предложением в октябре!

Тонкая настройка systemd-journald Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода. Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald. Прежде всего посмотрим текущие настройки, это можно сделать командой:

cat  /etc/systemd/journald.conf

По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах. Создадим для этого директорию:

mkdir -p /etc/systemd/journald.conf.d

А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет 00-journal.conf куда мы будем вносить изменившиеся опции. Начнем с места хранения логов. Для сохранения на диск используйте:

Storage=persistent

Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.

Storage=volatile

Затем проверьте опции:

Compress=yes 
Seal=yes

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

SystemMaxUse=1G
SystemKeepFree=2G

Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места. Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:

RuntimeMaxUse=64M
RuntimeKeepFree=256M

Опции

SystemMaxFileSize= 
SystemMaxFiles=100

Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ. Для хранения в оперативной памяти аналогичные опции:

RuntimeMaxFileSize= 
RuntimeMaxFiles=100

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

MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug

Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.

ForwardToSyslog=no
ForwardToKMsg=no 
ForwardToConsole=no 
ForwardToWall=yes

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

RateLimitIntervalSec=30s
RateLimitBurst=10000

Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы. В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.

Рабочих задач много, а времени на всё не хватает? Поставь задачу агенту V2 голосом или текстом — обычными словами, как объяснил бы её коллеге. Подготовить документ, разобраться в большом объёме информации, написать текст, провести анализ, собрать отчёт или презентацию, создать картинку — V2 поможет сделать это в одном месте. Внутри агента V2 — более 60 моделей нейросетей, а нужная подбирается автоматически под твою задачу. Без зарубежных карт и необходимости разбираться в разных нейросетях. V2 запоминает твои проекты и контекст, поэтому не приходится каждый раз начинать с нуля. Работает прямо в Telegram! Попробуй бесплатно — 200 кредитов при регистрации без привязки карты. Переходи по ссылке — v2bot.ai #реклама О рекламодателе

Авторское право – не пустой звук. Часть 3   В прошлой части мы разобрали, какие объекты авторского права можно использовать и на каких основаниях, но остались некоторые тонкости, которые мы сегодня рассмотрим.   Статья 1274 ГК РФ прямо говорит, что допустимо использование:

правомерно обнародованных произведений и отрывков из них в качестве иллюстраций … в объеме, оправданном поставленной целью

  А где и как искать этот объем? Начнем с цели. Какая цель вашего произведения? Именно от этого будет исходить объем. Допустим, вы описываете некоторую материнскую плату – тогда для достижения поставленной цели вы правомерно можете использовать общий вид, фото со стороны разъёмов и т.д.   Но если вы пишете общую статью, скажем об оперативной памяти и поставили на КДПВ (картинка для привлечения внимания) какую-нибудь художественную фотографию с планкой ОЗУ, где не только сама планка, но еще и сюжет, фон, модель – это однозначно нарушение.   А вообще общий принцип прост – если данный объект авторского права можно исключить из вашего произведения, и оно не пострадает – то его нужно исключить, так как его применение не оправдано поставленной целью.   Потому что когда у вас в тексте «посмотрим на скриншот и увидим» или «вот фото устройства в разобранном виде, обратите внимание», то изображения становятся неотъемлемой частью произведения, если их убрать, то станет непонятно, о чем идет речь.   С целью поняли, а что с объемами? Тут тоже следует исходить из того, то заимствованный материал не должен составлять основную часть вашего произведения. В журналистской и редакторской среде действует эмпирическое правило 30%.   Т.е. вы не должны заимствовать более 30% исходного произведения и общий процент заимствований в вашем произведении не должен превышать 30%.   Но это общее эмпирическое правило, в реальности объем всегда зависит от поставленной цели. Скажем, вы пишете статью про историю вычислительной техники. Тематика не позволяет вам самостоятельно создать иллюстрации и поэтому заимствование чужих изображений в полном объеме оправданно заявленной целью.   Следующий момент, демонстрация чужих объектов авторского права на скриншотах, например, обоев рабочего стола. Тема тоже очень скользкая, которая в итоге сводится к правомерности воспроизведения объекта в определенном окружении.   Скажем, в дистрибутиве Simply Linux от Альт есть отличные авторские обои. Показывать их на скриншотах дистрибутива полностью допустимо, правообладатель сам разрешил их использование в составе ОС, а вы показываете внешний вид ОС.   Но стоит вам выложить этот файл изображения отдельно – вы нарушили чужое право, автор не разрешал использовать это изображение отдельно от дистрибутива.   Или, скажем, вы использовали известное изображение Bliss (Безмятежность) из Windows XP как фон рабочего стола Linux и наделали там скриншотов. Поздравляем, вы только что грубо нарушили авторское право.   Статья 1273 ГК РФ разрешает свободное воспроизведение произведения в личных целях, т.е. вы имеете полное право поставить такое изображение на рабочий стол вашей Linux-системы. Но вот публично демонстрировать вы его права не имеете.   Это же касается любых изображений, защищенных авторским правом, поставить на рабочий стол можно, публично демонстрировать нельзя. Поэтому если вы снимаете скриншоты какой-либо системы, то поставьте туда стандартные обои.   Ну и не забывайте, что даже свободно распространяемые изображения имеют своего автора и лицензию, с которыми бывает полезно ознакомиться.   Потому что свободно не означает бесплатно и на такое использование могут быть наложены некоторые ограничения.

3D-графика давно вышла за пределы игр и кино. Сегодня это целое направление цифрового производства. А что, если освоить инструменты, с помощью которых создают виртуальные миры? На годовом курсе HDS ты шаг за шагом освоишь ключевые навыки 3D при поддержке персонального наставника: пройдёшь путь от базового моделирования до финальных рендеров и стилизации, попробуешь разные направления и соберёшь 6 проектов в портфолио. А если захочешь превратить интерес в профессию — получишь базу для первых шагов в игровой индустрии. 🔥 Сейчас — скидка 50% на годовое обучение + графический планшет в подарок. Переходи по ссылке и сделай первый шаг к освоению профессии 3D-художника.

Как получить полный дистрибутив конфигурации 1С:Предприятие Многие коллеги активно пользуются Порталом 1C:Обновление программ для получения обновлений. Но когда требуется скачать полный дистрибутив начинаются определенные сложности. Обычно в этом случае рекомендуют обратиться к обслуживающему франчайзи, некоторые начинают искать дистрибутивы в широко известных «злачных местах», но на самом деле все гораздо проще. Достаточно просто скопировать ссылку на дистрибутив обновления и в самом ее конце заменить:

_updsetup.zip

На

_setup1c.zip

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

ИТ-отдел есть, но его не хватает Поддержка инфраструктуры отнимает много времени, которое уходит на инциденты, заявки, серверы, базы, приложения, ночные аварии. В результате специалисты, которых нанимали развивать ИТ, большую часть ресурса тратят на поддержку того, что уже работает. У РДТЕХ.СЕРВИС другой подход: часть или всю эксплуатационную поддержку можно передать их внешней команде, у которой более 100 технологических стеков, работа 24/7/365 и единый ответственный. Так вы будете уверены, что на ваши критичные инциденты отреагируют в течение 15 минут. При этом не обязательно отдавать внешний ИТ-отдел целиком. Можно подключить только те направления, где сейчас не хватает ресурсов. 💡 Подробнее на сайте

Авторское право – не пустой звук. Часть 2   Сегодня мы посмотрим на этот вопрос с другой стороны, потому что многие авторы и блогеры один раз столкнувшись с фототроллями начинают дуть на воду и бояться каждой тени.   Поэтому начнем с базы:

Статья 1257. Автор произведения   Автором произведения науки, литературы или искусства признается гражданин, творческим трудом которого оно создано.

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

Статья 1274. Свободное использование произведения в информационных, научных, учебных или культурных целях   1. Допускается без согласия автора или иного правообладателя и без выплаты вознаграждения, но с обязательным указанием имени автора, произведение которого используется, и источника заимствования: 1) цитирование в оригинале и в переводе в научных, полемических, критических, информационных, учебных целях, в целях раскрытия творческого замысла автора правомерно обнародованных произведений в объеме, оправданном целью цитирования…

  А вот это тот самый спасательный круг, который держит на плаву весь блогинг и журналистику, авторов обучающих материалов и т.д. и т.п. Но учтите – вы обязаны указать имя автора и ссылку на источник.   Что это значит? А это значит, что вы можете использовать чужое, защищенное авторским правом изображение в информационных целях абсолютно законно, но в объеме, оправданном целью цитирования.   Если говорить просто, то вы, в процессе написания обзора на мини-ПК вполне можете взять чужое фото, чтобы показать его внутри, потому что не хотите разбирать свой гарантийный экземпляр. Это как раз оправданный объем и понятная цель.   Но когда вы построите свой материал на чужом фото и добавите от себя два дежурных абзаца, то цитированием тут уже не пахнет, чужой объект стал ключевым элементом вашей публикации, а это нарушение.   А теперь пройдемся по самым частым случаям. Скриншоты интерфейса программ. Несмотря на то, что сами программы – объект авторского права их интерфейс таковым не является (исключая шрифты, иконки и т.п.), иначе авторы того же MS Office давно бы засудили альтернативные пакеты, которые повторяют интерфейс практически один в один.   Поэтому скриншоты можно публиковать смело, никто никаких претензий вам не предъявит. Исключение – чужой обработанный скриншот, на который нанесены надписи, стрелочки, рамочки – это уже результат чужого творческого труда и использовать его вы можете только в части цитирования.   Изображения комплектующих и готовых устройств. Здесь ситуация еще тоньше. Многие юристы вполне обоснованно считают, что если у нас есть вид устройства с некоторого стандартного ракурса (спереди, сзади, сверху, вид на разъемы), то результатом творческого труда это изображение не является.   Эта позиция находит поддержку в судах, но мы не будем лишний раз дергать тигра за усы, а снова возьмем 1274 ГК РФ. Если вы пишете статью об устройстве или в тексте используете это устройство как пример, то будет абсолютно правомерно привести тут его изображение.   Чужие логотипы и прочие элементы брендирования. Самая сложная тема, так как она учитывает множество факторов, в частности коммерческое применение. Так в условиях партнерских программ многие бренды прямо запрещают использование официальной символики.   Но это касается именно коммерческой деятельности. В информационных, научных или учебных целях вы полностью в праве использовать чужие логотипы и элементы корпоративного стиля, тем более что практически все производители публикуют брендбуки и на этом настаивают.   Если вы пишете статью про Ubuntu или RHEL, то абсолютно логично проиллюстрировать ее официальным логотипом. Это нормально и не является нарушением. Но если вы разместите в этой статье некоторые партнерские ссылки, ситуация может тут же развернуться на 180 градусов.   Объем заметки не позволяет разобрать все ситуации, поэтому к этой теме мы еще вернемся.

Вытяжка наклонная F 603 B KUPPERSBERG Надежная вытяжка от KUPPERSBERG — официальный сайт производителя. Узнать больше #реклама kuppersberg.ru О рекламодателе

ZRAM и ZSWAP в Proxmox VE В прошлой заметке мы подробно разобрали как работают ZRAM и ZSWAP, в чем их основное отличие и рекомендуемые сценарии использования. Но это касалось систем общего назначения, а когда мы переходим к специализированным системам, то расклад может измениться. Поэтому мы отдельно остановимся на популярном средстве виртуализации Proxmox VE. Казалось бы, а что там думать, серверная виртуализация, ZSWAP и всех делов. Но не все так просто. ZSWAP – функция ядра и для многих расположенных выше слоев системы она работает прозрачно. Приложение думает, что оно пишет в дисковый swap, а на самом деле оно пишет в кеш, расположенный в сжатой памяти. И если с виртуалками проблем не возникает, то LXC-контейнеры начинают вести себя своеобразно. Напомним, что у контейнеров нет ни своей памяти, ни своей подкачки, они используют ресурсы хоста в пределах установленных для них лимитов. Но для LXC использование SWAP-кеша не учитывается ни в одном лимите, в результате контейнер свободно выходит за пределы установленного лимита на подкачку. На первый взгляд – ничего страшного, кеш в памяти, он быстрее любого, даже самого быстрого диска, пусть работает. А теперь вспомним, что ZSWAP – это именно кеш, он может быть очищен ядром, он может начать вытеснять холодные данные на диск. Если коротко – это не гарантированное хранилище, а динамически выделяемый ресурс. В итоге может оказаться так, что кеш придется сбросить, а места в дисковой подкачке у вас недостаточно, что вполне реально, если несколько контейнеров выйдут за лимиты. И тогда – привет OOM-Killer. Либо, если вы выставили критичным службам защиту от указанного товарища, а именно они и сожрали память, то ваш сервер просто станет колом и потребуется принудительная перезагрузка. Поэтому Proxmox не рекомендует использовать ZSWAP, а предлагает, неожиданно, ZRAM. Но как так, спросит внимательный читатель, ведь только что вы писали, что ZRAM плохо влияет на производительность, особенно для виртуализации и СУБД. Все верно, но это в том случае, если мы используем его в качестве расширителя объема ОЗУ. Но если у нас достаточно памяти, то мы можем создать ZRAM устройство исключительно на замену swap. При этом, в Proxmox это отдельно подчеркивают, использование подкачки является временной мерой для защиты от OOM-Killer и использовать ее в качестве расширения памяти категорически не рекомендуется. Т.е. здесь мы приходим к тому, что памяти у нас для виртуальных машин и контейнеров достаточно, а подкачка нужна для сглаживания пиков, но не для повседневной работы. В этом случае перенос подкачки в ZRAM вполне оправдан, а так как это отдельное блочное устройство и настоящее пространство подкачки, то лимиты LXC здесь работают, как и задумано, считая несжатые данные. Ну и совершенно понятно, что выделять в таком случае под ZRAM не следует ни 25%, ни, тем более 50% ОЗУ. Исходим из того, сколько реально подкачки нам надо и делим на коэффициент сжатия. Для LZ4 это 2,5, для ZSTD около 4. Таким образом, если у нас есть хост с 64 ГБ ОЗУ, то отрезав всего 4 ГБ при помощи ZRAM и zstd мы спокойно организовываем пространство подкачки на 16 ГБ. Причем – быстрой подкачки. При этом Proxmox настоятельно советует дисковую подкачку отключить, так как совместное использование ZRAM и дисковой подкачки может вызвать неконтролируемый рост задержек и привести к катастрофической дестабилизации системы. В данном случае ZRAM предлагается использовать не как расширение памяти при ее недостатке, а как альтернативу дисковому swap, но в более предсказуемом виде, нежели ZSWAP-кеш. Это еще раз показывает, что любая технология может приносить пользу, если ее применяют правильно, или стать источником проблем при бездумном использовании.

Ремень EKONIKA Одна сторона ремня выполнена из натурального велюра в темно-коричневом цвете,... Узнать больше #реклама ekonika.ru О рекламодателе

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

Мы рекомендуем запрос доп пин-кода присылать сразу после использования последнего пин-кода, не дожидаясь запроса лицензии от программы. В запросе указывайте наименование организации, рег.номер лицензии и все цифры активного пин-кода, взамен которого требуется доп.пин-код.

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

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

Правила несложные, но мы очень редко видели, что кто-то им следует. Зато многократно сталкивались с тем, что администратор в принципе не имел понятия какой именно рег.номер лицензии на этом компьютере, какой пин-код активирован и с какими данными пользователя. А в этом случае никакое наличие бумажек с кодами вам не поможет. Поэтому никакой сакральности в этих желтых бумажках нет. Нужно использовать код – используйте. И тут же запрашивайте новый. Задача полностью будничная, указали рег.номер – получили новый код. И никому не интересно зачем он вам и для чего. Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы. Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?