года 2 назад когда я услышал я подумал "ну зачем а ?" а сейчас это вплоне седе идея.

вы это сейчас серьезно ?

Саш, а ты тут типа про то что юникернел неплохая идея ?

идея хорошая, но как процесс в юзерленде

наоборот совсем

зачем нам эти толстые гипервизоры

а как это может выглядеть как процесс в юзерленде

зачем вообще эти гипервизоры? :)

Так и под какой язык Будет этот ваш уникернел?

я даже представить себе не могу

а как это может выглядеть как процесс в юзерленде

например, сетевой стек в юзерленде :)

сетевой стек я могу представить в юзерленде (он правда медленный что пипец) а вот концепт юникернелс нет

Нет - ну под какой язык-то?

сетевой стек я могу представить в юзерленде (он правда медленный что пипец) а вот концепт юникернелс нет

он очень быстрый и быстрее чем ядерный.

Гоулэнг вон можно гонять и поверх обычного ядра

Нет - ну под какой язык-то?

я тебя не понял

Безо всякого там юзерспейса лишнего

я тебя не понял

Сейчас юникернелы таки language-specific

не

@demeliorator ну есть реилзации для эрланг и для джавки вроде как

Точнее VM-specific

это опять про сейчас

Типа “BEAM on Xen”

сетевой стек я могу представить в юзерленде (он правда медленный что пипец) а вот концепт юникернелс нет

http://www.openonload.org/

Так и далее так же будет, не?

It achieves performance improvements in part by performing network processing at user-level, bypassing the OS kernel entirely on the data path.

не

идея в том, чтобы контейнер запускать не в ОС, а с библиотечной ОС в основе

Типа “BEAM on Xen”

что мешает beam on kvm?

эксперименты с эрлангом и джавой это типа пруф он концепт

идея в том, чтобы контейнер запускать не в ОС, а с библиотечной ОС в основе

зачем?

http://www.openonload.org/

микрокернел страйкс бек?

микрокернел страйкс бек?

ну, это скорее всё-таки юникернел.

что мешает beam on kvm?

Я не знаю А что мешает собирать докер имадж при помощи nix-docker в один слой

И он будет не 300 метров, а 30

ну затем чтобы хотя бы с безопасностью порешать и не таскать огромные образы

Я не знаю А что мешает собирать докер имадж при помощи nix-docker в один слой

а оно аккуратно выцепит все нужные dso?

зачем?

а зачем нам десяток слоев поверх хардвара в виде виртуалок, в которых бегают докеры ?

а оно аккуратно выцепит все нужные dso?

А никакие не нужны

Пишите на Go

Но вообще - видимо да, выцепит

Оно никсовые пакеты сложит нужные в тот же образ

а зачем нам десяток слоев поверх хардвара в виде виртуалок, в которых бегают докеры ?

ну так контейнеры - это вообще без каких-либо слоёв. только ядро и всё :)

а зачем нам десяток слоев поверх хардвара в виде виртуалок, в которых бегают докеры ?

А что там за десяток слоев?

проблем много сейчас в контейнеризации и связаны эти все проблемы с линуксом

проблем много сейчас в контейнеризации и связаны эти все проблемы с линуксом

какие именно проблемы?

сеть в юзерспейсе, безопасность и изоляция контейнеров, производительность со специфическим железом

сеть в юзерспейсе, безопасность и изоляция контейнеров, производительность со специфическим железом

шта?

какая ещё сеть в юзерспейсе?

А что там за десяток слоев?

все прослоечки в виде фс\сети\шедулинга намапленные еще на контейнеры\намапленые в гипервизорах.

ты сам про сеть в юзерспейсе писал :)

В контейнере нет никакой прослоечки над фс

ну опенвсвитч например

Там обычный bind mount же

все прослоечки в виде фс\сети\шедулинга намапленные еще на контейнеры\намапленые в гипервизорах.

нет там прослоек. процесс в контейнере == процесс вне его.

ну опенвсвитч например

Он же в ядре

ну опенвсвитч например

во-первых, зависит от datapath.

вообще читайте тут https://blog.docker.com/2016/01/unikernel/ вы меня достали :)

чувак ты во всем прав :)

во-вторых, openvswitch с правильным юзерспейсным datapath сильно быстрее.

я тебе точно говорю

и ты очень крут и все знаешь :)

но ты хочешь не разговаривать а доказывать свою правоту, а это не интересно

нет там прослоек. процесс в контейнере == процесс вне его.

тоесть абстракция неймспейсов не прослойка ?

но ты хочешь не разговаривать а доказывать свою правоту, а это не интересно

потому что ты говоришь какой-то набор штампов.

а что тебе надо сказать?

это тогда я тут научную работу напишу

ERROR: S client not available

тоесть абстракция неймспейсов не прослойка ?

ну ёмае. у процессов просто появляется атрибут, описывающий к какому неймспейсу он принадлежит. всё.

и qemu не прослойка

и qemu не прослойка

он не нужен для контейнеров.

ну ёмае. у процессов просто появляется атрибут, описывающий к какому неймспейсу он принадлежит. всё.

если так смотреть, тогда все наши системы "плоские"

везде, какие то флаги, и набор услоновстей у кучи объектов содержащих в себе другие объекты

а что тебе надо сказать?

ты знаешь про dpdk?

знаю

и это появилось не от хорошей жизни

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

отлично. ovs умеет его использовать.

и у интел нет возможности это исправит

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

он везде не очень хорош.

это все костыли

не костыли - это очень дорого

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

а что дорого то?

а dpdk, как и прочий kernel bypass - это такой хак для конкретной задачи.

не приспособлен, да

ну ты подумай, что можно жить без хака

а что дорого то?

надо перетрясти весь сетевой стек.

ну а я о чем

ты что - как так, жить без боли ))

сейчас, правда, этим и заняты в netdev

ты что - как так, жить без боли ))

потому что i/o - боль!

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

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

да блин. там не в драйверах беда.

и интел быстро это запилит

вместо dpdk

вот тебе поддержка вендоров

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

лучше вместо всех этих гипервизоров пусть сделают дешевые bare metal на arm64

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

сделали уже.