Мертвые форматы
Встретился случайно с одним своим знакомым, который работает в бюджетной организации, и сразу вспомнил эту историю. Дело было где-то в середине десятых, из организации списали последние компьютеры на Windows 9x и выяснилась одна крайне неприятная вещь.
Практически весь электронный архив документов оказался в формате AWD, который на современных системах прочитать нельзя никак. Вообще никак, без шансов. И весь огромный архив сканов одним моментом превратился в тыкву.
Решение тогда нашли в виртуалке с Windows 98 на борту, через которую все это методично перегонялось в современный PDF. Но, как выяснилось, отдельные документы в AWD находят до сих пор, и эта схема по сей день востребована.
А вообще история показательна. В свое время Microsoft не стала заморачиваться и для своей подсистемы At Work Fax (AWD) приобрела компонент Imaging for Windows у сторонней компании, которая позже была куплена компанией Kodak. Доступа к исходным кодам у нее не было и компонент поставлялся по ограниченному лицензионному соглашению.
Причем существовал он только для линейки 9x, в NT поддержки AWD изначально не было. А с выходом Windows XP и вовсе решили от него отказаться, нежели платить Kodak за новую версию (если она вообще существовала в природе). После чего формат AWD резко осиротел.
Масштаб бедствия можно оценить по тому, что этот формат предлагался при сканировании штатными средствами по умолчанию и пользователи не видели особого смысла выбирать что-то иное.
Но в Microsoft решили, что одного раза недостаточно, и чтобы не платить за лицензию теперь уже Adobe, они, начиная с Windows Vista, ввели и начали агрессивно продвигать собственный формат – XPS (XML Paper Specification), который позже был стандартизирован как OpenXPS.
А в системе устанавливался по умолчанию виртуальный принтер Microsoft XPS Document Writer, который, казалось бы, закрывал главную проблему тех лет – конвертацию документа в универсальный формат, который везде будет открываться одинаково.
Напомним, что Adobe сделала PDF открытым только в 2008 году, а до этого массовых бесплатных решений для конвертации в этот формат не существовало. Поэтому формат достаточно активно использовался, но повальной популярности, как в свое время AWD, не достиг.
Сам по себе формат XPS был технически неплох: по сути, ZIP-архив с разметкой XAML, векторной графикой и шрифтами. Но он оказался за пределами мира Windows никому не нужен.
В macOS его просто проигнорировали, а в Linux определенные попытки были, но разработка велась по остаточному принципу и существующие библиотеки обеспечивают только базовую поддержку формата.
К выходу Windows 10 Microsoft признала провал и внедрила в систему нативный Microsoft Print to PDF, что сразу лишило формат XPS смысла существования. А дальше все пошло по классике: начиная с выпуска 1803, утилиту XPS Viewer перестали устанавливать по умолчанию и перенесли в раздел опциональных компонентов, откуда его нужно устанавливать вручную.
А начиная с Windows 11 24H2 формат признан устаревшим, и его поддержка полностью удалена из дистрибутива.
В результате через какое-то время пользователи снова могут оказаться в ситуации, когда документы есть, а открыть их нечем. Даже если формат открытый, какой смысл в открытости, если он никому не нужен и никем не поддерживается.
И чтобы прочитать и конвертировать такие документы, снова придется идти проторенным путем – поднимать виртуалку с устаревшей системой.
А какие мертвые форматы документов встречались вам?
Встретился случайно с одним своим знакомым, который работает в бюджетной организации, и сразу вспомнил эту историю. Дело было где-то в середине десятых, из организации списали последние компьютеры на Windows 9x и выяснилась одна крайне неприятная вещь.
Практически весь электронный архив документов оказался в формате AWD, который на современных системах прочитать нельзя никак. Вообще никак, без шансов. И весь огромный архив сканов одним моментом превратился в тыкву.
Решение тогда нашли в виртуалке с Windows 98 на борту, через которую все это методично перегонялось в современный PDF. Но, как выяснилось, отдельные документы в AWD находят до сих пор, и эта схема по сей день востребована.
А вообще история показательна. В свое время Microsoft не стала заморачиваться и для своей подсистемы At Work Fax (AWD) приобрела компонент Imaging for Windows у сторонней компании, которая позже была куплена компанией Kodak. Доступа к исходным кодам у нее не было и компонент поставлялся по ограниченному лицензионному соглашению.
Причем существовал он только для линейки 9x, в NT поддержки AWD изначально не было. А с выходом Windows XP и вовсе решили от него отказаться, нежели платить Kodak за новую версию (если она вообще существовала в природе). После чего формат AWD резко осиротел.
Масштаб бедствия можно оценить по тому, что этот формат предлагался при сканировании штатными средствами по умолчанию и пользователи не видели особого смысла выбирать что-то иное.
Но в Microsoft решили, что одного раза недостаточно, и чтобы не платить за лицензию теперь уже Adobe, они, начиная с Windows Vista, ввели и начали агрессивно продвигать собственный формат – XPS (XML Paper Specification), который позже был стандартизирован как OpenXPS.
А в системе устанавливался по умолчанию виртуальный принтер Microsoft XPS Document Writer, который, казалось бы, закрывал главную проблему тех лет – конвертацию документа в универсальный формат, который везде будет открываться одинаково.
Напомним, что Adobe сделала PDF открытым только в 2008 году, а до этого массовых бесплатных решений для конвертации в этот формат не существовало. Поэтому формат достаточно активно использовался, но повальной популярности, как в свое время AWD, не достиг.
Сам по себе формат XPS был технически неплох: по сути, ZIP-архив с разметкой XAML, векторной графикой и шрифтами. Но он оказался за пределами мира Windows никому не нужен.
В macOS его просто проигнорировали, а в Linux определенные попытки были, но разработка велась по остаточному принципу и существующие библиотеки обеспечивают только базовую поддержку формата.
К выходу Windows 10 Microsoft признала провал и внедрила в систему нативный Microsoft Print to PDF, что сразу лишило формат XPS смысла существования. А дальше все пошло по классике: начиная с выпуска 1803, утилиту XPS Viewer перестали устанавливать по умолчанию и перенесли в раздел опциональных компонентов, откуда его нужно устанавливать вручную.
А начиная с Windows 11 24H2 формат признан устаревшим, и его поддержка полностью удалена из дистрибутива.
В результате через какое-то время пользователи снова могут оказаться в ситуации, когда документы есть, а открыть их нечем. Даже если формат открытый, какой смысл в открытости, если он никому не нужен и никем не поддерживается.
И чтобы прочитать и конвертировать такие документы, снова придется идти проторенным путем – поднимать виртуалку с устаревшей системой.
А какие мертвые форматы документов встречались вам?
👍17🤔2❤1🔥1😁1
Прекращена поддержка Debian 11
31 августа 2026 года поддержка дистрибутива Debian 11 прекращена. Репозитории официально переведены в архив, обновлений безопасности больше не будет. Одновременно с ним во вторую стадию поддержки перешел Debian 12.
Что это значит? Схема поддержки Debian построена следующим образом: три года обычной поддержки и два года LTS. Но последний термин не должен сбивать вас c толку, LTS поддержка обеспечивается отдельной командой и распространяется не на весь дистрибутив.
Таким образом, если вы используете что-то редкое и специфическое, то можете остаться без поддержки уже на LTS стадии дистрибутива.
Справедливости ради следует сказать, что существует еще Extended LTS, которая осуществляется энтузиастами и силами компании Freexian и будет поддерживать Debian 11 до 30 июня 2031 года.
Но поддерживаться будут только те пакеты, для которых найдутся спонсоры или энтузиасты. Так что всерьез рассчитывать на Extended LTS нельзя.
А по факту, в современной модели угроз Debian не оставляет иного выбора, нежели следовать трехлетнему циклу основной поддержки, что делает его уже не столь привлекательным, как, скажем, Ubuntu, которая обеспечивает пять лет полноценной LTS поддержки.
31 августа 2026 года поддержка дистрибутива Debian 11 прекращена. Репозитории официально переведены в архив, обновлений безопасности больше не будет. Одновременно с ним во вторую стадию поддержки перешел Debian 12.
Что это значит? Схема поддержки Debian построена следующим образом: три года обычной поддержки и два года LTS. Но последний термин не должен сбивать вас c толку, LTS поддержка обеспечивается отдельной командой и распространяется не на весь дистрибутив.
Таким образом, если вы используете что-то редкое и специфическое, то можете остаться без поддержки уже на LTS стадии дистрибутива.
Справедливости ради следует сказать, что существует еще Extended LTS, которая осуществляется энтузиастами и силами компании Freexian и будет поддерживать Debian 11 до 30 июня 2031 года.
Но поддерживаться будут только те пакеты, для которых найдутся спонсоры или энтузиасты. Так что всерьез рассчитывать на Extended LTS нельзя.
А по факту, в современной модели угроз Debian не оставляет иного выбора, нежели следовать трехлетнему циклу основной поддержки, что делает его уже не столь привлекательным, как, скажем, Ubuntu, которая обеспечивает пять лет полноценной LTS поддержки.
🤝8👍4🤔4😱2👌1
Debian или Ubuntu
Нам достаточно часто задают вопрос: какой именно из этих дистрибутивов использовать для серверов? Вопрос не простой, так как обе системы сильно похожи и на первый взгляд мало чем отличаются друг от друга.
Но есть некоторые неочевидные тонкости, касающиеся релизного цикла и поддержки. Поэтому рассмотрим их подробнее.
1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве, и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.
Перейдем к поддержке. Команда Debian оказывает поддержку выпущенной версии дистрибутива в течении 3 лет, в это время система получает обновления пакетов, не меняющие основную функциональность, исправление ошибок и обновления безопасности.
Также в течении этого срока может производиться бекпортирование новых функций и улучшений для поддержания актуальности и совместимости с оборудованием.
По истечении трех лет дистрибутив получает 2 года долгосрочной поддержки LTS, в течение которой система получает только исправления критических багов и обновления безопасности.
Поддержка LTS осуществляется не командой Debian, а сообществом волонтеров при спонсировании компании Freexian. При этом уровень долгосрочной поддержки распространяется не на весь дистрибутив, а только на его часть, включающую наиболее важные и критические пакеты.
За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией, а точнее ее спонсорами.
2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.
Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив в части разделов main и restricted, и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.
Также в течении этих пяти лет может производиться бекпортирование новых функций и улучшений.
За пределами стандартной пятилетней поддержки доступна коммерческая поддержка ESM еще на пять лет, которая предоставляется также компанией-разработчиком и распространяется на весь дистрибутив. В течении этого времени он будет получать обновления безопасности и исправления критических багов, причем не только для main, но и для universe.
Для некоммерческого использования любому желающему доступна подписка ESM на пять устройств. Для этого достаточно просто зарегистрироваться на портале ESM, никаких дополнительных проверок не производится.
👉 Таким образом, как мы видим, есть довольно существенная разница в релизном цикле и способах поддержки Debian и Ubuntu.
В первом случае отсутствует строгий релизный цикл и поддержка осуществляется по принципу 3 + 2, это означает что по истечении первых 3 лет дистрибутив фактически замораживается и начинает получать только обновления безопасности на критически важные пакеты (но не на весь дистрибутив).
Такой подход затрудняет планирование и поддержку в коммерческих средах, так как присутствует значительный элемент неопределенности.
Ubuntu, наоборот, имеет четкий релизный цикл и пять лет полноценной поддержки всего дистрибутива. Это позволяет спокойно планировать жизненный цикл систем на предприятии и упорядочить процессы обновления.
При необходимости можно продлить срок использования систем при помощи расширенной поддержки ESM, которая также распространяется на весь дистрибутив и предоставляется самим разработчиком (кроме того, ее гораздо проще получить, в т.ч. и не совсем честно).
Каких-либо выводов и рекомендаций мы делать не будем. Приведенной информации достаточно для того, чтобы каждый самостоятельно сделал свой выбор.
Нам достаточно часто задают вопрос: какой именно из этих дистрибутивов использовать для серверов? Вопрос не простой, так как обе системы сильно похожи и на первый взгляд мало чем отличаются друг от друга.
Но есть некоторые неочевидные тонкости, касающиеся релизного цикла и поддержки. Поэтому рассмотрим их подробнее.
1️⃣ Debian. Официально Debian не имеет строгого релизного цикла, так как основной упор команда разработчиков делает на качестве, и выпуск новой версии дистрибутива производится тогда, когда он будет соответствовать внутренним стандартам качества, а не к определенной дате.
Перейдем к поддержке. Команда Debian оказывает поддержку выпущенной версии дистрибутива в течении 3 лет, в это время система получает обновления пакетов, не меняющие основную функциональность, исправление ошибок и обновления безопасности.
Также в течении этого срока может производиться бекпортирование новых функций и улучшений для поддержания актуальности и совместимости с оборудованием.
По истечении трех лет дистрибутив получает 2 года долгосрочной поддержки LTS, в течение которой система получает только исправления критических багов и обновления безопасности.
Поддержка LTS осуществляется не командой Debian, а сообществом волонтеров при спонсировании компании Freexian. При этом уровень долгосрочной поддержки распространяется не на весь дистрибутив, а только на его часть, включающую наиболее важные и критические пакеты.
За пределами пятилетнего цикла доступны дополнительные пять лет коммерческой ELTS поддержки от компании Freexian, при этом уровень этой поддержки и состав поддерживаемых пакетов определяется самой компанией, а точнее ее спонсорами.
2️⃣ Ubuntu. Выпуски дистрибутива с долгосрочной поддержкой (LTS) происходят по строго определенному двухгодовому графику. Таким образом каждый апрель каждого четного года мы получаем новый выпуск системы.
Ubuntu LTS получает пятилетнюю поддержку от компании-разработчика, которая распространяется на весь дистрибутив в части разделов main и restricted, и в течении этих пяти лет он будет получать обновления и улучшения пакетов, исправления ошибок и обновления безопасности.
Также в течении этих пяти лет может производиться бекпортирование новых функций и улучшений.
За пределами стандартной пятилетней поддержки доступна коммерческая поддержка ESM еще на пять лет, которая предоставляется также компанией-разработчиком и распространяется на весь дистрибутив. В течении этого времени он будет получать обновления безопасности и исправления критических багов, причем не только для main, но и для universe.
Для некоммерческого использования любому желающему доступна подписка ESM на пять устройств. Для этого достаточно просто зарегистрироваться на портале ESM, никаких дополнительных проверок не производится.
👉 Таким образом, как мы видим, есть довольно существенная разница в релизном цикле и способах поддержки Debian и Ubuntu.
В первом случае отсутствует строгий релизный цикл и поддержка осуществляется по принципу 3 + 2, это означает что по истечении первых 3 лет дистрибутив фактически замораживается и начинает получать только обновления безопасности на критически важные пакеты (но не на весь дистрибутив).
Такой подход затрудняет планирование и поддержку в коммерческих средах, так как присутствует значительный элемент неопределенности.
Ubuntu, наоборот, имеет четкий релизный цикл и пять лет полноценной поддержки всего дистрибутива. Это позволяет спокойно планировать жизненный цикл систем на предприятии и упорядочить процессы обновления.
При необходимости можно продлить срок использования систем при помощи расширенной поддержки ESM, которая также распространяется на весь дистрибутив и предоставляется самим разработчиком (кроме того, ее гораздо проще получить, в т.ч. и не совсем честно).
Каких-либо выводов и рекомендаций мы делать не будем. Приведенной информации достаточно для того, чтобы каждый самостоятельно сделал свой выбор.
👍7🔥6❤5👌3😁2
Что из DEB-систем на серверах вы предпочитаете?
Anonymous Poll
51%
Debian
33%
Ubuntu
8%
Я из другого мира
8%
Посмотреть ответы
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
DarkHost — хостинг и VDS для ваших проектов
Размещайте сайты, интернет-магазины, приложения и другие проекты на производительной инфраструктуре DarkHost.
— NVMe-хостинг
— VDS/VPS с процессором AMD EPYC 7713 и ресурсами под ваши задачи
— DDoS-защита хостинг-тарифов
— Локации: Молдова, Нидерланды и РФ
— Регистрация доменов
— Бесплатная помощь с переносом сайта
— Конструктор сайтов
— Лояльный подход к DMCA-жалобам
Работаем с 2018 года и развиваем инфраструктуру для проектов разного масштаба.
Выберите подходящее решение для вашего проекта:
Хостинг | VDS/VPS | О компании
Реклама. Дементьев И.А. ИНН 165036861363.
Размещайте сайты, интернет-магазины, приложения и другие проекты на производительной инфраструктуре DarkHost.
— NVMe-хостинг
— VDS/VPS с процессором AMD EPYC 7713 и ресурсами под ваши задачи
— DDoS-защита хостинг-тарифов
— Локации: Молдова, Нидерланды и РФ
— Регистрация доменов
— Бесплатная помощь с переносом сайта
— Конструктор сайтов
— Лояльный подход к DMCA-жалобам
Работаем с 2018 года и развиваем инфраструктуру для проектов разного масштаба.
Выберите подходящее решение для вашего проекта:
Хостинг | VDS/VPS | О компании
Реклама. Дементьев И.А. ИНН 165036861363.
👍2
Протоколы быстрого роуминга Wi-Fi 802.11k/v/r
Начнем с того, что бесшовного Wi-Fi роуминга не существует и существовать не может, потому что решение о подключении или переподключении принимает клиент и только клиент. Точка доступа может только подсказать ему правильный выбор, но решение клиент все равно будет принимать сам.
В самом простейшем случае роуминг представляет собой обычное переподключение, когда клиент обнаружив слабый сигнал от точки доступа (обычно -75 дБи и ниже) начинает поиск альтернативных точек и подключается к той, которая предоставляет наиболее сильный сигнал.
Также точка доступа может отключать клиента при некотором уровне сигнала, но отключать она его будет в никуда, так как данными о соседних точках не располагает, как и положением клиента относительно этих точек. И может так оказаться, что клиент не найдет лучшей альтернативы и будет обращаться именно к ней снова и снова.
Чтобы избежать этих ситуаций были разработаны и внедрены протоколы 802.11k/v/r, которые используются совместно, как минимум в связке 802.11k/v.
🔹 802.11k: Radio Resource Measurement - позволяет точкам и клиентам динамически обмениваться информации о состоянии среды передачи, что позволяет клиенту быстрое и проще понять куда можно переподключиться.
Так клиент может запросить у точки Link Measurement Report – отчет об измерении канала, в ответ точка ему пришлет параметры приема клиента, что позволит последнему вовремя понять, что точка его не слышит из-за асимметрии мощности или помех, хотя он слышит ее хорошо.
Также точка может попросить у клиента Beacon Reports – отчет о всех точках, которые он видит и качестве сигнала каждой из них, это позволяет контроллеру сети понять положение клиента относительно точек и то, как выглядит радиочастотная среда со стороны клиента.
Наконец клиент перед принятием решения о переключении может запросить Neighbor Reports, в которых точка ему сообщит о ближайших к нему точках на которое он может переключиться.
Последнее имеет важное значение для быстрого переключения, так позволяет избегать полного сканирования диапазона и проверить только рекомендованные точки, что уменьшает время сканирования с 0,5 -2 с, до 0,1 с и менее.
🔹 802.11v: Wireless Network Management – протокол, используемый в связке с 802.11k и позволяющий проактивно управлять беспроводной сетью.
Так перед переподключением клиент может отправить BTM Query, в ответ точка сообщит ему рекомендации по выбору альтернативных точек не только с учетом радиообстановки для конкретного клиента, но и загруженности точек доступа.
Также если точка доступа перегружена или видит, что качество связи с клиентом ухудшилось, то она проактивно отправляет клиенту BTM Request с рекомендацией переключиться.
Но, как мы уже говорили, это только рекомендация, решение переключиться или остаться остается за клиентом. Если на точке включена опция принудительного отключения клиента, то она отключит его только по истечении срока ожидания, предоставляя возможность уйти самому.
В целом наличие этих двух протоколов позволяет значительно ускорить роуминг и улучшить качество работы сети за счет того, что и клиент, и точки динамически отслеживают состояние среды и могут проактивно рекомендовать куда и когда переподключаться.
🔹 802.11r: Fast BSS Transition – протокол быстрого переключения, который позволяет ускорить этот процесс за счет предварительной аутентификации и генерации сессионных ключей.
Обычно переключение происходит следующим образом: клиент отличается от одной точки, аутентифицируется на второй, подключается, формирует ключи и производит рукопожатие.
Это может занимать до 0,7 – 1 с, что приводит к разрывам VoIP соединений, зависанию видеоконференций, лагам в онлайн-играх и т.д.
802.11r предлагает выполнять предварительную аутентификацию и генерацию ключей для подключения к другой точке еще до разрыва старого подключения, что позволяет радикально сократить время переключения до 15-50 мс.
Однако для ее поддержки требуется WPA2-Enterprise или WPA3, что делает технологию пока недоступной большинству домашних и SOHO пользователей.
Начнем с того, что бесшовного Wi-Fi роуминга не существует и существовать не может, потому что решение о подключении или переподключении принимает клиент и только клиент. Точка доступа может только подсказать ему правильный выбор, но решение клиент все равно будет принимать сам.
В самом простейшем случае роуминг представляет собой обычное переподключение, когда клиент обнаружив слабый сигнал от точки доступа (обычно -75 дБи и ниже) начинает поиск альтернативных точек и подключается к той, которая предоставляет наиболее сильный сигнал.
Также точка доступа может отключать клиента при некотором уровне сигнала, но отключать она его будет в никуда, так как данными о соседних точках не располагает, как и положением клиента относительно этих точек. И может так оказаться, что клиент не найдет лучшей альтернативы и будет обращаться именно к ней снова и снова.
Чтобы избежать этих ситуаций были разработаны и внедрены протоколы 802.11k/v/r, которые используются совместно, как минимум в связке 802.11k/v.
🔹 802.11k: Radio Resource Measurement - позволяет точкам и клиентам динамически обмениваться информации о состоянии среды передачи, что позволяет клиенту быстрое и проще понять куда можно переподключиться.
Так клиент может запросить у точки Link Measurement Report – отчет об измерении канала, в ответ точка ему пришлет параметры приема клиента, что позволит последнему вовремя понять, что точка его не слышит из-за асимметрии мощности или помех, хотя он слышит ее хорошо.
Также точка может попросить у клиента Beacon Reports – отчет о всех точках, которые он видит и качестве сигнала каждой из них, это позволяет контроллеру сети понять положение клиента относительно точек и то, как выглядит радиочастотная среда со стороны клиента.
Наконец клиент перед принятием решения о переключении может запросить Neighbor Reports, в которых точка ему сообщит о ближайших к нему точках на которое он может переключиться.
Последнее имеет важное значение для быстрого переключения, так позволяет избегать полного сканирования диапазона и проверить только рекомендованные точки, что уменьшает время сканирования с 0,5 -2 с, до 0,1 с и менее.
🔹 802.11v: Wireless Network Management – протокол, используемый в связке с 802.11k и позволяющий проактивно управлять беспроводной сетью.
Так перед переподключением клиент может отправить BTM Query, в ответ точка сообщит ему рекомендации по выбору альтернативных точек не только с учетом радиообстановки для конкретного клиента, но и загруженности точек доступа.
Также если точка доступа перегружена или видит, что качество связи с клиентом ухудшилось, то она проактивно отправляет клиенту BTM Request с рекомендацией переключиться.
Но, как мы уже говорили, это только рекомендация, решение переключиться или остаться остается за клиентом. Если на точке включена опция принудительного отключения клиента, то она отключит его только по истечении срока ожидания, предоставляя возможность уйти самому.
В целом наличие этих двух протоколов позволяет значительно ускорить роуминг и улучшить качество работы сети за счет того, что и клиент, и точки динамически отслеживают состояние среды и могут проактивно рекомендовать куда и когда переподключаться.
🔹 802.11r: Fast BSS Transition – протокол быстрого переключения, который позволяет ускорить этот процесс за счет предварительной аутентификации и генерации сессионных ключей.
Обычно переключение происходит следующим образом: клиент отличается от одной точки, аутентифицируется на второй, подключается, формирует ключи и производит рукопожатие.
Это может занимать до 0,7 – 1 с, что приводит к разрывам VoIP соединений, зависанию видеоконференций, лагам в онлайн-играх и т.д.
802.11r предлагает выполнять предварительную аутентификацию и генерацию ключей для подключения к другой точке еще до разрыва старого подключения, что позволяет радикально сократить время переключения до 15-50 мс.
Однако для ее поддержки требуется WPA2-Enterprise или WPA3, что делает технологию пока недоступной большинству домашних и SOHO пользователей.
2👍20❤1🤝1
Когда vSphere уже «трофейная», а продлевать нечего 🙃
24 сентября в 11:00 (МСК) CNS и Orion Soft проводят вебинар про
zVirt, российскую платформу виртуализации на замену VMware
vSphere и Hyper-V.
Покажем на живом демо-стенде, в реальном интерфейсе:
▫️ живую миграцию ВМ
▫️ гиперконвергенцию
▫️ SDN
▫️ DR и катастрофоустойчивость
▫️ управление всем этим из одной консоли, без «зоопарка»
Отдельно для тех, у кого КИИ: сертифицированная ФСТЭК редакция и реестр отечественного ПО, то есть что показать безопасникам и регулятору.
👉 Регистрация: Здесь
#реклама
О рекламодателе
24 сентября в 11:00 (МСК) CNS и Orion Soft проводят вебинар про
zVirt, российскую платформу виртуализации на замену VMware
vSphere и Hyper-V.
Покажем на живом демо-стенде, в реальном интерфейсе:
▫️ живую миграцию ВМ
▫️ гиперконвергенцию
▫️ SDN
▫️ DR и катастрофоустойчивость
▫️ управление всем этим из одной консоли, без «зоопарка»
Отдельно для тех, у кого КИИ: сертифицированная ФСТЭК редакция и реестр отечественного ПО, то есть что показать безопасникам и регулятору.
👉 Регистрация: Здесь
#реклама
О рекламодателе
🤡4😁2
Приглашаем на воркшоп «Управление уязвимостями: строим технический процесс как у взрослых»
🔹Разберём на стенде: ОС, веб-сервер, база данных, приложение - разные слои, разные владельцы, - как это устроено в реальной компании.
Что разберём:
✅откуда берутся уязвимости и патчи, как читать security-advisory
✅как приоритизировать, когда уязвимостей сотни: CVSS, EPSS, CISA KEV
✅полный цикл вживую: скан → приоритизация → патч на staging → проверка тестами → раскатка на прод
✅что делать, когда патча ещё нет — на живом примере с реальным эксплойтом
✅как устроен процесс: SLA, метрики, реестр уязвимостей
🔹Проведёт Кирилл Казарин - руководитель международного департамента информационных технологий, инфраструктуры и поддержки производственных систем, RingCentral Inc.
🔹Формат: около 4 часов с перерывами, вопросы можно задавать по ходу. Руками на воркшопе не работаем, но в конце дадим ссылку на репозиторий со стендом, конфигами и шаблоном реестра уязвимостей, чтобы повторить всё в своём темпе.
🔹Когда: 26 сентября в 12:00 мск
⚡️ЗАНЯТЬ МЕСТО НА ВОРКШОПЕ⚡️
🔹Разберём на стенде: ОС, веб-сервер, база данных, приложение - разные слои, разные владельцы, - как это устроено в реальной компании.
Что разберём:
✅откуда берутся уязвимости и патчи, как читать security-advisory
✅как приоритизировать, когда уязвимостей сотни: CVSS, EPSS, CISA KEV
✅полный цикл вживую: скан → приоритизация → патч на staging → проверка тестами → раскатка на прод
✅что делать, когда патча ещё нет — на живом примере с реальным эксплойтом
✅как устроен процесс: SLA, метрики, реестр уязвимостей
🔹Проведёт Кирилл Казарин - руководитель международного департамента информационных технологий, инфраструктуры и поддержки производственных систем, RingCentral Inc.
🔹Формат: около 4 часов с перерывами, вопросы можно задавать по ходу. Руками на воркшопе не работаем, но в конце дадим ссылку на репозиторий со стендом, конфигами и шаблоном реестра уязвимостей, чтобы повторить всё в своём темпе.
🔹Когда: 26 сентября в 12:00 мск
⚡️ЗАНЯТЬ МЕСТО НА ВОРКШОПЕ⚡️
Спрашивают – отвечаем. Какой утилитой можно посмотреть какой процесс сколько занимает памяти.
Вопрос не праздный, часто нужно понять кто занял всю память или весь swap, причем сделать это в удобной форме, без лишней консольной магии.
Для этих целей следует использовать утилиту smem, которая доступна в стандартных репозиториях.
Утилита достаточно проста, прежде всего запустим ее с ключом -h, чтобы посмотреть доступные ключи. Их немного.
Если запустить утилиту без параметров, то вы получите список процессов в указанием занимаемой ими памяти в килобайтах отсортированный по возрастанию значений колонки PSS.
Всего колонок четыре, коротко разберем что они обозначают:
🔸 RSS – реальный объем памяти, выделяемый процессу, но это число не является точным, так как включает в себя в том числе память, занимаемую разделяемыми библиотеками, которые загружаются в память один раз, но в тоже время дает понять общие аппетиты процесса.
🔸 PSS – пропорциональный объем памяти, наиболее интересное с практической точки зрения число, так как объем памяти разделяемых библиотек делится пропорционально между процессами, например, если у нас три процесса используют одну и ту же библиотеку, то занимаемый ею объем памяти поделится на троих.
🔸 USS – уникальный объем памяти, который принадлежит собственно процессу, без учета разделяемых библиотек. Показывает фактическую стоимость запуска процесса и именно этот объем памяти будет возвращен в систему если процесс завершить.
🔸 Swap – объем сброшенных в подкачку страниц памяти процесса.
Сразу запоминаем полезные ключи программы:
▫️ -t - выводит снизу результирующую строку по всем колонкам
▫️ -p – представляет значение в процентах от общего объема памяти, а не в килобайтах
▫️ -а – подстраивает ширину колонок под текущий размер окна терминала
Как мы уже говорили, сортировка ведется по возрастанию колонки PSS, т.е. самые «жирные» процессы будут внизу.
Это поведение можно изменить ключами -s и -r, после которых следует указать имя колонки для сортировки. Ключ -r сортирует значения в обратном порядке – по убыванию значений.
Например, чтобы посмотреть кто использует Swap в процентах по убыванию значений, используйте:
У применения этой утилиты есть одна особенность, будучи запущена с правами пользователя она показывает только процессы текущего пользователя, чтобы получить полное представление на уровне системы ее следует запускать от root или через sudo.
Также мы можем делать отборы по имени процесса или его владельцу, например, посмотрим все процессы Postgres по убыванию в процентах:
Или все процессы пользователя 1С:Предприятия:
Что еще можно посмотреть с ее помощью? Использование памяти в разрезе пользователей с ключом -u или по всей системе с ключом -w.
Отдельного упоминания стоит ключ -m, который показывает маппинги, это файлы отраженные в оперативную память, чаще всего это разделяемые библиотеки, с данным ключом вы можете подробно посмотреть что именно у вас загружено в память и сколько места оно там занимает.
Вопрос не праздный, часто нужно понять кто занял всю память или весь swap, причем сделать это в удобной форме, без лишней консольной магии.
Для этих целей следует использовать утилиту smem, которая доступна в стандартных репозиториях.
Утилита достаточно проста, прежде всего запустим ее с ключом -h, чтобы посмотреть доступные ключи. Их немного.
Если запустить утилиту без параметров, то вы получите список процессов в указанием занимаемой ими памяти в килобайтах отсортированный по возрастанию значений колонки PSS.
Всего колонок четыре, коротко разберем что они обозначают:
🔸 RSS – реальный объем памяти, выделяемый процессу, но это число не является точным, так как включает в себя в том числе память, занимаемую разделяемыми библиотеками, которые загружаются в память один раз, но в тоже время дает понять общие аппетиты процесса.
🔸 PSS – пропорциональный объем памяти, наиболее интересное с практической точки зрения число, так как объем памяти разделяемых библиотек делится пропорционально между процессами, например, если у нас три процесса используют одну и ту же библиотеку, то занимаемый ею объем памяти поделится на троих.
🔸 USS – уникальный объем памяти, который принадлежит собственно процессу, без учета разделяемых библиотек. Показывает фактическую стоимость запуска процесса и именно этот объем памяти будет возвращен в систему если процесс завершить.
🔸 Swap – объем сброшенных в подкачку страниц памяти процесса.
Сразу запоминаем полезные ключи программы:
▫️ -t - выводит снизу результирующую строку по всем колонкам
▫️ -p – представляет значение в процентах от общего объема памяти, а не в килобайтах
▫️ -а – подстраивает ширину колонок под текущий размер окна терминала
Как мы уже говорили, сортировка ведется по возрастанию колонки PSS, т.е. самые «жирные» процессы будут внизу.
Это поведение можно изменить ключами -s и -r, после которых следует указать имя колонки для сортировки. Ключ -r сортирует значения в обратном порядке – по убыванию значений.
Например, чтобы посмотреть кто использует Swap в процентах по убыванию значений, используйте:
smem -tap -r swap
У применения этой утилиты есть одна особенность, будучи запущена с правами пользователя она показывает только процессы текущего пользователя, чтобы получить полное представление на уровне системы ее следует запускать от root или через sudo.
Также мы можем делать отборы по имени процесса или его владельцу, например, посмотрим все процессы Postgres по убыванию в процентах:
smem -tpa -P postgres -r pss
Или все процессы пользователя 1С:Предприятия:
smem -tpa -U usr1cv8 -r pss
Что еще можно посмотреть с ее помощью? Использование памяти в разрезе пользователей с ключом -u или по всей системе с ключом -w.
Отдельного упоминания стоит ключ -m, который показывает маппинги, это файлы отраженные в оперативную память, чаще всего это разделяемые библиотеки, с данным ключом вы можете подробно посмотреть что именно у вас загружено в память и сколько места оно там занимает.
1👍9
Сеанс двоичной магии с разоблачением
Сегодня мы поговорим о том, как правильно рассчитать IP-адрес по маске и делать это будем исключительно руками без всяких калькуляторов.
Начнем с просто примера: 192.168.1.100 с маской 255.255.255.0 или /24
Прежде всего скажем, не обращайте никакого внимания на десятичные цифры, они тут нужны исключительно для удобства восприятия. Вся магия происходит на двоичном уровне. Хотя на самом деле никакой магии там нет, обычная двоичная математика.
IP адрес и маска состоят из 4 октетов, каждый из которых нам нужно перевести в двоичный вид. Для этого сделаем такую табличку:
Теперь берем первый октет, проверяем, помещается ли первое число 128 в 192? Помещается, ставим 1. Затем вычитаем из 192 число 128, получаем 64. Проверяем со вторым числом, помещается, снова ставим 1 и вычитаем из остатка 64.
У нас остался ноль, в который не помещаются остальные числа, там проставляем ноли.
В итоге адрес 192.168.1.100 мы запишем как
Теперь маска, также переводим ее в двоичный вид. Но если с 255.255.255.0 все понятно, то как понимать /24? А просто, 24 обозначает что маска содержит 24 единицы, т.е. вам даже не нужно ничего переводить:
А теперь начинается настоящая двоичная магия, записываем адрес и маску друг под другом:
Те части адреса, которые покрываются маской являются номером (префиксом) сети, а те, которые не попадают в маску – номером узла.
Таким образом у нас адрес сети (все что не попадает под маску меняем нолями):
Что соответствует 192.168.1.0
Минимальным адресом сети будет:
Максимальным:
А последний доступный адрес в сети является широковещательным:
Теперь поменяем маску на /23 или 255.255.254.0 и посмотрим, что изменится:
Адрес сети у нас та часть, которая покрывается маской, остальное заменяем нулями:
Минимальный адрес:
Максимальный адрес:
Широковещательный адрес:
А теперь вернемся к примеру из пятничного вопроса:
Адрес сети:
Минимальный адрес:
Максимальный адрес:
Широковещательный адрес:
Таким образом в результате таких вот магических манипуляций мы выяснили, что 5.6.7.0/23 является адресом узла сети.
Адресом сети с такой маской он не может быть ни при каком раскладе, так как ее просто не может существовать физически.
Почему? Расписываем в двоичном виде адрес и маску и понимаем, что сети с адресами 5.6.6.0/23 и 5.6.8.0/23 существовать могут, а вот сеть с адресом 5.6.7.0/23 – нет.
Сегодня мы поговорим о том, как правильно рассчитать IP-адрес по маске и делать это будем исключительно руками без всяких калькуляторов.
Начнем с просто примера: 192.168.1.100 с маской 255.255.255.0 или /24
Прежде всего скажем, не обращайте никакого внимания на десятичные цифры, они тут нужны исключительно для удобства восприятия. Вся магия происходит на двоичном уровне. Хотя на самом деле никакой магии там нет, обычная двоичная математика.
IP адрес и маска состоят из 4 октетов, каждый из которых нам нужно перевести в двоичный вид. Для этого сделаем такую табличку:
128 | 64 | 32 | 16 | 8 | 4 | 2 | 1
Теперь берем первый октет, проверяем, помещается ли первое число 128 в 192? Помещается, ставим 1. Затем вычитаем из 192 число 128, получаем 64. Проверяем со вторым числом, помещается, снова ставим 1 и вычитаем из остатка 64.
У нас остался ноль, в который не помещаются остальные числа, там проставляем ноли.
В итоге адрес 192.168.1.100 мы запишем как
11000000 10101000 00000001 01100100
Теперь маска, также переводим ее в двоичный вид. Но если с 255.255.255.0 все понятно, то как понимать /24? А просто, 24 обозначает что маска содержит 24 единицы, т.е. вам даже не нужно ничего переводить:
/24 = 255.255.255.0 = 11111111 11111111 11111111 00000000
А теперь начинается настоящая двоичная магия, записываем адрес и маску друг под другом:
11000000 10101000 00000001 01100100
11111111 11111111 11111111 00000000
Те части адреса, которые покрываются маской являются номером (префиксом) сети, а те, которые не попадают в маску – номером узла.
Таким образом у нас адрес сети (все что не попадает под маску меняем нолями):
11000000 10101000 00000001 00000000
Что соответствует 192.168.1.0
Минимальным адресом сети будет:
11000000 10101000 00000001 00000001 = 192.168.1.1
Максимальным:
11000000 10101000 00000001 11111110 = 192.168.1.254
А последний доступный адрес в сети является широковещательным:
11000000 10101000 00000001 11111111 = 192.168.1.255
Теперь поменяем маску на /23 или 255.255.254.0 и посмотрим, что изменится:
11000000 10101000 00000001 01100100
11111111 11111111 11111110 00000000
Адрес сети у нас та часть, которая покрывается маской, остальное заменяем нулями:
11000000 10101000 00000000 00000000 = 192.168.0.0
Минимальный адрес:
11000000 10101000 00000000 00000001 = 192.168.0.1
Максимальный адрес:
11000000 10101000 00000001 11111110 = 192.168.1.254
Широковещательный адрес:
11000000 10101000 00000001 11111111 = 192.168.1.255
А теперь вернемся к примеру из пятничного вопроса:
5.6.7.0/23
00000101 00000110 00000111 00000000
11111111 11111111 11111110 00000000
Адрес сети:
00000101 00000110 00000110 00000000 = 5.6.6.0
Минимальный адрес:
00000101 00000110 00000110 00000001 = 5.6.6.1
Максимальный адрес:
00000101 00000110 00000111 11111110 = 5.6.7.254
Широковещательный адрес:
00000101 00000110 00000111 11111111 = 5.6.7.255
Таким образом в результате таких вот магических манипуляций мы выяснили, что 5.6.7.0/23 является адресом узла сети.
Адресом сети с такой маской он не может быть ни при каком раскладе, так как ее просто не может существовать физически.
Почему? Расписываем в двоичном виде адрес и маску и понимаем, что сети с адресами 5.6.6.0/23 и 5.6.8.0/23 существовать могут, а вот сеть с адресом 5.6.7.0/23 – нет.
1👍8👌4