AD
Проект просто перестал обновляться
rkt командной CoreOS делался как часть ее, потому и перестал обновляться
Size: a a a
2020 November 11
AO
Alex Demidov
rkt командной CoreOS делался как часть ее, потому и перестал обновляться
Они его выделили отдельно во время покупки
AO
То есть rkt мог бы развиваться если бы был интересен как проект
AO
Но он не был интересен, появился podman, он был интереснее
AD
Они его выделили отдельно во время покупки
выделили чтобы задницы не подорвались сразу, только результат тот же
AO
Podman умеет запускать деплойменты, в совместимом с K8s виде то есть работает
AO
То есть различие с K8s по входным данным меньше, с Podman’ом в итоге проще работать, а K8s стал отраслевым стандартом. Плюс там API сделали
AO
rkt был в этом смысле менее интересным, он был способом выбрать «что угодно только не Docker», некий «протестный кандидат», единственный плюс которого - альтернатива основному тогда Docker’у
AO
С podman’ом можно было бы отказаться от создания docker-compose.yaml в пользу deployment.yaml и прочего, то есть пишешь сразу под K8s и оно работает на Podman, обойтись без дублирования то есть
AO
Alex Demidov
выделили чтобы задницы не подорвались сразу, только результат тот же
У Core OS был опыт с Tectonic (managed Kubernetes от Core OS), они его взяли к себе в OpenShift
AL
Если разработчик не заинтересован, чтобы его продукт попал на системы, то что поделать
Разработчик один, а систем множество и они все различны. Допустим. Разработчик выпустил программу Ч, у которой в зависимостях библиотека Л.версии1, Д.версии2. В одном дистрибутиве есть Л.версия1 и Д.версии6. В другом Л.версии2 и нет Д.версии2. Как тогда быть? Все тащить с собой?
MK
Я знаю про эту проблему
MK
Но я также знаю, что очень мало дистрибутивов в целом поставляют го библиотеки в качестве отдельных пакетов
MK
В nix/guix, flatpak/snap всё собственно и тащится с собой
MK
И за это этот подход критикуют
AO
В nix/guix, flatpak/snap всё собственно и тащится с собой
Получается, что это правильный способ? В итоге
AD
rkt был в этом смысле менее интересным, он был способом выбрать «что угодно только не Docker», некий «протестный кандидат», единственный плюс которого - альтернатива основному тогда Docker’у
rkt был альтернативой монолитному комбайну docker работающему от root'а.
AO
Получается, что это правильный способ? В итоге
Но в чем очарование Debian’а тогда?
MK
Получается, что это правильный способ? В итоге
Это просто иной способ. То есть, да можно иметь кучу версий разных библиотек на одной системы, но нужно ли. В большинстве дистрибутивов фикс на одной, что собственно накладывает ограничения для разработчиков, но система в таком случае более целостна, так как реиспользует имеющиеся ресурсы
AO
Alex Demidov
rkt был альтернативой монолитному комбайну docker работающему от root'а.
Да, некий «протестный кандидат» по аналогии с «умным голосованием»