Георг Гаал

https://www.freedesktop.org/software/systemd/man/s...

systemd-run — Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units

--pty, -t

When invoking the command, the transient service connects its standard input, output and error to the terminal systemd-run is invoked on, via a pseudo TTY device. This allows running programs that expect interactive user input/output as services, such as interactive command shells.

Типичные примеры использования:

JPG — фото, иллюстрации без прозрачности, где важны цвета, переходы, оттенки и т. п. В таком случае JPG выигрывает у других форматов в плане соотношения качество/цветность/размер. Так себе для контрастных схем и текстов.

PNG — фотографии, схемы, графические элементы с прозрачностью, всякие вылетающие за границы элементы, где относительно много цветов (фото людей, инопланетян и т. п.). При соотносимом с JPG размере файла, PNG содержит гораздо меньше цветов, а сравнимые с JPG по количеству цветов файлы PNG будут весить очень много (поэтому для фото используют JPG). Если дело доходит до схем и текстов, PNG предпочтительнее JPG в силу отсутствия артефактов на контрастных краях.

GIF — анимации. Ну тут вообще отдельная песня. Ему на смену пророчат APNG и MP4, но воз и ныне там.

SVG — иконки, иллюстрации. Поддерживает прозрачность, бесконечно тянется. Обычно те же иконки в SVG весят меньше, чем в PNG при одинаковом фактическом размере использования. Можно анимировать (отдельная тема и куча особенностей) и управлять с помощью CSS и JS, если встраивать inline (можно и через #use, но с ограничениями). Наверное, самый чувствительный к ошибкам формат, потому что состоит из кода: сложный SVG-файл может убить производительность. Можно очень легко зашить вредоносный код, поэтому запрещён в вёрстке писем.

P. S. Я не могу описать все случаи, бывают уникальные, так как процесс выбора формата зависит от контента вашего изображения. В каждом конкретном нетипичном случае — думайте сами. К примеру, если векторная иллюстрация весит много, то есть смысл перевести её в JPG или PNG. Иногда SVG-иконка может весить в разы больше её PNG-аналога (при одинаковом фактическом размере использования, например, 100 на 100 пикселей при 1:1 размере viewport к физическому разрешению экрана) — тут многое зависит от методов и качества создания таких иконок. Как правильно отметил @Adamosу, иногда затраты на рендеринг SVG (на стороне клиента) не окупают его преимуществ, и приходится использовать растровые изображения. Ну и т. д… Особенностей использования форматов — куча.

P. P. S. Почитайте о Retina, ибо нет никакого «для ретины следует юзать JPG».

Суть в том, что PV - статические сущности.
PV создаются вручную и отражают максимальный физический объём, который могут предоставить(на самом деле - сколько администратор решил предоставлять).
PVC - это по сути запрос на предоставление PV. Kubernetes попытается найти такой PV, который подойдёт к указанным параметрам - в вашем случае, он будет искать свободный PV с размером 20Gi или больше. Как только такой будет найден, будет создана связка PV-PVC - т.е. пока действует Claim, другие поды не смогут запросить этот же PV.

Однако, несколько под могут использовать один и тот же PVC.

storageclass.storage.k8s.io "persistent-data" not found

Возможно, вы не создали StorageClass с таким именем

Используем LXC-контейнеры уже несколько лет в составе Proxmox, никаких серьёзных проблем ни разу не возникало. Сырость технологии проявляла себя крайне недолго, буквально до первого апдейта платформы после изменения в Proxmox технологии контейнеров с OpenVZ на LXC.

Почему в 2018 году OpenVZ-хостинги распространены шире - затрудняюсь ответить, видимо владельцы купили лицензию у Виртуоззо и теперь залочились на этом старье :)

LXC удобно использовать для отвязки от ОС хоста, как современный аналог OpenVZ (OpenVZ устарел, т.к. не поддерживается новыми ядрами и дистрибутивами). Мы использовали LXC для виртуализации Linux сервисов. LXC значительно эффективнее расходует ресурсы, чем KVM.
LXC внутри больше похож на виртуальную машину, чем Docker. В LXC почти все привычные инструменты работают как обычно. Но изолированно от хост системы. Можно ставить пакеты, менять настройки etc, запускать демоны и использовать стандартные инструменты Linux среды и т.д. Для LXC можно подтянуть специфичные для дистрибутивов шаблоны. Например, на хосте с Ubuntu поднять гостя с Centos. При желании гостя можно держать на виртуальном диске.

Еще про разницу между LXC и docker написано тут: https://vps.ua/blog/docker-and-linux-containers/

import os
os.system('"C:/Windows/System32/notepad.exe"')

или

import subprocess
subprocess.call('C:/Windows/System32/notepad.exe')

Лень печатать, почитайте сами:

Можно, если установить вторую видеокарту или заменить имеющуюся на другую, с двумя аналоговыми выходами. Одними проводами это не решается.

повторю свой ответ на предыдущий ваш вопрос. Настраивайте роутинг и маскарад. В этом случае вам нужен source routing, без особых извращений - либо микротик, либо опенврт....

у вас на порту в д-линке должен быть tagged, а на порту 5 в Микроте untagged. и на Микроте VLAN, который вы хотите подружить с некой сетью, должен быть в том же бридже. ну а потом уже маршруты.

Рекомендую серию данных книг. Мне они раньше очень помогли.

kubectl --namespace=efk exec -it efk-fluent-bit-58vn5 -- /bin/bash
root@efk-fluent-bit-58vn5:/var/log/containers# ls | grep db-master
root@efk-fluent-bit-58vn5:/var/log/containers#

зашел в fluentd - а там лога нет.