Сообщение Re[3]: Про докер итд - надоело кругами ходить. от 21.05.2020 10:43
Изменено 21.05.2020 11:14 Явь-истъ
Re[3]: Про докер итд - надоело кругами ходить.
Здравствуйте, Zhendos, Вы писали:
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Ну да, у snap все печально, но chromium теперь доступен только в виде snap-пакета https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
И в остальных snap пакетах обычно программы более свежие.
Или вот игры часто поставляются на windows и с DirectX, и с microsoft SDK, это решение лучше — требовать установки системных библиотек вместо того, чтобы их взять все с собой? Java вот тоже, потребляет ресурсов больше, чем С++, но ведь множество проектов все таки выбрали именно Java? Дополнительный уровень абстракции всегда появляется в ответ на увеличение сложности нижележащих уровней.
Серебряной пули, как говорится, нет, все новое не обязательно по всем параметрам лучше, но и полностью отвергать нововведения будет неверным.
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Ну да, у snap все печально, но chromium теперь доступен только в виде snap-пакета https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
И в остальных snap пакетах обычно программы более свежие.
Или вот игры часто поставляются на windows и с DirectX, и с microsoft SDK, это решение лучше — требовать установки системных библиотек вместо того, чтобы их взять все с собой? Java вот тоже, потребляет ресурсов больше, чем С++, но ведь множество проектов все таки выбрали именно Java? Дополнительный уровень абстракции всегда появляется в ответ на увеличение сложности нижележащих уровней.
Серебряной пули, как говорится, нет, все новое не обязательно по всем параметрам лучше, но и полностью отвергать нововведения будет неверным.
Re[3]: Про докер итд - надоело кругами ходить.
Здравствуйте, Zhendos, Вы писали:
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Ну да, у snap все "печально", но chromium теперь доступен только в виде snap-пакета https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
И в остальных snap пакетах обычно программы более свежие.
Или вот игры часто поставляются на windows и с DirectX, и с microsoft SDK, это решение лучше — требовать установки системных библиотек вместо того, чтобы их взять все с собой? Java вот тоже, потребляет ресурсов больше, чем С++, но ведь множество проектов все таки выбрали именно Java? Дополнительный уровень абстракции всегда появляется в ответ на увеличение сложности нижележащих уровней.
Серебряной пули, как говорится, нет, все новое не обязательно по всем параметрам лучше, но и полностью отвергать нововведения будет неверным.
Z>Инструмент конечно не может быть плохим или хорошим. Но очевидно что у каждого использования
Z>инструмента для решения задачи есть преимущества и недостатки. И недостатки контейнеров очевидны:
Z>1. повышенное потребление памяти, эти ведь разные версии библиотек/интерпретаторов/виртуальных машин не святым
Z> воздухом питаются и тратят и кэш на самом диске и ОЗУ которую использует ОС для кэширования I/O и
Z> кэши инструкций процессора и т.п.. У snap вообще все печально, насколько я знаю,
Z> там даже одинаковые версии библиотек не разделяются, потому что нет фичи аналогичной "послойной" ФС в
Z> docker. Иначе сложно объяснить почему калькулятор так долго стартует (одно из первых snapd приложений в Ubuntu)
Z>2. сложность внесения критичных исправлений, например исправление уязвимостей.
Ну да, у snap все "печально", но chromium теперь доступен только в виде snap-пакета https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
И в остальных snap пакетах обычно программы более свежие.
Или вот игры часто поставляются на windows и с DirectX, и с microsoft SDK, это решение лучше — требовать установки системных библиотек вместо того, чтобы их взять все с собой? Java вот тоже, потребляет ресурсов больше, чем С++, но ведь множество проектов все таки выбрали именно Java? Дополнительный уровень абстракции всегда появляется в ответ на увеличение сложности нижележащих уровней.
Серебряной пули, как говорится, нет, все новое не обязательно по всем параметрам лучше, но и полностью отвергать нововведения будет неверным.