Объём данных, которые мы производим и используем, растёт феноменальными темпами. СМИ сегодня существуют преимущественно в цифровом формате, данные предприятий всё чаще хранятся на облачных платформах, а учёные накапливают огромные массивы исследовательской информации. Не забываем и про снимки из космоса и мемы с котиками. К 2025 году скорость роста данных превысит 175 зеттабайт в год. Центры обработки данных изо всех сил пытаются не отставать. Но объёмы продолжают увеличиваться с каждым днём.

Мало того, что объём данных, особенно неструктурированных, увеличился, облачное хранилище побудило компании – и частных лиц – принять подход «хранить всё», даже если эти данные не имеют какою-либо ценность.

Как предприятия могут безопасно хранить в будущем такой огромный объём данных, учитывая, что растёт он экспоненциально? Быстрый рост данных требует инновационных решений в бурно развивающейся области технологий. В течение достаточно длительного периода времени физические носители, такие как магнитные ленты и жёсткие диски, в конечном итоге демонстрируют 100% вероятность отказа. Учёные ищут новые методы, чтобы устранить текущие ограничения в отношении ёмкости, мощности, скорости и долговечности. Но как? Подробности под катом.

❯ Неограниченный рост

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

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

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

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

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

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

В течение 15 лет на рубеже XXI века скорость и ёмкость компьютерной памяти росли с ошеломляющей скоростью. В период с 1990 по 2005 год плотность битов (объём информации, которую можно хранить на квадратный дюйм дискового пространства) систем магнитных приводов росла в среднем на 60% каждый год. Однако к 2010-м годам рост выровнялся. Растущий спрос на ёмкость хранения, а также потребности в миниатюризации и энергоэффективности портативных устройств, таких как смартфоны и ноутбуки, сделали твердотельную «флэш-память» доминирующим средством хранения цифровых данных.

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

❯ Гелиевые диски

Жёсткий диск уже является одной из старейших разработок в компьютерной истории. Согласно технологическому плану, предложенному Консорциумом передовых технологий хранения данных, к 2025 году ёмкость жёстких дисков вырастёт до 100 ТБ благодаря новым технологиям записи, таким как память на магнитных сердечниках, перпендикулярная магнитная запись, улучшенное кэширование и гелиевые накопители.

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

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

❯ Хранение данных в ДНК

Идея хранения цифровой информации на синтетических нитях ДНК существует с 1960-х годов, и вдохновлена тем фактом, что ДНК сама по себе является системой хранения. Она состоит из химических строительных блоков, называемых нуклеотидами, каждый из которых состоит из сахара, фосфатной группы и одного из четырех азотистых оснований. Каждое из этих азотистых оснований обозначается буквами: А (аденин), Т (тимин), G (гуанин) и С (цитозин). Именно порядок и последовательность этих азотистых оснований определяют биологическую информацию, закодированную в цепи ДНК.

Цифровая информация существует в виде двоичного кода, а хранилище ДНК работает путём перевода её нулей и единиц в последовательности этих четырех букв. Например, 00 равняется A, а 10 равняется G. Затем можно получить синтетическую ДНК, содержащую эту последовательность. Эту ДНК можно сохранить и на более позднем этапе декодировать в текст, или, скажем, в видео.

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

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

Количество исследований, связанных с этой темой, в последние годы сильно возросло. Различные компании работают над её реализацией: некоторые — над синтезом или чтением ДНК, другие — над переводом двоичного кода в алфавит ДНК. В 2020 году Microsoft стала соучредителем Альянса хранения данных ДНК, объединившего 41 организацию с двойной целью: реализовать потенциал хранения ДНК и рекомендовать создание спецификаций и стандартов для обеспечения совместимости. И уже есть доказательства концепции. Учёные уже закодировали книги в ДНК, а недавно стартап выпустил устройство размером с кредитную карту, которое может хранить килобайт в форме ДНК. В 2012 году исследователи из Гарварда успешно закодировали цифровую информацию в ДНК, в том числе книгу на 53 400 слов в HTML, одиннадцать изображений JPEG и программу JavaScript.

Для бизнеса потенциальные выгоды значительны. Объём мирового рынка хранения данных оценивался в 217 миллиарда долларов в 2022 году и, по прогнозам, к 2030 году достигнет 778 миллиарда долларов. Согласно одному из отчётов, развивающийся рынок хранения ДНК достигнет 3,4 миллиарда долларов к 2030 году.

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

Если это звучит футуристично, то так оно и есть. Синтез ДНК остаётся дорогим, и поэтому его использование ограничивается лишь небольшим количеством чрезвычайно ценных данных.

Технология хранения данных в ДНК сталкивается с большим временем чтения/записи и общими проблемами стоимости. Долго удерживаемый рекорд скорости составил 200 МБ в сутки. Однако в конце 2021 года исследователи увеличили этот показатель до 20 ГБ в день. Это всё равно значительно медленнее, чем скорость записи на HDD: 200–300 МБ/с.

Другая проблема — стоимость. Исследования показывают, что кодирование 1 мегабайта данных может стоить около 3500 долларов США.

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

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

❯ Развивающаяся область спинтроники и беговая память

Спинтроника — это термин, который исследователи используют для обозначения теоретических вычислений и систем хранения данных, которые используют квантовое свойство, известное как «спин», магнитную ориентацию электрона или другой субатомной частицы. Все такие частицы имеют один из двух спинов: вверх или вниз. Эти два значения могут стать основой для двоичной системы, которую компьютеры используют для хранения цифровой информации — системы субатомных единиц и нулей, которая будет в миллионы раз более эффективной, чем память и процессоры, которые мы используем сегодня. Эта возможность воодушевляет учёных-компьютерщиков, которые в целом согласны с тем, что возможности традиционных систем имеют встроенные ограничения.

Физик из IBM Дональд Эйглер обнаружил, что он может использовать сканирующий туннельный микроскоп (СТМ) не только для наблюдения за атомами, но и для их перемещения. Условия должны были быть абсолютно подходящими: атом должен был находиться в вакуумной камере, охлажденной почти до абсолютного нуля, а кончик микроскопа должен был располагаться очень близко к рассматриваемому атому, но не касаться его. В течение 22 часов 11 ноября 1989 года Эйглер и его команда тщательно расположили 35 атомов ксенона так, чтобы получилось слово «I B M».

Атомное написание Эйглера имело хорошую рекламу, но оно также продемонстрировало ранний прогресс в направлении квантовой электроники.

В течение следующих нескольких лет Эйглер и его команда исследовали новые применения СТМ, в конечном итоге создав электронный переключатель, в котором в качестве активного элемента использовался одиночный атом. В 2004 году команда Эйглера использовала СТМ, чтобы изменить ориентацию спина атомной частицы; они заменили единицу на ноль, обеспечив техническую основу для записи битов на квантовом уровне.

Ранее в том же году другая группа учёных IBM объявила, что они успешно использовали магнитно-резонансную силовую микроскопию для обнаружения вращения одного атома, внедренного в твёрдый образец — техническую основу для считывания квантовых битов. Вместе эти два открытия приблизили информатику на шаг ближе к многолетней мечте о беговой памяти.

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

Беговая память обещает лучшее из обоих технологий: носитель данных, который будет таким же быстрым, как флэш-память, но таким же дешёвым, как магнитный, с теоретической ёмкостью хранения, превосходящей оба варианта. Беговая память работает, перемещая не диск, а сами данные. Биты хранятся в субатомных «доменах» между областями магнитного заряда на нанопроволоке шириной в 1/100 000 ширины человеческого волоса. Затем эти домены перемещаются по проводам, как бегуны на беговых дорожках, со скоростью, в 1 миллион раз превышающей скорость магнитных дисков.

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

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

В 2021 году группа исследователей Нью-Йоркского университета объявила об ещё одном шаге к будущему: они обнаружили, что материалы, называемые ферримагнетиками, которые создают меньшие магнитные поля, чем обычные материалы, такие как железо и никель, лучше подходят для создания стабильного магнитного поля. Это открытие представляет собой ещё один прорыв в продолжающемся проекте по выводу беговой памяти за пределы лабораторий на потребительские рынки.

❯ Нужно ли нам хранить все?

Фактически, сейчас хранение одного терабайта данных в течение года обходится более чем в 3000 долларов. Компании с чрезвычайно большими объёмами данных платят ещё больше. По оценкам, хранение петабайта данных в течение пяти лет может стоить более 1 миллиона долларов.

Дедупликация данных — это простая концепция; она просто удаляет избыточные данные. Но это может привести к существенной экономии средств. В одном примере глобальный банк ежегодно тратил 2 миллиарда долларов на эксплуатацию 600 хранилищ данных. Они реорганизовали, вывели из эксплуатации некоторые данные и сэкономили 400 миллионов долларов на ежегодных затратах.

Итак, жизнеспособно ли сохранение подхода «хранить всё», когда, по оценкам, на дата-центры сегодня приходится до 3% мирового потребления электроэнергии, а к 2030 году, по прогнозам, он достигнет 4%? И где хранить все эти данные в будущем?

Существуют различные традиционные способы хранения данных. Ленточные накопители потребляют минимальное количество энергии, но доступ к данным происходит медленно, а их сохранение обходится дорого. Твёрдотельные и жёсткие диски являются привлекательной альтернативой из-за низкой задержки доступа, что позволяет быстро извлекать данные из хранилища. Но поскольку оба этих носителя информации имеют ограниченный срок службы, они требуют периодического переноса данных на более новые носители. Этот повторяющийся процесс миграции данных вносит значительный вклад в загрязнение окружающей среды, поскольку как жёсткие диски, так и ленты обычно уничтожаются после использования. Твёрдотельные и жёсткие диски требуют постоянного питания для поддержания функций хранения и извлечения данных. Значительная часть сегодняшних архивных данных хранится в огромных ЦОД, битком набитых ими. Они не только занимают много физического пространства, но и производят огромное количество выбросов парниковых газов.

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

Написано специально для Timeweb Cloud и читателей Пикабу. Больше интересных статей и новостей в нашем блоге на Хабре и телеграм-канале.

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

Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать авторские проекты.

❯ Независимость — это свобода

Всем хорошо известны отличия энергозависимой памяти от энергонезависимой. Данные, хранящиеся в энергозависимой памяти живы только до тех пор, пока система работает. Как только подача энергии прекращается, данные становятся недоступными. Именно так работает оперативная память компьютера (ОЗУ) и кэш-память процессора.

Энергонезависимая память сохраняет информацию при отключении питания и хранит значительно бóльшие объёмы данных. Но работает она, на сегодняшний день неэкономично и гораздо медленнее, хотя именно в ней и содержится основная часть данных. Именно поэтому оперативная память остаётся первичной и применяется для хранения данных, необходимых ЦП для работы ОС и программ.

Сегодня существуют несколько видов быстрой энергозависимой памяти. Это динамическая, например, широко распространённая DRAM, разные версии которой используются в качестве ОЗУ, в ячейках она имеет транзистор и конденсатор, статическая (SRAM, применяется в качестве кэш-памяти ядра процессора), с шестью транзисторами в ячейке.

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

Поэтому и появились новые разработки быстрой, но уже энергонезависимой памяти. Это, например, резистивная память с произвольным доступом (RRAM, ReRAM, Resistive random-access memory). В её основе лежит свойство диэлектриков создавать внутри себя проводящие каналы при приложении высокого напряжения. Причём, изменив уровень напряжения проводящий канал можно разрушить, а затем создать снова. Получается так называемый мемристор, из которых и собираются матрицы памяти ReRAM.

❯ Сдвиг по фазе? Нет, фазовый переход!

В качестве ещё одного примера энергонезависимой памяти, претендующей на место ОЗУ, часто приводят 3D XPoint от Intel (торговая марка Optane). Она использует уже другой эффект — phase-change memory (PCM), изменение фазового состояния материала ячейки (кристалла халькогенида) при нагреве электрическим током. Халькогениды — бинарные химические соединения халькогенов (к которым относятся кислород, сера, селен, теллур, полоний, ливерморий) с металлами. В случае 3D XPoint используется халькогенидное стекло на основе сплава антимонида и теллурида германия Ge-Sb-Te). Память состоит из селектора и, собственно, ячейки, которые находятся в точках пересечения перпендикулярно друг к другу проложенных проводников (wordline и bitline). Селектор (ключ) включается при подаче на него напряжения и меняет состояние ячейки либо позволяет считать информацию. Память имеет многослойную структуру (она построена на базе вертикально интегрированных ячеек PCMS), что позволяет масштабировать плотность её размещения на кристаллах.

Phase-change memory на сегодняшний день считается наиболее перспективной технологией, которая может прийти на замену энергозависимой оперативной памяти. Она наиболее полно сочетает преимущества, которые присущи NAND, NOR, EEPROM и DRAM. При этом наиболее серьёзные недостатки всех этих видов памяти у PCM отсутствуют. Зато, преимущества очевидны. Изменение фазы вещества исключает возможные сбои в виде электрических помех, как это бывает в DRAM. Минимальные размеры стабильных ячеек — до 5 нм, что обеспечивает глубокую масштабируемость технологии. Phase-change memory позволяет выполнять побитное изменение данных, что возможно в DRAM, но нельзя сделать в NAND (там приходится оперировать крупными блоками).

Поскольку PCM обеспечивает высокую скорость чтения и произвольный доступ к ячейкам памяти, код можно запускать оттуда, без дополнительного сохранения его ещё куда-либо. К сожалению, пока скорость записи Phase-change memory не столь высока, как хотелось бы (она сравнима с этим показателем у NAND) но время начальной задержки у PCM, примерно в сто раз ниже. Кроме того, отсутствует цикл стирания.

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

❯ Чудеса в слоистых никелатах

В недавнем исследовании, опубликованном в журнале Advanced Science, сообщается об экспериментах с термически обратимым изменением электрического сопротивления при комнатной температуре в слоистых никелатах. Слоистые никелаты представляют собой класс сложных оксидных материалов, состоящих из ионов никеля. Они имеют сложную структуру, в которой слои атомов никеля и водорода перемежаются слоями, содержащими другие элементы, часто щёлочноземельные или редкоземельные. Именно эта уникальная слоистая структура привлекла интерес исследователей из-за свойств электронов, которые сулят слоистым никелатам применение в таких областях, как сверхпроводимость и электроника.

Свойства никелатов исследуются уже давно. В 2020 году учёные из Женевского университета (UNIGE) в сотрудничестве со швейцарским федеральным технологическим институтом в Лозанне EPFL), Цюрихским университетом и Льежским университетами, а также Нью-Йоркским институтом Флэтайрон выяснили, что слоистые никелаты по энергоэффективности могут превзойти кремний, причём с более низким энергопотреблением, обеспечив снижение дополнительных выбросов CO2 при производстве.

Такие никелаты образуются из оксида никеля и атома редкоземельного элемента. В соответствии с тем, какой элемент использован, меняется и температура порога проводимости. Для самария она составит 130° C, для неодима −73° C. Столь значительная разница возникает из-за редкоземельных элементов, которые по-разному деформируют кристаллическую решётку никелата.

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

На схеме отражён процесс переключения электрического сопротивления в Sr2,5Bi0,5NiO5. Два объекта вверху — это кристаллические структуры Sr2,5Bi0,5NiO5 с различным расположением Sr/Bi. Внизу приведена кристаллическая структура двойного перовскита Sr2BiNiO4,5. Синее значение показывает электрическое сопротивление каждого слоя

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

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

❯ ReRAM+PCM — взболтать, но не смешивать!

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

В оригинальных технологиях не устранён целый ряд недостатков. Мемристоры, которые имеют ничтожный размер и постоянно разогреваются до высоких температур, не так надёжны, как хотелось бы. В свою очередь, материалы, обеспечивающие запоминание, при помощи фазового перехода вещества (фактически, его расплавления), требуют для работы больших токов, что, как уже говорилось выше, не так просто обеспечить при плотной упаковке ячеек в кристалле. Гибридная разработка состоит в том, что на кристалл воздействует небольшой ток, который не плавит его, а переводит в состояние, когда его сопротивление меняется.

Чтобы обеспечить неустойчивое состояние кристалла, которое легко изменить небольшим током, потребовалось создать специальный материал, растянутый до состояния тончайшей плёнки в одном направлении и сжатый в другом. В экспериментах использовался дителлурид молибдена (MoTe2). Напряжение, необходимое для переключения ячейки составило 90 мВ, а время переключения — 5 нс. Все параметры такой памяти можно регулировать путём изменения технологии производства и подаваемого на ячейки напряжения. Сейчас исследователи заняты повышением надёжности своей разработки.

❯ Операционные системы — на свалку истории

Начиная с эпохи мейнфреймов компьютеры использовали жёсткие диски и два уровня хранения данных: оперативную память и дисковое хранилище, доступ к которому осуществлялся через дисковый контроллер с использованием файловой системы для индексации и последующего извлечения содержимого. Если постоянное хранилище будет на карте памяти процессора, необходимость в дисковых контроллерах, файлах и файловой системе исчезнет. Трудно представить, что разработчикам удастся адаптировать к новым условиям существующие сегодня Unix-подобные операционные системы, с самого первого дня своего создания ориентированные на работу с файлами, каталогами и метаданными, которые являются их фундаментальной основой. Они тоже могут исчезнуть. Потребуются ОС и программное обеспечение с совершенно иной компьютерной архитектурой.

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

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

❯ ОС нового типа есть, но это не точно

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

Одна из операционных систем, опирающихся на новые принципы — ОС «Фантом» от известного разработчика Дмитрия Завалишина. Концепция ориентации на файлы, стандартная для Unix-подобных систем в ней изменена на концепцию, главным элементом которой является объект. ОС представляет собой виртуальную машину, обеспечивающую восстановление системы с момента последнего выключения за счёт того, что периодически делает и сохраняет снимки своего состояния. Новые принципы, заложенные в проекте, позволяют ОС не замечать перезагрузок и сохранять состояние компьютера, в том числе и при аварийном завершении работы. Все приложения работают в едином адресном пространстве и обмениваются данными через ссылки, а разделение доступа обеспечивается тем, что любые данные обрабатываются, как отдельные объекты и получить объект, принадлежащий другому процессу нельзя. В системе много интересных «фишек». Проект ещё в стадии разработки.

Существуют и другие ОС, включающие отдельные элементы и идеи, использованные в ОС «Фантом». Это IBM i, EROS, Singularity, и PalmOS. Из них, наиболее полно критериям персистентной ОС отвечает проект IBM i, наследник OS/400. Эта операционная система является объектно-ориентированной, содержит одноуровневую память, управляемую среду и поддерживает, собственно, персистентность. Но на сегодняшний день это не ОС для домашних компьютеров, а довольно дорогое платное серверное решение для бизнеса.

❯ Будущее

Вполне вероятно, что грядёт эра энергонезависимого ОЗУ, совмещающего ещё и функции хранилища данных. И возможно, что встретим мы её не только с другими компьютерами, но и с иными операционными системами и другими программами, так как существующий софт не совсем подходит под новую концепцию.

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

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

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

Я еще не говорю о вопросах безопасности, надежности и прочего устройств на базе WIFI и других безпроводных решений, особенно которые завязаны на заруюежные сервисы(в том числе на сервисы не дружественных стран).

Однажды, когда я искал эффективное решение для преобразования речи в текст (транскрибации), чтобы применить его в своем проекте умной колонки, обнаружил интересное решение под названием Whisper от широко известной компании Open AI. К сожалению, Whisper не подошел для реализации в моем проекте по «аппаратным» причинам, но его функционал отпечатался в моей душе. Прошло время и меня посетила идея: «Почему бы не разработать телеграмм бота, куда бы пользователь мог отправлять аудиофайл, а в ответ получал текстовую расшифровку и перевод (песни) на родной язык». В этой статье я расскажу о реализации данной идеи и Whisper в этом проекте займет одну из ключевых функций.

❯ Чем же меня так впечатлил Whisper?

Во первых, что такое Whisper?

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

Ну и само название модели «Whisper» переводится как шепот, что само по себе намекает о качестве распознавания речи.

Чтобы не быть голословным, давайте запустим базовый пример использования и посмотрим вывод:

import whisper
model = whisper.load_model("base")

# load audio and pad/trim it to fit 30 seconds
audio = whisper.load_audio("audio.mp3")
audio = whisper.pad_or_trim(audio)

# make log-Mel spectrogram and move to the same device as the model
mel = whisper.log_mel_spectrogram(audio).to(model.device)

# detect the spoken language
_, probs = model.detect_language(mel)
print(f"Detected language: {max(probs, key=probs.get)}")

# decode the audio
options = whisper.DecodingOptions()
result = whisper.decode(model, mel, options)

# print the recognized text
print(result)

В результате выполнения скрипта мы получим следующий вывод в формате json:

{'text': ' Солнечное излучение (большой текст обрезал).',
'segments': [
{'id': 0, 'seek': 0, 'start': 0.0, 'end': 4.84, 'text': ' Солнечное излучение является одним из самых мощных источников энергии в Селенной.', 'tokens': [50364, 2933, 20470, 4310, 6126, 3943, 41497, 5627, 29755, 50096, 3943, 37241, 39218, 5783, 12410, 20483, 22122, 40804, 7347, 740, 2933, 21180, 5007, 13, 50606], 'temperature': 0.0, 'avg_logprob': -0.1954750242687407, 'compression_ratio': 2.0371621621621623, 'no_speech_prob': 0.0006262446404434741},
{'id': 1, 'seek': 0, 'start': 4.84, 'end': 8.4, 'text': ' Оно поступает на Землю в виде видимого и инфракрасного света,', 'tokens': [50606, 3688, 1234, 43829, 3310, 1470, 42604, 6578, 740, 12921, 38273, 2350, 1006, 6635, 3619, 481, 1272, 17184, 4699, 4155, 20513, 11, 50784], 'temperature': 0.0, 'avg_logprob': -0.1954750242687407, 'compression_ratio': 2.0371621621621623, 'no_speech_prob': 0.0006262446404434741},
{'id': 2, 'seek': 0, 'start': 8.4, 'end': 10.56, 'text': ' а также в виде космических лучей.', 'tokens': [50784, 2559, 16584, 740, 12921, 31839, 919, 38911, 15525, 2345, 13, 50892], 'temperature': 0.0, 'avg_logprob': -0.1954750242687407, 'compression_ratio': 2.0371621621621623, 'no_speech_prob': 0.0006262446404434741},
{'id': 3, 'seek': 0, 'start': 10.56, 'end': 15.8, 'text': ' Солнечное излучение имеет мощность примерно в квадратный метр поверхности Земли.', 'tokens': [50892, 2933, 20470, 4310, 6126, 3943, 41497, 5627, 33761, 39218, 9930, 37424, 740, 35350, 2601, 11157, 4441, 18791, 481, 44397, 13975, 42604, 1675, 13, 51154], 'temperature': 0.0, 'avg_logprob': -0.1954750242687407, 'compression_ratio': 2.0371621621621623, 'no_speech_prob': 0.0006262446404434741},
{'id': 4, 'seek': 0, 'start': 15.8, 'end': 19.44, 'text': ' Это достаточно для производства электроэнергии и других применений.', 'tokens': [51154, 6684, 28562, 5561, 28685, 12115, 31314, 9938, 7570, 489, 19480, 7347, 1006, 31211, 31806, 1008, 17271, 13, 51336], 'temperature': 0.0, 'avg_logprob': -0.1954750242687407, 'compression_ratio': 2.0371621621621623, 'no_speech_prob': 0.0006262446404434741}
], 'language': 'ru'}

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

❯ Улучшения приходят в процессе творчества

Изначально планировалось реализовать только текстовую расшифровку аудиофайла(песни), но потом мелькнула мысль: «Почему бы не реализовать перевод текста, отличного от родного языка? Ведь так можно узнать смысл любимой песни всего за пару минут.»
Для реализации этой идеи, я решил пойти простым путём: использовать API сервисов онлайн переводчиков. К сожалению, а может и к счастью, это была моя ошибка, ввиду ограничения запросов на данные API. Ну что ж, подумал я, меньше внешних сервисов — больше свободы, будем использовать локальные алгоритмы перевода на базе нейронных сетей.

❯ Оффлайн перевод с помощью нейронных сетей

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

Для оффлайн перевода будем использовать модели Helsinki-NLP от Группы исследований языковых технологий Хельсинкского университета.

Пример Python скрипта для оффлайн перевода:
from transformers import pipeline

import torch
device = "cuda:0" if torch.cuda.is_available() else "cpu"
torch_dtype = torch.float16 if torch.cuda.is_available() else torch.float32
# устанавливаем количество потоков для torch
torch.set_num_threads(4)
#Перевод с любого языка на английский
translator = pipeline("translation", model="Helsinki-NLP/opus-mt-mul-en")
text = "Какой-то текст на любом языке"
translation = translator(text)
print(translation[0]['translation_text'])

В примере указан мультиязычный перевод на английский. К сожалению, у Helsinki-NLP нет мультиязычных моделей с переводом на русский язык, поэтому воспользуемся трюком большинства генеративных ИИ и применим двойной перевод, то есть в нашем случае, с английского языка на русский, используя модель Helsinki-NLP/opus-mt-en-ru.

❯ Ну что ж, давайте собирать бота

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

Главный скрипт, отвечающий за работу бота tg_bot.py:

import neural_process
import file_process
import config
from telegram import ForceReply, Update
from telegram.ext import Application, CommandHandler, MessageHandler, filters, CallbackContext, ContextTypes

# Функция, которая вызывается при отправке файла
async def handle_file(update: Update, context: CallbackContext):
audio = update.message.audio
print(audio.mime_type)
# Сохраняем аудиофайл локально и получаем путь сохранения
file = await context.bot.get_file(audio.file_id)
f_name = audio.file_name
local_file_path = file_process.save_audio_file(f_name, file.file_path)
# Отправляем сообщение о успешном сохранении аудиофайла
await update.message.reply_text(
f"Подождите немного, я в ускоренном темпе прослушаю аудиофайл {f_name} и отправлю вам текстовую "
f"расшифровку с переводом."
)
# проверяем файл на длительность
status = True
status_dur = True
try:
file_dur = file_process.file_duration_check(local_file_path)
if file_dur > 600:
status_dur = False
except Exception as e:
print(f"Возникла ошибка: {e}")
status_dur = False

# Получаем перевод

trance_text = 'в эту переменную сохраняется текст транскрибации с переводом'
if status_dur:
try:
start_time = time.time()
trance_text = neural_process.final_process(local_file_path, f_name)
except Exception as e:
print(f"Возникла ошибка: {e}")
status = False
else:
status = False
await update.message.reply_text(
f"Сожалею, но возникла ошибка обработки файла. Длительность файла не должна превышать десять минут."
)

if status:

# Сохраняем вывод в текстовый файл
tx_file_path = file_process.save_text_to_file(f_name, trance_text)
end_time = time.time()
process_time = round(end_time - start_time, 2)
await update.message.reply_text(
f"Перевод готов! Ловите файл с переводом. Затраченное время: {process_time} сек. "
)

# Отправляем текстовый файл
with open(tx_file_path, "rb") as document:
await context.bot.send_document(chat_id=update.message.chat_id, document=document)

else:
file_process.delete_file(local_file_path)
if status_dur:
await update.message.reply_text(
f"Сожалею, но возникла ошибка обработки файла. Пожалуйста, убедитесь что файл имеет правильный аудиоформат."
)

# Функция для команды /start
async def start(update: Update, context: CallbackContext) -> None:
await update.message.reply_text(
'Привет! Добро пожаловать! Нравится песня, но ты не знаешь о чем она? Я могу перевести песню с любого языка '
'на русский за считанные секунды, просто скинь аудио файл в чат. ')

# Функция для команды / help
async def help_command(update: Update, context: ContextTypes.DEFAULT_TYPE) -> None:
"""Send a message when the command /help is issued."""
user = update.effective_user
await update.message.reply_html(
rf"{user.mention_html()}, я могу перевести песню с любого языка на русский, просто скинь аудио файл в чат.",
reply_markup=ForceReply(selective=False),
)

# Запускаем бота
def main():
# Токен бота
application = Application.builder().token(config.tg_key).build()
# Регистрируем обработчик для команды /start
application.add_handler(CommandHandler("start", start))
application.add_handler(CommandHandler("help", help_command))
# Регистрируем обработчик для приема файлов
application.add_handler(MessageHandler(filters.AUDIO, handle_file))
# Запускаем бота
application.run_polling()
# Останавливаем бота при нажатии Ctrl+C
application.idle()

if __name__ == '__main__':
main()

Скрипт для работы с файлами file_process.py:

import requests
import os
from pydub.utils import mediainfo

def delete_file(file_path):
try:
os.remove(file_path)
print(f"Файл {file_path} успешно удален.")
except FileNotFoundError:
print(f"Файл {file_path} не найден.")
except Exception as e:
print(f"Произошла ошибка при удалении файла {file_path}: {e}")

def save_audio_file(file_name, file_link):
response = requests.get(file_link)
# Сохраняем аудиофайл локально для последующей обработки
sound_folder = 'sound'
local_file_path = f"{sound_folder}/{file_name}"

if not os.path.exists(sound_folder):
# Если папки нет, создаем её
os.makedirs(sound_folder)

with open(local_file_path, 'wb') as local_file:
local_file.write(response.content)
return local_file_path

def save_text_to_file(file_name, trance_text):
text_folder = 'output'
local_file_path = f"{text_folder}/{file_name.replace('.', '_') + '.txt'}"

if not os.path.exists(text_folder):
# Если папки нет, создаем её
os.makedirs(text_folder)
# Сохраняем вывод в текстовый файл
with open(local_file_path, "w", encoding="utf-8") as output_file:
output_file.write(trance_text)

return local_file_path

def file_duration_check(file_path):
audio_info = mediainfo(file_path)
duration = float(audio_info['duration'])
print(duration)
return duration

Скрипт для работы с нейросетями neural_process.py:

from transformers import pipeline
import torch
import whisper
import file_process

device = "cuda:0" if torch.cuda.is_available() else "cpu"
torch_dtype = torch.float16 if torch.cuda.is_available() else torch.float32
# устанавливаем количество потоков для torch
torch.set_num_threads(4)

def sound_to_text(audios):
model = whisper.load_model("base")
# load audio and pad/trim it to fit 30 seconds
audio = whisper.load_audio(audios)
audio = whisper.pad_or_trim(audio)
# make log-Mel spectrogram and move to the same device as the model
mel = whisper.log_mel_spectrogram(audio).to(model.device)
# detect the spoken language
_, probs = model.detect_language(mel)
lang = max(probs, key=probs.get)
print(f"Detected language: {max(probs, key=probs.get)}")
# decode the audio
result = model.transcribe(audios, fp16=False, language=lang)
print(result)
return result['segments'], lang

def final_process(file, file_name):
print(f"Сохранен в директории: {file}")
raw, detected_lang = sound_to_text(file)
translator = pipeline("translation", model="Helsinki-NLP/opus-mt-mul-en")
translator2 = pipeline("translation", model="Helsinki-NLP/opus-mt-en-ru")
text = f"Перевод аудиофайла: {file_name} \n"
text += f"В файле используется {get_language_name(detected_lang)} язык. \n"
for segment in raw:
text += "-------------------- \n"
text += f"ID элемента: {segment['id']} Начало: {int(segment['start'])} --- Конец: {int(segment['end'])} \n"
text += f"Исходный текст:{segment['text']} \n"
if detected_lang == 'en':
text_en = segment['text']
translation2 = translator2(text_en)
text += f"Перевод: {translation2[0]['translation_text']} \n"
elif detected_lang == 'ru':
text += ""
else:
translation = translator(segment['text'])
text_en = translation[0]['translation_text']
translation2 = translator2(text_en)
text += f"Перевод: {translation2[0]['translation_text']} \n"

file_process.delete_file(file)
print(text)
return text

def get_language_name(code):
languages = {
'ru': 'русский',
'en': 'английский',
'zh': 'китайский',
'es': 'испанский',
'ar': 'арабский',
'he': 'иврит',
'hi': 'хинди',
'bn': 'бенгальский',
'pt': 'португальский',
'fr': 'французский',
'de': 'немецкий',
'ja': 'японский',
'pa': 'панджаби',
'jv': 'яванский',
'te': 'телугу',
'ms': 'малайский',
'ko': 'корейский',
'vi': 'вьетнамский',
'ta': 'тамильский',
'it': 'итальянский',
'tr': 'турецкий',
'uk': 'украинский',
'pl': 'польский',
}
return languages.get(code, 'неизвестный язык')

Для запуска скрипта, нам необходимо установить следующие пакеты, используя команду:

pip install transformers, torch, accelerate, sentencepiece, sacremoses, python-telegram-bot, openai-whisper, pydub

❯ Деплоим бота

Чтобы всё заработало, не деплойте по пятницам.

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

Для создания нашего облачного сервиса, нам необходимо войти в панель управления под вашей учетной записью. Если учетная запись не создана, то регистрация учетной записи займет всего пару кликов. Я, например, для регистрации и авторизации воспользовался аккаунтом Google.
Создаем новый сервис, выбираем пункт «Облачный сервер»:

Далее нам предстоит выбрать операционную систему для нашего сервера, я выбрал Debian 11:

Выбираем расположение нашего сервера:

Выбираем конфигурацию сервера, как видно на изображении, для начальных тестов я выбрал конфигурацию с четырьмя ядрами CPU и 8 ГБ оперативной памяти:

Вот и все основные опции, которые нам нужны для создания сервера, остальные опции выбираете/указываете по желанию. Чтобы создать сервер, необходимо нажать кнопку «Заказать», которая располагается справа.

Процесс создания сервера:

Сервер создан:

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

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

❯ Подключаемся, настраиваем сервер для размещения бота

Далее мы будем использовать терминал для подключения к нашему облачному сервису.
Запускаем терминал и подключаемся к нашему серверу, после подключения нам необходимо проверить и установить доступные обновления:

apt-get update & upgrade

Запускать скрипты с root правами — как минимум, это дурной тон, поэтому создаем нового пользователя с именем tg_bot:

adduser tg_bot

и пропишем его в группу sudo:

usermod -aG sudo tg_bot

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

Проверим обновления Python3 и установим, если имеются:

sudo apt update
sudo apt install python3

Установим менеджер пакетов:

sudo apt install python3-pip

Так как мы работаем с медиафайлами, нам необходимо установить набор библиотек FFmpeg:

sudo apt install ffmpeg

Для оценки производительности, на всякий случай установим системный монитор htop:

sudo apt install htop

Устанавливаем необходимые зависимости, для работы нашего бота:

pip install transformers, torch, accelerate, sentencepiece, sacremoses, python-telegram-bot, openai-whisper, pydub

Создаем рабочую директорию для нашего бота:

mkdir tg_bot_scripts

Затем переходим в созданную директорию, с помощью команды:

cd tg_bot_scripts

Далее нам нужно создать файлы Python нашего бота, с помощью команд:

nano tg_bot.py

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

nano neural_process.py

nano file_process.py

nano config.py

файл config.py содержит только одну переменную, которая содержит секретный ключ телеграм-бота.

tg_key = 'Ваш секретный ключ'

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

Чтобы это реализовать, нам нужно установить Git:

sudo apt install git

После установки Git, выполнить следующую команду:

git clone https://github.com/VGCH/music_translate_AI_bot

Далее нам необходимо переименовать созданную при клонировании Git репозитория папку music_translate_AI_bot с помощью команды:

mv music_translate_AI_bot tg_bot_scripts

После этого важно не забыть добавить токен телеграмм бота:

cd tg_bot_scripts
nano config.py

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

pyton3 tg_bot.py

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

sudo nano /etc/systemd/system/AI_tg_bot.service

Копируем в открывшийся текстовый редактор следующее содержимое и сохраняем файл:

[Unit]
Description=My AI Bot service
After=network.target

[Service]
WorkingDirectory=/home/tg_bot/tg_bot_scripts/
User=tg_bot
Type=simple
Restart=always
ExecStart=/usr/bin/python3 /home/tg_bot/tg_bot_scripts/tg_bot.py > /dev/null

[Install]
WantedBy=multi-user.target

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

sudo systemctl enable AI_tg_bot.service

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

sudo systemctl start AI_tg_bot.service

Чтобы остановить:

sudo systemctl stop AI_tg_bot.service

❯ Изменение конфигурации сервера

В процессе отладки бота, я решил изменить конфигурацию своего облачного сервера с четырехъядерного CPU на восьмиядерный. Захожу в панель управления Timeweb Cloud, выбрав свой сервер, перехожу на вкладку «конфигурация»:

И выбираю необходимую конфигурацию:

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

При изменении количества ядер CPU на облачном сервере, так же необходимо в скрипте обработки neural_process.py изменить количество потоков для torch, в моем случае на восемь.

torch.set_num_threads(8)

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

htop

❯ Заключение

В итоге у нас получился интересный эксперимент реализации телеграм-бота с применением алгоритмов машинного обучения для распознавания речи и перевода текста.
Спасибо вам за уделенное время и внимание. Есть вопросы, критика, осуждение? Добро пожаловать в комментарии. :)

Небольшой бонус к статье. Переводы песен с помощью созданного бота:

Перевод аудиофайла: Lana Del Rey West Coast.mp3
В файле используется английский язык.
—
ID элемента: 16 Начало: 99 — Конец: 103
Исходный текст: Who baby, who baby, I'm in love
Перевод: Кто, детка, я влюблен.
—
ID элемента: 17 Начало: 103 — Конец: 113
Исходный текст: I'm in love
Перевод: Я влюблен.
—
ID элемента: 18 Начало: 113 — Конец: 123
Исходный текст: Don't know the west coast, they got their icons
Перевод: Не знаю западного побережья, у них есть иконы.
—
ID элемента: 19 Начало: 123 — Конец: 127
Исходный текст: They serve as others, their queens are psychons
Перевод: Они служат как другие, их королевы — психи.
—
ID элемента: 20 Начало: 127 — Конец: 132
Исходный текст: You, good to music, you, good to music and you
Перевод: Ты, хорош в музыке, ты, хорош в музыке и ты
—
ID элемента: 21 Начало: 132 — Конец: 134
Исходный текст: Don't you
Перевод: А ты нет?
—
ID элемента: 22 Начало: 134 — Конец: 139
Исходный текст: Don't know the west coast, they love their movies
Перевод: Не знаю западного побережья, они обожают свои фильмы.
—
ID элемента: 23 Начало: 139 — Конец: 142
Исходный текст: They're golden-guzzing, rocking all copies
Перевод: Они хвастаются золотом, раскачивают все копии.
—
ID элемента: 24 Начало: 142 — Конец: 147
Исходный текст: And you, good to music, you, good to music and you
Перевод: А ты, хорош в музыке, ты, хорош в музыке и ты
—
ID элемента: 25 Начало: 147 — Конец: 149
Исходный текст: Don't you
Перевод: А ты нет?
—

Перевод аудиофайла: Edis-Banane.mp3
В файле используется турецкий язык.
—
ID элемента: 0 Начало: 0 — Конец: 1
Исходный текст: Alo.
Перевод: Привет.
—
ID элемента: 1 Начало: 2 — Конец: 3
Исходный текст: Bir şey söyle.
Перевод: Скажи что-нибудь.
—
ID элемента: 2 Начало: 6 — Конец: 7
Исходный текст: Bir şey söylemek istemiyorum.
Перевод: Я не хочу ничего говорить.
—
ID элемента: 3 Начало: 8 — Конец: 9
Исходный текст: Peki o zaman.
Перевод: Ну что ж.
—
ID элемента: 4 Начало: 30 — Конец: 32
Исходный текст: Bala ne dediğimi soracak olamazsın.
Перевод: Ты не можешь спросить моего отца, что я сказал.
—
ID элемента: 5 Начало: 32 — Конец: 33
Исходный текст: Hayır.
Перевод: Нет, нет, нет.
—
ID элемента: 6 Начало: 33 — Конец: 36
Исходный текст: Bir sebebim yok artık kalamam mı?
Перевод: У меня больше нет причин?
—
ID элемента: 7 Начало: 36 — Конец: 37
Исходный текст: Hayır.
Перевод: Нет, нет, нет.
—
ID элемента: 8 Начало: 40 — Конец: 42
Исходный текст: Ki göz dilimi.
Перевод: Вот об этом я и говорю.
—
ID элемента: 9 Начало: 42 — Конец: 43
Исходный текст: Bu ne?
Перевод: Что это?
—

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

Полезные ссылки:

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать меня и мои проекты.

• Мой GitHub с исходным кодом проекта.

❯ Небольшая предыстория

Больше года назад я нашел в своих закромах одноплатный компьютер Raspberry Pi 4 Model B 8 ГБ. Устройство было куплено за небольшую цену в то время, когда человечество ещё не сошло с ума. Без долгих размышлений, я принял решение создать голосового ассистента на базе этого одноплатного компьютера, чтобы управлять своей системой домашней автоматизации. Бонусом к этой идее шли приватность и автономность. В итоге у меня «родилось» устройство под кодовым именем «Мария».

Но в этой статье не пойдет речь об использовании Raspberry Pi 4 Model B, так как в современных реалиях использование данного одноплатного компьютера стоимостью более $190, трудно назвать бюджетным решением.

❯ Давайте изобретать

Недавно компания Xunlong Software, которая занимается выпуском одноплатных компьютеров под маркой Orange Pi, представила интересное решение — плату Orange Pi Zero 2W с 4 ГБ оперативной памяти, стоимостью $27.

Данное решение вполне подходит для нашего проекта, как в техническом, так и в экономическом плане.

Итак, определимся с конструкцией устройства. Изучив спецификацию Orange Pi Zero 2W, у нас формируется следующий список дополнительных компонентов:

1. Динамик 52мм (просто он у меня уже был $1,3)

2. Усилитель низкой частоты (буду использовать PAM8403 $0,9 за 10 шт)

3. USB микрофон (xingzhaotong $1,5)

4. Шлейф FFC FPC 24pin тип B ($1)

5. RGB светодиод

❯ Разработка звуковой платы

Согласно документации, аудиовыходы реализованы на боковом разъеме FPC, а интерфейс I2S отсутствует. По крайней мере, мне не удалось его реализовать на этой плате. Таким образом, в качестве аудиовхода мы будем использовать USB-микрофон. В версии «Мария» я использовал I2S-микрофон, который продемонстрировал отличные результаты. Ниже предоставлена распиновка бокового разъёма.

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

Так могла бы выглядеть плата при производстве на китайской фабрике:

❯ Изготовление звуковой платы

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

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

Ниже показано тестовое подключение звуковой платы к одноплатному компьютеру с помощью шлейфа FFC FPC:

❯ Настало время творчества! Проектируем корпус

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

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

❯ Сборка умной колонки

Подключение элементов устройства выполняется по следующей схеме:

Как видно из схемы, для управления усилителем используется выход 28 (wPi 18) RPI разъёма, данный выход подключается к контакту звуковой платы с обозначением «SOUND EN». К выходам 26, 24, 22 подключается управление RGB светодиода, который выполняет функцию индикатора при выполнения запросов.

Как я упоминал ранее, в качестве микрофона используется USB микрофон марки xingzhaotong, который выглядит так:

Для установки в корпус колонки, нам необходимо его полностью разобрать и оставить только плату. Данная плата подключается согласно распиновки к соответствующим контактам на звуковой плате GND, DP, DM, VCC.

Давайте приступим к сборке устройства. Предварительная примерка платы Orange Pi Zero 2W:

Вид сверху без верхней крышки, на верхней поверхности резонатора виден прикрепленный USB микрофон в центре будет размещен RGB светодиод.

❯ Немного программной части

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

Операционная система:

В качестве операционной системы я использовал Debian Bullseye c версией ядра 6.1.31, скачать можно на официальном сайте Orange Pi.

Управление GPIO:

Для управления GPIO используется официальная библиотека Orange Pi wiringPi.

Установка wiringPi:

apt-get update
apt-get install -y git
git clone https://github.com/orangepi-xunlong/wiringOP.git
cd wiringOP
sudo ./build clean
sudo ./build

После успешной установки Orange Pi wiringPi, мы можем вывести таблицу GPIO:

gpio readall

В итоге мы увидим следующее:

Обратите внимание, что в колонке «V» указано текущее состояние пина RPI.
Чтобы изменить состояние, мы можем воспользоваться следующими командами:

gpio mode 18 out # Изменение типа пина вход/выход (in/out)
gpio write 18 0 # Изменение уровня пина низкий/высокий (0/1)
gpio read 18 # Чтение состояние пина

Пример одного из вариантов управления GPIO из Python скрипта:

import os
os.system("gpio mode 18 out") # Изменение типа пина вход/выход (in/out)
os.system("gpio write 18 0") # Изменение уровня пина низкий уровень
os.system("gpio write 18 1") # Изменение уровня пина высокий уровень
os.system("gpio read 18") # Чтение состояние пина

Проверка наличия микрофона в системе:

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

arecord -l

Вывод команды должен быть следующим:

**** List of CAPTURE Hardware Devices ****
card 2: ahubhdmi [ahubhdmi], device 0: ahub_plat-i2s-hifi i2s-hifi-0 [ahub_plat-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

Как видим из вывода, устройство USB PnP Sound Device успешно определилось в системе, если устройство отсутствует, то необходимо убедиться в его корректном подключении.

Настройка аудиовыхода:

Чтобы сконфигурировать аудиовыход под наши задачи, в терминале необходимо выполнить следующую команду:

alsamixer

В консоли появится окно с аудио устройствами, нажав F6 необходимо выбрать наше устройство с именем audiocodec и выполнить настройку как отображено ниже на картинке:

После этого можно выполнить алгоритм теста аудиосистемы.

Вывод списка доступных устройств воспроизведения звука:

aplay -l

Вывод команды:

**** List of PLAYBACK Hardware Devices ****
card 0: audiocodec [audiocodec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: ahubhdmi [ahubhdmi], device 0: ahub_plat-i2s-hifi i2s-hifi-0 [ahub_plat-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Мы используем линейный выход, поэтому наше устройство имеет имя CDC PCM Codec-0 [CDC PCM Codec-0]. Давайте протестируем вывод звука через наше устройство.

Первое что нужно сделать — это включить наш усилитель с помощью команд:

gpio mode 18 out
gpio write 18 1

Далее нам необходимо запустить тест с помощью генератора шума, командой в терминале:

speaker-test -c2 -Dplughw:0,0 # plughw:0,0 - это адрес нашего звукового устройства

Вывод команды:

speaker-test 1.2.4

Playback device is plughw:0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 131072
Period size range from 16 to 16384
Using max buffer size 131072
Periods = 4
was set period_size = 16384
was set buffer_size = 131072
0 - Front Left
1 - Front Right
Time per period = 2.742858
0 - Front Left
1 - Front Right
Time per period = 5.461073
0 - Front Left
1 - Front Right
Time per period = 0.580064

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

❯ Итог

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

Предугадывая ваш вопрос — «Почему бы не использовать Yandex Алису и подобные коммерческие решения?», сразу же изложу свою мысль:

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

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

Файлы проекта:

• Файлы модели корпуса.

• Печатная плата проекта.

Так же рекомендуем почитать:

• Как проклятие невидимой стены ждало меня 20 лет

• DECstation 5000/260 — когда интернет был еще молодым

• Простая гравировка для дома: электрический карандаш

❯ Платформа

На этот раз мне в руки попала экстремально редкая машина — DECstation 5000/260, представитель временной линейки RISC-станций, выпускавшейся Digital Equipment Corp. в ожидании готовности их собственной процессорной архитектуры — Alpha AXP. Да, вам не показалось — компания, создавшая PDP, VAX и Alpha, выпускала компьютеры не только на собственных архитектурах. И если представители линеек на базе х86 процессоров (HiNote, DECpc, Celebris/Venturis итд) известны многим, то линейка рабочих станций и серверов DECstation/DECsystem на базе процессоров MIPS, из-за небольших объемов и короткого времени производства (с 1989 по 1994 год). Последняя модель на базе процессоров MIPS была представлена годом ранее, в 1993. Этой моделью и была 5000/260, на базе новейшего процессора MIPS R4400 с частотой 120 МГц.

Линейка DEC 5000 относилась к сегменту Hi-End и начиналась с моделей 200 и 240, использовавших процессоры R4000 с частотой 25 и 40 МГц соответственно, с частотой шины, равной частоте ядра. В R4600 появляется умножение внутренней частоты и процессор, использующий 60 МГц шину, работает на частоте 120 МГц. Часто в информации о модели 260 указывалась именно частота внешней шины процессора. В качестве основной шины, использовалась фирменная разработка DEC — TURBOchannel. Эта шина позволяла достичь пропускной способности в 50-100 Мбайт/с в зависимости от частоты (12.5-25 МГц), в моделях 5000/240 и 260 используется наибыстрейшая ее версия. Из-за использования собственной системной шины и собственного стандарта Firmware, эти машины часто выделяют в отдельную “подархитектуру” Pmax, например так обозначаются поддерживающие эти машины версии NetBSD.

К сожалению, это означает, что вам не удастся запустить на DECstation IRIX или Windows NT/MIPS. Хотя, разработка NT/MIPS велась именно на этих машинах и даже первые демо этой ОС проводились с их использованием, в финальную версию системы поддержка DEC 5000 не вошла. Впрочем, DEC подготовила для своих машин фирменную версию Юникс под названием Ultrix. Она выпускалась в двух вариантах — Ultrix/VAX для систем VAX/MicroVAX и Ultrix/RISC для систем MIPS. Уже ближе к концу жизненного цикла платформы, эта система была заменена OSF/1, вскоре портированной на Alpha AXP и сменившей несколько имен — Digital UNIX, Tru64 Unix.

Интересный факт — первые машины на процессорах Alpha тоже относились к линейке DECstation и использовали шину TURBOchannel. Для корректной работы карт расширения в прошивку был добавлен эмулятор процессора MIPS — ведь прошивки карт TURBOchannel были рассчитаны именно на них. В дальнейшем таким же образом была организована поддержка карт PCI/ISA в более новых Alpha машинах.

❯ Машина

Итак, перед нами машина не только редкая, но и довольно необычная. Во-первых, в ней не предусмотрено место для накопителей вообще. Несколько непривычно для топовой модели, не правда ли? Тем не менее — это так, пространство корпуса поделено между блоком питания и материнской платой с 15(!) слотами оперативной памяти, занимающими почти треть ее площади. Поддерживается до 480 Мбайт ОЗУ типа FPM в собственном формате модулей. Существовали модули на 8 и 32 Мбайт, а также специальные энергонезависимые (читай — с батарейкой) модули для кэширования ввода-вывода. В нашей машине установлено пять обычных модулей по 32 МБайт, общим объемом 160 Мбайт. Цифры огромные для начала 90х!

Рядом со слотами памяти расположилась процессорная карта, на ней расположен процессор, сопроцессор и кэш второго уровня (целый мегабайт!). У задней стенки — три слота TURBOchannel, один из которых занят видеокартой “HX Smart Frame-Buffer Graphics Module" (PMAGB-B) — средней из доступных карт, предоставляющей вывод 8-битного цветного изображения в разрешении до 1280х1024 и обеспечивающей базовые функции 2D ускорения. В линейке же присутствовали и 3D ускорители — редкая и дорогая опция. Остальные два слота свободны. В них можно установить дополнительные SCSI и сетевые опции, например FDDI или Token Ring. На плате интегрированы сетевой контроллер DEC Lance (10 Мбит/с, разъем AUI) и SCSI-контроллер NCR 53C94. Оба контроллера подключены к шине через 128 Кбайт локального кэша для ускорения операций ввода-вывода.

Внимательный взгляд наверняка уже зацепился за шильдик “5000/240” на передней панели девайса. Действительно, эта машина начала свою жизнь 7 мая 1992 года как DECstation 5000/240, но уже в начале 1993 года она была официально обновлена до модели 260, о чем гласит наклейка на задней панели (KN03 и KN05 — коды обозначения процессорных плат этих моделей, соответственно). В комплекте набора для апгрейда должен был быть и новый шильдик, но, судя по всему, кто-то его решил оставить себе в качестве сувенира 30 лет с лишним назад…

И так — у нас есть сеть и есть SCSI. Можно использовать машину как бездисковую рабочую станцию и загружать полностью по сети — встроенный контроллер и прошивка это умеют — причем как с использованием фирменного протокола MOP, так и с помощью привычной связки BOOTP+TFTP. Но такой подход ограничивает производительность — больше 1 Мбайт/с от NFS поверх Ethernet ждать не стоило, а топовые SCSI диски уже могли быть в пару раз быстрее.

В принципе, с DECstation можно использовать любой внешний SCSI диск или даже дисковую полку (мне досталась в комплекте небольшая симпатичная полочка на 3 диска с горячей заменой), но DEC не была бы DEC, если бы не предусмотрел все ситуации. В комплекте с машиной мог поставляться DEC Storage Expansion — второй корпус, в том же стиле, что и основная машина, но чуть выше и уже. Казалось бы, вот так промах! Но и делали его изначально для VAX, к которому он подходил замечательно — тут уже результат унификации. В корпусе находится собственный блок питания и два посадочных места под SCSI устройства форм-фактора 5.25” Full Height (то есть в высоту как два привода CD-ROM). Одно из мест занято огромным, занимающим всё отведенное пространство, диском RZ57 на 1 Гбайт производства самой DEC, второе место доступно для установки еще одного диска или ленточного накопителя (для этого на корпусе установлена заглушка). Возможно можно установить и CD-ROM, но у меня не нашлось подходящего. Всю жизнь машина и блок хранения проработали вместе, долгие годы трудясь в офисе самого вендора — о чем гласит наклейка “Property of Digital”. Этим, я думаю, и объясняется такое везение с апгрейдом процессорной платы — все же модель 240 значительно уступает в производительности 260. Вторая наклейка — несколько умиляет. На ней выбито изначальное сетевое имя машины — “MOULEFRITE”, в переводе с французского, наиболее близкое значение — “Сковородка”.

Казалось бы, повезло — получить редчайшую машину в отличном комплекте и требующий всего лишь тщательной чистки после гаражного хранения и замены “Далласа”, модуля, хранящего настройки firmware на “протез”. Но не все так просто — как вы могли заметить, разъем для подключения монитора здесь проприетарный — 3W3, на сигнальном уровне совместимый с VGA и 13W3, но без переходника (который по редкости сравним с самой машиной) обычный монитор к нему не подключить. Также и разъем для клавиатуры и мышки здесь свой, сигнально не совместимый с чем-либо другим.

❯ Приключения

Но и это — не проблема. Компорт — лучший друг инженера! На многих серьезных машинах до появления систем удаленного управления можно было выбрать вывод системной консоли на последовательный порт. Для родственных серверов DECsystem, отличавшихся отсутствием видеокарты, это и вовсе основной способ взаимодействия с оператором. К нему можно подключить последовательный терминал, например Digital VT100, или просто обычный компьютер с эмулятором терминала. В качестве терминала, я использовал в основном машину из статьи Dreamstation с программой HyperTerminal — примерно вдвое более мощную, чем герой этой статьи. Хотя на паре фото DECstation запечатлена с чудесным ноутом Digital HiNote — его я использовал во время первоначальной отладки.

Опустим историю с чисткой, это не так уж интересно — лишь много воды, пузырьков и куча стертых дисков для шлифовки от ржавчины. Первоначальная отладка тоже не таила сложностей — заменить “даллас” (он тут в панельке), подключиться терминалом, настроить переменные firmware, попробовать загрузиться — и узнать, что диск пуст.
А вот с установкой операционной системы возникли сложности. Самый простой путь — установить её с компакт-диска. Благо, внешний SCSI CD-ROM у меня есть, и даже не один. Но тут кроется засада! У некоторых старых RISC машин есть прикол — они ожидают, что CD-ROM будет использовать секторы размером 512 байт, как у жесткого диска, а не 2048 байт, как подавляющее большинство приводов. Но я был готов и к этому — у меня есть привод, который щелчком тумблера позволяет переключать размер сектора — Yamaha 2100S. В режиме 512 байтных секторов машина загружается с диска, запускает инсталлятор Ultrix и…падает с ошибкой размера сектора CD-ROM. Что за магия, мне понять не удалось, а оригинального CD-ROM тех времен с прошивкой от DEC в моих запасах нет. Альфа же уже не столь привередлива.

Подход номер два случился через несколько недель. В этот раз я решил попробовать загрузку по сети. Сначала, я достал старую добрую “малинку” и попробовал поднять mopd — собрать его под ARM не составило большого труда. Взять его можно здесь — github.com/qu1j0t3/mopd/tree/master, а если будете идти моим путем — нужно сказать линковщику, чтобы он не обращал внимания на повторные объявления переменных. Запустить сервис мне удалось, но в процессе выяснилось два интересных обстоятельства. Во-первых я не смог найти образ Ultrix для сетевой загрузки, во-вторых — я узнал, что DECstation умеет работать с BOOTP+TFTP, прежде я не знал об этом. Ultrix устанавливаться так не умеет, но зато NetBSD может. Поэтому я решил начать с нее.

Я использую pfSense в качестве домашнего роутера — его же я и использовал в качестве сервера BOOTP. BOOTP отличается от DHCP лишь отсутствием поддержки динамической конфигурации хостов, поэтому если вы сделается статическое выделение адреса в DHCP сервере, машина сможет получить его по BOOTP-запросу. Не забудьте в свойства указать поддержку сетевой загрузки и имя файла с образом. Вам понадобится образ инсталлятора в формате ecoff (в моем случае netbsd-INSTALL.ecoff). TFTP не идет в базовой поставке pfSense, но его легко установить из пакетов. В веб-интерфейсе нет поддержки вложенных папок, но их легко создать при подключении по ssh.

❯ NetBSD

Я выбрал версию NetBSD 8.0, в 9.3 сломали поддержку моего SCSI контроллера, а 10 пока не является стабильной. Установка проходит без проблем, главное не забывать, что это достаточно современная система и она требует заметного пространства на диске. Стоит выбрать минимальную установку, а потом доустановить требуемые пакеты. Впрочем, если у вас диск больше 4 Гбайт, можно об этом не задумываться.

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

❯ Ultrix

Одновременно коллеги мне подкинули идею, о которой я должен был догадаться сам. Раз размер сектора у образа установочного диска и обычного харда совпадают — нужно его просто раскатать с помощью dd на второй жесткий диск. Для этого у меня нашелся забавнейший 3.5” дюймовый Micropolis полной высоты емкостью в целый гигабайт (мой друг и коллега по увлечению Slex обозвал его Necropolis — за древность и неспешность).

Трюк удался. Меньше чем через полчаса у меня был рабочий инсталлятор — можно приступать! Установка проходит без особых проблем, главное запастись терпением. Процесс занимает минут 40. Устанавливать стоит сразу полный набор компонентов, Ultrix бережет место на вашем диске. Важно правильно разбить диск, базовые варианты разбиения не оптимальны и оставляют слишком мало свободного места в разделах, а изменить таблицу разделов после установки будет очень неприятной задачей. Сложных вопросов установщик почти не задает, из важного — пожалуй, лишь выбор графической оболочки — XUI или DecWindows/Motif. Я выбрал вторую, но надо будет как-нибудь решиться и попробовать вариант с провокационным неймингом.

После установки потребуется настроить сеть и выполнить несколько базовых настроек (хорошо описаны тут в разделе Some basic customization). Если, вы будете, как и я работать с машиной через последовательный терминал, обязательно включите его в /etc/ttys (сделать это придется в single user mode), иначе вы можете оказаться с нормально загружающейся машиной, после загрузки отказывающейся реагировать на ваши действия в консоли.

После завершения настроек, вы можете использовать машину как сервер или пользоваться консольными приложениями. Но ведь это совсем не интересно, правда! Эта машина практически ровесница интернета, для нее доступен один первых браузеров — NCSA Mosaic, так что грех не установить его и не попробовать выйти в интернет. Но, как вы помните, у меня нет ни монитора, ни даже клавомышки…

❯ X-терминал

Что чаще всего приходит на ум, когда идет речь о выводе графики по сети? VNC, а следом возникают слова “медленно”, “задержки”. Может быть это не такая и плохая идея в качестве временного решения, но в любом случае для Ultrix нет сервера VNC, ну или я его не нашел. Мне удалось найти лишь небольшой набор freeware софта под эту ОС (теперь он доступен для загрузки из архива Digital Vintage — тут). В процессе поисков информации, я вспомнил об X-терминалах, упрощенных машинах с небольшим объемом памяти и младшим в линейке процессором (а иногда и созданным специально для них), но с полноценной видеоподсистемой, созданных, чтобы обеспечивать работу множества пользователей с одной мощной рабочей станцией. В коллекции даже есть одна такая машина — Sun X-terminal 1, ее настройка еще только предстоит, поэтому я выбрал программное решение.

Х-терминалы отличаются от тонких клиентов тем, что обрабатывают вывод видео полностью на своей стороне, а не предоставляют доступ к сгенерированной на удаленной машине картинке.
Так как под MacOS ничего не нашлось, я думал использовать X-ming для Windows в режиме XDMCP, первые успехи пришли с его использованием, но, как оказалось, приложения ожидают наличия определенных шрифтов, которых нет в Windows и в их отсутствие могут работать некорректно или вовсе не запускаться. Поэтому я установил Linux в виртуальную машину (каюсь, у меня нет под рукой десктопной Linux-машины), в дополнение к минимальной десктопной установке поставил растровые шрифты 75 и 100 dpi и главное — Xephyr. На DECstation понадобится установить дополнительный файлсет с утилитами X-windows, на установочном диске он лежит в разделе Unsupported. Вместе с ним можно поставить и игры:

• монтируем установочный образ — mount /dev/rz2a /mnt

• переходим в папку с “неподдерживаемыми” файлсетами — /mnt/RISC/UNSUPPORTED

• запускаем установщик — setld -l ./

• выбираем нужные файлсеты

• запускаем установку

• перезагружаемся

• устанавливаем значение переменной setenv DISPLAY %IP_ADDR%, указывая адрес машины, где будет запущен Xephyr

• запускаем xdm — /usr/bin/X11/xdm -nodaemon

• запускаем Xephyr на машине с Linux — Xephyr -ac -query %DEC_IP_ADDR% -retro -screen 1280x1024 (можно выбрать и другое разрешение, на ваш вкус)

И вот, перед вами рабочий стол настоящего Unix начала 90-х! Как при подключении по telnet, так и в графическом режиме машина работает очень быстро, ОС и софт рассчитаны на более скромные конфигурации — всю мощь рабочей станции мог бы раскрыть специализированный софт, например инженерные пакеты CAD/CAE или программы для видеоконференций — эти машины даже могли поставляться в виде готового решения для их проведения.

Установка софта из каталога freeware проста — либо вы просто распаковываете исполняемый файл и перемещаете в /usr/local/bin, либо выполняете make install. Прописать программу в меню программ можно в настройках сессии (Application Definitions). Mosaic установлен, сеть работает, осталось последнее дело — сходить в интернет!

А вот с этим не все так гладко… По традиции, на ретро машинах я делаю скриншот с главной страницей архива Digital Vintage, но Mosaic в GET запросе не указывает имя домена, поэтому открывается дефолтный бэкенд K8s, причем браузер искренне считает его бинарным файлом и предлагает сохранить на диск. Из всех сайтов мне удалось открыть лишь архив EISA конфигов mR_Slug — его вы и можете видеть на скриншоте. Другого же браузера для Ultrix мною обнаружено не было…

❯ Заключение

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

P.S. Хотелось бы объявить искреннюю благодарность «Ленинградскому компьютерному клубу» и лично его основателю Ивану за помощь в обретении героини этой статьи.

Связаться с автором можно через канал.