С днем Отца!
Кстати, с днем Отца, мужики!
Отец – это важно, это не только про деньги, а про воспитание и передачу подрастающему поколению правильных ценностей.
Мой сын от меня всегда получал поддержку в своих стремлениях, а если что-то, то ломал или палил, то папа всегда ему это компенсировал, причем так, чтобы не знала мама. У мамы другие цели и интересы, незачем ее расстраивать.
А в этом году сын вне конкурса поступил в Колледж высоких технологий местного ВУЗа. Благодаря собственным достижениям, с которыми он выступал на Олимпиадах и Конкурсах.
Сыном я горжусь и поддерживаю его. А он говорит, что без меня и мой поддержки он бы сюда не пришел.
В общем отцы – занимайтесь своими детьми. Вторых отцов у них нет, а деньги не самое важное в этой жизни.
Быть Отцом – это круто, пацаны. На самом деле круто!
Кстати, с днем Отца, мужики!
Отец – это важно, это не только про деньги, а про воспитание и передачу подрастающему поколению правильных ценностей.
Мой сын от меня всегда получал поддержку в своих стремлениях, а если что-то, то ломал или палил, то папа всегда ему это компенсировал, причем так, чтобы не знала мама. У мамы другие цели и интересы, незачем ее расстраивать.
А в этом году сын вне конкурса поступил в Колледж высоких технологий местного ВУЗа. Благодаря собственным достижениям, с которыми он выступал на Олимпиадах и Конкурсах.
Сыном я горжусь и поддерживаю его. А он говорит, что без меня и мой поддержки он бы сюда не пришел.
В общем отцы – занимайтесь своими детьми. Вторых отцов у них нет, а деньги не самое важное в этой жизни.
Быть Отцом – это круто, пацаны. На самом деле круто!
👍66❤21👏6🤮2
До свиданья наш ласковый миша, часть 2
Про проблемы mdadm в современных реалиях мы уже писали, тогда это касалось такого явления, как bitrot (битовое гниение). Но на этом проблемы mdadm не заканчиваются и когда снова и снова видишь рекомендации использовать этот тип массивов как хранилище виртуальных машин, скажем для Proxmox, то начинает дергаться глаз.
Сегодня мы поговорим о более серьезной проблеме - O_DIRECT – флаге прямой записи на блочное устройство, минуя страничный кеш системы.
Этот флаг чаще всего используется СУБД, которые имеют свой кеш и хотят избежать двойного кеширования, а также виртуальными машинами для ускорения операций ввода вывода.
1️⃣ Самая распространенная ошибка при использовании O_DIRECT совместно с mdadm – это ошибка выравнивания. O_DIRECT требует, чтобы блоки записи были выровнены согласно страницам памяти (4 КБ), в то время как mdadm требует выравнивания данных по размеру блока чередования (chunk).
При этом файловая система ничего не знает о внутреннем устройстве RAID, для нее это просто виртуальное блочное устройство. А mdadm не контролирует процесс записи на уровне файловой системы и приложения.
Таким образом, если блок данных прямой записи пересекает границы блока чередования или не совпадает с ним, то такая команда записи не может быть обработана и вызывает ошибку.
Данная ошибка может приводить к краху приложения или всей операционной системы, также она может оказаться фатальной для всего массива, если он находится в состоянии ресинхронизации.
Современные системы имеют своеобразную защиту от подобной ошибки – при невозможности выполнить прямую запись они автоматически откатывают ее до буферизованной, что может самым негативным образом сказаться на приложениях, потому что нарушает ожидаемое поведение.
Так приложение или виртуальная машина будет думать, что данные уже записаны, но на самом деле они все еще находятся в кеше. Само по себе это может быть не так и страшно, но в случае отказа питания может повлечь самые негативные последствия, вплоть до разрушения баз данных и виртуальных дисков.
2️⃣ Вторая проблема mdadm и O_DIRECT – это тихое повреждение данных. Как мы уже говорили, при наличии флага прямой записи mdadm не контролирует содержимое буфера, а передает его на все входящие в массив дисковые устройства.
И если в процессе записи данный буфер будет изменен (а приложения могут менять его содержимое), то мы имеем ненулевой шанс того, что на разные диски будет записан разный набор данных.
Причем сам mdadm это никак не контролирует, не отражает в логах и считает такой массив синхронизированным.
Чаще всего с подобной проблемой можно столкнуться во время живой миграции, что в лучшем случае приводит к сбою в работе мигрирующей машины, в худшем – к повреждению виртуального диска, часто – незаметному.
Данные проблемы в принципе нерешаемы, так как требуют серьезной переработки или mdadm или O_DIRECT, что ни те, ни другие делать не собираются.
❓ А как обстоят дела в других реализациях? Ровно тем же самым проблемам подвержены LVM RAID и DRBD. Все это достаточно старые технологии и причины проблем там те же самые, что и у mdadm.
👉 В то же время современные файловые системы включающие в себя функции RAID, такие как ZFS или btrfs от данных проблем свободны. Да, там тоже были свои сложности при поддержке O_DIRECT, но фатальных проблем с ним они не имели.
Здесь сказывается сама архитектура этих систем, где RAID является частью файловой системы, и она имеет полное представление о его структуре, это позволяет правильно выполнять выравнивание и избегать связанных с ним ошибок и отказов в записи.
Также такие файловые системы самостоятельно управляют записью на физические устройства и контролируют содержимое буфера прямой записи, если в процессе записи буфер будет изменен, то изменения будут гарантированно записаны на все физические устройства.
Таким образом мы снова видим, что mdadm значительно устарел и уже не может служить надежным хранилищем для ваших данных.
Про проблемы mdadm в современных реалиях мы уже писали, тогда это касалось такого явления, как bitrot (битовое гниение). Но на этом проблемы mdadm не заканчиваются и когда снова и снова видишь рекомендации использовать этот тип массивов как хранилище виртуальных машин, скажем для Proxmox, то начинает дергаться глаз.
Сегодня мы поговорим о более серьезной проблеме - O_DIRECT – флаге прямой записи на блочное устройство, минуя страничный кеш системы.
Этот флаг чаще всего используется СУБД, которые имеют свой кеш и хотят избежать двойного кеширования, а также виртуальными машинами для ускорения операций ввода вывода.
1️⃣ Самая распространенная ошибка при использовании O_DIRECT совместно с mdadm – это ошибка выравнивания. O_DIRECT требует, чтобы блоки записи были выровнены согласно страницам памяти (4 КБ), в то время как mdadm требует выравнивания данных по размеру блока чередования (chunk).
При этом файловая система ничего не знает о внутреннем устройстве RAID, для нее это просто виртуальное блочное устройство. А mdadm не контролирует процесс записи на уровне файловой системы и приложения.
Таким образом, если блок данных прямой записи пересекает границы блока чередования или не совпадает с ним, то такая команда записи не может быть обработана и вызывает ошибку.
Данная ошибка может приводить к краху приложения или всей операционной системы, также она может оказаться фатальной для всего массива, если он находится в состоянии ресинхронизации.
Современные системы имеют своеобразную защиту от подобной ошибки – при невозможности выполнить прямую запись они автоматически откатывают ее до буферизованной, что может самым негативным образом сказаться на приложениях, потому что нарушает ожидаемое поведение.
Так приложение или виртуальная машина будет думать, что данные уже записаны, но на самом деле они все еще находятся в кеше. Само по себе это может быть не так и страшно, но в случае отказа питания может повлечь самые негативные последствия, вплоть до разрушения баз данных и виртуальных дисков.
2️⃣ Вторая проблема mdadm и O_DIRECT – это тихое повреждение данных. Как мы уже говорили, при наличии флага прямой записи mdadm не контролирует содержимое буфера, а передает его на все входящие в массив дисковые устройства.
И если в процессе записи данный буфер будет изменен (а приложения могут менять его содержимое), то мы имеем ненулевой шанс того, что на разные диски будет записан разный набор данных.
Причем сам mdadm это никак не контролирует, не отражает в логах и считает такой массив синхронизированным.
Чаще всего с подобной проблемой можно столкнуться во время живой миграции, что в лучшем случае приводит к сбою в работе мигрирующей машины, в худшем – к повреждению виртуального диска, часто – незаметному.
Данные проблемы в принципе нерешаемы, так как требуют серьезной переработки или mdadm или O_DIRECT, что ни те, ни другие делать не собираются.
❓ А как обстоят дела в других реализациях? Ровно тем же самым проблемам подвержены LVM RAID и DRBD. Все это достаточно старые технологии и причины проблем там те же самые, что и у mdadm.
👉 В то же время современные файловые системы включающие в себя функции RAID, такие как ZFS или btrfs от данных проблем свободны. Да, там тоже были свои сложности при поддержке O_DIRECT, но фатальных проблем с ним они не имели.
Здесь сказывается сама архитектура этих систем, где RAID является частью файловой системы, и она имеет полное представление о его структуре, это позволяет правильно выполнять выравнивание и избегать связанных с ним ошибок и отказов в записи.
Также такие файловые системы самостоятельно управляют записью на физические устройства и контролируют содержимое буфера прямой записи, если в процессе записи буфер будет изменен, то изменения будут гарантированно записаны на все физические устройства.
Таким образом мы снова видим, что mdadm значительно устарел и уже не может служить надежным хранилищем для ваших данных.
👍36❤7🔥6
Как устроена и работает сеть
Бывает, что сеть работает не так, как задумано и предполагается. Что делать? Можно, конечно, долго пытаться угадать причину, искать возможные похожие случаи в интернете и т.д. и т.п.
Но лучше взять и один раз посмотреть, что происходит самостоятельно. А для этого нужно научиться работать с сетью на низком уровне и посмотреть своими глазами содержимое пакетов и их заголовки.
Для первых шагов лучше взять какой-нибудь простой протокол и начать изучение с него, скажем, DHCP или FTP.
Что нам для этого понадобится? Во-первых, теоретическая база, для этого можно взять наши статьи:
🔹 Как устроен и работает протокол DHCP
🔹 Особенности работы протокола FTP
Во-вторых, нам понадобятся инструменты. Мы рекомендуем стандарт де-факто – Wireshark, который умеет производить как захват, так и анализ трафика.
Устанавливаем его на клиентский ПК и настраиваем захват трафика с нужного сетевого адаптера, после чего у вас сразу посыплется множество пакетов, разобраться в этом изобилии достаточно сложно, но мы даже не будем пытаться этого делать.
Чтобы выделить необходимый нам трафик сразу применим фильтр, за него отвечает верхняя строка приложения (показана на скриншоте), в стандартных фильтрах уже есть DHCP и вам останется только выбрать его и применить.
Список пакетов сразу сократиться, и мы можем попробовать заново получить IP-адрес и посмотреть своими глазами весь процесс взаимодействия между DHCP-клиентом и сервером.
Как мы уже говорили, протокол простой и открытый. Для просмотра информации достаточно выбрать пакет в списке и ознакомиться с его содержимым в нижней части окна.
Например, на нашем скриншоте прекрасно видно содержимое DHCP-запроса.
Мы рекомендуем, если у вас еще не было такого опыта, обязательно установить Wireshark и разобраться с работой DHCP или FTP хотя бы в рамках наших материалов.
Это добавит вам полезный опыт, заложит основы анализа трафика при помощи Wireshark и, главное, избавит от страха перед низкоуровневыми инструментами и добавит уверенность в собственных силах.
Бывает, что сеть работает не так, как задумано и предполагается. Что делать? Можно, конечно, долго пытаться угадать причину, искать возможные похожие случаи в интернете и т.д. и т.п.
Но лучше взять и один раз посмотреть, что происходит самостоятельно. А для этого нужно научиться работать с сетью на низком уровне и посмотреть своими глазами содержимое пакетов и их заголовки.
Для первых шагов лучше взять какой-нибудь простой протокол и начать изучение с него, скажем, DHCP или FTP.
Что нам для этого понадобится? Во-первых, теоретическая база, для этого можно взять наши статьи:
🔹 Как устроен и работает протокол DHCP
🔹 Особенности работы протокола FTP
Во-вторых, нам понадобятся инструменты. Мы рекомендуем стандарт де-факто – Wireshark, который умеет производить как захват, так и анализ трафика.
Устанавливаем его на клиентский ПК и настраиваем захват трафика с нужного сетевого адаптера, после чего у вас сразу посыплется множество пакетов, разобраться в этом изобилии достаточно сложно, но мы даже не будем пытаться этого делать.
Чтобы выделить необходимый нам трафик сразу применим фильтр, за него отвечает верхняя строка приложения (показана на скриншоте), в стандартных фильтрах уже есть DHCP и вам останется только выбрать его и применить.
Список пакетов сразу сократиться, и мы можем попробовать заново получить IP-адрес и посмотреть своими глазами весь процесс взаимодействия между DHCP-клиентом и сервером.
Как мы уже говорили, протокол простой и открытый. Для просмотра информации достаточно выбрать пакет в списке и ознакомиться с его содержимым в нижней части окна.
Например, на нашем скриншоте прекрасно видно содержимое DHCP-запроса.
Мы рекомендуем, если у вас еще не было такого опыта, обязательно установить Wireshark и разобраться с работой DHCP или FTP хотя бы в рамках наших материалов.
Это добавит вам полезный опыт, заложит основы анализа трафика при помощи Wireshark и, главное, избавит от страха перед низкоуровневыми инструментами и добавит уверенность в собственных силах.
👍37❤2🤮1👀1
Режимы запуска bash
Скрипты и команды bash – это то, с чем ежедневно сталкивается системный администратора, поэтому важно знать режимы запуска командной оболочки и контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
Кроме того,
Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
Скрипты и команды 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 будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
👍28❤3🥱1
Жить станет лучше, жить станет веселей
С 7 января 2026 года весь маркированный товар нужно будет проверять с помощью специального модуля ТС ПИоТ - программного комплекса проверки информации о товаре.
Официальные функции ТС ПИоТ заявлены как:
▫️ Передача данных о состоянии работы в Государственную информационную систему мониторинга товаров (ГИС МТ);
▫️ Контроль работоспособности компонентов кассовой зоны;
▫️ Проверка корректности распознавания кодов маркировки;
▫️ Соблюдение требований законодательства по работе с маркированными товарами;
▫️ Блокировка продажи товаров, запрещенных к реализации на основании данных системы маркировки.
Т.е., как всегда, за все хорошее и против всего плохого. Причем это новшество будет дополнением к уже существующим:
▫️ Онлайн-проверке РР
▫️ Оффлайн-проверке ЛМ
▫️ Проверке ОИСМ на ККТ
Таким образом получаем дополнительный этап проверки (увеличиваем время обслуживания) и добавляем дополнительную точку отказа.
Кроме того непонятно, что это вообще за «мышонок, лягушка или еще какая неведомая зверюшка».
В реестре пока две модели и судя по названиям и прочей информации – это будут аппаратные комплексы (т.е. привет дополнительные затраты), которые будут взаимодействовать с текущей системой на уровне драйвера ККТ.
Ситуацию усугубляет то, что до времени Ч осталось практически ровно два месяца. Не получится ли так, что производители не смогут насытить рынок ТС ПИоТ и не повторится ситуация с дефицитом ФН и онлайн-касс на заре внедрения последних.
После чего рознице будет предоставлен невеселый выбор: или закрыться, или пойти на сознательное нарушение законодательства, в надежде на какие-то послабления и переходные периоды.
Но в любом случае новый год скучным не будет.
С 7 января 2026 года весь маркированный товар нужно будет проверять с помощью специального модуля ТС ПИоТ - программного комплекса проверки информации о товаре.
Официальные функции ТС ПИоТ заявлены как:
▫️ Передача данных о состоянии работы в Государственную информационную систему мониторинга товаров (ГИС МТ);
▫️ Контроль работоспособности компонентов кассовой зоны;
▫️ Проверка корректности распознавания кодов маркировки;
▫️ Соблюдение требований законодательства по работе с маркированными товарами;
▫️ Блокировка продажи товаров, запрещенных к реализации на основании данных системы маркировки.
Т.е., как всегда, за все хорошее и против всего плохого. Причем это новшество будет дополнением к уже существующим:
▫️ Онлайн-проверке РР
▫️ Оффлайн-проверке ЛМ
▫️ Проверке ОИСМ на ККТ
Таким образом получаем дополнительный этап проверки (увеличиваем время обслуживания) и добавляем дополнительную точку отказа.
Кроме того непонятно, что это вообще за «мышонок, лягушка или еще какая неведомая зверюшка».
В реестре пока две модели и судя по названиям и прочей информации – это будут аппаратные комплексы (т.е. привет дополнительные затраты), которые будут взаимодействовать с текущей системой на уровне драйвера ККТ.
Ситуацию усугубляет то, что до времени Ч осталось практически ровно два месяца. Не получится ли так, что производители не смогут насытить рынок ТС ПИоТ и не повторится ситуация с дефицитом ФН и онлайн-касс на заре внедрения последних.
После чего рознице будет предоставлен невеселый выбор: или закрыться, или пойти на сознательное нарушение законодательства, в надежде на какие-то послабления и переходные периоды.
Но в любом случае новый год скучным не будет.
🤬23❤4😱3🔥2🙏1
Листая старую тетрадь
Занимаясь переносом контента со старого на новый движок, заново вспоминаешь события прошлых лет, что тогда было актуально, что из этого осталось актуально сейчас.
Сегодня хотелось бы поделиться парой заметок далекого и светлого 2011 года, которые связаны общей темой – работой с железом, его диагностикой и ремонтом.
В первой статье:
🔹 Админу на заметку - 2. Организация рабочего места
Мы поделились идеей коллег по созданию открытого стенда из обычного корпуса ПК. Идея была проста, но эффективна – развернуть отсек накопителей поперек корпуса и вынести туда же разъемы передней панели, кнопки и индикаторы.
Также организовать в легком доступе отсеки для подключения накопителей. А потом задвинуть все это к стенке или повесить на стену.
Идея оказалась стоящая и жива до сих пор, хотя нет уже DVD-приводов, да и жесткие диски встречаются все реже. Но именно такая концепция стенда продолжает жить и позволяет быстро и просто повысить удобство на рабочем месте.
И может оно выглядит не совсем эстетично, зато дешево, надежно и практично.
Вторая статья:
🔹 Админу на заметку - 3. Полезные инструменты для диагностики ПК
Тоже на эту тему, тогда мы только-только начали осваивать для себя китайские площадки и многие вещи оттуда были в диковинку.
Тестеры ATX-блоков питания пришлись ко двору и прижились, благо штука дешевая и полезная, позволяющая быстро проверить любой имеющийся в наличии блок питания.
До этого в арсенале была только металлическая скрепка, которой замыкали зеленый и черный провод, после чего можно было узнать – стартует блок или нет.
Но не более, напряжения на линиях и наличие сигнала готовности оставалось загадкой.
А вот POST-платы, по сути, оказались игрушкой. Любую материнку тех лет любой техник умел диагностировать по звуковым сигналам, выявляя основные неисправности.
Потом большинство производителей добавило эту функцию на сами платы, в виде семисегментных индикаторов или светодиодов. При этом шина PCI стала уходить в прошлое, а современные разъемы не предназначены для вывода на них диагностической информации.
Какое-то время мы еще пытались найти более-менее универсальное решение, но отказались, так как смысла и так было немного. Сейчас любая современная плата, ну кроме самых дешевых, покажет вам неисправность одного из основных компонентов.
Но все равно перечитывать такие материалы интересно, равно как возвращаться в те дни, с их проблемами и чаяниями, а потом сравнивать это с днем сегодняшним.
Занимаясь переносом контента со старого на новый движок, заново вспоминаешь события прошлых лет, что тогда было актуально, что из этого осталось актуально сейчас.
Сегодня хотелось бы поделиться парой заметок далекого и светлого 2011 года, которые связаны общей темой – работой с железом, его диагностикой и ремонтом.
В первой статье:
🔹 Админу на заметку - 2. Организация рабочего места
Мы поделились идеей коллег по созданию открытого стенда из обычного корпуса ПК. Идея была проста, но эффективна – развернуть отсек накопителей поперек корпуса и вынести туда же разъемы передней панели, кнопки и индикаторы.
Также организовать в легком доступе отсеки для подключения накопителей. А потом задвинуть все это к стенке или повесить на стену.
Идея оказалась стоящая и жива до сих пор, хотя нет уже DVD-приводов, да и жесткие диски встречаются все реже. Но именно такая концепция стенда продолжает жить и позволяет быстро и просто повысить удобство на рабочем месте.
И может оно выглядит не совсем эстетично, зато дешево, надежно и практично.
Вторая статья:
🔹 Админу на заметку - 3. Полезные инструменты для диагностики ПК
Тоже на эту тему, тогда мы только-только начали осваивать для себя китайские площадки и многие вещи оттуда были в диковинку.
Тестеры ATX-блоков питания пришлись ко двору и прижились, благо штука дешевая и полезная, позволяющая быстро проверить любой имеющийся в наличии блок питания.
До этого в арсенале была только металлическая скрепка, которой замыкали зеленый и черный провод, после чего можно было узнать – стартует блок или нет.
Но не более, напряжения на линиях и наличие сигнала готовности оставалось загадкой.
А вот POST-платы, по сути, оказались игрушкой. Любую материнку тех лет любой техник умел диагностировать по звуковым сигналам, выявляя основные неисправности.
Потом большинство производителей добавило эту функцию на сами платы, в виде семисегментных индикаторов или светодиодов. При этом шина PCI стала уходить в прошлое, а современные разъемы не предназначены для вывода на них диагностической информации.
Какое-то время мы еще пытались найти более-менее универсальное решение, но отказались, так как смысла и так было немного. Сейчас любая современная плата, ну кроме самых дешевых, покажет вам неисправность одного из основных компонентов.
Но все равно перечитывать такие материалы интересно, равно как возвращаться в те дни, с их проблемами и чаяниями, а потом сравнивать это с днем сегодняшним.
👍37❤3
Трассировка TCP
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
Для получение большей информации используйте запуск с ключом -?
В комментариях уже несколько раз спрашивали, как сделать трассировку по порту. Это нужно если у вас есть проблемы с доступностью сетевой службы, но при этом сетевая связность с конечным узлом присутствует и этот узел принимает соединения на указанных портах.
В этом случае проблема может быть где-то посередине, например, на пограничном роутере или провайдер фильтрует исходящие соединение по определенным портам (что очень часто бывает с почтой).
Поэтому именно такая трассировка поможет найти проблемный узел. В Linux все очень просто, достаточно поставить утилиту tcptraceroute, которая есть в репозиториях.
Потом все просто:
tcptraceroute ya.ru 443
Чтобы узнать все поддерживаемые ключи запустите утилиту без параметров.
Для Windows все немного сложнее, потребуются сторонние утилиты, например, Tcproute.exe, которая требует установки Pcap.Net.
После чего разместите утилиту в удобном месте и используйте:
tcproute ya.ru 443
Для получение большей информации используйте запуск с ключом -?
👍48❤3👎1
Не новое, но актуальное, так как коллеги продолжают раз за разом ходить по одним и тем же граблям
Токены и удаленный рабочий стол (RDP подключение)
Электронно-цифровая подпись (ЭЦП) и токены, как средство ее хранения, плотно вошли в нашу жизнь, трудно представить себе предприятие, где нет хотя бы одной подписи.
Другая распространенная технология - это удаленный рабочий стол (RDP), это может быть как сервер терминалов, так и просто доступ к рабочему месту сотрудника.
Вполне ожидаемы попытки использовать обе эти технологии совместно, где и начинаются проблемы. В большинстве своем они проистекают от непонимания того, что такое токен, для чего он нужен и как с ним правильно работать.
✅ Читать полностью
Токены и удаленный рабочий стол (RDP подключение)
Электронно-цифровая подпись (ЭЦП) и токены, как средство ее хранения, плотно вошли в нашу жизнь, трудно представить себе предприятие, где нет хотя бы одной подписи.
Другая распространенная технология - это удаленный рабочий стол (RDP), это может быть как сервер терминалов, так и просто доступ к рабочему месту сотрудника.
Вполне ожидаемы попытки использовать обе эти технологии совместно, где и начинаются проблемы. В большинстве своем они проистекают от непонимания того, что такое токен, для чего он нужен и как с ним правильно работать.
✅ Читать полностью
1👍22❤2🥱2
Про НДС
На фоне новостей, в которых Госдума приняла в первом чтении повышение НДС до 22%, странно слышать комментарии не только коллег, но и многих предпринимателей, мол ну чего там нам эти 2%...
🤷♀️ А вроде взрослые люди, одни с техническим образованием, другие умеют деньги считать…
❗️Ладно, возьмем такой загадочный предмет, как калькулятор. Странная такая машинка, ни интернета ей не надо, ни нейросетей, вместо процессора – огрызок какой-то допотопный, а поди ты – правильно цифры считает.
‼️ И посчитаем, что в условном товаре за 1000 руб. на прилавке НДС по ставке 20% содержится 166,67 руб. или 180,33 руб. по ставке 22%. Таким образом увеличение налоговой нагрузки составит 8,2%.
👉 На кого будет переложена эта нагрузка, думать не надо – на конечного покупателя, а 8,2%, согласитесь, это не каких-то там 2%, это уже на уровне официальной инфляции и способно ощутимо ударить по карману.
На фоне новостей, в которых Госдума приняла в первом чтении повышение НДС до 22%, странно слышать комментарии не только коллег, но и многих предпринимателей, мол ну чего там нам эти 2%...
🤷♀️ А вроде взрослые люди, одни с техническим образованием, другие умеют деньги считать…
❗️Ладно, возьмем такой загадочный предмет, как калькулятор. Странная такая машинка, ни интернета ей не надо, ни нейросетей, вместо процессора – огрызок какой-то допотопный, а поди ты – правильно цифры считает.
‼️ И посчитаем, что в условном товаре за 1000 руб. на прилавке НДС по ставке 20% содержится 166,67 руб. или 180,33 руб. по ставке 22%. Таким образом увеличение налоговой нагрузки составит 8,2%.
👉 На кого будет переложена эта нагрузка, думать не надо – на конечного покупателя, а 8,2%, согласитесь, это не каких-то там 2%, это уже на уровне официальной инфляции и способно ощутимо ударить по карману.
🤝44🤣6👏5👀4👍2
Осваиваем эффективную работу в Midnight Commander
Midnight Commander - популярный двухпанельный файловый менеджер, широко распространенный в UNIX-like операционных системах, он должен быть знаком каждому, кто хоть раз работал в консоли.
Но, как показывает практика, не все администраторы в полной мере используют все возможности данного приложения, ограничиваясь только базовыми, что может приводить к определенным неудобствам.
Поэтому сегодня ы расскажем о возможностях Midnight Commander и приемах, способных сделать работу в нем удобной и эффективной.
https://interface31.ru/tech_it/2020/10/osvaivaem-effektivnuyu-rabotu-v-midnight-commander.html
Midnight Commander - популярный двухпанельный файловый менеджер, широко распространенный в UNIX-like операционных системах, он должен быть знаком каждому, кто хоть раз работал в консоли.
Но, как показывает практика, не все администраторы в полной мере используют все возможности данного приложения, ограничиваясь только базовыми, что может приводить к определенным неудобствам.
Поэтому сегодня ы расскажем о возможностях Midnight Commander и приемах, способных сделать работу в нем удобной и эффективной.
https://interface31.ru/tech_it/2020/10/osvaivaem-effektivnuyu-rabotu-v-midnight-commander.html
🫡21👍20❤7
Из старенького, очень старенького, но актуального:
🔹 Как включить автоматический вход в систему для Windows
Зачем это надо?
Ну вот есть у вас домашний ПК и хотите вы утром просто его включить и попасть на рабочий стол без всяких этих самых явок и паролей.
Но в тоже время хотите к нему удаленно коннектиться из разных поездок и командировок.
А тут или пароль или никак. Или настроить автоматический вход.
И работает это даже в последних версиях Windows 10/11
🔹 Как включить автоматический вход в систему для Windows
Зачем это надо?
Ну вот есть у вас домашний ПК и хотите вы утром просто его включить и попасть на рабочий стол без всяких этих самых явок и паролей.
Но в тоже время хотите к нему удаленно коннектиться из разных поездок и командировок.
А тут или пароль или никак. Или настроить автоматический вход.
И работает это даже в последних версиях Windows 10/11
👍19🤣1
Критическая уязвимость CVE-2025-59287 в компоненте WSUS Windows Server
Вчера, 23 октября 2025 года Microsoft выпустило внеплановое (Out-of-Band, OOB) обновление для Windows Server.
Исправления устраняют критическую уязвимость CVE-2025-59287 в компоненте WSUS, которая позволяет удаленно выполнять произвольный код (Remote Code Execution, RCE).
👆 Уязвимости присвоен уровень CVSS:3.1 - 9.8 баллов, при этом ситуация усугубляется наличием публичного PoC-эксплоита.
Особенность эксплуатации данной уязвимости делает возможным ее каскадное использование между основным и подчиненными WSUS серверами, даже если последние не имеют непосредственного доступа во внешнюю сеть.
Рекомендуется не откладывая установить обновления автоматически (они доступны для скачивания через Windows Update) или вручную. Обновления являются накопительными, т.е. если вы пропустили более ранние обновления дополнительно их устанавливать не нужно.
В настоящий момент выпущены следующие пакеты обновлении:
▫️ Windows Server 2025 — KB5070881
▫️ Windows Server 23H2 — KB5070879
▫️ Windows Server 2022 — KB5070884
▫️ Windows Server 2019 — KB5070883
▫️ Windows Server 2016 — KB5070882
▫️ Windows Server 2012 R2 — KB5070886
▫️ Windows Server 2012 — KB5070887
При невозможности своевременно установить исправления Microsoft рекомендует выключить службу WSUS или заблокировать входящие соединения на портах 8530 и 8531.
Вчера, 23 октября 2025 года Microsoft выпустило внеплановое (Out-of-Band, OOB) обновление для Windows Server.
Исправления устраняют критическую уязвимость CVE-2025-59287 в компоненте WSUS, которая позволяет удаленно выполнять произвольный код (Remote Code Execution, RCE).
👆 Уязвимости присвоен уровень CVSS:3.1 - 9.8 баллов, при этом ситуация усугубляется наличием публичного PoC-эксплоита.
Особенность эксплуатации данной уязвимости делает возможным ее каскадное использование между основным и подчиненными WSUS серверами, даже если последние не имеют непосредственного доступа во внешнюю сеть.
Рекомендуется не откладывая установить обновления автоматически (они доступны для скачивания через Windows Update) или вручную. Обновления являются накопительными, т.е. если вы пропустили более ранние обновления дополнительно их устанавливать не нужно.
В настоящий момент выпущены следующие пакеты обновлении:
▫️ Windows Server 2025 — KB5070881
▫️ Windows Server 23H2 — KB5070879
▫️ Windows Server 2022 — KB5070884
▫️ Windows Server 2019 — KB5070883
▫️ Windows Server 2016 — KB5070882
▫️ Windows Server 2012 R2 — KB5070886
▫️ Windows Server 2012 — KB5070887
При невозможности своевременно установить исправления Microsoft рекомендует выключить службу WSUS или заблокировать входящие соединения на портах 8530 и 8531.
👍17🔥3
Управление серверами 1С:Предприятие
Начинающие (да и не только) администраторы системы 1С:Предприяите часто спрашивают, а есть ли кроссплатформенный аналог MMC-оснастке Администрирование серверов 1С Предприятия.
Обычно это происходит в свете перехода на Linux, но и не только. У стандартной MMC-консоли есть существенный недостаток – она использует COM-технологию и привязана к версии платформы.
Если у вас есть несколько серверов на разных версиях платформы, то вам постоянно придется перерегистрировать COM-компоненту на разные версии или использовать разные рабочие станции.
Альтернативой этому может служить веб-приложение от сторонних разработчиков – ПУСК, которое использует современный механизм управления серверами 1С:Предприятие – сервер администрирования RAS.
Как установить и настроить ПУСК мы рассказывали в этой статье:
🔹 Устанавливаем и настраиваем ПУСК - Панель Управления Сервисами и Компонентами для 1С:Предприятие
Но это тоже не всегда удобно, потому что требует специального развертывания и поддержки отдельного серверного приложения. Иногда надо что-то быстро и просто.
И такой инструмент есть, причем, что называется, из коробки. Но по странному стечению обстоятельств знают о нем очень немногие.
Речь идет о встроенной в платформу обработке Управление серверами. Для того, чтобы ее использовать вам потребуется любая информационная база 1С:Предприятие, даже полностью чистая, без конфигурации, в т.ч. файловая.
В ней переходим в Функции для технического специалиста – Стандартные – Управление серверами.
Работает она, как и ПУСК, через RAS, т.е. не зависит от установленной версии платформы. По функциям и возможностям она полностью повторяет стандартную MMC-консоль.
Начинающие (да и не только) администраторы системы 1С:Предприяите часто спрашивают, а есть ли кроссплатформенный аналог MMC-оснастке Администрирование серверов 1С Предприятия.
Обычно это происходит в свете перехода на Linux, но и не только. У стандартной MMC-консоли есть существенный недостаток – она использует COM-технологию и привязана к версии платформы.
Если у вас есть несколько серверов на разных версиях платформы, то вам постоянно придется перерегистрировать COM-компоненту на разные версии или использовать разные рабочие станции.
Альтернативой этому может служить веб-приложение от сторонних разработчиков – ПУСК, которое использует современный механизм управления серверами 1С:Предприятие – сервер администрирования RAS.
Как установить и настроить ПУСК мы рассказывали в этой статье:
🔹 Устанавливаем и настраиваем ПУСК - Панель Управления Сервисами и Компонентами для 1С:Предприятие
Но это тоже не всегда удобно, потому что требует специального развертывания и поддержки отдельного серверного приложения. Иногда надо что-то быстро и просто.
И такой инструмент есть, причем, что называется, из коробки. Но по странному стечению обстоятельств знают о нем очень немногие.
Речь идет о встроенной в платформу обработке Управление серверами. Для того, чтобы ее использовать вам потребуется любая информационная база 1С:Предприятие, даже полностью чистая, без конфигурации, в т.ч. файловая.
В ней переходим в Функции для технического специалиста – Стандартные – Управление серверами.
Работает она, как и ПУСК, через RAS, т.е. не зависит от установленной версии платформы. По функциям и возможностям она полностью повторяет стандартную MMC-консоль.
👍35🔥7❤4
Пятничное чтиво
На новогодних каникулах мы поднимали тему организации рабочего процесса, ценообразования, взаимоотношения с клиентами и всего этому сопутствующего.
Считаем, что перечитать эти заметки будет интересно и полезно, причем всем: кто работает на себя, кто рассматривает это как дополнительный заработок, только планирует или не планирует совсем.
Потому что даже при работе на дядю многое из изложенного будет полезно взять на вооружение.
🔹 Про почасовку (https://t.me/interface31/3678)
🔹 Вопрос ценообразования (https://t.me/interface31/3680)
🔹 Специалист ну очень широкого профиля (https://t.me/interface31/3682)
🔹 Проблема мелкого прайса (https://t.me/interface31/3686)
🔹 Про помогаторов (https://t.me/interface31/3691)
В комментариях предлагаем поделиться собственным взглядом по указанным вопросам.
На новогодних каникулах мы поднимали тему организации рабочего процесса, ценообразования, взаимоотношения с клиентами и всего этому сопутствующего.
Считаем, что перечитать эти заметки будет интересно и полезно, причем всем: кто работает на себя, кто рассматривает это как дополнительный заработок, только планирует или не планирует совсем.
Потому что даже при работе на дядю многое из изложенного будет полезно взять на вооружение.
🔹 Про почасовку (https://t.me/interface31/3678)
🔹 Вопрос ценообразования (https://t.me/interface31/3680)
🔹 Специалист ну очень широкого профиля (https://t.me/interface31/3682)
🔹 Проблема мелкого прайса (https://t.me/interface31/3686)
🔹 Про помогаторов (https://t.me/interface31/3691)
В комментариях предлагаем поделиться собственным взглядом по указанным вопросам.
👍21
Про мессенджеры
Тема мессенджеров сегодня одна из самых обсуждаемых, в жарких спорах ломается множество копий, но на наш взгляд – совершенно бесполезно, почему – расскажем в этой заметке.
Прежде всего давайте сразу отойдем от конкретных названий, технологий и реализаций, а посмотрим на вопрос более широко – с точки зрения обычного человека.
Что такое мессенджер для простого гражданина? Это средство коммуникации и чем более широка эта коммуникация – тем данное средство популярнее. И речь тут не только о контактах данного гражданина, но и о возможностях с кем-то связаться, кого в контактной книге нет.
Это могут быть новые знакомые, коллеги, заказчики, поддержка, продавцы, учителя, соседи. Да кто угодно. И если я знаю, что всегда легко найду их в этом мессенджере – то я буду им пользоваться. Если нет – то зачем он нужен?
Этим, собственно, и объясняется непопулярность различных «альтернативных» мессенджеров, в которых сидят по полтора землекопа, один из которых – разработчик.
Нет, вы можете, конечно, поставить этот мессенджер своим близким, коллегам и общаться в нем. Но это будет корпоративный чат – ни более, ни менее, ну или семейный. Сугубо междусобойчик, потому что для связи с внешним миром он чуть более чем полностью непригоден.
Никто не будет ставить еще одно непонятное приложение чтобы связаться с неким странным пассажиром, который игнорирует иные средства коммуникации. Хотя в нынешние времена относятся к этому снисходительно, каждый сходит с ума по-своему.
Поэтому, повторимся, ни один мессенджер не станет массовым пока с его помощью нельзя будет связаться с произвольным контактом из внешнего мира.
А что сподвигнет этот самый внешний мир использовать один мессенджер и не использовать другой? Правильно – размер аудитории. Что делать бизнесу в чате на полтора землекопа? Нечего ему там делать. А вот игнорировать популярные каналы коммуникации – глупо и недальновидно.
Поэтому бизнес там будет, бизнесу нужны каналы взаимодействия как с клиентами, так и с партнерами. Будет аудитория – будет бизнес. А будет бизнес – будет еще больше аудитории, которая будет использовать этот канал коммуникации.
А будет аудитория, будет бизнес – значит будет контент. Производители контента тоже не сидят на месте, никто ничего для полутора землекопов писать и публиковать не будет, так как публика эта абсолютно бесперспективная.
Для производства контента нужны две основные составляющие: читатели и рекламодатели, которые оплачивают производство контента для читателей. Не просто так оплачивают, к своей выгоде, разумеется, но именно так сегодня эта схема существует и никак иначе.
В результате, если мессенджер сумеет собрать вокруг себя три эти составляющие – он будет востребован и никому не будет дела кто и как его делает, насколько он технически совершенный и вся такая прочая ерунда.
Все это никому не интересно, как и не интересна переписка 99% пользователей, ибо она скучна и банальна. Да и сами пользователи ничего за собой такого не чувствуют, что требовалось бы обязательно от всех скрывать.
Им нужна возможность коммуникаций, причем как можно более широкая. И, желательно, все в одном месте, чтобы не приходилось с учителем общаться здесь, с врачом там, а с соседями еще где-то.
И чтобы тут же еще и новости почитать можно было, и пообщаться по интересам. В общем ничего нового. Вы же не будете покупать телефон, по которому можно звонить только на работу? А чтобы позвонить домой – покупать еще один телефон? А еще куда – третий?
Да, каждый из них может иметь свои преимущества, но по факту они никому не нужны, кроме тех самых полутора землекопов. Широким народным массам нужно универсальное и удобное средство коммуникации, при помощи которого он сможет связаться практически с каждым.
Игнорировать такие средства коммуникаций глупо, так как будете тем самым полуторным землекопом, на которого будут смотреть как на чудака. Ну не хочет человек общаться, как хочет, нам и без него хорошо. Подстраиваться под них никто не будет.
Тема мессенджеров сегодня одна из самых обсуждаемых, в жарких спорах ломается множество копий, но на наш взгляд – совершенно бесполезно, почему – расскажем в этой заметке.
Прежде всего давайте сразу отойдем от конкретных названий, технологий и реализаций, а посмотрим на вопрос более широко – с точки зрения обычного человека.
Что такое мессенджер для простого гражданина? Это средство коммуникации и чем более широка эта коммуникация – тем данное средство популярнее. И речь тут не только о контактах данного гражданина, но и о возможностях с кем-то связаться, кого в контактной книге нет.
Это могут быть новые знакомые, коллеги, заказчики, поддержка, продавцы, учителя, соседи. Да кто угодно. И если я знаю, что всегда легко найду их в этом мессенджере – то я буду им пользоваться. Если нет – то зачем он нужен?
Этим, собственно, и объясняется непопулярность различных «альтернативных» мессенджеров, в которых сидят по полтора землекопа, один из которых – разработчик.
Нет, вы можете, конечно, поставить этот мессенджер своим близким, коллегам и общаться в нем. Но это будет корпоративный чат – ни более, ни менее, ну или семейный. Сугубо междусобойчик, потому что для связи с внешним миром он чуть более чем полностью непригоден.
Никто не будет ставить еще одно непонятное приложение чтобы связаться с неким странным пассажиром, который игнорирует иные средства коммуникации. Хотя в нынешние времена относятся к этому снисходительно, каждый сходит с ума по-своему.
Поэтому, повторимся, ни один мессенджер не станет массовым пока с его помощью нельзя будет связаться с произвольным контактом из внешнего мира.
А что сподвигнет этот самый внешний мир использовать один мессенджер и не использовать другой? Правильно – размер аудитории. Что делать бизнесу в чате на полтора землекопа? Нечего ему там делать. А вот игнорировать популярные каналы коммуникации – глупо и недальновидно.
Поэтому бизнес там будет, бизнесу нужны каналы взаимодействия как с клиентами, так и с партнерами. Будет аудитория – будет бизнес. А будет бизнес – будет еще больше аудитории, которая будет использовать этот канал коммуникации.
А будет аудитория, будет бизнес – значит будет контент. Производители контента тоже не сидят на месте, никто ничего для полутора землекопов писать и публиковать не будет, так как публика эта абсолютно бесперспективная.
Для производства контента нужны две основные составляющие: читатели и рекламодатели, которые оплачивают производство контента для читателей. Не просто так оплачивают, к своей выгоде, разумеется, но именно так сегодня эта схема существует и никак иначе.
В результате, если мессенджер сумеет собрать вокруг себя три эти составляющие – он будет востребован и никому не будет дела кто и как его делает, насколько он технически совершенный и вся такая прочая ерунда.
Все это никому не интересно, как и не интересна переписка 99% пользователей, ибо она скучна и банальна. Да и сами пользователи ничего за собой такого не чувствуют, что требовалось бы обязательно от всех скрывать.
Им нужна возможность коммуникаций, причем как можно более широкая. И, желательно, все в одном месте, чтобы не приходилось с учителем общаться здесь, с врачом там, а с соседями еще где-то.
И чтобы тут же еще и новости почитать можно было, и пообщаться по интересам. В общем ничего нового. Вы же не будете покупать телефон, по которому можно звонить только на работу? А чтобы позвонить домой – покупать еще один телефон? А еще куда – третий?
Да, каждый из них может иметь свои преимущества, но по факту они никому не нужны, кроме тех самых полутора землекопов. Широким народным массам нужно универсальное и удобное средство коммуникации, при помощи которого он сможет связаться практически с каждым.
Игнорировать такие средства коммуникаций глупо, так как будете тем самым полуторным землекопом, на которого будут смотреть как на чудака. Ну не хочет человек общаться, как хочет, нам и без него хорошо. Подстраиваться под них никто не будет.
🥱22👍14🤔4💯4🤣1
Мифы и легенды про айтишников
В IT, как и в любой другой сложившейся отрасли, существует собственный свод мифов и легенд.
С одной из них уже достаточно давно приходится часто встречаться, в том числе и в обсуждениях на нашем канале.
В общем и целом, его смысл таков: живут на земле такие особые люди, как айтишники. И они крайне интересны целому пантеону злых сил, которые прямо кушать не могут, все об айтишниках думают.
Главным злом в этом пантеоне является мифический товарищ майор и некие мрачные органы. Им всем крайне интересно то, чем айтишник живет и дышит, поэтому основной своей задачей они считают расшифровать его трафик.
Для этого они, как и положено мифическим злодеям, идут на всякие ухищрения, например, распространяют отечественные сертификаты, чтобы потом как взять и завернуть весь трафик к себе, да как расшифровать его…
Для айтишника это, согласно каноническому тексту легенды, окажется фатальным, так как только ознакомившись с составом его трафика товарищ майор моментально вышлет в его адрес черный воронок и расстрельную команду и в лучшем случае придется бедному айтишнику пилить ангарскую сосну тупым лобзиком на свежем и морозном воздухе.
За что, легенда умалчивает, ну наверное есть за что, он же айтишник.
За товарищем майором идут злодеи поменьше, всякие корпорации и прочие производители ПО, которые тоже активно интересуются нашим айтишником, для этого они внедряют в свои продукты всякие телеметрии, которые активно рыщут по всем углам и передают, передают, передают данные.
Что будет с айтишником после того, как его данные попадут злобным корпорациям, текст легенды умалчивает, но ясно, что ничего хорошего. Ведь он же айтишник.
Да и вообще, темные силы не спят, поэтому настоящий айтишник всегда проверяет адрес сайта в адресной строке посимвольно, внимательно рассматривает каждую строку сертификата, сверяет хеши загружаемых файлов и вообще постоянно бдит, не расслабляется, ну что бы с ним не стало как с той собачкой из анекдота.
А еще настоящий айтишник нигде и никогда не регистрируется под собственным именем, только под вымышленным, чтобы сбить со следа товарища майора и злобные силы поменьше.
В общем, в том или ином виде эту легенду слышал каждый, но и не только слышал, у нее довольно широкий круг последователей.
Которые шифруют VPN для полазить в интернете самым стойким шифром, ну и что что канал стал вдвое уже, а на роутере можно жарить яичницу.
Выпиливают с корнями телеметрию, ну и пусть система после этого глючит.
Регистрируют важные сервисы на Васю Пупкина, ну и фиг с ними, возможными проблемами с поддержкой.
Спорить с технических и рациональных позиций с ними невозможно, потому что в ответ вы услышите, что даже если никогда такого не было, то обязательно будет, или было уже, но никому не сказали, ну потому, что товарищ майор и органы не дремлют…
Мы долго думали, откуда и почему такая легенда возникла и ниже приведено наше личное мнение.
За все время существования профессии, да и сейчас, но ранее – особенно, айтишники были такой привилегированной кастой. Это некие странные люди, со своим непонятным языком и поведением, которые умеют управлять всей этой «бисовой техникой». Шаманы и заклинатели змей в одном лице.
Оплата в рамках профессии тоже всегда была на уровне от средней и выше. Поэтому типичный айтишник, особенно молодого поколения, не заставший в сознательном возрасте «святых 90-х» крайне далек от реальной жизни на земле, проблем и чаяний пролетариата и прочих представителей городской флоры и фауны.
С серьезным криминалом наш айтишник не сталкивался и единственный известный ему сотрудник органов – это инспектор ГИБДД, ну может еще участкового пару раз видел.
В общем, как говорил классик, крайне далеки они от народа.
Ну а какие представления о жизни на земле, такие и злодеи. Ну и про себя, любимого, как вершину мироздания не нужно забывать.
Ведь по каноническому тексту айтишник всех побеждает, он же шифрует, выпиливает, закрывает, огораживает и сам успешно шифруется, постоянно оставляя злые силы с носом. Ну по-другому и быть не может, ведь он же айтишник.
В IT, как и в любой другой сложившейся отрасли, существует собственный свод мифов и легенд.
С одной из них уже достаточно давно приходится часто встречаться, в том числе и в обсуждениях на нашем канале.
В общем и целом, его смысл таков: живут на земле такие особые люди, как айтишники. И они крайне интересны целому пантеону злых сил, которые прямо кушать не могут, все об айтишниках думают.
Главным злом в этом пантеоне является мифический товарищ майор и некие мрачные органы. Им всем крайне интересно то, чем айтишник живет и дышит, поэтому основной своей задачей они считают расшифровать его трафик.
Для этого они, как и положено мифическим злодеям, идут на всякие ухищрения, например, распространяют отечественные сертификаты, чтобы потом как взять и завернуть весь трафик к себе, да как расшифровать его…
Для айтишника это, согласно каноническому тексту легенды, окажется фатальным, так как только ознакомившись с составом его трафика товарищ майор моментально вышлет в его адрес черный воронок и расстрельную команду и в лучшем случае придется бедному айтишнику пилить ангарскую сосну тупым лобзиком на свежем и морозном воздухе.
За что, легенда умалчивает, ну наверное есть за что, он же айтишник.
За товарищем майором идут злодеи поменьше, всякие корпорации и прочие производители ПО, которые тоже активно интересуются нашим айтишником, для этого они внедряют в свои продукты всякие телеметрии, которые активно рыщут по всем углам и передают, передают, передают данные.
Что будет с айтишником после того, как его данные попадут злобным корпорациям, текст легенды умалчивает, но ясно, что ничего хорошего. Ведь он же айтишник.
Да и вообще, темные силы не спят, поэтому настоящий айтишник всегда проверяет адрес сайта в адресной строке посимвольно, внимательно рассматривает каждую строку сертификата, сверяет хеши загружаемых файлов и вообще постоянно бдит, не расслабляется, ну что бы с ним не стало как с той собачкой из анекдота.
А еще настоящий айтишник нигде и никогда не регистрируется под собственным именем, только под вымышленным, чтобы сбить со следа товарища майора и злобные силы поменьше.
В общем, в том или ином виде эту легенду слышал каждый, но и не только слышал, у нее довольно широкий круг последователей.
Которые шифруют VPN для полазить в интернете самым стойким шифром, ну и что что канал стал вдвое уже, а на роутере можно жарить яичницу.
Выпиливают с корнями телеметрию, ну и пусть система после этого глючит.
Регистрируют важные сервисы на Васю Пупкина, ну и фиг с ними, возможными проблемами с поддержкой.
Спорить с технических и рациональных позиций с ними невозможно, потому что в ответ вы услышите, что даже если никогда такого не было, то обязательно будет, или было уже, но никому не сказали, ну потому, что товарищ майор и органы не дремлют…
Мы долго думали, откуда и почему такая легенда возникла и ниже приведено наше личное мнение.
За все время существования профессии, да и сейчас, но ранее – особенно, айтишники были такой привилегированной кастой. Это некие странные люди, со своим непонятным языком и поведением, которые умеют управлять всей этой «бисовой техникой». Шаманы и заклинатели змей в одном лице.
Оплата в рамках профессии тоже всегда была на уровне от средней и выше. Поэтому типичный айтишник, особенно молодого поколения, не заставший в сознательном возрасте «святых 90-х» крайне далек от реальной жизни на земле, проблем и чаяний пролетариата и прочих представителей городской флоры и фауны.
С серьезным криминалом наш айтишник не сталкивался и единственный известный ему сотрудник органов – это инспектор ГИБДД, ну может еще участкового пару раз видел.
В общем, как говорил классик, крайне далеки они от народа.
Ну а какие представления о жизни на земле, такие и злодеи. Ну и про себя, любимого, как вершину мироздания не нужно забывать.
Ведь по каноническому тексту айтишник всех побеждает, он же шифрует, выпиливает, закрывает, огораживает и сам успешно шифруется, постоянно оставляя злые силы с носом. Ну по-другому и быть не может, ведь он же айтишник.
🤮33😁21💯12👍7❤5
Подборка про самосбор
Самосбор – тема вечно живая, полемическая, с множеством за и против. Мы тоже немало писали на эту тему, поэтому решили собрать все в одном месте:
🔹 Гарантия по другую сторону баррикад, часть 3, самосбор (https://t.me/interface31/1366)
🔹 Самосбор, почему это не самая лучшая идея (https://t.me/interface31/1441)
🔹 И снова о вреде самосбора (https://t.me/interface31/2062)
🔹 И снова про самосбор серверов (https://t.me/interface31/2137)
🔹 Про сборку (https://t.me/interface31/4774)
🔹 Неочевидные опасности самосбора для опытных (https://t.me/interface31/4776)
👆 А если коротко и по делу, то наше мнение такое: если сборка ПК для вас не является хобби (или работой), и вы не готовы к дополнительным финансовым и/или временным затратам – то оставьте процесс сборки тому, кто получает за это деньги.
Особенно если вам нужен компьютер, который нужно просто включить и работать, а приключения – это то, что нужно вам в последнюю очередь.
Самосбор – тема вечно живая, полемическая, с множеством за и против. Мы тоже немало писали на эту тему, поэтому решили собрать все в одном месте:
🔹 Гарантия по другую сторону баррикад, часть 3, самосбор (https://t.me/interface31/1366)
🔹 Самосбор, почему это не самая лучшая идея (https://t.me/interface31/1441)
🔹 И снова о вреде самосбора (https://t.me/interface31/2062)
🔹 И снова про самосбор серверов (https://t.me/interface31/2137)
🔹 Про сборку (https://t.me/interface31/4774)
🔹 Неочевидные опасности самосбора для опытных (https://t.me/interface31/4776)
👆 А если коротко и по делу, то наше мнение такое: если сборка ПК для вас не является хобби (или работой), и вы не готовы к дополнительным финансовым и/или временным затратам – то оставьте процесс сборки тому, кто получает за это деньги.
Особенно если вам нужен компьютер, который нужно просто включить и работать, а приключения – это то, что нужно вам в последнюю очередь.
👍16🤔6💯2❤1🤡1
Как и зачем делить базы данных по отдельным установкам СУБД
В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять.
Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.
Поэтому вместо этого мы рассмотрим общие принципы, и вы могли понять для чего и зачем мы плодим установки и какие плюсы от этого получаем.
Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.
Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.
Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память.
Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.
Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные.
При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.
Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.
Весь месяц бухгалтерия тихо вбивает первичку, проводит оплаты, а торговля торгует, получает остатки, взаиморасчеты, резервы и задолженности. Кеш прогрет, его хватает обоим базам и вроде бы все хорошо.
Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты.
Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле.
При этом у бухгалтерии все хорошо, у них все летает, а у торговли раньше резервы или задолженность считались за пару секунд, а теперь программа тупит десятками секунд или минутами. Что вызывает сплошной негатив пользователей.
Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия.
Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.
Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.
Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.
Но теперь мы можем анализировать и оптимизировать выделение ресурсов под единственный характер нагрузки. Можем делать быстрее, можем медленнее, но самого плохого сценария – качелей, когда сегодня все летает, а завтра все тормозит – мы избежим.
При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.
В комментариях также спрашивали, как и по каким принципам делить базы по установкам экземпляров сервера БД и сколько памяти кому выделять.
Если брать конкретные цифры, то дать тут общие рекомендации сложно, нужно смотреть на сценарии применения, объемы данных, интенсивность и характер обращения к СУБД, в общем – требуется индивидуальный подход.
Поэтому вместо этого мы рассмотрим общие принципы, и вы могли понять для чего и зачем мы плодим установки и какие плюсы от этого получаем.
Описывая модель нами сознательно предельна упрощена и не требует каких-либо специфических знаний, а также применима к любым СУБД, а не только PostgreSQL.
Одной из задач СУБД – является быстрое и эффективное предоставление прикладному ПО доступа к хранящихся в базе данных. А получить мы их можем одним единственным образом – прочитать с диска.
Но чтение с диска – процесс дорогой и достаточно медленный. Поэтому, чтобы избежать повторного чтения СУБД помещает поднятые с диска данные в оперативную память. И делать так она будет до тех пор, пока будет иметь доступную память.
Именно этим объясняется известное всем стремление SQL-серверов занять всю доступную память. В простейших случаях, когда база по размеру гораздо меньше, чем размер оперативной памяти, то она будет закеширована практически вся.
Если же суммарный размер данных больше размера доступной памяти, то данные в кеше будут иметь приоритет по количеству обращений к ним. Таким образом более горячие данные будут вытеснять более холодные.
При достаточном количестве памяти через некоторое время будет достигнут некоторый баланс и все горячие данные будут в кеше. Иначе одни будут постоянно вытеснять другие и СУБД будет вынуждена постоянно прибегать к дисковому чтению.
Хотя это не всегда плохо, с появлением быстрых дисков, таких как NVMe, иногда более оптимально будет читать данные с диска, нежели тратить на их хранение достаточно ограниченный ресурс оперативной памяти.
А теперь про то, зачем делить базы по разным экземплярах СУБД. Представим, что у нас есть некоторый единый сервер, где находятся базы торгового подразделения и бухгалтерии.
Весь месяц бухгалтерия тихо вбивает первичку, проводит оплаты, а торговля торгует, получает остатки, взаиморасчеты, резервы и задолженности. Кеш прогрет, его хватает обоим базам и вроде бы все хорошо.
Но вот наступает конец месяца, и бухгалтерия начинает закрывать месяц, готовить отчетность, начислять зарплату, считать налоги, формировать регламентированные отчеты.
Объем потребляемых ею данных резко вырастет, и они просто вытеснят из кеша данные торгового отдела. И чем активнее будет работать бухгалтерия, тем хуже будет торговле.
При этом у бухгалтерии все хорошо, у них все летает, а у торговли раньше резервы или задолженность считались за пару секунд, а теперь программа тупит десятками секунд или минутами. Что вызывает сплошной негатив пользователей.
Также возможен обратный сценарий, когда торговля активно подбивает итоги и тормозит уже бухгалтерия.
Какой выход? В лоб – добавить память. Но опять-таки мы не можем гарантировать, что кто-то не перетянет на себя все одеяло, разве что памяти с запасом хватит на всех. Но это не про современные объемы данных.
Поэтому просто делим один экземпляр СУБД на два и каждому выделяем свое количество памяти. Да, в итоге каждый получит меньше, чем мог бы откусить из общей кучи и может начать работать немного медленнее.
Но это будет гарантированная производительность, особенно после того, как вы определите достаточный объем памяти для хранения всего горячего кеша. Соседи могут делать все, что угодно. Равно как и вы.
Но теперь мы можем анализировать и оптимизировать выделение ресурсов под единственный характер нагрузки. Можем делать быстрее, можем медленнее, но самого плохого сценария – качелей, когда сегодня все летает, а завтра все тормозит – мы избежим.
При этом накладные расходы на дублирование экземпляров СУБД минимальные, особенно если мы используем контейнеры.
👍25❤3