Лидеры

Раз уж на форуме появился специализированный раздел, посвященный операционным системам, то грех не выложить свою. Сама система является графической оболочкой к дефолтной OpenOS со множеством собственных библиотек, основной упор при ее написании делался на визуальную составляющую и общее быстродействие. Ключевые особенности: Многозадачность Оконный интерфейс с двойной буферизацией графики Поддержка анимаций, обоев, заставок и цветовых схем Поддержка языковых пакетов и локализации ПО Поддержка авторизации пользователя по паролю и биометрике Поддержка обмена файлами по локальной сети через модемы Поддержка клиентского подключения к реальным FTP-серверам Система отчетов об ошибках с возможностью отправки информации разработчикам Магазин приложений с возможностью публикации собственных творений и системой пользовательских рейтингов Интегрированная IDE с отладчиком и значительное количество разнообразного прикладного ПО Открытое системное API и подробная иллюстрированная документация к библиотекам Собственная прошивка EEPROM с возможностью выбора/форматирования загрузочного тома и восстановлением через интернет Частичная совместимость с OpenOS-софтом Установка: Для запуска инсталлера введите следующую команду: wget -f https://raw.githubusercontent.com/IgorTimofeev/MineOS/master/Installer/BIOS.lua /tmp/bios.lua && flash -q /tmp/bios.lua && reboot Перед вами появится симпатичный интерфейс, где вы сможете выбрать параметры установки: к примеру, загружать ли все имеющиеся приложения, либо оставить только системные, а также загружать ли обои рабочего стола. Лицензионное соглашение шуточное, всерьез можно не воспринимать. Исходники: https://github.com/IgorTimofeev/MineOS Люди, прямо или косвенно участвовавшие в разработке: Тимофеев Игорь - рефакторинг, оптимизация и вылизывание кода Трифонов Глеб - разработчик формата изображений OCIF и методов цветовой обработки Веревкин Яков - консультант по вопросам векторно-матричных преобразований Шестаков Тимофей - специалист по UI/UX-дилеммам Смирнов Алексей - тестировщик ПО Богушевич Виктория - синтаксический корректировщик и отвлекающий фактор Витвицкая Яна - позитивистский мотиватор и не менее отвлекающий фактор Какой-то Андрей - эксперт в области оценки красоты кода Ярычев Никита - компаньон в обсуждениях философских нюансов Пакин Максим - автор нескольких приложений Тиунов Дмитрий - консультант по нюансам веб-запросов Маяковский Константин - товарищ со уникальным духовно-пофигистическим характером Сазонов Слава - автор пары оптимизационных моментов и любитель кратких диалогов Омелаенко Максим - анализатор рынка ПО и конкурентных решений Просин Михаил - генератор мотивации по генерации идей по улучшению ПО Чернышева Дарья - моральная поддержка команды Палиев Егор - очень хотел в этот список

Да это могли быть плагины или моды какие-то,которые так портачили(а могли быть и не они). Это не сильно важно,я просто к слову вспомнил.

Это рассуждение применимо только по отношению к дрейфу тиков Майнкрафта относительно времени сервера. Такты же времени OpenComputers относительно тактов реактора не дрейфуют. По крайней мере, я такого поведения никогда не наблюдал, и предпосылок для него не вижу. Зато регулярно можно наблюдать внезапные задержки отдельных операций, не требующих дополнительной синхронизации. И значительно реже требуется вычисление новой задержки, которая будет актуальна до следующего сбоя синхронизации. Что такое рассинхрон? Это непредсказуемое изменение величины лага. Потому что если лаг постоянный, его можно учесть в управлении реактором. По сути именно учёт лага в планировании действий и позволяет сделать управление синхронным. А неучтённое изменение лага ведёт к сбою синхронизации. Что значит "зависают"? Реактор становится невосприимчивым к отключению сигнала редстоуна? Как долго сохраняется зависание? В какой схеме? Что является источником сигнала?

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

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

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

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