Опубликовано интервью (http://www.stavimlinux.ru/dists/KolibriOS/interview-with-dev.../) с участниками проекта KolibriOS (http://kolibrios.org/ru/), а рамках которого развивается миниатюрная операционная система, написанная преимущественно на ассемблере (fasm) и распространяемая в рамках лицензии GPL. На вопросы ответили Кирилл Липатов - прикладной программист проекта, и Дмитрий Переверзев - администратор проекта KolibriOS.Загрузочный образ KolibriOS помещается на дискету 1.44 Мб и может работать на системах с 8 Мб ОЗУ. В базовую поставку входит набор драйверов, браузер, текстовый процессор, графический редактор, просмотрщик, более 30 игр. Обеспечена полная поддержка ФС FAT12/16/32 и частичная (только чтение) NTFS, ISO 9660 и Ext2/3/4.
<center><a href="http://kolibrios.org/i/slaid/slaid2.png"><img src="https://www.opennet.ru/opennews/pics_base/0_1360504686.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
URL: http://www.stavimlinux.ru/dists/KolibriOS/interview-with-dev.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=36073
Оу! У этого проекта даже есть администратор?
Эту систему нужно брать как основу для мобилок.
x86-совместимые мобилки? Ты с дубу рухнул?
> x86-совместимые мобилки? Ты с дубу рухнул?Во-первых, такие есть, хотя это и экзотика.
Во-вторых, её можно портировать с х86 на ARM тем же способом, что и OpenVMS перенесли с VAX на Alpha - трактовать ассемблер х86 как высокоуровневый язык и сделать с него компилятор на ARM. И вот такой проект был бы весьма полезен.
Ну-ну, портируйте, особливо если это на асме;))
> трактовать ассемблер х86 как высокоуровневый язык и сделать с него компилятор на ARMточно!
на эт трактовать как Javascript :)
Научите меня так портировать когда на асме
Он же написал, что "за основу" брать, то есть идею нужно перенимать :-)
Если помечтать, то да, такая система на современных мобило-смартфонках экономила бы батарейку и работала бы быстро. Только время разработки не устроит смартфоностроителей, да и для разработки нужно будет программистов нанимать, а не js-разработчиков разносветных кнопочек.
Motorola RAZR i
Lenovo K900, например
Оно на ассемблере
> Оно на ассемблереOpenVMS тоже была на ассемблере, на VAX ассемблере. :-) Перекомпилировали под Alpha.
Правда это не отменяет общего идиотизма переноса Kolibri на телефоны/планшеты.
Вы путаете понятия "портировать" и "переписать".
Нет, он все правильно говорит. Все, что нужно сделать, это написать компилятор, переводящий команды fasm'a, на котором написана KolibriOS, в машинные коды ARM.
Пощупайте KolibriOS. Она не заточена под мобильные. Зачем её портировать-то? Интерфейс придётся (если архитнетура позволяет) переписывать под мобильные, приложений мобильных нет, на ассемблере под такую платформу никогда не выйдет достаточное количество игр и софта для массового пользователя. Вообщем, странная идея какая-то.
> Пощупайте KolibriOS. Она не заточена под мобильные. Зачем её портировать-то? Интерфейс
> придётся (если архитнетура позволяет) переписывать под мобильные, приложений мобильных
> нет, на ассемблере под такую платформу никогда не выйдет достаточное количество
> игр и софта для массового пользователя. Вообщем, странная идея какая-то.Чукча не читатель, чукча писатель? Да, идея с телефонами странная и глупая. Более того, сама KolibriOS - штука странная.
> Чукча не читатель, чукча писатель?Не понял вброс.
> Пощупайте KolibriOS. Она не заточена под мобильные. Зачем её портировать-то? Интерфейс
> придётся (если архитнетура позволяет) переписывать под мобильные, приложений мобильных
> нет, на ассемблере под такую платформу никогда не выйдет достаточное количество
> игр и софта для массового пользователя. Вообщем, странная идея какая-то.Ты хочешь сказать, заточена QNX, или, может, Убунта?!
>> Пощупайте KolibriOS. Она не заточена под мобильные. Зачем её портировать-то? Интерфейс
>> придётся (если архитнетура позволяет) переписывать под мобильные, приложений мобильных
>> нет, на ассемблере под такую платформу никогда не выйдет достаточное количество
>> игр и софта для массового пользователя. Вообщем, странная идея какая-то.
> Ты хочешь сказать, заточена QNX,Внезапно - да.
> или, может, Убунта?!
Убунта похуже. Но уже на порядки лучше, чем Колибри
Нет. Поэтому они нафиг не нужны на мобильных. Требуется вложить уйму денег, чтобы на их базе создать полноценную мобильную платформу и заинтересовать разработчиков ПО и конечного пользователя. Каноникал просто пытается попасть на рынок мобильных устройств. Но до существующих решений им ещё как до Китая пешком.
> Нет, он все правильно говорит. Все, что нужно сделать, это написать компилятор,
> переводящий команды fasm'a, на котором написана KolibriOS, в машинные коды ARM.А обращения к x86 железу и вообще x86-специфичные вещи как "компилировать" собрались? Даже то же программирование GDT/IDT, например?
>> Нет, он все правильно говорит. Все, что нужно сделать, это написать компилятор,
>> переводящий команды fasm'a, на котором написана KolibriOS, в машинные коды ARM.
> А обращения к x86 железу и вообще x86-специфичные вещи как "компилировать" собрались?
> Даже то же программирование GDT/IDT, например?Как и написано выше - трактовать вышеобозначенный x86-ассемблер, как язык высокого уровня, и заменять специфичные для x86 команды блоками команд arm.
> Как и написано выше - трактовать вышеобозначенный x86-ассемблер, как язык высокого уровня, и заменять специфичные для x86 команды блоками команд arm.Хорошая тема для разработки ИИ... Одну и ту же операцию как правило можно сделать 100500 различными способами.
Еще раз: программируем, допустим, PC-speaker. Так, тупо для примера. Можно через PIT. Можно напрямую через порт. Будете весь PIT эмулировать "командами ARM"?
Или DMA. Или memory-mapped area через системные регистры. Или, что самоё зачётное - видеоадаптер :) Современные видеоадаптеры настолько рутинны в программировании, что драйверок под них именно на ассемблере написать, да еще и без использования вендорского API, который не на ассемблере - уже Задача. Не, можно конечно через VideoBIOS видеорежим шифтнуть, и писать в фреймбуфер - но это полное отсутствие акселерации блитов и прочего. Ну и где вы еще на ARM аналог биоса для этого возьмёте?
Утопия, короче. Без ручного портирования не выйдет.
Не согласны? Проэмулируйте мне это на ARM с учетом особенностей x86:
in al,21h
and al,0FEh
out 21h,alПростой блок, казалось бы. А если я его вот так запишу:
in al,21h
mov ah,1
xor ah,0FFh
and al,ah
out 21h,alУсложнять можно до бесконечности. Ваш анализ "блоков" съедет достаточно быстро.
Плохой пример. После правки таблицы векторов прерываний (Рузумеется, а Вы как думали? Новая система - новые прерывания.) все заработает.Разумеется после написания компилятора надо будет немного поработать ручками. Но совсем не много, как тут пытаются доказать некоторые личности.
> Плохой пример. После правки таблицы векторов прерываний (Рузумеется, а Вы как думали?
> Новая система - новые прерывания.) все заработает.Вы даже не поняли примера... чего уж говорить о "совсем не много". В примере - разрешение прерываний от клавиатуры. Причём может быть написано десятком косвенных способов, и хрен ваш "компилятор" определит, о чём речь. Даже ваш интеллект не осилил, а чего ждать от машины?
>> Плохой пример. После правки таблицы векторов прерываний (Рузумеется, а Вы как думали?
>> Новая система - новые прерывания.) все заработает.
> Вы даже не поняли примера... чего уж говорить о "совсем не много".
> В примере - разрешение прерываний от клавиатуры. Причём может быть написано
> десятком косвенных способов, и хрен ваш "компилятор" определит, о чём речь.
> Даже ваш интеллект не осилил, а чего ждать от машины?Ну, машина всё-таки мыслит лучше среднего интернетовского комментатора...
машина никак не мыслит, не обожествляйте ее, она тупо делает то, что в нее вложил другой комментатор, ни больше, ни меньше. Т.е. с ошибками и всякими "неправильностями"
> машина никак не мыслитВерно.
> машина никак не мыслит, не обожествляйте ее, она тупо делает то, что
> в нее вложил другой комментатор, ни больше, ни меньше. Т.е. с
> ошибками и всякими «неправильностями»при этом — что интересно — всё равно оказывается «умнее» многих.
>> Плохой пример. После правки таблицы векторов прерываний (Рузумеется, а Вы как думали?
>> Новая система - новые прерывания.) все заработает.
> Вы даже не поняли примера... чего уж говорить о "совсем не много".
> В примере - разрешение прерываний от клавиатуры. Причём может быть написано
> десятком косвенных способов, и хрен ваш "компилятор" определит, о чём речь.
> Даже ваш интеллект не осилил, а чего ждать от машины?Оппонент, Вы откровенно бредите.
Можете считать это концом нашей дискуссии.
> Оппонент, Вы откровенно бредите.
> Можете считать это концом нашей дискуссии.Ок. Слив заЩитан.
Объясните теперь мне неразумному, какие конкретно нароботки вы хотите включить в мобильную версию при портировании? Драйвера надо будет писать/переписывать под конкретное мобильное железо, интерфейс тоже придётся переделать. Плюс к этому придётся создать некоторую комфортную среду для разработчиков софта и для покупателей софта (SDK, какой-нибудь market, средства установки приложений и тп).
> А обращения к x86 железу и вообще x86-специфичные вещи как "компилировать" собрались?
> Даже то же программирование GDT/IDT, например?Драйвера, ясен пень, надо переписывать:
"Most of the OpenVMS kernel is in VAX assembly language (VAX MACRO-
32). Instead of rewriting the VAX MACRO-32 code in another language,
we developed a compiler. In addition, we required inspection and
manual modification of the VAX MACRO-32 code to deal with certain VAX
architectural dependencies. Parts of the kernel that depended heavily on
the VAX architecture were rewritten, but this was a small percentage of the
total volume of VAX MACRO-32 source code.
"Но методика того, что было сделано при портировании OpenVMS с VAX на Alpha вот - http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pdf
"Compiling VAX MACRO-32 Code for the Alpha AXP Architecture
Simply stated, the VAX MACRO-32 compiler treats VAX MACRO-32 as a source
language to be compiled and creates native OpenVMS AXP object files
just as a FORTRAN compiler might. This task is far more complex than
a simple instruction-by-instruction translation because of fundamental
differences in the architectures, and because source code frequently
contains assumptions about the VAX architecture and the OpenVMS Calling
Standard on VAX systems.[3,4] The compiler must either transparently
convert these VAX dependencies to their OpenVMS AXP counterparts or inform
the user that the source code has to be changed.
"
> Нет, он все правильно говорит. Все, что нужно сделать, это написать компилятор,
> переводящий команды fasm'a, на котором написана KolibriOS, в машинные коды ARM.Позвольте с Вами не согласиться.
То, что он говорит, немножко бред. Возможно даже сивой кобылы.
Объясню почему.
Если посмотреть на VAX и Alpha, то Alpha специально проектировались на смену VAX так, чтобы ПО переносилось с минимальными изменениями (т.е. архитектура, набор регистров и система комманд этому очень сильно способствуют). Это примерно похоже на переносимость программ между i386 и x86_64(в 64-битном режиме) - в большинстве случаев даже программы на ASM достаточно просто модифицировать.
Если же посмотреть на x86 и ARM, то это очень разные по архитектуре, набору регистров и системе комманд процессоры и простой "перекомпиляцией" ASM вряд ли удастся добиться желаемого результата - программу проще будет переписать с нуля, чем написать компилятор для "перегенерации" корректного и, главное, эффективного бинарного ARM-кода на основе бинарного (или ASM, что почти одно и то же) x86-кода. Ведь речи идет именно о таком коде, а не "лишь бы работало"? Если "лишь бы работало", то можно и нативный x86-код в эмуляторе гонять...
>[оверквотинг удален]
> на переносимость программ между i386 и x86_64(в 64-битном режиме) - в
> большинстве случаев даже программы на ASM достаточно просто модифицировать.
> Если же посмотреть на x86 и ARM, то это очень разные по
> архитектуре, набору регистров и системе комманд процессоры и простой "перекомпиляцией"
> ASM вряд ли удастся добиться желаемого результата - программу проще будет
> переписать с нуля, чем написать компилятор для "перегенерации" корректного и, главное,
> эффективного бинарного ARM-кода на основе бинарного (или ASM, что почти одно
> и то же) x86-кода. Ведь речи идет именно о таком коде,
> а не "лишь бы работало"? Если "лишь бы работало", то можно
> и нативный x86-код в эмуляторе гонять...Так он именно такой эмулятор и изобрёл. И если бы это было в практические сроки с практической пользой реально, то современные эмуляторы и работали бы быстро.
> Так он именно такой эмулятор и изобрёл. И если бы это было
> в практические сроки с практической пользой реально, то современные эмуляторы и
> работали бы быстро.При чём тут я, когда это сделали сотрудники фирмы Digital? Современные эмуляторы, например qemu, часть кода перекомпилируют.
>[оверквотинг удален]
> на переносимость программ между i386 и x86_64(в 64-битном режиме) - в
> большинстве случаев даже программы на ASM достаточно просто модифицировать.
> Если же посмотреть на x86 и ARM, то это очень разные по
> архитектуре, набору регистров и системе комманд процессоры и простой "перекомпиляцией"
> ASM вряд ли удастся добиться желаемого результата - программу проще будет
> переписать с нуля, чем написать компилятор для "перегенерации" корректного и, главное,
> эффективного бинарного ARM-кода на основе бинарного (или ASM, что почти одно
> и то же) x86-кода. Ведь речи идет именно о таком коде,
> а не "лишь бы работало"? Если "лишь бы работало", то можно
> и нативный x86-код в эмуляторе гонять...Я, откровенно говоря, не в курсе, что там было с VAX и Alpha, но идея трактовать ассемблер одной архитектуры, как высокоуровневый язык для генерации машинных кодов другой архитектуры - очень хорошая идея, которая в этой ветке треда и рассматривалась.
Разумеется, тема эффективности генерируемого таким образом кода даже не поднималась. Но все-таки, по сравнению с эмулятором, как Вы упомянули, все равно будет быстрее - ибо, как я понимаю, эмулятор ведь параллельно транслирует и выполняет команды, а тут предлагается сразу оттранслировать команды и загружать изначально их, уже на другой платформе.
[...]
> Я, откровенно говоря, не в курсе, что там было с VAX и
> Alpha, но идея трактовать ассемблер одной архитектуры, как высокоуровневый язык для
> генерации машинных кодов другой архитектуры - очень хорошая идея, которая в
> этой ветке треда и рассматривалась.Видите ли в чем фокус, ассемблер по определению является НИЗКОУРОВНЕВЫМ языком, т.е. очень сильно зависит от аппаратной реализации. В принципе, можно ассемблер CISC-архитектуры считать сравнительно высокоуровневым языком для RISC-архиректуры, но это никак не решает проблему эмуляции несоответствий архитектуры - разного количества регистров, разного их назначения, разной системы прерываний, разной модели памяти, разного порядка байт в памяти (мелкий/большой "индеец" ;) ), разного подхода к конструированию комманд (фиксированной/переменной длины).
Вы можете привести в качестве примера реализацию современных архитектур x86_64 - "снаружи CISC, внутри - RISC", но согласитесь, то, что "внутри RISC" - это довольно-таки специфический RISC, который не так-то просто заменить на какой-либо другой.> Разумеется, тема эффективности генерируемого таким образом кода даже не поднималась. Но
> все-таки, по сравнению с эмулятором, как Вы упомянули, все равно будет
> быстрее - ибо, как я понимаю, эмулятор ведь параллельно транслирует и
> выполняет команды, а тут предлагается сразу оттранслировать команды и загружать изначально
> их, уже на другой платформе.Это тоже довольно спорное утверждение. В современных эмуляторах все чаще используется динамическая трансляция, которая позволяет осуществить некоторые "интеллектуальные" оптимизации с учетом данных времени исполнения, что в большинстве случаев дает определенный выигрыш в скорости за счет фоновой трансляции, удаления переходов, вызова процедур и возврата из них, оптимизации по удалению избыточности, распространения копий и констант, «раскрутки» циклов и т.д.
>[оверквотинг удален]
> очень сильно зависит от аппаратной реализации. В принципе, можно ассемблер CISC-архитектуры
> считать сравнительно высокоуровневым языком для RISC-архиректуры, но это никак не решает
> проблему эмуляции несоответствий архитектуры - разного количества регистров, разного
> их назначения, разной системы прерываний, разной модели памяти, разного порядка байт
> в памяти (мелкий/большой "индеец" ;) ), разного подхода к конструированию комманд
> (фиксированной/переменной длины).
> Вы можете привести в качестве примера реализацию современных архитектур x86_64 - "снаружи
> CISC, внутри - RISC", но согласитесь, то, что "внутри RISC" -
> это довольно-таки специфический RISC, который не так-то просто заменить на какой-либо
> другой.Мне все-таки кажется, что написать компилятор ассемблера x86 в arm было бы возможно. Все-таки в arm-процессорах регистров больше, чем в x86. А больше - это не меньше, это упрощает дело. Таблицу векторов надо подправить. Прослойку сделать для трансляции x86 прерываний в arm'овские.
Нда. Как грустно это звучит. Нет, я думаю, что это сделать возможно, если найдутся энтузиасты-бездельники.
>[оверквотинг удален]
>> все-таки, по сравнению с эмулятором, как Вы упомянули, все равно будет
>> быстрее - ибо, как я понимаю, эмулятор ведь параллельно транслирует и
>> выполняет команды, а тут предлагается сразу оттранслировать команды и загружать изначально
>> их, уже на другой платформе.
> Это тоже довольно спорное утверждение. В современных эмуляторах все чаще используется динамическая
> трансляция, которая позволяет осуществить некоторые "интеллектуальные" оптимизации
> с учетом данных времени исполнения, что в большинстве случаев дает определенный
> выигрыш в скорости за счет фоновой трансляции, удаления переходов, вызова процедур
> и возврата из них, оптимизации по удалению избыточности, распространения копий и
> констант, «раскрутки» циклов и т.д.Вот тут я даю маху. В чем не разбираюсь, в том не разбираюсь.
> Если посмотреть на VAX и Alpha, то Alpha специально проектировались на смену
> VAX так, чтобы ПО переносилось с минимальными изменениями (т.е. архитектура, набор
> регистров и система комманд этому очень сильно способствуют).Ну да, ну да. VAX - CISC, Alpha - RISC. :-) Сходство между VAX и Alpha - такое же, как между x86 и Alpha. Кроме того, под Альфу делалась своя ОС - Mica (под project PRISM), кстати, микроядерная.
А вот описание этого чуда - http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pdf
Разумеется, часть вещей не компилировалась, а либо переписывалась, либо интерпретировалась. Драйвера, конечно же, нужны были новые. Но скорость Alpha в десятки раз была выше скорости VAX.
Аналогично, скорость современных ARM в десятки/сотни раз выше скорости Пентиума, под который писалась Kolibri.
Посему, теоретически порт Kolibri на ARM возможен. Но практически никакого смысла нет.
> Вы путаете понятия "портировать" и "переписать".Нет - http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art7.pdf
"Simply stated, the VAX MACRO-32 compiler treats VAX MACRO-32 as a source
language to be compiled and creates native OpenVMS AXP object files
just as a FORTRAN compiler might. This task is far more complex than
a simple instruction-by-instruction translation because of fundamental
differences in the architectures, and because source code frequently
contains assumptions about the VAX architecture and the OpenVMS Calling
Standard on VAX systems.[3,4] The compiler must either transparently
convert these VAX dependencies to their OpenVMS AXP counterparts or inform
the user that the source code has to be changed."Разумеется, это не простое перекомпилирование, но тем не менее.
Прикольно было-бы если они реализовали jawa.
>jawaафигеть. ну а чё, жабистам слабо портировать? ах, да, там же сразу разрыв шаблона произойдёт при взгляде на ассемблерный код.
> там же сразу разрыв шаблона произойдёт при взгляде на ассемблерный код.Почему же? Лично я как раз считаю язык Java чем-то вроде ассемблера для JVM (в то время, как полноценные высокоуровневые языки для JVM в моём понимании - это Scala, Groovy, Clojure и т.п.)
Нее, джава скорее как плюсы. А ассемблер это то, что выдает javap.
>> там же сразу разрыв шаблона произойдёт при взгляде на ассемблерный код.
> Почему же? Лично я как раз считаю язык Java чем-то вроде ассемблера
> для JVM (в то время, как полноценные высокоуровневые языки для JVM
> в моём понимании - это Scala, Groovy, Clojure и т.п.)Жабу считаешь как ACM... м-м-м, приведу аналогию, это как: огромный, обкопчёный, неповоротливый паровоз, сравнивать с маленьким хромированным болтиком;)
Знать бы, кто такие джаwисты.
Ну и какой ты после этого копетан?
Они еще Джwа года ждать будут...
«Функция 18, подфункция 14 - Ожидать начала обратного хода луча развёртки монитора.
Функция 24, подфункция 1 - начать проигрывать CD-audio.
Функция 55, подфункция 55 - Начать проигрывать данные на встроенном спикере.
Функция 47 - вывести число в окно (дальше куча параметров преобразования числа в текст, и это в ядре).»Всего этого мобилкам действительно очень не хватало.
Интересное интервью, спасибо! Ребятам - всяческих успехов.
Интересно, а в чем именно может заключается успех для этой мертворожденной поделки?
минимум, проект можно использовать для изучения основ построения операционок. второе - можно использовать для изучения ассемблера.
Я не говорил что проект абсолютно бесполезен, но желать успеха этому проекту все равно что желать успеха в собирании марок...
почему бы и не желать успеха в интересном увлечении?
> почему бы и не желать успеха в интересном увлечении?Так вопрос был: в чём заключается успех?
понятие "успех" вообще совсем по-разному воспринимается многими людьми. только люди, которые ненавидят свою работу и не имеют никаких творческих увлечений, никогда не поймут этого понятия.
Ненавижу работу
Творчеством года 3 не занимаюсь
Считаю себя успешным, и знаю почему.
ЧЯДН?
воруешь?
> Считаю себя успешным, и знаю почему.А также радиоволной и зелёным пёсиком. Кто ж запретит, считать-то.
А в чем разница между "just for fan" филателистов и осеписателей ?
A причем здесь вентилятор ?
> A причем здесь вентилятор ?При том что носорог фиолетовый
Гмм, раньше до слонов допивались розовых, теперь значит новое поколение выбирает носорогов.
Вместо того чтобы в школе аглицкий учить.
это старое поколение, со старческим маразмом.но вообще-то это старое поколение где-то признавалось, что маразм начался давно, и потому с английским не ладится напрочь. не смотря на прошлые усилия учителей.
Проблема в том что никто там не изменяет(причины меня не интересуют) унаследованое из Menuet структуру ядра. А в существуюей структуре ядра очень сложно делать какие-то изменения или оптимизации.
> Проблема в том что никто там не изменяет(причины меня не интересуют) унаследованое
> из Menuet структуру ядра. А в существуюей структуре ядра очень сложно
> делать какие-то изменения или оптимизации.Откуда такие поспешные выводы? Сравните, пожалуйста, исходные коды последней версии ядра Menuet32 (0.85) и ночной сборки Колибри. Начнем с того, что только в ядре осталось кода от Menuet около 20% (это в транке, в сетевой ветке около 5%). Далее, структура ядра претерпела значительные изменения, теперь вместо кучи больших файлов и одной папки есть куча маленьких файлов и много папок по подсистемам. Каждый кусок кода довольно обособлен, за исключением общеядерных функций и областей памяти.
я не про код, а про структуру ядра
sourcerer wrote:
Далее, структура ядра претерпела значительные изменения, теперь вместо кучи больших файлов и одной папки есть куча маленьких файлов и много папок по подсистемамЭТО вы понимаете под структуруй ядра? свеженький товарищ из института
> sourcerer wrote:
> Далее, структура ядра претерпела значительные изменения, теперь вместо кучи больших файлов
> и одной папки есть куча маленьких файлов и много папок по
> подсистемам
> ЭТО вы понимаете под структуруй ядра? свеженький товарищ из институтаА, вы имеете в виду монолит/микроядро? К черту микроядро.
К чёрту микроядро. К чёрту labels.
Скорость програмного блиттера нельзя повысить в 30 раз из-за курсора (сотни *инструкций* на пиксель сейчас, а должно быть несколько пикселей на одну инструкцию), курсор нельзя исправить из-за gui Mario, gui нельзя исправить потому как никто не желает переписывать прикладные програмы. Ситуация усуглубляется тем что продолжается написание прикладных прог на основе неудачного ядра.
> К чёрту микроядро. К чёрту labels.
> Скорость програмного блиттера нельзя повысить в 30 раз из-за курсора (сотни *инструкций*
> на пиксель сейчас, а должно быть несколько пикселей на одну инструкцию),
> курсор нельзя исправить из-за gui Mario, gui нельзя исправить потому как
> никто не желает переписывать прикладные програмы. Ситуация усуглубляется тем что продолжается
> написание прикладных прог на основе неудачного ядра.Загрузка драйверов ATI/Intel заменяет функцию программного блиттера на аппаратно-ускоренную версию. Это в 0.7.7.0 только курсор ускорялся, уже три года прошло. Курсор уже год как не мерцает, благодаря двойной буфферизации. Производительность VESA-видео в Колибри превосходит производительность VESA-видео в Windows в несколько раз. По поводу "исправить GUI" и "неудачное ядро" - не понял.
> в Колибри превосходит производительность VESA-видео в Windows в несколько раз.
> По поводу "исправить GUI" и "неудачное ядро" - не понял.Шо за зверь. x-серверы на vesa знаю, univbe знаю, а этого не знаю. Кстати, univbe оно превосходит? А то на лептопах и 486 с video paradise (после загрузки dos-драйвера) и p1 с chips&technologies univbe в разных воркрафтах рисовалось со свистом, а от kolibri вообще никакой графики добиться не удалось.
А что, в Windows до сих пор используется VESA-видео? И превосходит ли? Чем меряли? Скоростью отрисовки вашего ущербного интерфейса по сравнению с интерфейсом Windows?
Продолжается? Сами авторы Колибри сами пишут программы, которые им самим потом лень переписывать.
а переход на плоскую модель памяти? а подгружаемые драйверы?
Просто повеселило:Unlevin:
C++ Builder используешь?
Кирилл Липатов:
Вот это сложный момент, и ты будешь в шоке, но я использую уже много лет не разрабатываемый компилятор С-- Сфинкс.
Он генерирует неоптимальный код, но так сложилось исторически. Я редактировал программы на MSVC++ и на GCC, но уже привык к С--, который все уже ненавидят в проекте. Однако, мои программы на нем отлично работают и мало весят.
Каюсь, но так и есть. :)
>Каюсь, но так и есть. :)Честно, не знаю, как редактировать программы с помощью GCC :D
> Честно, не знаю, как редактировать программы с помощью GCC :Dда чего сложного-то? пишем плугин к GCC — благо, это можно, в плугин засовываем vim…
>да чего сложного-то? пишем плугин к GCC — благо, это можно, в плугин засовываем vim…Вот чего только люди не придумают, лишь бы emacs не использовать :)
>>да чего сложного-то? пишем плугин к GCC — благо, это можно, в плугин засовываем vim…
> Вот чего только люди не придумают, лишь бы emacs не использовать :)ок. для хардкорщиков — опционально — edlin.
Может быть пора перейти на llvm-ассемблер? Будет очень переносимо.
Ребята застряли в палеолите.
> Может быть пора перейти на llvm-ассемблер? Будет очень переносимо.ага. особенно сборка колибри под самой колибри доставит. не впряжёшься портировать на колибри llvm?
имхо, достойно уважения, хоть и никому не нужно
Ну ну, а некоторые утверждали когда то, что ос поместится на 1 дискете. ВОТ ОНА!
> Ну ну, а некоторые утверждали когда то, что ос поместится на 1
> дискете. ВОТ ОНА!Вы никогда не пробовали QNX, загружавшуюся вместе с графическим окружением, браузером и поддержкой dial-up-доступа в Интернет (при наличии полноценного комовского модема) с одной дискетки?
4.25
жирную 6-ки вряд ли возможно запихнуть
>> Ну ну, а некоторые утверждали когда то, что ос поместится на 1
>> дискете. ВОТ ОНА!
> Вы никогда не пробовали QNX, загружавшуюся вместе с графическим окружением, браузером и
> поддержкой dial-up-доступа в Интернет (при наличии полноценного комовского модема) с одной
> дискетки?А здесь на ту же дискету еще и три десятка ethernet-карточек, и pppoe, и на закуску mp3 и mp4. В скором времени даже онлайн. И жесткое реальное время. Выкуси, QNX.
Только вот браузера в ней фактически нет. Имеющееся не многим лучшим телнета, в то время как в qnx 99 года выпуска был сносный браузер, с поддержкой js.Я конечно понимаю что это сложно реализовать, но это уже проблема дизайна системы. А в нынешнем виде колибри продолжает оставаться только лишь занятной игрушкой.
_____«Многие сис. функции ядра позволяют прикладным программам писать в память ядра (т.е. в диапазоне 0x80000000-0xFFFFFFFF), тем сам можно "прибить систему" или выполнить пользовательский код с максимальным уровнем привелегий (в 0-вом кольце)»
Ну а после такого, сравнение с qnx выглядит совсем неуместно.
> Только вот браузера в ней фактически нет. Имеющееся не многим лучшим телнета,
> в то время как в qnx 99 года выпуска был сносный
> браузер, с поддержкой js.А нормальная поддержка сети, кроме модемного соединения, там была? А локали? А КОСИЛКА? В kolibri, когда там была гробница фараона, можно было вообще жить. и единственный рабочий эмулятор dendi fceu, которым можно было нормально управлять, причём нормально управлять СРАЗУ, я видел только в kolibri (ни в одном linux я никогда не видел fceu, которым можно было бы пользоваться).
джентельменский набор "гробница фараона", "doom", "dosbox" и "fceu" позволяет на этой ос переиграть в тысячу интересных игрушек. вот. :)
> А нормальная поддержка сети, кроме модемного соединения, там была?Для того времени - да была:
« http://toastytech.com/guis/qnxdemo.html
NE1000/2000, DEC 21x4x, or 3com 509 based network card »> doom", "dosbox" и "fceu"
Хех, это и дос может. И кстати колибри чем-то его и напоминает, этакий дос с окошками. С прямым доступом к железу и невнятной изоляцией программ.
Ну и то, что у ядра первая функция - рисование окошек, тоже забавно.
>> doom", "dosbox" и "fceu"
> Хех, это и дос может.Может, но не хочет. И десктопа там никакого нет.
DOS Shell, Windows 2.x/3.0 - не? Официальные десктопные надстройки над MS-DOS. От того же производителя, кстати, прошу заметить.
вот таким должен быть современный софт и ОС. уважаю ассемлеристов, это настоящие пацаны-программисты
Непереосимым? Не модульным? Со сплабой поддержкой сети? Почему вы думаете. что современный софт должен быть таким? Кому он должен?
На дискету помещается... Это преимущестрво?
> Непереосимым? Не модульным? Со сплабой поддержкой сети? Почему вы думаете. что современный софт должен быть таким? Кому он должен?Потому что 90% пользователей ПК, которые, как известно, используют оффтопик, довольствуются именно таким софтом — то бишь оффтопиком.
> На дискету помещается... Это преимущестрво?
По сравнению с оффтопиком — да.
>> Непереосимым? Не модульным? Со сплабой поддержкой сети? Почему вы думаете. что современный софт должен быть таким? Кому он должен?
> Потому что 90% пользователей ПК, которые, как известно, используют оффтопик, довольствуются
> именно таким софтом — то бишь оффтопиком.
>> На дискету помещается... Это преимущестрво?
> По сравнению с оффтопиком — да.Причем тут вообще Windows? Вы без него не можете? Я спросил у черлорвека, почему он думает, что "вот таким должен быть современный софт", а вы тут сразу со своим срверхценным "венда гавно"... Я не об этом спрашвал.
потому что программы на ассемблере могут творить чудеса по скорости и размеру, достаточно вспомнить потрясающие игры на спектруме размером в 30-50Кб. или посмотреть на современные ассембли демки. а еще ассемблер может больше, чем языки высокого уровня
> потому что программы на ассемблере могут творить чудеса по скорости и размеру,
> достаточно вспомнить потрясающие игры на спектруме размером в 30-50Кб.Опуская тот факт, что эти потрясающие игры - это совсем не сорвременный софт, и то что сегодня нет особой разницы между 50 Kb и 50 Mb, все же немогу не заметить - при разработпке на asm вы выигрываете в физичиспком размере программы. А этот ресурс (память )сейчас очень, очень дешев. Но сильно проигрываете во времени разработки. А вот этот ресурс, наоборот очень дорог. Вопрос - зачем так делать?
> а еще ассемблер может больше, чем языки высокого уровня
Строго говоря это не сорвсем так. Совок не может делать работу экскаватора. ну то есть, теоретически совком можно впкопать котлаван под фундамент небоскреба. Но кому он будет нужен? все уже на альфа центавра улетят.
Я так подозреваю должно быть так:
Современный софт должен быть быстрый и компактный.А идиотов считающих, что памяти у всех много и процессоры минимум двухядерные, нужно высмеивать при людно.
> А идиотов считающих, что памяти у всех много и процессоры минимум двухядерные,
> нужно высмеивать при людно.А уж что надо ПРИЛЮДНО делать с незнающими русского языка.
> Современный софт должен быть быстрый и компактный.Для этого не нужен именно ассемблер.
А ещё современный софт должен быть легко портируемый и переносимый, а не прибитый к одной платформе ассемблерными гвоздями.
Установщик openbsd тоже вмещается на дискету. И ядро там поддерживает где-то в 100 раз больше устройств.
> Современный софт должен быть быстрый и компактный.во-первых, это не всегда совпадает.
во-вторых — удачной ручной оптимизации под современную технику, чо. под x86, например: ты уверен, что сможешь это сделать лучше хорошего компилятора C?
я, кстати, знаю людей, которые сейчас пишут на асме. не вставки, а именно софт. во-первых, у них в итоге в коде система макросов, напоминающая такой себе «недоси». а во-вторых, их код если уж не работает, то смачно и качественно не работает, и отлаживается ой, как долго. при этом читаемость кода на асме затруднена ненужными деталями (на си тоже, конечно, но далеко не в такой мере), потому чтобы помочь нарыть ошибку, надо долго медитировать.
p.s. а потом удачного переноса ассемблерного софта на другую архитектуру, кстати. тоже спецолимпиада.
Речь шла не о том, что все надо писать на асме. А то что современный софт должен быть "быстрый и компактный".
Или вам не попадались джава-калькуляторы тормозящие даже в режиме ожидания?
> Или вам не попадались джава-калькуляторы тормозящие даже в режиме ожидания?к счастью, не попадались. и вряд ли попадутся. а bc не тормозит.
> Опуская тот факт, что эти потрясающие игры - это совсем не сорвременный софтНу и что? А человечество — совсем не современный вид: как появились несколько десятков тысяч лет назад, так с тех пор и просуществовали без особых изменений. И ничего, живём как-то, бороздим на космических кораблях просторы Большого Театра, ассемблерные демки пишем.
> и то что сегодня нет особой разницы между 50 Kb и 50 Mb
Есть. 50 Кб поместится в ПЗУ современного ПК, 50 Мб — нет. Файл размером 50 Мб будет качаться с моим интернетом не меньше пяти минут, размером 50 Кб — меньше секунды. 50 Кб ты втиснешь в микроконтроллер (хотя программе даже такого размера на многих микроконтроллерах будет тесно), 50 Мб — никогда. В обратную сторону это тоже работает: для, скажем, «Муму» хватит и 50 Кб, а вот для десятка романов типа «Войны и мира» и 50 Мб может быть мало. Так что память — это всё еще ценный ресурс. Нечего им разбрасываться.
> при разработпке на asm вы выигрываете в физичиспком размере программы. А этот ресурс (память )сейчас очень, очень дешев
Выигрываем. См. выше. Не смотря на то, что оперативная память дёшева, у неё есть очевидные недостатки (например, медлительность), делающие недопустимым использование такой памяти в, скажем, микроконтроллерах и ПЗУ.
>> Опуская тот факт, что эти потрясающие игры - это совсем не сорвременный софт
> Ну и что? А человечество — совсем не современный вид: как появились
> несколько десятков тысяч лет назад,В школу,скорее.
>> и то что сегодня нет особой разницы между 50 Kb и 50 Mb
> Есть. 50 Кб поместится в ПЗУ современного ПК, 50 Мб — нет.
> втиснешь в микроконтроллер (хотя программе даже такого размера на многих микроконтроллерахКто тут говорит о микроконтроллерах? речь об Ос и прикладном софте.
> Файл размером 50 Мб будет качаться с моим интернетом не меньше
> пяти минут, размером 50 Кб — меньше секунды. 50 Кб тыМеняй провайдера.
> В школу,скорее.Что не так? Человек появился на земле где-то 35—70 тысяч лет на зад, в эпоху позднего палеолита. Или ты сверяешься с библией и считаешь, что вселенной всего пять тысяч лет? Вынужден разочаровать, но религиозные тексты до сих пор не включили в школьную программу в качестве учебников истории и биологии.
> Кто тут говорит о микроконтроллерах? речь об Ос и прикладном софте.Во-первых, ОС для микроконтроллеров никто не отменял (например, FreeRTOS). Во-вторых, написание ОС и прикладного софта для неё — не такой уж и плохой повод для получения навыков программирования на ассемблере. В-третьих, ты забыл про ПЗУ что-нибудь эдакое сказать.
> Меняй провайдера.Зачем? Меня вполне устраивает текущая скорость. Я же не использую результаты труда быдлокодеров, у которых простейший калькулятор распухает до гигабайта.
> 35—70 тысяч лет на задИ это при том, что язык с литературой в школе вроде бы как проходят :(
Сопоставьте на досуге временнЫе интервалы:
- становления и применения радиоуглеродного метода "определения" возраста;
- летописной и вообще хоть как-то документально зафиксированной истории;
- те, о которых отдельные особи не стесняются писать в учебниках.Они соотносятся примерно как 1:20:500.
> И это при том, что язык с литературой в школе вроде бы как проходят :(Никакие языки и литературы не страхуют от опечаток.
> становления и применения радиоуглеродного метода "определения" возраста;Тебя тоже "смущает" метод определения возраста по изотопам углерода?
>> становления и применения радиоуглеродного метода "определения" возраста;
> Тебя тоже "смущает" метод определения возраста по изотопам углерода?Некоторые и по двум комментариям на опеннете возраст вон определяют. И никого это не смущает.
> — летописной и вообще хоть как-то документально зафиксированной истории;офигенный аргумент. так и вижу, как через много-много-много лет другой Миша будет говорить: «ну где, где документальные свидетельства? вот пару тыщ лет назад — да, всё было, вот носители на основе технологии ABCD, на них всё записано. а от более раннего периода носителей нет — какие там вообще люди могли быть?!»
> 50 Кб поместится в ПЗУ современного ПК, 50 Мб — нет.Уточните пожалуйста, какое именно ПЗУ имеется в виду...
памяти больше, процики быстрее, да вот почему то современные компы на win7 работают не быстрее, чем pentium 166 на windows 98. тоже касается и офисных программ. у меня кстати виндус 98 на пентиум 133 летала быстрей, чем виндус 7 на 4 ядерном процике!
Да что ж вы всё своим вантузом меряете? Неужели все ассемблерщики к вантузу прилипли?У мене лично KDE4 именно что летает. Core i7-3770k/16Gb
PS: И да, как программировавший БЗ-34/МК-52, считаю что астматики не знают что такое рационально использовать ресурсы. 98/104 шагов, 14/15 общих регистров и 4 стековых - это посложнее будет чем ваша фаллометрия.
> У мене лично KDE4 именно что летает. Core i7-3770k/16GbУдивительно, да...
Core i7-3770k/16Gb для KDE, это тоже самое, что реактивный двигатель для легкового автомобиля
>Причем тут вообще Windows?При том, что у разработчиков и фанатов - "папки". Ясное дело, что они вендузоиды.
> При том, что у разработчиков и фанатов - "папки""Папка" - куда более удачное название для коллекции "файлов", чем "директория" тащемта например
>> При том, что у разработчиков и фанатов - "папки"
> "Папка" - куда более удачное название для коллекции "файлов", чем "директория" тащемта
> напримерОпять Вам мерзкософт мозги перепромыл. Если я правильно помню, то в "папках" положено хранить "документы", а в "каталогах" (а не "директориях") положено хранить "файлы". Если Вы не понимаете чем "документ" отличается от "файла", то я тут ничем помочь не могу.
Юноша, ненависть к флагману рынка выела вам остатки разума.В каталоге нет никаких файлов, и никогда не было.
файлы с документами сшиваются в картонные или пластиковые папки, а общие сведения о документе записаны на маленькой бумажечке, которая и хранится в ящичке каталога.
> Юноша, ненависть к флагману рынка выела вам остатки разума.Это не флагман, это дырявая галера, которая тащится на плечах миллионов юзеров. Которые не устают при этом делать вид, что это не на них плывут.
> В каталоге нет никаких файлов, и никогда не было.
> файлы с документами сшиваются в картонные или пластиковые папки, а общие сведения
> о документе записаны на маленькой бумажечке, которая и хранится в ящичке
> каталога.Папка - место хранения ФАЙЛОВ. Каталог - место хранения УКАЗАТЕЛЕЙ НА ФАЙЛЫ. Вывод: с точки зрения банальной логики, название "папка" для дисковой структуры с указателями - исключительно идиотам посвящается.
Все нормальные люди работают с объектами, а не указателями.
Файл может не храниться на диске вообще (сетевые папки, виртуальные папки, медиа библиотеки)
> Все нормальные люди работают с объектами, а не указателями.прямо так с объектами. каждый раз весело их копируя, видимо, потому что про ссылки не знают.
>> При том, что у разработчиков и фанатов - "папки"
> "Папка" - куда более удачное название для коллекции "файлов", чем "директория" тащемта
> например"Папка" - это виндузчее название для каталога.
> На дискету помещается... Это преимущестрво?Ну, строго говоря, это недостаток. Где ж её, дискету, взять по нынешним непростым временам. Хотя, нет, вру, у меня в чулане есть ещё несколько коробок, и 3.5", и 5". И 8", если поднапрячься, найти можно. Вот только, куда их вставлять...
> вот таким должен быть современный софт и ОСдля микроконтроллеров
> уважаю ассемлеристов, это настоящие пацаны-программисты
вы ананисты ребята плечисты :)
>> вот таким должен быть современный софт и ОС
> для микроконтроллеров
>> уважаю ассемлеристов, это настоящие пацаны-программисты
> вы ананисты ребята плечисты :)Микроконтроллеры мрачно охренеют с десктопа и "более 30 игр"
> Микроконтроллеры мрачно охренеют с десктопа и «более 30 игр»да нормалёк.
«извините, в работе процесса управления реактором произошёл сбой. не пытайтесь убежать, это бессмысленно. но зато у вас ещё есть время два раза разложить косынку!»
Хорошо соптимизированный С код не уступает ассемблеру. Зря они фигней страдают.
как полезный опыт, наверное хорошо, но где можно это практически применять?
да, лучше бы GCC дооптимизировали...
> Хорошо соптимизированный С код не уступает ассемблеру. Зря они фигней страдают.Хорошо оптимизированный ассемблер делает оптимизированный Си.
ну давайте писать сразу на машинном языке! а че.
мисье забыл ситуации когда при переходе с i386 на 486 и 586 надо было начинать оптимизацию с 0?
при том что код написаный под i386 на 586 работал сильно медленее?
>> Хорошо соптимизированный С код не уступает ассемблеру. Зря они фигней страдают.
> Хорошо оптимизированный ассемблер делает оптимизированный Си.По объёму или производительности? Про объём не помню, а вот по производительности любители потягаться с компилятором в оптимизации уже довольно давно признали поражение. Ну не укладывается вся железка (или хотя бы состояние всех регистров) в голову.
> Про объём не помню, а вот по
> производительности любители потягаться с компилятором в оптимизации уже довольно давно
> признали поражение. Ну не укладывается вся железка (или хотя бы
> состояние всех регистров) в голову.Миш, есть всякие сильноузкоспециализированные приложения. Дружок из Софтлаба, программирующий странную графику на не менее странных устройствах, хвалился как-то, что после того, как он проходит глазами нагенерённый код, тот начинает работать в _разы_ быстрее. Но это нет, не ассемблер общего назначения.
Начинает работать быстрее только от одного взгляда. От страха, что ли?
> Дружок из Софтлаба, программирующий
> странную графику на не менее странных устройствах, хвалился как-то, что после
> того, как он проходит глазами нагенерённый код, тот начинает работать в
> _разы_ быстрее. Но это нет, не ассемблер общего назначения.Просто "проходит глазами", ничего не изменяя? И после этого "тот начинает работать в
> _разы_ быстрее"?!! Мистика и ненаучная фантастика!
>> Хорошо соптимизированный С код не уступает ассемблеру. Зря они фигней страдают.
> Хорошо оптимизированный ассемблер делает оптимизированный Си.при этом компилятор си таки переводит и оптимизирует тысячи и более строк менее, чем за секунду, а бедный ассемблерщик как минимум пол-дня полирует функцию, которая на си заняла бы строк 15-12.
алё, там, в бункере! Z80 на «десктопную» технику уже не ставят. даже iAPX386 и iAPX486 уже не ставят. даже первые пентиумы. заканчивайте уже вылизывать пузырьковую сортировку, выходите на свет: узнаете много нового и поразитесь, как изменился мир.
p.s. ничего не имею против написания на асме: нормальное развлечение, ничем не хуже других. но не надо при этом чуши утверждать, ок?
>Какое окружение используешь?
>Кирилл Липатов: Windows, но в проекте используют и GNU/Linux. Это не очень важно.На этом можно ответе можно сразу данную поделку закапывать. Если после стольких лет разработчики декстопной ОС все еще не могут ее использовать как основную, значит ничего хорошего из этой недоОСи уже не выйдет.
Да её, в общем, никто и не выкапывал. Она just for fun - для энтузиастов. На чём-то учиться надо - и это - не худший вариант. Жаль, что в силу ситуации в экономике совершенно нет времени - workin' workin' workin' as Doogs. Если бы время было - записался бы в проект, поскольку старый ассемблерщик.
Кто сказал ,что не могут? Я в ней фильмы смотрю, музыку слушаю, статьи пишу.
учитывая, что БИОС современных ПК 4-8Мб, то KolibriOS можно спокойно вшить в БИОС и продавать такие ПК, как Спектрумы. В БИОСе выставить опцию загрузка KolibriOS или другая ОС, как обычно. нужно только ее дошлифовать малость
> учитывая, что БИОС современных ПК 4-8Мб, то KolibriOS можно спокойно вшить в
> БИОС и продавать такие ПК, как Спектрумы.И кто это будет покупать ?
> И кто это будет покупать ?те же, кто покупает Rapsberry Pi
и приблизительно для тех же целей
как кто будет покупать? кто угодно, не только те шо Rapsberry Pi. покупаешь такую материнку, не хочешь запускать KolibriOS, пожалуйста устанавливай обычную для себя Виндус 7 или Линукс. никаких ограничений
http://enjoy.51t.ru/ :)111 мб
лучше тогда уж это вшивать в материнку, если уж совсем делать нечего.
>> учитывая, что БИОС современных ПК 4-8Мб, то KolibriOS можно спокойно вшить в
>> БИОС и продавать такие ПК, как Спектрумы.
> И кто это будет покупать ?"Ты не поверишь...."
В SunFire выпуска 2008 года в БИОС (в x64 машинах) был вшит - тадаааааа! - линукс с убожщной узкоспециализированно-биосно-ориентированной оболочкой! :))))))
И - да, эти машинки покупали - еще как! И рвали они нынешние четырехядерники, потребляя не более 240 ватт на 1 RU....
смотрел я эту KolibriOS на нетбуке MSI Wind U100.. шустро работала..
люто бешено плюсую.
вот вам пример написания осей а не тот блоатварь с гигабайтами свистоперделок который счас осями называют.
Вы это из под KolibriOS написали ?
лучший комент
> люто бешено плюсую.
> вот вам пример написания осей а не тот блоатварь с гигабайтами свистоперделок который счас осями называют.Не осями, а windows.
Ради эксперимента взял openbsd, сделал виртуальный диск на 500 мб, подключил это в qemu с 32 mb памяти, взял образ дискетки freedos, загрузился, отрезал 60 мб под fat, скопировал туда базу freebsd, загузился с дискеты openbsd, установил систему на оставшееся место, используя источником файлы с fat, без обращений к сети: всё установилось и заработало.
> отрезал 60 мб под fat, скопировал туда базу freebsd, загузился ссложно делать пять дел одновременно, делая отложенную запись на форум. скопировал туда базу openbsd.
> люто бешено плюсую.
> вот вам пример написания осей а не тот блоатварь с гигабайтами свистоперделок
> который счас осями называют.если хоть один из «люто, бешено плюсующих» и глаголящих про «вот как надо писать» хоть маленькую софтину под колибри написал, хоть патчик к ядру, добавляющий что-то — я закажу шляпу и сожру её.
Проект заглох как только автору (Ville Turjanmmaa) надоели дармоеды и он начал новый проект не под GPL (есть его весьма эмоциональное письмо на эту тему). За 5 лет он closed-source продвинулся куда дальше, чем эти open-source клоуны.
> Проект заглох как только автору (Ville Turjanmmaa) надоели дармоеды и он начал
> новый проект не под GPL (есть его весьма эмоциональное письмо на
> эту тему). За 5 лет он closed-source продвинулся куда дальше, чем
> эти open-source клоуны.Спасибо, посмеялся.
Да не за что. Для этого и существуют клоуны!http://www.menuetos.net/download.htm
http://kolibrios.org/ru/download.htmСравни и посмейся ещё раз. Из актуального в Колибри только автоматические ночные сборки.
Предлагаете поразбираться в сортах зомби ?
> Предлагаете поразбираться в сортах зомби ?Перефразируя Кураева - "Distrowatch - в сортах гогна не разбираюсь!" (С)
> Да не за что. Для этого и существуют клоуны!Нет главклоуна кроме Балмера и вантузятники подклоуны его, ггг
тю. менуэт64 даже другу скопировать нельзя, не то, что исходники глянуть. зачем оно такое?
Интересно, их не смущает, что дискеты уже не производят?
> Интересно, их не смущает, что дискеты уже не производят?А вас не смущает, что образ дискеты можно использовать для создания загрузочных CD, а еще легко грузить через GRUB/SYSLINUX? Существуют, конечно, универсальные образы CD/USB stick, но они далеко не везде хорошо работают.
> А вас не смущает, что образ дискеты можно использовать для создания загрузочных
> CD, а еще легко грузить через GRUB/SYSLINUX? Существуют, конечно, универсальные образы
> CD/USB stick, но они далеко не везде хорошо работают.Ядро linux с initrd тоже легко грузить с загрузочных cd, через grub/syslinux, через ipxe и ещё 400 сравнительно честными способами включая qemu -kernel kernel -initrd initrd. Я вон выше даже целую операционную систему ради смеха на таком принципе собрал, и весит она, как несложно посчитать, несколько больше 1.44 мб. Другие аргументы ждём.
>> Интересно, их не смущает, что дискеты уже не производят?
> А вас не смущает, что образ дискеты можно использовать для создания загрузочныхУ меня линь год грузился с дискеты (ядро), потому как матплата не распознавала винт, а апдейты к ней не выпускались к тому времени пару лет, а ограничивать винт аппаратно до 32гб не хотелось. И чего?
Уж пользительнее было.
http://vk.com/id80351627?z=photo80351627_297047905%2Fal...
Есть ли у этой ОС практическое применение? Просто любопытно...
> Есть ли у этой ОС практическое применение? Просто любопытно...Когда в поставке была "Гробница фараона", это была лучшая геймерская ось. :)
Нет.На этих сайтах собираются энтузиасты, разрабатывающие собственные ОС:
osdev.ru
osdev.orgА здесь список всех проектов (Колибри среди них тоже есть):
http://wiki.osdev.org/ProjectsЭто хобби. Цель - убить время, копаясь в интересующем вопросе.
1
3d-движок симпатичный.Можно в качестве пушера сделать roaf (rpg on a floppy), с простым управлением а-ля powder. Чтобы показать, чем это отличается от игр dos 90-х, можно оставить десктоп, и с помощью нехитрого тайлового менеджера сделать возможность мультиплеера на одной клавиатуре 2,3,4 игроков.
8 мегабайт О_О? вынь 95 на 4-х работала
> 8 мегабайт О_О? вынь 95 на 4-х работалаКолибри нужен пентиум (486/386 will not work), а их с 8 мегабайтами наверное уже и не было.
> 8 мегабайт О_О? вынь 95 на 4-х работалакое-как запускалась. работой это назвать было сложно.
> 8 мегабайт О_О? вынь 95 на 4-х работалаВиндоус 95 на 4Мб тормозила разве-что. Нормально работала на 8, это да. Комфортно - на 16.
>> 8 мегабайт О_О? вынь 95 на 4-х работала
> Виндоус 95 на 4Мб тормозила разве-что.
> Нормально работала на 8, это да.Нет
> Комфортно - на 16.
Нет
95 OSR2 на 4Мб уже даже не инсталлировалась
>> Комфортно - на 16.
> НетОй, да ладно. Мы спокойно работали под Win98SE на 80486DX4/16Mb, еще и с DriveSpace.
> 95 OSR2 на 4Мб уже даже не инсталлировалась
Просто 95 - инсталлировалась. OSR - угу, не лезла.
А на 64 метра уже втуливали 2000/XP потом :) Хотя для комфорта в XP надо было 128-256. Очень много было студенческих машин в классах с 32Mb/W2K... Кошмар, но работало хоть как-то - NT4 к сожалению был "не торт".
да ну, NT4 на 32 метрах был вполне торт, помнится. и второквак на матраце в софтваре гонял весьма неплохо.
> да ну, NT4 на 32 метрах был вполне торт, помнится. и второквак
> на матраце в софтваре гонял весьма неплохо.Он конкретно у нас был не торт, потому что DC был на W2KS.
из рамдиска? :)
> 8 мегабайт О_О? вынь 95 на 4-х работалаи не работала, а загружала оболочку для свопа. и 20 мб свопа ей вынь, да положь
и на 4 она никогда толком не работала
а без рамдиска и у kolibri будут пониже требования
