VitruvianOS – гибрид Haiku на ядре Linux
В конце марта этого года состоялся первый публичный релиз VitruvianOS – операционной системы на базе Debian, которая предоставляет API и компоненты пользовательского пространства для запуска приложений для Haiku и BeOS.
В системе реализованы: app_server - графический сервер и графический тулкит Interface Kit из Haiku. Вместо systemd используется система инициализации janus_daemon, аналог родного launch_daemon.
Как видим, это не просто реализация графической оболочки а-ля Haiku поверх ядра Linux, а именно отдельная подсистема, позволяющая запускать на Linux нативные приложения Haiku и BeOS.
Сразу возникает вопрос: а зачем это надо? Ведь есть оригинальная Haiku. Есть, только весь вопрос в том, сколько человек ее использует и сколько занимается разработкой. Круг их весьма узок и все, чем они занимаются происходит в тесном сообществе, изолированном от остального мира открытого ПО.
Переход на платформу Linux позволяет, во-первых, привлечь большее количество пользователей и решить ряд проблем за счет использования готовой базы, а самим сосредоточиться на сильных сторонах BeOS, которые есть желание продолжать использовать.
От этого выиграют все: и поклонники Haiku, и пользователи Linux, так как наработки обоих проектов можно будет использовать совместно. А работать в большой команде всегда лучше, чем вариться с собственном мирке.
Да, в конечном итоге это скорее всего приведет к появлению очередного окружения рабочего стола, скажем, HaikuDE, который будет работать с привычным Linux окружением. Но такой вариант кажется мне наиболее оптимальным.
Потому что сильные стороны Haiku/BeOS – это идеи и реализации, заложенные в первоначальную систему, а не конкретное воплощение в коде.
Яркий пример тому – macOS, которая спокойно сменила платформу сначала на BSD, а теперь и просто перешла на архитектуру ARM. Причем абсолютно прозрачно для пользователя. Потому что ему не интересно, что там под капотом, ему важен пользовательский опыт, как он взаимодействует с системой и что она может ему дать.
Поэтому пожелаем новому проекту удачи, потому что BeOS – это действительно самобытная и интересная система, которая наконец сможет найти своего пользователя.
В конце марта этого года состоялся первый публичный релиз VitruvianOS – операционной системы на базе Debian, которая предоставляет API и компоненты пользовательского пространства для запуска приложений для Haiku и BeOS.
В системе реализованы: app_server - графический сервер и графический тулкит Interface Kit из Haiku. Вместо systemd используется система инициализации janus_daemon, аналог родного launch_daemon.
Как видим, это не просто реализация графической оболочки а-ля Haiku поверх ядра Linux, а именно отдельная подсистема, позволяющая запускать на Linux нативные приложения Haiku и BeOS.
Сразу возникает вопрос: а зачем это надо? Ведь есть оригинальная Haiku. Есть, только весь вопрос в том, сколько человек ее использует и сколько занимается разработкой. Круг их весьма узок и все, чем они занимаются происходит в тесном сообществе, изолированном от остального мира открытого ПО.
Переход на платформу Linux позволяет, во-первых, привлечь большее количество пользователей и решить ряд проблем за счет использования готовой базы, а самим сосредоточиться на сильных сторонах BeOS, которые есть желание продолжать использовать.
От этого выиграют все: и поклонники Haiku, и пользователи Linux, так как наработки обоих проектов можно будет использовать совместно. А работать в большой команде всегда лучше, чем вариться с собственном мирке.
Да, в конечном итоге это скорее всего приведет к появлению очередного окружения рабочего стола, скажем, HaikuDE, который будет работать с привычным Linux окружением. Но такой вариант кажется мне наиболее оптимальным.
Потому что сильные стороны Haiku/BeOS – это идеи и реализации, заложенные в первоначальную систему, а не конкретное воплощение в коде.
Яркий пример тому – macOS, которая спокойно сменила платформу сначала на BSD, а теперь и просто перешла на архитектуру ARM. Причем абсолютно прозрачно для пользователя. Потому что ему не интересно, что там под капотом, ему важен пользовательский опыт, как он взаимодействует с системой и что она может ему дать.
Поэтому пожелаем новому проекту удачи, потому что BeOS – это действительно самобытная и интересная система, которая наконец сможет найти своего пользователя.
👍21❤2🤡1
Копируй, вставляй и молись
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
Не так давно в классическом труде UNIX® and Linux® System Administration Handbook в очередной раз наткнулся на описание данного метода, который авторы метко назвали «копируй, вставляй и молись».
В переводе данный абзац будет выглядеть так:
Не стесняйтесь адаптировать код существующих скриптов для своих нужд. Но не занимайтесь программированием по принципу «копируй, вставляй и молись», когда вы не понимаете код. Найдите время, чтобы разобраться в этом. Это время никогда не тратится зря.
Но, к сожалению, данный метод использовался, используется и будет продолжать использоваться со всеми вытекающими отсюда последствиями.
И это относится не только к написанию скриптов, но и к файлам конфигурации, когда администраторы копируют чужие примеры даже не задумываясь.
Спрашиваешь: «а зачем тут это?»
В ответ пожимают плечами и путано поясняют что так было написано в одной умной инструкции.
К этой же порочной методике можно отнести и бездумное копирование инструкций, а также любимый многими «вид спорта» - настройка чего-либо с помощью чужих готовых скриптов.
Последний вариант вообще вне конкуренции по возможным деструктивным последствиям, потому как в статье автор хотя бы комментирует свои действия, и вы можете понять надо ли это в вашем случае или не надо, то скрипт может просто сделать все молча и по-своему.
Неоднократно сталкивались с товарищами, которые приходят за помощью с жалобой, мол поставил продукт А, но ничего не работает. А на уточняющие вопросы поясняют, что ничего не знают и дают ссылку на скрипт.
Бездумное следование инструкциям ничуть не лучше, по сути, это выходит тот же самый скрипт, но в более простом варианте, когда команды вбивает оператор. Его роль тут сводится просто к скопировал-вставил и его спокойно можно заменить дрессированной обезьяной. 🐵
Поэтому не стоит уподобляться братьям нашим меньшим. Делаем по инструкции – стараемся понять каждое действие, назначение всех используемых опций, значений настроек и всегда сопоставляем их с нашими текущими реалиями.
Надо нам это? Не надо? А почему здесь такое число? На что оно влияет.
Да, вы потратите больше времени, но это время не будет потрачено даром. Вы начнете хотя бы на базовом уровне разбираться в конфигурации и принципе работы продукта, а также сразу наметите возможные проблемы и места, которые за эти участки отвечают.
Что касается чужих скриптов, то их использовать, конечно можно, но крайне нежелательно до тех пор, пока вы не сможете читать их с листа и понимать, что они делают и зачем. И не важно, насколько популярен этот скрипт, сколько у него звезд на гитхабе и т.д. и т.п.
Почему? Да потому что всегда может что-то пойти не так и если скрипт для вас черный ящик, то вы даже не поймете, где проблема и в чем. После чего все равно придется либо изучать его, либо идти просить помощи.
И это мы еще не говорим о том, что автор может иметь собственные представления «о прекрасном» и использовать нестандартные пути, приемы, допускать ошибки, прибиваться гвоздями к версиям и т.д. и т.п.
При определенных условиях работа скрипта может вообще оказаться деструктивной, но не со злого умысла автора, а просто потому, что он пропустил некоторые проверки или вообще не предусмотрел вашего сценария.
При этом мы понимаем, что, даже прочитав данную заметку многие пожмут плечами и пойдут работать методом «копируй, вставляй и молись» дальше. Потому что он в целом работает, а что касается дальнейшей эксплуатации: упремся – разберемся.
Но только вот профессиональному росту специалиста он никак не содействует и об этом нужно помнить если не хотите чтобы вас потом заменила дрессированная обезьяна в виде столь популярного ныне искусственного интеллекта.
👍33❤3🥱3🤮1
Zettlr – мощный визуальный Markdown редактор
Уже заканчивая работу над переносом старого сайта, мы начали подбирать инструменты для работы над новым. Нужен был удобный редактор для работы с Markdown как в визуальном режиме, так и в сыром виде.
Попробовано было не мало, но все так или иначе чем-то не подходило. Многие коллеги предлагают использовать для этого Joplin/Obsidian, да, там неплохой редактор, но это отдельные приложения для ведения заметок, а не редакторы.
Особенно учитывая наличие проекта с 16-летней историей, запихать ее всю в заметки – не самая лучшая идея, как и жить на два дома: новое здесь, старое там.
Тем более что за это время уже сложился определенный технологический процесс работы над статьями и менять в нем хотелось что-либо в самую последнюю очередь. Поэтому инструмент должен был органично встроиться в рабочий процесс, а не заставлять менять процесс под инструмент.
У нас есть большая структура, примерно на 9 ГБ, с файлами черновиков, картинок, дополнительных материалов и т.д., разложенных в определенной иерархии папок. Осталось только добавить туда MD и вопрос решен.
При подготовке к публикации мы использовали для редактирования редактор VS Code, в целом, при помощи плагинов его несложно превратить в неплохой Markdown WYSIWYG редактор, но есть еще одно НО.
В среде профессиональных авторов и людей много работающих с текстом существует принцип «чистого листа», которые не следует путать с «боязнью чистого листа».
Данный принцип гласит, что при работе над текстом ничего не должно отвлекать от текста, с этим VS Code не справляется, да и не должен, это инструмент разработки, а не писательства.
В итоге пошел на поклон к ИИ и Gemini после нескольких попыток что-то посоветовать и выслушав мои претензии неожиданно посоветовала Zettlr.
Данный редактор возник в 2017 году как проект одного человека - Хендрика Эрца, которому нужен был простой и удобный редактор для академического письма, результат своего труда он опубликовал под лицензией GPL, что привело к привлечению в команду новых людей.
И Zettlr выстрелил, в своей среде, разумеется, среди людей, которые постоянно имеют дело с большими объемами текста. Сегодня это инструмент, управляемый сообществом и широко используемый в университетской, журналистской и писательской среде.
И он действительно удобен. Основной режим редактирования – гибридный, в том месте, где стоит курсор вы видите сырую MD-разметку, но как только вы поменяли его позицию вы видите, как это будет выглядеть в готовом документе.
При необходимости вы можете быстро переключиться в RAW-режим и проконтролировать разметку.
Редактор поддерживает проверку орфографии и пунктуации на многих языках с возможностью самостоятельно дополнять словари.
Файлы и изображения вы можете напрямую перетаскивать в окно редактора, он их сохранит в папку проекта, а если вы перетащили из папки – корректно оформит ссылку.
Есть режим автоматического сохранения при каждой правке, что ценно в наших условиях приграничья, когда в любой момент может случиться всякое.
Готовый материал можно не только сохранить как MD, но и экспортировать во все популярные офисные форматы или PDF.
А для человека много работающего с текстом у редактора есть ряд интересных и полезных режимов.
Во-первых, режим печатной машинки, когда активная область ввода (выделена серым на скриншотах) всегда остается в середине листа и текст плавно уезжает вверх. Тому, кто работает с длинными текстами не нужно пояснять удобство данного режима.
Для остальных поясним. При работе с большим текстом, более чем на 1 экран курсор у вас постоянно будет внизу страницы, что неудобно, а так вы постоянно фокусируете взгляд на одну и ту же область.
К ней можно прибавить режим «без отвлекающих факторов», он же режим «чистого листа», когда с вами только ваш текст и ничего лишнего, уже написанные абзацы немного затемняются и не отвлекают вас от текущей мысли.
На первый взгляд странно и неудобно, но постоянно работая над текстом такой режим дает наибольшую концентрацию и результативность.
Уже заканчивая работу над переносом старого сайта, мы начали подбирать инструменты для работы над новым. Нужен был удобный редактор для работы с Markdown как в визуальном режиме, так и в сыром виде.
Попробовано было не мало, но все так или иначе чем-то не подходило. Многие коллеги предлагают использовать для этого Joplin/Obsidian, да, там неплохой редактор, но это отдельные приложения для ведения заметок, а не редакторы.
Особенно учитывая наличие проекта с 16-летней историей, запихать ее всю в заметки – не самая лучшая идея, как и жить на два дома: новое здесь, старое там.
Тем более что за это время уже сложился определенный технологический процесс работы над статьями и менять в нем хотелось что-либо в самую последнюю очередь. Поэтому инструмент должен был органично встроиться в рабочий процесс, а не заставлять менять процесс под инструмент.
У нас есть большая структура, примерно на 9 ГБ, с файлами черновиков, картинок, дополнительных материалов и т.д., разложенных в определенной иерархии папок. Осталось только добавить туда MD и вопрос решен.
При подготовке к публикации мы использовали для редактирования редактор VS Code, в целом, при помощи плагинов его несложно превратить в неплохой Markdown WYSIWYG редактор, но есть еще одно НО.
В среде профессиональных авторов и людей много работающих с текстом существует принцип «чистого листа», которые не следует путать с «боязнью чистого листа».
Данный принцип гласит, что при работе над текстом ничего не должно отвлекать от текста, с этим VS Code не справляется, да и не должен, это инструмент разработки, а не писательства.
В итоге пошел на поклон к ИИ и Gemini после нескольких попыток что-то посоветовать и выслушав мои претензии неожиданно посоветовала Zettlr.
Данный редактор возник в 2017 году как проект одного человека - Хендрика Эрца, которому нужен был простой и удобный редактор для академического письма, результат своего труда он опубликовал под лицензией GPL, что привело к привлечению в команду новых людей.
И Zettlr выстрелил, в своей среде, разумеется, среди людей, которые постоянно имеют дело с большими объемами текста. Сегодня это инструмент, управляемый сообществом и широко используемый в университетской, журналистской и писательской среде.
И он действительно удобен. Основной режим редактирования – гибридный, в том месте, где стоит курсор вы видите сырую MD-разметку, но как только вы поменяли его позицию вы видите, как это будет выглядеть в готовом документе.
При необходимости вы можете быстро переключиться в RAW-режим и проконтролировать разметку.
Редактор поддерживает проверку орфографии и пунктуации на многих языках с возможностью самостоятельно дополнять словари.
Файлы и изображения вы можете напрямую перетаскивать в окно редактора, он их сохранит в папку проекта, а если вы перетащили из папки – корректно оформит ссылку.
Есть режим автоматического сохранения при каждой правке, что ценно в наших условиях приграничья, когда в любой момент может случиться всякое.
Готовый материал можно не только сохранить как MD, но и экспортировать во все популярные офисные форматы или PDF.
А для человека много работающего с текстом у редактора есть ряд интересных и полезных режимов.
Во-первых, режим печатной машинки, когда активная область ввода (выделена серым на скриншотах) всегда остается в середине листа и текст плавно уезжает вверх. Тому, кто работает с длинными текстами не нужно пояснять удобство данного режима.
Для остальных поясним. При работе с большим текстом, более чем на 1 экран курсор у вас постоянно будет внизу страницы, что неудобно, а так вы постоянно фокусируете взгляд на одну и ту же область.
К ней можно прибавить режим «без отвлекающих факторов», он же режим «чистого листа», когда с вами только ваш текст и ничего лишнего, уже написанные абзацы немного затемняются и не отвлекают вас от текущей мысли.
На первый взгляд странно и неудобно, но постоянно работая над текстом такой режим дает наибольшую концентрацию и результативность.
5👍41⚡1❤1🤮1
Подборка наших статей про BIND, ISC DHCP и Kea
▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP
▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP
▫️ Установка и базовая настройка DHCP-сервера Kea
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP
▫️ Настраиваем отказоустойчивый DHCP-сервер на базе ISC DHCP
▫️ Настраиваем отказоустойчивый DNS-сервер на базе BIND 9
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи ISC DHCP
▫️ Установка и базовая настройка DHCP-сервера Kea
▫️ Настраиваем динамическое обновление DNS-сервера BIND 9 при помощи Kea DHCP
👍17👀4❤1
Обновляем Proxmox Virtual Environment с версии 8 до 9
Практически сразу после выхода Debian 13 была выпущена новая версия известного гипервизора Proxmox Virtual Environment 9. Это плановое обновление, с которым можно не спешить, поддержка восьмой версии запланирована до августа 2026 года, поэтому есть время подготовиться.
Наша инструкция, как всегда, написана на основе официальной документации, но нацелена именно на использование бесплатной версии и дополнена собственным опытом, накопленном в процессе эксплуатации данного продукта.
✅ Читать далее
Практически сразу после выхода Debian 13 была выпущена новая версия известного гипервизора Proxmox Virtual Environment 9. Это плановое обновление, с которым можно не спешить, поддержка восьмой версии запланирована до августа 2026 года, поэтому есть время подготовиться.
Наша инструкция, как всегда, написана на основе официальной документации, но нацелена именно на использование бесплатной версии и дополнена собственным опытом, накопленном в процессе эксплуатации данного продукта.
✅ Читать далее
👍32👌8🌭2🤮1🤝1
Фишинг через RDP
Старый-добрый RDP известен всем, казалось бы, что тут можно придумать нового и вообще, что может пойти не так?
Взломать? Да, возможно, ломали и этот вектор атаки остается актуальным, так как обновления на Windows Server далеко не все устанавливают своевременно, а также в эксплуатации достаточно откровенно старых систем.
Но фишинг? Да, именно фишинг. Причем уязвимость оказалась очень серьезной и заставила Microsoft выпустить усиливающие защиту обновления.
Все дело в возможностях протокола RDP, который позволяет пробрасывать на удаленное устройство ресурсы локальной машины: буфер обмена, диски, токены и т.д.
Сценарий последующей атаки очень прост: злоумышленник присылает жертве RDP-файл и убеждает запустить его под благовидным предлогом. Далее идет подключение к серверу злоумышленника с пробросом всех локальных ресурсов, после чего последний получает полный доступ к ним.
Просто, но эффективно. Все окружение пользователя, все доступные ему ресурсы прямо на блюдечке с голубой каемочкой.
Исправления вошли в апрельское обновление безопасности:
🔹KB5082200 для Windows 10
🔹KB5083769/KB5082052 для Windows 11
Теперь при подключении показывается более подробные сведения о системе назначения, явно отображаются ресурсы, которые предлагается расшарить, но разрешения по умолчанию сброшены, т.е. пользователь должен явно подтвердить разрешение доступа к каждому ресурсу.
✅ Более подробно можно прочитать здесь: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
Старый-добрый RDP известен всем, казалось бы, что тут можно придумать нового и вообще, что может пойти не так?
Взломать? Да, возможно, ломали и этот вектор атаки остается актуальным, так как обновления на Windows Server далеко не все устанавливают своевременно, а также в эксплуатации достаточно откровенно старых систем.
Но фишинг? Да, именно фишинг. Причем уязвимость оказалась очень серьезной и заставила Microsoft выпустить усиливающие защиту обновления.
Все дело в возможностях протокола RDP, который позволяет пробрасывать на удаленное устройство ресурсы локальной машины: буфер обмена, диски, токены и т.д.
Сценарий последующей атаки очень прост: злоумышленник присылает жертве RDP-файл и убеждает запустить его под благовидным предлогом. Далее идет подключение к серверу злоумышленника с пробросом всех локальных ресурсов, после чего последний получает полный доступ к ним.
Просто, но эффективно. Все окружение пользователя, все доступные ему ресурсы прямо на блюдечке с голубой каемочкой.
Исправления вошли в апрельское обновление безопасности:
🔹KB5082200 для Windows 10
🔹KB5083769/KB5082052 для Windows 11
Теперь при подключении показывается более подробные сведения о системе назначения, явно отображаются ресурсы, которые предлагается расшарить, но разрешения по умолчанию сброшены, т.е. пользователь должен явно подтвердить разрешение доступа к каждому ресурсу.
✅ Более подробно можно прочитать здесь: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
👍35😁5❤2👌2
Удобство против безопасности
Стоило нам опубликовать днем новую заметку о фишинге через RDP и предпринятых разработчиками Windows мерами по этому поводу, как тут же появились советы как все это отключить.
На первый взгляд – парадокс, но на самом деле все закономерно. Человек существо ленивое и подверженное привычкам, от которых очень трудно избавляется. И для обычного пользователя все эти нововведения - только очередное неудобство, которое придумало IT чтобы еще сильнее затруднить им работу.
И здесь можно позавидовать тем, у кого в штатном расписании есть нормальная СБ, которая учитывает и IT-риски и на которую всегда можно перевести стрелки: мол, если недовольны – вам туда.
А в остальных случаях IT-отдел остается один на один с недовольными пользователями и раздраженным начальством. И да, появляется желание вернуть все как было, лишь бы отстали, но не стоит ему потакать.
Хотя не стоит и бросаться в крайности. Мы давно говорим о том, что затраты на безопасность не должны превышать возможный ущерб от ее отсутствия. Если проводить аналогию, то не стоит вешать на дачный сарай замок стоимостью выше, чем все имущество внутри этого сарая.
Но в данном случае следует исходить именно из оценки возможного ущерба, а он тут потенциально велик. Протокол RDP позволяет пробросить на удаленный компьютер практически все локальные ресурсы ПК, включая подключенные к нему токены и электронные ключи.
А это дает возможность выполнить определенные действия от вашего имени, которые потом будет очень сложно оспорить, либо вообще увести ваши ключи, если у вас там что-то простое, наподобие Rutoken Lite.
Если такое случится, то кто будет виноват? Конечно же IT-отдел и отмаза, что пользователям было неудобно тут не прокатит. Потому что руководство сразу задаст резонный вопрос: а видел ли ты подобный вариант развития событий? А если видел, то почему не настоял, не донес в понятной нам форме? Почему не был достаточно настойчив?
При том, что поиск крайнего – это любимое развлечение управленческой прослойки во все времена. И стать крайним очень и очень плохо. Особенно в бюджете и госах.
В тоже время всегда надо помнить, что безопасность и удобство – это два разных полюса и иногда надо настоять на своем и пожертвовать удобством ради безопасности.
Пользователи поворчат, но привыкнут, а вы снимите с себя еще одну головную боль. И не нужно вестись на шантаж, потому как удобно будет им, а отвечать будете вы.
Ну или требуйте письменный приказ от лиц, принимающих решения, в которых они явно приказывают вам понизить уровень безопасности и берут ответственность на себя.
Главное не забыть про последний пункт, потому что без делегирования ответственности эта бумага будет просто филькиной грамотой.
В заключение хочется сказать: коллеги, будьте разумны, осознавайте рамки ответственности и грамотно проводите политику, балансируя между безопасностью и удобством не выходя в зону риска.
Стоило нам опубликовать днем новую заметку о фишинге через RDP и предпринятых разработчиками Windows мерами по этому поводу, как тут же появились советы как все это отключить.
На первый взгляд – парадокс, но на самом деле все закономерно. Человек существо ленивое и подверженное привычкам, от которых очень трудно избавляется. И для обычного пользователя все эти нововведения - только очередное неудобство, которое придумало IT чтобы еще сильнее затруднить им работу.
И здесь можно позавидовать тем, у кого в штатном расписании есть нормальная СБ, которая учитывает и IT-риски и на которую всегда можно перевести стрелки: мол, если недовольны – вам туда.
А в остальных случаях IT-отдел остается один на один с недовольными пользователями и раздраженным начальством. И да, появляется желание вернуть все как было, лишь бы отстали, но не стоит ему потакать.
Хотя не стоит и бросаться в крайности. Мы давно говорим о том, что затраты на безопасность не должны превышать возможный ущерб от ее отсутствия. Если проводить аналогию, то не стоит вешать на дачный сарай замок стоимостью выше, чем все имущество внутри этого сарая.
Но в данном случае следует исходить именно из оценки возможного ущерба, а он тут потенциально велик. Протокол RDP позволяет пробросить на удаленный компьютер практически все локальные ресурсы ПК, включая подключенные к нему токены и электронные ключи.
А это дает возможность выполнить определенные действия от вашего имени, которые потом будет очень сложно оспорить, либо вообще увести ваши ключи, если у вас там что-то простое, наподобие Rutoken Lite.
Если такое случится, то кто будет виноват? Конечно же IT-отдел и отмаза, что пользователям было неудобно тут не прокатит. Потому что руководство сразу задаст резонный вопрос: а видел ли ты подобный вариант развития событий? А если видел, то почему не настоял, не донес в понятной нам форме? Почему не был достаточно настойчив?
При том, что поиск крайнего – это любимое развлечение управленческой прослойки во все времена. И стать крайним очень и очень плохо. Особенно в бюджете и госах.
В тоже время всегда надо помнить, что безопасность и удобство – это два разных полюса и иногда надо настоять на своем и пожертвовать удобством ради безопасности.
Пользователи поворчат, но привыкнут, а вы снимите с себя еще одну головную боль. И не нужно вестись на шантаж, потому как удобно будет им, а отвечать будете вы.
Ну или требуйте письменный приказ от лиц, принимающих решения, в которых они явно приказывают вам понизить уровень безопасности и берут ответственность на себя.
Главное не забыть про последний пункт, потому что без делегирования ответственности эта бумага будет просто филькиной грамотой.
В заключение хочется сказать: коллеги, будьте разумны, осознавайте рамки ответственности и грамотно проводите политику, балансируя между безопасностью и удобством не выходя в зону риска.
👍35❤3🤮2🤝2
Интересная статья на Хабре
Как я за 15 лет устал диагностировать серверы руками и сделал инструмент, который делает это за 60 секунд
Предыстория:
Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top. Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но вопрос оставался один и тот же:
Сервер тормозит. Что не так?
За эти годы у меня накопились инструкции, SSH-скрипты, обёртки над vmstat, iostat, ss, perf. Каждый раз, подключаясь к проблемному серверу, я тратил 20-40 минут на одни и те же действия вроде команды top
Это Tier 1 — базовый уровень. Но когда top показывает что всё вроде нормально, а приложение всё равно тормозит, начинается настоящая диагностика.
Глубже: BPF, softnet, NUMA и другие невидимые проблемы
С опытом я погружался глубже. BPF/eBPF инструменты от Brendan Gregg — runqlat, biolatency, tcpretrans, offcputime — открыли целый мир проблем, невидимых через top
Проблема в том, что подобные задачи решаются не каждый день. Между инцидентами проходят недели, иногда месяцы. И каждый раз я забывал: как называлась та утилита для softnet? Какой файл в /proc показывает conntrack drops? Какой sysctl отвечает за watermark?
Я снова гуглил, перечитывал свои же заметки, вспоминал синтаксис BCC-тулз.
AI изменила правила игры — но не до конца
Появление ChatGPT, а затем Claude изменило workflow. Теперь не нужно парсить глазами вывод cat /proc/net/netstat — можно скормить его нейронке и получить анализ. Не нужно помнить, что PruneCalled > 0 означает давление на TCP-память — AI это знает.
Но есть проблемы в том что нейросеть не умеет сама находить правильные инструменты и строить связи для вывода между ними. Давать root и SSH не безопасно. Запуски программ диагностики съедают кучу токенов и т.д.
Я понял, что нужен мост между сервером и AI: инструмент, который соберёт все данные за один прогон, в структурированном виде, и отдаст нейронке для анализа.
Что я сделал
melisai — один Go-бинарник. Без зависимостей, без конфигов, без демонов. Одна команда.
✅ Читать далее: https://habr.com/ru/articles/1019782/
Как я за 15 лет устал диагностировать серверы руками и сделал инструмент, который делает это за 60 секунд
Предыстория:
Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top. Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но вопрос оставался один и тот же:
Сервер тормозит. Что не так?
За эти годы у меня накопились инструкции, SSH-скрипты, обёртки над vmstat, iostat, ss, perf. Каждый раз, подключаясь к проблемному серверу, я тратил 20-40 минут на одни и те же действия вроде команды top
Это Tier 1 — базовый уровень. Но когда top показывает что всё вроде нормально, а приложение всё равно тормозит, начинается настоящая диагностика.
Глубже: BPF, softnet, NUMA и другие невидимые проблемы
С опытом я погружался глубже. BPF/eBPF инструменты от Brendan Gregg — runqlat, biolatency, tcpretrans, offcputime — открыли целый мир проблем, невидимых через top
Проблема в том, что подобные задачи решаются не каждый день. Между инцидентами проходят недели, иногда месяцы. И каждый раз я забывал: как называлась та утилита для softnet? Какой файл в /proc показывает conntrack drops? Какой sysctl отвечает за watermark?
Я снова гуглил, перечитывал свои же заметки, вспоминал синтаксис BCC-тулз.
AI изменила правила игры — но не до конца
Появление ChatGPT, а затем Claude изменило workflow. Теперь не нужно парсить глазами вывод cat /proc/net/netstat — можно скормить его нейронке и получить анализ. Не нужно помнить, что PruneCalled > 0 означает давление на TCP-память — AI это знает.
Но есть проблемы в том что нейросеть не умеет сама находить правильные инструменты и строить связи для вывода между ними. Давать root и SSH не безопасно. Запуски программ диагностики съедают кучу токенов и т.д.
Я понял, что нужен мост между сервером и AI: инструмент, который соберёт все данные за один прогон, в структурированном виде, и отдаст нейронке для анализа.
Что я сделал
melisai — один Go-бинарник. Без зависимостей, без конфигов, без демонов. Одна команда.
✅ Читать далее: https://habr.com/ru/articles/1019782/
Хабр
Как я за 15 лет устал диагностировать серверы руками и сделал инструмент, который делает это за 60 секунд
Предыстория: Я работаю с Linux больше 15 лет. Начинал с хостинга, где «сервер тормозит» означало зайти по SSH и запустить top . Потом были выделенные серверы, кластеры, Kubernetes. Задачи менялись, но...
👍37🔥16❤5🤮1
И снова одно и тоже... Выключился свет, бесперебойник погас, сервера упали... А теперь... В общем - беда, да еще и вечером.
А надо было всего-лишь подстелить соломки...
Настраиваем централизованное управление электропитанием в сети при помощи NUT
Всем известно, что для защиты от сбоев электропитания нужно купить бесперебойник. Но сам по себе источник бесперебойного питания не решает проблему, а только отсрочивает негативные последствия.
Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте - NUT (Network UPS Tools).
✅ Читать далее
А надо было всего-лишь подстелить соломки...
Настраиваем централизованное управление электропитанием в сети при помощи NUT
Всем известно, что для защиты от сбоев электропитания нужно купить бесперебойник. Но сам по себе источник бесперебойного питания не решает проблему, а только отсрочивает негативные последствия.
Действительно, если питание пропадет надолго, то после разрядки батарей ИБП ваши системы аварийно завершат работу. Избежать этого позволяют модели, имеющие обратную связь, но, чтобы использовать эти возможности нам потребуется система управления электропитанием и сегодня мы расскажем об открытом и бесплатном продукте - NUT (Network UPS Tools).
✅ Читать далее
👍34🔥1
psistat – монитор Pressure Stall Information (PSI) в Linux
Про метрики Pressure Stall Information мы уже рассказывали в материале про новые возможности Proxmox VE 9.
Но это универсальные Linux метрики, которые появились в ядре 4.20 и показывают процент времени, в течении которого процессы ожидают освобождения критичных ресурсов: процессора, памяти, ввода-вывода.
👉 У данных метрик есть две основные категории:
🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов
🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов
Про интерпретацию их значений мы повторяться не будем, все это можно прочитать в заметке по ссылке. Сегодня мы расскажем про инструмент их контроля в реальном времени – psistat.
Он написан на python и для его установки вам сначала потребуется pipx:
Затем:
Он установит утилиту в
После чего выйдите и снова войдите в систему.
Затем просто запустите:
Вы увидите интерактивный текстовый интерфейс как на скриншоте, метрики со средними значениями в 60 и 300 секунд предоставляются ядром и доступны сразу, метрики за 1, 3 и 10 секунд рассчитываются утилитой на основе накопленных данных и появляются не сразу.
Управление происходит при помощи клавиш:
▫️ t – задает порог превышения метрики, по умолчанию 5%
▫️ i – интервал превышения, по умолчанию 10 сек
Теперь любое событие, значение которого превысит 5% за 10 секунд появится в таблице ниже.
Остальные клавиши управляют отображением этой таблицы:
▫️ b – ограничивает ее размером экрана, остальные события вытесняются, иначе доступен полный список
▫️ d – дамп, прерывает интерактивный режим и выводит список событий в консоль, чтобы вы могли его скопировать, после чего переходит в режим нормальной работы.
Инструмент крайне интересный и полезный, потому что сегодня мало интерактивных инструментов для Pressure Stall Information, в то время как это один из важнейших показателей при анализе проблем с производительностью.
Про метрики Pressure Stall Information мы уже рассказывали в материале про новые возможности Proxmox VE 9.
Но это универсальные Linux метрики, которые появились в ядре 4.20 и показывают процент времени, в течении которого процессы ожидают освобождения критичных ресурсов: процессора, памяти, ввода-вывода.
👉 У данных метрик есть две основные категории:
🔹 some — показывает время, когда хотя бы один процесс ожидает освобождения ресурсов
🔹 full — показывает время, когда все активные процессы ожидают освобождения ресурсов
Про интерпретацию их значений мы повторяться не будем, все это можно прочитать в заметке по ссылке. Сегодня мы расскажем про инструмент их контроля в реальном времени – psistat.
Он написан на python и для его установки вам сначала потребуется pipx:
apt install pipx
Затем:
pipx install psistat
Он установит утилиту в
~/.local/bin и если вы хотите, чтобы утилита была доступна без указания полного пути, выполните: pipx ensurepath
После чего выйдите и снова войдите в систему.
Затем просто запустите:
psistat
Вы увидите интерактивный текстовый интерфейс как на скриншоте, метрики со средними значениями в 60 и 300 секунд предоставляются ядром и доступны сразу, метрики за 1, 3 и 10 секунд рассчитываются утилитой на основе накопленных данных и появляются не сразу.
Управление происходит при помощи клавиш:
▫️ t – задает порог превышения метрики, по умолчанию 5%
▫️ i – интервал превышения, по умолчанию 10 сек
Теперь любое событие, значение которого превысит 5% за 10 секунд появится в таблице ниже.
Остальные клавиши управляют отображением этой таблицы:
▫️ b – ограничивает ее размером экрана, остальные события вытесняются, иначе доступен полный список
▫️ d – дамп, прерывает интерактивный режим и выводит список событий в консоль, чтобы вы могли его скопировать, после чего переходит в режим нормальной работы.
Инструмент крайне интересный и полезный, потому что сегодня мало интерактивных инструментов для Pressure Stall Information, в то время как это один из важнейших показателей при анализе проблем с производительностью.
👍17❤1
Жизнь и необычайные приключения DNS в одной сети
Продолжая тему DNS, точнее борьбы с утечкой DNS хотим рассказать о собственном опыте, он во многом частный и субъективный, но во многом помогает понять на что надо обратить внимание и куда смотреть.
Начнем со всеми любимых роутеров Mikrotik. Если мы заглянем с настройки DNS, то можем увидеть там, как доступные к редактированию поля, где записаны указанные нами значения вышестоящих серверов, так и недоступные к редактированию значения, которые берутся из настроек DHCP или коммутируемого соединения. Т.е. то, что передал нам провайдер.
Они используются как дополнительные DNS, если не отвечают те, которые мы указали явно – в дело идут следующие по списку. Это не хорошо и не плохо, это нормальное поведение DNS-клиента.
Далее есть еще одна тонкость, если в настройках DHCP-сервера у вас явно не указана Option 6, она же адрес(а) DNS, то ваш DHCP передаст как собственный адрес (первым), так и все внешние адреса, которые указаны в настройках вышестоящих DNS.
Таким образом, если ваш роутер вдруг по какой-то причине перестал отвечать на DNS-запросы они пойдут напрямую внешним серверам.
Вот так вы можете легко и непринужденно начать использовать на клиентах совсем не те DNS-сервера, которые предполагали.
Но это еще не все. Проанализировав DNS-трафик в сети, мы выяснили, что мобильные устройства на Android эпизодически обращаются к DNS-серверам Google, хотя эти сервера нигде в настройках сети до этого не фигурировали.
Скорее всего такое поведение зашито где-то внутри ОС и предполагает использование именно доверенных для нее серверов. Такое поведение можно понять, но с позиции наших целей, а именно защитить DNS-запросы от просмотра третьими лицами – налицо типичная утечка.
Но это половина беды. От тех же мобильных устройств и телевизоров были обнаружены DNS-запросы к вообще третьим DNS-серверам, о существовании которых мы ранее не догадывались.
Причем это не какие-то левые сервера, а достаточно крупные региональные сервисы или сервисы крупных хостеров, как вероятно зашитые разработчиками приложений в свои разработки. Это тоже не особо страшно и не особо плохо, но в наличии у нас имеется факт, что отдельные приложения могут также игнорировать системные настройки DNS.
Вы думаете, что это все? Но нет. Отдельно порадовали два роутера Xiaomi AX3000T, которые продолжили обращаться к внешним серверам, используемыми нами до этого и серверам провайдера.
При этом сетевые настройки они получают от DHCP-сервера на Mikrotik, но все настройки, кроме адреса и шлюза тупо игнорируют.
В веб-интерфейсе и приложении доступа к этим настройкам также нет. Перезагрузка не помогает и приводит только к замене одного сервера на другой из списка.
Есть предположение что DNS-сервера были взяты при первоначальной настройке и добавлены в некоторый конфигурационный файл, который при смене настроек DHCP не обновляется.
В данном случае они работают именно как точки доступа и разрешают только свои внутренние запросы. Но все равно, данный факт показывает, что активное сетевое оборудование в вашей сети также может иметь свои собственные взаимоотношения с DNS, что может приводить к утечкам.
Пока мы плотно не занялись этим вопросом, то предполагали, что основной риск утечки DNS несут пользователи, которые могут вручную поменять сервера в настройках сетевого подключения.
В реальности же это оказалось далеко не так и основной риск исходит от сетевых устройств и сетевых приложений, которые могут игнорировать (и успешно это делают) системные настройки DNS.
Продолжая тему DNS, точнее борьбы с утечкой DNS хотим рассказать о собственном опыте, он во многом частный и субъективный, но во многом помогает понять на что надо обратить внимание и куда смотреть.
Начнем со всеми любимых роутеров Mikrotik. Если мы заглянем с настройки DNS, то можем увидеть там, как доступные к редактированию поля, где записаны указанные нами значения вышестоящих серверов, так и недоступные к редактированию значения, которые берутся из настроек DHCP или коммутируемого соединения. Т.е. то, что передал нам провайдер.
Они используются как дополнительные DNS, если не отвечают те, которые мы указали явно – в дело идут следующие по списку. Это не хорошо и не плохо, это нормальное поведение DNS-клиента.
Далее есть еще одна тонкость, если в настройках DHCP-сервера у вас явно не указана Option 6, она же адрес(а) DNS, то ваш DHCP передаст как собственный адрес (первым), так и все внешние адреса, которые указаны в настройках вышестоящих DNS.
Таким образом, если ваш роутер вдруг по какой-то причине перестал отвечать на DNS-запросы они пойдут напрямую внешним серверам.
Вот так вы можете легко и непринужденно начать использовать на клиентах совсем не те DNS-сервера, которые предполагали.
Но это еще не все. Проанализировав DNS-трафик в сети, мы выяснили, что мобильные устройства на Android эпизодически обращаются к DNS-серверам Google, хотя эти сервера нигде в настройках сети до этого не фигурировали.
Скорее всего такое поведение зашито где-то внутри ОС и предполагает использование именно доверенных для нее серверов. Такое поведение можно понять, но с позиции наших целей, а именно защитить DNS-запросы от просмотра третьими лицами – налицо типичная утечка.
Но это половина беды. От тех же мобильных устройств и телевизоров были обнаружены DNS-запросы к вообще третьим DNS-серверам, о существовании которых мы ранее не догадывались.
Причем это не какие-то левые сервера, а достаточно крупные региональные сервисы или сервисы крупных хостеров, как вероятно зашитые разработчиками приложений в свои разработки. Это тоже не особо страшно и не особо плохо, но в наличии у нас имеется факт, что отдельные приложения могут также игнорировать системные настройки DNS.
Вы думаете, что это все? Но нет. Отдельно порадовали два роутера Xiaomi AX3000T, которые продолжили обращаться к внешним серверам, используемыми нами до этого и серверам провайдера.
При этом сетевые настройки они получают от DHCP-сервера на Mikrotik, но все настройки, кроме адреса и шлюза тупо игнорируют.
В веб-интерфейсе и приложении доступа к этим настройкам также нет. Перезагрузка не помогает и приводит только к замене одного сервера на другой из списка.
Есть предположение что DNS-сервера были взяты при первоначальной настройке и добавлены в некоторый конфигурационный файл, который при смене настроек DHCP не обновляется.
В данном случае они работают именно как точки доступа и разрешают только свои внутренние запросы. Но все равно, данный факт показывает, что активное сетевое оборудование в вашей сети также может иметь свои собственные взаимоотношения с DNS, что может приводить к утечкам.
Пока мы плотно не занялись этим вопросом, то предполагали, что основной риск утечки DNS несут пользователи, которые могут вручную поменять сервера в настройках сетевого подключения.
В реальности же это оказалось далеко не так и основной риск исходит от сетевых устройств и сетевых приложений, которые могут игнорировать (и успешно это делают) системные настройки DNS.
👍29❤4👌3🤡2
Caddy-Docker-Proxy
Веб-сервер Caddy крайне популярен не только в виде веб-сервера, но и обратного прокси, благодаря крайне простой настройке, автоматической конфигурации TLS, включая прозрачную интеграцию с Let’s Encrypt.
Также Caddy популярен как обратный прокси для Docker, который обычно принято настраивать «классически», например:
Но Docker – это в первую очередь динамические среды, контейнеры могут создаваться, удаляться, меняться, особенно в тестовых средах и каждый раз править руками конфигурацию обратного прокси – занятие утомительное.
Поэтому был разработан специальный плагин Caddy-Docker-Proxy, который позволяет Caddy работать с метками Docker, автоматически подхватывая конфигурацию, как Traefik.
Для этого просто используйте готовый контейнер от разработчика плагина, для этого создайте следующий
Затем в compose нужного сервиса добавьте:
Теперь при запуске контейнера my_app в конфигурацию Caddy будет добавлена секция для обратного проксирования вашего сервиса.
Веб-сервер Caddy крайне популярен не только в виде веб-сервера, но и обратного прокси, благодаря крайне простой настройке, автоматической конфигурации TLS, включая прозрачную интеграцию с Let’s Encrypt.
Также Caddy популярен как обратный прокси для Docker, который обычно принято настраивать «классически», например:
grafana.example.com {
reverse_proxy grafana:3000
}
nextcloud.example.com {
reverse_proxy nextcloud:8080
}Но Docker – это в первую очередь динамические среды, контейнеры могут создаваться, удаляться, меняться, особенно в тестовых средах и каждый раз править руками конфигурацию обратного прокси – занятие утомительное.
Поэтому был разработан специальный плагин Caddy-Docker-Proxy, который позволяет Caddy работать с метками Docker, автоматически подхватывая конфигурацию, как Traefik.
Для этого просто используйте готовый контейнер от разработчика плагина, для этого создайте следующий
docker-compose.yamlservices:
caddy:
image: lucaslorentz/caddy-docker-proxy:ci-alpine
ports:
- 80:80
- 443:443/tcp
- 443:443/udp
environment:
- CADDY_INGRESS_NETWORKS=caddy
networks:
- caddy
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- caddy_data:/data
restart: unless-stopped
networks:
caddy:
external: true
volumes:
caddy_data: {}
Затем в compose нужного сервиса добавьте:
services:
my_app:
image: my_app:latest
networks:
- caddy
labels:
caddy: my_app.example.com
caddy.reverse_proxy: "{{upstreams 80}}"
networks:
caddy:
external: true
Теперь при запуске контейнера my_app в конфигурацию Caddy будет добавлена секция для обратного проксирования вашего сервиса.
👍30❤1
ИИ в современной разработке
Вчера была ровно неделя релизу нашего нового сайта и самое время подвести итоги и рассказать о той роли ИИ, которую он взял на себя в этом нелегком процессе.
В настоящее время бытует два противоположных мнения. Одно из них, что ИИ — это баловство и ничего серьезного он не напишет, дольше будете за ним разгребать и проверять. Второе, что это прямо серебряная пуля, только успевай загадывать желания.
Истина, как всегда, где-то посередине и пока фанатики с обеих сторон ломают копья, практики играют от сильных сторон доступных решений.
Мы не раз и не два пытались перевести сайт на новый движок, но все упиралось в то, что если, в общем и целом, все было хорошо, то оставшиеся 20% «мелочи» требовали оставшиеся 80% времени, которые надо было потратить на глубокое погружение в новый движок.
Никакой Америки мы тут не открыли, это в любой отрасли так. Но всегда лучше, если у тебя есть наставник, который хотя бы покажет примеры и пояснит почему тут так, а не эдак.
И нейросети вполне могут стать таким наставником. При освоении HUGO именно ИИ помог быстро разобраться в устройстве движка, принципах построения проекта, шаблонизации.
Я просто закидывал ему насущные задачи, проверял ответы и просил пояснить что именно он сделал и почему.
Можно ли это было сделать самому? Можно, но вопрос не в этом, а в затраченном времени. То, что я сделал с ИИ за вечер самостоятельно я бы искал неделю – читал документацию, проверял варианты, отлаживал, искал ответы на форумах и т.д. и т.п.
А тут интенсивная и быстрая прокачка прямо по ходу решения актуальных вопросов.
Поэтому, если вы действительно настроены на изучение новой темы, то ИИ дают вам возможность быстрого старта за счет концентрации уже накопленных знаний в одном месте.
Но можно ли просто не вникать, а заставить ИИ довести проект до конца? Можно, только вот далеко не факт, что вы придете туда, куда хотели, а не заплутаете в трех соснах.
В части освоения азов сетки дают отличный старт, но вот после они уже не так уверенны в себе, хотя вам никогда этого не покажут.
На сложных вопросах сетка может начать галлюцинировать или ходить по кругу, предлагая набор неработающих решений по кругу.
Именно с этим я столкнулся при решении вопроса транслитерации таксономии. ИИ выдавал одно нерабочее решение за другим, потом говорил, что он все понял и выдавал очередную дребедень и так по кругу.
Тут помогли знания, которые я почерпнул на первом этапе освоения движка, с его же помощью. Я просто ткнул его носом в кусок кода и спросил – а почему тут так, ведь надо совсем иначе.
В ответ получил стандартное – ты абсолютно прав и пояснения, почему это не будет работать.
Дальше предлагаю ему поискать в сети эту же проблему и через минуту получаю ссылку на форум с рабочим решением.
Проверяю – работает, но у меня не один шаблон и не два. Беру ссылку отдаю ИИ и говорю, вот так работает, давай ка сделай на проекте как надо и очень скоро получаю все необходимые правки.
Много ли я написал кода сам? Строки две-три, остальное старалась сетка. Результат – он перед вами. Полгода на перенос проекта с историей более 15 лет, большая часть которого это именно перенос контента, а не работа над сайтом.
Да, в любом случае в новом проекте будет все и косяки, и баги, но факт не в этом, а в том, что ИИ позволяет вам сократить путь от задумки до релиза. А не зависнуть надолго в промежуточной стадии.
Код написан ИИ? А что в этом плохого? Сетка давно пишет лучше человека, читая ее код я понимаю, что сам бы проигнорировал все эти проверки, обработки исключений и прочее, так как это в «типовом сценарии» маловероятно.
Поэтому не стоит чураться ИИ, равно как и превозносить их, это просто современный рабочий инструмент, который способен быстро подсказать, помочь, ввести в курс дела или взять на себя рутину.
Но руководите проектом именно вы и вы решаете в какую именно сторону будет грести ИИ и что конкретно он будет делать.
Вчера была ровно неделя релизу нашего нового сайта и самое время подвести итоги и рассказать о той роли ИИ, которую он взял на себя в этом нелегком процессе.
В настоящее время бытует два противоположных мнения. Одно из них, что ИИ — это баловство и ничего серьезного он не напишет, дольше будете за ним разгребать и проверять. Второе, что это прямо серебряная пуля, только успевай загадывать желания.
Истина, как всегда, где-то посередине и пока фанатики с обеих сторон ломают копья, практики играют от сильных сторон доступных решений.
Мы не раз и не два пытались перевести сайт на новый движок, но все упиралось в то, что если, в общем и целом, все было хорошо, то оставшиеся 20% «мелочи» требовали оставшиеся 80% времени, которые надо было потратить на глубокое погружение в новый движок.
Никакой Америки мы тут не открыли, это в любой отрасли так. Но всегда лучше, если у тебя есть наставник, который хотя бы покажет примеры и пояснит почему тут так, а не эдак.
И нейросети вполне могут стать таким наставником. При освоении HUGO именно ИИ помог быстро разобраться в устройстве движка, принципах построения проекта, шаблонизации.
Я просто закидывал ему насущные задачи, проверял ответы и просил пояснить что именно он сделал и почему.
Можно ли это было сделать самому? Можно, но вопрос не в этом, а в затраченном времени. То, что я сделал с ИИ за вечер самостоятельно я бы искал неделю – читал документацию, проверял варианты, отлаживал, искал ответы на форумах и т.д. и т.п.
А тут интенсивная и быстрая прокачка прямо по ходу решения актуальных вопросов.
Поэтому, если вы действительно настроены на изучение новой темы, то ИИ дают вам возможность быстрого старта за счет концентрации уже накопленных знаний в одном месте.
Но можно ли просто не вникать, а заставить ИИ довести проект до конца? Можно, только вот далеко не факт, что вы придете туда, куда хотели, а не заплутаете в трех соснах.
В части освоения азов сетки дают отличный старт, но вот после они уже не так уверенны в себе, хотя вам никогда этого не покажут.
На сложных вопросах сетка может начать галлюцинировать или ходить по кругу, предлагая набор неработающих решений по кругу.
Именно с этим я столкнулся при решении вопроса транслитерации таксономии. ИИ выдавал одно нерабочее решение за другим, потом говорил, что он все понял и выдавал очередную дребедень и так по кругу.
Тут помогли знания, которые я почерпнул на первом этапе освоения движка, с его же помощью. Я просто ткнул его носом в кусок кода и спросил – а почему тут так, ведь надо совсем иначе.
В ответ получил стандартное – ты абсолютно прав и пояснения, почему это не будет работать.
Дальше предлагаю ему поискать в сети эту же проблему и через минуту получаю ссылку на форум с рабочим решением.
Проверяю – работает, но у меня не один шаблон и не два. Беру ссылку отдаю ИИ и говорю, вот так работает, давай ка сделай на проекте как надо и очень скоро получаю все необходимые правки.
Много ли я написал кода сам? Строки две-три, остальное старалась сетка. Результат – он перед вами. Полгода на перенос проекта с историей более 15 лет, большая часть которого это именно перенос контента, а не работа над сайтом.
Да, в любом случае в новом проекте будет все и косяки, и баги, но факт не в этом, а в том, что ИИ позволяет вам сократить путь от задумки до релиза. А не зависнуть надолго в промежуточной стадии.
Код написан ИИ? А что в этом плохого? Сетка давно пишет лучше человека, читая ее код я понимаю, что сам бы проигнорировал все эти проверки, обработки исключений и прочее, так как это в «типовом сценарии» маловероятно.
Поэтому не стоит чураться ИИ, равно как и превозносить их, это просто современный рабочий инструмент, который способен быстро подсказать, помочь, ввести в курс дела или взять на себя рутину.
Но руководите проектом именно вы и вы решаете в какую именно сторону будет грести ИИ и что конкретно он будет делать.
👍34👌2❤1🤮1👀1
Использование Routing Rules в роутерах Mikrotik
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через один канал, если неожиданно отключился второй.
Вопрос не праздный, потому как при том же переключении на мобильный интернет неконтролируемый выход в сеть быстро способен исчерпать доступный лимит трафика.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой широкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию – lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной.
Поэтому, если мы не хотим, чтобы при отказе одного провайдера пакет уходил другому, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило lookup-only-in-table.
В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать адреса источника и назначения, а также интерфейс.
В действиях нам также доступны drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.
Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
На днях один коллега спросил, как эффективнее всего заблокировать доступ к определенным ресурсам через один канал, если неожиданно отключился второй.
Вопрос не праздный, потому как при том же переключении на мобильный интернет неконтролируемый выход в сеть быстро способен исчерпать доступный лимит трафика.
Можно воспользоваться брандмауэром, но есть способ лучше - Routing Rules. Это правила, используемые при маршрутизации и которые в ряде случаев позволяют решать задачи фильтрации более дешево и эффективно, нежели брандмауэр.
Однако следует помнить, что правила в Mangle имеют больший приоритет, так как будут отработаны раньше, чем будет принято решение о маршрутизации.
Правила Routing Rules начнут работать уже после того, как решение о маршрутизации принято.
Немного напомним, основной задачей маршрутизации является поиск интерфейса выхода среди непосредственно присоединенных сетей (т.е. интерфейсов маршрутизатора).
По умолчанию в роутере присутствует основная таблица маршрутизации – main, также мы можем создать сколько угодно пользовательских.
В процессе поиска маршрута роутер ищет маршрут с самой широкой маской в своей таблице маршрутизации, если ни одна запись не найдена, то выбирается «нулевой» маршрут, он же основной шлюз сети.
Очень многие ошибочно считают, что на этом процесс выбора маршрута завершен, но это не так. Да, мы знаем куда нам надо пройти, но не знаем как.
Поэтому маршрутизатор начинает искать интерфейс выхода к найденному нами шлюзу среди непосредственно присоединенных сетей, если таковой находится, то поиск считается завершенным и пакет уходит по назначению.
Если же узел назначения недоступен – поиск продолжается. Правило маршрутизации по умолчанию – lookup – поиск. И если маршрут не будет найден в собственной таблице, он будет продолжен в основной.
Поэтому, если мы не хотим, чтобы при отказе одного провайдера пакет уходил другому, то нам следует ограничить поиск только собственной таблицей маршрутизации, установив правило lookup-only-in-table.
В качестве критериев задаем метку маршрутизации и таблицу маршрутизации. Фактически правило читается так: для всех пакетов с меткой такой-то ограничить поиск таблицей маршрутизации такой-то.
Но это далеко не все. В качестве критериев мы можем использовать адреса источника и назначения, а также интерфейс.
В действиях нам также доступны drop, который молча блокирует пакет и unreachable, который отравит ICMP-ответ с сообщением о недоступности узла назначения.
Это можно использовать для ограничения доступа между сетями или отдельными узлами без использования брандмауэра.
Но выбирая тот или иной способ надо всегда руководствоваться здравым смыслом и общей читабельностью правил, так как для других ваших коллег фильтрация на уровне таблиц маршрутизации может оказаться в диковинку.
❤11🔥11👍7🤮1
Великое вымирание видов
Каждая наша публикация на тему ИИ всегда вызывает комментарии вида, что тем самым мы просто роем себе могилу и сужаем «кормовую базу», ведь если клиент может все сделать сам при помощи ИИ, то зачем ему нанимать специалиста.
Другие сетуют, что, заменив младшую ступень специалистов, так называемых «джунов» ИИ уничтожает рост квалифицированных кадров, ибо откуда тогда возьмутся «мидлы» и «сеньоры»?
Однако ничего принципиального нового не происходит, идет планомерное изменение технического уклада, которые оставит за бортом одни профессии, изменит другие и создаст третьи.
Все это уже было в человеческой истории, те же луддиты не на пустом месте возникли, но ничего, не вымерло человечество, как-то адаптировалось.
Чтобы не ходить далеко давайте вернемся в еще совсем недавнее прошлое, была такая профессия как чертежник. Его задачей было перечерчивать рабочие чертежи, потому как чертежей надо было много, а инженеры заниматься такой рутиной не хотели.
Инженер в процессе разработки или проектирования создавал чертеж, который потом те самые чертежники старательно дублировали, создавали дополнительные проекции, разрезы и все такое прочее.
Была ли эта работа творческой? Нет. Создавали ли чертежники что-то новое? Снова нет, их работа – повседневная рутина.
А потом появились CAD, которые сами, без посторонней помощи могли создать все нужные чертежи и распечатать их в нужном количестве. Чертежники как вид перестали существовать, просто за ненадобностью.
Но инженеры как были, так и остались, им даже лучше стало, не надо проверять за чертежниками, потому что CAD делает все точно и не ошибается.
Теперь вернемся к нашим баранам, в области написания кода буквами ИИ уверенно опережает человека и не «на полкорпуса», а со значительным отрывом.
В системном администрировании скоро тоже наступит перелом от повсеместного внедрения ИИ агентов. Да, в нынешнем виде агенты косячат, местами фатально, но давайте будем честны – люди косячат не реже, а даже чаще, с теми же самыми фатальными последствиями.
Но ИИ-агент, в отличие от человека, никогда не будет лениться сделать дополнительные проверки, резервные копии и все такое прочее, на что живой коллега вполне себе может забить, мол не очкуй, сто раз так делал.
Но если ИИ плотно займет позиции «джунов», откуда тогда браться более квалифицированным специалистам?
Честно? Откуда они до сих пор брались, оттуда и продолжат. Это в идеальной вселенной у нас есть «дорога из желтого кирпича» - джун, мидл, сеньор, тимлид. В реально жизни все немного иначе.
Для примера возьмем спортивную секцию в спальном районе. Туда ходит много детей, но сколько из них достигнут реальных результатов? Станут лауреатами хотя бы на уровне города?
Тут все тоже самое, большинство джунов – это пожизненные джуны, выше они никогда не стремятся и не прыгнут, по множеству самых разных причин. Начиная от способностей и заканчивая тем, что тут и так неплохо кормят.
Это те же чертежники от программирования, которые не создают никакой новой сущности, а просто переносят в код, на выбранном старшими товарищами языке их решения в четком соответствии с ТЗ и правилами проекта, стандартами языка и т.д. и т.п.
Но человек ленив, ошибается, ему надо отдыхать, спать, кушать и т.д. и т.п. Поэтому заменить его на ИИ – это только плюсы и для работодателя, и для старших товарищей. Что задачу джуну ставить, что промт написать.
А как же карьерная лестница? Да никак, ее там не было и сейчас нет. В мидлы выбиваются не те, кто хорошо умеет набивать код буквами, а кто мыслит и понимает абстракции, которые находятся выше этих букв.
Но это могут не только лишь все и для такого начинающего ИИ будет только помощником, которые реализует его идеи в коде, проверит гипотезы, расскажет, покажет и вообще поможет профессиональному росту.
Кто хочет – тот найдет пути и инструменты. А вот кто не хочет, там да, впереди великое вымирание видов. Как раньше вымерли чертежники, так скоро вымрут писатели кода буквами и админы начального уровня,
Каждая наша публикация на тему ИИ всегда вызывает комментарии вида, что тем самым мы просто роем себе могилу и сужаем «кормовую базу», ведь если клиент может все сделать сам при помощи ИИ, то зачем ему нанимать специалиста.
Другие сетуют, что, заменив младшую ступень специалистов, так называемых «джунов» ИИ уничтожает рост квалифицированных кадров, ибо откуда тогда возьмутся «мидлы» и «сеньоры»?
Однако ничего принципиального нового не происходит, идет планомерное изменение технического уклада, которые оставит за бортом одни профессии, изменит другие и создаст третьи.
Все это уже было в человеческой истории, те же луддиты не на пустом месте возникли, но ничего, не вымерло человечество, как-то адаптировалось.
Чтобы не ходить далеко давайте вернемся в еще совсем недавнее прошлое, была такая профессия как чертежник. Его задачей было перечерчивать рабочие чертежи, потому как чертежей надо было много, а инженеры заниматься такой рутиной не хотели.
Инженер в процессе разработки или проектирования создавал чертеж, который потом те самые чертежники старательно дублировали, создавали дополнительные проекции, разрезы и все такое прочее.
Была ли эта работа творческой? Нет. Создавали ли чертежники что-то новое? Снова нет, их работа – повседневная рутина.
А потом появились CAD, которые сами, без посторонней помощи могли создать все нужные чертежи и распечатать их в нужном количестве. Чертежники как вид перестали существовать, просто за ненадобностью.
Но инженеры как были, так и остались, им даже лучше стало, не надо проверять за чертежниками, потому что CAD делает все точно и не ошибается.
Теперь вернемся к нашим баранам, в области написания кода буквами ИИ уверенно опережает человека и не «на полкорпуса», а со значительным отрывом.
В системном администрировании скоро тоже наступит перелом от повсеместного внедрения ИИ агентов. Да, в нынешнем виде агенты косячат, местами фатально, но давайте будем честны – люди косячат не реже, а даже чаще, с теми же самыми фатальными последствиями.
Но ИИ-агент, в отличие от человека, никогда не будет лениться сделать дополнительные проверки, резервные копии и все такое прочее, на что живой коллега вполне себе может забить, мол не очкуй, сто раз так делал.
Но если ИИ плотно займет позиции «джунов», откуда тогда браться более квалифицированным специалистам?
Честно? Откуда они до сих пор брались, оттуда и продолжат. Это в идеальной вселенной у нас есть «дорога из желтого кирпича» - джун, мидл, сеньор, тимлид. В реально жизни все немного иначе.
Для примера возьмем спортивную секцию в спальном районе. Туда ходит много детей, но сколько из них достигнут реальных результатов? Станут лауреатами хотя бы на уровне города?
Тут все тоже самое, большинство джунов – это пожизненные джуны, выше они никогда не стремятся и не прыгнут, по множеству самых разных причин. Начиная от способностей и заканчивая тем, что тут и так неплохо кормят.
Это те же чертежники от программирования, которые не создают никакой новой сущности, а просто переносят в код, на выбранном старшими товарищами языке их решения в четком соответствии с ТЗ и правилами проекта, стандартами языка и т.д. и т.п.
Но человек ленив, ошибается, ему надо отдыхать, спать, кушать и т.д. и т.п. Поэтому заменить его на ИИ – это только плюсы и для работодателя, и для старших товарищей. Что задачу джуну ставить, что промт написать.
А как же карьерная лестница? Да никак, ее там не было и сейчас нет. В мидлы выбиваются не те, кто хорошо умеет набивать код буквами, а кто мыслит и понимает абстракции, которые находятся выше этих букв.
Но это могут не только лишь все и для такого начинающего ИИ будет только помощником, которые реализует его идеи в коде, проверит гипотезы, расскажет, покажет и вообще поможет профессиональному росту.
Кто хочет – тот найдет пути и инструменты. А вот кто не хочет, там да, впереди великое вымирание видов. Как раньше вымерли чертежники, так скоро вымрут писатели кода буквами и админы начального уровня,
👍35❤5⚡4🤔3🤮1
Официальный выход Ubuntu 26.04
В четверг, 23 апреля 2026 года был официально выпущен релиз Ubuntu 26.04, о самой системе мы уже недавно писали (https://t.me/interface31/5994) и к уже опубликованному особо добавить нечего.
Основное нововведение – это полный переход на Wayland и отказ от X11 в головном дистрибутиве. Также на Wayland перешли и такие популярные выпуски как Kubuntu и Ubuntu Budgie, но в них возможность сеанса X11 можно вернуть вручную, необходимые пакеты остались в репозитории, хотя более не поддерживаются.
В общем и целом все уверенно идет к тому, что X11 в течении нескольких следующих лет полностью сдаст свои позиции в ведущих средах рабочего стола и останется уделом энтузиастов.
И это скорее хорошо, чем плохо, так как X11 архитектурно сильно устарел, а скорость разработки Wayland откровенно не радовала, теперь же есть надежда на то, что ситуация коренным образом изменится.
Также в этом выпуске «дружное семейство» дистрибутивов на базе Ubuntu понесло потери. Так Ubuntu MATE вообще не смог сформировать сборки для 26.04 (как и не сформировал их для 25.10), а в конце марта проект покинул лидер и ведущий разработчик.
Скорее всего на Ubuntu MATE, как и на среде MATE вообще можно ставить жирный крест, проект находится в стагнации с 2024 года, и он не интересен крупным игрокам, которые могли бы вдохнуть в проект новую жизнь.
Более интересна другая сборка - Ubuntu Unity, которая все-таки выпустила релиз 26.04, но он не получил статуса LTS. А интересен этот проект тем, что основной разработчик проекта – индийский студент Rudra Saraswat, который оставил проект по причине поступления в университет.
В 2021 году, когда он только начинал работу над Unity ему было 12 лет, а уже в 2022 Ubuntu Unity вошел в число официальных редакций.
Сегодня в проекте остался только модератор, но тем не менее сборка 26.04 была сформирована на базе Unity 7.7 от декабря 2022 года.
Несмотря на это будущее проекта также туманно, так как не видно желающий подхватить проект, в то время как основной разработчик теперь имеет иные интересы.
В четверг, 23 апреля 2026 года был официально выпущен релиз Ubuntu 26.04, о самой системе мы уже недавно писали (https://t.me/interface31/5994) и к уже опубликованному особо добавить нечего.
Основное нововведение – это полный переход на Wayland и отказ от X11 в головном дистрибутиве. Также на Wayland перешли и такие популярные выпуски как Kubuntu и Ubuntu Budgie, но в них возможность сеанса X11 можно вернуть вручную, необходимые пакеты остались в репозитории, хотя более не поддерживаются.
В общем и целом все уверенно идет к тому, что X11 в течении нескольких следующих лет полностью сдаст свои позиции в ведущих средах рабочего стола и останется уделом энтузиастов.
И это скорее хорошо, чем плохо, так как X11 архитектурно сильно устарел, а скорость разработки Wayland откровенно не радовала, теперь же есть надежда на то, что ситуация коренным образом изменится.
Также в этом выпуске «дружное семейство» дистрибутивов на базе Ubuntu понесло потери. Так Ubuntu MATE вообще не смог сформировать сборки для 26.04 (как и не сформировал их для 25.10), а в конце марта проект покинул лидер и ведущий разработчик.
Скорее всего на Ubuntu MATE, как и на среде MATE вообще можно ставить жирный крест, проект находится в стагнации с 2024 года, и он не интересен крупным игрокам, которые могли бы вдохнуть в проект новую жизнь.
Более интересна другая сборка - Ubuntu Unity, которая все-таки выпустила релиз 26.04, но он не получил статуса LTS. А интересен этот проект тем, что основной разработчик проекта – индийский студент Rudra Saraswat, который оставил проект по причине поступления в университет.
В 2021 году, когда он только начинал работу над Unity ему было 12 лет, а уже в 2022 Ubuntu Unity вошел в число официальных редакций.
Сегодня в проекте остался только модератор, но тем не менее сборка 26.04 была сформирована на базе Unity 7.7 от декабря 2022 года.
Несмотря на это будущее проекта также туманно, так как не видно желающий подхватить проект, в то время как основной разработчик теперь имеет иные интересы.
👍8🤮7❤4👌2