Пользователь
18,0
рейтинг
19 мая 2014 в 17:15

Администрирование → И объял меня systemd до глубин дистрибутива моего

Оно случилось: Debian начал переход на systemd.

Для системных администраторов это выглядит вот так:
localhost# apt-get update;apt-get upgrade
...
The following packages have unmet dependencies:
 systemd-sysv : Breaks: sysvinit-core but 2.88dsf-53 is installed.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     sysvinit-core               

Accept this solution? [Y/n/q/?]


Что это означает? Это означает прохождение рубежа в постепенной миграции на systemd, решение о котором было принято чуть ранее, замена sysv-init на systemd. Пакет sysvinit-core содержит в себе /sbin/init, и его заменяют на другой /sbin/init из состава systemd.

Кто-то видит в происходящем шаг в светлое будущее, где все будут счастливы и почти не надо будет умирать, кто-то видит акт трагичного и смиренного принятия роковой судьбы, тёмной длани Рэдхэта, простирающейся на все дистрибутивы вокруг и устраняющий Фатальный Недостаток других систем запуска, кто-то просто со стоическим отчаянием ждёт ещё больше и больше Поттеринга (Л. Поттеринг — автор systemd, он же автор pulseaudio, он же автор неповторимого стиля изложения новых идей, при которых для старого образа жизни и мышления не остаётся места).


В любом случае, свершилось. GNU Debian/jessie, в девичестве GNU Debian/sid, становится systemd-based distribution.


На очереди Убунта.
Георгий Шуклин @amarao
карма
268,0
рейтинг 18,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (176)

  • 0
    Вот прям только что выполнил full-upgrade и где же оно?
    # cat /etc/debian_version
    jessie/sid

    # dpkg -l | grep systemd
    ii libsystemd-journal0:amd64
    ii libsystemd-login0:amd64
    • +1
      Вероятнее всего, на ваш миррор ещё не свалилось.
      cat /etc/debian_version 
      jessie/sid
      dpkg -l|grep systemd
      ii  libpam-systemd:amd64           204-10                             amd64        system and service manager - PAM module
      ii  libsystemd-daemon0:amd64       204-10                             amd64        systemd utility library
      ii  libsystemd-id128-0:amd64       204-10                             amd64        systemd 128 bit ID utility library
      ii  libsystemd-journal0:amd64      204-10                             amd64        systemd journal utility library
      ii  libsystemd-login0:amd64        204-10                             amd64        systemd login utility library
      ii  systemd                        204-10                             amd64        system and service manager
      ii  systemd-sysv                   204-10                             amd64        system and service manager - SysV links
      
      • –1
        Ну, допустим-с…
        Сейчас использую ftp.ru.debian.org.
        Подождём до завтра.
      • 0
        Cтарый добрый © инит никто не забирает:
        вай необратимость?
        # cat /etc/debian_version
        jessie/sid
        # dpkg -l | grep systemd
        ii libsystemd-daemon0:amd64 204-10 amd64 systemd utility library
        ii libsystemd-id128-0:amd64 204-10 amd64 systemd 128 bit ID utility library
        ii libsystemd-journal0:amd64 204-10 amd64 systemd journal utility library
        ii libsystemd-login0:amd64 204-10 amd64 systemd login utility library
        # aptitude show systemd-sysv | grep -i ^version
        Version: 204-10
        # grep ^deb /etc/apt/sources.list
        deb ftp.debian.org/debian/ sid main non-free contrib


        а пока системд доползет до стейбла, глядишь, и падать перестанет.
  • +2
    А объективно у Вас есть какие-нибудь жалобы на systemd, или это просто протест ради протеста?
    Если меинтейнеры хорошо поработали, то пользователи ничего не заметят, кроме увеличения скорости загрузки и изменения внешнего вида. Слой совместимости с sysv-скриптами в любом случае остается.
    • +17
      У меня есть килограммы претензий к pulseaudio, плюс отношение автора к «легаси-проблемам». Для себя я уже смирился, что придётся изучать. Но без малейшего удовольствия, как неизбежное и неприятное зло.

      Главная претензия — оно невероятно сложное. Отладить sysv-init может любой администратор. Отладить systemd может только системный программист, да ещё с приличным запасом времени. Причём сложность systemd делает процесс определения «виноватого», мягко говоря, не самым тривиальным, потому что отследить весь процесс старта становится слишком сложно.

      Это в одной категории с UEFI boot. Было старо куце и легаси, но просто. Сделали «ново, модно», но безумно сложно.
      • +2
        http v2 туда же… Боюсь эта неизбежность ждёт всё. Со временем знать всё на достаточном уровне становится просто невозможно.
        Такими темпами могут появиться вакансии «администратор systemd» и т.п.
        • +5
          То есть спрайты и скукоженные js и css это нормально, а бинарный http с мультиплексированием это плохо, да?
          • +1
            Всё хорошо. Просто простой базис становится сложным. Тем, кого этот базис интересует с точки зрения полного знания и отладки, становится немножко сложнее жить. И так во всех областях. А в остальном всё хорошо.
            • +1
              Всё хорошо. Просто простой базис становится сложным.
              По-моему, это происходило всегда в процессе прогресса цивилизации.
              • +9
                Нет. Большую часть времени базис становился проще. Если сравнить арифметику у римлян и во времена Ньютона, можно заметить значительное упрощение. А если сравнить процесс изложения дифференциального исчисления в пост-ньютоновские времена с современным описанием, ньютоновское будет несравнимо сложнее.

                Электротехника начала века была адской и ужасной. Сейчас развести проводку куда проще — и надо очень постараться чтобы что-то сделать не так.

                Про изучение латыни в школе я даже напоминать не буду.
                • +2
                  Возможно, вы и правы. Но, прежде, чем появилась сложная электроника и её потом упростили, её вообще небыло. Ну а до изучения латыни в школе было время, когда школ совсем небыло.

                  Про systemd же, уже сейчас синтаксис .service-файлов, systemctl достаточно прост. И логи интуитивны. А во времена sysvinit где были логи? Да где демон захочет, там и были. А сейчас мы точно знаем, где их искать и как парсить. То есть это стало проще уже только потому, что исчез зоопарк. И логи — только один пример.
                  • +7
                    Я же не говорю, что sysv-init это чудо инженерной мысли. Оно хак на хаке и костылём подпёрто.

                    Но новое решение, вместо открытых универсальных компонент вываливает нам в систему гигантский комплект блобов, которые друг с другом подогнаны а о других ни сном, ни духом.

                    … Кажется, надо переползать в область метафор. Это называется «ремонтопригодность». Эпплофаги в восторге от яблочка, мастера по ремонту матерятся по поводу клея всюду вместо винтов.

                    systemd нельзя разобрать на кусочки. sysv-init — можно. Он неказистый, зато понятный.
                    • 0
                      А можно поподробнее про блобы в systemd?
                      • 0
                        Какие зависимости у logind? Что ему нужно для работы? Почему init имеет связи с udev'ом?
                        • 0
                          А почему бы ему не иметь связи с udev? Покажите мне хоть один вменяемый дистрибутив без udev. Ну и про блобы, пожалуйста, коммит в основную ветку systemd с блобом.
                          • +9
                            А почему бы ему не иметь связи ещё с кучей других сервисов? Это типовой виндузятный подход — если чаще всего оно есть, значит, можно линковаться. А если нет? Проблемы негров шерифа не волнуют? А если будет принято решение переделать udev, то, внезапно «оно ломает systems?»
                            • +1
                              Не надо с больной головы на здоровую. Речь шла о блобах. udev разработан в недрах systemd. Вы хотите systemd без udev? Ну сделайте форк, кто мешает то? Ещё systemd завязан на Linux, на других ядрах работать не будет. Хотите поддержку своего любимого ядра — делайте форк.

                              Про виндузовый подход не понятно, там же «всё своё ношу с собой».
                            • 0
                              Я конечно буду банален. А документацию читать пробовали? К примеру дерево зависимостей можно посмотреть следующей командой:
                              systemctl list-dependencies
                              


                              Почему init имеет связи с udev'ом?

                              Потому что это systemd. А связь с udev ему требуется, чтобы при старте системы осуществить инициализацию /dev
                              • 0
                                А почему он вообще осуществляет конфигурацию устройств, но при этом не готовит кофе?
                                • 0
                                  facepalm.jpg все что я тут могу сказать. udev является частью systemd. По этой причине и осуществляет. Я не сказать что в восторге от того что он более монолитен, чем sysv-init или upstart. Но это с точки зрения разработчика требуется, чтобы ускорить работу. Опять же в embedded это плюс, так-как кода получается меньше.
                                  • +5
                                    udev появился задолго до systemd, и их «блобоинтеграция» получилась отвратительной.

                                    В embedded (настоящем, а не который с «флешом на 32Мб»), инит, который занимает 6Мб, это позор.

                                    dpkg -l|grep systemd|awk '{print $2}'|xargs dpkg -L|xargs ls -lad|awk '{a+=$5}END{print a}'
                                    6087907
                                    • –1
                                      udev появился задолго до systemd, и их «блобоинтеграция» получилась отвратительной.

                                      Те же люди писали. В итоге они его поместили в systemd. И при этом оставили возможность использовать его отдельно от systemd. В случае если используется вместе с systemd экономится время на загрузку и уменьшается размер сервиса.

                                      В настоящий embedded linux не кладут. Смысла нет. А где кладут, то там проблемы с 6 мегабайтами не наблюдается и да там можно при сборке много что повыкидывать из systemd так что он будет меньше. И да то как вы считаете еще туда всю документацию включает. Если же посмотреть чисто бинарники то у меня это 4 мегабайта.
                                      • +7
                                        У меня относительно маленький опыт в embedded, но по моим воспоминаниям для не очень сложной железки размер «фирмвари» под линуксом был 2Мб. Строго и ровно.

                                        Более того, сейчас в комьюнити идёт особый срач на тему minimize footprint (internet of things, $0.5 за компьютер и всё такое). И в условиях срача за 400кб TCP-стека 6Мб на /sbin/init выглядит как… ну, «пусть едят пирожные».

                                        Я к тому, что монолитный дизайн (а что бы Поттеринг не говорил, получается монолитный блобик) — это зло. Вместо аккуратного конструктора — лапша из зависимостей и огромный функционал там, где его не ожидают (нахрена там встроенный веб-сервер?)
                                        • +1
                                          У меня относительно маленький опыт в embedded, но по моим воспоминаниям для не очень сложной железки размер «фирмвари» под линуксом был 2Мб. Строго и ровно.

                                          Это размер сжатого образа и это фактически минимальная система с busybox в том числе и в качестве init системы.

                                          Более того, сейчас в комьюнити идёт особый срач на тему minimize footprint (internet of things, $0.5 за компьютер и всё такое). И в условиях срача за 400кб TCP-стека 6Мб на /sbin/init выглядит как… ну, «пусть едят пирожные».

                                          Если бы вы почитали этот самый срач, то товарищей из Intel отправляют в лес. К тому же где 6 мегабайт много, используют другие решения. В том числе не используют linux. Так-как он для своей загрузки и какой-то работы требует минимум 4 мегабайта RAM.

                                          Я к тому, что монолитный дизайн (а что бы Поттеринг не говорил, получается монолитный блобик) — это зло. Вместо аккуратного конструктора — лапша из зависимостей и огромный функционал там, где его не ожидают (нахрена там встроенный веб-сервер?)

                                          Для начала монолитный дизайн разбит на модули и systemd позволяет отключить лишнее еще на стадии компиляции. Т.е. к примеру выпилить встроенный-веб сервер. Про лапшу зависимостей поржал. И да sysv-init это не аккуратный конструктор, это костыль на костыле и костылем погоняет. Функционал же systemd вполне себе регулируется и отключается. Тут кстати момент есть, я уже не раз замечал, что на systemd гонят волну люди которые видели его один раз. Вы сами подумайте если бы все было так плохо как вы описываете, то чего debian его берет?
                                          • +5
                                            Я этот срач внимательно читаю. Посылают их товарищи с жирных десктопов и серверов. С учётом, что «если не линукс, то кто-нибудь другой», интереса Интела и ситуации, когда подобное железо будет востребовано, я думаю, здравый смысл победит.

                                            О политике вокруг systemd можно много говорить.

                                            Что sysv-init не аккуратный конструктор а артефакт-переросток я уже выше писал. Но это не означает, что его замена должна быть столь громоздкой и немодулярной.

                                            «Отключение функционала при сборке» — это не совсем то, о чём я говорю. Хорошие универсальные компоненты можно использовать как самостоятельные инструменты. Огромные блобо-куски — только там, куда их написали. Об этом и скорбь. Много кода, гигантский функционал, который «делает всё».
                                            • –2
                                              Я этот срач внимательно читаю. Посылают их товарищи с жирных десктопов и серверов. С учётом, что «если не линукс, то кто-нибудь другой», интереса Интела и ситуации, когда подобное железо будет востребовано, я думаю, здравый смысл победит.

                                              Пока людям говорят, что они страдают фигней. И я считаю, что те кто это говорит правы. Так-как в свете нам надо минимум 4 мегабайта памяти для работы выпиливание 400кб стека полная фигня.

                                              Что sysv-init не аккуратный конструктор а артефакт-переросток я уже выше писал. Но это не означает, что его замена должна быть столь громоздкой и немодулярной.

                                              Попытки сделать что-то лучше предпринимались не раз. Тот же upstart, но я бы не сказал что они удачны. На данный момент сама спецификация которую задает systemd весьма удачна.

                                              «Отключение функционала при сборке» — это не совсем то, о чём я говорю. Хорошие универсальные компоненты можно использовать как самостоятельные инструменты.

                                              Не получится. Если делать отдельными универсальными инструментами, опять получим sysvinit. Замечу там где функционал четко выделяется, отдельные сервисы сделаны. Тот же journal и logind. Но вообще говоря конечно бы неплохо чтобы функционал подключался через библиотеки, а не как сейчас при сборке в один модуль. Но это я думаю сделают.

                                              Огромные блобо-куски — только там, куда их написали. Об этом и скорбь. Много кода, гигантский функционал, который «делает всё».

                                              Это все чинится в том числе сообществом. Вон с glibc жили жили, как стало прижимать сделали свой eglibc. Так может произойти и с systemd. Главное чтобы при этом новый systemd был совместим со старым по спецификации.
                                        • 0
                                          в systemd есть встроенный веб-сервер? ебанулись точно.
                                          • 0
                                            Не то, чтобы встроенный — libmicrohttpd в зависимостях. И ещё генерация QR-кодов через qrencode-libs
                                            Инфа отсюда: thread.gmane.org/gmane.linux.redhat.fedora.devel/169082
                                            • 0
                                              Засилье systemd вобще какое-то, смотрю freebsd снова начали порт писать openlaunchd
          • +5
            Плохо, что именно бинарный.
            • –1
              Чем же?
              • +4
                Тем, что прочитать глазами не получится без спец. инструментов.
                • –6
                  Вы давно читали дамп http без инструментов браузера или wireshark?
                  • +19
                    Почти постоянно.

                    nc -l 80 — и у вас готовый веб-сервер. Которому можно даже что-то ответить. Аналогично, nc foobar 80 — и у вас готовый веб-клиент, куда можно написать за разумное число усилий HTTP запрос.

                    И да, я его использую в ежедневной работе для отладки, проверки гипотез и т.д.
                    • –9
                      http2 позволит (что сходу пришло в голову) избавиться от грязных оптимизаций веб-мастеров (спрайты, сжатия нескольких скриптов\стилей в один файл), от грязных оптимизаций браузеров, которые зарание открывают по несколько TCP-соединений, даже если это ещё не нужно, чтобы потом было быстрее, от проблем разрыва передачи большого файла и т. д.
                      Всё это не без помощи мультиплексирования, которое было бы сложно реализовать без бинаризации протокола.
                      Так вот, Вы предлагаете от всего этого отказаться, чтобы можно было netcat-ом просто делать http-клиент и сервер, так?
                      Вообще, для тестового клиента есть curl. Для тестового сервера я предпочёл бы набросать код в ipython.
                      • +11
                        Ни кто не предлагает ни от чего отказываться, просто для нас ощутим факт того, что некая программная сущность (будь то система инициализации или протокол) становится сложнее в осознании и дэбаге.
                      • +3
                        Бред т.к. это не объясняет бинаризацию протокола.
                        Единственное объяснение, что я могу придумать — это необходимость drm. Т.к. drm с текстовым и простым в дебаге протоколом общаться не захочет.
                        Сам http без проблем можно превратить в http2, загнав все в блоб base64 и раскрыв это яваскриптом в браузере клиента.

                        Опять же проблему сессий — главный недостаток http — оно не решает, хотя решения для этого есть!
                    • +2
                      BTW, предположу, что дампящий прокси уровня TCP для HTTP2 будет писаться в сто-двести строк Erlang-а.

                      Но, конечно, к systemd этот подход неприменим, и это ужасно. Я со своего дилетантского уровня не вижу, в чем проблема с upstart, и категорически не понимаю, почему не взяли его. Он же простой как три рубля и вроде бы вполне логичный.
                      • 0
                        Я со своего дилетантского уровня не вижу, в чем проблема с upstart, и категорически не понимаю, почему не взяли его.

                        Потому что он хуже systemd. Я в свое время смотрел на него. И я бы не сказал что он сильно лучше systemd. И да довольно долгое время upstart требовал sysv-init в комплекте так-как у него небыло команд shutdown и reboot из коробки.
                        • +2
                          Потому что он хуже systemd. Я в свое время смотрел на него. И я бы не сказал что он сильно лучше systemd.
                          Это не выглядит сильной аргументацией в пользу systemd.
                          • 0
                            Для более сильной аргументации сравните банально что можно в файле описания сервиса upstart и что в systemd в случае systemd делать какую-то обертку нужно существенно реже чем в случае upstart.
                            • +1
                              Ну, не знаю. У меня на upstart-е практически с пол-пинка завелась тулза на все том же э-ге, собранная в релиз. А релизы, прямо скажем, не самая дружественная init-ам штука.

                              systemd отчетливо хуже, потому что он комплекснее, в него затащили кучу каких-то unrelated вещей, и он навязывает какие-то свои конвенции и интерфейсы. upstart — простой supervisor, не больше и не меньше.
                              • 0
                                Значит точно так же заведется на systemd. А комплексность необходима, чтобы потом в случае чего не городить костылей в виде скриптов. В systemd это требуется делать реже чем в случае upstart.
                    • 0
                      Разумное число усилий?
                      Серьезно?
                      Это так сложно?
                      GET / HTTP/1.0\n
                      Host: ip\n
                      \n\n

                      Серьезно, почему тот же SMTP бинарным не сделали? У меня такое чувство, что http2 и html5 drm чем-то связаны и очень крепко и отсюда вот эти бинарные подвижки.
                  • +5
                    Я иногда говорю на чистом HTTP в целях отладки. Просто telnet host http и поехали, GET /.../ HTTP/1.1 и так далее
                    • +9
                      telnet опасен тем, что он не совсем чисто использует plain tcp. nc куда лучше.
                      • 0
                        В данном случае это не принципиально.
                    • –3
                      см. #
                  • +12
                    Ниже уже написали, зачем это всё нужно, а я просто дам ссылку на хорошую книгу, а именно место:

                    1.8. Применение философии Unix

                    Структура баз данных и протоколы приложений должны быть, если это возможно, текстовыми (доступными человеку для чтения и редактирования).
                    • –7
                      Структура баз данных и протоколы приложений должны быть, если это возможно, текстовыми...
                      если это возможно
                      Ну вы понели? А выше я писал, почему это теперь стало невозможно.
                      • +3
                        Во-первых, вы писали, что это сложно, а не невозможно. Во-вторых, и это-то спорно:

                        > не без помощи мультиплексирования, которое было
                        > бы сложно реализовать без бинаризации протокола.

                        Почему? Бинарный вид или текстовый вид — это всего лишь форматы представления данных. С точки зрения алгоритмизации между этими представлениями данных нет принципиальной разницы.
              • +5
                Тем, что если безупречная программа правильно запишет сообщение об отсутствии ошибки, гениальный пользователь, способный читать в hex-кодах, сможет не читать его с целью не исправления идеально работающей программы.
                • +1
                  Что, простите?
                  Нет, я правда ничего не понял.
                  • +8
                    Ок, пишу без сарказма. Тем, что если глючная поделка криво запишет сообщение об ошибке другой программы, средний пользователь, не умеющий читать бинарный формат в hex-редакторе (а обычный свалится на битом файле) не сможет прочитать это сообщение для исправления ошибки.
                    • 0
                      Я давно не видел, чтобы даже глючные поделки сами реализовывали тот же http 1.x. Есть же готовые библиотеки для этого.

                      Да и ситуация выглядит слишком уж гипотетической. Сомнительный минус при очевидных плюсах.
                      • +3
                        Я буквально на в начале месяца отлаживал отправку логов. С nc и tcpdump'ом в руках. Печально, что отбирают.
                        • –1
                          А я отлаживал бинарный протокол с tcpdump. По сути какая разница-то?
                          • +1
                            Тестовые данные вы как отсылали?
                            • –2
                              А я писал клиент на elang, там всё просто.
                              • +4
                                Ну да, писать программы для отладки сети — это так обычно и по-юниксовски. Каждый стадион, решивший разобраться с логгингом может написать программу на эрланге и перестать страдать по поводу текста и nc.
                                • –2
                                  Казалось, бы причём тут systemd? Парсить бинарные данные простейшим скриптом можно абсолютно на чём угодно. ЧТо мешает перенаправить вывод tcpdump? Ничего что сам tcp бинарный, вам это сильно мешает?
                                • 0
                                  да. пользоваться ерлангом нечестно.
                                  • +2
                                    Я реально хочу посмотреть на процесс отладки «ерлангом» коннекта с маршрутизатора на сервер. Вот берём мы juniper потолще, вываливаемся в freebsd внутрях, набираем nc server 80… Ой, я хотел сказать, идём в порты, ставим эрланг, пишем программу… На маршрутизаторе, да?
                                    • –1
                                      внезапно оказывается, что httpv2 отлаживаем на маршрутизаторе
                                      вы это, когда закончите двигать ворота, напишите
                                      • +2
                                        Я не понимаю, что странного в процессе отладки http с любого сетевого устройства. Надо выяснить, что происходит. Например, злобный ростелеком странно реагирует на заголовки и надо исключить сам маршрутизатор из рассмотрения. Сравниваем реакцию на заголовки из сети за маршрутизатором с поведением на самом маршрутизаторе.

                                        Ну, то есть я понимаю, что это же http2, там всё не просто так. Суть скорби в том, что раньше было «просто так», а теперь становится «не просто».
                                        • –2
                                          Я не понимаю, что странного в процессе отладки http с любого сетевого устройства.
                                          абсолютно ничего. проблема в том, что условие задачи дополняется на лету.
                                          • +3
                                            Мы обсуждали удобство администраторов в отладке http и http2. Вы сказали, что писать программы на эрланге это здорово и правильно, и что все системные администраторы должны этим заниматься. Возможно не точно так, но так прозвучало.

                                            Я привёл пример сценария, когда писать программы на эрланге будет глупо, даже если оставить в стороне максиму «хочешь отладить систему — пиши программы».
                                            • –2
                                              1. никто никому ничего не должен
                                              2. если исходить из предположения, что з/п нормального сисадмина приблизительно равна з/п программиста (в моём окружении это так), то я решительно не вижу, почему бы сисадмину при необходимости не писать программы в том числе и на ерланге (благо для парсинга всяких бинарных протоколов я ничего лучше не знаю).
                                              • +3
                                                Я лично эрланг не перевариваю. И если для внедрения нового протокола будет обязательным писать программы на эрланге, то хрен вам лысый, а не http2.
                                                • +1
                                                  В итоге мы пришли к выводу, что вас неустраивает systemd, потому что у вас в embedded меньше 6MB. Отлично, зачем вам там Debian? Полно специализированных дистрибутивов, которые заточены под маленькую оепративную память. Там нет systemd. На декстопе systemd ускоряет загрузку за счёт параллельного исполнения. Конфигурировать unit файлы намного проще, чем ковырять неведомый слой отходов жизнедеятельности мамонтов в виде init скриптов. Ещё с учётом, что все инитскрипты разные для разных дистрибутивов. Пробовали перенести скрипт с Дебиана на Сузе, например? Systemd нужен для general-propose. Если у вас что-то специфическое, используйте что-то специфическое, кто мешает?

                                                  Вас не устраивает http2 потому что вам трудно сниффить это роутере. Ну что поделать, может вас ещё не устраивают компилируемые языки, что исполняемый файл не human readable? Будет вам http2dump, в чём проблема?
                                                  • 0
                                                    Не будет вам http2. Причину я уже сказал.
                                              • +1
                                                > 2. если исходить из предположения, что з/п нормального сисадмина приблизительно равна з/п программиста

                                                По этой логике почему бы сисадмина не обязать не заниматься, скажем, хирургией заодно?
                                                • +3
                                                  Хирурги пофигу. А вот склад пойти помочь разгрузить — why not?
        • 0
          Вакансии нет, а вот звание «гуру системд» можно вполне иметь и получать от этого лучи уважения от остальных сотрудников, которые в нём ни бельмеса.
          • +2
            Я тоже был против systemd, но оно действительно неплохое. Ну, есть, конечно, нюансы, но в целом работает быстро, утилиты удобные (управлять сервисами мне нравится гораздо больше в systemd, нежели в sysvinit), тот же journald достаточно интересный. Загрузка происходит быстро. Юниты писать проще простого.

            Pulseaudio тоже долгое время не пользовался, а сейчас перешел. К нему тоже вопросов у меня много. Перешел из-за того, что мне одно время приходилось много записывать с «монитора», а в alsa это получалось неудобно.
            • +1
              Плюсы, вне всяких сомнений есть, но journald, по моему мнению, относится исключительно к минусам. И при чем не как идея, а именно в реализации.
      • +1
        Главная претензия — оно невероятно сложное. Отладить sysv-init может любой администратор.
        У вас какое-то странное определение сложности.

        инит-файл
        #!/bin/sh
        set -e
        
        ### BEGIN INIT INFO
        # Provides:		postgresql
        # Required-Start:	$local_fs $remote_fs $network $time
        # Required-Stop:	$local_fs $remote_fs $network $time
        # Should-Start:		$syslog
        # Should-Stop:		$syslog
        # Default-Start:	2 3 4 5
        # Default-Stop:		0 1 6
        # Short-Description:	PostgreSQL RDBMS server
        ### END INIT INFO
        
        # Setting environment variables for the postmaster here does not work; please
        # set them in /etc/postgresql/<version>/<cluster>/environment instead.
        
        [ -r /usr/share/postgresql-common/init.d-functions ] || exit 0
        
        . /usr/share/postgresql-common/init.d-functions
        
        # versions can be specified explicitly
        if [ -n "$2" ]; then
            versions="$2 $3 $4 $5 $6 $7 $8 $9"
        else
            get_versions
        fi
        
        case "$1" in
            start|stop|restart|reload)
        	if [ -z "`pg_lsclusters -h`" ]; then
        	    log_warning_msg 'No PostgreSQL clusters exist; see "man pg_createcluster"'
        	    exit 0
        	fi
        	for v in $versions; do
        	    $1 $v || EXIT=$?
        	done
        	exit ${EXIT:-0}
                ;;
            status)
        	LS=`pg_lsclusters -h`
        	# no clusters -> unknown status
        	[ -n "$LS" ] || exit 4
        	echo "$LS" | awk 'BEGIN {rc=0} {if (match($4, "down")) rc=3; printf ("%s/%s (port %s): %s\n", $1, $2, $3, $4)}; END {exit rc}'
        	;;
            force-reload)
        	for v in $versions; do
        	    reload $v
        	done
                ;;
            *)
                echo "Usage: $0 {start|stop|restart|reload|force-reload|status} [version ..]"
                exit 1
                ;;
        esac
        
        exit 0
        
        
        юнит
        [Unit]
        Description=PostgreSQL database server
        After=network.target
        
        [Service]
        Type=forking
        TimeoutSec=120
        User=postgres
        Group=postgres
        
        Environment=PGROOT=/var/lib/postgres
        
        SyslogIdentifier=postgres
        PIDFile=/var/lib/postgres/data/postmaster.pid
        
        ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data
        ExecStart= /usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120
        ExecReload=/usr/bin/pg_ctl -s -D ${PGROOT}/data reload
        ExecStop=  /usr/bin/pg_ctl -s -D ${PGROOT}/data stop -m fast
        
        # Due to PostgreSQL's use of shared memory, OOM killer is often overzealous in
        # killing Postgres, so adjust it downward
        OOMScoreAdjust=-200
        
        [Install]
        WantedBy=multi-user.target
        
        • +4
          А теперь представим себе, что у нас в файле опечатка. Которая вызывает silent ignore со стороны systemd каких-то строчек. Как вы это отлаживать будете? Не как программист, как сисадмин.
          • +4
            Именно опечатки можно вот так ловить:

            # systemctl show apparmor.service --no-pager | fgrep -x -f - -v /etc/systemd/system/apparmor.service | grep -v '\['
            
            Typx=oneshot
            ExecStart=/usr/local/bin/apparmor_load.sh
            ExecStop=/usr/local/bin/apparmor_unload.sh
            

            А остальное… хмм.
      • +2
        Это в одной категории с UEFI boot. Было старо куце и легаси, но просто. Сделали «ново, модно», но безумно сложно.
        Боже, а с UEFI-то что не так в плане сложности? Я вот всегда мечтал делать загрузочные флешки простым копированием файлов. UEFI так позволяет делать.
        • +1
          Это пожалуй единственное, что стало проще. Вы само UEFI-приложение, которое можно скопировать на флешку и оно так запустится, сделать пробовали?
          • +2
            Я пробовал, и не вижу причин для беспокойства.
            Да, EDK поначалу кажется сложным, но сборочная стреда настраивается один раз, а потом для сборки остается только GUID придумать и INF-файл правильно написать. Другое дело, что нужно API изучать, но оно в разы проще для понимания, чем прерывания старого BIOS'а.
      • 0
        А что, oss/alsa работали лучше? У меня на ноутбуке pulseaudio вполне справляется с поставленными задачами. Ну и не понятно, почему отношение к продукту диктуется отношением к другому продукту того же разработчика.

        Лог у systemd настолько полный (может быть даже слишком?), что разобраться при портировании init-скриптов на systemd с тем, что происходит, у меня получилось очень легко. Если речь идет об отлавливании багов в самом systemd, то, возможно, этим действительно должны заниматься программисты, а не сисадмины?

        Ну и пожалуйста, не говорите, что считаете, что в 2014 году дата и время должны храниться в BCD, а загрузчик запускаться в реальном режиме. Излишняя усложненность — это лишь попытка максимально оттянуть дату необходимости разработки следующего нового стандарта.
        • +10
          А что, oss/alsa работали лучше? У меня на ноутбуке pulseaudio вполне справляется с поставленными задачами. Ну и не понятно, почему отношение к продукту диктуется отношением к другому продукту того же разработчика.

          Да. У альсы предсказуемая и небольшая задержка. У пульса она большая и непредсказуемая. Попробуйте работать с музыкой на компе, резко поймёте, что без полного удаления пульса с системы практически обойтись не удаётся (ну иди городить костыли на костылях, чтобы его присутствие не мешало).
          • 0
            Да уж, про костыли тут сказано верно, ни прибавить, ни убавить.
        • +18
          Вся проблема в том, что старые решения уже плохи, но новые несут с собой боль. Много боли. Разумеется, защищённый режим зло. Но UEFI тоже зло — из-за всего того, что в него набили. Всякие secureboot'ы и т.д. У меня UEFI'шный биос предлагает мне обновлять статус в твиттере и фейсбуке. Так сказать, дожили.

          Потребность в замене init'а назрела, но на смену ему пришло что-то невероятно монолитное и и самодостаточное, с встроенным веб-сервером и твиттер-клиентом.

          Грустно это. Вместо того, чтобы реализовать несколько минимальных компонент, каждая из которых очень ясна, проста и имеет мало связей с другими компонентами, мы получили лапшу из взаимных зависимостей, огромный функционал в нескольких крупных кусочках паззла с буквами О Ж П А, которые складываются только в одно слово, а вовсе не в алфавит.

          Оно всё некрасиво и сложно. Это печалит.
          • +2
            Проблема не в том, что systemd не написали просто. Проблема в том, что простые и надёжные альтернативы существуют очень много лет (например runit), но всем плевать!

            У меня Gentoo, и люблю я его в частности за то, что я когда на него переходил 10 лет назад сделал ebuild для runit, ebuild с простым загрузочным скриптом, и ebuild-ы для запуска всех сервисов, так с тех пор у меня вроде и Gentoo, а на самом деле на всех серверах и дома от Gentoo только портаж, а за загрузку и сервисы отвечает runit. В Gentoo за эти годы тоже меняли систему загрузки, один раз точно, а то и пару — был baselayout, сейчас вроде openrc — всё это прошло мимо меня и никак не затронуло. Система загружается одним sh-скриптом на 200 строк. Всё это я когда-то описал в статье "Как загружается Linux".

            Поэтому если Вам не пофиг сложность системы, которую приходится админить — голосуйте ногами, есть ещё дистрибутивы, которые или не бегут по принципу «куда все туда и я» на systemd, или дают возможность настоящего выбора (как Gentoo).
            • 0
              есть ещё дистрибутивы, которые или не бегут по принципу «куда все туда и я» на systemd, или дают возможность настоящего выбора


              А кто кроме gentoo/слаки (и производных) еще не переходит на systemd?
              • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Поддержку Compatibility Support Module пока бросать не собираются минимум до 2017 года, поэтому можно и дальше «наслаждаться» legacy-загрузкой и не беспокоиться о переходе. И со сложностью я бы поспорил, код загрузчика стал намного проще засчет использования UEFI Boot Services и UEFI Runtime Services, исполняемый код в MBR и PBR больше не нужен, мультизагрузка поддерживается из коробки, нынешние проблемы с подменой загрузчика или внедрением кода в UEFI будут вскоре решены внедрением технологии Bios Guard.
        Я не буду отрицать некоторого оверинжениринга при разработке UEFI, и меня во всем стеке технологий UEFI устраивает далеко не все, но то, что было раньше — это такой адский ад, что непонятно, почему UEFI не внедрили на 10 лет раньше.
        • +3
          Раньше я мог сделать раздел на весь диск с /boot. Теперь не могу. Да, есть очень серьёзные идеологические причины, но факт остаётся фактом — раздел-то нужен. И существующий диск загрузочным просто так не сделаешь — надо раздел двигать.
          • 0
            Это минус, да, но зато теперь можно вообще не использовать никакого загрузчика, запуская с ESP непосредственно ядро, и /boot на весь диск станновится не нужен совсем.
            • 0
              ядро тоже в /boot лежит ;-)
              • 0
                Ну так переложить его на ESP вместе с InitRD и вообще /boot удалить, как не нужный более.
                • 0
                  А как чинить поломавшийся initrd/ядро? Раньше был груб, а теперь?
                  • 0
                    А теперь есть UEFI Shell.
                    • 0
                      И я из него могу смонтировать файловую систему (эм… не fat) на LVM и починить что там сломалось? Или рейд пересобрать?
                      • 0
                        Если драйвер этой не-FAT есть — можете. Для HFS, Ext2/3/4 и NTFS драйверы есть уже сейчас.
                        Если EFI-версия утилиты для работы с LVM или RAID есть — можете. Я таких не видел, но только потому, что не интересовался.
                        А еще можете запустить Linux с LiveUSB и чинить все из него, если нет времени искать драйверы и портировать утилиты.
                        • 0
                          А откуда эти дайрвера окажутся в UEFI Shell?

                          Грузиться с внешнего носителя — это уже следующий этап. Раньше у меня был инструментарий для починки системы на месте.
                          • 0
                            Оттуда же, откуда и сам UEFI Shell — с ESP.
                            Если вам нужен такой инструмент — поставьте его. У Windows есть recovery-раздел, у OSX есть recovery-раздел, ничего не мешает сделать себе recovery-раздел с какой-угодно любимой ОС и пользоваться им на месте.
                            Тот факт, что разработчики GRUB добавили в него средства для восстановления работоспособности Linux не имеет никакого отношения к способу загрузки.
                            Хотите иметь GRUB любой ценой — поставьте его и загружайтесь через него, никто не мешает, UEFI-версия существует и отлично работает.
                            • +2
                              Можно уточнить, куда именно на software raid5 надо класть «recovery раздел»? Спасибо.
                              • +1
                                Сразу после EFI System Partition, пожалуйста.
                                И я прошу уточнить, где у вас раньше GRUB стоял, который переживал разваливание software raid5? Спасибо.
                                • +1
                                  Груб устанавливался на все диски из 5ого raid'а (в первые два мегабайта) и дальше мог в случае проблемы вывалиться в grub shell, откуда можно было собрать raid. Под «собрать» я имею в виду не ситуацию потери информации, а ситуацию, когда тома автоматически не собираются в 5ый рейд.

                                  Да, заодно, как будет выглядеть EFI system partition на raid5 диске?
                                  • 0
                                    ESP обязан находиться вне любого software RAID, иначе загрузчик не сможет найти его.
                                    • 0
                                      И после этого вы мне рассказываете про крутость UEFI?
                                      • +1
                                        Да. И я не вижу в этом никакой проблемы.
                                        • 0
                                          Сегодня потребности в ESP на рейде нет, я понял, спасибо.
                                  • +1
                                    Первый раздел на диске — FAT32/100MB/GUID=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, в нем в каталоге /efi/boot лежит файлик GRUB'а — bootx64.efi/grubx64.efi. За ним — раздел с данными RAID.
                                    В первый раздел можно положить драйверы NTFS/EXT3 и т.п., родные для EFI, чтобы с данными можно было работать не только через grub rescue, но и через EFI shell.

                                    К сожалению, EFI не умеет грузится не с раздела, но у BIOS, согласитесь, тоже ограничений хватает, да и GRUB на MBR нужен зазор между началом диска и началом первого раздела, просто этот участок не регистрируется в таблице разделов, как занятый. В EFI это пространство честно выделяется и обладает правами раздела.
                                    • 0
                                      Проблема в синхронизации трёх разделов с /boot. Возможно, кто-то изобретёт соответствующую прослойку, но сейчас это решение выглядит как довольно грязный хак. Ничем не чище старой версии с grub'ом, но много-много-много сложнее.
                                    • +3
                                      EFI умеет грузиться с чего угодно, если для этого чего-угодно создан Device Path. Если производитель материнской платы нужный драйвер в firmware положил — можно смело грузиться хоть с RAID, хоть с USB, хоть с LAN, хоть с COM-порта.
                                      Стандарт говорит о том, что в любой реализации UEFI должен быть драйвер FAT, и что с раздела с вышеприведеннным GUID будет осуществлена автоматическая загрузка, если таковой будет найден, но ESP от этого не становится обязательным. Другой вопрос, что и производители не торопятся добавлять в firmware драйверы всего подряд, и я их прекрасно понимаю.
      • –1
        Причём сложность systemd делает процесс определения «виноватого», мягко говоря, не самым тривиальным, потому что отследить весь процесс старта становится слишком сложно.

        Именно процесс старта, кстати говоря, отследить очень просто
        Скрытый текст
        • 0
          А что будет, если в депенденсах поломается (то есть остановится после запуска) один из сервисов?
          • 0
            Если критичный для загрузки системы, то выкинет в systemctl rescue. А по другим случаем не могу сказать, с таким не встречался. Сейчас попробую что-нибудь сломать и посмотреть, что будет.
            • +3
              Интересует ситуация, когда от сервиса что-то зависит, но он начинает флапать (то есть бесконечно перезапускаться после падения или аварийного завершения).
              • +1
                не бесконечно, а 5 раз (по умолчанию):
                StartLimitInterval=10000000
                StartLimitBurst=5
                StartLimitAction=none
                
                И на этом всё:
                …If none is set, hitting the rate limit will trigger no action besides that the start will not be permitted.…
                И никакой ракетной науки.
                • 0
                  Я о том, как будут отрабатываться обещания сокетов.
                  • 0
                    в смысле сокет-юниты? по умолчанию сокеты остановятся со всеми вытекающими
                    Socket units will have a Before= dependency on the service which they trigger added implicitly. No implicit WantedBy= or RequiredBy= dependency from the socket to the service is added.
                    Note that when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied.
                    • 0
                      То есть все зависящие от сокета сервисы будут остановлены, нсди провайдер сокета умрёт?
                      • 0
                        по умолчанию — да
      • 0
        А что сложного с UEFI то?
      • +2
        Ай, я вот тоже сначала был настроен скептически, но на самом деле там все просто и логично, нет там никакой невероятной сложности. Изучать особо нечего — одного вечера достаточно. Пульс вообще тут никаким местом, оценивать надо продукт, а не личность автора.

        Отлаживать сам systemd администратору не должно понадобиться, а касаемо остального — надо просто привыкнуть к systemctl; на случай серьезных проблем при загрузке есть включаемое бут-параметрами логирование, интерактивный режим и crash shell.

        А вот накой оно черт в данный момент в дебиане в режиме запускалки инит-скриптов, это мне непонятно совершенно.
      • 0
        Отладить sysv-init может любой администратор. Отладить systemd может только системный программист, да ещё с приличным запасом времени.

        Эм. Я смотрел и то и то. Можно как-то пояснить чего там сложного? По мне в systemd оно проще наоборот. Если есть такой странный баг, то он скорее в systemd самом, нежели в сервисе.
        • 0
          > Если есть такой странный баг, то он
          > скорее в systemd самом, нежели в сервисе.

          Ржу, простите :-) Релайебл, мать его!
  • +5
    Я уже с полгода как перешёл на systemd. Жалоб нет. Debian testing.

    Кстати, pulseaudio у меня несколько лет уже работает в бездемоновом режиме через jackd. Всё настроилось с помощью cadence. 5 мс задержка, никаких xrun'ов.
    • 0
      Я сейчас пытаюсь подружить systemd с приложением внутри network namespace и другим пользователем. Проблема в том, что сокет systemd лежит в /run/user/ с правами пользователя, а через lo — pulseaudio не хочет слушать на veth интерфейсе.

      jackd посмотрю, спасибо, что напомнили.
      • 0
        jackd в общем-то тоже стремится открыть аудиоустройство в /dev с правами юзера, как и pulseaudio. А сетевой режим у jackd имхо до сих пор какой-то недоделанный. Так что вряд ли поможет, если я правильно понял постановку задачи.
    • +1
      Вот чувствую я, что надо с этим разбираться. То есть, у вас jack висит на звуковухе, а пульс — его клиент?
      • +1
        Да, именно так. При помощи вот такого трюка

        alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

        pulseaudio думает, что подключается к ALSA-совместимой звуковой карте, а на самом деле оно подключается к JACK.

        Причём никаких описанных там хитрых настроек я не делал, а только убедился в том, что snd-aloop грузится при старте и выбрал опцию в cadence.
        • 0
          с aloop я очень хорошо знаком. Я уж было подумал, пульс сам умеет, без таких трюков… ан нет, костыли.
          • +1
            Ну, если костыль не мешает мне писать 8 дорожек в ардуре и параллельно слушать ютуб, то я это переживу. :)
  • 0
    А я думаю так — На wheezy или trusty ещё можно будет дооооолго работать. А к моменту их устаревания либо systemd допилят, либо форкнут, либо новое что-нить напишут.
    • +2
      Ну, с учётом, что главное достоинство systemd — исправление Фетального Недостатка для red hat, я думаю, надежды на форк слабы.
      • 0
        А что это за недостаток такой?
  • +2
    Debian RIP.

    У меня от таких вещей возникает «Apple-эффект». Ну то есть знаете такое… в рекламе показывают красивый приёмчик… делаешь фотку на телефон, тут же жмёшь кнопочку разместить в Фейсбуке и оно мгновенно там появляется. Вау! Все кричат «как круто» и швыряют свои деньги на прилавок.
    А потом оказывается что кнопка Фейсбука там прибита гвоздями. Не хочешь пользоваться — все равно изволь иметь ее у себя. А никаких других сервисов мы не признаем и их кнопки туда не добавить.

    Это всё равно как если бы вместо буфера обмена каждое приложение могло бы обмениваться данными строго только с какими-то другими приложениями.

    В общем видимо путь мой теперь лежит в сторону LFS
  • +1
    Самое неприятное начнется, когда к systemd начнут привязывать бинарники, так что его придется ставить, чтобы обеспечить работоспособность пакетов. Например, в Debian (testing) уже довольно давно апплет управления NetworkManager'ом для Plasma (plasma-nm) требует libpam-systemd, а тот — systemd. Причем, даже если пакет стоит, но система запускалась через sysvinit, апплет не работает, и, чтобы подключиться к wi-fi, нужно лезть в консоль. Что такого особенного в этом пакете, и почему он не может работать без авторизации именно через systemd, надо смотреть в исходниках.
    • 0
      • 0
        Да, я так тоже пытался. Как я понимаю, systemd-shim нужен, чтобы можно было поставить systemd, не удаляя sysvinit. Но если я ставлю последний plasma-nm, systemd и не изменяю стоку запуска ядра, добавляя init=/bin/systemd, то апплет запускается, но подключиться к wi-fi через него я не могу (
        • 0
          sudo dpkg-reconfigure libpam-runtime, убедиться, что выбран пункт «Register user sessions in the systemd control group hierarchy». По крайней мере, с гномовским nm-applet работает.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Думаю стоит перевести на русский.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Я и предлагаю объединиться.
    • +1
      и news.ycombinator.com/item?id=7639170 для полноты картины
      • +1
        Добавлю еще ссылку на более раннюю дискуссию (там же на Y) + исходная заметка о том, почему systemd is broken by design.
        • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      А тоже самое про upstart есть? А то он инвалид сплошной.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    На самом деле, было бы очень неплохо неписать не пару строк, а пару килобайт про systemd, рассказать о смылсе перехода. Т.е. понятно, что хаброжители часто разбираются в линуксе, но, во-первых, пост и правда по информативности на твит смахивает, а, во-вторых, пост как затравка для беспорядочного обсуждения в комментах хорош, но для образовательных целей, а также как что-то, к чему, спасибо Гуглу, множество людей придет по запросу «что такое systemd» — не очень хорош.

    Тем более от такого автора! )
    • +2
      Ок, объясняю, что такое systemd — гигантское bloatware, которое пытается заменить собой nginx, графический сервер, sudo, gdm, систему передачи сообщений, журналирования и ещё немножно /sbin/init. Продвигается redhat с целью подмять под себя значительный кусок экосистемы линукса.
      • –3
        > Ок, объясняю, что такое systemd — гигантское bloatware
        du -h /lib/systemd/systemd
        1.1M /lib/systemd/systemd

        Целый мегабайт, ужас какой

        > собой nginx
        лол, што? Ну не собирайте сервер, если он не нужен

        > графический сервер
        Бред же
        > sudo
        лол!
        > gdm
        Оукей, у меня есть systemd, как мне входить в систему без kdm? (у меня кеды)
        > систему передачи сообщений
        Вообще-то это dbus, можете его использовать откуда угодно, хоть из init
        > журналирования
        Это очень хорошо, что в демоне можно просто писать в sout и не заботиться ни о чём. Это как раз та простота и unix-way.
        > и ещё немножно /sbin/init
      • 0
        пытается заменить собой nginx, графический сервер, sudo, gdm, систему передачи сообщений
        не затруднит ли пояснить, каким именно образом?
        • 0
          Про nginx, видимо, речь о libmicrohttpd в зависимостях. См. выше.
          • 0
            И как из этого следует:
            >>>пытается заменить собой nginx
            ?
            • 0
              Не знаю, это единственное, что я нашёл на тему встраивания веб-сервера в systemd. Могу только поиграть в телепата.
              • 0
                Тогда понятно, простите, не сразу понял =)
            • 0
              Строк кода в systemd уже почти вдвое больше чем в nginx, и такими темпами скоро будет в 10 раз больше. =)
              • 0
                … Ну и что с того? ;-)
                • +2
                  Я думаю, systemd покажет героические усилия и будет делать в два раза меньше ошибок-на-строку-кода, чтобы количество ошибок в systemd было сравнимым с nginx.

                  Ах, да, на самом деле решение такое: в systemd не будет ошибок. В этом случае не важно, сколько там строк кода. А вот если ошибки будут — размер исходного кода косвенно говорит о числе ошибок.
                  • 0
                    Я думаю, systemd следует разрабатывать как Hurd — Тщательно Продумывать Архитектуру как минимум 20 лет и раз в 8 лет выпускать релизы, которые почти ничего не умеют и едва работают. Главное, чтобы НЕ СМЕЛ СУКА ПОКУШАТЬСЯ НА СВЯ не было ошибок.
              • 0
                такими темпами скоро будет в 10 раз больше. =)
                Слишком оптимистично — когда они вмергают в systemd linux kernel, KDE и скайп, LOC вырастет минимум на два порядка.
      • +1
        Можно вот это всё же обосновать?
        • 0
          нет, т.к. оффтопик :)
          • 0
            ;)
  • 0
    По поводу «неповторимого стиля» вы что не отличаете первоапрельские шутки от новостей?
    • +2
      Текст — шутка. Стиль — нет.
      • 0
        В таком случае предоставьте ссылку на серьёзную новость.
      • 0
        Способность к самоиронии это скорее плюс :)
  • +2
    Никогда не имел проблем с pulseaudio, даже с удовольствием делаю USE=pulseaudio.
    С недавнего времени комфортно юзаю UEFI, даже собираюсь подписать ядро и включить Secure Boot на ноуте.
    Но все эти прелести компенсируются двумя ублюдочными инициативами redhat: ограничение отдельного usr и systemd. Такое ощущение, что по юникс-идеалогии прошлись грязными эппломсовскими сапогами.
    Молюсь на генту с ее openrc и eudev. Пойду что ли им денег переведу.
    • 0
      Но все эти прелести компенсируются двумя ублюдочными инициативами redhat: ограничение отдельного usr и systemd. Такое ощущение, что по юникс-идеалогии прошлись грязными эппломсовскими сапогами.
      Вообще-то отдельный /usr никогда не был «юникс-идеалогией». Изначально в /usr хранились файлы пользователей и системные программы туда попали по одной-единственной причине: кончилось место в корневом разделе. «И самый настоящий из всех настоящих» Unix'ов (Solaris) отказался от поддержки /usr на отдельном разделе лет много лет назад
      • 0
        «И самый настоящий из всех настоящих» Unix'ов (Solaris) отказался от поддержки /usr на отдельном разделе лет много лет назад
        Это Же Совсем Другое Дело
      • 0
        ru.wikipedia.org/wiki/FHS

        В том то и дело. Что началом слияние /usr и / стало то, что системные программы, используемые до монтирования систем стали почему-то инсталировать в /usr.

        Не увидел по Вашей ссылке подтверждения тому, что "(Solaris) отказался от поддержки /usr на отдельном разделе".
        • 0
          /usr вообще нужно было отменить уже давно. Когда-то из-за нехватки места появилась дополнительная иерархия /usr, которая частично является копией /. Но сейчас-то это не нужно, места завались. Пусть всё будет в /.
          • 0
            Дело не только в месте (которого не всегда так уж и завались). Традиционно в корне лежит самое необходимое для запуска системы (в single user mode, причем с остальными разделами можно в это время делать что угодно, без необходимости грузиться со внешней флешки).

            Кроме того, на корень можно назначить свои отдельные опции монтирования, или вообще монтировать его read-only (как говорится, во избежание). Отдельный корень, в случае традиционных файловых систем *nix, где таблица инодов статическая, — меньше вероятность, что внезапно закончится место; проще и быстрее бекапить через dump/restore, etc.
            • +2
              Так и знал.

              Нет, изначально в юниксе в / лежало всё. Ну, кроме того, что было подмонитировано. /home, /var — да, отдельные. Ничто не мешало монтировать / только для чтения, когда никакого /usr и в помине не было. Никто не мешал назначать ему особые опции монтирования.

              Вы предлагаете монтировать / только для чтения, а /usr и для записи? А зачем? Оба они изменяются (в идеале) крайне редко, и как правило — одновременно (/ на самом деле чаще, так как там /etc). А если их оба монтировать только для чтения — какой смысл разделять их? Что именно там будет разным? Смонтировать / со встроенным /usr только для чтения и всего-то.
              Более того, я наверняка размещу всё на LVM и если потребуется ремонт и даже крупное обновление, я перед этим сделаю снепшот, получая дополнительно возможность быстро вернуть всё как было. Если разделять, мне потребуется одинаково обслуживать две одинаковых ФС одинакового назначения.

              На практике ремонт систем по отдельности, нужен крайне редко (если вообще нужен), в моей пятнадцатилетней практике работы с линуксом такое не требовалось ни разу. Сейчас, если какой-то сервер упал — я просто подниму ему замену с нуля (из бекапа), быстро и аккуратно, переключу на неё нагрузку, а потом буду изучать упавшую систему — что это было, и если это не железо, скорее всего всё опять же подниму из бекапа и тогда уже приму меры, чтобы не повторилось. Не понимаю, зачем мне отдельные ФС, чтоб больше телодвижений было?

              Собственно, я никогда в жизни не разделял их и не собираюсь, не представляю ситуацию, где это хоть как-то упростило бы жизнь. Напротив, жду, когда же наконец лишняя иерархия /usr будет объединена с /: /usr/bin -> /bin, /usr/sbin -> /sbin, /usr/lib -> /lib, /usr/local -> /local и так далее, как это изначально задумывалось, чтобы у меня была одна директория для пользовательских утилит (/bin), одна — для системных административных (/sbin) и так далее, а не по две каждого типа.

              Для запуска системы традиционно есть initrd/initramfs и всё, что нужно для запуска, находится в нём. Зачем ещё один слой? Ттрадиционных файловых систем UNIX уже давно никто не использует; кроме того, мы кажется про современный Linux говорим, не так ли?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.