​​Субботнее, общественно-политическое. Безусловный базовый доход

Когда мы обсуждали негативные последствия автоматизации и роботизации, то неоднократно всплывала тема безусловного базового дохода, как мера поддержки тех, кто остался без работы по причине замены человека автоматом.

На первый взгляд идея интересная и здравая, но только на первый взгляд.

Представим себе, что наступило некоторое светлое или не очень будущее, в котором уровень автоматизации, роботизации и ИИ вытеснил очень многие начальные профессии и масса низкоквалифицированной рабочей силы выплеснулось на рынок труда.

Чтобы избежать массовых социальных волнений государство вводит безусловный базовый доход. Просто так, для любого желающего. Нет работы – держи ББД. Причем делает его не уровня МРОТ, на котором только ноги протянуть, а примерно по уровню медианной зарплаты, чтобы вся эта масса не сильно просела в доходах.

Если брать нашими деньгами, то это где-то 40-50 тыс. Первоначально все будет очень даже хорошо, кто-то, наоборот, даже вырастет, ибо не получал столько на своей кассе в Пятерочке, а тут и делать ничего не надо.

Понятно, что на эту тему тут же присядут всякие люмпены, цыгане и прочие маргинальные слои. Кто-то сразу сопьется, кто-то сторчится. Но это нормально, это все в рамках действующей модели.

При этом текущая общественная модель не подразумевает какого-то открытого разделения общества на касты. В основном имеет место имущественное расслоение, но тут все дороги открыты – иди, работай, зарабатывай.

В нашем же обществе возникнет такое разделение и будет оно проходит по уровню образования. Потому что в игре останутся только достаточно квалифицированные кадры, в т.ч. и рабочие. Так как станки будут поголовно с ЧПУ и даже сварочные аппараты будут «умными».

И перейти из одной касты во вторую будет достаточно проблемно, так как переучиться смогут далеко не все, очень мало кто сможет на самом деле.

По факту общество будет разделено на касты «тупых» и «умных», первым не светит ничего выше ББД, а вторые будут получать весьма неплохие деньги, что добавит еще и имущественный разрыв между этими кастами.

А теперь рассмотрим состав этих каст. «Тупые» — это преимущественно лица физически сильные, привыкшие к физической работе и к рефлексиям не склонные. Выросшие на улице, привычные к силовому решению вопроса, мелкому криминалу и физическому насилию.

«Умные» – полная их противоположность, это люди, привыкшие к умственному труду, нахождению компромиссов, решению сложных вопросов при помощи переговоров, а все их прегрешения перед законом в основном записаны в Правилах дорожного движения.

При этом «умные» у нас заняты, «умные» работают им некогда предаваться всяким непотребствам.

А вот «тупые» предоставлены сами себе, работать им не надо, свободного времени – завались. А вот материальных ценностей как раз остро не хватает. Естественно, праздный ум будет занят тем, что думать о том, как эти материальные ценности получить.

И если нет пути легального, то в ход пойдут методы нелегальные, начиная от тупого гоп-стопа, квартирных краж и угонов, до образования масштабных ОПГ, которые будут действовать уже совсем в иных масштабах.

А дальше сращивания криминала и власти, после чего мы получим то, что уже видим на примере диаспор, только в более глобальном масштабе. После чего общество еще больше поляризуется, так как маркером свой-чужой будет даже не национальный, а образовательный признак.

После чего «святые 90-е» покажутся цветочками, так как там вопрос стоял именно в перераспределении имущественных ценностей, а не носил национального или классового, как в нашем случае, характера.

В тоже время история знает, что самые ожесточенные конфликты – это именно межнациональные или межклассовые.

Поэтому, безусловный базовый доход – это только на первый взгляд хорошо, но в долгую это бомба замедленного действия. Более правильными видятся лимиты на автоматизацию, которые будут сохранять рабочие места, даже если их можно заменить роботами.

Коллеги, кто успел поработать с Edge-Core EAP101?

Цена на площадках приятная, возможностей много, поддерживает Wi-Fi 6 c 2×2:2 MU-MIMO, 2,5 Гбит/с порт, BLE/ Zigbee, PoE, есть возможность управления через софт-контроллеры.

Есть желание опробовать на загородном доме коллеги.

https://wifi.edge-core.com/access-point/wifi-6-access-point/eap101/

​​Советские ПК. Часть 1

Компьютеризация в Советском союзе – тема сложная и неоднозначная. И сейчас, когда многое уже забылось и выросло поколение никогда Союза в глаза не видевшая, появляются мнения, что советская компьютерная индустрия — это то, что мы потеряли.

На самом деле все было совсем по-другому и советские компьютеры вполне закономерно пришли туда, куда пришли и причин тому было множество. Чтобы не быть голословными мы будем опираться на публикации тех лет, в частности журнала Радио.

Необходимость компьютеризации на уровне широких масс в СССР поняли уже в первой половине 80-х. К этому времени на Западе уже был развитый рынок недорогих 8-битных ПК и делал свои первые шаги IBM PC.

Рынок в СССР в первую очередь состоял из образовательных заведений и спроса частных лиц, который был прежде всего от ИТР и энтузиастов. Чтобы понимать потребности выполним небольшие вычисления.

На 90 год в СССР было 135,9 тыс. школ и 4556 СУЗов. Даже если брать по одному компьютерному классу на 25 машин, то получаем емкость рынка в 3,5 млн. ПК.

Количество рабочей силы в СССР было 152,3 млн человек. Даже если мы поделим его на шесть (средний размер семьи + бабушки-дедушки) и прикинем, что ПК был нужен только 10% оставшихся, то получим еще 2,5 млн ПК. Таким образом общий рынок можно оценивать в 6 млн. ПК.

Что у нас было на этом рынке? Начнем с БК-0010, это был 16-разрядный ПК по системе команд полностью совместимый с PDP-11 и частично совместимый с ним по архитектуре и многие считают его лучшим из бытовых ПК советской эпохи.

Производство ПК началось в 1985 году и всего было выпущено 162 тыс. ПК. Это при емкости рынка около 6 млн. Просто брызги. А если учесть, что большая часть выпушенных ПК уходила в учебные заведения до розницы, доходили единицы, не способные решить вопрос дефицита.

При этом цена компьютера составляла 600 руб. (позже 650 руб.), что равнялось трем месячным зарплатам инженера.

А что писала советская пресса, Радио №6 87, интервью с директором завода производителя «Тернистый путь БК в наш дом».

- О трудностях с приобретением персональных бы¬товых компьютеров в нынешнем году нам известно. А станет ли легче купить их в ближайшем будущем!

- Не думаю, хотя и планируется значительно увеличить выпуск БК-0010. Главная наша задача — обеспечить машинами школы, ПТУ, техникумы.

Но это еще не все, палки в колеса и так буксующей отрасли начали вставлять родные бюрократы:

Но может так случиться, что БК вообще перестанет выпускаться. С 1 июля 1987 г. вводится ГОСТ… Так что если с 1 июля от час будут требовать выполнения ГОСТа, то производство микро-ЭВМ нам придется прекратить.

Ну да ладно, не прекратили и худо-бедно продолжили выпускать в целом неплохую машину, но в очень и очень малых количествах. Но для ПК нужно ПО, а где его взять?

- Больной вопрос для многих пользователей БК — ПО. Далеко не каждый может написать программы сам, а купить их пока негде.

- Проблема выпуска ПО из технической пере¬росла в социальную. Ведь для ликвидации компьютерной неграмотности надо дать возможность пользоваться вычислительной техникой всем желающим. Пока же использовать бытовые компьютеры могут лишь те, кто спосо¬бен самостоятельно создать программное обеспечение.

При этом отрасль в очередной раз сталкивалась с бюрократическими препонами:

На программы, например, до сих пор нет авторского права. До сих пор не известно, кто же должен определять воспитательный и идеологический уровень программ (особенно это важно для … игр). Нет и прейскуранта, позволяющего определить цены на программы.

В общем писать софт вроде бы и способны, но как его выпустить на рынок? В результате для БК было написано около 800 программ, преимущественно энтузиастами любителями.

И только в последние годы Союза кооперативами было выполнено, говоря современным языком, портирование приблизительно около 4000 программ со Spectrum, преимущественно игр.

Фактически БК, имея неплохой технический задел так и не смог выполнить своей главной задачи. Компьютеров было выпущено очень мало, еще хуже обстояла ситуация с ПО к ним.

А мы что? А мы ничего...

Рунет снова плющит и колбасит, под раздачу снова попали средства удаленного доступа и многое многое другое.

Кто виноват? Виноваты злые "буржуины":

Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) фиксирует проблемы в доступности ряда сервисов. Неработоспособность ряда сервисов связана с использованием иностранной серверной инфраструктуры, на которой и фиксируются сбои. Рекомендуем отечественным организациям пользоваться мощностями российских хостинг‑провайдеров

Только сами "буржуины" об этом почему-то не знают... 🤷‍♀️🤷‍♀️🤷‍♀️

В свете дневных событий. Статья не старая, а очень даже свежая, сентябрьская:

🔹 Устанавливаем и настраиваем Aspia - бесплатную программу для удаленного управления ПК

Данная система в плотной эксплуатации у нас с сентября и зарекомендовала себя только с хорошей стороны.

▫️ Легкая установка и настройка, на клиент можно передать набор с уже готовыми настройками.

▫️Адресные книги. Книг можно наделать множество, для разных пользователей с разными правами.

▫️ Стабильная работа, даже на плохих каналах.

▫️ Много разных сервисных возможностей. В т.ч. запись видео без подтверждения с той стороны.

Есть и минусы:

🔸 Сборка серверной части под устаревшие дистрибутивы

🔸 Клиентская часть только для Windows

🔸 Нет мобильного приложения.

Но если сравнивать с позиции именно инструмента регулярной поддержки, а не разовых подключений и для большого числа узлов, то Aspia выглядит предпочтительнее своего основного конкурента Rustdesk.

🚀 Представляем наш новый комплексный курс: "Полный путь WEB-разработчика".

🔥Чему вы научитесь:🔥

✔Освоите весь стек современных web-технологий: от HTML и CSS до Node.js и SQL
✔Создадите множество реальных проектов, включая Todo-приложение, трекер расходов, приложение-викторину
✔Разработаете собственные API и полноценные Full-Stack приложения
✔Изучите работу с Git, MongoDB, React, NextJS и многое другое
ㅤ
🔥Преимущества курса:🔥ㅤ

✔Дистанционный формат обучения
✔Практические задания после каждой темы
✔Проекты для вашего портфолио
✔Поддержка опытных менторов
ㅤ
🔥По окончании вы получите (один документ на выбор):🔥ㅤ

✔Диплом о профессиональной переподготовке
✔Удостоверение о повышении квалификации
ㅤ
Не упустите возможность получить востребованную профессию и начать карьеру в IT!ㅤ

 👉 Ссылка на курс: web.dms-it.ru

#реклама
О рекламодателе

​​Вкалывают роботы, но счастлив ли человек? Серия номер следующая

Сегодня совершенно нежданно-негаданно закончился домашний интернет Мегафон, причем все признаки указывали на то, что закончились деньги.

Ну этому у Мегафона удивляться совершенно не следует, в чем я убедился еще прошлым летом. У меня на такие вещи обычно настроено автоматическое списание и во избежание всякого-разного непонятного я настроил его на 25 число.

Полгода все работало нормально, но в один не очень прекрасный момент все отвалилось. Я как раз был далеко за городом в командировке и было совершенно не ясно, что произошло, то ли интернет сломался, то ли электричества дома нет, то ли еще что.

Вечером родные подтвердили, что все включено, все норм, но интернета нет. Звоню в Мегафон, тогда там еще стоял обычный автоответчик, быстро вызываю оператора, немного жду и узнаю, что денег нет.

Как так нет? Сегодня же только 24 число? Но выяснилось, что месяц в тарификации Мегафона это просто 30 календарных дней и поэтому дата оплаты постоянно плавает.

Ладно, оплатил, потом в ЛК нашел что можно сделать списание с привязкой к дате оплаты и снова стало все хорошо.

И вот сегодня днем снова пропал интернет и снова с похожими симптомами. Хотя вчера сумма платежа списалась. Номер, на который все привязано, у сына, сын в школе. Тревожит не стал. Просто закинул еще сумму месячного платежа. Не помогло.

Ну тогда будем звонить. И тут начался полный треш. Вместо автоответчика там теперь голосовой помощник с ИИ и опция оператор изначально недоступна.

Ладно, пообщаемся с этой то ли Алисой, то ли Марусей, она так и не представилась. Подтверждаю, что меня интересует домашний интернет после чего сей интеллект задает мне вопрос, о чем бы я с ней хотел поговорить…

Оригинальный подход, наверно я звоню в поддержку, потому что мне скучно и хочется поболтать. Но болтать я не намерен и сразу перехожу к делу:

- Не работает интернет
- Мне очень жаль, что так получилось (мне тоже очень и очень жаль, если выражаться мягко), но я попробую вам помочь. Ваш вопрос связан с домашним интернетом, да или нет?

- Да (хотя зачем спрашивать, мы и так в разделе домашнего интернета)

- Он связан с тем же вопросом, по которому вы обращались ранее? Да или нет?

А я помню, о чем я обращался ранее? Тоже, наверное, интернет не работал.

- Да

- Попробуйте по-другому сформулировать свой вопрос. Простыми и понятными фразами.

Куда уж проще:

- НЕ РАБОТАЕТ ИНТЕРНЕТ – диктую практически по буквам и снова ухожу на второй круг.

- Мне очень жаль, что так получилось…

Ладно, меняем тактику:

- Баланс

ИИ бодро озвучивает мне сумму месячного платежа, т.е. второй платеж не списался. Снова спрашиваю за интернет, формулируя вопрос по-разному:

- Интернет не работает
- Нет услуги домашний интернет
- Не открываются сайты

Но в ответ слышу только сожаления, стандартный набор вопросов и предложение изъясняться нормально.

Начинаю пробовать вызвать оператора и снова:

- Сформулируйте понятно вопрос, по которому вы хотите, чтобы вас переключили на оператора.

- Я не поняла ваш вопрос, задайте его повторно…

Терпение стремительно иссякает, и я просто обкладываю голосового помощника матом, не стесняясь в выражениях. И чудо:

- Я понимаю, что вы расстроены, но такие выражения не следует использовать… и вдруг идет переключение на оператора.

Оператор чего-то где-то поколдовал и интернет мигом появился. На вопрос что это было ответил стандартно – сессия зависла. Попытка выяснить подробности, успехом не увенчалась. Да, деньги есть, да, сессия повисла, да бывает. Еще вопросы есть? Нет. До свидания.

Я понимаю, что цель всего этого непотребства именно высвободить и уменьшить количество живых операторов, но тогда вы свою Марусю или Алису сделайте хоть немного умнее, чтобы она хотя бы могла проверить состояние линии и ту же сессию сбросить. Там много ума не надо, если девочки с первой линии справляются.

Серьезно обновлена, дополнена и актуализирована статья:

🔹 Нормативное регулирование Wi-Fi в Российской Федерации

▫️ Дополнен и актуализирован раздел по 5 ГГц

▫️ Добавлены разделы 6 ГГц и 60 ГГц

​​Проблема медленного клиента в Wi-Fi сетях

Многие читатели высказывают скептическое отношение к современным стандартам Wi-Fi, мол все это ни к чему, когда есть старый-добрый 802.11n, да и 2,4 ГГц добивает дальше. Но не все так просто и в этой заметке постараемся коротко рассказать об этом.

Начнем с того, что канал Wi-Fi – это разделяемая среда и пропускная способность канала делится поровну между всеми ее участниками.

Стандарт предусматривает разделение эфирного времени на слоты по количеству переданных устройством пакетов, что гарантирует каждому клиенту возможность передать или принять определенный объем данных.

Идем дальше. Ширина канала также является фиксированной и объем данных, которые мы можем по нему передать за единицу времени зависит от используемого метода модуляции (изменения электромагнитной волны таким образом, чтобы закодировать в ней данные).

Чем более сложную модуляцию мы используем – тем выше скорость передачи данных, но тем ниже помехоустойчивость такого сигнала.

Для примера возьмем квадрат определенного размера и разметим его сеткой 2х2 – получим 4 ячейки, если же возьмем сетку 4х4 – то ячеек уже будет 16, а при размере сетки 8х8 целых 64. Исходный квадрат у нас будет обозначать доступную полосу, а сетка – модуляцию.

А теперь давайте будем удалять наши квадраты на некоторое расстояние от наблюдателя, первым потеряет читабельность сетка 8х8, затем 4х4 и т.д.

Точно также и в беспроводных сетях. Чем ниже уровень сигнала и/или выше уровень помех, тем более простой метод модуляции будет использоваться.

Все стандарты до 802.11n (Wi-Fi 4) включительно предусматривают работу по принципу «один говорит – остальные молчат», т.е. точка одновременно работает только с одним клиентом.

Начиная со стандарта 802.11ac (Wi-Fi 5) предусмотрен режим многопользовательского MIMO, когда точка может передавать данные одновременно сразу нескольким клиентам (но не наоборот).

Такое решение позволило улучшить передачу потокового мультимедиа и улучшить пользовательские характеристики беспроводной сети.

В 802.11ax (Wi-Fi 6) добавили исходящие потоки и теперь точка может не только передавать, но и принимать данные от нескольких клиентов одновременно.

А теперь вернемся к проблеме медленного клиента. Под медленным клиентом может подразумеваться два типа устройств: устройство с устаревшим стандартом и устройство того же стандарта, но со слабым уровнем сигнала.

Начнем с устаревших, эта проблема наиболее характерна для диапазона 2,4 ГГц, даже если точка поддерживает все современные стандарты, например, как в новых Mikrotik 802.11b/g/n/ax (Wi-Fi 6), то в такой сети у нас всегда найдутся устройства 802.11n.

Что это значит? А это значит, что во время работы такого устройства все клиенты 802.11ac/ax будут молчать и точка не будет передавать им данные даже если могла бы это сделать.

В итоге мы теряем все преимущества новых стандартов и фактически опускаемся на уровень производительности сети 802.11n, особенно если старых устройств много.

С медленным клиентом того же стандарта проблема немного иная. В силу плохого уровня приема и низкого соотношения сигнал/шум он будет использовать простые методы модуляции, а следовательно, занимать больше эфирного времени.

При высокой активности такого клиента или большого их количества скорость передачи всей сети будет стремиться к скорости самого медленного устройства.

Т.е. если ваша бабушка слушает музыку с высоким качеством пропалывая грядки на краю участка страдать будет производительность и вашего нового и крутого смартфона в паре метров от точки доступа.

Поэтому самым разумным способом на сегодняшний день является использование двух диапазонов: 5 ГГц и 2,4 ГГц.

В первом будут собраны преимущественно современные устройства и работать будут как минимум на уровне 802.11ac, а все старые устройства сбросим на 2,4 ГГц на 802.11n.

Туда же будут переключаться и все устройства со слабым сигналом, и более низкая дальность 5 ГГц здесь только играет в плюс.

​​Почему не следует использовать ретрансляторы Wi-Fi

Если не хватает покрытия беспроводной сети, то обычный пользователь идет в магазин и покупает там ретранслятор, он же повторитель, и он же усилитель беспроводного сигнала.

Ну а что, просто, дешево и сердито. Воткнул в розетку и Wi-Fi снова появился. При этом мало кто задумывается над неочевидными подводными камнями данного решения.

А подводных камней там хватает. Практически все повторители, а в бюджетном сегменте поголовно все работают на той же частоте что и базовая точка доступа, т.е. занимают один и тот же канал, полоса пропускания которого делится на все беспроводные устройства.

Ширина канала – величина строго ограниченная, как и количество данных, которые мы можем передать за единицу времени. Время доступа к каналу также равномерно делится между всеми подключенными устройствами.

Причем делится оно не по времени, а по количеству переданных пакетов. Т.е. медленный клиент будет занимать больше эфирного времени для передачи одного и того же объема данных.

В идеальном случае, когда все устройства работают с одной и той же скоростью, канал поделится между устройствами примерно равномерно.

Но что произойдет, когда у нас появится повторитель? С точки зрения беспроводной сети повторитель – это еще один клиент, причем для обеспечения стабильного покрытия его следует размещать в пределах уверенного приема от точки доступа (50% перекрытия).

К чему это приводит? Как мы помним Wi-Fi работает по принципу – один говорит, остальные молчат. А повторитель у нас говорит два раза, как клиент основной точки и как точка для своего клиента. Т.е. занимает дополнительные слоты передачи.

Т.е. вместо одного устройства у нас как-бы появляется два. Вместо двух – четыре и т.д.

При этом сами устройства, подключенные через повторитель, потеряют где-то 50% полосы, так как одни и те же данные потребуется передавать в одном радиоканале два раза: от клиента к повторителю и от повторителя к точке (и точно также в обратном направлении).

Но, как мы уже сказали выше, страдать будут не только клиенты репитера, но и клиенты основной точки доступа за счет появления в сети паразитного дублирующегося трафика.

Простой и очень грубый пример: 4 устройства поделят между собой беспроводную полосу примерно поровну – по 25% на каждого.

Теперь берем 2 устройства напрямую и два через репитер. В результате полоса поделится уже на 6 устройств (два за репитером удваивают используемую полосу).

И опять-таки в идеальных условиях мы уже получим не 25, а 16% полосы на устройство.

До поры до времени, особенно если беспроводные устройства представлены нетребовательными клиентами и общей полосы хватает с запасом – это не заметно.

Но если мы начнем подключать к беспроводной сети требовательные устройства, например, телевизоры 2К – 4К, то это очень быстро станет заметно. Особенно если за репитер переместится несколько медленных клиентов, которые начнут отравлять жизнь всем остальным в два раза активнее.

Про цепочки из нескольких повторителей мы и говорить не хотим, фактически это приведет к кратному увеличению дублирующегося трафика и приведет к катастрофическому падению производительности сети.

Знаю, что многие тут хотят уйти в DevOps. Но не знают где взять информацию и четкий план.

💪 Советую бесплатный мета-курс Devops Roadmap - это расширенный чек-лист, который поможет сориентироваться в мире DevOps и стать крутым спецом.

В мета-курсе перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования в удобном формате.

✔️А еще он будет полезен при подготовке к собеседованиям.

👉 Кстати, бонусом крутой канал о девопс. Там тоже самые свежие IT-новости, полезные советы от DevOps-инженера с 20-летним стажем, эксклюзивные материалы, релизы топовых инструментов, обзоры вакансий и личный взгляд на девопс-сферу.

📌 Ну а тем, кто хочет двигаться под руководством наставника - индивидуальная программа.

​​И снова вой на болотах

Начнем с новости:

Начиная с 11 марта встроенный в ОС Windows антивирусный пакет Windows Defender начал блокировать (помещать в карантин) свободный драйвер WinRing0. Драйвер используется для получения доступа из пространства пользователя к различному оборудованию, для которого не предусмотрено другого API в системе.

Драйвер WinRing0 востребован в проектах, управляющих настройками оборудования, как свободных (OpenRGB, Libre Hardware Monitor, FanControl), так и проприетарных (SignalRGB, Razer Synapse 3). Среди программ, использующих драйвер, есть официальное ПО от десятков производителей оборудования, в том числе популярных. Стоит отметить, что драйвер был подписан самостоятельно автором (разработчиком CrystalDiskMark) и принят Microsoft.

Отмеченная Microsoft проблема, из-за которой произведена блокировка, связана с тем, что доступ к установленному в системе драйверу может получить любая программа, и посредством драйвера программа может манипулировать любым устройством в системе или повысить свои привилегии (CVE-2020-14979).

После чего из многих закоулков сети послышался тоскливый вой и гневные вопли насчет попранных прав и свобод, но, как всегда, мало кто разобрался в вопросе, что же именно заблокировала компания Microsoft.

Драйвер, скажет кто-то и на том успокоится, делов то… Но вот здесь начинается самое интересное, потому что драйвер – это единственное доступный пользователю способ добавить исполняемый код на уровне ядра.

В целом имя данного драйвера наглядно об этом говорит - Ring0 – нулевое кольцо защиты – режим, в котором работает ядро ОС.

Ну так есть же и другие драйвера? Есть, но они предназначены исключительно для работы с конкретным оборудованием или даже с конкретными его экземплярами. А WinRing0, по сути, драйвером в прямом смысле этого слова не является, это некая прослойка, которая дает возможность приложению обращаться к произвольному местоположению памяти ядра.

Да, это удобно, когда знаешь, что куда писать и что откуда читать и не хочешь завязываться на высокоуровневые инструменты производителей оборудования или их возможности оказываются недостаточными.
Но это в тоже время огромный риск, так как ошибка выполнения кода на уровне ядра – это крах ОС иначе именуемый BSOD. А самый лучший способ нарушить стабильность системы – это поставить в нее какой-нибудь левый драйвер.

Т.е. уже, даже в легальном сценарии использования мы имеем все шансы ушатать систему из-за ошибки в каком-нибудь стороннем приложении для управления вентиляторами или подсветкой.

Но это еще не все, конструктивной ошибкой данного драйвера было то, что получить к нему доступ могла любая программа в системе, в т.ч. и с низким уровнем целостности (low integrity) т.е. недоверенное приложение. А это уже не просто дыра, это проходной двор.

Проходной потому, что позволяет легко обходить инструменты безопасности системы и получать доступ на уровень ядра даже из «песочницы» куда система помещает приложения с низким уровнем доверия или процесс работающие с документами из ненадежных источников.

Поэтому решение о блокировке такого драйвера – это не ошибка и не произвол, а вполне взвешенное и обоснованное решение. Наоборот, странно что не случилось этого раньше.

А всем любителям всякого нестандартного ПО, в т.ч. и открытого, это лишний повод задуматься – а оно мне надо. И крепко думать каждый раз, когда какое-то приложение предлагает поставить драйвер, особенно если явной необходимости в этом нет.

​​О радиомостах

В свете материала о нормативном регулировании Wi-Fi неизбежно всплывает вопрос о радиомостах.

Бытуют распространенные заблуждения, что радиомосты можно поднимать над своей территорией, только в диапазоне 2,4 ГГц или только в диапазоне 5 ГГц и много всего такого прочего.

Но увы, радиомосты без регистрации незаконны в любом виде. Абсолютно в любом.

Чтобы понять откуда ноги растут вернемся к Постановлению Правительства РФ от 20.10.2021 N 1800 "О порядке регистрации радиоэлектронных средств и высокочастотных устройств", а именно пункту 14 приложения Изъятия из перечня радиоэлектронных средств и высокочастотных устройств, подлежащих регистрации.

Этот пункт прямо гласит, что регистрации не требует:

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосе радиочастот 2400 - 2483,5 МГц, с допустимой мощностью излучения передатчика не более 100 мВт, в том числе встроенное либо входящее в состав других устройств.

Пользовательское (оконечное) оборудование передающее, включающее в себя приемное устройство, малого радиуса действия семейства стандартов IEEE 802.11 (Wi-Fi), работающее в полосах радиочастот 5150 - 5350 МГц и 5650 - 6425 МГц, с допустимой мощностью излучения передатчика не более 200 мВт, в том числе встроенное либо входящее в состав других устройств.

Начнем с формулировки Пользовательское (оконечное) оборудование, для этого заглянем в Федеральный закон от 07.07.2003 N 126-ФЗ "О связи", статья 2, п. 10:

пользовательское оборудование (оконечное оборудование) - технические средства для передачи и (или) приема сигналов электросвязи по линиям связи, подключенные к абонентским линиям и находящиеся в пользовании абонентов или предназначенные для таких целей

Оборудование для радиомоста очевидно пользовательским и оконечным не является, даже с очень большой натяжкой.

Кроме того, п. 14 содержит дополнительную оговорку о малом радиусе действия и ограничивает мощность излучения передатчика.

Таким образом никаких иных оговорок в законе, которые бы предоставляли лазейки нет.

Любой радиомост, который светит за пределы вашего помещения вне закона и требует регистрации.

Понятно, что не все этим занимаются и эксплуатируют такие решения на свой страх и риск. Однако говорить, что все так делают и ничего – это типичная ошибка выжившего.

Если ваш луч ни с кем не пересекается и никому не мешает, то, скорее всего специально искать его никто не будет. Но все может поменяться в любой момент.

В таком случае вас привлекут к ответственности по Статье 13.4. КоАП Нарушение требований к использованию радиочастотного спектра, правил радиообмена или использования радиочастот, несоблюдение норм или параметров радиоизлучения

А именно пункта 2:

Использование без регистрации радиоэлектронного средства и (или) высокочастотного устройства, подлежащих регистрации, -

влечет наложение административного штрафа *на граждан* в размере *от пятисот до одной тысячи рублей* с конфискацией радиоэлектронных средств … или без таковой;
*
на должностных лиц - от одной тысячи до двух тысяч пятисот рублей*;

на лиц, осуществляющих *предпринимательскую деятельность без образования юридического лица, - от одной тысячи до двух тысяч рублей *с конфискацией радиоэлектронных средств … или без таковой;

*на юридических лиц - от десяти тысяч до двадцати тысяч рублей* с конфискацией радиоэлектронных средств … или без таковой.

Отягчающими обстоятельствами считаются:

1) совершение длящегося административного правонарушения, продолжительность которого превышает три месяца;

2) создание в результате совершения административного правонарушения радиопомех радиоэлектронным средствам других пользователей радиочастотным спектром.

А дальше каждый решает сам. С одной стороны штрафы не такие большие, но с другой практически всегда это сопровождается конфискацией оборудования и постановкой нарушителя на карандаш.

🖥 Дорогие айтишники и им сочувствующие!

ИТ-индустрия переживает период беспрецедентных изменений. Погрузиться в эту тему и разобраться во всех нюансах гос. регулирования поможет этот профессиональный канал.

🎯 Наш подход:

✓ Только полезная информация с щепоткой юмора и капелькой цинизма
✓ Фокус на реальных кейсах и практических решениях
✓ Профессиональный анализ изменений в отрасли
✓ Конкретные рекомендации для бизнеса (CxO)

📊 Что внутри:

• Анализ изменений / трендов и прогнозы через призму реальности
• Практические рекомендации по адаптации к новым условиям
• Разбор полётов ИЦК, ОЦК, ЦК КПСС (да-да, мы знаем, что это такое, и готовы объяснить вам)
• Серьёзные (мемы) темы про ПДН, ЗОКИИ, ГИС-ы (хотя очень хочется просто запостить мемы)
• Пофессиональное сообщество IT-специалистов (ИТ-реалистов), заинтересованных в развитии отрасли.

👉 Присоединяйтесь по ссылке, пока не приняли закон о запрете присоединения по ссылкам ;)

​​И на старуху бывает проруха

Трой Хант (Troy Hunt), известный деятель в области компьютерной безопасности, автор курсов по защите информации, создатель сервиса проверки скомпрометированных паролей "Have I Been Pwned?" и региональный директор Microsoft, раскрыл сведения об утечке базы пользователей собственного списка рассылки. История показательна тем, что даже признанные специалисты в области компьютерной безопасности могут стать жертвами типового фишинга при определённом стечении обстоятельств.

Трою пришло письмо от имени сервиса Mailchimp c предупреждением о приостановке работы его списка рассылки и необходимости выполнения определённых проверок. Трой перешёл по ссылке в письме, ввёл на открывшейся странице параметры учётной записи в Mailchimp, подтвердил запрос двухфакторной аутентификации и страница зависла...., а атакующие получили доступ к пользовательской базе его списка рассылки и выгрузили сведения о email и IP-адресах 16627 подписчиков. Примечательно, что в выгрузку вошли 7535 адресов пользователей, ранее отписавшихся от рассылки, но сервис Mailchimp сохранил их несмотря на отписку и включил в экспортируемые данные.

Трой не стал умалчивать свою оплошность и подробно разобрал инцидент в своём блоге, а также добавил информацию об утечке на свой сервис haveibeenpwned.com. Трой считает, что он не заподозрил подвоха из-за стечения нескольких факторов. Во время получения письма Трой был в поездке, не адаптировался после смены часовых поясов и был сильно уставшим. Письмо было прочитано именно в тот момент, когда бдительность была подавлена.

Вторым фактором стало то, что письмо вначале было просмотрено на iPhone с почтовым клиентом Outlook, который показал только имя отправителя и не отобразил email. Затем, когда письмо было повторно открыто утром на компьютере, Трой не стал перепроверять параметры и не обратил внимание на то, что письмо отправлено с подозрительного адреса "[email protected]".

Текст был стилизован под стандартное сообщение Mailchimp и предупреждал об ограничении отправки рассылки из-за получения жалобы на спам. Информация была подана ровно в той мере, чтобы вызвать беспокойство, но не переусердствовать. В письме предлагалось проверить недавно отправленные рассылки и предпринять действия для разблокировки. По ссылке вместо mailchimp.com открылся сайт mailchimp-sso.com. Менеджер паролей 1Password автоматически не заполнил форму входа, но и это было проигнорировано. После зависания формы аутентификации Трой очнулся и перезашёл на реальный сайт Mailchimp, но было уже поздно - атакующие использовали захваченные учётные данные для получения токена для доступа к API и выполнили экспорт информации.

✅ Источник: https://www.opennet.ru/opennews/art.shtml?num=62964

​​Завершающий слеш в путях Linux

Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.

В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.

Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:

~/video

Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:

~/video/

Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.

Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.

Например, в нашем скрипте написано в цикле что-то вроде:

mv -f “$file” /new_path/video

Данная конструкция имеет неопределенность, потому что если мы забудем создать папку video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл.

Если же мы напишем:

mv -f “$file” /new_path/video/

То при отсутствии директории получим ошибку:

mv: невозможно создать обычный файл ' video/': Это не каталог

Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:

mv: не удалось получить доступ к ' video /': Это не каталог

Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.

Но наличие обратного слеша устраняет неопределенность, потому как в случае с каталогом явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.

Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?

В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?

Поэтому в скриптах такие вещи всегда лучше проверять явно, например:

if ! [ -d /new_path/video/ ]; then
   mkdir /new_path/video
fi

В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.

В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.

А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.

С 1 марта родители могут бесплатно записать своих детей 8–17 лет на программу льготного обучения программированию. 

Цель программы — познакомить школьников с IT-профессиями, обучить разработке на Python, созданию 3D-игры и мультфильмов. Участники получат именные сертификаты, которые помогут при поступлении в вуз и в будущей карьере.

Онлайн-курс проводит федеральная школа программирования Алгоритмика, лауреат премии «Бренд года в России 2024» и участник проекта Сколково. Занятия ведут преподаватели с опытом работы в IT-компаниях, включая Яндекс, Сбер и Иннополис.

Запись открыта до конца недели. Для участия нужно выбрать направление по возрасту ребенка и оставить заявку на сайте: https://s.algoritmika.org/1kbt5q5?erid=2W5zFFwHqWG

​​Зависимости DEB-пакетов

Слово зависимость знают все, но далеко не все понимают, что именно значит этот термин и часто применяют его неправильно. Поэтому сегодня мы решили разобрать этот вопрос.

Начнем с того, что низкоуровневым пакетным менеджеров в DEB-системах является dpkg, именно он занимается распаковкой и установкой пакетов. Упрощенно говоря, установка пакета состоит из двух этапов: распаковки и настройки.

При распаковке файлы извлекаются из пакета и размещаются на указанные места в файловой системе, а настройка обеспечивает выполнение необходимых скриптов и действий, например, создание нужных пользователей и групп, добавление в автозагрузку и т.д. и т.п.

Если в процессе настройки dpkg обнаруживает неудовлетворенные зависимости, то он прекращает настройку и пакет остается распакованным, но не настроенным, мы можем попытаться удовлетворить зависимости и заново попытаться настроить пакет.

Но так как разрешение зависимостей дело непростое, то были придуманы высокоуровневые инструменты, такие как apt-get и apt, задача которых – построить дерево зависимостей, скачать их все и передать для установки тому же dpkg.

Посмотреть зависимости можно командой:

apt-cache depends package_name

И чтобы правильно понимать ее вывод давайте разберем какие именно типы зависимостей существуют:

▫️ Предзависит (Pre-Depends) – означает критическую зависимость пакета А от пакета Б, которая требует строгой последовательности распаковки, если данная зависимость не удовлетворена, то dpkg даже не будет пытаться распаковать пакет А.

▫️ Зависит (Depends) – для работы пакету А обязательно требуется пакет Б, также могут выдвигаться требования к версии пакета, например, не ниже чем. Данные зависимости автоматически разрешаются через apt или apt-get. Если при установке зависимость отсутствует, то dpkg распаковывает пакет, но оставляет не настроенным.

▫️ Рекомендует (Recommends) – не является обязательной, но сопровождающий пакета считает, что большинство сценариев использования пакета А потребуют пакет Б, установка производится вручную при необходимости.

▫️ Предлагает (Suggests) – обычно это пакеты, расширяющие функциональность пакета А или просто используемые с ним совместно. Также не являются обязательными, но ознакомиться с ними будет полезно.

▫️ Конфликтует (Conflicts) – обозначает что пакет А не может работать одновременно с пакетом Б, чаще всего конфликт происходит в тех случаях, когда А содержит обновленные компоненты пакета Б. Часто используется совместно с Заменяет.

▫️ Заменяет (Replaces) – в этом случае файлы пакета Б удаляются или замещаются файлами пакета А.

▫️ Ломает (Breaks) – означает, что нельзя настроить пакет А, если в системе установлен и настроен пакет Б, в этом случае dpkg предотвращает установку пакета. Для его установки нам потребуется вручную удалить пакет Б.

▫️ Предоставляет (Provides) – это значит, что все функции пакета Б предоставляются пакетом А, т.е. пакет его полностью поглощает. Изучение данных зависимостей может быть полезно для контейнеров или встраиваемых систем, когда вам не нужны все функции пакета А и вы можете заменить их легковесным Б.

Как мы уже говорили выше, высокоуровневые менеджеры автоматически разрешают зависимости с типом: предзависит, зависит, конфликтует, заменяет, ломает и предоставляет.

Зависимости типов рекомендует и предлагает предназначены для пользователя. При этом нужно помнить, что не всегда такие зависимости могут быть перечислены в пакете и их наличие следует искать в документации. Хороший пример – пакет шрифтов MS для 1С:Предприятие, их нет в зависимостях пакетов и продукт прекрасно работает без них, но страдает внешний вид текста.

Часто задают еще один вопрос: стоит ли установить зависимости вручную или отдать это на откуп apt? Действительно, во многих инструкциях зависимости явно перечислены в команде на установку.

Так вот, так делать можно, но не нужно. Потому что в этом случае пакеты будут считаться установленными интерактивно и не будут удаляться командой autoremove после удаления основного пакета.

​​За героизм нам не платят

Сегодня, на фоне обсуждений в комментариях, хочется поговорить о производственном «героизме». А именно, когда мы начинаем выполнять задачу не в обычном рабочем режиме, а в состоянии аврала или близком к нему.

Данный героизм можно разделить на два типа: добровольный и вынужденный. Начнем с последнего. Вынужденный героизм – это всегда результат просчета, вашего или не только вашего.

Да, причиной возникновения подобной ситуации может послужить некий внешний фактор, но это только триггер, маленький камушек запускающий сход целой лавины. А истинные причины, в случае лавины, это накопление критической массы снега на склоне.

В нашей отрасли – это накопление критической массы ошибок, недоработок, халатного отношения и прочего, прочего, прочего.

По-хорошему, причиной авральной ситуации может быть только наступление форс-мажора, т.е. обстоятельств непреодолимой силы. Во всех остальных случаях ситуация может быть сложной, но контролируемой.

Что такое авральная ситуация? Это когда все бегают по потолку и ищут там пятый угол, а заодно мучительно думают кого бы назначить крайним.

Сложная, но контролируемая ситуация выглядит так: у нас утрачена рабочая копия сервера и локальное хранилище копий. Чтобы запустить основные функции надо получить 40 ГБ бекапов из внешнего хранилища, это займет примерно час. За это время переустановим сервер, потом еще час-полтора на запуск. Туда-сюда, через три -четыре часа взлетим.

В чем разница? В том, что в первом случае это чистый «героизм», мы превозмогаем, самозабвенно бьемся с обстоятельствами, пытаемся пропетлять между струями дождя и т.д. и т.п.

Во-втором – планомерная и слаженная работа в сложной ситуации, когда мы понимаем, что со всеми допущениями и закладками на прочие «сюрпризы» за три – четыре часа мы систему гарантированно поднимем.

А теперь подумаем, что могло стать причиной перерастания сложной ситуации в авральную? Не было внешнего хранилища? Было, но процесс копирования в него никто не контролировал? Контролировал, но не проверял сами копии?

Таких причин можно найти множество и именно их накопление провоцирует в критической ситуации уже упомянутую нами лавину.

Второй вид героизма – добровольный. Тут все проще и не так трагично. Просто мы вызываемся поработать во внерабочее время, в плотном графике, без необходимых ресурсов и т.д. и т.п.

Обычно это начинается так: нам нужно…

А вы вместо того, чтобы обоснованно пояснить, что тут у нас не хватает ресурсов: вычислительных, памяти, пропускной способности, технологического окна и т.д. и т.п. просто берете под козырек и говорите, что мол попробуем.

Начинается все это безобидно: давайте задержимся после работы, выйдем в ночь, пока сделаем так, а там докупим…

Заканчивается по-разному. Самый безобидный сценарий, это когда вам первый раз пожали руку, сказали спасибо и выдали премию, второй раз просто пожали руку, третий раз забыли про спасибо, а потом еще и посетовали, что что-то вы как-то плохо работали.

В результате подобный «героизм» входит в рутину и от вас его уже ожидают по умолчанию. Ну если нравится человеку работать по ночам без дополнительной оплаты…

Но это был безобидный сценарий. А ведь может все пойти не так, и ситуация превратится в авральную и неконтролируемую. После чего сразу переходим к пункту про вынужденный героизм.

Но тут есть нюансы, если причиной критического сбоя послужил внешний фактор, то им еще как-то можно прикрыться. А вот если вы размотали систему «на ровном месте», то это конкретное попадалово.

Потому что руководство доходчиво вам объяснит всю степень вашей неправоты: не контролировал, неверно оценивал риски, не приложил должных усилий и т.д. и т.п.

И оправдания, типа ну я же просил новый сервер, диски, память и т.п. не прокатят. Так как вам справедливо заметят, что если вы осознавали, то почему делали?

А если делали, то вам и отвечать. А что не выделили, так это вы не объяснили и не довели.

В общем – не надо так делать. Как говорил один мой первый руководитель, когда я проявлял ненужную инициативу – за героизм нам не платят.

​​Про бумажки

Как известно, чем больше бумаги – тем чище одно место. И в обсуждениях вчерашней заметки этот метод неоднократно всплывал.

Что делать, если руководство или заказчики игнорируют потребности IT и требуют работать на том, что есть? Как обезопасить себя? Каким образом снять ответственность?

Скажем сразу – надежный и проверенный способ только один – не работать с чудаками на букву «м». Поэтому если заказчик ила работодатель начинает неоднократно исполнять дичь, что с ним лучше расстаться по-хорошему, чем потом выяснять кто прав, а кто виноват.

Способ обложиться служебками не так прост, как кажется, и таит свои подводные камни. Прежде всего, служебку надо подать по всем принятым правилам документооборота, регистрацией и отметкой на своем экземпляре. Иначе толку от такой служебки не будет, она тут же отправится в мусорку.

В этом плане внешним подрядчикам проще, у них в договоре указаны допустимые форматы обмена документами и в большинстве случаев достаточно обычного письма по электронной почте. Более важные документы можно всегда отправить по ЭДО или заказным письмом с уведомлением.

Но вернемся к нашим баранам. А именно служебкам, в некоторых случаях их наличие может сыграть резко против вас, вплоть до самых печальных последствий.

Почему так? Начнем немного издалека. Для чего пишется служебка? Для того чтобы переложить ответственность с себя на руководителя, который не выделяет нужных ресурсов. Мол я тебя уведомил, моя совесть чиста, теперь это твоя проблема.

А вот и нет. Самая плохая ситуация, когда сложившаяся ситуация однозначно попадет под одну из статей скучной книжки с названием Уголовный кодекс.

Скажем пришла проверка на пиратство, а вы неоднократно служебками уведомляли руководство о наличии нелицензионного ПО. Вы молодец? Нет, вы только что подняли статью с пола. Потому что следователь так и запишет: осознавая противоправность деяния, группой лиц, по предварительному сговору…

Если касаться бюджетки, то там список статей куда более широкий, включая коррупционные и всякие прочие, касающиеся той же КИИ. И там наличие служебки будет являться доказательством того, что вы были в курсе всех творящихся безобразий, но мер по их предотвращению не приняли, в ближайший околоток с заявлением не обратились, а следовательно, пойдете прицепом.

Поэтому перед тем, как руки потянулись писать служебку, надо сесть и крепко подумать, а что скажет прокурор, попади эта бумага ему в руки? Иногда проще пройти за недалекого и недостаточно квалифицированного товарища, чем поднять с пола статью.

Но это только одна сторона монеты. На другой стороне коммерческие структуры и бизнес. А бизнес бывает разный. Вы можете обложиться служебками в два слоя, но если владелец бизнеса решит, что вы крайний – то крайним назначат именно вас.

И подпрыгивать там бесполезно. Свободно улетите по статье, если сами не уйдете по собственному, а там можете пытаться в суде доказать свое честное имя и восстановиться.

Но, это в реальной жизни практически волчий билет. Так как ваш новый потенциальный работодатель видит, что вы не смогли уладить конфликт полюбовно (т.е. уйти по собственному), а значит вы человек конфликтный. А судебная тяжба говорит о том, что вы еще и сутяжник. Ну и нафиг ему такой сотрудник?

Но это мы про бизнес цивилизованный, а кроме бизнеса цивилизованного, у нас осталось немало бизнеса дикого, который так и живет «по понятиям». И по этим самым «понятиям» вы будете им должны.

Полиция? С тем некомплектом, который творится там будет классическое: когда убьют – тогда и приходите. И даже если наш герой имеет стальные тестикулы, то всегда есть слабое звено: жена, дети, родители.

А еще никто не исключает связи вашего бывшего работодателя в силовых структурах, когда прессовать вас будет уже полиция. И тут надо или иметь контрсвязи, или сидеть и не отсвечивать.

Все это наша жизнь и реалии на земле. Поэтому служебки это хорошо, но абсолютно бесполезно во многих случаях.

Поэтому – просто не работайте с чудаками на букву «м».