1.8, Аноним (8), 04:50, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
> Осуществлён переход c autotools на сборочную систему Meson
Почему на этот любительский треш без документации (точнее - с документацией за деньги, во как) вместо стандартного CMake? Они любят трудности и неудобства?
| |
|
|
3.26, Аноним (26), 10:24, 18/06/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
Отстойная хрень - это мезон, ибо не умеет в автопакетировагие и автоматический поиск зависимостей в системе. Всё ручками кодить нужно вместо использования батареек. Ещё более отстойная хрень - это autotools.
| |
|
4.29, llolik (ok), 11:57, 18/06/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
> не умеет в автопакетировагие
Не очень и нужно, для системы сборки, как-минимум. Не сказать что cpack сильно гибкий. В meson есть поддержка install_script, что позволяет писать скрипты пакетирования и запускать их после установки. Т.е. префиксом инсталлируешь в нужный каталог и автоматом запускаешь указанный скрипт, который уже пакетит как ты там напишешь.
> автоматический поиск зависимостей в системе
цитируя документацию
Dependency detection method
You can use the keyword method to let Meson know what method to use when searching for the dependency. The default value is auto. Additional methods are pkg-config, config-tool, cmake, builtin, system, sysconfig, qmake, extraframework and dub.
Мало? В том числе, как написано, можно использовать и систему поиска cmake, если он установлен, конечно.
Вообще, meson и не пытается доминировать. Он может использовать систему поиска пакетов cmake, можно использовать проекты cmake, как сабпроджекты (пробовал, работает и конвертирует успешно, местами ценой небольшой правки специфических мест).
> Всё ручками кодить нужно вместо использования батареек
Ну не знаю. Пробовал на одних и тех же собственных пет-проектах и cmake и meson. Получается ± одинаково, но meson читать и понимать проще.
| |
4.60, anonymous (??), 17:30, 20/06/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
> не умеет в автопакетировагие
О, ужас! Микроскоп не умеет закручивать саморезы.
| |
|
|
|
|
2.12, n00by (ok), 07:07, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Разработчики Calculate Linux представили новый дистрибутив Calculate Container Desktop Xfce, предназначенный для запуска рабочего стола в LXC-контейнере.
... на одном ПК можно организовать несколько рабочих мест, распределив ресурсы компьютера между ними. Образ
https://opennet.ru/48279-lxc
Позже отказались от такой экономии на железе, если правильно помню, из-за каких-то проблем с LXC.
| |
|
3.14, Аноним (15), 07:11, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Сантехник Иванов ремонтировал кухонный смеситель прессом на 500 тон. Что-то пошло не так)
Вот так и разработчики кальки.
| |
|
2.13, Аноним (15), 07:09, 18/06/2022 [^] [^^] [^^^] [ответить]
| +6 +/– |
LXC и Docker как гребля и бокс. И то, и другое спорт, но такой разный.
| |
2.17, Роман (??), 07:35, 18/06/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Всё еще бывает нужда представить изолированное окружение схожее с полноценной системой (условно виртуалку) и управлять этим соответственно из такой парадигмы (например бэкапы целиком, выдаление cpu/ram/disk size) - этакие легкие виртуалки (VE в терминах OpenVZ). Скорее всего почти всё можно сделать и через набор docker compose + swarm, но уйдет больше времени.
| |
|
3.24, Stanislavvv (?), 09:56, 18/06/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт на полчаса-час больше, но есть нюанс: сеть в lxc и docker устроена по-разному, отчего может быть больно. Но вообще - для lxc-подобного со своими (не заранее подготовленными) образами проще использовать голый runc, возможно даже частично выключив изоляцию, если это приемлемо.
| |
|
4.50, Роман (??), 02:14, 19/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Я конечно больше про LXD, чем про голый LXC.
> Делал подобное в докере (для запуска в имеющемся сварме). На запуск уйдёт
> на полчаса-час больше,
Не думаю что это оценка для вообще всех случаев справедлива. Для каких-то конкретных может быть, но там вероятно и вообще тогда VE/VM парадигма лишняя by design.
>но есть нюанс: сеть в lxc и docker
> устроена по-разному, отчего может быть больно.
Не уверен про macvlan, но dhcp/routed было бы странно заводить на докере вообще. Поведение Сети там для разных сценариев задумана.
>Но вообще - для lxc-подобного
> со своими (не заранее подготовленными) образами проще использовать голый runc, возможно
> даже частично выключив изоляцию, если это приемлемо.
Тут мысль не понял, раскроете? Особенно про изоляцию - зачем её отключать если половина задачи в изоляции и есть, вторая половина в управлении.
| |
|
|
2.23, microcoder (ok), 09:53, 18/06/2022 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Кто-нибудь это использует?
Да.
> Почему выбрали это, а не докер?
1. Докер это контейнеризация приложений (один докер = одно приложение), а LXC контейнеризация целого специального дистрибутива.
2. Докер слишком сложен, нагружен и не гибок. LXC - ничего лишнего. :)
| |
|
|
4.57, qrKot (?), 08:04, 20/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
более того, в подавляющем количестве случаев именно что без него и работает. Это канониклы, а в убунте apparmor, нету нам SELinux
| |
|
|
2.28, Аноним (28), 11:49, 18/06/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
В docker нельзя поменять ограничения IO для уже созданного контейнера, у lxc это просто config файл.
| |
|
3.38, Аноним (38), 17:23, 18/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да даже то что до докер под крылом частной компании это уже плохо и не свободно. Хотя LXC из под крыла Каноникла ни чем не лучше.
| |
|
|
5.43, Аноним (38), 18:43, 18/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.
| |
|
6.46, llolik (ok), 19:21, 18/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это путаешь квадратное и птицей. Каноникл единственный спонсор linux container project.
Оказывается да, я не прав. Всегда знал, что LXD Canonical нагородили поверх LXC, но не знал, что LXC - это тоже их разработка.
| |
|
|
|
|
2.61, anonymous (??), 17:32, 20/06/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Это скорее альтернатива openvz, фряшечным джейлам и солярочным зонам, чем докеру.
| |
|
|
|
3.35, Аноним (38), 16:47, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Нужный велосипед, который решает архитектурную проблемы всего этого вашего Лин-у-пса.
| |
|
|
5.58, qrKot (?), 08:06, 20/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
конечно работает, это канониклы, нету у них SELinux
В целом зависимости: cgroups, namespaces
| |
|
6.59, Аноним (30), 14:33, 20/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Хорошо.
>канониклы
Ни о чём не говорит, а может быть даже минус: GTK4, systemd, продолжать не буду.
| |
|
7.66, qrKot (?), 15:25, 12/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Хорошо.
>>канониклы
> Ни о чём не говорит, а может быть даже минус: GTK4, systemd,
> продолжать не буду.
Переформулируйте, пожалуйста, я ничего не понял. При чем тут минус, ГТК4 и системД.
Чуть-чуть пояснений: Канониклы - это Canonical, разработчики Ubuntu. В Ubuntu и Debian'е SELinux нет, там AppArmor, т.е. SELinux'а в зависимостях LXC5.0, разрабатываемого изначально на дистрибутиве без SELinux'а однозначно нет. Я об этом говорил.
Кстати, GTK4 и systemd в зависимостях тоже не числится, если вы об этом. Тащить графический тулкит в зависимости консольной управлялке контейнерной изоляцией никто не будет, а systemd, в целом, происходящему ортогональна.
| |
|
|
|
|
|
|
1.34, Аноним (38), 16:46, 18/06/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Лучше бы сразу придумали как в NixOS или придумали что-то своё. Если бы линукс не тырил структуру приложение из Unix, а придумал что-то своё всем было был лучше. И не нужны были бы всё это контейнеры в докере в виртуалке в гипервизорве в облаке.
| |
|
2.36, Аноним (36), 17:12, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
NixOS был бы номер один, если бы не пытался через свой велосипед рулить конфигами ПО. Тем более не всё настроики можно через этот велосипед сделать. Приходится и там, и в стандартных конфигах ПО вносить корректировки. Тот ещё зоопарк.
| |
|
3.37, Аноним (38), 17:20, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Для того чтобы это сделать было достаточно чьей то воли ли наоборот воли так не делать. Можно же было сделать по человечески.
| |
3.41, Аноним (49), 18:20, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Не понял, в чём проблема с конфигами у тебя. Никто не заставляет никсом конфиги генерировать. Положил файл рядом с кодом, сослался на него, дальше никс сам всё сделает. Мало файла — сделай шаблон. Мало шаблонов — целая система сборки под рукой, можно хоть джигу станцевать, хоть из другой репы взять нужные файлы и разложить куда надо. Без Никсоса ты чем конфиги по серверам раскидываешь? Ансиблом-паппетом-шефом? Или как локалхостный васян, вручную правишь по ssh?
| |
|
4.48, Анончик (?), 23:34, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
>> Или как локалхостный васян, вручную правишь по ssh?
Зачем на локалхосте вручную править конфиги по ssh?
Или у настоящего админа все должно быть по сети, даже секс?
| |
4.52, Аноним (36), 04:53, 19/06/2022 [^] [^^] [^^^] [ответить] | +/– | Ты не понял, пакетный менеджер не должен рулить конфигами ПО Собрали пакет, пол... большой текст свёрнут, показать | |
|
|
2.39, Аноним (39), 17:26, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Контейнеры это не только пространства имён файловой системы, есть ещё сеть, CPU, ввод-вывод, память, NixOS собирающий пакеты в разных каталогах с этим не поможет.
| |
|
3.42, Аноним (38), 18:40, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Так и штатными инструментами ос можно ограничивать ресурсы тем же cpulimit но сделать всё это правильно или хотя бы удобно было бы совсем не лишним.
| |
|
4.63, Аноним (63), 19:00, 20/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Можно, именно это и делают системы контейнеризации docker, lxc и т.п., в NixOS ничего этого нет.
| |
4.65, Oxyd76 (?), 11:01, 25/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Всё это уж сто лет как встроено в systemd (cgroups, namespaces, capablities - основа основ systemd). А для таких вот изолированных "контейнеров" есть systemd-nspawn и система сборки образов "уровня ОС" (с почти любым произвольным дистром и инит системой внутре) mkosi для него . Никаких сторонних зависимостей типа runc. А приложеньку, как в дохере, вообще одной командой можно в контейнер упихуять, с пробросом сетевизмов и этим вот всем. На гитхабе даже кубер c nspawn контейнерами в бэке делали https://github.com/kinvolk/kube-spawn.
| |
|
3.44, Аноним (44), 18:48, 18/06/2022 [^] [^^] [^^^] [ответить]
| +/– |
Пространства имён и прочее реализованы в ядре. Что осталось, так это именно собрать root fs.
| |
|
|
1.51, Ддд (?), 03:33, 19/06/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Lxc это изолированный кусок ОС как zones в солярке. Выглядит как виртуалка куда можно зайти и выйти. Хорошая штука для девопса
| |
|