Комментарии 176
Вот прям только что выполнил full-upgrade и где же оно?
# cat /etc/debian_version
jessie/sid
# dpkg -l | grep systemd
ii libsystemd-journal0:amd64
ii libsystemd-login0:amd64
Вероятнее всего, на ваш миррор ещё не свалилось.
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
А объективно у Вас есть какие-нибудь жалобы на systemd, или это просто протест ради протеста?
Если меинтейнеры хорошо поработали, то пользователи ничего не заметят, кроме увеличения скорости загрузки и изменения внешнего вида. Слой совместимости с sysv-скриптами в любом случае остается.
Если меинтейнеры хорошо поработали, то пользователи ничего не заметят, кроме увеличения скорости загрузки и изменения внешнего вида. Слой совместимости с sysv-скриптами в любом случае остается.
У меня есть килограммы претензий к pulseaudio, плюс отношение автора к «легаси-проблемам». Для себя я уже смирился, что придётся изучать. Но без малейшего удовольствия, как неизбежное и неприятное зло.
Главная претензия — оно невероятно сложное. Отладить sysv-init может любой администратор. Отладить systemd может только системный программист, да ещё с приличным запасом времени. Причём сложность systemd делает процесс определения «виноватого», мягко говоря, не самым тривиальным, потому что отследить весь процесс старта становится слишком сложно.
Это в одной категории с UEFI boot. Было старо куце и легаси, но просто. Сделали «ново, модно», но безумно сложно.
Главная претензия — оно невероятно сложное. Отладить sysv-init может любой администратор. Отладить systemd может только системный программист, да ещё с приличным запасом времени. Причём сложность systemd делает процесс определения «виноватого», мягко говоря, не самым тривиальным, потому что отследить весь процесс старта становится слишком сложно.
Это в одной категории с UEFI boot. Было старо куце и легаси, но просто. Сделали «ново, модно», но безумно сложно.
http v2 туда же… Боюсь эта неизбежность ждёт всё. Со временем знать всё на достаточном уровне становится просто невозможно.
Такими темпами могут появиться вакансии «администратор systemd» и т.п.
Такими темпами могут появиться вакансии «администратор systemd» и т.п.
То есть спрайты и скукоженные js и css это нормально, а бинарный http с мультиплексированием это плохо, да?
Всё хорошо. Просто простой базис становится сложным. Тем, кого этот базис интересует с точки зрения полного знания и отладки, становится немножко сложнее жить. И так во всех областях. А в остальном всё хорошо.
Всё хорошо. Просто простой базис становится сложным.По-моему, это происходило всегда в процессе прогресса цивилизации.
Нет. Большую часть времени базис становился проще. Если сравнить арифметику у римлян и во времена Ньютона, можно заметить значительное упрощение. А если сравнить процесс изложения дифференциального исчисления в пост-ньютоновские времена с современным описанием, ньютоновское будет несравнимо сложнее.
Электротехника начала века была адской и ужасной. Сейчас развести проводку куда проще — и надо очень постараться чтобы что-то сделать не так.
Про изучение латыни в школе я даже напоминать не буду.
Электротехника начала века была адской и ужасной. Сейчас развести проводку куда проще — и надо очень постараться чтобы что-то сделать не так.
Про изучение латыни в школе я даже напоминать не буду.
Возможно, вы и правы. Но, прежде, чем появилась сложная электроника и её потом упростили, её вообще небыло. Ну а до изучения латыни в школе было время, когда школ совсем небыло.
Про systemd же, уже сейчас синтаксис .service-файлов, systemctl достаточно прост. И логи интуитивны. А во времена sysvinit где были логи? Да где демон захочет, там и были. А сейчас мы точно знаем, где их искать и как парсить. То есть это стало проще уже только потому, что исчез зоопарк. И логи — только один пример.
Про systemd же, уже сейчас синтаксис .service-файлов, systemctl достаточно прост. И логи интуитивны. А во времена sysvinit где были логи? Да где демон захочет, там и были. А сейчас мы точно знаем, где их искать и как парсить. То есть это стало проще уже только потому, что исчез зоопарк. И логи — только один пример.
Я же не говорю, что sysv-init это чудо инженерной мысли. Оно хак на хаке и костылём подпёрто.
Но новое решение, вместо открытых универсальных компонент вываливает нам в систему гигантский комплект блобов, которые друг с другом подогнаны а о других ни сном, ни духом.
… Кажется, надо переползать в область метафор. Это называется «ремонтопригодность». Эпплофаги в восторге от яблочка, мастера по ремонту матерятся по поводу клея всюду вместо винтов.
systemd нельзя разобрать на кусочки. sysv-init — можно. Он неказистый, зато понятный.
Но новое решение, вместо открытых универсальных компонент вываливает нам в систему гигантский комплект блобов, которые друг с другом подогнаны а о других ни сном, ни духом.
… Кажется, надо переползать в область метафор. Это называется «ремонтопригодность». Эпплофаги в восторге от яблочка, мастера по ремонту матерятся по поводу клея всюду вместо винтов.
systemd нельзя разобрать на кусочки. sysv-init — можно. Он неказистый, зато понятный.
А можно поподробнее про блобы в systemd?
Какие зависимости у logind? Что ему нужно для работы? Почему init имеет связи с udev'ом?
А почему бы ему не иметь связи с udev? Покажите мне хоть один вменяемый дистрибутив без udev. Ну и про блобы, пожалуйста, коммит в основную ветку systemd с блобом.
А почему бы ему не иметь связи ещё с кучей других сервисов? Это типовой виндузятный подход — если чаще всего оно есть, значит, можно линковаться. А если нет? Проблемы негров шерифа не волнуют? А если будет принято решение переделать udev, то, внезапно «оно ломает systems?»
Не надо с больной головы на здоровую. Речь шла о блобах. udev разработан в недрах systemd. Вы хотите systemd без udev? Ну сделайте форк, кто мешает то? Ещё systemd завязан на Linux, на других ядрах работать не будет. Хотите поддержку своего любимого ядра — делайте форк.
Про виндузовый подход не понятно, там же «всё своё ношу с собой».
Про виндузовый подход не понятно, там же «всё своё ношу с собой».
Я конечно буду банален. А документацию читать пробовали? К примеру дерево зависимостей можно посмотреть следующей командой:
Потому что это systemd. А связь с udev ему требуется, чтобы при старте системы осуществить инициализацию /dev
systemctl list-dependencies
Почему init имеет связи с udev'ом?
Потому что это systemd. А связь с udev ему требуется, чтобы при старте системы осуществить инициализацию /dev
А почему он вообще осуществляет конфигурацию устройств, но при этом не готовит кофе?
facepalm.jpg все что я тут могу сказать. udev является частью systemd. По этой причине и осуществляет. Я не сказать что в восторге от того что он более монолитен, чем sysv-init или upstart. Но это с точки зрения разработчика требуется, чтобы ускорить работу. Опять же в embedded это плюс, так-как кода получается меньше.
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
В embedded (настоящем, а не который с «флешом на 32Мб»), инит, который занимает 6Мб, это позор.
dpkg -l|grep systemd|awk '{print $2}'|xargs dpkg -L|xargs ls -lad|awk '{a+=$5}END{print a}'
6087907
udev появился задолго до systemd, и их «блобоинтеграция» получилась отвратительной.
Те же люди писали. В итоге они его поместили в systemd. И при этом оставили возможность использовать его отдельно от systemd. В случае если используется вместе с systemd экономится время на загрузку и уменьшается размер сервиса.
В настоящий embedded linux не кладут. Смысла нет. А где кладут, то там проблемы с 6 мегабайтами не наблюдается и да там можно при сборке много что повыкидывать из systemd так что он будет меньше. И да то как вы считаете еще туда всю документацию включает. Если же посмотреть чисто бинарники то у меня это 4 мегабайта.
У меня относительно маленький опыт в embedded, но по моим воспоминаниям для не очень сложной железки размер «фирмвари» под линуксом был 2Мб. Строго и ровно.
Более того, сейчас в комьюнити идёт особый срач на тему minimize footprint (internet of things, $0.5 за компьютер и всё такое). И в условиях срача за 400кб TCP-стека 6Мб на /sbin/init выглядит как… ну, «пусть едят пирожные».
Я к тому, что монолитный дизайн (а что бы Поттеринг не говорил, получается монолитный блобик) — это зло. Вместо аккуратного конструктора — лапша из зависимостей и огромный функционал там, где его не ожидают (нахрена там встроенный веб-сервер?)
Более того, сейчас в комьюнити идёт особый срач на тему minimize footprint (internet of things, $0.5 за компьютер и всё такое). И в условиях срача за 400кб TCP-стека 6Мб на /sbin/init выглядит как… ну, «пусть едят пирожные».
Я к тому, что монолитный дизайн (а что бы Поттеринг не говорил, получается монолитный блобик) — это зло. Вместо аккуратного конструктора — лапша из зависимостей и огромный функционал там, где его не ожидают (нахрена там встроенный веб-сервер?)
У меня относительно маленький опыт в 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 его берет?
Я этот срач внимательно читаю. Посылают их товарищи с жирных десктопов и серверов. С учётом, что «если не линукс, то кто-нибудь другой», интереса Интела и ситуации, когда подобное железо будет востребовано, я думаю, здравый смысл победит.
О политике вокруг systemd можно много говорить.
Что sysv-init не аккуратный конструктор а артефакт-переросток я уже выше писал. Но это не означает, что его замена должна быть столь громоздкой и немодулярной.
«Отключение функционала при сборке» — это не совсем то, о чём я говорю. Хорошие универсальные компоненты можно использовать как самостоятельные инструменты. Огромные блобо-куски — только там, куда их написали. Об этом и скорбь. Много кода, гигантский функционал, который «делает всё».
О политике вокруг systemd можно много говорить.
Что sysv-init не аккуратный конструктор а артефакт-переросток я уже выше писал. Но это не означает, что его замена должна быть столь громоздкой и немодулярной.
«Отключение функционала при сборке» — это не совсем то, о чём я говорю. Хорошие универсальные компоненты можно использовать как самостоятельные инструменты. Огромные блобо-куски — только там, куда их написали. Об этом и скорбь. Много кода, гигантский функционал, который «делает всё».
Я этот срач внимательно читаю. Посылают их товарищи с жирных десктопов и серверов. С учётом, что «если не линукс, то кто-нибудь другой», интереса Интела и ситуации, когда подобное железо будет востребовано, я думаю, здравый смысл победит.
Пока людям говорят, что они страдают фигней. И я считаю, что те кто это говорит правы. Так-как в свете нам надо минимум 4 мегабайта памяти для работы выпиливание 400кб стека полная фигня.
Что sysv-init не аккуратный конструктор а артефакт-переросток я уже выше писал. Но это не означает, что его замена должна быть столь громоздкой и немодулярной.
Попытки сделать что-то лучше предпринимались не раз. Тот же upstart, но я бы не сказал что они удачны. На данный момент сама спецификация которую задает systemd весьма удачна.
«Отключение функционала при сборке» — это не совсем то, о чём я говорю. Хорошие универсальные компоненты можно использовать как самостоятельные инструменты.
Не получится. Если делать отдельными универсальными инструментами, опять получим sysvinit. Замечу там где функционал четко выделяется, отдельные сервисы сделаны. Тот же journal и logind. Но вообще говоря конечно бы неплохо чтобы функционал подключался через библиотеки, а не как сейчас при сборке в один модуль. Но это я думаю сделают.
Огромные блобо-куски — только там, куда их написали. Об этом и скорбь. Много кода, гигантский функционал, который «делает всё».
Это все чинится в том числе сообществом. Вон с glibc жили жили, как стало прижимать сделали свой eglibc. Так может произойти и с systemd. Главное чтобы при этом новый systemd был совместим со старым по спецификации.
в systemd есть встроенный веб-сервер? ебанулись точно.
Не то, чтобы встроенный — libmicrohttpd в зависимостях. И ещё генерация QR-кодов через qrencode-libs
Инфа отсюда: thread.gmane.org/gmane.linux.redhat.fedora.devel/169082
Инфа отсюда: thread.gmane.org/gmane.linux.redhat.fedora.devel/169082
Плохо, что именно бинарный.
Чем же?
Тем, что прочитать глазами не получится без спец. инструментов.
Вы давно читали дамп http без инструментов браузера или wireshark?
Почти постоянно.
И да, я его использую в ежедневной работе для отладки, проверки гипотез и т.д.
nc -l 80 — и у вас готовый веб-сервер. Которому можно даже что-то ответить. Аналогично, nc foobar 80 — и у вас готовый веб-клиент, куда можно написать за разумное число усилий HTTP запрос.И да, я его использую в ежедневной работе для отладки, проверки гипотез и т.д.
http2 позволит (что сходу пришло в голову) избавиться от грязных оптимизаций веб-мастеров (спрайты, сжатия нескольких скриптов\стилей в один файл), от грязных оптимизаций браузеров, которые зарание открывают по несколько TCP-соединений, даже если это ещё не нужно, чтобы потом было быстрее, от проблем разрыва передачи большого файла и т. д.
Всё это не без помощи мультиплексирования, которое было бы сложно реализовать без бинаризации протокола.
Так вот, Вы предлагаете от всего этого отказаться, чтобы можно было netcat-ом просто делать http-клиент и сервер, так?
Вообще, для тестового клиента есть curl. Для тестового сервера я предпочёл бы набросать код в ipython.
Всё это не без помощи мультиплексирования, которое было бы сложно реализовать без бинаризации протокола.
Так вот, Вы предлагаете от всего этого отказаться, чтобы можно было netcat-ом просто делать http-клиент и сервер, так?
Вообще, для тестового клиента есть curl. Для тестового сервера я предпочёл бы набросать код в ipython.
Ни кто не предлагает ни от чего отказываться, просто для нас ощутим факт того, что некая программная сущность (будь то система инициализации или протокол) становится сложнее в осознании и дэбаге.
Бред т.к. это не объясняет бинаризацию протокола.
Единственное объяснение, что я могу придумать — это необходимость drm. Т.к. drm с текстовым и простым в дебаге протоколом общаться не захочет.
Сам http без проблем можно превратить в http2, загнав все в блоб base64 и раскрыв это яваскриптом в браузере клиента.
Опять же проблему сессий — главный недостаток http — оно не решает, хотя решения для этого есть!
Единственное объяснение, что я могу придумать — это необходимость drm. Т.к. drm с текстовым и простым в дебаге протоколом общаться не захочет.
Сам http без проблем можно превратить в http2, загнав все в блоб base64 и раскрыв это яваскриптом в браузере клиента.
Опять же проблему сессий — главный недостаток http — оно не решает, хотя решения для этого есть!
BTW, предположу, что дампящий прокси уровня TCP для HTTP2 будет писаться в сто-двести строк Erlang-а.
Но, конечно, к systemd этот подход неприменим, и это ужасно. Я со своего дилетантского уровня не вижу, в чем проблема с upstart, и категорически не понимаю, почему не взяли его. Он же простой как три рубля и вроде бы вполне логичный.
Но, конечно, к systemd этот подход неприменим, и это ужасно. Я со своего дилетантского уровня не вижу, в чем проблема с upstart, и категорически не понимаю, почему не взяли его. Он же простой как три рубля и вроде бы вполне логичный.
Я со своего дилетантского уровня не вижу, в чем проблема с upstart, и категорически не понимаю, почему не взяли его.
Потому что он хуже systemd. Я в свое время смотрел на него. И я бы не сказал что он сильно лучше systemd. И да довольно долгое время upstart требовал sysv-init в комплекте так-как у него небыло команд shutdown и reboot из коробки.
Потому что он хуже systemd. Я в свое время смотрел на него. И я бы не сказал что он сильно лучше systemd.Это не выглядит сильной аргументацией в пользу systemd.
Для более сильной аргументации сравните банально что можно в файле описания сервиса upstart и что в systemd в случае systemd делать какую-то обертку нужно существенно реже чем в случае upstart.
Ну, не знаю. У меня на upstart-е практически с пол-пинка завелась тулза на все том же э-ге, собранная в релиз. А релизы, прямо скажем, не самая дружественная init-ам штука.
systemd отчетливо хуже, потому что он комплекснее, в него затащили кучу каких-то unrelated вещей, и он навязывает какие-то свои конвенции и интерфейсы. upstart — простой supervisor, не больше и не меньше.
systemd отчетливо хуже, потому что он комплекснее, в него затащили кучу каких-то unrelated вещей, и он навязывает какие-то свои конвенции и интерфейсы. upstart — простой supervisor, не больше и не меньше.
Разумное число усилий?
Серьезно?
Это так сложно?
GET / HTTP/1.0\n
Host: ip\n
\n\n
Серьезно, почему тот же SMTP бинарным не сделали? У меня такое чувство, что http2 и html5 drm чем-то связаны и очень крепко и отсюда вот эти бинарные подвижки.
Серьезно?
Это так сложно?
GET / HTTP/1.0\n
Host: ip\n
\n\n
Серьезно, почему тот же SMTP бинарным не сделали? У меня такое чувство, что http2 и html5 drm чем-то связаны и очень крепко и отсюда вот эти бинарные подвижки.
Я иногда говорю на чистом HTTP в целях отладки. Просто telnet host http и поехали, GET /.../ HTTP/1.1 и так далее
telnet опасен тем, что он не совсем чисто использует plain tcp. nc куда лучше.
см. #
Ниже уже написали, зачем это всё нужно, а я просто дам ссылку на хорошую книгу, а именно место:
1.8. Применение философии Unix
…
Структура баз данных и протоколы приложений должны быть, если это возможно, текстовыми (доступными человеку для чтения и редактирования).
Структура баз данных и протоколы приложений должны быть, если это возможно, текстовыми...Ну вы понели? А выше я писал, почему это теперь стало невозможно.если это возможно
Во-первых, вы писали, что это сложно, а не невозможно. Во-вторых, и это-то спорно:
> не без помощи мультиплексирования, которое было
> бы сложно реализовать без бинаризации протокола.
Почему? Бинарный вид или текстовый вид — это всего лишь форматы представления данных. С точки зрения алгоритмизации между этими представлениями данных нет принципиальной разницы.
> не без помощи мультиплексирования, которое было
> бы сложно реализовать без бинаризации протокола.
Почему? Бинарный вид или текстовый вид — это всего лишь форматы представления данных. С точки зрения алгоритмизации между этими представлениями данных нет принципиальной разницы.
Тем, что если безупречная программа правильно запишет сообщение об отсутствии ошибки, гениальный пользователь, способный читать в hex-кодах, сможет не читать его с целью не исправления идеально работающей программы.
Что, простите?
Нет, я правда ничего не понял.
Нет, я правда ничего не понял.
Ок, пишу без сарказма. Тем, что если глючная поделка криво запишет сообщение об ошибке другой программы, средний пользователь, не умеющий читать бинарный формат в hex-редакторе (а обычный свалится на битом файле) не сможет прочитать это сообщение для исправления ошибки.
Я давно не видел, чтобы даже глючные поделки сами реализовывали тот же http 1.x. Есть же готовые библиотеки для этого.
Да и ситуация выглядит слишком уж гипотетической. Сомнительный минус при очевидных плюсах.
Да и ситуация выглядит слишком уж гипотетической. Сомнительный минус при очевидных плюсах.
Я буквально на в начале месяца отлаживал отправку логов. С nc и tcpdump'ом в руках. Печально, что отбирают.
А я отлаживал бинарный протокол с tcpdump. По сути какая разница-то?
Тестовые данные вы как отсылали?
А я писал клиент на elang, там всё просто.
Ну да, писать программы для отладки сети — это так обычно и по-юниксовски. Каждый стадион, решивший разобраться с логгингом может написать программу на эрланге и перестать страдать по поводу текста и nc.
Казалось, бы причём тут systemd? Парсить бинарные данные простейшим скриптом можно абсолютно на чём угодно. ЧТо мешает перенаправить вывод tcpdump? Ничего что сам tcp бинарный, вам это сильно мешает?
НЛО прилетело и опубликовало эту надпись здесь
Я реально хочу посмотреть на процесс отладки «ерлангом» коннекта с маршрутизатора на сервер. Вот берём мы juniper потолще, вываливаемся в freebsd внутрях, набираем nc server 80… Ой, я хотел сказать, идём в порты, ставим эрланг, пишем программу… На маршрутизаторе, да?
НЛО прилетело и опубликовало эту надпись здесь
Я не понимаю, что странного в процессе отладки http с любого сетевого устройства. Надо выяснить, что происходит. Например, злобный ростелеком странно реагирует на заголовки и надо исключить сам маршрутизатор из рассмотрения. Сравниваем реакцию на заголовки из сети за маршрутизатором с поведением на самом маршрутизаторе.
Ну, то есть я понимаю, что это же http2, там всё не просто так. Суть скорби в том, что раньше было «просто так», а теперь становится «не просто».
Ну, то есть я понимаю, что это же http2, там всё не просто так. Суть скорби в том, что раньше было «просто так», а теперь становится «не просто».
НЛО прилетело и опубликовало эту надпись здесь
Мы обсуждали удобство администраторов в отладке http и http2. Вы сказали, что писать программы на эрланге это здорово и правильно, и что все системные администраторы должны этим заниматься. Возможно не точно так, но так прозвучало.
Я привёл пример сценария, когда писать программы на эрланге будет глупо, даже если оставить в стороне максиму «хочешь отладить систему — пиши программы».
Я привёл пример сценария, когда писать программы на эрланге будет глупо, даже если оставить в стороне максиму «хочешь отладить систему — пиши программы».
НЛО прилетело и опубликовало эту надпись здесь
Я лично эрланг не перевариваю. И если для внедрения нового протокола будет обязательным писать программы на эрланге, то хрен вам лысый, а не http2.
В итоге мы пришли к выводу, что вас неустраивает systemd, потому что у вас в embedded меньше 6MB. Отлично, зачем вам там Debian? Полно специализированных дистрибутивов, которые заточены под маленькую оепративную память. Там нет systemd. На декстопе systemd ускоряет загрузку за счёт параллельного исполнения. Конфигурировать unit файлы намного проще, чем ковырять неведомый слой отходов жизнедеятельности мамонтов в виде init скриптов. Ещё с учётом, что все инитскрипты разные для разных дистрибутивов. Пробовали перенести скрипт с Дебиана на Сузе, например? Systemd нужен для general-propose. Если у вас что-то специфическое, используйте что-то специфическое, кто мешает?
Вас не устраивает http2 потому что вам трудно сниффить это роутере. Ну что поделать, может вас ещё не устраивают компилируемые языки, что исполняемый файл не human readable? Будет вам http2dump, в чём проблема?
Вас не устраивает http2 потому что вам трудно сниффить это роутере. Ну что поделать, может вас ещё не устраивают компилируемые языки, что исполняемый файл не human readable? Будет вам http2dump, в чём проблема?
> 2. если исходить из предположения, что з/п нормального сисадмина приблизительно равна з/п программиста
По этой логике почему бы сисадмина не обязать не заниматься, скажем, хирургией заодно?
По этой логике почему бы сисадмина не обязать не заниматься, скажем, хирургией заодно?
Вакансии нет, а вот звание «гуру системд» можно вполне иметь и получать от этого лучи уважения от остальных сотрудников, которые в нём ни бельмеса.
Я тоже был против systemd, но оно действительно неплохое. Ну, есть, конечно, нюансы, но в целом работает быстро, утилиты удобные (управлять сервисами мне нравится гораздо больше в systemd, нежели в sysvinit), тот же journald достаточно интересный. Загрузка происходит быстро. Юниты писать проще простого.
Pulseaudio тоже долгое время не пользовался, а сейчас перешел. К нему тоже вопросов у меня много. Перешел из-за того, что мне одно время приходилось много записывать с «монитора», а в alsa это получалось неудобно.
Pulseaudio тоже долгое время не пользовался, а сейчас перешел. К нему тоже вопросов у меня много. Перешел из-за того, что мне одно время приходилось много записывать с «монитора», а в alsa это получалось неудобно.
Главная претензия — оно невероятно сложное. Отладить 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
Это в одной категории с UEFI boot. Было старо куце и легаси, но просто. Сделали «ново, модно», но безумно сложно.Боже, а с UEFI-то что не так в плане сложности? Я вот всегда мечтал делать загрузочные флешки простым копированием файлов. UEFI так позволяет делать.
Это пожалуй единственное, что стало проще. Вы само UEFI-приложение, которое можно скопировать на флешку и оно так запустится, сделать пробовали?
Я пробовал, и не вижу причин для беспокойства.
Да, EDK поначалу кажется сложным, но сборочная стреда настраивается один раз, а потом для сборки остается только GUID придумать и INF-файл правильно написать. Другое дело, что нужно API изучать, но оно в разы проще для понимания, чем прерывания старого BIOS'а.
Да, EDK поначалу кажется сложным, но сборочная стреда настраивается один раз, а потом для сборки остается только GUID придумать и INF-файл правильно написать. Другое дело, что нужно API изучать, но оно в разы проще для понимания, чем прерывания старого BIOS'а.
А что, oss/alsa работали лучше? У меня на ноутбуке pulseaudio вполне справляется с поставленными задачами. Ну и не понятно, почему отношение к продукту диктуется отношением к другому продукту того же разработчика.
Лог у systemd настолько полный (может быть даже слишком?), что разобраться при портировании init-скриптов на systemd с тем, что происходит, у меня получилось очень легко. Если речь идет об отлавливании багов в самом systemd, то, возможно, этим действительно должны заниматься программисты, а не сисадмины?
Ну и пожалуйста, не говорите, что считаете, что в 2014 году дата и время должны храниться в BCD, а загрузчик запускаться в реальном режиме. Излишняя усложненность — это лишь попытка максимально оттянуть дату необходимости разработки следующего нового стандарта.
Лог у systemd настолько полный (может быть даже слишком?), что разобраться при портировании init-скриптов на systemd с тем, что происходит, у меня получилось очень легко. Если речь идет об отлавливании багов в самом systemd, то, возможно, этим действительно должны заниматься программисты, а не сисадмины?
Ну и пожалуйста, не говорите, что считаете, что в 2014 году дата и время должны храниться в BCD, а загрузчик запускаться в реальном режиме. Излишняя усложненность — это лишь попытка максимально оттянуть дату необходимости разработки следующего нового стандарта.
А что, oss/alsa работали лучше? У меня на ноутбуке pulseaudio вполне справляется с поставленными задачами. Ну и не понятно, почему отношение к продукту диктуется отношением к другому продукту того же разработчика.
Да. У альсы предсказуемая и небольшая задержка. У пульса она большая и непредсказуемая. Попробуйте работать с музыкой на компе, резко поймёте, что без полного удаления пульса с системы практически обойтись не удаётся (ну иди городить костыли на костылях, чтобы его присутствие не мешало).
Вся проблема в том, что старые решения уже плохи, но новые несут с собой боль. Много боли. Разумеется, защищённый режим зло. Но UEFI тоже зло — из-за всего того, что в него набили. Всякие secureboot'ы и т.д. У меня UEFI'шный биос предлагает мне обновлять статус в твиттере и фейсбуке. Так сказать, дожили.
Потребность в замене init'а назрела, но на смену ему пришло что-то невероятно монолитное и и самодостаточное, с встроенным веб-сервероми твиттер-клиентом.
Грустно это. Вместо того, чтобы реализовать несколько минимальных компонент, каждая из которых очень ясна, проста и имеет мало связей с другими компонентами, мы получили лапшу из взаимных зависимостей, огромный функционал в нескольких крупных кусочках паззла с буквами О Ж П А, которые складываются только в одно слово, а вовсе не в алфавит.
Оно всё некрасиво и сложно. Это печалит.
Потребность в замене init'а назрела, но на смену ему пришло что-то невероятно монолитное и и самодостаточное, с встроенным веб-сервером
Грустно это. Вместо того, чтобы реализовать несколько минимальных компонент, каждая из которых очень ясна, проста и имеет мало связей с другими компонентами, мы получили лапшу из взаимных зависимостей, огромный функционал в нескольких крупных кусочках паззла с буквами О Ж П А, которые складываются только в одно слово, а вовсе не в алфавит.
Оно всё некрасиво и сложно. Это печалит.
Проблема не в том, что systemd не написали просто. Проблема в том, что простые и надёжные альтернативы существуют очень много лет (например runit), но всем плевать!
У меня Gentoo, и люблю я его в частности за то, что я когда на него переходил 10 лет назад сделал ebuild для runit, ebuild с простым загрузочным скриптом, и ebuild-ы для запуска всех сервисов, так с тех пор у меня вроде и Gentoo, а на самом деле на всех серверах и дома от Gentoo только портаж, а за загрузку и сервисы отвечает runit. В Gentoo за эти годы тоже меняли систему загрузки, один раз точно, а то и пару — был baselayout, сейчас вроде openrc — всё это прошло мимо меня и никак не затронуло. Система загружается одним sh-скриптом на 200 строк. Всё это я когда-то описал в статье "Как загружается Linux".
Поэтому если Вам не пофиг сложность системы, которую приходится админить — голосуйте ногами, есть ещё дистрибутивы, которые или не бегут по принципу «куда все туда и я» на systemd, или дают возможность настоящего выбора (как Gentoo).
У меня Gentoo, и люблю я его в частности за то, что я когда на него переходил 10 лет назад сделал ebuild для runit, ebuild с простым загрузочным скриптом, и ebuild-ы для запуска всех сервисов, так с тех пор у меня вроде и Gentoo, а на самом деле на всех серверах и дома от Gentoo только портаж, а за загрузку и сервисы отвечает runit. В Gentoo за эти годы тоже меняли систему загрузки, один раз точно, а то и пару — был baselayout, сейчас вроде openrc — всё это прошло мимо меня и никак не затронуло. Система загружается одним sh-скриптом на 200 строк. Всё это я когда-то описал в статье "Как загружается Linux".
Поэтому если Вам не пофиг сложность системы, которую приходится админить — голосуйте ногами, есть ещё дистрибутивы, которые или не бегут по принципу «куда все туда и я» на systemd, или дают возможность настоящего выбора (как Gentoo).
Поддержку Compatibility Support Module пока бросать не собираются минимум до 2017 года, поэтому можно и дальше «наслаждаться» legacy-загрузкой и не беспокоиться о переходе. И со сложностью я бы поспорил, код загрузчика стал намного проще засчет использования UEFI Boot Services и UEFI Runtime Services, исполняемый код в MBR и PBR больше не нужен, мультизагрузка поддерживается из коробки, нынешние проблемы с подменой загрузчика или внедрением кода в UEFI будут вскоре решены внедрением технологии Bios Guard.
Я не буду отрицать некоторого оверинжениринга при разработке UEFI, и меня во всем стеке технологий UEFI устраивает далеко не все, но то, что было раньше — это такой адский ад, что непонятно, почему UEFI не внедрили на 10 лет раньше.
Я не буду отрицать некоторого оверинжениринга при разработке UEFI, и меня во всем стеке технологий UEFI устраивает далеко не все, но то, что было раньше — это такой адский ад, что непонятно, почему UEFI не внедрили на 10 лет раньше.
Раньше я мог сделать раздел на весь диск с /boot. Теперь не могу. Да, есть очень серьёзные идеологические причины, но факт остаётся фактом — раздел-то нужен. И существующий диск загрузочным просто так не сделаешь — надо раздел двигать.
Это минус, да, но зато теперь можно вообще не использовать никакого загрузчика, запуская с ESP непосредственно ядро, и /boot на весь диск станновится не нужен совсем.
ядро тоже в /boot лежит ;-)
Ну так переложить его на ESP вместе с InitRD и вообще /boot удалить, как не нужный более.
А как чинить поломавшийся initrd/ядро? Раньше был груб, а теперь?
А теперь есть UEFI Shell.
И я из него могу смонтировать файловую систему (эм… не fat) на LVM и починить что там сломалось? Или рейд пересобрать?
Если драйвер этой не-FAT есть — можете. Для HFS, Ext2/3/4 и NTFS драйверы есть уже сейчас.
Если EFI-версия утилиты для работы с LVM или RAID есть — можете. Я таких не видел, но только потому, что не интересовался.
А еще можете запустить Linux с LiveUSB и чинить все из него, если нет времени искать драйверы и портировать утилиты.
Если EFI-версия утилиты для работы с LVM или RAID есть — можете. Я таких не видел, но только потому, что не интересовался.
А еще можете запустить Linux с LiveUSB и чинить все из него, если нет времени искать драйверы и портировать утилиты.
А откуда эти дайрвера окажутся в UEFI Shell?
Грузиться с внешнего носителя — это уже следующий этап. Раньше у меня был инструментарий для починки системы на месте.
Грузиться с внешнего носителя — это уже следующий этап. Раньше у меня был инструментарий для починки системы на месте.
Оттуда же, откуда и сам UEFI Shell — с ESP.
Если вам нужен такой инструмент — поставьте его. У Windows есть recovery-раздел, у OSX есть recovery-раздел, ничего не мешает сделать себе recovery-раздел с какой-угодно любимой ОС и пользоваться им на месте.
Тот факт, что разработчики GRUB добавили в него средства для восстановления работоспособности Linux не имеет никакого отношения к способу загрузки.
Хотите иметь GRUB любой ценой — поставьте его и загружайтесь через него, никто не мешает, UEFI-версия существует и отлично работает.
Если вам нужен такой инструмент — поставьте его. У Windows есть recovery-раздел, у OSX есть recovery-раздел, ничего не мешает сделать себе recovery-раздел с какой-угодно любимой ОС и пользоваться им на месте.
Тот факт, что разработчики GRUB добавили в него средства для восстановления работоспособности Linux не имеет никакого отношения к способу загрузки.
Хотите иметь GRUB любой ценой — поставьте его и загружайтесь через него, никто не мешает, UEFI-версия существует и отлично работает.
Можно уточнить, куда именно на software raid5 надо класть «recovery раздел»? Спасибо.
Сразу после EFI System Partition, пожалуйста.
И я прошу уточнить, где у вас раньше GRUB стоял, который переживал разваливание software raid5? Спасибо.
И я прошу уточнить, где у вас раньше GRUB стоял, который переживал разваливание software raid5? Спасибо.
Груб устанавливался на все диски из 5ого raid'а (в первые два мегабайта) и дальше мог в случае проблемы вывалиться в grub shell, откуда можно было собрать raid. Под «собрать» я имею в виду не ситуацию потери информации, а ситуацию, когда тома автоматически не собираются в 5ый рейд.
Да, заодно, как будет выглядеть EFI system partition на raid5 диске?
Да, заодно, как будет выглядеть EFI system partition на raid5 диске?
ESP обязан находиться вне любого software RAID, иначе загрузчик не сможет найти его.
Первый раздел на диске — 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 это пространство честно выделяется и обладает правами раздела.
В первый раздел можно положить драйверы NTFS/EXT3 и т.п., родные для EFI, чтобы с данными можно было работать не только через grub rescue, но и через EFI shell.
К сожалению, EFI не умеет грузится не с раздела, но у BIOS, согласитесь, тоже ограничений хватает, да и GRUB на MBR нужен зазор между началом диска и началом первого раздела, просто этот участок не регистрируется в таблице разделов, как занятый. В EFI это пространство честно выделяется и обладает правами раздела.
Проблема в синхронизации трёх разделов с /boot. Возможно, кто-то изобретёт соответствующую прослойку, но сейчас это решение выглядит как довольно грязный хак. Ничем не чище старой версии с grub'ом, но много-много-много сложнее.
EFI умеет грузиться с чего угодно, если для этого чего-угодно создан Device Path. Если производитель материнской платы нужный драйвер в firmware положил — можно смело грузиться хоть с RAID, хоть с USB, хоть с LAN, хоть с COM-порта.
Стандарт говорит о том, что в любой реализации UEFI должен быть драйвер FAT, и что с раздела с вышеприведеннным GUID будет осуществлена автоматическая загрузка, если таковой будет найден, но ESP от этого не становится обязательным. Другой вопрос, что и производители не торопятся добавлять в firmware драйверы всего подряд, и я их прекрасно понимаю.
Стандарт говорит о том, что в любой реализации UEFI должен быть драйвер FAT, и что с раздела с вышеприведеннным GUID будет осуществлена автоматическая загрузка, если таковой будет найден, но ESP от этого не становится обязательным. Другой вопрос, что и производители не торопятся добавлять в firmware драйверы всего подряд, и я их прекрасно понимаю.
Причём сложность systemd делает процесс определения «виноватого», мягко говоря, не самым тривиальным, потому что отследить весь процесс старта становится слишком сложно.
Именно процесс старта, кстати говоря, отследить очень просто
Скрытый текст
А что будет, если в депенденсах поломается (то есть остановится после запуска) один из сервисов?
Если критичный для загрузки системы, то выкинет в systemctl rescue. А по другим случаем не могу сказать, с таким не встречался. Сейчас попробую что-нибудь сломать и посмотреть, что будет.
А что сложного с UEFI то?
Ай, я вот тоже сначала был настроен скептически, но на самом деле там все просто и логично, нет там никакой невероятной сложности. Изучать особо нечего — одного вечера достаточно. Пульс вообще тут никаким местом, оценивать надо продукт, а не личность автора.
Отлаживать сам systemd администратору не должно понадобиться, а касаемо остального — надо просто привыкнуть к systemctl; на случай серьезных проблем при загрузке есть включаемое бут-параметрами логирование, интерактивный режим и crash shell.
А вот накой оно черт в данный момент в дебиане в режиме запускалки инит-скриптов, это мне непонятно совершенно.
Отлаживать сам systemd администратору не должно понадобиться, а касаемо остального — надо просто привыкнуть к systemctl; на случай серьезных проблем при загрузке есть включаемое бут-параметрами логирование, интерактивный режим и crash shell.
А вот накой оно черт в данный момент в дебиане в режиме запускалки инит-скриптов, это мне непонятно совершенно.
Отладить sysv-init может любой администратор. Отладить systemd может только системный программист, да ещё с приличным запасом времени.
Эм. Я смотрел и то и то. Можно как-то пояснить чего там сложного? По мне в systemd оно проще наоборот. Если есть такой странный баг, то он скорее в systemd самом, нежели в сервисе.
Я уже с полгода как перешёл на systemd. Жалоб нет. Debian testing.
Кстати, pulseaudio у меня несколько лет уже работает в бездемоновом режиме через jackd. Всё настроилось с помощью cadence. 5 мс задержка, никаких xrun'ов.
Кстати, pulseaudio у меня несколько лет уже работает в бездемоновом режиме через jackd. Всё настроилось с помощью cadence. 5 мс задержка, никаких xrun'ов.
Я сейчас пытаюсь подружить systemd с приложением внутри network namespace и другим пользователем. Проблема в том, что сокет systemd лежит в /run/user/ с правами пользователя, а через lo — pulseaudio не хочет слушать на veth интерфейсе.
jackd посмотрю, спасибо, что напомнили.
jackd посмотрю, спасибо, что напомнили.
Вот чувствую я, что надо с этим разбираться. То есть, у вас jack висит на звуковухе, а пульс — его клиент?
Да, именно так. При помощи вот такого трюка
alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge
pulseaudio думает, что подключается к ALSA-совместимой звуковой карте, а на самом деле оно подключается к JACK.
Причём никаких описанных там хитрых настроек я не делал, а только убедился в том, что snd-aloop грузится при старте и выбрал опцию в cadence.
alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge
pulseaudio думает, что подключается к ALSA-совместимой звуковой карте, а на самом деле оно подключается к JACK.
Причём никаких описанных там хитрых настроек я не делал, а только убедился в том, что snd-aloop грузится при старте и выбрал опцию в cadence.
А я думаю так — На wheezy или trusty ещё можно будет дооооолго работать. А к моменту их устаревания либо systemd допилят, либо форкнут, либо новое что-нить напишут.
Debian RIP.
У меня от таких вещей возникает «Apple-эффект». Ну то есть знаете такое… в рекламе показывают красивый приёмчик… делаешь фотку на телефон, тут же жмёшь кнопочку разместить в Фейсбуке и оно мгновенно там появляется. Вау! Все кричат «как круто» и швыряют свои деньги на прилавок.
А потом оказывается что кнопка Фейсбука там прибита гвоздями. Не хочешь пользоваться — все равно изволь иметь ее у себя. А никаких других сервисов мы не признаем и их кнопки туда не добавить.
Это всё равно как если бы вместо буфера обмена каждое приложение могло бы обмениваться данными строго только с какими-то другими приложениями.
В общем видимо путь мой теперь лежит в сторону LFS
У меня от таких вещей возникает «Apple-эффект». Ну то есть знаете такое… в рекламе показывают красивый приёмчик… делаешь фотку на телефон, тут же жмёшь кнопочку разместить в Фейсбуке и оно мгновенно там появляется. Вау! Все кричат «как круто» и швыряют свои деньги на прилавок.
А потом оказывается что кнопка Фейсбука там прибита гвоздями. Не хочешь пользоваться — все равно изволь иметь ее у себя. А никаких других сервисов мы не признаем и их кнопки туда не добавить.
Это всё равно как если бы вместо буфера обмена каждое приложение могло бы обмениваться данными строго только с какими-то другими приложениями.
В общем видимо путь мой теперь лежит в сторону LFS
Самое неприятное начнется, когда к systemd начнут привязывать бинарники, так что его придется ставить, чтобы обеспечить работоспособность пакетов. Например, в Debian (testing) уже довольно давно апплет управления NetworkManager'ом для Plasma (plasma-nm) требует libpam-systemd, а тот — systemd. Причем, даже если пакет стоит, но система запускалась через sysvinit, апплет не работает, и, чтобы подключиться к wi-fi, нужно лезть в консоль. Что такого особенного в этом пакете, и почему он не может работать без авторизации именно через systemd, надо смотреть в исходниках.
НЛО прилетело и опубликовало эту надпись здесь
Думаю стоит перевести на русский.
НЛО прилетело и опубликовало эту надпись здесь
Добавлю еще ссылку на более раннюю дискуссию (там же на Y) + исходная заметка о том, почему systemd is broken by design.
А тоже самое про upstart есть? А то он инвалид сплошной.
На самом деле, было бы очень неплохо неписать не пару строк, а пару килобайт про systemd, рассказать о смылсе перехода. Т.е. понятно, что хаброжители часто разбираются в линуксе, но, во-первых, пост и правда по информативности на твит смахивает, а, во-вторых, пост как затравка для беспорядочного обсуждения в комментах хорош, но для образовательных целей, а также как что-то, к чему, спасибо Гуглу, множество людей придет по запросу «что такое systemd» — не очень хорош.
Тем более от такого автора! )
Тем более от такого автора! )
Ок, объясняю, что такое systemd — гигантское bloatware, которое пытается заменить собой nginx, графический сервер, sudo, gdm, систему передачи сообщений, журналирования и ещё немножно /sbin/init. Продвигается redhat с целью подмять под себя значительный кусок экосистемы линукса.
> Ок, объясняю, что такое systemd — гигантское bloatware
du -h /lib/systemd/systemd
1.1M /lib/systemd/systemd
Целый мегабайт, ужас какой
> собой nginx
лол, што? Ну не собирайте сервер, если он не нужен
> графический сервер
Бред же
> sudo
лол!
> gdm
Оукей, у меня есть systemd, как мне входить в систему без kdm? (у меня кеды)
> систему передачи сообщений
Вообще-то это dbus, можете его использовать откуда угодно, хоть из init
> журналирования
Это очень хорошо, что в демоне можно просто писать в sout и не заботиться ни о чём. Это как раз та простота и unix-way.
> и ещё немножно /sbin/init
du -h /lib/systemd/systemd
1.1M /lib/systemd/systemd
Целый мегабайт, ужас какой
> собой nginx
лол, што? Ну не собирайте сервер, если он не нужен
> графический сервер
Бред же
> sudo
лол!
> gdm
Оукей, у меня есть systemd, как мне входить в систему без kdm? (у меня кеды)
> систему передачи сообщений
Вообще-то это dbus, можете его использовать откуда угодно, хоть из init
> журналирования
Это очень хорошо, что в демоне можно просто писать в sout и не заботиться ни о чём. Это как раз та простота и unix-way.
> и ещё немножно /sbin/init
НЛО прилетело и опубликовало эту надпись здесь
Про nginx, видимо, речь о libmicrohttpd в зависимостях. См. выше.
И как из этого следует:
>>>пытается заменить собой nginx
?
>>>пытается заменить собой nginx
?
Не знаю, это единственное, что я нашёл на тему встраивания веб-сервера в systemd. Могу только поиграть в телепата.
Строк кода в systemd уже почти вдвое больше чем в nginx, и такими темпами скоро будет в 10 раз больше. =)
… Ну и что с того? ;-)
Я думаю, systemd покажет героические усилия и будет делать в два раза меньше ошибок-на-строку-кода, чтобы количество ошибок в systemd было сравнимым с nginx.
Ах, да, на самом деле решение такое: в systemd не будет ошибок. В этом случае не важно, сколько там строк кода. А вот если ошибки будут — размер исходного кода косвенно говорит о числе ошибок.
Ах, да, на самом деле решение такое: в systemd не будет ошибок. В этом случае не важно, сколько там строк кода. А вот если ошибки будут — размер исходного кода косвенно говорит о числе ошибок.
НЛО прилетело и опубликовало эту надпись здесь
Можно вот это всё же обосновать?
По поводу «неповторимого стиля» вы что не отличаете первоапрельские шутки от новостей?
Никогда не имел проблем с pulseaudio, даже с удовольствием делаю USE=pulseaudio.
С недавнего времени комфортно юзаю UEFI, даже собираюсь подписать ядро и включить Secure Boot на ноуте.
Но все эти прелести компенсируются двумя ублюдочными инициативами redhat: ограничение отдельного usr и systemd. Такое ощущение, что по юникс-идеалогии прошлись грязными эппломсовскими сапогами.
Молюсь на генту с ее openrc и eudev. Пойду что ли им денег переведу.
С недавнего времени комфортно юзаю UEFI, даже собираюсь подписать ядро и включить Secure Boot на ноуте.
Но все эти прелести компенсируются двумя ублюдочными инициативами redhat: ограничение отдельного usr и systemd. Такое ощущение, что по юникс-идеалогии прошлись грязными эппломсовскими сапогами.
Молюсь на генту с ее openrc и eudev. Пойду что ли им денег переведу.
Но все эти прелести компенсируются двумя ублюдочными инициативами redhat: ограничение отдельного usr и systemd. Такое ощущение, что по юникс-идеалогии прошлись грязными эппломсовскими сапогами.Вообще-то отдельный /usr никогда не был «юникс-идеалогией». Изначально в /usr хранились файлы пользователей и системные программы туда попали по одной-единственной причине: кончилось место в корневом разделе. «И самый настоящий из всех настоящих» Unix'ов (Solaris) отказался от поддержки /usr на отдельном разделе лет много лет назад
НЛО прилетело и опубликовало эту надпись здесь
ru.wikipedia.org/wiki/FHS
В том то и дело. Что началом слияние /usr и / стало то, что системные программы, используемые до монтирования систем стали почему-то инсталировать в /usr.
Не увидел по Вашей ссылке подтверждения тому, что "(Solaris) отказался от поддержки /usr на отдельном разделе".
В том то и дело. Что началом слияние /usr и / стало то, что системные программы, используемые до монтирования систем стали почему-то инсталировать в /usr.
Не увидел по Вашей ссылке подтверждения тому, что "(Solaris) отказался от поддержки /usr на отдельном разделе".
/usr вообще нужно было отменить уже давно. Когда-то из-за нехватки места появилась дополнительная иерархия /usr, которая частично является копией /. Но сейчас-то это не нужно, места завались. Пусть всё будет в /.
Дело не только в месте (которого не всегда так уж и завались). Традиционно в корне лежит самое необходимое для запуска системы (в single user mode, причем с остальными разделами можно в это время делать что угодно, без необходимости грузиться со внешней флешки).
Кроме того, на корень можно назначить свои отдельные опции монтирования, или вообще монтировать его read-only (как говорится, во избежание). Отдельный корень, в случае традиционных файловых систем *nix, где таблица инодов статическая, — меньше вероятность, что внезапно закончится место; проще и быстрее бекапить через dump/restore, etc.
Кроме того, на корень можно назначить свои отдельные опции монтирования, или вообще монтировать его read-only (как говорится, во избежание). Отдельный корень, в случае традиционных файловых систем *nix, где таблица инодов статическая, — меньше вероятность, что внезапно закончится место; проще и быстрее бекапить через dump/restore, etc.
Так и знал.
Нет, изначально в юниксе в / лежало всё. Ну, кроме того, что было подмонитировано. /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 говорим, не так ли?
Нет, изначально в юниксе в / лежало всё. Ну, кроме того, что было подмонитировано. /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 говорим, не так ли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
И объял меня systemd до глубин дистрибутива моего