Лидеры

Представляю Вашему вниманию RedOS, ОСь предназначенную для первоуровневых компьютеров. Версия 1.1 Особенности: 1. Интуитивный и минималистичный интерфейс 2. Возможность копировать, удалять и переименовывать файлы и папки 3. Установка через дискету* 4. Буферизация графики 5. Низкие системные требования Интерфейс очень простой и понятный, снизу рабочая папка и страница, слева - названия файлов и папок, в центре - тип, справа - размер. Очень удобный курсор, который сразу дает понять, где и с чем именно ТЫ будешь работать, также есть защита в случае, если случайно нажмете на удаление или еще чего) Расширенный набор функций удовлетворит любого пользователя MAC своими возможностями Поддержка установки как через Pastebin, так и через дискету Гайд по созданию установочной дискеты: 1. Установить ОС через pastebin 2. Вставить дискету 3. Скопировать все из "/ISO" на дискету 4. Использовать ее как установочную для Бабушкиного ведра)) И наконец, системные требования: Жесткий диск : 40 Кбайт для версии с дискеты и 88 для версии с Pastebin Видеокарта: должна присутствовать Процессор: смотри на видеокарту Оперативная память: 256 Кбайт Дополнительная периферия: Дисковод или Интернет карта, монитор, клавиатура, bios Установка производится после установки OpenComputers Ссылка на скачивание через Pastebin: XRGVrufj Просто напишите в консоли pastebin run XRGVrufj)) Ссылка на исходники на Github

Система предоставляет графическую оболочку для планшетов, имеющую минималистичный интерфейс и понятное только мне использование, а так же минимальное (надеюсь) потребление ОЗУ. Из фич оболочка дает: Возможность использования OpenOS частично без использования команд. Для особых случаев - используем контекстное меню -> "Выполнить команду" Возможность посылки уведомлений пользователю. Многозадачность не реализована, так что пассивную часть программы нужно активировать библиотекой thread из OpenOS Запуск программ-папок (*.pkg). Чисто для разграничения кода и возможности создания модулей Адаптивная отрисовка интерфейса. На экранах с разрешением по ширине, не кратной 20, могут возникать проблемы, однако без искусственного изменения разрешения такого не произойдет. Помощь в настройке при первом запуске. На случай проблем - на первом экране используется колёсико мыши. Блокировка экрана Горячие клавиши на главном экране (клик+delete - удалить, ctrl+e+клик - редактировать и подобное) QR-коды для быстрого доступа юзера к ссылкам В планах: Специальный фреймворк аля Zygote из андроида. Естественно абсолютно весь функционал переписывать не буду, однако основной останется. Этот фреймворк повлечет за собой полный рефакторинг кода (перевод системы на него), но полностью устранит все недостатки TabletOSNetwork - что бы было. Протокол сам в себе будет держать защиту от MITM (Сначала на DSA, потом переведу на ECDSA (реально сложно для меня пока)) и некоторую маршрутизацию с помощью специальных реле (что бы у юзеров планшеты не лагали). Установка - pastebin run 1xudmTa7 Выберите в установщике TabletOS и канал обновлений "Stable". В дальнейшем система будет уведомлять о обновлениях, при получении оного нужно будет зайти в настройки (контекстное меню в левом нижнем углу экрана) и там обновиться. В случае, когда при обновлении бросает ошибку - посмотрите изменения, там будут инструкции по ручному обновлению или переустановке системы. Если и это невозможно. переустановите систему. Данные должны сохраниться, а вот система - обновиться.

Да, независимо. Корпус реактора охлаждается одинаково что холодным, что нагретым теплоотводом. Разогнанный теплоотвод рассеивает тепло со скоростью 20 hu/s независимо от поступления тепла с корпуса реактора. Но может рассеивать и меньше 20 hu/s, если теплоотвод не содержит в себе достаточного количества тепла. И наоборот, если корпус реактора содержит в себе достаточно тепла, разогнанный теплоотвод будет принимать его тепло со скоростью 36 hu/s независимо от своей способности рассеивать это тепло. Поэтому так трудно применять разогнанные теплоотводы для работы с MOX: они сплошь и рядом то излишне переохлаждают реактор, то сами перегреваются. Уточню формулировку: нагретый теплоотвод в горячем реакторе рассеивает то же количество тепла, что и в холодном. Но остывает он быстрее в холодном реакторе. В горячем же реакторе теплоотвод вообще будет нагреваться.

Значит схема в мусорку. Я ведь говорю, что реактор с адаптивным алгоритмом ни одной секунды не будет простаивать, эффективность всегда 7, просто в фазе охлаждения на 1-2 стержня меньше, следовательно, и энергии немного меньше. Можно рассчитать так, чтобы один реактор переходя в режим охлаждения, передавал лишние стержни другому реактору с такой же схемой. Тогда тепло будет плавать как маятник, попеременно повышаясь и понижаясь у каждого реактора, эффективность и энергия у такой сборки будут постоянными. И получаем лагодром. В семи корпусах слишком много слотов, на 2-3 такое сгодится, если схема действительно эффективная. Да, но зачем? Вкл/выкл это не эффективно. А нормальный алгоритм на ~700 шагов писать ручкамии это как-то фу. Динамическое программирование избавляет от лишней писанины, алгоритм просто решает поставленную задачу любыми доступными средствами.

Выпустил 1.0.7 QR Codes: Фиксы: - Окно с прокруткой не закрывалось по клику Добавлено: - QR коды в всплывающих окнах. Если нажать по кликабельному слову (обычно так и пишется - "кликабельно"), появится QR код, который можно легко считать. (что-то список не могу сделать с готового текста) Пока я занят оптимизацией поиска простых чисел на RSA (а потом и на DSA (возможно ECDSA, там ключ меньше), он мне нужен для TabletOSNetwork - что-то наподобие внутриигрового интернета), обновления будут маленькими.

В канале Experimental появились эти QR коды. Удалите файл /TabletOS/Settings.bin и переустановите систему с каналом Experimental, затем пройдите Setup Wizard и найдите в настройках уведомление "Добро пожаловать в графическую оболочку TabletOS" (это и есть те самые инструкции для юзера). Слова перед "кликабельно" вроде как кликаются. Вроде как, потому что не знаешь, как работать с этой луа, например у меня сегодня один и тот же код в разных функциях давал разный результат)) отличие было в цвете текста. Пока это в канале Experimental, могу послушать рекомендации по изменению вида этого QR-кода, ибо я не знаю. как убрать эту черную область (черный на зеленый не сменить - считыватель не видит тогда код) Использовал костыль от ECS (unicode.find из ECSAPI), либу qr кодов с гугла и braile bicycle с этого форума, модифицировав под даблбуфер. (Спасибо всем, что почти ничего не пришлось писать самому ) + свайпы таки могут появиться, я решил просто убрать анимацию, что позволит В РАЗЫ уменьшить количество кода. Что забыл сказать при обновлении вчера. Все необновившиеся до 1.0.6 потеряют доступ к обновлениям перед обновлением 1.0.7. Связано оно с тем, что в системе обновлений есть автоматическая подчистка файлов, которых уже нет в файллисте, а я как раз в 1.0.7 удаляю /lib/TabletOSGraphics.lua и переделываю ее в папку - будет несовместимость. Переустановить систему, к сожалению, не поможет :C Надеюсь с помощью installerScript исправить это

Еще можно виртуальную клавиатуру, чтобы не ставить клаву, коль ОС тут на сенсор рассчитана

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

Скриншотов таблетоса в студию!

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

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

Грядущее обновление 1.2 (Бета уже доступна !) Нововведения: 1. Добавлено меню Буфера и Настроек 2. Продвинутый алгоритм копирования и вставки 3. Постоянство (сохранение рабочего каталога после перезагрузки) 4. Обновленная графическая библиотека 5. Улучшения в производительности и стабильности 6. Поддержка работы мышью (Тач-скрин для мониторов второго и третьего уровня) 7. Новый загрузочный экран 8. Новый установщик Уже завершена Бета версия RedOS 1.2, которая будет обновляться до самого Релиза, на этапе Бета тестирования готов весь основной функционал, то, что уже есть выделено сверху зеленым цветом. Заранее извиняюсь за Баги и плохую оптимизацию, если встретите их то сразу пишите, ближе к Релизу постараюсь их исправить. Минимальные системные требования RedOS v1.2 Жесткий диск : 80 Кбайт Видеокарта: должна присутствовать Процессор: аналогично видеокарте Оперативная память: 384 Кбайт Ссылка на Бета версию (Github) (Также необходимо наличие интернет карты) Ссылка для установки с Pastebin: mH43QtkT

Наконец-то смог запустить TTY в виртуальном окружении! Теперь можно сделать полноценные терминалы ( скопировать исходники из OpenOS )

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

ААААААААААААААААААААААААААААААААААААААА!!!!!!!!!! Как же оказывается сложно писать свою ОС Очень много приходится проектировать. 80% времени проектирую, 20% времени пишу код

Да, но такие программы должны слушать событие "screen_resized", чтобы сразу обновить свои переменные в соответствии с новым размером окна. Поэтому я добавлю возможность ручного перезапуска (ctrl + R) для таких программ, которые не адаптированы под изменяющийся размер окна.

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

Решил еще добавить возможность ставить приложения на паузу(coroutine позволяют и такое делать) Кроме того, что любую программу можно поставить на паузу, можно будет еще 'выключать графику' этой программы Пример использования: запустил 4 программы сразу и комп начал лагать. Взял и вырубил всем 4 программам графику, при этом все неграфические процессы продолжат работу. И все ок, комп перестанет лагать. Так как именно операции с графикой обычно тормозят систему

Словом «все», взятым в кавычки, я надеялся выразить свою иронию. Но твоя новая формулировка меня устраивает: большинство программ – это не все программы, тем более с таким выделением жирным шрифтом: Многозадачность можно реализовать двумя путями: 1) Подменить load своей функцией, автоматически расставляющей по всему коду вызовы yielding. Недостатки этого способа в том, что он провоцирует повышенное потребление памяти и процессорного времени, и годится не для любого кода. Достоинство в том, что потенциально он может спасти систему от падения в TLWY из-за одного кривого приложения. 2) Подменить буквально все методы всех компонент, которые неявно выполняют уступку времени. Начать, конечно, следует с computer.pullsignal, но этого недостаточно. Например, есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периферии. Если ты готов подменить методы всех компонент, добавляя в каждый из них вызов yielding – пожимаю руку. Еще надо не забыть, что периферия может динамически подключаться и отключаться от компьютера, и таблицы методов нужно будет подменять на лету. Предполагаю, что ты выбрал второй способ, удовлетворившись подменой pullsignal, да gpu Например, есть два редстоун-адаптера и два приложения, работающих с ними. Как ты планируешь обеспечить каждому из приложений доступ к нужному адаптеру, изолировав от другого?

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

Вот еще интересный, красочный пример. Запустил две змейки на одном компе: Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

В большинстве случаев дело именно в реализации, да. Если имеется какой-нибудь вшивый цикл на пару итераций, то куда выгоднее использовать локальные переменные, как ты и предлагал, чтобы минимизировать нагрузку на ЦП, это логично. Однако в нашем случае рассматривается функция, вызываемая весьма часто со множеством вложенных циклов и способная в самый неподходящий момент перегрузить сборщик мусора. В принципе, если памяти хватает - то и фиг с ним. Вообще за наводку на идею ускорения спасибо, можно вынести локальные сокращения за пределы циклов отрисовки - и тем самым сэкономить тики ЦП без ущерба для памяти. Хотя придется изрядно повозиться, да А насчет исходников OpenOS - с каких это пор они стали эталоном грамотного и эффективного кода? Лично я вообще не понимаю, что в ней может кушать столько памяти (пс-с-ст, более 200 КБайт по дефолту, жуть какая). Хотя приведенный тобой пример вносит определенную ясность хд

По поводу моей субъективной оценки твоего кода: Я вот такие вещи вообще видеть не могу, это вообще не по-человечески так писать: changes[buffer.currentFrame[index]] = changes[buffer.currentFrame[index]] or {} changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] = changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] or {} table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], x) table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], y) table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], table.concat(sameCharArray)) Когда я вижу подобный код, я начинаю думать: 1) У автора этого кода паническая боязнь переменных(или он проспорил кому-то) 2) Автор думает, что любая созданная переменная занимает гигабайты в оперативке, поэтому их не использует 3) У автора Крутой Продвинутый Текстовый Редактор ™, который позволяет написать "buffer.currentFrame[index]" сразу в трех местах Так как я не фанат различных навороченных редакторов текстовых редакторов и не боюсь переменных и знака "=", я бы написал этот код вот так: local el0 = buffer.currentFrame[index], el1 = buffer.currentFrame[indexPlus1] changes[el0] = changes[el0] or {} changes[el0][el1] = changes[el0][el1] or {} table.insert(changes[el0][el1], x) table.insert(changes[el0][el1], y) table.insert(changes[el0][el1], table.concat(sameCharArray)) По поводу нагрузки на ЦПУ: писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия: 1) получает значение переменной "buffer" 2) получает поле "currentFrame" объекта "buffer" 3) получает поле "index" объекта "buffer.currentFrame" А если хранить это значение в переменной, то будет одно действие: 1) получает значение переменной "el0"

Для справки: каждая переменная-указатель на таблицу или функцию в Lua весит в равной мере 9 байт. А теперь немного сухих расчетов: представим простейшую трехмерную сцену из восьми кубиков. Каждый куб имеет 8 вершин, каждая вершина - это трехмерная таблица-вектор с числовой индексацией, в сумме кушающая 40 (table) + 8 (double) * 3 = 64 байта. Все вершины заносятся в массив вершин сцены для минимизации расхода памяти. Также каждый куб имеет таблицу-линковщик, содержащую индексы вершин, образующие треугольники для отрисовки куба в количестве 12 штук. Каждый треугольник с ссылками на три вершины - это такой же трехмерный вектор, кушающий все так же 64 байта. Итого получаем 64 * 8 = 512 байт на вершины и 64 * 12 = 768 байт на линковку вершин, итого 1280 байт на куб. Сколько у нас там их? Восемь? Итого трехмерная сцена выжрет 1280 * 8 = 10240 байт = 10 КБайт. Это тот минимум, который необходим для старта отрисовки графики, материалы и текстуры для простоты рассматривать не будем. Если же использовать локальные переменные-сокращалки, то расход памяти взлетит по экспоненте. Чтобы пруфануть это более наглядно, привожу выдержку из кода движка, содержащую основной цикл, отвечающий за получение соответствующих вершин через треугольники: for triangleIndex = 1, #OCGL.triangles do vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][1]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][1]][2], OCGL.vertices[OCGL.triangles[triangleIndex][1]][3] vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][2]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][2]][2], OCGL.vertices[OCGL.triangles[triangleIndex][2]][3] vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][3]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][3]][2], OCGL.vertices[OCGL.triangles[triangleIndex][3]][3] material = OCGL.triangles[triangleIndex][4] ... Также привожу скриншот с результирующим FPS в 7 единиц и расходом оперативной памяти в 46% от максимального запаса (4 Мб) А теперь намутим-ка локальных сокращений для минимизации нагрузки на ЦП: local ti, ve1, ve2, ve3 for triangleIndex = 1, #OCGL.triangles do ti = OCGL.triangles[triangleIndex] ve1, ve2, ve3 = OCGL.vertices[ti[1]], OCGL.vertices[ti[2]], OCGL.vertices[ti[3]] vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + ve1[1], renderer.viewport.yCenter - ve1[2], ve1[3] vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + ve2[1], renderer.viewport.yCenter - ve2[2], ve2[3] vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + ve3[1], renderer.viewport.yCenter - ve3[2], ve3[3] material = OCGL.triangles[triangleIndex][4] ... Результат плачевный. Не замечено ни прироста, ни убыли значений FPS, однако расход памяти возрос до 61%. Магия? Нет, особенности конкретного ЯП и его интеграции в виде мода.

RccHD немного не убедительно написал, я попробую его поправить. выполнение buffer.currentFrame[index] -- обращение к переменной buffer -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ. - расчёт hash("currentFrame") - определение смещения по хешу - выборка списка (может дерева) элементов по смещению из массива - разрешение коллизий (дорого) - ... -- выборка из полученной таблицы элемента с индексом, что приводит к 'см выше' -- если вы 'lucky boss' то разрешение кеш промахов (это очень затратная операция) выборка значения переменной -- если интерпретатор lua переменную положил на стек, то это бесплатная операция, иначе: - чтение данных из ОЗУ (если есть кеш, то это тоже почти бесплатная op) - в худшем случае разрешение 1 кеш промаха Мне что-то подсказывает, что выполнять операцию (1) много раз не стоит. Если у вас есть проблемы со своевременной очисткой памяти, то можно вручную вызвать сборку мусора. Но таких проблем быть не должно. Мне кажется, что кто-то просто забывает писать ключевое слово local. И переменная весит ровно 64 бита. Если у вас локальная переменная долго живёт а объект который по ней находится больше не будет использоваться, то можно написать var = nil. И gc, по возможности, удалит объект, на который ссылалась переменная. А сама ссылка удалится как закончится её область видимости (без gc).

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же