man_cubus

В 02.10.2021 в 23:37, eu_tomat сказал:

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

Неожиданно

Это небось всякие оптимизации под SSE влияют

Отличная идея, годится

Что нужно:

промаркировать каким-то образом несколько голографических излучателей чтобы операционка их распознавала не только по uuid

для чего нужно:

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

Вопрос:

как пометить компоненты чтобы распознавать их место в матрице автоматически при подключении? Еще до того как операционка впервые увидит uuid компонента

35 минут назад, eu_tomat сказал:

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

 

Где можно посмотреть примеры реализации такой механики?

Я не нашел, но могу набросать приблизительный план:

вот тут есть пример регистрации события установки блока в мир и формирования списка блоков, которые его не триггерят.

вот тут похоже, но с использованием forge

Дальше по этому вот гайду сохраняем игрока и поставленный блок (если блок прошел по условиям как механизм) в глобальное хранилище

По таймеру на сервере проверяем очередного игрока: не накоплена ли "критическая масса блоков"

А дальше если таки накоплена, даём волю своей извращённой фантазии

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

2 минуты назад, Alex сказал:

Какая разница от кого лаги

Есть разница.

Ты, как я погляжу, за уравниловку. В духе "все одинаково хотят играть" и эта предпосылка - некорректная.

Есть те, кто сидит на сервере сутками, а есть южуал кэжуал фар фром хардкоре.

Мне видится не совсем справедливым оценивать их желание играть на сервере одинаково. И считать что у каждого из них равные права на процессорное время сервера

Маньяки - это по-моему хорошо.

1 час назад, Alex сказал:

Ты как бы хочешь сделать дорогими машинки и процессы, которые создают лаги, чтобы типа их "ограничить" на сервере

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

Но я за справедливость. Если маньяков станет слишком много и настанут слишком мощные лаги - маньяки должны от них пострадать сильнее других. И при таких взрывах реакторов лаги начнут самоустраняться вместе с машинами их вызывающими.

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

С вашего позволения встряну:

Насчет бага с материальной пушкой скорее согласен с Алексом: баги надо чинить.

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

Ограничение на число машин по игроку и чанку - неприятная мера, но необходимая на густонаселенных серверах. Атомик вряд ли можно к таким отнести.

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

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

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

И радиационное заражение на n*2 дней реального времени, где n - число реакторов, такое, чтоб и хазмат не спасал

То же самое можно организовать со взрывом механизмов от неправильного вольтажа: чем больше механизмов на одном проводе тем сильнее рванёт.

Таким образом те кто больше всего лагов вызовет сильнее рискует.

Только что, eu_tomat сказал:

В какой версии так происходит?

Я ж написал что это предположение, гипотеза. Написал как её проверить. Причём тут номер версии чего бы то ни было?

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

Для нагруженного сервера это не совсем верно и при старте может вызвать как минимум отставание аптайма. А если еще и entityPlayer.getEntityWorld.getTotalWorldTime обнуляется для сервера целиком, то аптайм уйдёт далеко назад от последнего таймстампа.

Еще раз: я этого не знаю, это только предположение которое можно проверить.

16.02.2019 в 21:25, Aex сказал:

меню не отрисовывается

Предположение:

При перезапуске сервера аптайм компьютера обнуляется, а переменная timestamp остается неизменной.

Таким образом после перезапуска

(computer.uptime() - timestamp > TimeOut) and (TimeOut > 0)

всегда будет ложным и ShowMenu() на с167 строке не выполнится.

Проверка: нужно проверять не ушло ли значение uptime назад.

23.03.2019 в 23:34, Firec сказал:

Забыл сказать. Данные строчки вызываются без ошибок.

Есть такая замечательная утилита: luacheck

Я сам невнимательный в таких вот мелочах и она меня прям очень выручает. Рекомендую.

Только что, Doob сказал:

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

Нужны либо мухи, либо котлеты. А это ниндзя-индусский код. 

Да, но для однопоточной ОС без параллелизма может прокатить.

17 минут назад, Zer0Galaxy сказал:

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

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

knowns[item_stack.name]()

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

В итоге вместо 10  elseif будет 2-3 функции-обработчика, организованных в одну таблицу.

3 минуты назад, eu_tomat сказал:

@man_cubus И что доказывает этот код?

Действительно, тут нужна прокси таблица. Вот исправленная версия

local prefix = "Я знаю, это "
local function unknown()
  print("Об этом я не ничего знаю")
end

local descriptions = {
  ["minecraft:cobblestone"] = "опять чертова кобла",
  ["minecraft:planks"] = "доски",
  ["minecraft:tnt"] = "кубик веселья",
  ["minecraft:log"] = "бревно, как моя бывшая"
}

local indexer = {
  __index = function(self, key)
    local value = descriptions[key]
    if value then
      return function() print(prefix .. value) end
    else
      return unknown
    end
  end
}

local knowns = {}

setmetatable(knowns, indexer)

local me_controller = require("component").me_controller

for _, item_stack in pairs( me_controller.getItemsInNetwork() ) do
  print(item_stack.label, " = ", item_stack.size)
  knowns[item_stack.name]()
end

6 минут назад, eu_tomat сказал:

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

Неправда

t = {1,2,3,4}
mt = {__index=function(self, key) v=rawget(self,key) if v then return v else return "shit!" end end }
setmetatable(t,mt)

for i=1,6 do print(t[i]) end

7 минут назад, Zer0Galaxy сказал:

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

Я не тестировал. Каковы сомнения?

15.03.2019 в 16:02, Teen_Romance сказал:

Минуты 2 сидел вчитывался и не мог понять фишку, а потом каааак понял 🤣 На самом деле гениально, просто звучит сложно. Если элемента по такому ключу в таблице не будет то выражение просто будет равно nil )

Сложно как то еще применить но я подумаю)

Спасибо большое еще раз

Вот тебе еще один способ сравнения:

local prefix = "Я знаю, это "
local function unknown()
  print("Об этом я не ничего знаю")
end

local indexer = {
  __index = function(self, key)
    local value = rawget(self, key)
    if value then
      return function() print(prefix .. value) end
    else
      return unknown
    end
  end
}

local knowns = {
  ["minecraft:cobblestone"] = "опять чертова кобла",
  ["minecraft:planks"] = "доски",
  ["minecraft:tnt"] = "кубик веселья",
  ["minecraft:log"] = "бревно, как моя бывшая"
}

setmetatable(knowns, indexer)

local me_controller = require("component").me_controller

for _, item_stack in pairs( me_controller.getItemsInNetwork() ) do
  print(item_stack.label, " = ", item_stack.size)
  knowns[item_stack.name]()
end

Для того чтоб посмотреть как оно работает, надо подключиться к контроллеру МЭ-сети адаптером.

Это прекрасно!

Пожалуйста добавьте репку в  hpm

46 минут назад, ECS сказал:

В таком случае я вообще не понимаю, что тебя удивило в нашем общении ВК. Каков собеседник - такой и диалог.  

У тебя безусловно абсолютно истинные и объективные критерии оценки собеседников в ВК и всегда корректный стиль общения. Всегда.

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

22 минуты назад, ECS сказал:

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

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

22 минуты назад, ECS сказал:

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

И действительно, ну надо же. И по моему примитивному критерию тоже можно. И я это сделал. О как, "вас заметили"

22 минуты назад, ECS сказал:

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

О том называть ли технически не-ось осью, разве нет?

22 минуты назад, ECS сказал:

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

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

22 минуты назад, ECS сказал:

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

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

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

22 минуты назад, ECS сказал:

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

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

22 минуты назад, ECS сказал:

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

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

22 минуты назад, ECS сказал:

Если тебе нужен копипаст программными средствами, то он ничем не отличается от такового на опеноси, благо либа filesystem у них эквивалентна:

Пример прочёл. Да, такой способ лучше.

22 минуты назад, ECS сказал:

Вкусовщина. Использовать объектное UI или консоль - дело субъективное. И о каком сокрытом от человечества наброске речь? Майнось уже несколько лет как на рынке, а стенделон версия ничем от нее не отличается. Вы здоровы, батенька?

Если использование объектного UI предполагает еще и графические либы и вот такие требования к памяти то не всегда это дело субъективное.

22 минуты назад, ECS сказал:

Не можешь. Стандартная Lua io вынесена за пределы в опенкомповской песочнице в файле Machine.lua, а лишь затем заоверрайжена опеносовской версией.

Я сказал "почти стандартная". Не уловил, да?

Технически правильно всё же не не называть MineOS полноценной ОС.

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

Кроме того разумеется фраза

Цитата

чертовы доморощенные эксперты-казуисты продолжают лезть изо всех дыр

не является переходом на личности, но токсичной - да, является.

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

2 часа назад, ECS сказал:

 

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

Тем не менее твоя ОС с её более лучшими модулями на минимальной конфе не запустится. Потому и сравниваю. Я ведь не смогу запустить более лучшие модули отдельно, правда?

2 часа назад, ECS сказал:

Если же говорить о самих осях, то я напомню, что опенось, имеющая элементарный интерфейс, в принципе не может иметь высоких требований.

Самоцитата: [сравнивать] точно нельзя. Потому что они ориентируются на разные вещи и исповедуют разные подходы

2 часа назад, ECS сказал:

Откуда им взяться-то?

Ну ты же откуда-то взял что ОС - это непременно богатая графика, верно?

2 часа назад, ECS сказал:

Экранного буфера нет, вся отрисовка идет на прямых обращениях к GPU, объектно-ориентированного интерфейса нет, I/O-буфер жестко ограничен 512 байтами.

воды нет. Населена роботами.

2 часа назад, ECS сказал:

Я бы удивился, если бы она не запускалась на первой плашке.

Вот и я не удивляюсь.

2 часа назад, ECS сказал:

Однако подобная простота критически уступает в производительности: при попытке отрисовать десктоп с несколькими приложениями через GPU ты вряд ли получишь больше 1 кадра в 3 секунды.

Это если мне непременно нужен оконный десктоп с параллельно выполняющимися тремя приложениями. В однопоточной системе.

2 часа назад, ECS сказал:

Для серьезных графических систем требуется двойная буферизация графики, и даже при грамотной оптимизации библиотек экранный буфер будет жрать память, словно Скуби-Ду пончики на ярмарке. Сам посуди: экран третьего уровня имеет максимальное разрешение в 8000 псевдографических пикселей. Каждый пиксель - это цвета фона и текста по 3 байта каждый, а также символ в UTF-8, способный жрать вплоть до 4 байт памяти. Даже если взять идеальный случай, когда экран заполнен символами, занимающими в среднем 2 байта, выходит 64000 байт на один фрейм экранного буфера. А у него их два. Вот тебе и плашка памяти первого уровня, заполненная почти целиком. Повторюсь: ты сравниваешь несравнимое.

Как и ты. Но свой критерий сравнения я уже приводил.

2 часа назад, ECS сказал:

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

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

2 часа назад, ECS сказал:

А сложность или простота разработки - понятие крайне относительное: для опеноси и опекомпов имеется OC Wiki, для майноси - документация по GUI.

Для простейшего фонового сервиса не нужен гуй. И их у меня довольно много в репе. И все под rc. Что например в МайнОС есть вместо rc?

2 часа назад, ECS сказал:

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

А меня ломает пилить ненужный мне гуй.

2 часа назад, ECS сказал:

Стесняюсь спросить, что во фразе "результат разработки законсервирован до лучших дней" тебе не понятно?

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

2 часа назад, ECS сказал:

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

Чудесно. Если б еще графическая часть не была непременно обязательно запускаемой - было бы идеально. Майкрософт со своим Windows Server 2018 Core тоже к этому пришла. На пару десятков лет позже юниксоподобных ОС.

2 часа назад, ECS сказал:

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

Эти ограничения и называются "вежливость"

2 часа назад, ECS сказал:

Если человек адекватен, вежлив, не токсичен, то он получит аналогичную реакцию в ответ.

Если повезет

2 часа назад, ECS сказал:

В противном случае от приветов маме никто не застрахован. И если с тобой я вел себя не так, как ты ожидал/рассчитывал/желал - ну что ж. Мяу.

Да, всё верно, ведь ты никогда не ошибаешься.

2 часа назад, ECS сказал:

Подтасовка фактов о трудозатратах на отсутствующую документацию к неопубликованному и никак не афишируемому софту, "законсервированному до лучших дней"? Интересная теория.

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

2 часа назад, ECS сказал:

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

Как я сделаю копипаст внутри своего приложения? Кусок кода для консольного исполнения я для OpenOS привёл. Может приведешь как то же самое делается через особенный, более совершенный механизм в MineOS standalone? Так же? Или как в каком-нибудь win32 API с обязательным указанием хендла на окно приложения?

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

Вообще, системное программирование, а речь именно о нём если ты сейчас не понял, на винде до выхода такой вещи как PowerShell был тем еще геморроем. И Майки выпустили достаточно приличный консольный инструмент. Которому всё же не хватает простоты того же bash. Аналогия понятна?

2 часа назад, ECS сказал:

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

Не совсем. Я могу и практически стандартную io задействовать. Но зачем?

52 минуты назад, ECS сказал:

  

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

Допустим.

Цитата

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

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

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

Цитата

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

Ну, тут сложно сказать. Утилита cp - это прикладное ПО? Да. Можно ли без неё и остального элементарного ПО нормально работать с ОпеноОС? Нет. Так что грань несколько размыта. Вон, недавно видел реализацию архитектуры с микропитоном всместо Луа, и что? Мне очень нравится идея использования питона, но она ж бесполезна без скелета из прикладного ПО с единственным интерпретатором, который запускается после загрузки.

Цитата

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

Окей. Но я сравниваю ОпенОС с МайнОС в том числе и по наличию таких скриптов.

Хотя основной критерий лично для меня вообще примитивен донельзя: насколько легко написать под %ОСнейм% программу для %действиенейм% осложнённую %наборфакторовнейм%? В случае с ОпенОС ответ - "довольно просто". В случае с МайнОС в в non-standalone виде бует "точно сложнее". Просто потому что МайнОС сама съедает немало системных ресурсов и на робота первого уровня её не поставить, к примеру.

А в standalone режиме - вообще непонятно куда копать и как оценить сложность, ибо пререлиз и альфа.

Зато кнопочки и обои. Но каждому своё как я уже говорил.

Цитата

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

Шикарно. И документацию тоже ко всему этому? Потому что вон Фингер тоже свой wonderful написал, а как им пользоваться простому говнокодеру вроде меня
 непонятно. Хотя в отличии от твоего творения у него доки почитать таки завезли.

Цитата

Конкретизируй. Пустословить и оскорблять каждый горазд.  

Опыт личной переписки в вк. Ты действительно хочешь чтобы я принёс это сюда? Или слова "ИМХО" для тебя недостаточно и ты решил что раз ты такой замечательный, то всем без разбора нравишься? У меня для тебя плохие новости в этом плане.

Цитата

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

Для меня лично заявление о трудозатратах - подтасовка фактов. Потому что помимо реализации низкоуровнего апи для работы с объектами ОС есть еще то самое базовое прикладное ПО, написание документации для всего этого. И этого ты не делал для МайнОС-standalone

И таки базовое ПО по моему мнению является составной частью ОС просто потому что мне куда проще сделать

os.execute(string.format("cp %s %s"), src_file, dst_file))

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

25.12.2018 в 15:02, ECS сказал:

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

Эх, мяу 

Здесь мерилом работы считают усталость. ©

Но даже если так, то первый релиз опенкомпов был согласно гитхабу 26-02-2015. И что, вот прям с первого же релиза вы с группой товарищей начали пилить вашу МайнОС? Или даже раньше первого релиза, телепатически предугадав выход опенкомпов?

Сомнительно.

Также сомнительно что можно поставить знак равенства между трудозатратами преобразованиея MineOS в MineOS standalone (с готовыми модулями из опеноси) и написанием OpenOS с нуля.

Цитата

Эта фраза уже бичом нервов стала

А с нервами у тебя вообще не всё хорошо. Имхо.

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

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

Каждому - своё.

И лично мне Майнось пока не пригодилась.

Добавлю мою любимую схему начального реактора без камер на 9 стержней с эффективностью 3,33 и выходом в 100 Еу/тик

Фидбек