LINUX.ORG.RU

Вышел KolibriN 8.1

 , ,


4

4

Многие уже слышали про Колибри — операционную систему написанную на ассемблере и умещающуюся на одну дискету. И это с целой кучей софта в комплекте! Завораживает? Возможно, но наши дети уже не знают зачем эти черные квадратики, да и Колибри давно уже выросла из дискеты размером 1.44 Мб — это и послужило причиной появления KolibriN Upgrade Pack, который призван собрать воедино все разбросанные по свету программы и наработки для KolibriOS.

Что сделано:

  • добавлены тени и полупрозрачность;
  • красивые обои и скины, которые можно легко менять через контекстное меню рабочего стола;
  • в поставку входят игры, среди которых Doom, Loderunner, Pig, Jumpbump и эмуляторы игровых консолей NES, SNES, Gameboy;
  • эмуляторы DosBox и ZX Spectrum позволят запустить сотни старых приложений и игр;
  • просмотрщик изображений zSea, графический редактор GrafX2, почтовый агент Liza, просмотрщик документов формата PDF, видеоплеер FPlay и многие другие программы.

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

>>> Скриншоты на официальном сайте

>>> Ссылка на закачку

>>> Подробности



Проверено: post-factum ()
Последнее исправление: Klymedy (всего исправлений: 8)

Ответ на: комментарий от namezys

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

anonymous
()
Ответ на: комментарий от Badboy

у меня создалось впечатление, что Lennart всё же искал не лицензию, а воров, преступников и негодяев.

А что, они тоже упомянуты на вики, но отсутствуют на сайте?

Lennart
()
Ответ на: комментарий от anonymous

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

Ну хоть ты тут в теме! А то эта школота, у которой взрывается мозг уже от xor ax,ax изрядно надоела :)

acukac
()
Ответ на: комментарий от namezys

Бред. Задача микрооптимизации это не задачу творческого подхода. Это просто задача поиска минимума, при достаточно хорошо известной метрике.

Мне грустно такое читать :)

acukac
()
Ответ на: комментарий от dmfd

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

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

Чем-то напоминает сжатие ZIP в зависимости от размера словаря.

acukac
()
Ответ на: комментарий от dmfd

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

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

Чем-то напоминает сжатие ZIP в зависимости от размера словаря.

acukac
()
Ответ на: комментарий от dmfd

Проблески разума появились. Уверяю, в достаточно сложной программе, состоящей более чем из одного алгоритма, эта схема до пункта 5 никогда не доходит.

Пункт 5 делают те, кто это умеют. У других до этого не доходит, согласен :)

Ну и да, архитектур больше одной, вам нужно реализовать пункт 6 под все, причём одинаково хорошо.

У компилятора та же проблема и у него нет возможности провести бенчмарк в отличии от человека :)

acukac
()
Ответ на: комментарий от dmfd

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

Ну даже, например, передача параметров в процедуру через регистры, а не через стек! Это 6 тактов минимум, вместо одного :)

acukac
()
Ответ на: комментарий от anonymous

Да, а что же по вашему делает компилятор?

Переводит с одного языка на другой

namezys ★★★★
()
Ответ на: комментарий от acukac

Ну даже, например, передача параметров в процедуру через регистры, а не через стек!

Ладно бы вы про SIMD начали рассказывать. Но это-то компиляторы умеют уже сто лет. man register, man inline

У компилятора та же проблема

Нет у него этой проблемы. man compiler frontend/backend

у него нет возможности провести бенчмарк в отличии от человека

И при чём здесь ассемблер? Time profiling я могу и для скомпилированного кода провести.

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

Конкретных примеров так и нет? Я знал, с кем имею дело.

Пункт 5 делают те, кто это умеют.

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

dmfd
()
Ответ на: комментарий от Lennart

Воры и негодяи

у меня создалось впечатление, что Lennart всё же искал не лицензию, а воров, преступников и негодяев.

А что, они тоже упомянуты на вики, но отсутствуют на сайте?

Ну, на официальной Вики ЛОРа они есть: http://lurkmore.to/MenuetOS

yogev_ezra
()
Ответ на: комментарий от dmfd

Ну даже, например, передача параметров в процедуру через регистры, а не через стек!

Ладно бы вы про SIMD начали рассказывать. Но это-то компиляторы умеют уже сто лет. man register, man inline

И они до сих пор делают это хреново! И сам программист не имеет возможности отследить использование отдельных регистров! А значит и не знает какой из них можно использовать. А пушить перед этим в стек другие переменные - тоже тупо!

acukac
()
Ответ на: комментарий от acukac

inline то зачем придумали? А вы всегда знаете, что данный вызов не воспользуется другими регистрами? где гарантия?

А вот компилятору можно было бы объяснить, чтоб он это проверял

namezys ★★★★
()
Ответ на: комментарий от SZT

Не, ну если им так хочется, то calling conversion и нарушить можно, только обучить этому компилятор надо.... Но тут есть больша ясложность

namezys ★★★★
()
Ответ на: комментарий от namezys

inline то зачем придумали? А вы всегда знаете, что данный вызов не воспользуется другими регистрами? где гарантия?

А вот компилятору можно было бы объяснить, чтоб он это проверял

А где гарантия, что вы напишите программу ХеллоуВорлд, которая будет работать? Вот тут примерно такая же гарантия :)))

acukac
()
Ответ на: комментарий от acukac

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

Но при вашем желании можно было научить компилятор делать то, что вам надо. И это было бы эффективней

namezys ★★★★
()
Ответ на: комментарий от acukac

Это 6 тактов минимум, вместо одного

#include <stdio.h>

int main() {
        int count = 1000000;
        int t1, t2, t3, t4;
        asm volatile(
                "mov %[count], %%ecx\n\t"
                "rdtsc\n\t"
                "mov %%eax, %%ebx\n\t"
                "1: push %%eax\n\t"
                "pop %%eax\n\t"
                "dec %%ecx\n\t"
                "test %%ecx, %%ecx\n\t"
                "jnz 1b\n\t"
                "rdtsc\n\t"
                "mov %%ebx, %[t1]\n\t"
                "mov %%eax, %[t2]\n\t"
                : [t1]"=r"(t1), [t2]"=r"(t2)
                : [count] "r" (count)
                : "eax", "ebx", "ecx", "edx"
        );

        asm volatile(
                "mov %[count], %%ecx\n\t"
                "rdtsc\n\t"
                "mov %%eax, %%ebx\n\t"
                "1: mov %%ecx, %%edx\n\t"
                "mov %%edx, %%ecx\n\t"
                "dec %%ecx\n\t"
                "test %%ecx, %%ecx\n\t"
                "jnz 1b\n\t"
                "rdtsc\n\t"
                "mov %%ebx, %[t1]\n\t"
                "mov %%eax, %[t2]\n\t"
                : [t1]"=r"(t3), [t2]"=r"(t4)
                : [count] "r" (count)
                : "eax", "ebx", "ecx", "edx"
        );

        printf("delta1: %d\n", t2 - t1);
        printf("delta2: %d\n", t4 - t3);
}
[~]$ ./test2
delta1: 3844133
delta2: 3005741
[~]$ ./test2
delta1: 4008326
delta2: 3134324
[~]$ ./test2
delta1: 3844955
delta2: 3005703

чото не видно разницы в 6 раз. Может назовете методику измерения?

AptGet ★★★
()
Ответ на: комментарий от AptGet

1. Почитайте, что происходит при push и pop. Сколько регистров при этом изменяется.

2. «dec %%ecx\n\t»
«test %%ecx, %%ecx\n\t»
«jnz 1b\n\t»

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

Пример:
50(тест)+50(оверхед)=100
10(тест)+50(оверхед)=60

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

3. push и pop записывают/читают RAM, а это однозначно в сотни раз медленней, даже если это кэш процессора.

4. Плюс к тому, параллелизация на уровне процессора push и pop невозможна, ни при выполнении одного потока инструкций в одном ядре, ни двух потоков инструкций в разных ядрах т.к. общие указатели на стек и оба потока обращаются к RAM.

acukac
()
Ответ на: комментарий от AptGet

кстати, лучше уж брать rdtscP - иначе вообще хрен поймешь, что там творится :)

acukac
()
Ответ на: комментарий от acukac

Я так понял, вы вообще не в курсах ассемблера.

А по моему вы даже близко не читали о компиляторах. Книжку дракона хоть осилили?

namezys ★★★★
()
Ответ на: комментарий от acukac

3. push и pop записывают/читают RAM, а это однозначно в сотни раз медленней, даже если это кэш процессора.

Я и рассчитывал на то, что будет заметная разница, а получилось что оверхед сравним с jmp.

4. Плюс к тому, параллелизация на уровне процессора push и pop невозможна, ни при выполнении одного потока инструкций в одном ядре, ни двух потоков инструкций в разных ядрах т.к. общие указатели на стек и оба потока обращаются к RAM.

Почему нет? У каждой нити свой стек обычно. Не представляю, зачем могут понадобиться нити на общем стеке.

AptGet ★★★
()
Ответ на: комментарий от acukac
#include <stdio.h>
#include <sched.h>
#include <sys/mman.h>

int main() {
        int count = 5000000;
        int val;
        int t1, t2, t3, t4;

        struct sched_param param;
        param.sched_priority = sched_get_priority_max(SCHED_FIFO);
        if (sched_setscheduler(0, SCHED_FIFO, &param))
                perror("sched_setscheduler");


        if (mlockall(MCL_CURRENT))
                perror("mlockall");

        asm volatile(
                "mov %[count], %%esi\n\t"
                "rdtscp\n\t"
                "mov %%eax, %%ebx\n\t"
                ".p2align 4\n\t"
                "1: mov %%eax, %[val]\n\t"
                "mov %[val], %%eax\n\t"
                "dec %%esi\n\t"
                "test %%esi, %%esi\n\t"
                "jnz 1b\n\t"
                "rdtscp\n\t"
                "mov %%ebx, %[t1]\n\t"
                "mov %%eax, %[t2]\n\t"
                : [t1]"=g"(t1), [t2]"=g"(t2), [val]"+m"(val)
                : [count] "g" (count)
                : "eax", "ebx", "ecx", "edx", "esi", "memory"
        );

        asm volatile(
                "mov %[count], %%esi\n\t"
                "rdtscp\n\t"
                "mov %%eax, %%ebx\n\t"
                ".p2align 4\n\t"
                "1: mov %%ecx, %%edx\n\t"
                "mov %%edx, %%ecx\n\t"
                "dec %%esi\n\t"
                "test %%esi, %%esi\n\t"
                "jnz 1b\n\t"
                "rdtscp\n\t"
                "mov %%ebx, %[t1]\n\t"
                "mov %%eax, %[t2]\n\t"
                : [t1]"=g"(t3), [t2]"=g"(t4)
                : [count] "g" (count)
                : "eax", "ebx", "ecx", "edx", "esi", "memory"
        );

        printf("delta1: %d\n", t2 - t1);
        printf("delta2: %d\n", t4 - t3);
}
[~]$ sudo ./test2
delta1: 22712278
delta2: 10141085
[~]$ sudo ./test2
delta1: 20859123
delta2: 10014537
[~]$ sudo ./test2
delta1: 19664553
delta2: 10019416

Ну что же, разница в 2 раза. Seems legit.

AptGet ★★★
()
Ответ на: комментарий от AptGet

Я и рассчитывал на то, что будет заметная разница, а получилось что оверхед сравним с jmp.

Не, ну если речь идет о push и pop против mov, то это и надо измерять :)

Почему нет? У каждой нити свой стек обычно. Не представляю, зачем могут понадобиться нити на общем стеке.

Я говорил о двух случаях:

1. Одна нить, но процессор выполняет некоторые упорядоченые инструкции параллельно, если они с друг другом не конфликтуют. Т.е., например, при передачи двух параметров «mov еax,[парам1]; mov ebx,[парам2]» две инструкции выполнятся параллельно, начиная с первого Пентюха. «push [парам1], push [парам2]» параллельно выполняться не могут т.к. изменяется указатель стека в обеих операциях.

2. Параллельные нити имеют каждый свой стек, но и тот и другой стек лежат в RAM, значит получается конкурентный доступ к памяти и при pop и при push. Да к разным кускам RAM, но к одной физической.

acukac
()
Ответ на: комментарий от AptGet

Ну что же, разница в 2 раза. Seems legit.

Интересный результат был бы еще, если запустить 100 нитей одновременно :) Думаю, там разница была бы раз в десять даже на двух ядрах :)

acukac
()
Ответ на: комментарий от acukac

Не, ну если речь идет о push и pop против mov, то это и надо измерять :)

Если обращение к памяти сравнимо по оверхеду с jmp, то можно и не измерять. Все равно при вызове функции основной оверхед будет от call.

1. Одна нить, но процессор выполняет некоторые упорядоченые инструкции параллельно, если они с друг другом не конфликтуют. Т.е., например, при передачи двух параметров «mov еax,[парам1]; mov ebx,[парам2]» две инструкции выполнятся параллельно, начиная с первого Пентюха. «push [парам1], push [парам2]» параллельно выполняться не могут т.к. изменяется указатель стека в обеих операциях.

А оно внутри никак не может оттранслироваться в

str парам1, [sp]
str парам2, [sp, #4]
add sp, sp, #8

и выполниться одновременно? Intel Architecture Optimization Reference Manual не читал.

2. Параллельные нити имеют каждый свой стек, но и тот и другой стек лежат в RAM, значит получается конкурентный доступ к памяти и при pop и при push. Да к разным кускам RAM, но к одной физической.

пока нет кэш-промахов все ok. А если есть, то никакие регистры не помогут, т.к. их мало.

AptGet ★★★
()
Ответ на: комментарий от acukac

Интересный результат был бы еще, если запустить 100 нитей одновременно :) Думаю, там разница была бы раз в десять даже на двух ядрах :)

да что интересного, там весь оверхед был бы от переключений контекста

AptGet ★★★
()

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

boo32
()
Ответ на: комментарий от boo32

Вот не надо хорошую команду разработчиков склонять к bloatware, мартетоидному буллшиту и прочему потреблядству.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

Для вас микроволновка - потреблятство, а костёр, выложенный вручную шалашиком - сверхэффективный продукт. Однако «бездушная» микроволновка всё-таки быстрее работает и стабильнее выдаёт результат.

boo32
()
Ответ на: комментарий от boo32

Для вас микроволновка - потреблятство

Для меня микроволновка из золота с брюликами - потреблядство.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

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

boo32
()
Ответ на: комментарий от devl547

Для меня микроволновка из золота с брюликами - потреблядство.

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

boo32
()
Ответ на: комментарий от boo32

Претензии

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

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

yogev_ezra
()
Ответ на: Претензии от yogev_ezra

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

boo32
()
Последнее исправление: boo32 (всего исправлений: 1)
Ответ на: комментарий от boo32

Личное мнение

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

yogev_ezra
()
Ответ на: Личное мнение от yogev_ezra

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

boo32
()
Ответ на: комментарий от boo32

Прощение

Прошу прощения, если это показалось вам обидным.

Вам не за что просить прощения у меня, так как я, к сожалению, не являюсь разработчиком. Проект KolibriOS я нашел в интернете самостоятельно 2.5 года назад, когда искал операционную систему с графическим интерфейсом, которая бы быстро грузилась и не «тормозила» на дешевых (порядка $100 USA за штуку) встроенных компьютерах на базе 32-битного x86 процессора Vortex86: http://www.compactpc.com.tw

Из всех проверенных мной «легковесных» ОС, включая Puppy Linux, DSL, Lubuntu, ReactOS, Haiku, урезанной Windows XP (BartPE) и других, KolibriOS оказалась самой быстрой, и требующей меньше всего места на диске. Некоторые из перечисленных систем вообще отказывались инсталлироваться или запускаться (по причине требования i686, поддержки только 64 бит, «сырости» самой ОС или кривого инсталлятора, считающего, что, кроме Intel и AMD, других процессоров на x86-архитектуре не существует в природе). Другие запустились, но тормозили так, что лучше б они не запускались :-) Единственным конкурентом KolibriOS, работающим более-менее достойно, оказался Puppy Linux, но даже он требовал в 50 раз больше места на диске (50MB против 1MB), и грузился в 6 раз дольше (60сек. вместо 10сек.)

Единственным неприятным моментом оказалось то, что Колибри не поддерживала звуковую и сетевую карты этого компьютера, а также USB устройства. Я обратился за помощью к разработчикам на форуме KolibriOS, и тут случилось то, что по законам джунглей не имело права случаться: эти нигилистичные самоучки, без всяких проектирований, алгоритмики, масштабирования, планирования, забесплатно НАПИСАЛИ ДЛЯ МЕНЯ (не портировали, не доработали, а именно написали с нуля) драйверы для моей сетевой и звуковой карт за 3 месяца, и драйвер USB за 1 год. Причем такая сетевая и звуковая карты были только у меня, т.е. для себя они точно не старались. А в любимых Вами «настоящих» ОС иногда даже за деньги невозможно получить поддержку своего железа. И кого я после этого буду уважать больше - разработчиков Колибри, или разработчиков «правильных ОС на ЯВУ»?

yogev_ezra
()
Ответ на: Прощение от yogev_ezra

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

boo32
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.