С днем знаний!

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

Как сказал Льюис Кэрролл: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»

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

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

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

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

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

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

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

Еще раз с праздником! Давайте не забывать учиться!

Проверяем DNS-записи при помощи PowerShell

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

Для разрешения доменных имен в PowerShell есть командлет Resolve-DnsName, использовать его достаточно просто, полный синтаксис команды выглядит так:

Resolve-DnsName -Name "example.com"

Но его можно упростить:

Resolve-DnsName example.com

Ответ зависит от типа записи, для A вы просто получите адрес, а для CNAME результатом будет доменное имя, на которое ссылается запись. Ниже будет приведена информация о полученном доменном имени и разрешение его в IP-адрес.

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

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

Для получения записей других типов дополнительно используйте ключ:

Resolve-DnsName example.com -Type MX

Результатом вывода для MX, если записи настроены правильно, вы получите одно или несколько доменных имен. Их разрешение в IP-адреса будет приведено ниже в выводе.

Если вам нужно получить результат от определенного сервера, то добавьте ключ:

Resolve-DnsName example.com -Type MX -Server 8.8.8.8

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

Resolve-DnsName example.com -DnsOnly

Данный ключ предписывает выполнить DNS-запрос игнорируя файлы hosts, локальный кеш, широковещательные протоколы и т.д.

Resolve-DnsName example.com -CacheOnly

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

Resolve-DnsName example.com -NoHostsFile

Указанный ключ проигнорирует локальный файл hosts, его следует использовать если есть подозрение, что указанный домен переназначен локально.

Это далеко не все возможности командлета, а только самые полезные. Больше информации вы можете найти в документации:

✅ https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname?view=windowsserver2022-ps

Simply Linux 11 - лед тронулся?

Simply Linux - отдельная операционная система от "Базальт СПО" на платформе Альт, которая позиционируется как бесплатная ОС для всех, что делает ее достаточно интересной.

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

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

И это правильный ход, потому как физические лица могут бесплатно использовать для личных, не связанных с предпринимательской деятельностью целей любую настольную систему Альт и их выбор будет скорее всего на стороне Рабочих станций, предоставляющих передовые выпуски GNOME или KDE, нежели остановится на Simply Linux со скромным XFCE.

✅ Читать далее: https://interface31.ru/post/simply-linux-11-led-tronulsya/

Я календарь переверну…

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

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

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

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

and time() >= 094500 and time() <= 221500

В данном случае триггер будет срабатывать между 09:45 и 22:15, в остальное время тревожить он вас не будет.

Но оказалось, что триггер работает неправильно.

Первое, о чем тут хочется спросить – часовой пояс.

Да, с часовым поясом все нормально, Zabbix показывает события точно по времени, а вот триггер по времени работать не хочет.

А теперь вспоминаем, что веб-интерфейс Zabbix – это отдельное приложение, которое имеет собственные настройки часового пояса, в то время, как сама система хранит все события с временной меткой UTC.

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

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

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

Таким образом у нашего коллеги оказалось, что веб-интерфейс Zabbix имел правильные настройки пояса – MSK (UTC +3), а вот сам сервер работал, как и был из коробки – т.е. в UTC.

Поэтому события в интерфейсе показывались с правильным временем, а вот триггеры срабатывали с отставанием на 3 часа, потому как считали, что сервер находится в часовом поясе UTC (Гринвич).

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

Врут все

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

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

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

Как это водится, тестовый контур собран из говна и палок. Нагрузили тестами, поняли, что это надолго. Ну и нажали Reset на корпусе, после чего контейнер с PostgreSQL подниматься отказался, точнее не сам контейнер, а СУБД в нем.

Кого позовем на помощь? Правильно – ИИ, а этом случае это был Google Gemini PRO, по халявному аккаунту.

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

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

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

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

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

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

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

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

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

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

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

Я понимаю, в корпоративном мире все привыкли врать, недоговаривать, искажать факты, но хотя бы ИИ не врите. Ему все равно, что получил на вход – то направит на выход, а вам потом с этим жить.

Конкатенация в Windows и Linux

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

На самом деле команда cat выполняет конкатенацию – т.е. соединение текстовых строк.

Допустим нам надо объединить два текстовых файла. Самый простой вариант:

cat two.txt >> one.txt

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

А если нужно наоборот, сначала содержимое второго файла, а потом первого?

В этом случае нам как раз потребуется конкатенация с перенаправлением результата в новый файл:

cat two.txt one.txt >> result.txt

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

Говоря о платформе Windows на ум сразу приходит PowerShell, но, вопреки мнению о скудости и убогости, CMD тоже есть что нам предложить.

Практически полным аналогом команды cat в CMD является type.

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

Те же самые команды будут выглядеть как:

type two.txt >> one.txt
type two.txt one.txt >> result.txt

И да, перенаправление в Windows тоже есть и было с незапамятных времен.

При этом работа и cat и type имеет свою особенность, они предполагают, что файл должен заканчиваться последовательностью EOF (End of File) ну или содержать в конце символ переноса строки.

Иначе вместо ожидаемого результата:

строка_файла_1
строка_файла_2 

Вы можете получить и получите:

строка_файла_1строка_файла_2 

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

Ну и наконец PowerShell, для этого у него имеется специальный командлет Get-Content. А так как PowerShell имеет объектную модель, то результатом его работы будет набор объектов, каждый из которых будет содержать строку исходного файла.

Чтобы прочитать содержимое файла выполните:

Get-Content -Path one.txt

Но можно написать проще:

Get-Content one.txt

Если нужно выполнить конкатенацию, то перечислите нужные файлы через запятую.

В PowerShell указанные выше команды будут выглядеть так:

Get-Content two.txt >> one.txt
Get-Content two.txt, one.txt >> result.txt

А так как PowerShell возвращает нам набор объектов по одному на строку, то для него не имеет значения завершается ли файл EOF или нет. Результат всегда будет ожидаем.

Программируемые калькуляторы СССР

Развитие вычислительной техники в СССР имело свои особенности и разительно отличалось от ситуации на Западе. Если там компьютеры широко шагнули в массовый сегмент в конце 70-х годов, то в СССР практически до самого его распада компьютер был средством роскоши и ни о какой массовой доступности их говорить не приходилось.

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

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

В СССР, выпуская программируемые калькуляторы (ПМК) руководствовались ровно теми же соображениями, но советская реальность заставила посмотреть на использование ПМК совершенно с иной стороны.

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

Ну как сказать доступными, средняя заплата инженера на производстве в середине 80-х составляла 120-180 руб., тогда как стоимость программируемых калькуляторов лежала в пределах 65-100 руб. Достаточно недешевое удовольствие, сравнимое с покупкой современного ПК среднего уровня.

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

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

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

Тем не менее именно ПМК открыли многим дорогу в мир вычислительной техники и позволили самостоятельно освоить навыками программирования и выработать алгоритмическое мышление. А достаточно жесткие ограничения по ресурсам заставили крайне серьёзно подойти к вопросам оптимизации.

✅ Читать далее: https://interface31.ru/post/istoriya-vychislitelnoy-tehniki-programmiruemye-kalkulyatory-sssr/

Zilog Z80 — 48 лет в строю

Относительно недавно, 14 июня 2024 года, была принята последняя заявка на производство легендарного процессора Zilog Z80, что завершило его 48-летнюю историю.

48 лет по меркам IT-индустрии — огромный срок. Далеко не каждый продукт может похвастаться даже в несколько раз меньшим, но Z80 это удалось.

А начиналось всё в далёком 1974 году. 31 октября из компании Intel уволились инженер Федерико Фаджин и его коллега Ральф Унгерманн — разработчики Intel 4004 и 8080 (последний вышел незадолго до их ухода).

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

После ухода из Intel инженеры создали собственную компанию — Zilog (отсылка к «последнему слову» Z в Iнтегральной LOGике).

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

В результате сделки Zilog получила финансирование в размере 1,5 млн долларов (около 9 млн по нынешнему курсу) в обмен на контрольный пакет акций в 51%.

Вскоре к команде присоединился ещё один блестящий специалист — Масатоси Сима, стоявший у истоков разработки 4004, затем перешедший в Intel и в итоге поддержавший проект Zilog.

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

Интересно, что изначально Федерико Фаджин предлагал руководству Intel создать усовершенствованный 8080 на контрактной основе, но его предложение отвергли.

В итоге Zilog занялась проектированием самостоятельно. Команда состояла всего из 12 человек, включая только трёх инженеров: Фаджина, Унгерманна и Симу. Работать приходилось по 80 часов в неделю.

Стоит отметить, что никаких систем автоматизированного проектирования (САПР) тогда не существовало: весь дизайн микросхемы и топология слоёв чертились вручную. Затем чертежи неделями перепроверял Сима с обычной линейкой, следя за соблюдением норм техпроцесса.

Изначально Zilog позиционировала себя как бесфабричная компания: производством чипов должен был заниматься Mostek, откуда в марте 1976 года поступили первые кристаллы. В июле того же года состоялся официальный анонс Z80.

Новый процессор получился быстрее и архитектурно удачнее Intel 8080 и моментально завоевал популярность. При финансовой поддержке Exxon Enterprises компания запустила собственные производственные мощности, а её штат разросся до 2000 сотрудников.

Z80 нашёл широчайшее применение в игровой индустрии (чип использовали Sega и Nintendo), стал «сердцем» музыкальных синтезаторов, станков, персональных компьютеров и десятков видов встраиваемых систем.

На постсоветском же пространстве главная ассоциация с Z80 — это легендарный ZX Spectrum, культовый домашний компьютер начала 90-х. Для многих именно Spectrum открыл дорогу в IT-профессию.

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

Не обошлось и без клонирования, что лишний раз доказало успешность архитектуры. Чип производили как по лицензии, так и без неё (включая предприятия СССР, Восточной Европы и Азии). По общим оценкам, нелицензионные копии Z80 составляли до 50% от общего парка выпущенных чипов.

Повторить феноменальный триумф Z80 компания Zilog не смогла: в начале 80-х её покинули отцы-основатели, а вектор сместился в сторону специализированных микроконтроллеров — в качестве производителя которых компания благополучно существует и сегодня.

И хотя выпуск оригинального Z80 официально завершён, на смену ему предлагается линейка eZ80: полностью двоично совместимая со своим предком, но куда более производительная и современная.

Перенаправление и права в Linux

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

echo “Hello” > file.txt

Или

echo “Hello” >> file.txt

В первом случае мы перепишем содержимое файла, во втором – допишем в конец. Кстати, это важный момент, запомните и не путайте!

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

Напрашивается привычное:

sudo echo “Hello” >> file.txt

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

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

Команда sudo позволяет нам выполнить команду с правами суперпользователя и этой командой будет echo, которая выведет указанный текст в стандартный поток вывода. На этом ее работа закончилась. Перенаправлением потока будет заниматься оболочка, которая запущена от обычного пользователя.

Чтобы все-таки выполнить запись в файл мы можем сделать так:

sudo bash -c ‘echo “Hello” >> file.txt’

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

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

Например, для решения нашей задачи можно использовать:

echo “Hello” | tee -a file.txt

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

sudo echo “Hello” | tee -a file.txt

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

Правильно:

echo “Hello” | sudo tee -a file.txt

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

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

Советские ПК

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

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

Необходимость компьютеризации на уровне широких масс в СССР поняли уже в первой половине 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, преимущественно игр.

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

SMB over QUIC

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

Во-вторых, основной проблемой на нестабильных каналах связи будет крайне низкая производительность протокола. В SMB используется транспортный протокол TCP, и потеря даже одного пакета полностью блокирует поток.

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

Новый протокол призван устранить все эти недостатки и сделать доступ к SMB ресурсам через интернет столь же простым, как локальный доступ. Впервые SMB over QUIC был представлен в Windows Server 2022 Azure Edition, а начиная с Windows Server 2025 стал доступен всем желающим.

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

К ключевым особенностям реализации относится шифрование TLS 1.3, являющееся неотъемлемой частью протокола QUIC, что делает не нужным VPN и прочие методы защиты канала.

Также QUIC внешне мало отличим от обычного HTTPS и использует стандартный 443 порт, что делает решение универсальным и устойчивым к различным ограничениям (скажем, гостиничный интернет, где кроме HTTP(S) все закрыто).

Внутри шифрованного туннеля используется SMB 3.1.1 со всеми его возможностями по управлению доступом и защите целостности, включая подписывание SMB-пакетов, только теперь все это, включая аутентификацию надежно защищено TLS 1.3.

Вторая важная особенность – транспорт, QUIC использует UDP и эффективно управляет мультиплексированием соединений. Теперь потерянный пакет не блокирует поток, что способствует серьезному повышению производительности, а мультиплексирование позволяет максимально эффективно использовать канал.

Для тех, кому нужно больше безопасности SMB over QUIC поддерживает Client Access Control – проверку подлинности клиента на основе сертификатов. Теперь не только клиент может убедиться в подлинности сервера используя его сертификат, но и наоборот.

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

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

Но при всех его достоинствах SMB over QUIC – это дело будущего, возможно не столь отдаленного, но тем не менее. Из ОС семейства Windows кроме Windows Server 2025 его поддерживает только Windows 11, в Windows 10 ввиду окончания срока поддержки данная возможность добавляться не будет.

Samba 4.23 выпущена 12 сентября 2025 года и не присутствует ни в одном LTS – дистрибутиве. Ближайший кандидат на ее появление – это Ubuntu 26.04 и Debian 14. Возможно, поддержка появится и раньше, в промежуточных дистрибутивах или backports, но особой погоды это не сделает.

Поэтому массовое внедрение SMB over QUIC следует ожидать не ранее, чем через несколько лет, как минимум после массовой замены Windows 10 более современными редакциями ОС и появлению пакетов Samba c поддержкой этой технологии в основных LTS-дистрибутивах Linux.

Утилизация CPU в Linux

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

Чтобы получить данную информацию мы будем использовать команду top, которая есть из коробки практически в каждом дистрибутиве.

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

🔹 us (User CPU time) – время потраченное на пространство пользователя. Это основная рабочая нагрузка и именно сюда попадает процессорное время, которое наши программы или службы тратят на полезную работу. Высокие значения говорят о том, что мы интенсивно нагружаем систему и не являются какой-либо аномалией.

🔹 sy (System CPU time) – время потраченное на пространство ядра. В пространстве ядра работают драйвера оборудования, системные вызовы и т.п. Нормальны умеренные значения этого показателя, высокие значения могут говорить о проблемах с оборудованием, высокую нагрузку на системы ввода-вывода или являться признаком DDoS-атаки на систему.

🔹 ni (Nice CPU time) - время потраченное на процессы пользовательского пространства запущенные с пониженным приоритетом. Для данного показателя справедливо все то, что было сказано для us. Данный показатель нужен для оценки того, как система перераспределяет ресурсы и анализируется в совокупности с us.

🔹 id (Idle) — время простоя (бездействия).

🔹 wa (I/O wait) — время на ожидание операций ввода-вывода, высокие значения показывают на то, что система много времени тратит на ожидание дисковых операций. Может служить показателем выхода из строя накопителей, но также высокие значения могут быть нормальными при интенсивной дисковой нагрузке. Продолжительные высокие значения являются признаком того, что система ввода-вывода не справляется с текущей нагрузкой.

🔹 hi (Hardware IRQ) — время, потраченное на обработку аппаратных прерываний. В обычных сценариях значение этого показателя должно быть близким к нулю, высокие значения указывают на возможную неисправность оборудования либо на крайне высокую нагрузку на устройства ввода-вывода.

🔹 si (Software IRQ) — аналогично, время, потраченное на обработку программных прерываний, умеренные значения этого показателя являются нормой, высокие значения в первую очередь показывают на высокую сетевую нагрузку, неисправность сетевого оборудования или DDoS-атаку.

🔹 st (Steal Time) - время «украденное» гипервизором у виртуальной машины, имеет значение внутри виртуальной машины и показывает какое количество процессорного времени она недополучила от гипервизора. Указывает на наличие конкуренции за процессорное время между виртуальными машинами или виртуальными машинами и процессами гипервизора.