Половина технического комитета debian выступила за systemd

halt/suspend

только от рута это работает. А гном не от рута.

Если речь про gdm, то он как-раз таки от рута.

советский выпуск новостей

отличный пример лицемерия и лжи, браво. как нельзя лучше характеризует каноникал.

и дальше жду ответа чьим клоном является systemd.

Так я же про твою фразу «В Systemd не тырят фичи, а перенимают удачные идеи»!

Linux в последние 5 лет неуклонно катится в УГ. Так что штрихом больше, штрихом меньше — пофиг. Я, лично, после 10 лет под Linux, сегодня на десктопе начинаю переходить на Windows. Всё течёт, всё меняется.

не вижу проблемы — что мешает не давать сетевым пользователям power и plugdev?

То, что один и тот же пользователь может быть локальным и сетевым?

Я, лично, после 10 лет под Linux, сегодня на десктопе начинаю переходить на Windows.

Вот и ещё один сломался :(

На мой взгляд, в линуксе всё ещё далеко не так плохо. Я вот купил ноут с Windows 8, поклацал, проблевался - нет, спасибо, у меня есть awesome (и KDE4, если захочется чего-то более традиционного).

некоторые удачные идеи, но не передирает фичи с каждого нового релиза чего либо, как это делает upstart.

вот точные слова. напомни мне, когда подобное было с systemd.

Ну вообще-то, федоровскую реализацию для systemd следует считать эталонной, хотя бы учитывая, где работает Поттеринг

Если это эталон, то он будет работать везде. О чём беспокойство тогда?

Можешь привести контрпримеры, ГДЕ systemd НЕ зависит от этих пакетов?

Gentoo.

Простейший вариант - sudo halt.

Подожди, ты всерьёз собираешься на многопользовательском терминальном сервере с доступом через сеть давать доступ к sudo halt всем?

В случае с sudo это всё вроде нормально настраивается.

sudo умеет отличать, залогинен ли пользователь с консоли или через сеть?

В более сложном, с коммуникацией с GDM - тоже.

Да, gdm спрашивает у logind и policykit (точнее, того, что вместо него), есть ли у пользователя права. О чём и речь.

В твоей цитате.

Твой ФГМ пухнет хоть и небыстро, зато стабильно. Короче, выдохся твой моск, можно метить в утиль.

вот точные слова. напомни мне, когда подобное было с systemd.

Да ты упорот. Системд сам по себе передраная идея by design.

Можешь привести контрпримеры, ГДЕ systemd НЕ зависит от этих пакетов?

ROSA Fresh, Debian 8. Сейчас проверю ещё в федоре 20 на виртуалке.

Ну нет, если и Debian после перехода на Systemd перестанет быть десктопным - это не «пофиг», это действительно плохо.

Linux в последние 5 лет неуклонно катится в УГ. Так что штрихом больше, штрихом меньше — пофиг. Я, лично, после 10 лет под Linux, сегодня на десктопе начинаю переходить на Windows. Всё течёт, всё меняется.

У винды таки есть одно неоспоримое преимущество. В следствии закрытой разработки не так заметно, куда она катится.

связка systemd + journald требует http-сервер и генератор Qr-кодов

Во-первых, не требует, а умеет.

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

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

Подожди, ты всерьёз собираешься на многопользовательском терминальном сервере с доступом через сеть давать доступ к sudo halt всем?

На таком сервере всегда есть админ. На однопользовательском компьютере с дефолтной конфигурацией - да. Если вдруг мне в голову взбредет зайти удаленно, с какого перепуга я не могу его перезагрузить?

sudo умеет отличать, залогинен ли пользователь с консоли или через сеть?

Для консоли умеет. Насчёт иксов не знаю, можно допилить, если кого то реально интересует такой странный с моей точки зрения юз кейс.

Да, gdm спрашивает у logind и policykit (точнее, того, что вместо него), есть ли у пользователя права. О чём и речь.

Проще эти настройки внести в него же.

Ты немного не вовремя начал. Там сейчас тот еще ад

На однопользовательском компьютере с дефолтной конфигурацией - да. Если вдруг мне в голову взбредет зайти удаленно, с какого перепуга я не могу его перезагрузить?

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

На таком сервере всегда есть админ.

Который должен всё за каждого пользователя делать руками? Я не понимаю, к чему ты.

Проще эти настройки внести в него же.

Зачем включать logind в gdm? Он не только этим занимается.

Общий код для разных *DM, который работает и в неиксовых сценариях, в gdm быть не должен.

Это значит, что Поцеринг, который решает, какие патчи принимаются, работает в Redhat.

Ну.. Все не совсем так (%

Впрочем я об этом уже много раз писал, но свидетелям мировой закулисы, конечно, виднее

Если это эталон, то он будет работать везде. О чём беспокойство тогда?

О том, что везде и эти зависимости втащат.

Gentoo.

Рад за них. Хотя если они останутся «последним бастионом»...

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

В том-то и дело, что технические преимущества у systemd. Из самого запомнившегося:

1. systemd использует cgroups для контроля и управления процессами сервиса. Таким образом невозможно оставление «висячих» процессов с завершившимся родителем, ставших потому дочерними init, а не основного процесса сервиса. upstart так не умеет, и потому, скажем, останавливая apache, можно затем обнаружить, что несколько его процессов всё ещё работают.
2. upstart почти не поддерживает socket activation.
3. У systemd модель взаимодействия сервисов основана на зависимостях, а у upstart - на событиях. Последняя значительно сложнее для понимания и отслеживания взаимосвязей между сервисами, а также имеет ещё ряд ограничений, самым эпичным из которых мне показалось следующее: чтобы указать, что сервис A зависит от сервиса B, нужно модифицировать сервис B! Оцените масштабируемость и упоротость решения.

Вообще, советую почитать хотя бы поверхностно аргументы сторон и обсуждение на http://bugs.debian.org/727708, чтобы лучше понимать причины решений и важные особенности систем.

О том, что везде и эти зависимости втащат

Ну дальше-то развивай мысль. Или всё, остановка на «зависимости это плохо»?

Это как ЛОР — можно и на|| послать, только надо перелогинится

Палишься :-D

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

Невозможность просто посмотреть лог уже минусом не считается?

Просто просмотреть лог == набрать journalctl. У последнего же есть много плюшек, весьма приятных для администратора, типа отбора записей по множеству условий без написания километровых скриптов, подсветки потенциально интересных сообщений и так далее.

Не говоря уже о том, что journald можно в качестве storage указать none, и тогда это будет просто шлюз для передачи сообщений в ваш любимый syslog.

В 20 федоре ВНЕЗАПНО тоже не зависит.

Это значит, что Поцеринг, который решает, какие патчи принимаются, работает в Redhat.

Ну.. Все не совсем так (%

А конкретнее - Поцеринг не работает Redhat, или не он решает, что принимать? То, что на самом деле всё не так, как в реальности, объяснять не надо.

Лично я следил за той огромной темой с самого начала, и хоть изначально был настроен весьма скептически что к upstart, что к systemd, выслушав аргументы сторон и проведя собственные изыскания, сделал вывод, что оба кандидата будут значительным улучшением по сравнению с sysvinit, а из них двоих systemd технически (концептуально) лучше, а также значительно удобнее для пользователя.

В 20 федоре ВНЕЗАПНО тоже не зависит.

Спасибо.

не он решает, что принимать

О нет, кто-то закоммитил без ведома Поттеринга!
http://cgit.freedesktop.org/systemd/systemd/commit/?id=bcbca8291fe3beaed36dd6...

«We believe ...» «We believe ...» «We believe ...»

The X Files: I Want to Believe

Ну вообще-то, зависимости от таких вещей - это действительно плохо. Другое дело, что тут ниже redgremlin пишет, что в 20-й Федоре это починили, и в Дебиане, скорее, всего, тоже будет без завсимостей - тогда этот пункт отпадает.

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

Да уж... И ведь не поспоришь.

Одно непонятно это происки конкурентов или раздолбайство дорвавшихся до «власти» поттерингов разного пошиба, тянущих одеяло на себя.

Ну вообще-то, зависимости от таких вещей - это действительно плохо

Чем?

Ненужных зависимостей больше - ресурсоёмкость больше - надёжность меньше.

Поцеринг не работает Redhat, или не он решает, что принимать?

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

Можешь привести контрпримеры, ГДЕ systemd НЕ зависит от этих пакетов?

systemd в Fedora не зависит от http-сервера.

Осталось понять, насколько удобно будет делать поиск по логам journald из своих скриптов.

Эмм. Никто не мешает грепать выхлоп journalctl. При желании — выхлоп по нужному юниту за нужный промежуток времени. Если так хочется — регулярно делай текстовые снимки, правда, я не представляю, зачем.

Про то, что связка systemd + journald требует http-сервер и генератор Qr-кодов, на ЛОРе не обсуждал только ленивый.

Ты наркоман?

Это какой-то гсмный высер, а не аргумент. Ты можешь ответить внятно по сути, без своих эмоциональных оценок, которые ни мне, ни кому либо ещё не интересны абсолютно?

В 20 федоре ВНЕЗАПНО тоже не зависит.

Таки зависит от qrencode-libs.

https://www.google.de/search?q=software coupling

Если я смогу нормально ориентироваться в логах без левых GUI-примочек

С каких пор journalctl стал GUI-примочкой? Он просто вывод по умолчанию на less отправляет. Делаешь alias catlog=journalctl --output=short --no-pager и вместо cat /var/log/syslog | script будет catlog | script

Не в тему.

Не в тему.

Это называется не «не в тему», а «не осилил».

Осталось понять, насколько удобно будет делать поиск по логам journald из своих скриптов.

Насколько знаю, простой вызов journalctl выдаёт лог в точно таком же формате, как и syslog, поэтому достаточно просто запайпить его в ваш скрипт. (А ещё можно выводить в JSON.)

Другое дело что сам journalctl позволяет легко делать те вещи, ради которых эти скрипты и писались. См. http://0pointer.de/public/systemd-man/journalctl.html.

И опять же, если есть насущная необходимость иметь текстовые логи в формате syslog, ничто не мешает этот syslog установить, и тогда journald будет все поступающие сообщения направлять и туда.

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