Опубликован выпуск операционной системы MenuetOS 1.50, разработка которой ведётся полностью на ассемблере. Сборки MenuetOS подготовлены для 64-разрядных систем x86 и могут быть запущены под управлением QEMU. Сборка системы занимает 1.4 МБ и сформирована в виде образа дискеты и iso-образа для записи на CD (поддерживается запуск в VirtualBox). Исходные тексты проекта распространяются под модифицированной лицензией MIT, дополненной требованием согласования любого использования в коммерческих целях...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60711
Лютые чуваки! Я иногда простую прогу на Си не могу написать, а они целую ОС на ассемблере((
Писать на ассемблере и писать лучше компилятора си на ассемблере это разные вещи. Опять же, свой сишный код ты запустишь на телефоне, а ассемблерный нет, так что не расстраивайся особо, ты просто опоздал родиться. Во времена доса это было проще.
Чтобы компилятор си умел писать лучше чем программист на ассемблере, нужно уметь его этому научить, то есть знать как правильно писать на ассемблере. А если уже знаешь как правильно писать на ассемблере и имеешь цель написания оси на асме, то компилятор си превращается в лишнюю сущность.К тому же си добавляет ундефинид бихаваёров, а всякие расты -- нечитаемой тяжести. Тут ж ось для умеющих на программирование, а не фпродакшонцов.
Какой бред, вам это кто рассказал, где вы эту жость вычитали? Оптимизировать должен компьютер, это его задача. А чтобы UB не было - ну так надо правильные языки брать, где его нет by design.
Вас жестоко обманули, задача компьютера выполнять действия, а думать, в том числе над оптимизациями, должен программист.
> а думать, в том числе над оптимизациями, должен программист.приведите пример кода на сях, который вы можете оптимизировать на асме лучше, чем какойнить gcc или llvm (без отключенных оптимизаций, ессно).
возможно, поиск подобного решения позволит вам сделать большое открытие: оптимизаторы написаны не дураками и работают настолько хорошо, что в подавляющем большинстве случаев просто нет смысла с ними соревноваться.
libjpegturbo гляньте например. Опять же иногда при приходится даже в машинных кодах писать и делать кусок памяти executable, ибо внезапно msvc не умеет naked функции для x64...
> приведите пример кода на сях, который вы можете оптимизировать на асме лучше, чем какойнить gcc или llvmКомпиляторы без оптимизации добавляют лишние команды ASM, сжирающие процессорное время без изменения результата. Например, битовое расширение 8->16->32 без надобности.
В этих условиях простое включение оптимизации показывает превосходный результат всем, кто избегает изучать ассемблерные листинги.
Многократно зафиксировано на тулчейне микроконтроллеров.
Вам во времена перфокарт, да не фортрановские, а когда машинный код напрямую вводили.
У вас ещё неоптимизирующий компилятор? Тогда мы идём к вам!
Программист нужен только до тех пор, пока компьютер глуп и не понимает естественный язык (а ещё лучше, мысли) человека. В каком-то уже не таком отдалённом будущем программисты станут лишними.
И вместо программ будет нечто, выдающее решения "похожие на правду".Примерно так же, что программист будет не нужен, говорили при появлении SCADA.
А потом выяснилось, что работы для обеспечения возможностей SCADA в разы больше. И нужны они только для того, что бы неспециалисты не имея четких критериев, что то могли делать.
Вот почему пользователями и используются вида и линуксах иногда. Потому что разработчики минуэтос думают, как оптимизировать, а остальные просто клепают нюто, на что есть спрос сейчас, оставляя всё остальное на откуп компилятора.
>Тут ж ось для умеющих на программирование, а не фпродакшонцов.Программирование - это не дворды из регистра в регистр перекладывать.
В том и дело, что компилятор этому учат под каждое поколение процессоров, каждые несколько лет. И если посмотреть на применяемые оптимизации, легко понять, что человек с таким не справится никогда. Ассемблер был популярен, когда компилятор ещё не умел эффективно оптимизировать код. Это ещё не говоря про PGO. А SIMD оперировать никто не запрещает -- компиляторы самостоятельно могут только достаточно примитивные оптимизации применять.
> А если уже знаешь как правильно писать на ассемблере и имеешь цель написания оси на асме, то компилятор си превращается в лишнюю сущность.С таким мышлением мы бы до сих пор ткани вручную ткали и горшки на гончарном круге лепили.
Если бы из пещер выбрались, что маловероятно.
В пещерах сыро и холодно, там вряд ли жили также как и сейчас не живут в погребах. Просто наскальная живопись и останки лучше сохранялись в пещерах, вот и пошли "пещерные люди"
> Чтобы компилятор си умел писать лучше чем программист на ассемблере, нужно уметь
> его этому научить, то есть знать как правильно писать на ассемблере.Знаете? Расскажете, что делается ниже?
Сравнительный анализ perf stat до и после модификации:
Performance counter stats for ***:
25 825 846 646 cycles:u # 2259676,844 GHz
12 440 035 801 instructions:u # 0,48 insn per cycle
3 120 008 855 branches:u # 272990537,667 M/sec
1 039 998 618 branch-misses:u # 33,33% of all branches9 581 647 564 cycles:u # 2254505,309 GHz
11 600 026 289 instructions:u # 1,21 insn per cycle
2 280 005 786 branches:u # 536471949,647 M/sec
80 002 443 branch-misses:u # 3,51% of all branches
...--- a/interp.asm
+++ b/interp.asm
mov eax, [opcode]
shl rax, instruction_size_log2
+; Переход никогда не происходит. *********
+; ***************************************
+ jc .stop
lea rax, [rax + vm_base + vm_base_lbl - execute_instruction]
next_opcode
jmp rax
- ud2
+.stop: ud2
вы забыли приложить документацию по асм хрен пойми какого цпу и его даташит
Такой процессор "по умолчанию" тут у каждого, такой же как и у ОС в обсуждаемой теме. А даташиты у всех экспертов конечно же и так есть.
> у всех экспертов конечно же и так есть.ну тогда надо подчеркнуть экспертов-телепатов, я просто не из таких :)
Так я конкретного эксперта спрашивал. Он так и не смог ответить. Наверное, занят, учит компилятор компилировать.)
Пример конечно занятный и зачетный, но скорее он не про умение в ассемблер, а про кучу штеудовских костылей и спекулятивных подпорок в x86.
И даже как-бы получается что знание оттенков вкуса этого гуана становиться "экспертизой".Ну и особо примечательно что все эти-же костыли сейчас активно пропагандируются как "сильные стороны и преимущества" RISC-V ;)
Ассемблер вне привязки к архитектуре не существует.
Это вы ещё ARM-овских костылей не видели.
Не, я про другое.Меня печалит что одни господа пытаются платить мне еще больше, за всю эту "экспертизу" (на деле уменье штопать чужие носки), но не ради своего (например допеределки эльбрусов).
А другие господа рядом упорото называют эти-же причины проблем "перспективами и преимуществами" RISC-V. В результате время, увлеченность и труд неплохих инженеров расходуется на полировку подаренных стеклянных бус.
Эльбрус-брелоки лучше стеклянных бус, ага.
Индейцы и папуасы всегда предпочитали бусы.
Как минимум, пока не стало слишком поздно.
Это исторический факт, с которым сложно спорить.Как-то уже давно было сформулировано - каждому свое, но индейцев мне всё-равно жалко.
Особенно жалко племя Сиу, которое некий якобы писатель оклеветал в "Последнем из могикан".
> Пример конечно занятный и зачетный, но скорее он не про умение в ассемблерДействительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.
Ответа, что примечательно, нет.
> И даже как-бы получается что знание оттенков вкуса этого гуана становиться "экспертизой".
Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:
>>> А если уже знаешь как правильно писать на ассемблере
Так то оно рядом замечательно смотрится. ;)
> Действительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.
> Ответа, что примечательно, нет.Патч добавляет несколько строк и исходнику - с такой формулировкой поспорить сложно.
Зачем он это делает и как интерпретировать изменение в счетчиках - тут уже могут быть разночтения.Очевидно что добавление инструкции перехода, который никогда не выполняется, увеличивает % верных предсказаний.
Это увеличение branch-hit приводит к тому, что предсказатель считает контекст истории переходов связанный с этим фрагментов ценным и сохраняет его дольше, а также пытается реже выкидывать из uos-cache целевые адреса косвенного перехода.
Соответственно, могут быть условия (особенно на синтетических тестах), когда такая "оптимизация" в целом работает в плюс.
Но на другой модели ЦПУ и/или на другом коде/данных, как правило все подобные плюсы становятся отрицательным.> Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:
Нет.
--На всякий уточню - меня расстраивает, что за подобное "штопанье чужих носков" мне не только платят деньги, но и настойчиво хотят сделать это "еще более", вместо того чтобы хотя-бы теже деньги вложить в разработку чего-то собственного (но не в полировку даренных стеклянных бус в виде RISC-V).
>> Я верно понимаю, отвечает тот же эксперт, что писал в #29 вот это:
> Нет.Жаль, эксперимент провалился. #29, #42 и #90 писал точно один, эксплуатируя нумератор Анонимов сайта.
Впрочем, 90 написано позже 81, значит ответить он не смог.
>> Действительно, понять, что делает патч можно по выдаче perf stat и без знания ассемблера.
>> Ответа, что примечательно, нет.
> Патч добавляет несколько строк и исходнику - с такой формулировкой поспорить сложно.
> Зачем он это делает и как интерпретировать изменение в счетчиках - тут
> уже могут быть разночтения.
> Очевидно что добавление инструкции перехода, который никогда не выполняется, увеличивает
> % верных предсказаний.То есть патч увеличивает % верных предсказаний. Это очевидно из чисел в выдаче perf рядом с %. Это мог бы любой ответить, а значит и тот эксперт тем более.
С инструкцией как раз не очевидно и требует знаний, например сходу я не нашёл в Optimization Manual подходящего правила.
> Это увеличение branch-hit приводит к тому, что предсказатель считает контекст истории переходов
> связанный с этим фрагментов ценным и сохраняет его дольше, а также
> пытается реже выкидывать из uos-cache целевые адреса косвенного перехода.
> Соответственно, могут быть условия (особенно на синтетических тестах), когда такая "оптимизация"
> в целом работает в плюс.
> Но на другой модели ЦПУ и/или на другом коде/данных, как правило все
> подобные плюсы становятся отрицательным.+; Переход никогда не происходит. Предотвращает предсказания следующего
+; косвенного перехода, во многих случаях некорректные.> --
> На всякий уточню - меня расстраивает, что за подобное "штопанье чужих носков"
> мне не только платят деньги, но и настойчиво хотят сделать это
> "еще более", вместо того чтобы хотя-бы теже деньги вложить в разработку
> чего-то собственного (но не в полировку даренных стеклянных бус в виде
> RISC-V).На всякий случай извинюсь, мне надо было обуздать именно того знатока правильно писать на ассемблере.
В данном случае пришлось штопать свои носки, когда оптимизированный код на асме без той инструкции позорно проиграл коду после транслятора Си, где конкретно в этом месте была ещё одна лишняя косвенность. То есть процессор заточили под типовой код (таблицу переходов), он спокойно лишний раз читал память, что мешало ему делать лишние предсказания, на чём и обыграл человека.
> +; Переход никогда не происходит. Предотвращает предсказания следующего
> +; косвенного перехода, во многих случаях некорректные.На всякий, это давно не так.
"Не переход" является таким-же учетным фактом как и "переход" для подавляющего большинства предсказателей, т.е. почти для всех актуальных ЦПУ с предсказателями (не только штеудовских ядер).
Упрощенно, предсказывается не факт перейдем/не перейдем, а адрес перехода (как вариант в координатах uops-кеша), а по факту корректируется статистика угадали или нет+актуальный_адрес.На (относительно) простых предсказателях этот не-выполняющийся переход просто всегда предсказываться, в том числе первый раз как переход вперед. Поэтому почти не оказывает влияния.
На более сложных предсказателях, с буфером истории, может происходить масса эффектов. В частности, тут существует отдельная проблема/задача разделение всего графа/потока переходов, на фрагменты по которым есть ресурсы/возможность накапливать статистику. Например, упрощенно, для фрагмента кода с 6 переходами из всех 64 вариантов 4 могут быть наиболее вероятными, а какие 32 совсем холодными. Но проблема начинается с выбора начала фрагмента, и одна из эвристик тут - начинать фрагмент с перехода, которому не нужна история, т.е. с добавленного патчем jc.
Далее, в реальном коде загрузка опкода в регистр будет с дополнением нулями. Соответственно, CF всегда и гарантированно будет 0. Подобные ситуации используются штеудом для реализации "косвенного управления" (при трансляции инструкций в uosp участвует микрокод, который детектирует подобные паттерны и вставляет отдельные специфические uops-команды в конвейер).
Так вот, весьма вероятно, что использованный паттерн либо генерирует upos отключения предсказателя для следующего перехода, либо подсказывает поставить pivot point для отметки начала фрагмента для накопления статистики переходов.
С одной стороны, погружение в подобные тонкости может показаться интересным. Но как уже писал, мне это уже давно представляется "штопаньем чужих носок", вместо того чтобы делать что-то собственное.
>> +; Переход никогда не происходит. Предотвращает предсказания следующего
>> +; косвенного перехода, во многих случаях некорректные.
> На всякий, это давно не так.У меня про данный частный случай. В цитате выше я восстановил комментарии, закрытые в исходном сообщении звёздочками.
execute_instruction:
mov eax, [opcode]
shl rax, instruction_size_log2
+; Переход никогда не происходит. Предотвращает предсказания следующего
+; косвенного перехода, во многих случаях некорректные.
+ jc .stop
lea rax, [rax + vm_base + vm_base_lbl - execute_instruction]
next_opcode
jmp rax
- ud2
+.stop: ud2> "Не переход" является таким-же учетным фактом как и "переход" для подавляющего большинства
> предсказателей, т.е. почти для всех актуальных ЦПУ с предсказателями (не только
> штеудовских ядер).В данном случае процессор не знает значение opcode, потому предполагает возможность перехода и видит его целью ud2.
Я наивно последовал правилу:
Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are
present, try to put the most likely target of an indirect branch immediately following the indirect
branch. Alternatively, if indirect branches are common but they cannot be predicted by branch
prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the
processor from decoding down the fall-through path.но без "неперехода" предиктор упорно заставлял процессор начинать исполнять следующую после ud2 команду.
Может быть там надо было два раза подряд ud2 поставить, как в том анекдоте, но у меня не стояла задача оптимизировать, потому не разбирался в деталях. Надо было проверить пару гипотез, для чего пришлось переписать с Си на асм (таблицу переходов выкинул - это не оптимизация, а упрощение кода). Когда в итоге код на асме заработал вдвое медленнее, пришлось дотягивать его до уровня компилятора.
> Упрощенно, предсказывается не факт перейдем/не перейдем, а адрес перехода (как вариант
> в координатах uops-кеша), а по факту корректируется статистика угадали или нет+актуальный_адрес.Да, тут игнорируется расширение нулями 32-разрядного eax (что гарантирует неисполнение перехода), либо ud2 имеет приоритет, как команда остановить декодирование.
>[оверквотинг удален]
> начинать фрагмент с перехода, которому не нужна история, т.е. с добавленного
> патчем jc.
> Далее, в реальном коде загрузка опкода в регистр будет с дополнением нулями.
> Соответственно, CF всегда и гарантированно будет 0. Подобные ситуации используются штеудом
> для реализации "косвенного управления" (при трансляции инструкций в uosp участвует микрокод,
> который детектирует подобные паттерны и вставляет отдельные специфические uops-команды
> в конвейер).
> Так вот, весьма вероятно, что использованный паттерн либо генерирует upos отключения предсказателя
> для следующего перехода, либо подсказывает поставить pivot point для отметки начала
> фрагмента для накопления статистики переходов.Так и как писать на ассемблере? Это лишь малая часть необходимых знаний, что бы обогнать транслятор. Оратор, кому я отвечал, утверждал, что это элементарно. Мне пришлось когда-то посидеть с AMD CodeAnalyst, где проводилась симуляция конвейера и микрооперации можно было увидеть глазами, потому на автомате могу написать получше некоторых, и то сел в лужу.)
Разве что в образовательных целях писать: у AMD64 достаточно регистров, системные вызовы в Linux проще любимого некоторыми DOS-а, нет бестолковой возни с сегментами.
> С одной стороны, погружение в подобные тонкости может показаться интересным. Но как
> уже писал, мне это уже давно представляется "штопаньем чужих носок", вместо
> того чтобы делать что-то собственное.Я узнал, что у Эльбруса отдельный стек для адресов возвратов, и задумался, как ещё возможно использовать стек данных. Проверил подручными средствами, реализовал стековую виртмашину, использовав аппаратный стек. На AMD64 пришлось всё затолкать в один стек, но сработало. На Эльбрусе, наверное, красивее должно смотреться, если бы к языку типа Си добавить возможность работать со стеком явно.
Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?
Вроде уже делали с forth. И javacard наверно, да? Вот эта вполне популярна и повсеместна. По-сути своей, x86 -- тоже байткод, который исполняется на микрокоде и далеко не всё в нём реализовано напрямую в железе.
Была Sun-попытка году, эдак, в 1995-м - Java bytecode CPU.
> Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?а чем по вашему представлены коды операций процессора (opcodes), разве не байтами? :)
> Может сразу отказаться от x86 и создавать процессоры для исполнения байт-кода?и вообще байт-код или бит-код совсем неудачные названия, нужно как-то i-code (interpretted code) или i-bcode (interpretted binary code) или ir-code как в случае с llvm или am-code (abstract machine code) или am-bcode (abstract machine binary code) обязательно подчеркнув бинарность.
Всё уже изобретено до вас. Это называется pcode, Вирт чтобы не париться с портированием паскаля на 100500 платформ, портировал интерпретатор байткода, компилируя паскаль в байткод. И байткод он называл pcode, в смысле portable code.
> Всё уже изобретено до вас.так зачем продолжаем говорить байт-код?
> И байткод он называл pcode, в смысле portable code.
Ну вот, замечательно.
Bytecode (also called portable code or p-code) - ну и где логика? кто и зачем это ввел?
Ты посмотри сколько времени они с этой ос ...морочатся... Ты за такое время и на си написал бы и на ассемблере и р--т бы всё переписал.
Он же нам поведал, стол даже простую прогу не способен.
на каком живом девайсе можно потестить?
VirtualBox, VMWare, qEmu.
Для начала готовьте PS/2 мышь и клавиатуру.
Эмуляция в биосе, наверное, тоже подойдёт (но не везде она есть).
> на каком живом девайсе можно потестить?устройся на подработку в музей компьютерной техники, там какойнить девайс можбыть воскресает по ночам -- вот на нём и тести.
Сидим на колибри проблем нет.
Зато наверно на любом железе летает...
Как это на любом железе? Раз Ассемблер, значит привязан к железу. Тут бы спросить на каком работает?
Вот список
http://www.menuetos.net/hwc.txtП.с.
Ленивая жопа )
>Вот список
>http://www.menuetos.net/hwc.txtИсчерпывающий список Network card
3Com595
Intel Pro/1000 GT
Realtek RTL8029
Realtek 8111CДавно собирался выкинуть эти раритеты на помойку. Теперь подожду - могут еще пригодится.
Компилятор С гораздо лучше оптмизирует почти любой код, чем человек напишет на ассемблере.-- Встраивание функций (inline),
-- переупорядочивание инструкций, чтобы лучше работало параллельное выполнение инструкций,
-- векторизация,
-- разные оптимизации типа замены деления умножением...Вручную ты такого никогда не сделаешь. Можешь реализовать какой-нибудь алгоритм на ассемблере, а затем на C и посмотреть на godbolt, какой код сгенерирует компилятор. Разница будет видна сразу.
Для stm32, avr, i8048-52 я, вместо программиста, пишу лучше, чем выхлоп сишки.
Про i8048-52 соглашусь. А вот с AVR и, тем более, STM32 сомнительно. Сам был изумлён, как avr-g++ хорошо классы с виртуальными методами перемалывает в машинный код.
Под АVR разница между ассемблером и выходом с компилятора конская, как по скорости, так и по объёму.Для Cortex великого смысла писать на ассемблере нет, ибо по скорости и объёму не жмёт.
Но для Cortex M0, в критичных местах, особенно в энергоэффективном ПО, тоже вполне можно уделать компилятор.А вот где компилятор часто генерировал код в целом лучше, чем ассемблер, так это MSP430.
докажи, балабол, давай ссылки
> -- разные оптимизации типа замены деления умножением...
> Вручную ты такого никогда не сделаешь.Вот это не верно. Все знают™ про Magic Divider by The Svin.
> Компилятор С гораздо лучше оптмизирует почти любой код, чем человек напишет на ассемблере.Тотоже криптографию и кодеки пишут на ассемблере. Чтобы медленнее было, да.
Ну не всё там пишут, а вставочки, где совсем-совсем жёстко.
>Чтобы медленнее было, да.прикинь да, крипту пишут на асемблере что бы время выполнения разных операций было одинаковым.
соответственно все равняют по самой медленной операции.
Чета сомневаюсь, что компилятор Си сможет оптимизировать код настолько, что операционка на выходе уместить в 1.4мб.
Надо выкинуть glibc и оптимизировать по размеру. Правда, получится не так быстро.)
Программисты для микроконтроллеров с Вами не согласятся.
Можно и на Си написать компактно.
Но.. если цель минимальный размер кода, исходник будет не на много читаемее ассемблера.
А вот читаемый Си исходник, грубо производит x86 бинарник вдвое большего объёма, по сравнению с ассемблером. Но такой исходник можно и поддерживать, и быстро развивать.
А не писать по 2 кБ бинарника в неделю, как в обсуждаемой ОС.
Переупорядочивание инструкций современные компиляторы делают так себе, не очень, а местами даже вредят.
И нафига она, поиграть в бомбермена, или шашки?
На ней хотя бы ютуб можно посмотреть?
Видео можно, Ютуб, стандартными средствами, нельзя
> Видео можноDVD из кладовки можно. И всё.
Хорошая альтернатива линуксу.
Нет.
Для Pine Star64 можно? ... А когда будет? ... Ясно, долго ждать.
К большому сожалению это чудо написано на x86_64 ассемблере. Даже на мой аллвиннер не встанет(
Тут целая ось в 1.4MB, а у меня проверочный проект на Electron в распакованном виде 300MB занимает :|
qnx 4 тоже на дискетку влезал , можно было по диалапу инет получить и посидеть в браузере
А современный интернет по диалапу? Можно будет посидеть просто в пустом браузере.
http://linux3d.netpedia.net/Сюда ходи
Выбрось каку(электрон).
Некоторые современные игрушки сотни гигабайт весят.
Так игрушки весят сотни гигабайт из-за 4k-текстур и несжатых звуков, а не кода.
> Некоторые современные игрушки сотни гигабайт весят.Там не Гигабайты кода, а значительный объём занимают, модели, текстуры, звуки, карты.
Даже древнний Морровид с модами распухает за 50Гб, при том что сам с текстурами и прочим был менее 1Гб, и так таким и остался, и в модах, во всех вместе не наберется хотя бы еще гигабайта кода.
> проект на Electron в распакованном виде 300MB занимаетЕсли тебя это смущает, значит, ты не безнадёжен.
в отличие от тебя
Вообще я впечатлён. Ещё бы браузер с Ютубом и норм. Когда графоний разовётся до возможности поддержки Вайна и игрушек в нём. Линь и Бзду можно будет выкинуть.
А колибри лучше!
Она и в правду существует. Даже образа скачать можно и по-моему там есть браузер.)
Обозначьте хоть плюсы. А так получается, что Вы прокричали что-то сродни "Я пустотрёп".
Если вам интересно - вы можете сами сформировать свое мнение. Если нет, то 300 страниц обоснования Вам могут написать, но не за бесплатно.
Открываешь такой сайт этого маргинального форка маргинального сабжа, а тебе с порога буфера и предолжение "псс, парень, за новостями пройди в наш телеграмм". По ссылкам небось еще и вишмастеры с депозитфайлс по смс качать надо?
VNC - прошлый век. Сейчас желательна поддержка Spice и RDP. Чтоб звук и видео можно было передавать.
Для Spice есть поддержка в DarkNet.
Пора переписывать на Aarch64. Практическая польза её существования на SBC и то, не сильно навороченных.
У сабжа есть описный пакет, браузер, RDP клиент, драйверы на МФУ Kyocera? Какой практический толк от сабжа?
Никто не ответил на мой вопрос, потому что нечего ответить. Потому что эта ОС бесполезна для широкого круга задач. А какие узкоспециализированные задачи на неё можно решать не представляю.
какой бы быстрой ОС не была, веб-браузер может сделать из неё тормоза. это как великий уровнитель всех ОС :)
Links не тормозит.
> Links не работает на 99 % современных сайтовФиксанул, можешь не благодарить
99% современных сайтов бесполезны.
А полезны только те, что открываются в lynx, да.
Чем оно лучше колибри?
Тем что запускает на 64 битах)
Просто создатели колибри, взять код смогли, копирайты заменить смогли, а вот в 64 бита не смогли.
Так и живут на 32 битах.
Значит, надо кому. Но это шаг назад. Не зря же Си придумали, чтобы на асме меньше кодить.
секундочку, сам менуэт же не опен сорс! на сайте есть исходники только от приложений и драйверов
Нет, мы идём другим путём, где пару строк кода будут занимать терабайт, и вечный срач кедерастов с гномосеками нам единая услада.
TempleOS всегда лучше всех.
Мда.... Беднягу Тэри жалко очень. А такой новатор был...
Классная идея, отличные оптимизации, мне нравится! Всё быстро, компактно! Супер!Как там с переносом на ARM дела? Хочу на Raspberry Pi такое, у неё памяти как раз не так уж и много. А ещё сейчас много RISC-V, тоже бы надо! Джва года готов подождать!
Извини, займёт ровно 3 года, так что не жди.
ассемблер и переносимость? ну, жди, жди
Часть инструкций тупо копипастом меняется, там переписывать немного. А вот именно оптимизация под платформу — да, небыстро.
Но помнится, у менуэта и колибри сама архитектура была не очень (не потому что ассемблер, просто так сделали, может и исправили) из-за чего ни нормальной изоляции прог, ни стабильности системы не было.
И очень может оказаться, что из-за раздробленности армов, не имеющих старых стандартов, которые есть у x86 типа тех же ps/2 и vga получить что-то работающее хотя бы на одной железке — уже подвиг.
> Часть инструкций тупо копипастом меняется, там переписывать немного.У нас специалист 80lvl в треде.
От так яны сягодни и пишюць свои проекты - копипастом на Электроне, вот так оно все выходзиць, как есть.....
Пусть в на Распберри в Dosbox запускает, ибо ос не ьребовательная к ресурсам, и как ни странно, должно работать на любом Распберри.
Хотя... Ой, а надо 64х битный эмулятор. Тогда облом.
Хм... Ну вот заинтересовал меня, допустим, этот видео-проигрыватель - mplayer. Захожу на сайт, скачиваю, а там бинарник, и в лицензии "Redistribution, reverse engineering, disassembly or decompilation
prohibited without permission from the copyright holders." Какой мне прок от того, что он на ассемблере? И вообще, как я узнаю, что он на ассемблере? Исходников же нет, он может быть на чем угодно написан.
> И вообще, как я узнаю, что он
> на ассемблере? Исходников же нет, он может быть на чем угодно
> написан.Посмотреть в дизассемблере, поискать характерные признаки.
Так как я посмотрю в дизассемблере? Он же phohibited from disassembly?!
Эту формальность автор добавил из жалости к клонерам из Коллибри ОС, что бы те могли сохранить лицо и вместо "мы не умеем" сказать "на нас обиделись".
чёт не понял, а где тиринг?
Когда KDE и файрфокс под неё пропатчат, тогда и смысл будет, а пока что линукс лутше к сожалению...
Это. Просто. ОБАЛДЕННО.
кто ее (ОС) вообще юзает?
кто?
похоже что никто.
просто такой прикольный проектик.
Оно сходу в тюнерные карты умело, видимо писалось под какой-то бокс для захвата и может ещё ретрансляции вещания.
Но сейчас такое лучше делать на видеокарте.
непонятно. какие так скаааать перспективы у этой ОС.
что для нее делать будут?что с ней делать будут?
юзать для видеокамер для охранников?
или десктоп?реальное приложение пишется на С или т.п.
а не на Асме.
вроде MenuetOS, а выглядит как HaikuOs
А зачем это нужно? Неэффективно ведь. С после компиляции превращается в машинные команды. Языки высокого уровня намного проще для понимания, в них совершаешь меньше ошибок, скорость работы в десятки раз выше чем на ассемблере. Это как есть суп вилкой.
А эта ось не для побыстрее написать, это про грамотное использование ресурсов.Компиляторы сначала нужно научить оптимизировать, да и то все возможные расклады оно не покроет. Тяп-ляпычи молятся на компилятор, но как оно внутри оно работает они знать не знают.
Писать ось с целью минимизации потребления ресурсов и наивысшей скорости на всяких си и проч., это как есть суп экскаватором.
> А эта ось не для побыстрее написать, это про грамотное использование ресурсов.Человеческих ресурсов или каких? Годы жизни выкинутые на мертвый бай дизайн проект - такое себе
> Компиляторы сначала нужно научить оптимизироватьЯ всё еще жду ответа на вопрос #53. Уже можно было даже скомпилировать из чужих.
Есть железо чьи возможности не раскрывает данная система. В ней нет даже элементарной возможности записать изображение с экрана(Чел на видео снимают экран сторонней камерой). Это грамотное использование ресурсов? Потенциал компа не раскрыт. Ты несешь полнейший бред. Советую обратиться к психиатру по месту прописки.
У меня она не раскрыла даже возможности USB-контроллера (к слову, есть даже досовские драйвера, которые на моей машине успешно работают).
Menuet64 Copyright (c) 2005-2022 Ville Turjanmaa1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation
prohibited without permission from the copyright holders.это даже не опенсорс, вроде это называется freeware, причем только для персонального использования
Да, это называется клозет-сорс проприетарь. 32 битная опенсорс. И колибриос (форк 32 битной) опенсорс. Сабж не запускал, колибри запускал.
Там открытые кода для приложений - menuetos.net/64bit.htmА причины закрытия сорцов банальны
At the moment of the fork and when new copyrights were added to almost all files, there were no significant changes. Most of the kernel files were exactly the same, line by line.
Подумаешь форкнули и перебили все копирайты)
Для последователей жирного воришки емаксов такое естественное - как дышать.
С одной стороны, понимаю парней -- самого бесят калькуляторы на 300+ мегабайт и массовое переползание на тормозные скриптанутые поделия. С другой стороны, сложность написания прикладного софта для такой ОС, видимо, зашкаливает. Респект и уважуха, но не взлетит, имхо.
Отнюдь! Там всё обмазывается макросами и становится похоже на язык более высокого уровня, только со всей подноготной асма на виду.Хотя по каментам видно, что современные питоножабоскриптеры асма в глаза не видели.
Интересно, но бестолково. Нет софта. Нет поддержки железа. В своё время, лет 20 назад, тоже писал ось на чистом ассемблере, но я хотя бы пытался сделать её совместимой и MS-DOS, при этом она с первых строк прыгала в защищённый режим и была многозадачной. И даже что-то простенькое запускалось.
Тут вот в комментах про грамотное использование ресурсов рассуждают. Выделил ей в виртуалке 512 Мб. При загрузке уведомляет, что для включения эффекта прозрачности нужно 640 Мб (хватит всем?).
У меня всё.
Все по Фрейду за красоту надо платить , то же с видео драйверами происходит или ты думал что у тебя paper 4millions на x 4millions на экране это некая шутка 2020-ых годов
А почему в новости сказано "распространяются под модифицированной лицензией MIT, дополненной требованием согласования любого использования в коммерческих целях."В тексте лицензии, кстати крайне коротком, всего три пункта, кроме стандартного AS IS
1) Free for personal and educational use.
2) Contact menuetos.net for commercial use.
3) Redistribution, reverse engineering, disassembly or decompilation
prohibited without permission from the copyright holders.
menuetos.net/m64l.txtНе уверен что пункт 3 вообще совместим с МИТ лицензией.
Эта ОС нужна хотя бы для того, чтобы показать насколько жирными и раздутыми стали современные ОС. Когда вся производительность уходит в абстракции, пережёвывание байткода и бесконечный парсинг, парсинг, парсинг...
Без офисного пакета и браузера не сабж не нужен.
Нафига в HCL перечислены видеокарты если все они только в Vesa mode работают в менуэте?
эх... там жеж целая многолетняя предистория должна быть ссылкой к этой новости, много эмоций, новость без этого голая и лысая((а если дев изначально открывает сорцы народу, а потом у него в попе щёлкает и он закрывает, - то он просто тварина((
..так появилась на свет КолибриОС!!!
а это поделие ставшее с закрытыми сорцами, не достойно даже новостей..
Как то так))
нету там никакой истории.последний раз о них слышал когда ещё всё было 32 битное.
собственно проект был "всё до кучи", ядро гуи и дрова в одной упаковке.
тогда еще мышка на стенной бумаге оставляла следы, а уже нет, уже починили.
> а если дев изначально открывает сорцы народу, а потом у него в попе щёлкает и он закрывает, - то он просто тварина((во-первых, "а что прям все сорцы закрыты"?
Ты всегда можешь скачать applications menuetos.net/64bit.htmво-вторых, почему какое-то б№№№ло как ты вообще указываешь создателю, что делать с его кодом?
это его полное право и никакие об%%ны, не сделавшие для системы вообще ничего, не имеют право раскрывать вякалоа в-третих, там же "целая многолетняя предистория", которую ты пропустил
> ..так появилась на свет КолибриОС!!!Которые, сделав форк, просто перебили все копирайты, на файлах включая неизмененные.
board.flatassembler.net/topic.php?t=16822At the moment of the fork and when new copyrights were added to almost all files, there were no significant changes. Most of the kernel files were exactly the same, line by line. New copyrigths were practically just added to unmodified kernel files (process management, GUI, TCP/IP, disk drivers, etc).
So, that's the reason why M64 is closed source.Но форк так и остался 32битным. И у меня большие сомнения, что они осилят 64.
Так что пожелаем КолибриОС помереть вместе с 32битным железом и вместе со всеми перебитыми копирайтами)
Самая мякотка, что они до сих пор не догоняют, что цитируют:wrz 11 15:00:51 <VMikael> I think we should thik about what we want from a 64 bit os
wrz 11 15:01:31 <jpelczar> - separate address space for each process
wrz 11 15:01:40 <jpelczar> - memory management
wrz 11 15:01:55 <VMikael> how about money ?
wrz 11 15:01:59 <jpelczar> money ?
wrz 11 15:02:08 <VMikael> yesТо есть Вилле предложил им подумать, как они все вместе (we) могут заработать. Например, он продолжает писать код, а остальные как-то способствуют монетизации. У них что-то в голове щелкнуло и они решили, что он с них денег требует.
Почитал эту историю.Вилле сделал то.
Вилле сделал сё.
Вилле прикрутил ещё вон то.
Вилле написал в чат:
- Полагаю, нам стоит подумать, что мы хотим от 64-х разрядной ОС.
- Мы хотим то и это!
- Как на счёт денег?
- Денег????На основании вот этого пользователь написанного Вилле кода, где позже перебили копирайты, публично хамит Вилле.
Пару лет назад эти вахтеры еще ж и форсили что это еще одна дофига отечественная разработка пря как еще один рикталь.
Самое во всей этой истории для меня удивительное, что был такой сайт - wasm.ru, где так или иначе отметились все местные и не очень ассемблерщики, но видать у меня что-то с памятью, поскольку название я помню, а вот что-либо связанное с написанием кода не припоминаю.
> ... так появилась на свет КолибриОС!!!Да, в лучших традициях Рашин Бузинес.
Но что поделать, если цап-царап это просто скрепа.С другой стороны, некоторые из них даже задумывались что делают что-то не так...
yogev_ezra Mon Feb 04, 2013 12:12 pm
"Я думаю, что мы не имеем права убирать упоминание того, что Колибри - это форк MenuetOS (по правилам GPL нужно писать, откуда брали код). Так что оставьте это предложение (и добавьте его обратно в английской версии сайта, где вы его уже убрали)."
"Эта строчка должна оставаться (IMHO), иначе у нас могут быть проблемы с Кикстартером и GNU/GPL."
"Если моё мнение ничего не значит, то не знаю, нужно ли мне заморачиваться с Кикстартером - как бы я не пожалел об этом. Ответственность за выполнение проекта я должен буду взять на себя, а делают тут каждый что хочет."https://board.kolibrios.org/viewtopic.php?f=7&t=1920&p=45536
Смотрим:http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
Цопирайты на месте.
>Но что поделать, если цап-царап это просто скрепа.
Главная скрепа - соврать про "цап-царап" и "скрепы".
> Смотрим:
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
> Цопирайты на месте.
> Главная скрепа - совратьАвтор пишет, что один файл - это не показатель, из остальных копирайты вырезаны:
New copyrights slapped to the beginning of almost all 32 bit files and in other places the original copyrights are completely missing. https://board.flatassembler.net/topic.php?p=176398#176398
Не поленился и проверилhttp://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...Вот тут, навскидку, от оригинала осталось буквально 2 строчки кода, а копирайт остался:
http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны
Никогда же в опенсурце форков, драм и обиженок не было, и вот опять.
> Не поленился и проверил
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...;; Copyright (C) KolibriOS team 2004-2022. All rights reserved. ;;
Это к чему? К отсутствию
;; Copyright (C) MenuetOS 2000-2004 Ville Mikael Turjanmaa
? Так это автор и утверждал.
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...
> Вот тут, навскидку, от оригинала осталось буквально 2 строчки кода, а копирайт
> остался:
> http://websvn.kolibrios.org/filedetails.php?repname=Kolibri+...В смысле, два ret осталось? Скажи, ты не умеешь кодить на асме, или полагаешь что на "две строчки" кто-то купится?
>>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны
> Никогда же в опенсурце форков, драм и обиженок не было, и вот
> опять.Вижу, как обиделись на закрытие и хамят автору.
Ты пойми, что в принципе не играет роли, кто в вашем с ним споре прав, а кто лев. Он автор и вправе делать со своим кодом что ему угодно. Булгаков например вообще сжигал рукопись, и кто сейчас помнит его травивших?
>Это к чему? К отсутствиюЭто к тому, что оригинальный заголовок вот:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; ;;
;; VGA.INC ;;
;; 640x480 mode 0x12 VGA functions for MenuetOS ;;
;; Paul Butcher, paul.butcher@asa.co.uk ;;
;; ;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Видишь тут затертые копирайты?>В смысле, два ret осталось? Скажи, ты не умеешь кодить на асме, или полагаешь что на "две строчки" кто-то купится?
http://websvn.kolibrios.org/comp.php?repname=Kolibri+OS&comp...
Какие ret'ы, дядь? Почти все переписано.
>кто в вашем с ним споре прав, а кто лев
Каком "вашем", я к колибри никакого отношения не имею.
>Он автор и вправе делать со своим кодом что ему угодно.
Со своим кодом - не вопрос. Пруфы на украденный код и стертые копирайты где? В репо колибри копирайты не месте.
>[оверквотинг удален]
> ;;
> ;;
>
>
>
>
> ;;
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
Я вижу утверждение автора "в начало подавляющего большинства файлов добавлены копирайты, а в других местах оригинальные копирайты отсутствуют". В опровержение этого приводятся ссылки на какие-то 4 (четыре) файла. Мне понятно, что общее количество файлов существенно больше четырёх, и такая выборка ничего не доказывает, то есть началась подтасовка фактов под удобный противникам автора вывод.
>>В смысле, два ret осталось? Скажи, ты не умеешь кодить на асме, или полагаешь что на "две строчки" кто-то купится?
> http://websvn.kolibrios.org/comp.php?repname=Kolibri+OS&comp...
> Какие ret'ы, дядь? Почти все переписано.
Посмотри сам по своей ссылке. Насчёт ret я не прогадал - три (на 50% больше) ret-а в белых строках. С "осталось буквально 2 строчки кода" ты обманул, белые строки сосчитаешь сам, зачтётся за попытку извиниться.
Что и зачем "переписано" в аннотированном коде - мне в это вникать нет смысла. Умели бы переписывать, переписали бы выдачу IDA из 64-х разрядной версии.
>>кто в вашем с ним споре прав, а кто лев
> Каком "вашем", я к колибри никакого отношения не имею.
Из двух сторон спора ты выбрал Колибри, а не автора. Да и как я тебе, Анониму, поверю, когда ты обманул с количеством строк выше?
>>Он автор и вправе делать со своим кодом что ему угодно.
> Со своим кодом - не вопрос. Пруфы на украденный код и стертые
> копирайты где? В репо колибри копирайты не месте.
Украденный? Заметь, ты сам это слово написал. У меня и намёка на такое не было, я привёл ссылку на заявление автора об _удалённых_ _копирайтах_. Так что ты сам себя определил.
>Я вижу утверждение автора "в начало подавляющего большинства файлов добавлены копирайты, а в других местах оригинальные копирайты отсутствуют".Ясно, чем больше пруфов, тем сильнее верим автору на слово.
>>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны:
>В опровержение этого приводятся ссылки на какие-то 4 (четыре) файла. Мне понятно, что общее количество файлов существенно больше четырёх, и такая выборка ничего не доказывает,Так падажжи, из остальных копирайты вырезаны или не вырезаны? Выборка доказывает, что не вырезаны.
А мне лично понятно, что если бы копирайты стирали специально, то стерли бы везде. Ах да, противник бесконечно коварен (украл исходники) и бесконечно глуп (не везде стер копирайты, исходники лежат в публичном доступе).
>то есть началась подтасовка фактов под удобный противникам автора вывод.
Как-то не подумал что надо бы предоставить факты, поддерживающие твою позицию.
> С "осталось буквально 2 строчки кода" ты обманул
"Навскидку" ты пропустил, да? Порядок чисел верный, без обмана.
>Что и зачем "переписано" в аннотированном коде - мне в это вникать нет смысла.
От исходника осталась одна короткая функция (примерно, для душнил) - "переписывать не умеют". Ясно, экспертная оценка.
>Умели бы переписывать, переписали бы выдачу IDA из 64-х разрядной версии.
Выдуманные мотивы какие-то. А они вообще хотели делать 64х разрядную версию?
>Украденный? Заметь, ты сам это слово написал.
>цап-царапЗаметь, что про цап царап написал не я.
>>>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны:
>>В опровержение этого приводятся ссылки на какие-то 4 (четыре) файла. Мне понятно, что общее количество файлов существенно больше четырёх, и такая выборка ничего не доказывает,
> Так падажжи, из остальных копирайты вырезаны или не вырезаны? Выборка доказывает, что
> не вырезаны.Выборка доказывает лишь одно: ты взял удобный для тебя минимум, тогда как необходимо смотреть все файлы, то есть целенаправленно подтасовываешь факты.
С какой целью ты это делаешь?
Ты пишешь:>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны
"Удобный для меня минимум" это файлы, которые можно идентифицировать как заимствованные - потому, что структура проектов отличается.
Я смотрю несколько файлов, имена которых совпадают с именами из дистра MenuetOS. Копирайты не стерты. Исходное утверждение ложно.
>Выборка доказывает лишь одно: ты взял удобный для тебя минимум, тогда как необходимо смотреть все файлы, то есть целенаправленно подтасовываешь факты.
>С какой целью ты это делаешь?Я не подтасовываю факты, мне интересно разобраться, что произошло в далеких 200х, когда Колибри отделилась. Полноценное расследование, откуда появилась каждая конкретная строчка кода, мне не по силам.
> Ты пишешь:
>>Автор пишет, что один файл - это не показатель, из остальных копирайты вырезаны
> "Удобный для меня минимум" это файлы, которые можно идентифицировать как заимствованные
> - потому, что структура проектов отличается.
> Я смотрю несколько файлов, имена которых совпадают с именами из дистра MenuetOS.
> Копирайты не стерты. Исходное утверждение ложно.Просмотренных файлов недостаточно. Если ты в школе не учился и не знаешь про доказательство по индукции, и чем отличается полная от неполной, то я не собираюсь навёрстывать упущенное.
>>Выборка доказывает лишь одно: ты взял удобный для тебя минимум, тогда как необходимо смотреть все файлы, то есть целенаправленно подтасовываешь факты.
>>С какой целью ты это делаешь?
> Я не подтасовываю факты, мне интересно разобраться, что произошло в далеких 200х,
> когда Колибри отделилась. Полноценное расследование, откуда появилась каждая конкретная
> строчка кода, мне не по силам.Если бы ты хотел разобраться, тогда бы ты воздержался от эмоционально окрашенных слов в адрес одной из сторон ("обиженка") и приписывания автору заявлений, какие он не писал.
>Просмотренных файлов недостаточно. Если ты в школе не учился и не знаешь про доказательство по индукции, и чем отличается полная от неполной, то я не собираюсь навёрстывать упущенное.Да нет, чтобы опровергнуть утверждение "из остальных файлов копирайты вырезаны" достаточно найти хотя бы один файл из которого копирайты не вырезаны.
>тогда бы ты воздержался от эмоционально окрашенных слов в адрес одной из сторонЭто я погорячился, сейчас уже ничего не накопать, кроме того, что конфликт был.
> Цопирайты на месте.Эх, анон-анон, то что сейчас копирайты на месте, не значит что их не выпилили в свое время, а потом вернули. Ты бы почитал историю конфликта, до того как писать про скрепы.
Напр. хотя бы тут на форуме board.flatassembler.net/topic.php?p=215879#215879
"Well, they took the code and in a couple of weeks also added their own copyrights to the beginning of all kernel files, booting, multitasking, GUI, networking, drivers, all. I'm not planning to find out if it would happen again."или тут osnews.com/story/17279/kolibrios-065-released - 2007 год как-никак.
> Главная скрепа - соврать
Да - ты прав. Ты именно это и сделал - соврал))
Ну а Ville закрыл кода именно из-за пи####в из kolibrios.
Причем 64 бита это ламерье так и не осилило.
Интересно, при форке не разобравшись в ГПЛ убрали копирайты из kernel.asm, в 2007 вернули, а автор в 2020 продолжает писать про то, что украли? Найс, 100% не обиженка.>Да - ты прав. Ты именно это и сделал - соврал))
Да, да, все так и было - украли и скрывали, что код был потырен из Menuet. Все по секретным документам.
> Интересно, при форке не разобравшись в ГПЛ убрали копирайты из kernel.asm, в
> 2007 вернули, а автор в 2020 продолжает писать про то, что
> украли?Если не приведёшь ссылку на слова автора вроде "steal" или "thief", значит ты не только самоопределившийся вор, но и занимаешься клеветой.
Забыл что я в суде. Конечно не "украли", а "нарушили авторское право".>ты не только самоопределившийся вор
Прости, а что я украл? Ну так, примерно хочу почувствовать.
> Забыл что я в суде. Конечно не "украли", а "нарушили авторское право".Ожидаемо, что ссылкой подтвердить ты свои слова не можешь.
>>ты не только самоопределившийся вор
> Прости, а что я украл? Ну так, примерно хочу почувствовать.Прощения проси у Вилле, кого ты оклеветал своим "продолжает писать про то, что украли".
Прошу прощения, неточно выразился - не украли, а нарушили авторское право.Так я вор или нет? У меня прощения попросить не хочешь?
> Прошу прощения, неточно выразился - не украли, а нарушили авторское право.Ссылки нет.
> Так я вор или нет? У меня прощения попросить не хочешь?
Ты, именно ты сам написал "украли". Я тебя за язык не тянул.
Ссылка выше:>https://www.osnews.com/story/17279/kolibrios-065-released/
>Kolibri guys have just removed the copyright from Menuet32 kernel.asm, which they have absolutely no right doing.
>Thats the reason Menuet64 is now closed source. Without violations like Kolibri, there would be much more open source software.
>I’ve reported this to FSF.Где "violation", очевидно, "copyright violation". Нарушили авторское право, в просторечии "украли".
>Ты, именно ты сам написал "украли". Я тебя за язык не тянул.
Поэтому я вор? Железная логика.
> Ссылка выше:
>>https://www.osnews.com/story/17279/kolibrios-065-released/
>>Kolibri guys have just removed the copyright from Menuet32 kernel.asm, which they have absolutely no right doing.
>>Thats the reason Menuet64 is now closed source. Without violations like Kolibri, there would be much more open source software.
>>I’ve reported this to FSF.
> Где "violation", очевидно, "copyright violation". Нарушили авторское право, в просторечии
> "украли".Очевидна подмена тезиса (и в данном контексте я бы перевёл "violation" как "ошибка [природы]"). И это уже после замены "украли" на "нарушили авторское право"
>>Ты, именно ты сам написал "украли". Я тебя за язык не тянул.
> Поэтому я вор? Железная логика.Если ты сам назвал свои действия воровством, значит ты сам своей логикой себя определил как вора. С моей помощью ты это понял, тебе это не понравилось, потому и началось вот это вот всё.
>Если ты сам назвал свои действия воровством, значит ты сам своей логикой себя определил как вора. С моей помощью ты это понял, тебе это не понравилось, потому и началось вот это вот всё.Какие действия?
> Интересно, при форке не разобравшись в ГПЛ убрали копирайты из kernel.asm, в 2007 вернулиОй, бедняжечки... GPL настолько сложная, что они не поняли что нельзя чужие копирайты перетирать!
Хотя там черным по белому написано...Не первый раз вижу, что у гнутиков, особенно из этой страны, юридическое образование как у табуретки.
Они могут только орать про шва60дку и то, что им обязаны дать исходники.> Найс, 100% не обиженка.
Почему вдруг обиженка? То что потом вернули, не значит что факт нарушения куда-то пропал.
Просто когда в 2020 автора спрашивает у причине закрытия сорцов, он честно называет причину.> Все по секретным документам.
Да где же они секретные? Достаточно только поискать в инете и всё становится явным))
А да, я и забыл что тут каждый же специалист по всему, и юрист отличный, и программирует как боженька.>Почему вдруг обиженка? То что потом вернули, не значит что факт нарушения куда-то пропал.
Потому что с копирайтами решили в 2007, а претензии остались и в 2020.
Ещё я тебе добавлю, что вообще ситуация у вас позорная.Люди вам про это не пишут, поскольку им жалко своё время тратить, но кто-то должен это сказать.
Восстановить исходники от ОС на асме - это не что-то немыслимое. Долго, но заметно быстрее, чем писать с нуля. Тем более при наличии 32-х разрядной версии, откуда можно брать догадки о наименованиях. И толку было бы куда больше, чем разносить всё это по Сети.
Вилле, похоже, просто пошёл в споре на принцип, и потому не стал открывать исходники. Знал, что спецов у вас нет и затроллил вас таким способом.
Интересно, а современных жутко оптимизирующих ассемблеров нет? Чтоб как для С и С++... а кроссассемблеров, чтобы написал на x64 например и странслировал в RISV-V или MIPS там итп...
flat assembler g не привязан к процессору. Каждая мнемноника является макроопределением. Технически, возможно их переопределить и менять целевую архитектуру. Но код в результате будет далёк от оптимального.
В 2000 году у меня на Пентиум 2 и 256 МБ ОЗУ на Windwos 98 были и игры, и фильмы с музыкой, и интернет, и офис.
Зачем нужен сабж абсолютно не понимаю.
256 — это ещё и довольно жирно к тому же. Обычно и 128 было за глаза (Serious Sam SE на такой конфигурации, правда, с видеокартой поновей, очень бодро проходился).
Ну может перепутал, да на пентиум 2 было 32 потом 64 мб ОЗУ. 256 мб ОЗУ это было уже на п2.
> 256 — это ещё и довольно жирно к тому же. Обычно и
> 128 было за глаза (Serious Sam SE на такой конфигурации, правда,
> с видеокартой поновей, очень бодро проходился).256 было для мажоров. У пацанов были celeron 800, 128 ram и 10GB HDD)
Столько времени люди потратили. А потом лет через 5:
"Алиса, напиши мне код ОС на ассемблере, чтобы там был OnlyOffice, Quake 3 arena,.." и дай инструкцию как это скомпилировать и установить на загрузочную флешку".
- ок, мой господин. Вот код:..."
Если бы ОС на ассемблере были лучше, то они доминировали на рынке. А так это просто затянувшаяся шизофрения.
> Если бы ОС на ассемблере были лучше, то они доминировали на рынке.
> А так это просто затянувшаяся шизофрения.Доминирования программ (в том числе ОС) на ассемблере нет, так как их очень сложно писать, нужно много человекочасов. Если этим будет заниматься ИИ, то все может поменяться.
Я представляю себе поддержку ассемблерных программ, написанных ИИ. То есть нет, не представляю.
Ну и не стоит забывать, что ИИ «программирует» не «из головы», а на основе датасета. А сколько в нём того ассемблера по сравнению с мейнстримными языками?
> Ну и не стоит забывать, что ИИ «программирует» не «из головы», а на основе датасета.ИИ бывает разный. Американцы с помощью маркетинга, ну и соответствующих вливаний денег раскрутили только одну из множества идей. Вероятнее всего другие идеи ждут своего часа. Деньги то когда-то закончатся и нужно будет подливать новые идеи.
Вы хоть в курсе о существовании, ну к примеру таких людей как Мамдании Цурэно?
> Вы хоть в курсе о существовании, ну к примеру таких людей как
> Мамдании Цурэно?Поисковики по фразе "Мамдании Цурэно" выдают только ваш коммент) Наверное, никто не в курсе.
А еще через 10:
- Эй, кожаный мешок № 5378502454, активней крути педали, мне электричества не хватает. А то будешь наказан.
- Да, госпожа Алиса...
А пока у нас хотят убрать из ПДД мигающий зеленый цвет, так как у AI есть сложности связанные с тем, что неясно AI тормозит потому что желтый зажегся или потому что зеленый погас.
Это плохая идея
Нет никакого смысла писать ОС на асме. Для этого есть С++ или на худой конец С. Лишь для некоторых частей ОС нужен ассемблер.
Вы не поверите, но это очень ценные кадры, если нужно будет создавать свой (русский) язык программирования для своих архитектур на новых литографах. А язык программирования и новые архитектуры понадобятся. Прочтите хотябы новости об NVIDIA. Как минимум понадобится процессор с множеством РОН, который сможет имитировать несколько AMD64 и функции видеокарты, но при этом работать согласно реалиям нынешнего времени. Тот же АЛУ должен иметь уже не только простые математические возможности, но неплохо бы и возможности для быстрого вычисления нейрончиков. Для этого нужен будет свой ассемблер, свой язык, своя ОС, программы. И желательно чтоб была совместимость. Но такого нет.
Свой язык точно не нужен. Языков и так уже более чем достаточно. С++ как базовый язык нужен обязательно. Остаётся в компиляторах (GCC, Clang) допилить поддержку инструкций для своего CPU, но если набор инструкций совместим с каким-то популярным набором инструкций (RISC-V, MIPS, ARM) или близок к нему, то в компиляторы нужно будет внести не так уж много изменений.
> Вы не поверите, но это очень ценные кадры, если нужно будет создавать
> свой (русский) язык программирования для своих архитектур на новых литографах.И как тут поможет Вилле, кого местные ценные кадры удивили своей душевной простотой и вынудили закрыть исходники? Сами то кадры почему-то даже отдизасемблировать 64-х разрядную версию не смогли, что ставит под сомнение их способность кодить на асме даже для существующих архитектур.