Плохо читал.

• mount namespace — личный /dev, в котором есть только тривиальные устройства (директива PrivateDevices=)
• capability bounding set — единожды убранное вернуть нельзя (та же директива, или CapabilityBoundingSet= для точного управления)
• свойства devices.allow и devices.deny в соответствующем контроллере цгруппы процесса (та же директива, или DevicePolicy=/DeviceAllow= для точного управления

видимо он имел в виду это:

За разработку общей теории операционных систем и в частности за создание Unix

Винда + андроид. В жизнеспособности этих ОС в ближайшее время есть некоторая уверенность, а привязываться к умирающей системе считаю опасным. Пока существовали олдскульные бородатые одмины, для которых были важны принципы Unix, я понимал, кто будет ядром пользователей и драйвером развития. А кому будет нужно то, чем линукс станет в ближайшее время, я не знаю и представить себе не могу. Линукс теряет принципы и выходит на поляну винды. Чем это заканчивается расскажет история ОС/2

ну дак что?

как всегда одно бла-бла-бла?

где саксесс стори о крутости системг для мультисета?

Захочешь — сам найдёшь. В списке рассылки есть несколько. Я не подписывался тебя развлекать.

Тема разжевана вдоль и поперек, это верно.
И то, что ни один ответ на вопрос «зачем?» не является удовлетворительным - так же верно.
Ни одна из заявленных целей systemd не достигнута.
Грузится медленно. А должен был бы быстро. Помнится мне обсуждению этой мегафичи было посвящено немеряное количество человекочасов.
Да если бы даже и быстро - где этот юзкейс при котором требуются молниеносные постоянные ребуты?
Журнал не журналирует. Приведенные тут ссылки в которых аргументируется его нужность доставляют отдельное удовольствие от прочтения.
Мультисит решения стали даже сложнее и ничуть не секурней, чем прежде.
Собственный велосипед для синхронизации времени - это (очередной) вин. Неосиляторство стандартных утилит иллюстрейтед.
Список можно продолжить.
Смысл?

ЛП внедрился везде и всюду исключительно потому, что звезды так сошлись, а не потому что он мегапейсатель.
Какие звезды?
1. Запрос на «настоящий» мультисит искаропки. Чтобы как у взрослой ОС, которую мы тут не обсуждаем.
2. ДЕ (Гном и КДЕ имеются в виду) фапали на ОЛЕ, КОМ и КОРБУ, лабали свои околотогоподелия, пока не обнаружили, что есть такая штука, как дибас. «Ага!» сказали сибирские мужики. И все заверте...
Так произошло потому что десктопопрограммеры так или иначе хотя бы каким-то боком из мира виндовс. И что бы ни говорили, а винда это законодатель мод в этой сфере.
Поэтому, кстати, Иказу в свое время соблазнил ДотНет и он в порыве страсти запилил моно. Но это другая история.
Отсутствие стандартов.
Дибас выступил в качестве эрзац-замены стандарта обмена данными.
3. Торвальдс был возмущен тем фактом, что для коррекции часов в гноме ему потребовалось выдать права суперпользователя своей дочери.
Короче.
Факторов 1, 2 и 3 хватило для того, чтобы дибас стал нужен по-умолчанию, в списке задач постоянно висел сонсолекит и... И все это были временные решения, заглушки, которыми заткнули дыры прямо перед тем как должно было быть запилено «правильное решение». Время шло. Правильное решение не пилилось. Ну потому что у всех, у кого руки произрастали из около головы работало все, в чем они нуждались и им было элементарно лень и непонятно нафига. Прочим было по большому счету по барабану.
Но консолекит раздражал. Постоянно болтающийся в списке задач длинный список консолекитов вызывал недоумение и вопросы любопытствующих ковырятелей. В конце концов красношапка нашла человека, который взял на себя смелость расчистить авгиевы конюшни и запилить «правильное решение».
Ту би континюед

Винда + андроид. В жизнеспособности этих ОС в ближайшее время есть некоторая уверенность, а привязываться к умирающей системе считаю опасным.

Странно об этом думать, а ведь именно «умирающий линукс» стал ядром для андроида.

[sarcasm]Эх, а уже привыкать стал, думал убью в себе виндовые привычки, стану свободным и честным юзером. А теперь вот оно как оказывается, линукс умирает[/sarcasm]

есть ещё BSD

журнал для этого не нужен

ух ты как категорично :) Если у товарища все до журнал-г работало, он удивляется как так инновации и нанотехнологии журнал-г не могут нормально решать то, что решалось десятилетиями... и понять его можно :)

по поводу advantages

1)2) хрень какая-то детсадовская. Хочешь секьюрные логи - складируй их на отдельном защищенном сервере. Этому решению не одно десятилетие и как уж Красношапка его забыла... или не забыла ;)

«On all Red Hat Enterprise Linux 7 machines, syslog will still be on by default»

упс...

а локальный лог я просто удалю... и ищи потом хвосты...

ты лжец!

их нет.

есть ещё BSD

Я слишком маленький-молодой для BSD Её не на всякое железо поставишь, имеется какое-то недоверие к ZFS/UFS и мне неизвестно, как там с драйверами в общем.

Её не на всякое железо поставишь

i686 и amd64 точно поддерживаются :)

Я не об архитектурах.

Вебки, принтеры, всякие там затычки новомодные на USB, мультимедиа-клавиатуры и мыши тебе знакомы? Воот. Надеюсь дошло :)

какие-то сомнительные фичи

есть же SELinux и apparmor, с их помощью вполне можно было бы те же самые ограничения накладывать

«Сомнительные» — не аргумент. Фичи есть, стало быть, твоё утверждение я опроверг.

есть же SELinux и apparmor

Ну и зачем они нужны в этом месте, когда этого можно достичь средствами одного лишь ядра?

компетенция шапки вызывает большие сомнения...

дойдет дело до оракула еще будет веселее

андроид неудачный кейс использования ядра линукса и вина в этом в большей степени ядра...

что-то подумалось, а ведь ядро то голое!

Куча паршивых проблем: видео, acpi, управление процессами, распухание а следовательно и рост сложности, поддержка железа, звук, многозадачность, производительность фс, блобы, необходимость перезагрузок, легкость зависаний, перегруженность разработчиков, сложности отладки и разработки, снижение качества. На этой благодатной почве и произрастают системди-паразиты...

Куча паршивых проблем: видео, acpi, управление процессами, распухание а следовательно и рост сложности, поддержка железа, звук, многозадачность, производительность фс, блобы, необходимость перезагрузок, легкость зависаний, перегруженность разработчиков, сложности отладки и разработки, снижение качества. На этой благодатной почве и произрастают системди-паразиты...

И это всё нам знакомо из-за открытости Linux. Получается, что он стал жертвой собственной открытости. В Windows/OS X наверняка тоже также, только это всё хорошо скрыто и более-менее отлажено.

В который раз глаз зацепился за тему, но в этот раз прочитал как «Фатальные тезисы...» и я с этим согласен.

закрытый не выжил бы вообще

суть линукса в том то Линус выложил свое творение на общее обозрение без жмотства и без особых претензий в открытую. Без этого он сидел бы в своей родине и писал бы никому неизвестную и ненужную национальную ось...

Ну и зачем они нужны в этом месте, когда этого можно достичь средствами одного лишь ядра?

а selinux и apparmor как будто не в ядре находятся

Требуют особой юзерспейсной поддержки, ЕМНИП. Впрочем, даже если таки ИП, то введение любой альтернативной модели безопасности будет значительно более интрузивно, чем выполнение нескольких bind-mount'ов и стольких же системных вызовов.

Скажем так: для использования selinux и apparmor дистрибутив должен быть selinux- или apparmor-ready, а вот это сработает везде при условии достаточно свежего ядра. Просто легче и удобнее. Тем более что пространства имён специально были придуманы для изоляции.

Требуют особой юзерспейсной поддержки, ЕМНИП.

А в случае cgroups ядро само догадывается, у какого процесса какие capabilities отобрать и какие девайсы скрыть, или таки ему этот ваш системдэ указывает? В чём разница?

Скажем так: для использования selinux и apparmor дистрибутив должен быть selinux- или apparmor-ready,

Redhat много лет уже как selinux-ready и достаточно свежее ядро ему для этого не нужно. Ещё генточка. Насчёт аппармора точно не знаю, вроде SuSe его изкоробки умеет

или таки ему этот ваш системдэ указывает? В чём разница?

Второе. А разница в количестве действий, которые необходимо совершить.

Redhat ... гентока ... SuSe

И зачем ты мне приводишь конкретные примеры и частные случаи? Есть два метода, один работает везде, другой — не везде и требует специальной настройки. Очевидно, что первый предпочтительнее.

ЕМНИП в iptables такая фича раньше была, но ее выпилили по какой-то причине

machined
Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6)

Не, ну это всё понятно, но зачем всё это говно тащить в один демон? Вроде и ничего, но возникает ощущение, будто тебя хотят калом накормить насильно.

но зачем всё это говно тащить в один демон

Чё не ясно? Леннарт пилит свою ОСь с блэкджеком и шлюхами.
Вот допилит всё окружение и примется за ядро.

Посоны, расходимся... это не наши (с)

GNOME Foundation запускает программу Outreachy

все вопросы, откуда повылезали эти воинствующие ситемг-фанбои сняты...

я то еще думаю, что у этих фанатов системг все время какие-то извращения и нетрадиционные подходы в почете... все покровы сорваны...

тьфу ты...

Как ни странно,

но Ваш собеседник прав. Пока было следование тем самым принципам UNIX, ни кто не мог подложить свинью сообществу.

Хотите примеров? Извольте. Ни кого не волновала скорость загрузки системы. Но апологеты systemd уверяли что вот-вот скорость офигенно увеличится. На деле упала. Не мерял, не интересно в секундах, но на глаз заметно.

Апологеты уверяли что дескать будет единая система инициализации и всем станет хорошо. На деле это возможно только если мы развёртываем N схожих машин с M схожими сервисами. Тот же spacewalk от RH позволял это делать на счёт раз. Если кому нужно было. Все остальные случаи от локалхоста и больше машин под вопросом.

Трудоёмкость написания демонов возрасла. Вместо простого как 3 коп. скрипта теперь извольте не напортачить как минимум в .service, а то и в .socket. Если раньше последовательность загрузки была в принципе по барабану, сеть поднялась, поднимаем демона да и всё, то теперь это может оказаться вовсе не так.

Про syslog/journal/etc даже я, помнится, писал вот здесь Systemd победил в третьем голосовании по выбору системы инициализации для Debian (комментарий) и не только. Выясняется (в данном треде) типа что «их не так поняли».

Доставляет (отдельно) крендель, уверяющий что:

Ну и зачем они нужны в этом месте, когда этого можно достичь средствами одного лишь ядра?

Оххх... фак-то какой... :))) Аж неловко. А ни чего что SELinux это прежде всего именно подсистема ядра, реализованная в виде модулей, а уж потом всё остальное? Что он собрался достигать средствами «одного лишь ядра» если уже и так достигнуто многое и необходимость новых достижений (да ещё и такими методами, без чёткого понимания чего мы желаем достичь) под вопросом.

Линукс в том виде, который мы знали до сего момента да, действительно умирает. Трамвай... трамвай. ;)

Ааа! Я пооонял!

По фразе:

Требуют особой юзерспейсной поддержки, ЕМНИП.

Всё встало на свои места. Клиент не созрел. Он не понимает что без реализации в kernel его userspace отправляется лесом.

А в генточке (ежели чего), то не только apparmor, в hardened-source есть все возможные и доступные на данный момент ср-ва безопасности. И tomoyo и pax и grsbac.

В один демон?

Их там штук пятьдесят.

Вместо простого как 3 коп. скрипта теперь извольте не напортачить как минимум в .service, а то и в .socket.

Дааа... Простой как три копейки инит-скрипт.

https://lists.isc.org/pipermail/bind-users/2008-August/072428.html
http://pastebin.com/1fA6re1f

Ладно. :)

Хорошо. Пусть будет не как 3, а как 5 копеек. Уговорили. :)

Но тогда я стесняюсь спросить что делают люди, не понимающие bash в Linux? Возьмите астерисковский скрипт например. Там, если избавиться от проверок, которые можно и в коде сделать (при желании), всё сводится к start/stop/restart. Как, в принципе, в самом безискусном способе http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

Нет. Давайте теперь qr-коды, корректировку времени и прочую фигню зафигачим чтобы демоны запускать удобнее было. :) Ага-ага... :)))

Врёшь как сивый мерин - если бы пытался понять, то уже давно прочитал бы, благо тема разжёвана вдоль и поперёк даже для полных дебилов.

Если бы меня не устраивала текущая система инициализации, я бы почитал про альтернативы.
И следи за тем что пишешь людям. Твое поведение никого не возбуждает.

Но апологеты systemd уверяли что вот-вот скорость офигенно увеличится. На деле упала. Не мерял, не интересно в секундах, но на глаз заметно.

Не знаю, что там они говорят, но бай дефолт системде тоже небыстрое, ежели подкрутить в конфиге что-то там типа CPUAffinity и добавить quiet в граб, то вроде как быстрее становится. Зато всякие красненькие строчки [FAIL] больше не мозолят красны глазки :D

Насчет остального не в курсе, Selinux никогда не юзал, да и вообще это не мое собачье дело :)

Дааа... Простой как три копейки инит-скрипт.

Простой как три копейки run-скрипт для runit:

$ cat /etc/sv/sshd/run 
#!/bin/sh
ssh-keygen -A # Will generate host keys if they don't already exist
exec /usr/sbin/sshd -D

Вопросы?

https://lists.isc.org/pipermail/bind-users/2008-August/072428.html
http://pastebin.com/1fA6re1f

Не надо ля-ля. По твоим ссылкам в коде идёт анализ различных параметров и условий запуска. Если делать это под systemd, то придётся вызывать точно такую же простынку sh-кода из service-файла. С libastral системд не слинкован.

Но тогда я стесняюсь спросить что делают люди, не понимающие bash в Linux?

Пытаются превратить Linux в Windows, очевидно. При этом в архитектуре Windows они разбираются так же отвратно, как в архитектуре Linux. Результат соответствующий.

Выросло поколение кодеров, воспитанное на Win95.

Но тогда я стесняюсь спросить что делают люди, не понимающие bash в Linux?

Нет. Давайте теперь qr-коды, корректировку времени и прочую фигню зафигачим чтобы демоны запускать удобнее было. :) Ага-ага... :)))

Что делают в Linux люди, не понимающие, что в одном пакете/проекте может быть куча исполняемых файлов, которые полностью опоциональны?

Как, в принципе, в самом безискусном способе http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

Ну нафиг. Я уже привык к удобствам cgroup. А ты предлагаешь возврат в восьмидесятые.

Это не мешает ему работать везде, где нет logind.

Да, похоже на то.

Только они, судя по действиям господина Поттеринга и тому, что происходит с GNOME3 (где RH тоже отруливают) больше на Mac OS X косятся. Делая из Linux макось «для бедных».

Виндари же тем временем открыли для себя важность и нужность shell. Юниксеют по-маленьку. :)

Что делают в Linux люди, не понимающие, что в одном пакете/проекте может быть куча исполняемых файлов, которые полностью опоциональны?

На самом деле люди совершенно не понимают какого хера весь такой пакет из одних полностью опциональных исполняемых файлов внезапно по каким-то совершенно необъяснимым причинам не опционален и принудителен.

Вот бы он еще с USB запускался. А то с unetbootin, imagewriter, dd и.т.д. ничего не происходит, grub запускается.

Говорили-говорили. :)

Я зла не помню, я его записываю. ;) Была такая аргументация.

Я всё удивлялся. Какая на фиг разница на HP DL 980 сколько там система грузится. Он в любом случае свои терабайты RAM будет дооолго ощупывать при POST.

Ну а если всё-таки очень хочется слегка быстрее, то почему в /etc/rc.conf не указать rc_parallel=«YES» и не угомониться?

Красинькие строчки... ну что-то в системе не так, лучше бы разобраться. Всё-таки мы умнее самой умной системы инициализации? ;)

Пользуюсь и SELinux (и не только). Прикладники, как правило, не читают буквари. Представители заказчика не читают вообще. Ни чего и, похоже, принципиально. А мне,получается, чаще чем хотелось бы нужно общаться с идиотами. Так они хотя бы систему не убьют на фиг. Ну и безопасность это хорошо. :)))

Вот бы он еще с USB запускался.

http://wiki.alpinelinux.org/wiki/Create_a_Bootable_USB Тут пишут, что должно всё работать. Не работает?

А я тем временем Void Linux накатил.

Не надо ля-ля. По твоим ссылкам в коде идёт анализ различных параметров и условий запуска. Если делать это под systemd, то придётся вызывать точно такую же простынку sh-кода из service-файла. С libastral системд не слинкован.

Разбор параметров? Ты читать умеешь? https://lists.isc.org/pipermail/bind-users/2008-August/072428.html

Особенно красивы строчки с магическими слипами:
restart() {
    stop
# wait a couple of seconds for the named to finish closing down
    sleep 2
    start
}    
Серьезно, вы вынужденны тупо надеяться на то, что за 2 секунды бинд везде и при любой нагрузке завершится?

stop() {
        # Stop daemons.
        echo -n $"Stopping $prog: "
    /usr/sbin/rndc stop >/dev/null 2>&1
    RETVAL=$?
    if [ $RETVAL -eq 0 ]; then
        rm -f /var/lock/subsys/named
#Этим должен таки инит заниматься.
        rm -f /var/run/named.pid       
#Костыль из эпохи, когда инит-система не знала пиды порожденных ею демонов.
    elif pidof named >/dev/null; then
        killproc named -TERM >/dev/null 2>&1
#Если по какой-то причине у меня два экземпляра бинда запущенны (скажем, на разных интерфейсах), то это место доставит много веселья.
        RETVAL=$?
        if [ $RETVAL -eq 0 ]; then
        rm -f /var/lock/subsys/named
        rm -f /var/run/named.pid
        fi;
    fi;
        if [ -n "${ROOTDIR}" -a "x${ROOTDIR}" != "x/" ]; then
                if egrep -q '^/proc[[:space:]]+'${ROOTDIR}'/proc' 
/proc/mounts; then
                    umount ${ROOTDIR}/proc >/dev/null 2>&1
                fi;
        fi;
    if [ $RETVAL -eq 0 ]; then
        success
    else
        failure
        fi;
    echo
    return $RETVAL
}


Ну и самое вкусное, где идет разбор параметров:
start() {
        # Start daemons.
        echo -n $"Starting $prog: "
    if [ -n "`/sbin/pidof named`" ]; then
# Не больше одного бинда на один компьютер! Иначе не олдскульно!
        echo -n $"$prog: already running"
        failure
        echo
        return 1
    fi
    ckcf_options='';
    if [ -n "${ROOTDIR}" -a "x${ROOTDIR}" != "x/" ]; then
        OPTIONS="${OPTIONS} -t ${ROOTDIR}"
        ckcf_options="-t ${ROOTDIR}";
        if [ -s /etc/localtime ]; then
            cp -fp /etc/localtime ${ROOTDIR}/etc/localtime
        fi;
        if [ ! -d ${ROOTDIR}/proc ]; then
            mkdir -p ${ROOTDIR}/proc
        fi
        if ! egrep -q '^/proc[[:space:]]+'${ROOTDIR}'/proc' 
/proc/mounts; then
            mount --bind -n /proc ${ROOTDIR}/proc >/dev/null 2>&1
        fi
    fi
#Подготовка chroot, это системд и сам делает нормально. А ниже подготовка selinux, чем системд сам занимается. 
    no_write_master_zones=0
    if [ -e /etc/selinux/config ]; then
           .  /etc/selinux/config
           if [ "$SELINUX" != 'disabled' ] && [ "$SELINUXTYPE" != "" ] 
&& [ -d /etc/selinux/${SELINUXTYPE} ] && [ -e 
/etc/selinux/${SELINUXTYPE}/booleans  ]; then
           . /etc/selinux/${SELINUXTYPE}/booleans
           if echo "$named_write_master_zones" | /bin/egrep -q 
'^[0-9]+$'; then
           if [ "$named_write_master_zones" -eq 1 ] ; then
               /bin/chown -f --from=root:named named:named 
$ROOTDIR/var/named
           elif [ "$named_write_master_zones" -eq 0 ] ; then
               /bin/chown -f --from=named:named root:named 
$ROOTDIR/var/named
           fi;
               fi;
       else
           no_write_master_zones=1
       fi;
    else
        no_write_master_zones=1
        fi;
    if [ "$no_write_master_zones" -eq 1 ]; then
        if [[ "$ENABLE_ZONE_WRITE" =  [yY1]* ]]; then
#Смотрим, можно ли нам писать в фаил зоны. Блин, у системд есть директива для read-only директорий. И вся возня с /bin/chown - просто не нужна.
        /bin/chown -f --from=root:named named:named $ROOTDIR/var/named
        elif [[ "$ENABLE_ZONE_WRITE" =  [nN0]* ]]; then            
        /bin/chown -f --from=named:named root:named $ROOTDIR/var/named
        fi;
    fi
        conf_ok=0;
# /usr/sbin/named-checkconf идет в ExecStartPre, без всей этой возни с ифами.
    if [ -x /usr/sbin/named-checkconf ] && /usr/sbin/named-checkconf 
$ckcf_options $named_conf >/dev/null 2>&1; then
           conf_ok=1;
        else
       RETVAL=$?;
    fi
    if [ $conf_ok -eq 1 ]; then       
       daemon /usr/sbin/named -u named ${OPTIONS};
       RETVAL=$?;
       if [ $RETVAL -eq 0 ]; then
# Опять работа с пидами и chroot.
           rm -f /var/run/named.pid
           ln -s $ROOTDIR/var/run/named/named.pid /var/run/named.pid;
       fi;
    else
       named_err="`/usr/sbin/named-checkconf $ckcf_options $named_conf 
2>&1`";       
       echo
       echo $"Error in named configuration"':';
# Если /usr/sbin/named-checkconf - вернет ошибку, системд сообщит пользователю и не будет пытаться запустить сам сервис.
       echo "$named_err";
       failure
       echo
       if [ -x /usr/bin/logger ]; then
           echo "$named_err" | /usr/bin/logger -pdaemon.error -tnamed
           fi;
           return $RETVAL;
        fi;
     [ $RETVAL -eq 0 ] && touch /var/lock/subsys/named
        echo
    return $RETVAL
}
[\code]

Это не мешает ему работать везде, где нет logind.

Да, только требовать от разрабов гнома завязывать свой функционал на мертвый проект - глупо.
Хотя они те-еще неадекваты...

развязочка...

у меня было подсознательно смутное подозрение... оказывается вот оно че Михалыч!

Эмпирическое правило: если что-то кое-где кое-как это вполне могут быть п...ы

Могут быть опциональны, да.

Но у нас есть getopt/getlongopt, которыми опции достаточно успешно обрабатываются и в зависимости от опций софт работает так или иначе. В том же bash аналогично можно использовать (примера ради http://wiki.bash-hackers.org/howto/getopts_tutorial)

Cgroup с systemd... К этому? http://0pointer.de/blog/projects/resources.html

Не представляю себе как именно можно предсказать заранее нагрузку на сервер http и правильно сконфигурировать параметры cgroup для него. Я бы предпочёл чтобы система сама разруливала такие тонкие моменты.

Фу-фу-фу, фу-фу-фу, мать вашу. Что я делаю на этом ресурсе? Что меня связывает с этой блевотой? Уж лучше FreeBSD и Windows, чем этот кал, который ПНХ.

Я всё удивлялся. Какая на фиг разница на HP DL 980 сколько там система грузится. Он в любом случае свои терабайты RAM будет дооолго ощупывать при POST.

На ноутах он обычный быстрый. На ПК медленнее.

Ну а если всё-таки очень хочется слегка быстрее, то почему в /etc/rc.conf не указать rc_parallel=«YES» и не угомониться?

В последний раз, когда пробовал, оно было глючным и могло зависнуть :)

Красинькие строчки... ну что-то в системе не так, лучше бы разобраться. Всё-таки мы умнее самой умной системы инициализации? ;)

Ну как бы, это упавшие юниты несистемного софта, вроде бы. На генте таковых у меня почти не было, на rpm-based особенно чаще :)

Пользуюсь и SELinux (и не только).

А есть смысл использовать это дома, или лучше не стоит?