Алиса на YandexGPT 5 Pro
Попробовал сегодня новую Алису на новом нейросетевом движке от Яндекса - https://alice.yandex.ru.
Попробовать можно бесплатно, в сутки дается сделать 20 запросов. После их окончания вас переключат на обычную, старую Алису. И вот здесь можно попробовать задать те же самые вопросы и сравнить качество ответов.
Я немного погонял ее техническими вопросами, конфигурациями, разбором логов и несложным скриптингом. Результаты откровенно порадовали. Если «старая» Алиса не блистала умом и сообразительностью, то новая отвечает весьма бодро, где-то на уровне GPT-4o.
Как и любой другой нейросети ей присущи классические недостатки, самый серьезный из которых – придумывание. Она спокойно придумает вам несуществующие опции для конфига или сама додумает возможный синтаксис.
Причем где-то она додумывает по образу и подобию – т.е. берет параметры из другой части конфига и применяет к текущей секции. А где-то фантазия разыгрывается куда дальше, и она пытается адаптировать опции из другого продукта.
Это особенно заметно, когда спрашиваешь про что-то менее распространенное. Скажем для веб-сервера Caddy она спокойно придумывала параметры на основе аналогичных для Nginx, а когда я ей заметил, что в документации их нет, спокойно согласилась и выдала только то, что есть в документации.
На более распространенных продуктах ведет себя достаточно адекватно, скрипты пишет достаточно уверенно, с должным уровнем пояснения. А стоит все это удовольствие 100 руб. в месяц. В целом достаточно неплохая альтернатива и пользоваться можно, особенно если вы уже используете другие сервисы Яндекса.
Картинку ниже тоже она нарисовала.
Попробовал сегодня новую Алису на новом нейросетевом движке от Яндекса - https://alice.yandex.ru.
Попробовать можно бесплатно, в сутки дается сделать 20 запросов. После их окончания вас переключат на обычную, старую Алису. И вот здесь можно попробовать задать те же самые вопросы и сравнить качество ответов.
Я немного погонял ее техническими вопросами, конфигурациями, разбором логов и несложным скриптингом. Результаты откровенно порадовали. Если «старая» Алиса не блистала умом и сообразительностью, то новая отвечает весьма бодро, где-то на уровне GPT-4o.
Как и любой другой нейросети ей присущи классические недостатки, самый серьезный из которых – придумывание. Она спокойно придумает вам несуществующие опции для конфига или сама додумает возможный синтаксис.
Причем где-то она додумывает по образу и подобию – т.е. берет параметры из другой части конфига и применяет к текущей секции. А где-то фантазия разыгрывается куда дальше, и она пытается адаптировать опции из другого продукта.
Это особенно заметно, когда спрашиваешь про что-то менее распространенное. Скажем для веб-сервера Caddy она спокойно придумывала параметры на основе аналогичных для Nginx, а когда я ей заметил, что в документации их нет, спокойно согласилась и выдала только то, что есть в документации.
На более распространенных продуктах ведет себя достаточно адекватно, скрипты пишет достаточно уверенно, с должным уровнем пояснения. А стоит все это удовольствие 100 руб. в месяц. В целом достаточно неплохая альтернатива и пользоваться можно, особенно если вы уже используете другие сервисы Яндекса.
Картинку ниже тоже она нарисовала.
🔥15🤮9👍7🍌2❤1
Вчера в обсуждениях поднялся вопрос о достоинствах и недостатках IPv6.
👍 Начнем с достоинств, они широко известны:
🔹 Устраняет дефицит адресов на многие десятилетия вперед.
🔹 Позволяет избавиться от NAT, теперь каждое устройство включая лампочку или чайник будет иметь собственный адрес и полноценно общаться с интернетом.
🔹 Улучшится работа P2P технологий
🔹 Упрощается автоматическая настройка сети при помощи SLAAC
🔹 Лучшая производительность за счет отсутствия фрагментации и упрощения заголовков пакетов.
🔹 Упрощается структура сети, так как устройства теперь могут общаться напрямую без NAT, VPN, туннелей и т.п.
☝️ Все это понятно, интересно, прогрессивно. Но есть и недостатки.
Я специально потратил время и изучил профильные обсуждения на сетевых ресурсах. Из чего был выделен следующий список недостатков, которые больше всего беспокоят пользователей:
🔸 Отсутствие обратной совместимости, фактически «переход» на IPv6 будет означать одновременное использование двух стеков. А это увеличение затрат на администрирование, повышенная нагрузка на оборудование и ухудшение безопасности за счет увеличения поверхности атаки.
🔸 При смене провайдера поплывет вся адресация сети, чтобы избежать этого придумано
🔸 Безопасность. NAT позволяет эффективно закрыть сегмент сети от интернета и даже при ошибках настройки брандмауэра внутренние узлы не оказывались выставлены во внешнюю сеть. В случае IPv6 требуется гораздо более грамотная и вдумчивая настройка правил межсетевого экрана.
🤔 При этом каких-либо явных преимуществ пользовательским сетям (мы не рассматриваем провайдеров, телеком, датацентры и т.п.) IPv6 не дает. А фактически усложняет сеть за счет двух независимых друг от друга настроек, так как IPv4 никуда не делся и жить на два стека придется еще очень долго.
👍 Начнем с достоинств, они широко известны:
🔹 Устраняет дефицит адресов на многие десятилетия вперед.
🔹 Позволяет избавиться от NAT, теперь каждое устройство включая лампочку или чайник будет иметь собственный адрес и полноценно общаться с интернетом.
🔹 Улучшится работа P2P технологий
🔹 Упрощается автоматическая настройка сети при помощи SLAAC
🔹 Лучшая производительность за счет отсутствия фрагментации и упрощения заголовков пакетов.
🔹 Упрощается структура сети, так как устройства теперь могут общаться напрямую без NAT, VPN, туннелей и т.п.
☝️ Все это понятно, интересно, прогрессивно. Но есть и недостатки.
Я специально потратил время и изучил профильные обсуждения на сетевых ресурсах. Из чего был выделен следующий список недостатков, которые больше всего беспокоят пользователей:
🔸 Отсутствие обратной совместимости, фактически «переход» на IPv6 будет означать одновременное использование двух стеков. А это увеличение затрат на администрирование, повышенная нагрузка на оборудование и ухудшение безопасности за счет увеличения поверхности атаки.
🔸 При смене провайдера поплывет вся адресация сети, чтобы избежать этого придумано
IPv6 Network Prefix Translation (NPt), и это (внезапно 😉) по принципу работы тот же NAT🔸 Безопасность. NAT позволяет эффективно закрыть сегмент сети от интернета и даже при ошибках настройки брандмауэра внутренние узлы не оказывались выставлены во внешнюю сеть. В случае IPv6 требуется гораздо более грамотная и вдумчивая настройка правил межсетевого экрана.
🤔 При этом каких-либо явных преимуществ пользовательским сетям (мы не рассматриваем провайдеров, телеком, датацентры и т.п.) IPv6 не дает. А фактически усложняет сеть за счет двух независимых друг от друга настроек, так как IPv4 никуда не делся и жить на два стека придется еще очень долго.
👍56🤡1
Тонкие настройки LXC. Память
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
/etc/pve/lxc/nnn.conf (где nnn – ID контейнера) указывается просто выделенный объем памяти, а вот если мы заглянем в настоящий конфиг LXC в /var/lib/lxc/nnn/config, то увидим там две директивы (для контейнера с 4 ГБ памяти):lxc.cgroup2.memory.max = 4294967296
lxc.cgroup2.memory.high = 4261412864
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
lxc.cgroup2.memory.low
lxc.cgroup2.memory.min
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
👍40👀1
Сколько месяцев ты ещё будешь сидеть без работы, пока другие получают офферы в IT?
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Как узнать все смонтированные файловые системы?
Раньше можно было сказать: загляните в
Можно использовать команду
Но есть способ лучше -
А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
Раньше можно было сказать: загляните в
/etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.Можно использовать команду
mount, но ее вывод недостаточно удобочитаем.Но есть способ лучше -
findmnt, данная команда выведет все смонтированные файловые системы в удобном древообразном виде.А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
--real. Чтобы получить больше информации воспользуйтесь ключом --help.
👍68
Секта свидетелей чего-то там
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
💯49👍22🤣14🤡9⚡3
Девушки в IT
Вас немного – но вы есть и с каждым годом вас становиться больше. Поэтому в этот день позвольте поздравить вас и пожелать всего самого светлого.
В первую очередь любви, любите и будьте любимыми и не забывайте радовать нас цветами любви – детьми. Это высший дар и награда для нас, суровых админов и прочих специалистов который кроме вас никто не сможет преподнести.
Затем – здоровья (его не купишь), цветите и будьте всегда бодрыми и радостными, вдохновляя нас на свершения для вас.
Ну и мирного нам всем неба над головой, этого тоже не купить, но это тоже очень важно. Жители приграничья меня поймут.
В общем милые дамы, с вами трудно, без вас совсем никуда. С праздником Вас, будьте любимы и счастливы. А мы для этого постараемся.
Вас немного – но вы есть и с каждым годом вас становиться больше. Поэтому в этот день позвольте поздравить вас и пожелать всего самого светлого.
В первую очередь любви, любите и будьте любимыми и не забывайте радовать нас цветами любви – детьми. Это высший дар и награда для нас, суровых админов и прочих специалистов который кроме вас никто не сможет преподнести.
Затем – здоровья (его не купишь), цветите и будьте всегда бодрыми и радостными, вдохновляя нас на свершения для вас.
Ну и мирного нам всем неба над головой, этого тоже не купить, но это тоже очень важно. Жители приграничья меня поймут.
В общем милые дамы, с вами трудно, без вас совсем никуда. С праздником Вас, будьте любимы и счастливы. А мы для этого постараемся.
👍25👏3⚡2🫡1
Больше никаких долгих внедрений и дорогих разработок. 12 марта в 11:00 мы покажем, как платформа Low-code/No-code помогает компаниям ускорить цифровую трансформацию.
🔥 Вы узнаете:
✅ Как мы прошли путь от идеи до запуска на примере кейса «Элемент Лизинг».
✅ Как выбрать LCNC-платформу, которая идеально подойдет вашему бизнесу.
✅ Какие практические шаги мешают цифровой трансформации — и как их устранить.
✅ Как инструменты ELMA365 позволяют запускать процессы в 5 раз быстрее.
📅 Дата и время: 12 марта, 11:00 (МСК)
💰 Стоимость участия: Бесплатно
📢 Этот вебинар для вас, если вы:
✔️ Хотите масштабировать бизнес без лишних затрат.
✔️ Директор по стратегии или ИТ, который ищет эффективные решения.
✔️ Просто устали от долгих и дорогих разработок.
Не откладывайте цифровую трансформацию!
👉 Регистрируйтесь
🔥 Вы узнаете:
✅ Как мы прошли путь от идеи до запуска на примере кейса «Элемент Лизинг».
✅ Как выбрать LCNC-платформу, которая идеально подойдет вашему бизнесу.
✅ Какие практические шаги мешают цифровой трансформации — и как их устранить.
✅ Как инструменты ELMA365 позволяют запускать процессы в 5 раз быстрее.
📅 Дата и время: 12 марта, 11:00 (МСК)
💰 Стоимость участия: Бесплатно
📢 Этот вебинар для вас, если вы:
✔️ Хотите масштабировать бизнес без лишних затрат.
✔️ Директор по стратегии или ИТ, который ищет эффективные решения.
✔️ Просто устали от долгих и дорогих разработок.
Не откладывайте цифровую трансформацию!
👉 Регистрируйтесь
Мы думали, что РОСА уже все и новостей не было от них очень давно. А оказывается еще не все, в конце февраля без лишнего шума и пыли выкатили новый релиз.
Свежий Фреш на новой платформе:
🔹 Теперь по-русски, не ROSA FRESH а РОСА Фреш.
🔹Упрощенная нумерация, мажорный номер версии фреша совпадает с номером платформы.
🔹Новейшие версии библиотек и пользовательских программ.
ядро 6.12 LTS для поддержки новой аппаратуры.
🔹glibc 2.20 для совместимости с переносимыми приложениями.
🔹systemd 256 — современная система управления службами.
🔹Обновленный дизайн в традиционной цветовой гамме.
🔹Базовая поддержка китайского и арабского языков.
Свежий Фреш на новой платформе:
🔹 Теперь по-русски, не ROSA FRESH а РОСА Фреш.
🔹Упрощенная нумерация, мажорный номер версии фреша совпадает с номером платформы.
🔹Новейшие версии библиотек и пользовательских программ.
ядро 6.12 LTS для поддержки новой аппаратуры.
🔹glibc 2.20 для совместимости с переносимыми приложениями.
🔹systemd 256 — современная система управления службами.
🔹Обновленный дизайн в традиционной цветовой гамме.
🔹Базовая поддержка китайского и арабского языков.
👍37🤣9🤔2❤1👎1
Новая РОСА Фреш при ближайшем рассмотрении вызывает только недоумение. Постоянно терзает мысль – а для кого это и зачем?
Изначально Роса получила отличный задел в виде наследства Mandriva, со всеми вытекающими. Но практически все это было бесполезно растрачено. Если Mandrake, а затем и Mandriva были дистрибутивами самобытными, то РОСА практически потеряла какую-либо уникальность, став просто еще одним дистрибутивом.
Родных для экосистемы утилит и программ drake для управления системой почти не осталось, а те, что остались давно устарели. Свой пакетный менеджер заменен на DNF. Чего-то своего тоже не появилось.
Сам Фреш позиционируется как домашний дистрибутив, об этом говорит как схема разбивки диска, так и набор поставляемого софта. Но вменяемые инструменты управления софтом в графическом режиме отсутствуют, магазин так и не завезли. Интеграции со Snap и Flatpak нет.
Кому это нужно домой? Зачем? В офис, посмотреть? Но тоже зачем? Документация куцая, распространенность слабая.
Изначально Роса получила отличный задел в виде наследства Mandriva, со всеми вытекающими. Но практически все это было бесполезно растрачено. Если Mandrake, а затем и Mandriva были дистрибутивами самобытными, то РОСА практически потеряла какую-либо уникальность, став просто еще одним дистрибутивом.
Родных для экосистемы утилит и программ drake для управления системой почти не осталось, а те, что остались давно устарели. Свой пакетный менеджер заменен на DNF. Чего-то своего тоже не появилось.
Сам Фреш позиционируется как домашний дистрибутив, об этом говорит как схема разбивки диска, так и набор поставляемого софта. Но вменяемые инструменты управления софтом в графическом режиме отсутствуют, магазин так и не завезли. Интеграции со Snap и Flatpak нет.
Кому это нужно домой? Зачем? В офис, посмотреть? Но тоже зачем? Документация куцая, распространенность слабая.
👀11🤔10🔥4🤣3🥱1
Устали от ограничений и долгой настройки серверов? High-speed VDS поможет в работе!
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса
👍3❤1👀1
Блеск и нищета FreeBSD
Разработчики FreeBSD опубликовали отчёт о развитии за четвёртый квартал 2024 года, в котором упомянут проект bsd-user-4-linux, развивающий инструментарий для запуска в Linux приложений, собранных для FreeBSD.
Целью проекта заявлена возможность собирать пакеты для FreeBSD в Linux, используя родной сборочный инструментарий FreeBSD.
Для запуска исполняемых файлов FreeBSD задействован форк эмулятора QEMU. В данном режиме QEMU выполняет трансляцию системных вызовов и обработку сигналов.
Для запуска приложений требуется развёртывание в локальном каталоге библиотек и настроек из базовой системы FreeBSD. Проект можно рассматривать как обратный аналог Linuxulator.
На текущем этапе разработки работает запуск основных системных утилит (sh, bash, find, grep, git, clang и т.п.), поддерживается динамическое связывание и разделяемые библиотеки, доступны сетевые функции.
Например, уже можно пересобрать FreeBSD находясь в Linux. Из отсутствующей функциональности отмечается невозможность запуска отладчика GDB, недоступность IPC, и ряда системных вызовов.
А теперь переведем это на обычный язык – дела у FreeBSD идут настолько неважно, что сами разработчики BSD не пользуются своей системой и вместо того, чтобы хоть как-то развивать ее тратят и без того скудное финансирование на разработку подобных костылей.
При этом жизнь, похоже, ничему не учит «строителей величественного собора», которые в начале десятых уступили Linux серверный рынок, причем уступили по вполне объективным причинам, проспав технологический прогресс.
Далее бездарно проспали наследство Sun в виде ZFS, которая могла бы стать киллер-фичей и снова сделать систему конкурентной. Но увы, в настоящий момент развитием этой файловой системы занимается OpenZFS, которая разрабатывает ее в первую очередь в интересах Linux.
В целом перспективы у FreeBSD более чем туманные, что еще держит проект на плаву и привлекает финансирование – так это то, что этот код можно просто взять и закрыть, ничего не возвращая назад.
Этим активно пользуются многие, от Apple до Juniper и слышать от адептов FreeBSD отсылки к этим системам смешно. Так как никто не знает, что именно там взяли от BSD и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.
Разработчики FreeBSD опубликовали отчёт о развитии за четвёртый квартал 2024 года, в котором упомянут проект bsd-user-4-linux, развивающий инструментарий для запуска в Linux приложений, собранных для FreeBSD.
Целью проекта заявлена возможность собирать пакеты для FreeBSD в Linux, используя родной сборочный инструментарий FreeBSD.
Для запуска исполняемых файлов FreeBSD задействован форк эмулятора QEMU. В данном режиме QEMU выполняет трансляцию системных вызовов и обработку сигналов.
Для запуска приложений требуется развёртывание в локальном каталоге библиотек и настроек из базовой системы FreeBSD. Проект можно рассматривать как обратный аналог Linuxulator.
На текущем этапе разработки работает запуск основных системных утилит (sh, bash, find, grep, git, clang и т.п.), поддерживается динамическое связывание и разделяемые библиотеки, доступны сетевые функции.
Например, уже можно пересобрать FreeBSD находясь в Linux. Из отсутствующей функциональности отмечается невозможность запуска отладчика GDB, недоступность IPC, и ряда системных вызовов.
А теперь переведем это на обычный язык – дела у FreeBSD идут настолько неважно, что сами разработчики BSD не пользуются своей системой и вместо того, чтобы хоть как-то развивать ее тратят и без того скудное финансирование на разработку подобных костылей.
При этом жизнь, похоже, ничему не учит «строителей величественного собора», которые в начале десятых уступили Linux серверный рынок, причем уступили по вполне объективным причинам, проспав технологический прогресс.
Далее бездарно проспали наследство Sun в виде ZFS, которая могла бы стать киллер-фичей и снова сделать систему конкурентной. Но увы, в настоящий момент развитием этой файловой системы занимается OpenZFS, которая разрабатывает ее в первую очередь в интересах Linux.
В целом перспективы у FreeBSD более чем туманные, что еще держит проект на плаву и привлекает финансирование – так это то, что этот код можно просто взять и закрыть, ничего не возвращая назад.
Этим активно пользуются многие, от Apple до Juniper и слышать от адептов FreeBSD отсылки к этим системам смешно. Так как никто не знает, что именно там взяли от BSD и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.
😢19👍10🫡9🤔2👀2
Культура работы с сертификатами
А точнее ее полное отсутствие. Причем наблюдать это можно сплошь и рядом. Про наплевательское отношение с доступом к ним промолчим, это тема отдельной беседы, сегодня именно про культуру работы.
Пригласили нас тут третьего дня помочь настроить работу Честного знака и маркировки. Да не вопрос, точнее самый первый вопрос – это сертификаты, а там такое… В общем бардак полный, который вы можете увидеть на рисунке ниже.
И во всем этом безобразии только три живых сертификата, остальные просроченные, причем сильно просроченные. И ладно бы там не было собственного админа, так он там есть.
На наш вопрос – а что это за бардак он только вяло махнул рукой, мол ну его нафиг, сейчас тронь, а потом там что-то поломается, утомишься чинить. Причем чему там ломаться он так и не пояснил.
Это все говорит о крайне низкой культуре работы с сертификатами и понимания как это все устроено, что местами приводит практически к мистической боязни всего что с ними связано.
Поэтому давайте разберемся, что это за зверь такой «сертификат», мы не просто взяли это слово в кавычки. Но оно стало общеупотребимым, а из песни слов не выкинешь. Но любой технический специалист должен понимать, что, говоря «сертификат» мы понимаем ключевую пару.
Ключевая пара состоит из секретного закрытого ключа и общедоступного открытого, который дополненный дополнительной информацией о владельце, выпустившей стороне, назначениях использования и т.д. и т.п. и представляет тот самый сертификат.
Подробнее о том, как это все работает и почему открытый ключ можно передавать, а закрытый нужно хранить в секрете можно прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.
Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.
Для того, чтобы мы могли работать с этой ключевой парой нам нужно установить сертификат в системное хранилище сертификатов. При этом вместе с сертификатом будет прописано расположение закрытого ключа.
Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.
Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.
Удаляя сертификат из системы, мы только делаем его недоступным для прикладного ПО, физически он как был в своем контейнере, так и остается, при необходимости мы всегда можем установить его снова.
Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.
После того, как срок действия сертификата закончился – он превратился в тыкву, в прямом смысле этого слова. Также в тыкву он может превратиться и ранее этого срока, если вы перевыпустили сертификат, не дожидаясь его окончания.
Держать их установленными нет никакого смысла, это не дает никаких плюсов, а только запутывает и делает работу крайне неудобной, в любом личном кабинете, куда вы входите по сертификату вместо трех вариантов входа, будет в нашем случае 13.
Аналогичная картина будет и при подписании, где вместо одного сертификата на организацию будет всплывать целая стопка.
Поэтому просроченный сертификат из системы нужно сразу удалять. Никаких негативных последствий это не несет и нести не может.
Зато сразу повысится удобство работы и значительно улучшится диагностика возможных проблем работы с сертификатами.
А точнее ее полное отсутствие. Причем наблюдать это можно сплошь и рядом. Про наплевательское отношение с доступом к ним промолчим, это тема отдельной беседы, сегодня именно про культуру работы.
Пригласили нас тут третьего дня помочь настроить работу Честного знака и маркировки. Да не вопрос, точнее самый первый вопрос – это сертификаты, а там такое… В общем бардак полный, который вы можете увидеть на рисунке ниже.
И во всем этом безобразии только три живых сертификата, остальные просроченные, причем сильно просроченные. И ладно бы там не было собственного админа, так он там есть.
На наш вопрос – а что это за бардак он только вяло махнул рукой, мол ну его нафиг, сейчас тронь, а потом там что-то поломается, утомишься чинить. Причем чему там ломаться он так и не пояснил.
Это все говорит о крайне низкой культуре работы с сертификатами и понимания как это все устроено, что местами приводит практически к мистической боязни всего что с ними связано.
Поэтому давайте разберемся, что это за зверь такой «сертификат», мы не просто взяли это слово в кавычки. Но оно стало общеупотребимым, а из песни слов не выкинешь. Но любой технический специалист должен понимать, что, говоря «сертификат» мы понимаем ключевую пару.
Ключевая пара состоит из секретного закрытого ключа и общедоступного открытого, который дополненный дополнительной информацией о владельце, выпустившей стороне, назначениях использования и т.д. и т.п. и представляет тот самый сертификат.
Подробнее о том, как это все работает и почему открытый ключ можно передавать, а закрытый нужно хранить в секрете можно прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.
Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.
Для того, чтобы мы могли работать с этой ключевой парой нам нужно установить сертификат в системное хранилище сертификатов. При этом вместе с сертификатом будет прописано расположение закрытого ключа.
Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.
Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.
Удаляя сертификат из системы, мы только делаем его недоступным для прикладного ПО, физически он как был в своем контейнере, так и остается, при необходимости мы всегда можем установить его снова.
Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.
После того, как срок действия сертификата закончился – он превратился в тыкву, в прямом смысле этого слова. Также в тыкву он может превратиться и ранее этого срока, если вы перевыпустили сертификат, не дожидаясь его окончания.
Держать их установленными нет никакого смысла, это не дает никаких плюсов, а только запутывает и делает работу крайне неудобной, в любом личном кабинете, куда вы входите по сертификату вместо трех вариантов входа, будет в нашем случае 13.
Аналогичная картина будет и при подписании, где вместо одного сертификата на организацию будет всплывать целая стопка.
Поэтому просроченный сертификат из системы нужно сразу удалять. Никаких негативных последствий это не несет и нести не может.
Зато сразу повысится удобство работы и значительно улучшится диагностика возможных проблем работы с сертификатами.
👍52❤3🤔3🤡2👎1
👍7🤣3
Режимы запуска bash
Для того, чтобы правильно ответить на вопрос «что не так сделал Вася» следует понимать контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
Кроме того,
Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной BASH_ENV среды окружения (если задан).
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
Для того, чтобы правильно ответить на вопрос «что не так сделал Вася» следует понимать контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
/etc/profile и один из файлов: ~/.bash_profile, ~/.bash_login или ~/.profile который будет найден первым при поиске в указанном порядке.Кроме того,
/etc/profile считывает файлы /etc/profile.d/*.sh и /etc/bash.bashrc, а : ~/.bash_profile содержит указание на исполнение файла ~/.bashrc.Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
~/.bash_profile и общие из /etc/bash.bashrc. Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
bash -с или bash имя_скрипта, а также при вызове команд и скриптов системными процессами, тем же cron.Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной BASH_ENV среды окружения (если задан).
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
./my_script.sh используйте bash my_script.sh.В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
👍54🤮2❤1