потому что у меня перменные в нем

ну то есть они и там и сям

у меня один проект — одно приложение

оно само состоит из 4-5 билд-конфигураций

которые наследуют переменные от папы

сделай проект Apps, у него подпроекты по приложениям

в Apps добавь глобальные переменные

в подпроектах их переопредели

в конфигурации тоже потом можешь

они наследуются же

типа тройной уровень вложенности будет?

типа того

а так чо можно штоле?

да

точно, можно

спасибо, няша

позязя

Ребят, вот вы тут умные, расскажите мне что я получу от перехода с sysV на systemd кроме огромной пачки критических багов в дополнение к уже существующим в баше, а так же сомнительной замены dhcpd.

Ребят, вот вы тут умные, расскажите мне что я получу от перехода с sysV на systemd кроме огромной пачки критических багов в дополнение к уже существующим в баше, а так же сомнительной замены dhcpd.

зависимости между сервисами

в некоторых случаях это реальне удобно

возмноность задавать новые вопросы 😆

sysV - а он где-то остался в чистом виде?

Олсо, за простотой юнитов скрывается их топорность и некастомизируемостью

sysV - а он где-то остался в чистом виде?

Дебьян до джесси?

Олсо, за простотой юнитов скрывается их топорность и некастомизируемостью

эм, Я бы сказал, что в некотором роде они намного более удобны в кастомизации

зависимости между сервисами

А разве systemV не умеет?

А разве systemV не умеет?

по умолчанию нет, разве в openrc это нормально сделано

ну а смысл на джесси переходить на системд?

эм, Я бы сказал, что в некотором роде они намного более удобны в кастомизации

Я где-то видел ребят, которым чтобы правильно описать старт сервиса пришлось написать 4 зависимых юнита

и да, systemd создавался в первую очередь для десктопов, где система инициализации должна реагировать на изменения

по умолчанию нет, разве в openrc это нормально сделано

Более тысячи серверов работают с sysV и не испытывают проблем

с серверами все намного проще, и systemd на серверах имеет меньше преимущество

для десктопов и лаптопов, во

и да, systemd создавался в первую очередь для десктопов, где система инициализации должна реагировать на изменения

К сожалению мейнтейнеры Debian думают иначе. Да и не только Debian

redhat жи

я увёл свой рабочий sandbox в stretch/sid

и прочите systemd

много странного

помоимо переименованных сетевых интерфейсов огрёб ещё массу интересного

ну а смысл на джесси переходить на системд?

Потому что адепты системд втихаря, роняя кал и не советуясь с сообществом принесли это говно в апстрим и жёстко забиндились на него

помоимо переименованных сетевых интерфейсов огрёб ещё массу интересного

это что такое ?

да, и после последнего update у меня отвалился sddm на старой nvidia

ну есть смысл на свежих системах, там где системд уже бай десинг

и то

помоимо переименованных сетевых интерфейсов огрёб ещё массу интересного

это к udev, systemd тут постольку-поскольку

Ребят, вот вы тут умные, расскажите мне что я получу от перехода с sysV на systemd кроме огромной пачки критических багов в дополнение к уже существующим в баше, а так же сомнительной замены dhcpd.

Вторую пачку критических багов в подарок

про переименование

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:23:54:5e:65:4a brd ff:ff:ff:ff:ff:ff inet 172.31.8.20/24 brd 172.31.8.255 scope global dynamic enp2s0 valid_lft 583545sec preferred_lft 583545sec inet6 fe80::223:54ff:fe5e:654a/64 scope link valid_lft forever preferred_lft forever 3: enp4s1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:02:b3:26:a2:1d brd ff:ff:ff:ff:ff:ff 4: enp4s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:a9:40:0f:91:ef brd ff:ff:ff:ff:ff:ff

а это вот так

так это же biosdevname

помоимо переименованных сетевых интерфейсов огрёб ещё массу интересного

Ну тут не совсем системд виноват. Сетевые интерфейсы то ли удев, то ли ядро переименовывают

сетевые интерфейсы да это к udev

всем миром решали что так только лучше

это к udev, systemd тут постольку-поскольку

Это к системд потому что udev часть

лично мне eth0 больше как-то было по душе

и предсказуемо

помоему там ситуация такая же как монтирование по имени \ uuid

есть удев udev не с системд)

ну всмысле обоснование

есть удев udev не с системд)

Нету.

потом я как-то привык к /etc/network/interfaces

То есть можешь оторвать конечно

но и это отломали

Но они часть единого целого

рилиЮ

?

но и это отломали

да ладно отломали? оно работает в systemd збс.

Володя прав.

https://github.com/gentoo/eudev

?

Системд всосал в себя udev

ну да это у нас в генте)

https://github.com/gentoo/eudev

Это форк системдшного удева

да

ну сугубо оно не часть системд

Форк != Оригинал

просто уже давно разработка самого удева идет вплотную с системд как его часть

это, если не через networkd

# systemctl status systemd-networkd.service ● systemd-networkd.service - Network Service Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2016-10-17 13:18:10 MSK; 1 day 5h ago Docs: man:systemd-networkd.service(8) Main PID: 461 (systemd-network) Status: "Processing requests..." Tasks: 1 (limit: 4915) CGroup: /system.slice/systemd-networkd.service └─461 /lib/systemd/systemd-networkd Oct 17 13:18:10 zero systemd[1]: Starting Network Service... Oct 17 13:18:10 zero systemd-networkd[461]: Enumeration completed Oct 17 13:18:10 zero systemd[1]: Started Network Service. Oct 17 13:18:10 zero systemd-networkd[461]: enp2s0: IPv6 enabled for interface: Success Oct 17 13:18:12 zero systemd-networkd[461]: enp2s0: Gained carrier Oct 17 13:18:13 zero systemd-networkd[461]: enp2s0: Gained IPv6LL Oct 17 13:18:13 zero systemd-networkd[461]: enp2s0: DHCPv4 address 172.31.8.20/24 via 172.31.8.1 Oct 17 13:18:26 zero systemd-networkd[461]: enp2s0: Configured

ну так никто не мешает не использовать networkd. кстати, имхо, он довольно убог.

когда там уже kerneld