Выражусь поконкретней. У меня хост-система, допустим, Debian с glibc, а в контейнере – Alpine с musl. Соответственно, хостовые приложения у нас связаны с одной библиотекой, а контейнеризованные – с другой. Так под glibc и musl что, не выделяется память отдельно под ту и другую?
Далее, представим себе, что у нас уже контейнеризовано что-то на Alpine версии 3.15 с musl=1.2.2, и тут мы создаём новый контейнер с Alpine 3.16 и musl=1.2.3. У нас опять происходит магия и никакого оверхеда, или всё-таки расходуется память под обе версии musl?
А если ещё чуть-чуть подумать, разве не весь юзерспейс у нас ведёт себя точно так же? Библиотеки, утилиты, шеллы? На хосте и в каждом контейнере?
Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.
Разве неочевидно? Они же омерзительно непитоничны. Судя по всему, их скопипастили в своё время с C++ или Java только потому, что надо было что-то такое иметь в стандартной либе как можно скорее. Теперь, когда есть нормальные альтернативы (loguru и pytest), поддерживать их там нет никакого смысла.
к сожалению, стало реальностью, когда при прохождении российской границы «погранцы» (и не только они) настойчиво интересуются его профессиональной деятельностью – не IT-шник ли он... Если вдруг выясняется, что пытается выехать программист, то… были даже случаи отказа в пересечении российской границы.
Самый близкий по сути проект к тому, что я имел в виду под
heroku-подобный serverless контейнер
видимо, https://caprover.com/. Но у него недостатки такие (дальше цитаты из мануалов):
(Simple Setup) The recommended method to install CapRover is via DigitalOcean one-click app. CapRover is available as a One-Click app in DigitalOcean marketplace.
даунгрейдить virtual server до serverless не имеет никакого смысла. Ни технически, ни финансово.
(Run Locally) Note that this is an advanced process. Some of the concepts used in this section are not easy for the beginners. In order to run CapRover on your local machine (just for testing and development) you need Docker installed on your machine.
а это уже совершенно недопустимо. Инсталляция на любой платформе (или как минимум на популярных) должна сводиться к самому типичному для этой платформы способу установки прикладного ПО. То есть на Ubuntu -- apt install, на Маке -- brew install или перетаскиванием *.dmg, на Windows -- кликом на *.exe и т. д.
А вот что можно запросто выбросить из списка фич, так это поддержку баз данных. Уже и так создан миллион сервисов персистентности для serverles apps.
Ну и, конечно, я бы с удовольствием присоединился к проекту, но только если весь код будет распространяться под свободной лицензией (пермиссивной или копилефт, не принципиально).
Не вижу особой разницы. В том и другом случае ресурсы не простаивают, только штуки типа folding@home привлекают пользователей гуманистическим посылом, а ваша идея, как я понимаю, заключается в том, чтобы понемногу отдавать свои простаивающие мощности за возможность кратковременно, на пике мощности, использовать чужие.
Мне очень нравится ваша идея в таком виде.
Только кубернетисы, конечно, для этого не подойдут, а подойдёт какой-нибудь heroku-подобный serverless контейнер. Я не смотрел в эту сторону раньше, не знаю, существуют ли такие, или нужно будет писать своё.
И надо будет немножко повозиться с определением эквивалента мощности. Плюс понадобятся некие централизованные ресурсы для сведения баланса, пробития NAT, распределения лямбд по контейнерам, ну и для организационных целей. Тут можно будет просто продавать часть ресурсов за деньги при необходимости. Лучше оформить это как нон-профит, при этом нужен будет ещё какой-то свой сервис, чтобы автоматически публиковать бюджет. Как-то так.
Выражусь поконкретней. У меня хост-система, допустим, Debian с glibc, а в контейнере – Alpine с musl. Соответственно, хостовые приложения у нас связаны с одной библиотекой, а контейнеризованные – с другой. Так под glibc и musl что, не выделяется память отдельно под ту и другую?
Далее, представим себе, что у нас уже контейнеризовано что-то на Alpine версии 3.15 с musl=1.2.2, и тут мы создаём новый контейнер с Alpine 3.16 и musl=1.2.3. У нас опять происходит магия и никакого оверхеда, или всё-таки расходуется память под обе версии musl?
А если ещё чуть-чуть подумать, разве не весь юзерспейс у нас ведёт себя точно так же? Библиотеки, утилиты, шеллы? На хосте и в каждом контейнере?
Ядро-то изолировано, а над ядром – отдельный юзерспейс, ортогональный хостовому. Как тут может не быть оверхеда по памяти?
Просто единственная ссылка на скачивание со страницы продукта ведёт на старую версию. То, что это “предыдущая” система, кстати, легко не заметить.
А какой смысл в этих гарантиях? Можно же обеспечить себе то, что нужно, а не довольствоваться тем, что завезли.
Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.
Разве неочевидно? Они же омерзительно непитоничны. Судя по всему, их скопипастили в своё время с C++ или Java только потому, что надо было что-то такое иметь в стандартной либе как можно скорее. Теперь, когда есть нормальные альтернативы (loguru и pytest), поддерживать их там нет никакого смысла.
Ещё бы выбросили logging и unittest, вообще супер было бы.
Ответ: никак. Если страна не способна наладить контакт с одним вендором, то взаимодействовать с международным сообществом тем более не получится.
Это уже не детсад, но и не энтерпрайз никаким боком. В школе как минимум учат Scrapy.
Химического всё-таки, а не биологического.
Можно с этого места поподробнее?
Маркиз Астольф де Кюстин, "Россия в 1839 году".
Ну, это я так образно выражаюсь. Почку-не почку, но повыкручивать руки друг другу в судах можно.
Открытый код без лицензии -- опасно. Я так закоммичу что-нибудь, а вы потом прикрутите лицензию, в которой каждый коммитер обязан продать почку.
Проприетарные: Google Firebase, Azure SQL Database, SashiDo. Открытые: Parse, Strapi.
Самый близкий по сути проект к тому, что я имел в виду под
видимо, https://caprover.com/. Но у него недостатки такие (дальше цитаты из мануалов):
даунгрейдить virtual server до serverless не имеет никакого смысла. Ни технически, ни финансово.
а это уже совершенно недопустимо. Инсталляция на любой платформе (или как минимум на популярных) должна сводиться к самому типичному для этой платформы способу установки прикладного ПО. То есть на Ubuntu --
apt install, на Маке --brew installили перетаскиванием *.dmg, на Windows -- кликом на *.exe и т. д.А вот что можно запросто выбросить из списка фич, так это поддержку баз данных. Уже и так создан миллион сервисов персистентности для serverles apps.
Ну и, конечно, я бы с удовольствием присоединился к проекту, но только если весь код будет распространяться под свободной лицензией (пермиссивной или копилефт, не принципиально).
Не вижу особой разницы. В том и другом случае ресурсы не простаивают, только штуки типа folding@home привлекают пользователей гуманистическим посылом, а ваша идея, как я понимаю, заключается в том, чтобы понемногу отдавать свои простаивающие мощности за возможность кратковременно, на пике мощности, использовать чужие.
Мне очень нравится ваша идея в таком виде.
Только кубернетисы, конечно, для этого не подойдут, а подойдёт какой-нибудь heroku-подобный serverless контейнер. Я не смотрел в эту сторону раньше, не знаю, существуют ли такие, или нужно будет писать своё.
И надо будет немножко повозиться с определением эквивалента мощности. Плюс понадобятся некие централизованные ресурсы для сведения баланса, пробития NAT, распределения лямбд по контейнерам, ну и для организационных целей. Тут можно будет просто продавать часть ресурсов за деньги при необходимости. Лучше оформить это как нон-профит, при этом нужен будет ещё какой-то свой сервис, чтобы автоматически публиковать бюджет. Как-то так.
https://github.com/BOINC/boinc не оно?
Карл Маркс и Фридрих Энгельс -- это не муж и жена, а четыре совершенно разных человека.