Состоялся (https://mirage.io/blog/announcing-mirage-35-release) релиз операционной системы MirageOS 3.5 (https://mirage.io), позволяющая формировать операционные системы одного приложения, в которых приложение поставляется как самодостаточный "unikernel", способный выполняться без применения операционных систем, отдельного ядра ОС и каких-либо прослоек. Для разработки приложений применяется язык OCaml. Код проекта распространяется (https://github.com/mirage/mirage) под свободной лицензией ISC.
Вся низкоуровневая функциональность, свойственная операционной системе, реализована в форме библиотеки, прикрепляемой к приложению. Приложение может быть разработано в любой ОС, после чего компилируется в специализированное ядро (концепция unikernel (http://queue.acm.org/detail.cfm?id=2566628)), которое может запускаться напрямую поверх гипервизоров Xen, KVM, BHyve и VMM (OpenBSD), поверх мобильных платформ, в форме процесса в POSIX-совместимом окружении или в облачных окружениях Amazon Elastic Compute Cloud и Google Compute Engine.
Сгенерированное окружение не содержит ничего лишнего и взаимодействует непосредственно с гипервизором без драйверов и системных прослоек, что позволяет добиться существенного снижения накладных расходов и повышения безопасности. Работа с MirageOS сводится к трём стадиям: подготовка конфигурации с определением используемых в окружении OPAM-пакетов (https://opam.ocaml.org/), сборка окружения и запуск окружения. Runtime для обеспечения работы поверх Xen основан на урезанном ядре Mini-OS (https://wiki.xenproject.org/wiki/Mini-OS), а для других гипервизоров и систем на базе ядра Solo5 (https://github.com/solo5/solo5).Несмотря на то, что приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размер (например, DNS-сервер занимает всего 200 Кб). Упрощается и сопровождение окружений, так как при необходимости обновления программы или изменения конфигурации, достаточно создать и запустить новое окружение. Поддерживается несколько десятков библиотек (https://github.com/mirage) на языке OCaml для выполнения сетевых операций (DNS, SSH, OpenFlow, HTTP, XMPP и т.п.), работы с хранилищами и обеспечения параллельной обработки данных.
Основные новшества:
- Расширена спецификация интерфейсов для работы с БД в формате ключ/значение (mirage-kv), добавлено новое хранилище в формате ключ/значение с поддержкой операций чтения и записи, а также вариант хранилища для непостоянного хранения данных в оперативной памяти. Целью проведённое работы является замена интерфейса mirage-fs на хранилище в формате ключ/значение. Кроме того развивается распределённое хранилище irmin, предоставлявшее возможность создания ответвлений БД и доступа с использованием протокола Git, а также файловая система wodan, которая сможет использоваться на Flash-накопителях;
- Расширены API библиотек mirage-clock (системные часы), mirage-protocols (сетевые протоколы) и mirage-net (сетевые устройства);
- Повышено качестве предоставляемого генератора псевдослучайных чисел;
- В реализации стека TCP/IP добавлена поддержка пересборки фрагментов пакетов IPv4 (fragment reassembly). Для TCP добавлена поддержка keepalive. Код для инкапсулирования/декапсулирования Ethernet и реализация протокола определения адресов (ARP) вынесены в отдельные OPAM-пакеты;
- Добавлена поддержка запуска в качестве unikernel высокопроизводительного http-сервера httpaf (https://github.com/inhabitedtype/httpaf);
- В пакете mirage-net, предоставляющем средства для низкоуровневого взаимодействия с сетевыми устройствами, реализованы бэкенды xen, solo5, unix, macos и vnetif;
- В runtime на базе Solo5 добавлена поддержка работы поверх гипервизоров FreeBSD bhyve и OpenBSD VMM, обеспечена поддержка ARM64 и KVM, добавлена возможность работы с использованием микроядра GenodeOS;
- Большинство пакетов переведены на использование сборочной системы
dune (https://dune.build/) (jbuilder). Всего для MirageOS подготовлено более 100 OPAM-пакетов;
- Добавлена возможность прикрепления пакетов-зависимостей к unikernel, для работы с которыми требуется наличие пакетного менеджера opam 2.0.2 или более новой версии;
- Добавлена поддержка языка OCaml 4.06.0 в режиме безопасной работы со строками (safe-string).
URL: https://mirage.io/blog/announcing-mirage-35-release
Новость: https://www.opennet.ru/opennews/art.shtml?num=50278
>приложения и библиотеки формируются на высокоуровневом языке OCaml, итоговые окружения демонстрируют достаточно неплохую производительность и минимальный размерИнтересно, причина в OCaml или в прямых руках разработчиков?
Развитая система типов плюс статическая типизация позволяют создавать API, которые инкапсулируя всё, что требует тщательной проработки, обходятся везде где можно памятью со стека, не нагружая кучу и сборщик мусора. Это всё те же идеи, которые отрабатывались в haskell'е и в C++. Плюс к этому оно не прибито гвоздями к какой-то выбранной парадигме, позволяя использовать те парадигмы, которые лучше ложатся на задачу.То есть причина в OCaml. Но вероятно причина также в программистах: я полагаю, что люди пользующиеся ocaml'ом -- это существенно не случайная выборка из генсовокупности программистов. Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих. А такой человек, как минимум, не заурядная web-макака.
> Туда лезут люди, которым чего-то не хватило в C++, в haskell и прочих.В Хаскелях не хватает скорости.
> обходятся везде где можно памятью со стека,
> не нагружая кучу и сборщик мусора.Вообще-то стэк OCaml-а аллоцирован в куче.
>> обходятся везде где можно памятью со стека,
>> не нагружая кучу и сборщик мусора.
> Вообще-то стэк OCaml-а аллоцирован в куче.Какая разница где он аллоцирован, если аллокация со стека сводится к одной арифметической инструкции процессора?
Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости переаллоцируя весь "стек".
> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных."стеке процессора"? Что за странное словосочетание? Ты хочешь сказать, что ocaml использует два стека? Один для нужд рантайма и параллельный стек для собственно программы? Да ладно, не может быть.
И да, о какой пересылке речь?
> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые
> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости
> переаллоцируя весь "стек".Большую часть этих проверок можно делать статически. Или даже все эти проверки можно выполнять статически. Но тут уже от языка зависит, скажем от того, позволяет ли он выделять со стека куски памяти динамического размера, и используется ли при этом рекурсия, глубину которой компилятор просчитать не в состоянии.
> переаллоцируя весь "стек".
Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае плохо, и если на это идёт заточка, то переаллокации должны происходить только в сторону увеличения, чтобы их было бы немного за всё время выполнения программы. А вообще, я бы просто выкидывал исключение -- за стеком надо следить, и если его мало, то надо заранее заказать побольше.
Вообще мне странны твои слова, в том смысле, что я в Common Lisp'е постоянно выделял на стеке, и я был уверен в том, что стоимость этого выделения в большинстве ситуаций O(1) -- то есть проверка на переполнение и сложение. Что там sbcl делал в случае переполнения, я не задумывался никогда.
Хотя я так подумал... про ocaml пишут, что у него generational gc, а выделение памяти из такой кучи, как я понимаю, не сильно дороже, чем выделение памяти из стека.Разница будет при сборке мусора. Всё что было выделено на стеке эффективно освобождается перемещением указателя стека. А вот выделенное в куче там и остаётся, и каждое выделение из кучи приближает момент, когда будет необходим цикл сборки мусора.
>> Во-первых, говоря о стеке процессора, ты забыл про пересылку данных.
> "стеке процессора"? Что за странное словосочетание?Обычное название для стека, который адресуется регистром процессора (RSP в случае AMD64).
> Ты хочешь сказать, что ocaml использует
> два стека?Да, именно о том я и писал выше.
> Один для нужд рантайма и параллельный стек для собственно
> программы? Да ладно, не может быть.
Instruct(PUSH): Instruct(PUSHACC0):
*--sp = accu; Next;
Instruct(PUSHACC1):
*--sp = accu; accu = sp[1]; Next;
Instruct(PUSHACC2):
*--sp = accu; accu = sp[2]; Next;
Instruct(PUSHACC3):
*--sp = accu; accu = sp[3]; Next;
Instruct(PUSHACC4):
*--sp = accu; accu = sp[4]; Next;
Instruct(PUSHACC5):
*--sp = accu; accu = sp[5]; Next;
Instruct(PUSHACC6):
*--sp = accu; accu = sp[6]; Next;
Instruct(PUSHACC7):
*--sp = accu; accu = sp[7]; Next;> И да, о какой пересылке речь?
Пересылка данных из сохраняемого регистра в память (и наоборот).
>> Во-вторых, для своего стека OCaml по очевидным причинам не может использовать стековые
>> инструкции; кроме того, проверяет выход за пределы выделенного блока, при необходимости
>> переаллоцируя весь "стек".
> Большую часть этих проверок можно делать статически. Или даже все эти проверки
> можно выполнять статически. Но тут уже от языка зависит, скажем от
> того, позволяет ли он выделять со стека куски памяти динамического размера,
> и используется ли при этом рекурсия, глубину которой компилятор просчитать не
> в состоянии.
/* Stack checks */check_stacks:
if (sp < caml_stack_threshold) {
caml_extern_sp = sp;
caml_realloc_stack(Stack_threshold / sizeof(value));
sp = caml_extern_sp;
}
/* Fall through CHECK_SIGNALS */>> переаллоцируя весь "стек".
> Ну, вообще, на мой взгляд, переаллокация стека -- это в любом случае
> плохо, и если на это идёт заточка, то переаллокации должны происходить
> только в сторону увеличения, чтобы их было бы немного за всё
> время выполнения программы. А вообще, я бы просто выкидывал исключение --
> за стеком надо следить, и если его мало, то надо заранее
> заказать побольше.Так и сделано. Лимит можно задать перед выполнением.
> Вообще мне странны твои слова, в том смысле, что я в Common
> Lisp'е постоянно выделял на стеке, и я был уверен в том,
> что стоимость этого выделения в большинстве ситуаций O(1) -- то есть
> проверка на переполнение и сложение. Что там sbcl делал в случае
> переполнения, я не задумывался никогда.В OCaml на уровне языка отсутствует понятие "выделить на стеке". В случае ocamlopt целые числа могут быть аллоцированы в регистрах процессора, за что приходится платить проверкой младшего бита (что бы отличать их от boxed) и суженным вдвое диапазоном возможных значений. Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С.
С другой стороны, даже несмотря на простор для низкоуровневых оптимизаций, OCaml действительно в ряде случаев конкурирует с C, значит выигрыш достигается за счёт простоты реализации сложных алгоритмов и компетенции разработчиков.
> Так и сделано. Лимит можно задать перед выполнением.На оба стека?
Контролем стека процессора занимается ОС (см. man limits.conf), ставит сторожевую страницу (в общем случае не даёт гарантий от переполнения).
> Кстати, в MLton эти проблемы решены, как и бесшовное взаимодействие с С.Только за счёт того, что компиляция программ занимает минуты или даже десятки минут.
Компиляция же самого компилятора ocaml (make world -j1000/make world.opt -j1000) на серьёзном сервере проходит секунд за 40.
Я не хочу умалять достоинства MLton, но это, всё-таки, исследовательский компилятор.
> Один для нужд рантайма и параллельный стек для собственно
> программы? Да ладно, не может быть.Почему? В Clean, например, 3 стека - ABC (atomic/boxed/control по типу того, что туда засовывается).
Потому что cache-locality. Стек хорош в этом: функции работают преимущественно с локальными переменными, которые либо в регистрах либо на стеке. Всякие там адреса возврата туда же попадают, и всё получается неплохо. Если же мы начинаем раскидывать это по трём стекам, то в кеш начинает попадать больше ненужного -- из стека же в кеш переносится не нужная переменная, а кусок памяти в 64 байта (cache line), содержащий эту переменную. Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше.Ну и потому, что накладные расходы на поддержание этих трёх стеков. Одно дело, когда всё сводится к одному указателю, под который мы условились в нашем ABI использовать один регистр, и даже не паримся хранить этот указатель где-то ещё в памяти, другое дело, когда у тебя три указателя, тут даже на x86-64, где регистров общего назначения не 8 а 16, будет не очень комфортно три регистра терять под стек. А уж на 32-х битной платформе, ты неизбежно упрёшься в необходимость хранить эти указатели в статических переменных, а эти статические переменные в кеше. И это добавит тебе лишний уровень индирекции: чтобы взять значение по его смещению от вершины стека, надо прочитать указатель стека из памяти в регистр, а потом разадресовать регистр.
При этом, я не удивлюсь, если x86 имеет в себе специальные фишки, которые делают операции со стеком быстрее, если стек построен на bp/ebp/rbp, а не на каком-нибудь там esi или r15. По-моему я даже читал об этом что-то когда-то.
> Там где на одном стеке будет достаточно 1-2 линий кеша под всё актуальное, на трёх надо будет в два-три раза больше.Я думаю, что раза в полтора - всё-таки, рабочая глубина этих стеков будет меньше. Кроме того, Clean очень лёгкий:
module Hello
Start :: String
Start = "Hello World!"компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля.
С третьей стороны, возможно они и как-то сливают вместе эти стеки - надо посмотреть кодогенератор.
> рабочая глубина этих стеков будет меньшеТут сложно навскидку рассуждать, но если с каждого из тех стеков надо всего одну 64-битную переменную, то выходит что две 64-байтовые кеш-линии заняты под 16 байт полезных данных. Это, наверное, чёрт с ним, двумя кеш-линиями больше, двумя меньше, какая собственно разница.
> Кроме того, Clean очень лёгкий:
> module Hello
> Start :: String
> Start = "Hello World!"
> компилируется в 113 килобайт, в отличие от мегабайтов Хаскеля.113Kb на hello world -- это "лёгкий"? ;) Лёгкий -- это 142 байта: http://timelessname.com/elfbin/
Но я это не к тому, что Clean тяжёлый, я это к тому, что размер этих 113 килобайт или мегабайтов Хаскеля определяются вовсе не количеством стеков. Хаскель скорее всего тащит статически вкомпонованные библиотеки, поэтому и бинари такие огромные.
142 многовато, вот 128
$ cat hello.asm; fasm demonstration of writing simple ELF executable
format ELF executable 3
entry startsegment readable executable
start:
mov eax,4
mov ebx,1
mov ecx,msg
mov edx,msg_size
int 0x80mov eax,1
xor ebx,ebx
int 0x80;segment readable writeable
msg db 'Hello world!',0xA
msg_size = $-msg
$ fasm hello.asm
flat assembler version 1.73.06 (16384 kilobytes memory)
2 passes, 128 bytes.
$ ./hello
Hello world!
> 142 многовато, вот 128ЖЫрнота, особенно по зависимостям!
% cat real_hello_world.asm
BASE equ 07c00h
VIDEO_MEM equ 0b800h
COLOR equ 02h * 100horg BASE
use16jmp 0:start
start:cli
cld
xor ax,ax
mov ds,ax
sti;*******************************
;set video out=80x25, 16 colors, page 0
;*******************************
mov ax,3
int 10hmov ax, 500h ;0 page
int 10hmov ax, VIDEO_MEM
mov es, axxor di, di
mov si, msg
mov ax, COLOR
mov cx, msg.lenprint:
lodsb
stosw
loop printcli
hltmsg db "Hello World!"
msg.len = $ - msg
;db BASE+510-$ dup(0)
;signature:
;dw 0aa55h% fasm real_hello_world.asm
flat assembler version 1.73.09 (16384 kilobytes memory)
2 passes, 56 bytes% dd if=/dev/zero count=454 conv=notrunc seek=56 bs=1 of=real_hello_world.bin
% echo -n "\0x55\xaa" >> real_hello_world.bin
У меня длиннее (или что именно меряли последние два замера?) :) ?
Это же MBR размером 512 байт (на некотором железе не запустится), а было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).
> размером 512 байтНеа, см:
>> 2 passes, 56 bytesСпециально считерил, "срезав" (см. последние три строчки - ";" в интел-синтаксисе комментарий) конец и дав подходящую команду для записи с помощью dd.
В принципе, можно и сам код еще (существенно) сделать меньше, но тогда оно может резко стать "qemu-only".
Но даже при размере в 512 байт оно выигрывает по размеру общих зависимостей (ни ld-elf, ни ядра не нужно) :PКстати, могу еще предложить:
cat hello.asm
org 100h
use16mov dx, msg
mov ah, 09h
int 21hint 20h
msg db 'Hello World!',0Ah,'$'% fasm hello.asm
flat assembler version 1.73.09 (16384 kilobytes memory)
2 passes, 23 bytes.
> (на некотором железе не запустится),Оно ж уже и не модно, давно. Тем более и на "том" железе была куча проблем и проблемок (а так же костылей, костыликов и подпорочек -- достаточно откопать LILO или глянуть (возможно, в старый вариант) GRUB).
Хотя замена старых костылей на "молодежные" PE + FAT32 вообще за гранью добра и зла …
> было "Smallest x86 ELF Hello World" (50 байт + файловый заголовок).Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках ;)
см.
>> компилируется в 113 килобайт, в отличие от мегабайтов ХаскеляНа самом деле тут еще желательно знать, что там линкуется статистически, а что динамически, т.к. тот же HelloWorld на Си при "gcc -static -s" запросто может выдать бинарник на 500КБ c гаком, а для плюсов и на все полтора, но те кто обсуждают, скорее всего более-менее в курсе или же могут посмотреть.
Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми сискол-вызовами ядра.
Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то особо не видно и практическая ценность таких замеров примерно на том же уровне, что и замер кое-чего другого ;)
>> размером 512 байт
> Неа, см:
>>> 2 passes, 56 bytesСами по себе эти 56 байт разве запустятся? Всё одно, требуется некий аналог "executable format".
>[оверквотинг удален]
> use16
> mov dx, msg
> mov ah, 09h
> int 21h
> int 20h
> msg db 'Hello World!',0Ah,'$'
> % fasm hello.asm
> flat assembler version 1.73.09 (16384 kilobytes memory)
> 2 passes, 23 bytes.Интересно, сколько выйдет подобное на каком-нибудь Sinclair BASIC, где PRINT занимает 1 байт, плюс 2 байта на номер строки, наверное, ещё что-то.
> Изначально речь шла о (грубом и ориентировочном) размере в довольно узких рамках
> ;)
> см.
>>> компилируется в 113 килобайт, в отличие от мегабайтов ХаскеляНу так то да, килобайты ныне "мало". :)
> На самом деле тут еще желательно знать, что там линкуется статистически, а
> что динамически, т.к. тот же HelloWorld на Си при "gcc -static
> -s" запросто может выдать бинарник на 500КБ c гаком, а для
> плюсов и на все полтора, но те кто обсуждают, скорее всего
> более-менее в курсе или же могут посмотреть.
> Однако, одно дело "стандартный" бинарник с использованием стандартной библиотеки/рантайма
> и совершенно другое -- "минимальный бинарник", с вставками ASM и прямыми
> сискол-вызовами ядра.С++ с использованием std::cout -- 24.5 Kb. В зависимостях лишь обёртка над сисколами (ntdll).
https://code.google.com/archive/p/ontl/wikis/HelloWorld.wiki Полагаю, ничего не мешает портировать и в Linux.> Оно конечно прикольно, но вот желающих писать реальный софт таким макаром почему-то
> особо не видно и практическая ценность таких замеров примерно на том
> же уровне, что и замер кое-чего другого ;)А если отправить в рассылку ядра какой-нибудь драйвер, скажем, на Rust. Линус выступит, покажет палец, тут впишется кто-то из этих, простите... ну, Вы поняли (надо же их наличие конвертировать в пользу для общества). Люди начнут об этом говорить, а? :)
популярен во франкоязычных странах. Сам по себе вполне не плох, но вот только в остальных странах к сожалению не особо популярен, нужно реально быть в голове французом чтобы предпочесть его плюсам или яве. В том смысле что начиная проект обычно сразу задумываешся с какими людьми будешь его делать вместе и как с ними будешь общаться; французы в этом плане довольно замкнуты.
Зависит от задачи. Вычислительный код писать, например, очень неудобно, если не переопределить операторы. Многопоточности пока нет.
Ну почему же? В фейсбуке используют (см. reasonml). Docker for Mac тоже на нем написан.
И то, и другое. Ocaml - это в девичестве Caml Light, который был создан Ксавье Леруа и компанией в качестве высокопроизводительного компилятора функционального языка. И это у них осталось в культуре: одно из основных требований - это быстрота программ. Это требование, например, заставило их делать все вычисления "справа налево", сломав традиционное для ML слева направо.
Упомянутая выше dune, кстати, тоже отрабатывает мгновенно за счёт умного кеширования. В Jane Street недавно был доклад на эту тему.
MLton для оптимизации выполняет unboxing, в аналогичных местах OCaml будет проверять младший бит, что бы различить значения и указатели. А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?
> А за счёт чего "делать все вычисления "справа налево" может дать прирост скорости при выполнении?Чтобы выражение (f a b c d), которое обязано быть равным ((((f a) b) c) d), можно было заменять на прямой вызов функции f с вычисленными параметрами a b c d. Это изложено в книжке https://xavierleroy.org/bibrefs/Leroy-ZINC.html (ссылка local copy), на странице 14.
Они ребята последовательные, поэтому это вычисление справа налево у них везде - я проверял. Делается структура, массив, кортеж, что угодно - везде справа налево. Ну кроме блока последовательных процедур, конечно.
Благодарю. Однако, там же сказано (со ссылкой на Драгонбук), что преимущество может дать неопределённый порядок вычисления аргументов, принятый в C.In Objective CAML, the order of evaluation of arguments is not specified. As it happens, today all implementations of Objective CAML evaluate arguments from left to right. All the same, making use of this implementation feature could turn out to be dangerous if future versions of the language modify the implementation.
http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora029....
Ну там лажа написана - надо поменять. Простейшая проверка показывает, что right to left:# let f x y = (x, y);;
val f : 'a -> 'b -> 'a * 'b = <fun>
# f (print_string "Left") (print_string "Right");;
RightLeft- : unit * unit = ((), ())Понятно, что чем больше у компилятора возможностей, тем больше может быть степень оптимизации. Но сейчас всё согласовано - right to left.
Если там перепутали порядок вычисления аргументов в существующих имплементациях, это одно. Другое дело, что кроме того там написано "порядок не определён; так получилось, что аргументы вычисляются так-то, но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".
> но рассчитывать на эту особенность опасно, т.к. в будущем может измениться".Ну я бы не стал рассчитывать на такие тонкости, с учётом тех серьёзных изменений в stdlib, которые произошли между 3 и 4. С другой стороны, то руководство вообще для дремучей версии 2.
print_endline "Hello World!";;компилируется в 355944 байт (ocamlopt)
либо в 17793 байт (ocaml, байт-код)
TL;DR: чуваки написали ядро ОС без поддержки userspace-процессов.
да, это для эмбедовки
MirageOS в первую очередь применяется в докере.
ок, спасибо, не знал. Сам на нее смотрел пару лет назад как на альтернативу freertos для allwiner (была идея выделить у A20 одно ядро под реалтайм), но не решился, да и не пошел тот проект у нас.
Это ОС в виде библиотеки (статически линкуемой, разумеется). В эмбедовке такой подход применяется повсеместно.
Гайс, обоснуйте в ней можно будет полноценно установить/запустить например брайзер чтобы он там в своём соку варилась и ни как не взаймидействовала с основной системой? Или есть что-то другое что вы можете предложить.
ne
Тебе как минимум для гуя нужно взаимодействие с системой.
Это для краснoглазиков любящих сервера и консоли, гуй не нужен.
Это хромопроблемы. В файрфокс метрики нет от слова "вообще", его хоть из-под рута можно запускать (я и запускаю иногда, кстати) и ничего не случится. Недавно добавили защиту от биткоина например. Ждем тебя в своих рядах, хромер!
О mirage-kv написано совершенно не верно. Это не библиотека, а набор сигнатур OCaml (спецификация интерфейса) для взаимодействия с абстрактным key-value storage engine. К git это никакого отношения не имеет, совсем.Далее, есть отдельный проект https://github.com/mirage/irmin, реализующий некую модульную базу данных. Так вот в этом Irwin-не есть модули для взаимодействия с git и для хранения данных внутри (с опорой на сервисы) Mirage-OS. В том числе этот Irwin конечно умеет предоставлять доступ через интерфейс описанный в mirage-kv.
Т.е. при жалении этот Irwin и его взаимодействие с Git можно пользовать без Mirage-OS (но не стоит думать что оно может конкурировать по скорости с RocksDB, Tarantool или libmdbx).
Вижу что уже поправили. Теперь норм.
Это для тех, кто скучает по DOSу?
да, кстати, сам только сейчас понял что действительно скучаю по такой юнности в которой дос был бы аккуратно написан в открытых исходниках на окамле...