По сути это система, которая показывает на экранах (ТВ в коридоре, монитор, планшет) актуальное расписание, время, объявления и звонки. Всё работает в обычном браузере, без всяких специальных программ. Мне надоело смотреть как девчонки бегают с флешками между телевизорами.
Сделал так, чтобы после настройки можно было отключить интернет совсем — всё хранится локально и работает по сети (после сборки). Поставил старый мини-ПК или даже прямо на Smart TV заходит по адресу и показывает.
Сначала думал только про школы (уроки, перемены, звонки на Рупор-300 или используя собственный усилитель), но чем дальше, тем больше понимаю, что это можно использовать гораздо шире...
Сейчас уже стоит в паре мест, работает. Столкнулся с интересными моментами по интерфейсу и удобству, особенно когда пытаешься сделать так, чтобы и директору было понятно, и обычному человеку на телефоне.
Если кому-то интересно такое решение для своей задачи — могу показать, что получилось. Или иные вопросы или явные указания (по скринам) на проблемы. Основа - питон, FastApi и js.
Мой ТГ (личка): @GuardDoc
Не каналы, не продажи, просто если есть интерес поговорить что это такое. Ищу критики и предложений по интерефейсу (сложно в UI)
Особенно не откажусь от мыслей что можно добавить как "виджеты"
Подскажите пожалуйста, пользуюсь Росой линукс. Стоит эмулятор PS1 Duckstation, биос использую такой: Sony PSone BIOS (U)(v4.5)(2000-05-25)[SCPH-101] все игры в которые играю всё нормально запускает кроме Kagero Deception II (Вектор), пробовал сборник с этой игрой от Kudos идёт нормально. Но сборники как правило урезаны. Проблема в том что после заставки Sony и playstation далее ничего не происходит запуска нет. Куда копать?...
Итак, что обещали потребителю? Lindows заменит две операционные системы. Зачем держать две системы? Когда я приобретал этот диск, я думал так же. Но обо всём по порядку.
Поехали. CD-диск (загрузочный) выглядит так:
Установка весьма проста — загружаемся с компакт-диска. Всего четыре простых шага.
Пользовательское соглашение
Определение наличия уже установленной системы
Присвоение имени компьютера и пароля
И установка на жесткий диск без его разбиения и реструктуризации
Инсталляция операционной системы завершается следующим сообщением и предложением перезагрузить компьютер.
После перезагрузки мы видим окно авторизации пользователя.
Заходим на рабочий стол и видим интерфейс в стиле Windows 95. По мере написания статьи монитор, отображающий целевую операционную систему, менялся.
Теперь определимся, что за окружение перед нами и куда мы попали.
Кто у нас пользователь по умолчанию? Ни много ни мало, а сам root. А в чём вишенка на торте? В том, что root — священная корова Unix-like систем — по умолчанию вообще без пароля. Найдёте ещё такую систему? Примечательно, ничего не скажешь. Две громадные дыры в безопасности.
Посмотрим версию Debian. Кодовое название версии 3.0 — Woody.
Woody
Графическая среда KDE 3.0.
Файловая система, на которую установилась Lindows — ReiserFS.
Любопытно выглядит файловая структура Windows в корне ReiserFS.
Процессы запущенные после установки.
Мы определились с внешностью Lindows, а теперь самое главное — в процессе инсталляции на экране было описание технологии Click-n-Run Warehause (далее CNR).
По сути, технология CNR — это инструмент запуска приложений из собственного магазина компании. Упор сделан на запуск программного обеспечения с открытым программным кодом, но не бесплатно. Подписка, позволяющая осуществить запуск из магазина приложений, оценивалась в $49,95 в год. Данная цифра — плата за удобство запуска Linux-приложений одним щелчком мыши. Да, кстати, не только Linux, но и Windows-приложений. Но обо всём по порядку.
После установки Lindows установленная операционная система почти чиста. Она содержит лишь пустые ярлычки, ведущие на приложения, которые можно загрузить с сайта компании, предварительно оплатив подписку. Приведу короткий видеообзор, навигацию по меню — так будет нагляднее.
Вот так выглядит запуск «Сетевого окружения». Думаю, планировался недоинтегрированный SAMBA-механизм при помощи SMB/CIFS-протокола работы в сети, включающей в себя Windows-машины.
Ожидается...
Мы видим операционную систему без наполнения. На текущий момент времени крутое доменное имя «Lindows.com» продаётся. Для нас это означает, что воспользоваться штатным механизмом запуска приложений, предназначенным создателями, невозможно.
Поэтому мы вспоминаем, на чем построена наша система и пробуем воспользоваться давно устаревшим репозиторием.
Прописываем действующий архивный репозиторий и обновляем его.
Поставим несколько игрушек, чтобы убедиться, что все ставится и работает. Вот Pacman.
Pacman
А вот Mirror magic 2.
Запустим Sabre — самолётик, но только криво он у меня запустился. Экран раздвоило, ну да пусть. Смысл в факте запуска, а играть я не собирался. С другой стороны, это говорит о качестве всего: ну не должно такого быть, чтобы так разнесло экран.
Остаётся открытым вопрос: а что же с самым интересным — запуском Windows-приложений? Механизм данного запуска планировался при помощи Wine. Wine — это акроним «Wine Is Not an Emulator», как подчёркивают авторы проекта. Пройдя поиском по всей системе, я не обнаружил и следов Wine. Вот незадача…
Какой напрашивается вывод? В чём основная «фишка» операционной системы? Мне, пользователю, хотелось бы одним щелчком мыши запустить Windows-приложение или хотя бы MS-DOS-программу. Получается, прежде всего я должен установить инструментарий, позволяющий это сделать? А как же обещанное «из коробки»? В чём тогда отличие от других дистрибутивов Linux, так громко не заявляющих о полноценной совместимости? Везде можно установить Wine и быть довольным результатом.
Вот тут-то и пришло прозрение, что гениальность этой операционной системы — только в названии. Предполагаю, что истинная цель — это успешная попытка использовать уже раскрученное имя Windows с небольшим изменением. Как мы видим, обернулось всё это выгодной продажей проекта. Так действуют киберсквоттеры — пираты в сфере доменных имён. Несмотря на очевидное созвучие с оригинальной Windows, такая корпорация, как Microsoft, не смогла справиться простым судебным решением. Здесь был размах глобальнее, и оно сработало: просуществовало как-никак 7 лет, правда сменив имя на LinspireOS.
Упомянув LinspireOS, предлагаю вкратце глянуть на скрины этой операционной системы.
Так выглядит рабочий стол.
Браузер открывает http-ресурсы.
С русским языком всё в порядке — «квакозяблы» отсутствуют. Совсем неплохо.
Напоследок — неразлучная пара канонических любимых игр, подтверждающих, что рассмотренные операционные системы вполне пригодны и не бесполезны. Куда без него, без DOOM'а разумеется?
Ну и достойный крутой последователь — Quake2
В конечном итоге Microsoft приняла гениальное решение «в лоб» — покупка наименования LindowsOS, впоследствии ставшего LinspireOS. Проблема решена навсегда.
Здесь неплохая детальная хронология разбирательств и судебных тяжб.
А здесь подобная информация по вышеописанной тематике.
Что скажете? Цель создания данной операционной системы для производителя, на мой взгляд, вполне достигнута. Среди уважаемых читателей есть тот, кто успел попользоваться сервисом этой операционной системы? Как оно вам? Любопытно услышать мнение. Пишите, пожалуйста, что считаете по этому вопросу!
Наверняка многие из вас, кто изучал в университете «Архитектуру ЭВМ» или системное программирование, сталкивались с архитектурой PDP-11. Эта машина стала настоящей классикой: её элегантная система команд и ортогональные методы адресации стали основой для обучения целых поколений программистов.
Однако софта для эмуляции PDP-11, который был бы удобным, современным и работал "из коробки" на современных ОС, критически не хватает. Часто это консольные утилиты из 90-х или софт, требующий бубнов при установке.
Поэтому я решил написать свой собственный эмулятор PDP-11 — с графическим интерфейсом, интерактивной памятью, виртуальной периферией и встроенным справочником.
Главное окно эмулятора: таблица оперативной памяти с мгновенным дизассемблером (загружена программа Hello World), панель регистров процессора и интерактивный контекстный справочник.
Что под капотом?
Эмулятор написан на C++17 с использованием фреймворка Qt6. Я ставил перед собой цель сделать не просто «выполнялку» кода, а именно наглядный инструмент для студентов и энтузиастов, чтобы каждый такт процессора был понятен.
Что умеет эмулятор на данный момент:
Интерактивная память и дизассемблер "на лету" Сердце интерфейса — таблица оперативной памяти. Как только вы вводите восьмеричный код в ячейку (например, 005203), эмулятор мгновенно дизассемблирует его и показывает мнемонику — INC R3. И наоборот, ошиблись цифрой — увидите UNKNOWN или другую команду. Это невероятно ускоряет процесс понимания машинного кода.
Полный набор регистров и флаги PSW Внизу окна всегда видны состояния регистров R0-R7 и слово состояния процессора (PSW). При пошаговом выполнении (Step Mode) можно наблюдать, как меняются флаги N, Z, V, C в зависимости от результатов арифметики.
Memory-Mapped I/O (Внешние устройства) Какая же ЭВМ без периферии? Я реализовал виртуальные устройства, отображаемые на память по классическим адресам PDP-11:
Дисплей терминала (регистры TPS 177564 и TPB 177566)
Клавиатура (регистры TKS 177560 и TKB 177562)
Принтер (регистры 177514 и 177516)
Виртуальный терминал, работающий через классический Memory-Mapped I/O. Процессор посимвольно вывел строку в регистр данных дисплея по адресу 177566.
Аппаратные прерывания и таймер
Отдельная гордость — это честная реализация работы с прерываниями. Это не просто скрипт, который выполняет команды по списку. Процессор умеет:
Обрабатывать команду WAIT (переход в режим энергосбережения).
Генерировать аппаратные прерывания. Например, встроенный таймер дергает вектор 100(8) каждые 100 мс.
В комплекте с эмулятором идет программа «Stopwatch» (Секундомер). Она показывает, как можно отсчитывать реальные секунды в регистре R0, перехватывая тики таймера и отправляя процессор в спячку (WAIT) между ними. Всё как в настоящем железе!
Сборка и DevOps (чтобы работало у всех)
Как разработчик, я ненавижу, когда для запуска опенсорс-проекта нужно потратить полдня на настройку окружения. Поэтому я заморочился с инфраструктурой:
Для Windows: Написан "умный" скрипт compile.bat. Вы просто запускаете его на чистой Windows. Скрипт сам скачает MSYS2, установит нужный GCC toolchain, подтянет статическую версию Qt6 и соберет независимый PDP11.exe весом в пару десятков мегабайт (без необходимости таскать за собой гору .dll).
Для Linux (Arch/Manjaro): Написан скрипт setup_package.sh, который на лету генерирует PKGBUILD, ресайзит иконки через ImageMagick, создает .desktop файл и устанавливает эмулятор как полноценный нативный пакет в систему.
Кросс-компиляция: Поддерживается сборка Windows .exe файла прямо из-под Linux через MinGW.
Примеры программ
Чтобы пользователям не пришлось начинать с чистого листа, я подготовил библиотеку дампов .pdp, которые идут в комплекте:
Hello World — классика с циклом и проверкой флага готовности дисплея.
Keyboard — программа эхо-ввода (выводит на экран то, что набирается на клавиатуре).
16-bit Integer Calculator — полноценный калькулятор (+, -, *, /) с программной реализацией алгоритмов умножения и деления (которых нет в базовой архитектуре PDP-11) и конвертацией бинарного результата в ASCII-строку для вывода на экран.
Но просто выложить код — это полдела. Поскольку проект задумывался как образовательный, я уделил огромное внимание документации. Каждая программа из примеров разобрана буквально по строчкам: с указанием адресов, машинных кодов, мнемоник и подробным описанием логики.
Фрагмент документации: пошаговый разбор логики работы и дамп памяти для программы «Hello World».
Кроме того, в репозиторий вшита подробнейшая документация по самой архитектуре PDP-11. Я перевел классические справочники из старых PDF-файлов в современный, аккуратно сверстанный Markdown (с поддержкой Obsidian-ссылок).
В нем расписана работа каждой машинной инструкции, особенности адресации и, самое главное для написания эмуляторов — точное влияние каждой команды на флаги регистра состояния (N V Z C).
Пример страницы из справочника: описание работы команды сложения и её влияния на регистр состояния процессора (PSW).
Итоги и планы
Проект полностью открытый, распространяется под свободной лицензией MIT и доступен на GitHub. Если вы преподаете архитектуру ЭВМ или просто хотите поностальгировать по временам, когда программы писались на машинном коде — заходите, пробуйте, делитесь идеями!
Что можно улучшить в будущем:
Внедрить поддержку макроассемблера (чтобы можно было писать код текстом, а не только вводить восьмеричные числа).
Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.
И книга оказалась просто 10 из 10.
Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.
Что внутри:
Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.
Большой блок посвящён коду. Код описан через примеры и советы, но так же описаны типовые ошибки, подводные камни и наследие старых версий, которое всё ещё можно встретить в живых инфраструктурах, но лучше заменить.
Отдельно понравилось, что есть главы про архитектуру использования Puppet, серверную часть, конфигурирование, тонкую настройку, логирование, мониторинг и эксплуатацию. То есть это не только книга для тех, кто пишет Puppet-код, но и для тех, кто потом будет держать всю эту систему в работоспособном состоянии.
Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.
Так же в этих главах становится понятно что автор не просто пользуется Puppet, а является частью его команды разработки. Отсюда и такой уровень погружения в разные аспекты инструмента.
По итогу:
Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.
Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.
Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.
О видео обычно говорят просто: "ну подключили камеры, и все". На практике именно видео чаще всего и начинает ломаться первым, когда система сталкивается с реальной нагрузкой.
С видеонаблюдением часто повторяется одна и та же история: на первом запуске или «на показе» всё красиво, а под реальной нагрузкой начинаются «черные плитки», таймауты, реконнекты и странные просадки.
У меня это тоже было — и это нормально: под нагрузкой впервые видно, где слабые места. Дальше текст не «из методички»: конспект того, что уже раз пришлось пройти руками — смотреть `top`, логи трансляции, поменять одну вещь и снова проверить, ушёл ли симптом.
Локальный стенд: VirtualBox и «всё сразу»
Домашний стенд на ПК — VirtualBox.
Сервер в рабочей сети — через него идёт работа с датчиками, камерами и остальным нужным оборудованием. У меня он тоже стоял в VirtualBox: 6 виртуальных ядер, 6 ГБ оперативной памяти, под систему и приложения 25 ГБ диска, отдельно 50 ГБ под видеоархив.
Одновременно все камеры в полном качестве, постоянная запись архива, движение и просмотр по архиву и много окон live для такой конфигурации — слишком плотный пакет: процессор и диск быстро упираются в потолок, отклик «плавает», кажется, что «сломалось всё». На стенде в «жаркие» минуты служба трансляции (go2rtc) в `top` доходила примерно до ~250–350% CPU — это сумма по ядрам, не «одна строка = одно ядро»; при таких цифрах на VM с шестью ядрами сразу видно, почему «всё и сразу» без компромиссов не взлетит.
По отдельности обычно спокойнее: одна камера крупно, или только сетка с облегчёнными превью, или только архив. Выделение отдельного физического сервера на объекте пока не удалось согласовать с руководством — поэтому остаётся тестовая VM с жёсткими лимитами. На нормальном серверном железе ту же схему разумно ожидать заметно ровнее, с большим запасом под «всё сразу».
Что перебирали, пока остановились на текущем варианте
Ниже не «история коммитов», а смысл: сколько разных рычагов пришлось пощупать, пока картинка и нагрузка не сошлись в рабочий баланс. Порядок в жизни мог быть любой — важнее, что почти никогда не хватало одной правки.
Полноценный поток на каждую плитку в сетке — слишком тяжело для сервера и сети при одновременном открытии; пришлось уйти к более лёгкому потоку в сетке, а «как в мониторе» — только для одной выбранной камеры (крупный просмотр).
Несколько тяжёлых вариантов встраивания видео в браузере сразу — давали всплеск нагрузки и на клиенте, и на сервере; схему показа и запасные режимы пришлось упростить.
Запасной кадр, если с камеры временно ничего не приходит — чтобы оператор не смотрел в пустой чёрный прямоугольник (в том числе на стенде без настроенной трансляции).
Нестабильные камеры — перевод на запасной канал с меньшей нагрузкой (типичный субпоток с регистратора), подбор параметров «картинка vs стабильность» на проблемных точках.
Повторные подключения из‑за обрывов по сети — убирал лишние «хвосты» подписок, следил, чтобы не копились фоновые процессы записи после перезапуска сервера.
Баланс по ядрам — когда сеть и трансляция грузят систему, без нормального распределения прерываний узел может «косить» под одним ядром сильнее остальных. Сервер на объекте у меня тоже на VM — не домашний ноутбук, но всё равно виртуалка, не выделенное железо в стойке. После включения балансировки IRQ (`irqbalance` в Ubuntu) в одном спокойном срезе простой CPU вырос примерно с ~41% до ~76%: не волшебство, просто меньше «залипаний» и перекоса, системе легче дышать.
В сумме это много мелких шагов с проверкой «до / после», а не одна правка. Итог — компромисс: не «идеальная картинка на каждой плитке всегда», а устойчивый просмотр в реальных условиях.
Что чаще всего ломает картинку
В работе чаще всего всплывали такие причины:
нестабильный сигнал с отдельных камер или регистратора;
частые переподключения;
перегруз сервера службой трансляции, когда много окон смотрят одновременно;
сеть и очереди пакетов (на узле с ограниченными ресурсами это особенно заметно).
Поэтому искать «один баг» почти всегда промах: чаще это связка камеры, сети, сервера и того, сколько окон открыто одновременно.
Как это чинили
Не «перезагрузил вкладку — и авось», а по делу:
проверка потоков по камерам;
уборка устаревших настроек трансляции;
запасные варианты для слабых мест;
контроль фоновых задач, которые держат нагрузку;
повторные замеры после каждой правки.
Именно так постепенно получилось убрать самые болезненные сценарии. Параллельно неплохо держать в порядке список потоков, запасные варианты для проблемных камер, зависшие просмотры и метрики до/после — иначе легко перепутать «кажется лучше» с реальным улучшением.
Онлайн видео: режим «Сетка (все сразу)»
Каталог камер (IP, поток, запись в архив — через «Изменить») открывается отдельно — «Камеры» в том же разделе меню:
Каталог камер (настройка)
Список камер и кнопки «Изменить» / «Удалить»; живой просмотр — только во вкладке «Онлайн видео».
Ещё есть вкладка «Видеорегистраторы». Она нужна, чтобы не заводить каждую камеру отдельно по IP: подключаешь к EAS уже стоящий в сети регистратор и подтягиваешь с него каналы в каталог камер — так проще, когда камер много и они уже сидят на NVR. Но по опыту важно знать другое: когда сигнал идёт через регистратор, тот часто отдаёт не «полный» поток, а облегчённый (типичный субпоток для веба или телефона) — на экране это обычно выглядит заметно хуже, чем при прямой схеме «камера → сервер». Удобство массового импорта и качество картинки здесь часто меняются местами: адресов меньше, а «картинка как в кино» ждать не стоит, пока на стороне регистратора не настроят нормальный канал.
Видеоархив: поиск и таймлайн
Вкладка «Видеоархив»: выбор камеры и интервала, таймлайн и список клипов; что реально попало в архив, зависит от галочки «Записывать в архив» и режима записи по каждой камере.
Какие камеры пишут в архив и куда складываются файлы
Писать не обязательно все камеры сразу — у каждой записи в каталоге (Админка → Камеры, кнопка «Изменить») есть галочка «Записывать в архив». Включил её только там, где запись реально нужна — остальные не грузят диск и CPU «про запас». Ниже по той же форме задаётся режим (по событиям СКУД, по расписанию, непрерывно и т.д.) и качество — это уже про баланс «сколько крутим ffmpeg» против «сколько храним».
Камера: «Записывать в архив» и режим записи
Форма редактирования камеры: запись в архив включается отдельно для каждой камеры.
Каталог, куда складываются клипы, задаётся во вкладке «Видеоархив», блок «Настройки хранилища» — поле «Путь на сервере». Это любой каталог, который видит Linux на машине EAS: можно взять локальный диск или каталог на отдельном томе, а можно указать путь к уже смонтированной сетевой шаре (SMB/CIFS, NFS и т.п.) — если администратор ОС смонтировал ресурс, например, в `/mnt/video-archive`, то в поле пишем именно его
Лимит, ГБ — сколько места отводим под архив по сумме клипов в учёте. Циклическая перезапись: если включена, при переполнении лимита система удаляет самые старые записи, пока объём снова не укладывается в квоту — диск не раздувается бесконечно. Если цикл выключить и лимит исчерпан, новые фрагменты могут не записаться (в логах будет предупреждение) — тогда либо поднимают лимит, либо чистят архив вручную. «Предзапись» и «После события, сек» — сколько секунд «до» и «после» тянуть вокруг срабатывания СКУД по считывателям, чтобы в клип попал нужный хвост, а не одна секунда события.
Видеоархив: путь хранилища и квота
На скрине: путь на сервере, лимит в гигабайтах, предзапись/хвост после события, циклическая перезапись.
Почему "все камеры сразу" - это испытание
Когда в сетке много камер, растут нагрузка на обработку потоков, сеть и параллельные просмотры. Слабое место всплывёт: дёргается картинка, тёмные плитки, задержка, рост нагрузки на сервер. Тут помогает не «ещё одна вкладка», а замерить, урезать лишнее или разнести нагрузку — иначе снова те же цифры в `top`.
Архив и расследование
Видеоархив в EAS — не «просто склад»: по нему возвращают момент события, сверяют время и подтверждают выводы после инцидента; вместе со схемой и событиями он помогает снять спор («когда это было», «что повторяется»). Удобно, когда архив открывается из того же экрана, где вы уже смотрите проблему — не нужно «перескакивать» в другую вселенную.
Видео на объекте: нагрузка и проверки
Камера может быть «вроде рабочая», а при нескольких потоках или полной сетке давать задержки и обрывы. Смотрю не на разовый «успешный показ», а на устойчивость в повторяемом режиме. Проверка у меня простая: симптомы → одно понятное действие → снова те же условия — иначе шаг за успех не считаю.
В двух словах
Если совсем коротко: стабильное live — это не галочка в настройках, а привычка смотреть нагрузку и не обманываться. Мониторинг, сетка потоков, запасные сценарии, проверка после каждой правки — и учёт реальных ресурсов (например VM на тесте: 6 CPU, 6 ГБ ОЗУ, 25 ГБ под систему и приложения, 50 ГБ под архив). «Всё сразу» от узла, который уже честно показал сотни процентов CPU в `top`, лучше не ждать — тогда картинка перестаёт «сыпаться», а архив остаётся рабочим инструментом разбора.
Далее — датчики: как сделать так, чтобы они не просто «рисовали цифры», а помогали видеть риск и принимать решение вовремя.
Недавно разбирал старые вещи и наткнулся на флешку, которой не пользовался уже много лет. Решил проверить, что там осталось. Оказалось — куча старых скриншотов, программ, игр и даже браузеров, которыми когда-то пользовались почти все.
Особенно удивили старые интерфейсы сайтов и приложений. Раньше всё выглядело намного проще: минимум анимации, простые кнопки и лёгкая навигация. Сейчас цифровые платформы стали намного быстрее и визуально сложнее.
Интересно наблюдать, как за несколько лет изменилась графика, мобильные интерфейсы и адаптивный дизайн. Даже простые приложения теперь используют плавные переходы и современную анимацию.
У кого-нибудь тоже сохранились старые архивы или программы с прошлого десятилетия?
