Что случилось с Мистой?
Форум mista.ru, он же «Волшебный форум», он же «Мистинский зверсовхоз» представлять не нужно, он нем знает любой, кто хоть немного погружен в тему 1С.
Это одно из старейших и крупнейших неофициальных сообществ по 1С:Предприятие в Рунете, которое ведет свою историю с далекого и светлого 2003 года.
Как и всякие сообщества того времени Миста оказалась местом весьма специфичным, токсичным и крайне недружелюбным. Что во многом было обеспечено личными качествами и амбициями владельца форума.
На Мисте могли послать, затравить, забанить за любой неудобный или просто неуместный вопрос. Нравы там были на уровне сельского клуба, где есть первый парень на деревне, его прихлебатели и все остальные.
Но как бы мы не относились к Мисте и ее основателю лично, следует признать, что это одно из крупнейших сообществ по 1С и огромная, хотя и не структурированная, база знаний.
Если вы зададите в поиске запрос касающийся 1С, то с очень большой вероятностью получите ссылку на Мисту и вполне возможно найдете там ответ на свой вопрос. И вам в этот момент все равно, насколько токсично это сообщество. вы в нем не общаетесь, а готовый ответ реально способен помочь.
Я не участник этого сообщества, но время от времени находил там интересующую меня информацию. А информации много не бывает, особенно если она не в пересказе, а из первых рук практикующих 1С-специалистов.
И вот недавно в профильных сообществах пошло обсуждение того, что Миста не работает. Действительно, сайт недоступен, но никаких комментариев и пояснений от владельца ресурса нет.
Слухи и домыслы ходят всякие разные, кто-то говорит, что на сервере посыпались диски, кто-то про финансовые проблемы. Но в любом случае молчаливый уход в оффлайн форума с более чем 20-летней историей вызывает вопросы.
И тут самое время обратиться к событиям ноября 2025 года, когда владелец Мисты получил претензию от АО «КМ» (представитель 1С по защите прав), которая требовала удалить все страницы с упоминанием торговой марки 1С.
По факту это означало закрытие форума, так как если на форуме про 1С убрать любое упоминание 1С, то что там останется? Курилка и флудилка?
Проигнорировать? Ну тоже такое себе, потому как штрафы там до 5 млн. руб. и платить их придется владельцу форума из своего кармана.
Возможно, именно это и стало причиной ухода Мисты в оффлайн. Но если это действительно так, то действия 1С становятся сильно непонятны. Компания последнее время активно вкладывается в сообщество: комьюнити-лицензии, портал разработчиков, официальные чаты…
А тут раз и убили крупнейшее сообщество лояльных компании пользователей…
Хотя, возможно, мы чего-то не знаем. Возможно цель – это взятие под контроль информационного поля. Потому что после ухода Мисты крупных независимых комьюнити не остается.
Инфостарт на 50% принадлежит компании 1С и колеблется вместе с линией партии, все остальное по масштабам недотягивает.
Но несмотря ни на что, надеемся, что Миста, какая бы она не была, к нам вернется. Иначе нас ждет сильно нехороший прецендент. Хотя, если честно, они уже были и тот же Инфостарт в свое время выдавливал конкурентов далеко не рыночными способами.
Но это уже совсем другая история…
Форум mista.ru, он же «Волшебный форум», он же «Мистинский зверсовхоз» представлять не нужно, он нем знает любой, кто хоть немного погружен в тему 1С.
Это одно из старейших и крупнейших неофициальных сообществ по 1С:Предприятие в Рунете, которое ведет свою историю с далекого и светлого 2003 года.
Как и всякие сообщества того времени Миста оказалась местом весьма специфичным, токсичным и крайне недружелюбным. Что во многом было обеспечено личными качествами и амбициями владельца форума.
На Мисте могли послать, затравить, забанить за любой неудобный или просто неуместный вопрос. Нравы там были на уровне сельского клуба, где есть первый парень на деревне, его прихлебатели и все остальные.
Но как бы мы не относились к Мисте и ее основателю лично, следует признать, что это одно из крупнейших сообществ по 1С и огромная, хотя и не структурированная, база знаний.
Если вы зададите в поиске запрос касающийся 1С, то с очень большой вероятностью получите ссылку на Мисту и вполне возможно найдете там ответ на свой вопрос. И вам в этот момент все равно, насколько токсично это сообщество. вы в нем не общаетесь, а готовый ответ реально способен помочь.
Я не участник этого сообщества, но время от времени находил там интересующую меня информацию. А информации много не бывает, особенно если она не в пересказе, а из первых рук практикующих 1С-специалистов.
И вот недавно в профильных сообществах пошло обсуждение того, что Миста не работает. Действительно, сайт недоступен, но никаких комментариев и пояснений от владельца ресурса нет.
Слухи и домыслы ходят всякие разные, кто-то говорит, что на сервере посыпались диски, кто-то про финансовые проблемы. Но в любом случае молчаливый уход в оффлайн форума с более чем 20-летней историей вызывает вопросы.
И тут самое время обратиться к событиям ноября 2025 года, когда владелец Мисты получил претензию от АО «КМ» (представитель 1С по защите прав), которая требовала удалить все страницы с упоминанием торговой марки 1С.
По факту это означало закрытие форума, так как если на форуме про 1С убрать любое упоминание 1С, то что там останется? Курилка и флудилка?
Проигнорировать? Ну тоже такое себе, потому как штрафы там до 5 млн. руб. и платить их придется владельцу форума из своего кармана.
Возможно, именно это и стало причиной ухода Мисты в оффлайн. Но если это действительно так, то действия 1С становятся сильно непонятны. Компания последнее время активно вкладывается в сообщество: комьюнити-лицензии, портал разработчиков, официальные чаты…
А тут раз и убили крупнейшее сообщество лояльных компании пользователей…
Хотя, возможно, мы чего-то не знаем. Возможно цель – это взятие под контроль информационного поля. Потому что после ухода Мисты крупных независимых комьюнити не остается.
Инфостарт на 50% принадлежит компании 1С и колеблется вместе с линией партии, все остальное по масштабам недотягивает.
Но несмотря ни на что, надеемся, что Миста, какая бы она не была, к нам вернется. Иначе нас ждет сильно нехороший прецендент. Хотя, если честно, они уже были и тот же Инфостарт в свое время выдавливал конкурентов далеко не рыночными способами.
Но это уже совсем другая история…
🤔33🤬7😢7👎5🤮3
❓Вопрос: будет ли работать PPP-туннель с такой адресацией?
✅ Ответ: будет, причем без всяких оговорок.
Почему? Потому что PPP (Point-to-Point Protocol) — двухточечный протокол канального уровня. Канального, т.е. L2 модели OSI. Поэтому для его работы, точно также как и для работы Ethernet IP-адреса не нужны.
IP-адреса – это уже следующий уровень модели OSI – L3 (сетевой). Поэтому любой кадр (именно кадр, а не пакет) попавший на одну сторону PPP-туннеля будет просто доставлен на другой, вне зависимости от его полезной нагрузки.
Таким образом для работы туннелей PPP нет никакой необходимости в IP-адресах вообще.
Но для чего тогда мы присваиваем конечным точкам туннелей IP-адреса? Для работы приложений сетевого уровня, например, чтобы мы могли пропинговать конец туннеля или указать его в качестве шлюза.
Какие адреса вы там будете использовать – туннелю абсолютно все равно, можете указать адреса из разных сетей и вообще разных диапазонов – все будет работать.
Тем более что такая возможность широко используется, например, при резервировании каналов и балансировке, когда вам нужно явно указать маршруты трафика для каждого из каналов, а на одном из них у вас PPPoE с динамическими адресами.
В этом случае просто вешаете на противоположную часть туннеля произвольный адрес и указываете его в качестве шлюза.
Как это работает? Просто. Маршрутизация – это процесс определения нужного интерфейса выхода, а когда мы его определили, благодаря нашему адресу, в дело вступит протокол PPP, который на канальном уровне доставит кадры туда, куда нужно.
✅ Ответ: будет, причем без всяких оговорок.
Почему? Потому что PPP (Point-to-Point Protocol) — двухточечный протокол канального уровня. Канального, т.е. L2 модели OSI. Поэтому для его работы, точно также как и для работы Ethernet IP-адреса не нужны.
IP-адреса – это уже следующий уровень модели OSI – L3 (сетевой). Поэтому любой кадр (именно кадр, а не пакет) попавший на одну сторону PPP-туннеля будет просто доставлен на другой, вне зависимости от его полезной нагрузки.
Таким образом для работы туннелей PPP нет никакой необходимости в IP-адресах вообще.
Но для чего тогда мы присваиваем конечным точкам туннелей IP-адреса? Для работы приложений сетевого уровня, например, чтобы мы могли пропинговать конец туннеля или указать его в качестве шлюза.
Какие адреса вы там будете использовать – туннелю абсолютно все равно, можете указать адреса из разных сетей и вообще разных диапазонов – все будет работать.
Тем более что такая возможность широко используется, например, при резервировании каналов и балансировке, когда вам нужно явно указать маршруты трафика для каждого из каналов, а на одном из них у вас PPPoE с динамическими адресами.
В этом случае просто вешаете на противоположную часть туннеля произвольный адрес и указываете его в качестве шлюза.
Как это работает? Просто. Маршрутизация – это процесс определения нужного интерфейса выхода, а когда мы его определили, благодаря нашему адресу, в дело вступит протокол PPP, который на канальном уровне доставит кадры туда, куда нужно.
👍20🔥9❤1👌1
Отправка системной почты через внешний почтовый сервер
В Linux системах вы будете постоянно сталкиваться с необходимостью отправки почты системных пользователей внешнему получателю. Исторически для этих целей был предназначен Sendmail – старейший MTA – агент отправки почты.
В современных системах Sendmail обычно не используется и является ссылкой на другие почтовые агенты, например, Postfix.
Но реалии сегодняшнего дня таковы, что настройка собственного SMTP-сервера на служебных серверах не имеет никакого смысла. Требования к добросовестному отправителю почты сегодня весьма велики, и ваш отправитель скорее всего попадет в спам у всех публичных и непубличных почтовых сервисов.
Можно, конечно, настроить все правильно, но это достаточно затратно и неоправданно для рабочих серверов. Поэтому более универсальным решением будет использовать внешние почтовые службы, публичные или собственные.
Для этого нам нужно будет передать системную почту специальному почтовому клиенту (MUA), который, с одной стороны, будет имитировать стандартный Sendmail, а на самом деле работать в роли почтового клиента, отправляя почту через внешние сервера.
Одним из таких приложений является SSMTP, который прозрачно заменяет sendmail и позволяет отправлять системную почту через внешний почтовый сервер.
Установим его:
Затем откроем файл /etc/ssmtp/ssmtp.conf и приступим к редактированию параметров, благо их немного.
Сначала укажем получателя для системной почты (все пользователи с идентификаторами < 1000):
Если вы не хотите выполнять перенаправление, то оставьте эту опцию пустой.
Разрешим изменять отправителя в поле From, для этого раскомментируйте и приведите к следующему виду опцию:
Если этого не сделать, то система будет отправлять письма от имени root@hostname, которые будут отклоняться почтовым сервером.
В некоторых случаях вам потребуется правильно указать в опции hostname имя хоста, желательно FQDN, но в большинстве случаев все работает с автоматически подставленным туда значением.
Это были общие параметры, а теперь настроим работу с почтовыми службами.
В общем виде настройка выглядит так:
Настройки достаточно простые и не требуют подробных пояснений. В опции mailhub указываем адрес и порт почтового сервера, ниже идут учетные данные и параметры шифрования.
Теперь создадим алиасы, чтобы системные пользователи могли отправлять почту через ssmtp. Для этого откроем /etc/ssmtp/revaliases и внесем туда следующую строку:
Это означает что пользователю root соответствует аккаунт my_account@example.com на сервере smtp.example.com:587 и отправку почты следует производить через него.
Секций mailhub в конфигурационном файле может быть несколько, и разные пользователи могут отправлять почту через разные системные записи.
Для проверки выполните:
После чего вы должны получить на указанную почту тестовое письмо.
В случае ошибки полезно будет выполнить отладку с получением логов обмена с почтовым сервером, для этого немного изменим команду отправки почты:
Теперь весь обмен с сервером как на ладони, что позволяет быстро найти и исправить возможные ошибки настройки.
В Linux системах вы будете постоянно сталкиваться с необходимостью отправки почты системных пользователей внешнему получателю. Исторически для этих целей был предназначен Sendmail – старейший MTA – агент отправки почты.
В современных системах Sendmail обычно не используется и является ссылкой на другие почтовые агенты, например, Postfix.
Но реалии сегодняшнего дня таковы, что настройка собственного SMTP-сервера на служебных серверах не имеет никакого смысла. Требования к добросовестному отправителю почты сегодня весьма велики, и ваш отправитель скорее всего попадет в спам у всех публичных и непубличных почтовых сервисов.
Можно, конечно, настроить все правильно, но это достаточно затратно и неоправданно для рабочих серверов. Поэтому более универсальным решением будет использовать внешние почтовые службы, публичные или собственные.
Для этого нам нужно будет передать системную почту специальному почтовому клиенту (MUA), который, с одной стороны, будет имитировать стандартный Sendmail, а на самом деле работать в роли почтового клиента, отправляя почту через внешние сервера.
Одним из таких приложений является SSMTP, который прозрачно заменяет sendmail и позволяет отправлять системную почту через внешний почтовый сервер.
Установим его:
apt install ssmtp mailutils
Затем откроем файл /etc/ssmtp/ssmtp.conf и приступим к редактированию параметров, благо их немного.
Сначала укажем получателя для системной почты (все пользователи с идентификаторами < 1000):
root = admin@examlpe.com
Если вы не хотите выполнять перенаправление, то оставьте эту опцию пустой.
Разрешим изменять отправителя в поле From, для этого раскомментируйте и приведите к следующему виду опцию:
FromLineOverride=YES
Если этого не сделать, то система будет отправлять письма от имени root@hostname, которые будут отклоняться почтовым сервером.
В некоторых случаях вам потребуется правильно указать в опции hostname имя хоста, желательно FQDN, но в большинстве случаев все работает с автоматически подставленным туда значением.
Это были общие параметры, а теперь настроим работу с почтовыми службами.
В общем виде настройка выглядит так:
mailhub=smtp.example.com:587
AuthUser=my_account@example.com
AuthPass=mY_pa$$word_1
UseTLS=YES
UseSTARTTLS=YES
TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt
Настройки достаточно простые и не требуют подробных пояснений. В опции mailhub указываем адрес и порт почтового сервера, ниже идут учетные данные и параметры шифрования.
Теперь создадим алиасы, чтобы системные пользователи могли отправлять почту через ssmtp. Для этого откроем /etc/ssmtp/revaliases и внесем туда следующую строку:
root:my_account@example.com:smtp.example.com:587
Это означает что пользователю root соответствует аккаунт my_account@example.com на сервере smtp.example.com:587 и отправку почты следует производить через него.
Секций mailhub в конфигурационном файле может быть несколько, и разные пользователи могут отправлять почту через разные системные записи.
Для проверки выполните:
echo "Test" | mail -s "Test" admin@example.com
После чего вы должны получить на указанную почту тестовое письмо.
В случае ошибки полезно будет выполнить отладку с получением логов обмена с почтовым сервером, для этого немного изменим команду отправки почты:
echo "Test" | ssmtp -v -s "Test" admin@example.com
Теперь весь обмен с сервером как на ладони, что позволяет быстро найти и исправить возможные ошибки настройки.
3👍49❤6🥱1
Перенос почтовых ящиков между серверами при помощи imapsync
Переход на новую почтовую систему немыслим без переноса уже существующей почты, так как у многих пользователей там скопилось немало ценной информации, зачастую заботливо разложенной по достаточно сложной структуре директорий.
Все это требуется не только сохранить, но перенести с наименьшими неудобствами. А если ящиков много, то безусловно хочется автоматизировать эту процедуру. Справиться с этой задачей нам поможет imapsync - простая, но в тоже время мощная утилита для миграции почтовых ящиков по протоколу IMAP.
Основное преимущество imapsync - это то, что ее не нужно устанавливать на почтовый сервер и, скажем больше, мы не советуем этого делать. Почему? Утилита написана на Perl и для работы требует достаточно много библиотек и зависимостей, засорять которыми сервер очень не хотелось бы, тем более что задача, по сути, одноразовая.
Поэтому лучше всего использовать отдельный ПК на Linux, виртуалку или контейнер. Из DEB-систем поддерживаются Debian и Ubuntu, хотя утилита будет работать в любой системе, если вы, конечно, обеспечите ей все необходимые библиотеки. В нашем случае будет использоваться рабочий ПК на Debian.
✅ Читать далее
Переход на новую почтовую систему немыслим без переноса уже существующей почты, так как у многих пользователей там скопилось немало ценной информации, зачастую заботливо разложенной по достаточно сложной структуре директорий.
Все это требуется не только сохранить, но перенести с наименьшими неудобствами. А если ящиков много, то безусловно хочется автоматизировать эту процедуру. Справиться с этой задачей нам поможет imapsync - простая, но в тоже время мощная утилита для миграции почтовых ящиков по протоколу IMAP.
Основное преимущество imapsync - это то, что ее не нужно устанавливать на почтовый сервер и, скажем больше, мы не советуем этого делать. Почему? Утилита написана на Perl и для работы требует достаточно много библиотек и зависимостей, засорять которыми сервер очень не хотелось бы, тем более что задача, по сути, одноразовая.
Поэтому лучше всего использовать отдельный ПК на Linux, виртуалку или контейнер. Из DEB-систем поддерживаются Debian и Ubuntu, хотя утилита будет работать в любой системе, если вы, конечно, обеспечите ей все необходимые библиотеки. В нашем случае будет использоваться рабочий ПК на Debian.
✅ Читать далее
2👍32🥱1
Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
Любая современная система требует регулярного обновления и Linux не исключение, но как бы ни был организован этот процесс мы столкнемся с постоянной нагрузкой на канал и повышенным расходом трафика, так как каждый компьютер будет скачивать обновления самостоятельно из сети интернет.
При этом, даже если вас не волнует трафик, данный процесс занимает время и не всегда зеркала репозиториев отдают данные на хорошей скорости, поэтому становится актуальным создание локального кеша пакетов, в чем нам поможет Apt-Cacher NG. Его просто установить и еще проще использовать.
Apt-Cacher NG - кеширующий прокси-сервер, который становится посредником между клиентом и зеркалом репозитория и сохраняет в собственное хранилище все загруженные из сети пакеты.
При повторном запросе он проверит кеш и при наличии в нем требуемого пакета отдаст его локально. Это позволяет существенно экономить как трафик, так и время и последний фактор сегодня играет все более значимую роль.
Каких-то существенных требований к железу Apt-Cacher NG не предъявляет и прекрасно работает в виртуальной машине или контейнере. Все что вам нужно - это выделить достаточное место для хранилища кеша пакетов.
Теоретически его размер может быть равен объему всех используемых репозиториев, но на практике запросы гораздо скромнее и зависят только от разнообразия систем и количества установленных в них пакетов.
Эффективность самого кеша зависит от однородности систем и их количества, чем более однородна инфраструктура и чем больше в ней однотипных ПК, тем больше будет попадания в кеш.
Но в любом случае эффект будет достигнут даже если у вас всего несколько машин, при крупных обновлениях все необходимые пакеты скачает первый компьютер, а остальные обновятся локально.
Первоначально Apt-Cacher NG поддерживал только DEB-пакеты, сегодня это универсальный прокси, который можно использовать с любыми пакетными системами, но это выходит за рамки данной статьи и ниже мы будем рассматривать его применение исключительно в среде Debian или Ubuntu.
✅ Читать далее
Любая современная система требует регулярного обновления и Linux не исключение, но как бы ни был организован этот процесс мы столкнемся с постоянной нагрузкой на канал и повышенным расходом трафика, так как каждый компьютер будет скачивать обновления самостоятельно из сети интернет.
При этом, даже если вас не волнует трафик, данный процесс занимает время и не всегда зеркала репозиториев отдают данные на хорошей скорости, поэтому становится актуальным создание локального кеша пакетов, в чем нам поможет Apt-Cacher NG. Его просто установить и еще проще использовать.
Apt-Cacher NG - кеширующий прокси-сервер, который становится посредником между клиентом и зеркалом репозитория и сохраняет в собственное хранилище все загруженные из сети пакеты.
При повторном запросе он проверит кеш и при наличии в нем требуемого пакета отдаст его локально. Это позволяет существенно экономить как трафик, так и время и последний фактор сегодня играет все более значимую роль.
Каких-то существенных требований к железу Apt-Cacher NG не предъявляет и прекрасно работает в виртуальной машине или контейнере. Все что вам нужно - это выделить достаточное место для хранилища кеша пакетов.
Теоретически его размер может быть равен объему всех используемых репозиториев, но на практике запросы гораздо скромнее и зависят только от разнообразия систем и количества установленных в них пакетов.
Эффективность самого кеша зависит от однородности систем и их количества, чем более однородна инфраструктура и чем больше в ней однотипных ПК, тем больше будет попадания в кеш.
Но в любом случае эффект будет достигнут даже если у вас всего несколько машин, при крупных обновлениях все необходимые пакеты скачает первый компьютер, а остальные обновятся локально.
Первоначально Apt-Cacher NG поддерживал только DEB-пакеты, сегодня это универсальный прокси, который можно использовать с любыми пакетными системами, но это выходит за рамки данной статьи и ниже мы будем рассматривать его применение исключительно в среде Debian или Ubuntu.
✅ Читать далее
👍19❤3🥱1
Уязвимости в MySQL и VirtualBox
Сегодня компания Oracle опубликовала плановый выпуск обновлений и заодно раскрыла ряд обнаруженных уязвимостей.
1️⃣ Наиболее критичными являются уязвимости MySQL, которых набралось 14 штук, две из них могут использоваться удаленно:
▫️ CVE-2025-6965 – уровень опасности 9,8. Связана с уязвимостью в библиотеке SQLite, которая используется во вспомогательных инструментах продукта.
▫️ CVE-2025-9230 -уровень опасности 7,5. Переполнение буфера в библиотеке OpenSSL.
Уязвимости устранены в выпусках MySQL Community Server 9.6.0 и 8.0.45.
Ввиду серьезности рекомендуется безотлагательно обновить используемые экземпляры MySQL или надежно изолировать их от внешней среды.
2️⃣ Второй уязвимый продукт – VirtualBox, уязвимостей тоже 14, пять из них опасные (уровень 8,2), одна может использоваться удаленно. Характер уязвимостей не раскрывается.
В данном случае все не так страшно, так как VirtualBox – средство настольной виртуализации, которое используется преимущественно в лабораторных и тестовых средах.
Однако если запущенные виртуальные машины имеют непосредственный доступ во внешний мир советуем также не затягивать с обновлением, выпуск VirtualBox 7.2.6 запланирован на сегодня, 21 января, в течении дня.
Сегодня компания Oracle опубликовала плановый выпуск обновлений и заодно раскрыла ряд обнаруженных уязвимостей.
1️⃣ Наиболее критичными являются уязвимости MySQL, которых набралось 14 штук, две из них могут использоваться удаленно:
▫️ CVE-2025-6965 – уровень опасности 9,8. Связана с уязвимостью в библиотеке SQLite, которая используется во вспомогательных инструментах продукта.
▫️ CVE-2025-9230 -уровень опасности 7,5. Переполнение буфера в библиотеке OpenSSL.
Уязвимости устранены в выпусках MySQL Community Server 9.6.0 и 8.0.45.
Ввиду серьезности рекомендуется безотлагательно обновить используемые экземпляры MySQL или надежно изолировать их от внешней среды.
2️⃣ Второй уязвимый продукт – VirtualBox, уязвимостей тоже 14, пять из них опасные (уровень 8,2), одна может использоваться удаленно. Характер уязвимостей не раскрывается.
В данном случае все не так страшно, так как VirtualBox – средство настольной виртуализации, которое используется преимущественно в лабораторных и тестовых средах.
Однако если запущенные виртуальные машины имеют непосредственный доступ во внешний мир советуем также не затягивать с обновлением, выпуск VirtualBox 7.2.6 запланирован на сегодня, 21 января, в течении дня.
👍15🥱1
Linux - начинающим. Учимся работать со Snap
Snap - это универсальный формат пакетов, созданный компанией Canonical первоначально для Ubuntu, но получивший широкое распространение и в других дистрибутивах. Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
В этой статье мы опишем основные приемы работы со snap для системного администратора и некоторые неочевидные особенности этой системы управления пакетами.
К сожалению, многие администраторы, как начинающие, так и опытные крайне негативно относятся к snap, доходя до того, что сразу же удаляют его из системы. При этом разумной аргументации этих действий ими не предоставляется. На наш взгляд - это непрофессиональный подход, хороший специалист не ставит искусственных ограничений для применяемых технологий и умеет играть от сильных сторон, нивелируя слабые.
Перед тем, как рассматривать работу со snap мы сделаем краткое отступление и рассмотрим причины, приведшие к появлению snap и аналогичных ему форматов, таких как flatpak или appimage. Традиционно софт в Linux распространяется по принципу конструктора, когда все зависимости приложения являются отдельными пакетами или библиотеками и распространяются отдельно.
Таким образом, если библиотека нужна сразу нескольким приложениям, то нам достаточно скачать ее один раз и установить в систему. Если в библиотеке найдены ошибки, то достаточно быстро их исправить и выпустить обновление, авторам программ, которые используют эту библиотеку ничего дополнительно делать не надо.
Для централизованного управления ПО каждый дистрибутив имеет собственный репозиторий, который содержит базу пакетов, собранных именно для этой версии дистрибутива, проверенных на ошибки и является единым доверенным источником программ для системы.
И вот здесь появляются первые сложности. Количество даже основных дистрибутивов весьма велико, потому как у каждого из них на поддержке находятся сразу несколько выпусков, с разным составом базовой системы.
Поэтому разработчик ПО как правило не собирает бинарные пакеты, этим занимаются мейнтрейнеры дистрибутиовов, что вызывает определенные задержки между выходом нового релиза программы и ее появления в репозитории.
Но это еще не все. В промышленном применении используются дистрибутивы с долгосрочной поддержкой (LTS), которые гарантируют неизменность основной пакетной базы на протяжении всего срока поддержки, а следовательно, многие библиотеки к концу жизненного цикла успеют порядочно устареть.
Это хорошо для промышленного ПО и серьезных бизнес-систем, которые получают стабильное и предсказуемое окружение на заранее определенный период времени. Но это плохо для пользовательского ПО, особенно связанного с такими быстро развивающимися областями как интернет, мессенджеры, мультимедиа.
Классическая ситуация, когда разработчик для внедрения каких-то новых возможностей использует новую версию библиотеки, которая входит в конфликт с библиотеками LTS-версий дистрибутивов. В этом случае ожидать появления новых версий программы в официальных репозиториях скорее всего не стоит. Установка из сторонних источников, включая сторонние репозитории, PPA и просто пакеты, всегда связана с риском и потенциальным нарушением стабильности системы.
Snap и альтернативные ему технологии позволяют самому разработчику один раз выпустить универсальный пакет, который будет одинаково подходить для всех поддерживаемых систем. Это сразу снимает вопросы по скорости доставки ПО - пользователь может всегда использовать последнюю версию пакета, снимает риски нарушения безопасности и стабильности системы - все snap-приложения запускаются внутри изолированной от системы песочницы.
✅ Читать далее
Snap - это универсальный формат пакетов, созданный компанией Canonical первоначально для Ubuntu, но получивший широкое распространение и в других дистрибутивах. Главной особенностью snap-пакетов является их самодостаточность, они содержат как нужное приложение, так и все основные зависимости к нему, что ускоряет распространение приложений и снижает возможные конфликты с другим ПО.
В этой статье мы опишем основные приемы работы со snap для системного администратора и некоторые неочевидные особенности этой системы управления пакетами.
К сожалению, многие администраторы, как начинающие, так и опытные крайне негативно относятся к snap, доходя до того, что сразу же удаляют его из системы. При этом разумной аргументации этих действий ими не предоставляется. На наш взгляд - это непрофессиональный подход, хороший специалист не ставит искусственных ограничений для применяемых технологий и умеет играть от сильных сторон, нивелируя слабые.
Перед тем, как рассматривать работу со snap мы сделаем краткое отступление и рассмотрим причины, приведшие к появлению snap и аналогичных ему форматов, таких как flatpak или appimage. Традиционно софт в Linux распространяется по принципу конструктора, когда все зависимости приложения являются отдельными пакетами или библиотеками и распространяются отдельно.
Таким образом, если библиотека нужна сразу нескольким приложениям, то нам достаточно скачать ее один раз и установить в систему. Если в библиотеке найдены ошибки, то достаточно быстро их исправить и выпустить обновление, авторам программ, которые используют эту библиотеку ничего дополнительно делать не надо.
Для централизованного управления ПО каждый дистрибутив имеет собственный репозиторий, который содержит базу пакетов, собранных именно для этой версии дистрибутива, проверенных на ошибки и является единым доверенным источником программ для системы.
И вот здесь появляются первые сложности. Количество даже основных дистрибутивов весьма велико, потому как у каждого из них на поддержке находятся сразу несколько выпусков, с разным составом базовой системы.
Поэтому разработчик ПО как правило не собирает бинарные пакеты, этим занимаются мейнтрейнеры дистрибутиовов, что вызывает определенные задержки между выходом нового релиза программы и ее появления в репозитории.
Но это еще не все. В промышленном применении используются дистрибутивы с долгосрочной поддержкой (LTS), которые гарантируют неизменность основной пакетной базы на протяжении всего срока поддержки, а следовательно, многие библиотеки к концу жизненного цикла успеют порядочно устареть.
Это хорошо для промышленного ПО и серьезных бизнес-систем, которые получают стабильное и предсказуемое окружение на заранее определенный период времени. Но это плохо для пользовательского ПО, особенно связанного с такими быстро развивающимися областями как интернет, мессенджеры, мультимедиа.
Классическая ситуация, когда разработчик для внедрения каких-то новых возможностей использует новую версию библиотеки, которая входит в конфликт с библиотеками LTS-версий дистрибутивов. В этом случае ожидать появления новых версий программы в официальных репозиториях скорее всего не стоит. Установка из сторонних источников, включая сторонние репозитории, PPA и просто пакеты, всегда связана с риском и потенциальным нарушением стабильности системы.
Snap и альтернативные ему технологии позволяют самому разработчику один раз выпустить универсальный пакет, который будет одинаково подходить для всех поддерживаемых систем. Это сразу снимает вопросы по скорости доставки ПО - пользователь может всегда использовать последнюю версию пакета, снимает риски нарушения безопасности и стабильности системы - все snap-приложения запускаются внутри изолированной от системы песочницы.
✅ Читать далее
👍17🤮10❤3🤔3👀1
Что ждет рынок компьютерных комплектующих в 2026 году?
Ответим сразу – ничего хорошего. Причина одна – бум искусственного интеллекта и связанный с ним дефицит памяти.
Так в декабре прошлого года компания Micron заявила о закрытии своего бренда Crucial, чтобы сосредоточится на поставках памяти и SSD для компаний искусственного интеллекта.
А бренд Crucial, на минуточку, был запущен в 1996 году и благополучно просуществовал на рынке 30 лет, заработав отличную репутацию, но сегодня резко оказался не нужен.
Теперь уже компания Kioxia заявила, что весь объем производства на 2026 год уже выкуплен, но с небольшой оговоркой, что сохранит объемы, поставляемые некоторым южнокорейским партнерам. Но в целом можем смело сказать, что с потребительского рынка Kioxia тоже ушла.
Значительные объемы производства также уже выкуплены у Samsung и SK Hynix, хотя последние полностью уходить с потребительского рынка не планируют, хотя и рассматривают его как нечто второстепенное.
Производителей тоже можно понять. Потребительский рынок – дело хлопотное. Модельные ряды, линейки, новинки, маркетинг и все это в высококонкурентной среде с небольшой маржой. Тут выпустить что-то – это половина беды, важнее – продать.
А тут приходит ИИ-компания и говорит, мол давай я все, что ты сделаешь гарантированно выкуплю. Ну кто откажется от такой радости? Напомню, что компании продали не уже произведенную память, а объемы производства, т.е. то, что только собираются произвести.
Это гарантированная 100% загрузка мощностей с гарантированным выкупом всего произведенного объема, при работе на потребительский рынок о таком можно только мечтать.
Все это вылилось в резкий рост цен на память и твердотельные накопители, а в дальнейшем, по мере распродажи запасов нас ждет еще и товарный дефицит.
Надеяться на быстрое исправление ситуации не приходится, все производство 2026 года уже выкуплено, поэтому если что-то и начнет меняться, то не ранее 2027 года, но это очень наивные и чрезмерно оптимистичные предположения.
Но если бы дело касалось только памяти и накопителей. В реальности нас ожидают каскадные проблемы для всей отрасли в целом.
Уже сегодня производители материнских плат столкнулись с прогрессирующим падением спроса.
А это прямое следствие дефицита памяти, кому нужна материнская плата, если память для нее стоит неподъемных денег?
Исходя из этого прямо сейчас можно говорить об аналогичном падении спроса на процессоры. И этот список можно продолжать. Фактически мы говорим о падении спроса не только на отдельные комплектующие, но и на компьютеры целиком.
Падение объемов производства неизбежно выльется в рост цен, что запустит цепную реакцию. В результате достаточно сложно предугадать к какому балансу в итоге придут спрос и предложение, но можно твердо быть уверенным, что нас ожидает эпоха высоких цен.
Текущие события снова отбрасывают компьютерный рынок в состояние, когда компьютер был дорогим и доступным далеко не всем, а не утилитарной вещью, как к этому привыкли сейчас.
Дефицит таже затронет и рынок б/у комплектующих, где сейчас особую популярность имеют китайские Xeon и недорогая DDR3 к ним. Наивно думать, что в эпоху глобального роста цен и сокращения предложения не произойдет коррекции этого сегмента рынка.
В общем, ближайшие перспективы не радостные и кто не успел, тот еще не опоздал. Да, текущие цены психологически и экономически неприятны, но это только начало, плюс рынок пока еще насыщен остатками производства.
Грубо говоря, сейчас продукция хоть и дорогая, но есть, а вот вскоре ее вообще может не оказаться на прилавках, а то, что останется явно совсем не порадует ценой.
Ответим сразу – ничего хорошего. Причина одна – бум искусственного интеллекта и связанный с ним дефицит памяти.
Так в декабре прошлого года компания Micron заявила о закрытии своего бренда Crucial, чтобы сосредоточится на поставках памяти и SSD для компаний искусственного интеллекта.
А бренд Crucial, на минуточку, был запущен в 1996 году и благополучно просуществовал на рынке 30 лет, заработав отличную репутацию, но сегодня резко оказался не нужен.
Теперь уже компания Kioxia заявила, что весь объем производства на 2026 год уже выкуплен, но с небольшой оговоркой, что сохранит объемы, поставляемые некоторым южнокорейским партнерам. Но в целом можем смело сказать, что с потребительского рынка Kioxia тоже ушла.
Значительные объемы производства также уже выкуплены у Samsung и SK Hynix, хотя последние полностью уходить с потребительского рынка не планируют, хотя и рассматривают его как нечто второстепенное.
Производителей тоже можно понять. Потребительский рынок – дело хлопотное. Модельные ряды, линейки, новинки, маркетинг и все это в высококонкурентной среде с небольшой маржой. Тут выпустить что-то – это половина беды, важнее – продать.
А тут приходит ИИ-компания и говорит, мол давай я все, что ты сделаешь гарантированно выкуплю. Ну кто откажется от такой радости? Напомню, что компании продали не уже произведенную память, а объемы производства, т.е. то, что только собираются произвести.
Это гарантированная 100% загрузка мощностей с гарантированным выкупом всего произведенного объема, при работе на потребительский рынок о таком можно только мечтать.
Все это вылилось в резкий рост цен на память и твердотельные накопители, а в дальнейшем, по мере распродажи запасов нас ждет еще и товарный дефицит.
Надеяться на быстрое исправление ситуации не приходится, все производство 2026 года уже выкуплено, поэтому если что-то и начнет меняться, то не ранее 2027 года, но это очень наивные и чрезмерно оптимистичные предположения.
Но если бы дело касалось только памяти и накопителей. В реальности нас ожидают каскадные проблемы для всей отрасли в целом.
Уже сегодня производители материнских плат столкнулись с прогрессирующим падением спроса.
А это прямое следствие дефицита памяти, кому нужна материнская плата, если память для нее стоит неподъемных денег?
Исходя из этого прямо сейчас можно говорить об аналогичном падении спроса на процессоры. И этот список можно продолжать. Фактически мы говорим о падении спроса не только на отдельные комплектующие, но и на компьютеры целиком.
Падение объемов производства неизбежно выльется в рост цен, что запустит цепную реакцию. В результате достаточно сложно предугадать к какому балансу в итоге придут спрос и предложение, но можно твердо быть уверенным, что нас ожидает эпоха высоких цен.
Текущие события снова отбрасывают компьютерный рынок в состояние, когда компьютер был дорогим и доступным далеко не всем, а не утилитарной вещью, как к этому привыкли сейчас.
Дефицит таже затронет и рынок б/у комплектующих, где сейчас особую популярность имеют китайские Xeon и недорогая DDR3 к ним. Наивно думать, что в эпоху глобального роста цен и сокращения предложения не произойдет коррекции этого сегмента рынка.
В общем, ближайшие перспективы не радостные и кто не успел, тот еще не опоздал. Да, текущие цены психологически и экономически неприятны, но это только начало, плюс рынок пока еще насыщен остатками производства.
Грубо говоря, сейчас продукция хоть и дорогая, но есть, а вот вскоре ее вообще может не оказаться на прилавках, а то, что останется явно совсем не порадует ценой.
😢8👍7❤2🤬2💯1
А вы успели купить все что хотели?
Anonymous Poll
23%
Да, еще по старым ценам
8%
Да, успел в последнюю очередь
3%
Нет, купил уже после подорожания
19%
Нет, в раздумьях
18%
Нет, отказался от покупки
28%
Просто посмотреть результат