Пишу из горящего танка

Будут. Например, в панели всегда будет отображаться en или вообще ничего.

ну и отлично, если ничего не будет отображаться.

ну и отлично, если ничего не будет отображаться.

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

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

для этого есть индикаторы на клавиатуре.

для этого есть индикаторы на клавиатуре.

А если раскладок более двух?

Вот так Wayland вредит простым людям :(

для этого есть индикаторы на клавиатуре.

Пишу из горящего танка (комментарий)

для этого есть индикаторы на клавиатуре.

А если раскладок более двух?

с помощью двух лампочек можно показать до четырех раскладок.

для этого есть индикаторы на клавиатуре.

Пишу из горящего танка (комментарий)

это карма :)

с помощью двух лампочек можно показать до четырех раскладок.

Ага, и выводить номера раскладок в двоичной системе счисления. :)

с помощью двух лампочек можно показать до четырех раскладок.

Ага, и выводить номера раскладок в двоичной системе счисления. :)

да.

с помощью двух лампочек можно показать до четырех раскладок.

Xkb вообще такое умеет?

с помощью двух лампочек можно показать до четырех раскладок.

Xkb вообще такое умеет?

искаропки - нет. Надо копаться в конфигах, афаик.

Хотел было свалить на Trinity, но вспомнил, что переключалка раскладок там тоже немного лагала, и заметил, что до сих пор они не выпилили зависимость от hal.

В openSUSE kde3 от hal не зависит. Хотя не понимаю, почему это должно волновать юзера.

В openSUSE kde3 от hal не зависит.

OpenSUSE у меня после установки не загрузилась — там почему-то корень не перемонтируется в rw, если он указан в fstab по UUID (видимо, юнит systemd, который делает «mount / -o remount», запускается раньше, чем доступен /dev/disk; в новом systemd нет ни этой проблемы, ни этого юнита, но в openSUSE почему-то древнющее systemd 44). Если это не исправили, openSUSE мне не подходит по той причине, что оно не загружается. И да, я всё делал средствами инсталлятора, ничего ручками поломать не успел, и эта ситуация наглядно показывает качество дистрибутива.

Хотя не понимаю, почему это должно волновать юзера.

Лишний демон, дублирующий функции других демонов — это плохо. Я вообще не уверен, что он может работать одновременно с udisks и upower, не вызывая проблем.

Не знаю как в KDE, а в Gnome файловый менеджер уже начали кастрировать выше всех разумных пределов.

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

Плюс хронические проблемы с использованием Super в кнопкосочетаниях, которые тянутся ещё из GNOME2 :-\

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

systemd в сусе можно отключить

Спасибо, не надо. Нужно баг исправлять, а не городить костыли и отключать полезные вещи.

systemd is the bug :)

полезные вещи :)

nope, it's killer feature

who has been killed with systemd? :)

anyway, what will be lost without systemd except of the impossibility of system start?

bugs are very useful, I know :)

anyway, what will be lost without systemd except of the impossibility of system start?

those really important things such as nice runtime daemon control and lots of mount points

I don't need such details, I want to know what possibilities I'll lose as user.

Тоже поковырялся на днях, офигел от этих сраных 90-ых с переключением по ctrl-alt-k и вернулся на qtile. А где-то писали что gnome 3.6 будет юзабелен. Обманули сволочи.

If so, you'll lose extremely fast shutdown. Other features are difficult to be seen by normal users.

Anybody cares about this? I don't. But I do care if my system is unable to boot.

But I care about everything. It's important for me how daemons are managed and how efficient my system works. That boot failure bug is already fixed in newer systemd versions, so it's problem of openSUSE.

If system is going to shutdown I'd not say that it works. Also, I really don't understand why systemd is more efficient?

Also, anonymous still can't boot his fedora with systemd here: Новый релиз systemd 195 (комментарий)

It's more efficient because it uses another approach for daemon control. For example, it starts and stop daemons on demand, saving memory and speeding up boot. Also it allows dependent daemons to start simultaneously decreasing their startup time.

Кончайте злостно нарушать, умники.

what do you mean saying «on demand»? I thought any init starts daemons if it was asked to do it

startup time is not significant for me too, why should I care about it? But guys in the topic spent very much amount of time to boot their fedora, yeah :))

It'd nice example about the RAM efficiency but it doesn't affect me in runtime, so I don't see the reason to care about it too.

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

Именно поэтому ушел из гнома в момент выпуска 3.6. Надеюсь, они починят хотя бы к 3.10. Благими намерениями они вымостили дорогу к неюзабельному релизу.

what do you mean saying «on demand»? I thought any init starts daemons if it was asked to do it

But I can ask systemd to start daemon not on boot time, but only when it's needed, for example, CUPS starts only when there are connected printers or jobs in queue available. It's rather simple to set up this feature with systemd. With SysVinit implementing such feature requires udev, xinetd and incrond setup.

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

лол, андроид такой андроид

where can I take a look on the system files implementing this feature?

/usr/lib/systemd/system/cups.{service,socket,path}

/usr/lib/systemd/system/sshd{@.service,.socket}

http://rghost.ru/41347414

3.10?!! На 3.8 даже надеяться смысла нет? =(

Зная устройство этого мира - я не поставлю на 3.8 ни копейки.

Смотрю я на эти DE, и думаю, что уж лучше буду дальше красноглазить.

tar: invalid tar magic :(

will retry tomorrow from my desktop

But I can ask systemd to start daemon not on boot time, but only when it's needed, for example, CUPS starts only when there are connected printers or jobs in queue available.

Для этого не нужен sustemd, но так все равно обычно никто не делат — незачем.

/usr/lib/systemd/system/cups.{service,socket,path}
/usr/lib/systemd/system/sshd{@.service,.socket}
http://rghost.ru/41347414

Во-первых, выложенная конфигурация не-полная (и причем тут ssh?).

Во-вторых, я правильно понимаю, что сетевой принтер в cups такая настройка не поддерживает, и http://127.0.0.1:631/ тоже? То есть то, что легко и непринужденно работало до systemd теперь нужно копать и настраивать руками? Очень удобно. Для тех, кому нечем заняться, кроме как тестировать и настраивать поттерингопрограммы.

В-третьих, вам серьезно нравится копаться в такой конфигурации? Например, как по этим файлам определить, запустится ли вообще cups или нет?

Печально всё-таки, что некогда хороший Линукс скатился до состояния «не готов».

Какая связь между: «хороший Линукс», и потенциальным недоразуменим созданным имбецилами для дегенератов под названием Gnome3?

А ведь KDE3 было лучшим DE, которое видел мой нетбук в своё время.

Что мешает установить человеческий дистрибутив (SuSE к примеру) где он есть, и прекрасно себя чувствует?

P.S. Руками настроить через xkb и xorg.conf/setxkbmap тоже видно не дано?

Во-первых, выложенная конфигурация не-полная

Чего не хватает?

и причем тут ssh?

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

Во-вторых, я правильно понимаю, что сетевой принтер в cups такая настройка не поддерживает

Поддерживает. CUPS запустится, когда появятся задания в очереди благодаря cups.path, и будет спокойно работать с сетевым принтером.

и http://127.0.0.1:631/ тоже

По порту 631 CUPS в такой конфигурации не активируется, его нужно будет запускать вручную, зато он умеет активироваться по сокету /var/run/cups/cups.sock. Возможно, это недостаток поддержки со стороны CUPS, а возможно, что можно настроить и для порта 631, написав ещё один юнит. С другой стороны, в большинстве случаев, когда нужен веб-интерфейс, принтер уже подключён, поэтому CUPS запущен через printer.target и никакой проблемы нет. И, опять же, здесь тоже никто не мешает настроить так, чтобы CUPS запускался не по требованию, а при загрузке.

То есть то, что легко и непринужденно работало до systemd теперь нужно копать и настраивать руками?

До systemd таких возможностей никогда не было, ничего непринуждённо не работало. CUPS просто тупо загружался при загрузке, а не тогда, когда он нужен. Чтобы настроить его так же, как с systemd, но без systemd, нужно будет долго возиться с udev, incrond и xinetd.

В-третьих, вам серьезно нравится копаться в такой конфигурации?

Конфиги просты до безобразия. Даже без чтения документации большая часть понятна, остальная быстро понимается при чтении манов.

Например, как по этим файлам определить, запустится ли вообще cups или нет?

Очень просто. Во-первых, в /etc/systemd/system/printer.target.wants лежит симлинк cups.service, поэтому cups.service запустится при активации printer.target, т.е. при подключении принтера. Во-вторых, в /usr/lib/systemd/system/cups.socket написано «ListenStream=/var/run/cups/cups.sock» — это значит, что при подключении к этому сокету активируется cups.service, и демону cups будет передан fd сокета. В-третьих, в /usr/lib/systemd/system/cups.path написано «PathExistsGlob=/var/spool/cups/d*» — это значит, что при появлении файлов /var/spool/cups/d* запустится cups.service. Что в этом не очевидно после прочтения юнитов?

Таки прочитай тред, там уже были ответы на эти вопросы.

Пишу из горящего танка (комментарий)
Пишу из горящего танка (комментарий)
Пишу из горящего танка (комментарий)

Чего не хватает?

Не хватает активации по tcp/udp порту 631. Как я понимаю, ее и нет.

Поддерживает. CUPS запустится, когда появятся задания в очереди благодаря cups.path, и будет спокойно работать с сетевым принтером.

А как в CUPS появится этот сетевой принтер?

Возможно, это недостаток поддержки со стороны CUPS

Это недостаток поддержки со стороны systemd. Cups слушал эти порты с тех пор как я его помню. Но для того, чтобы он работал с systemd, леннарт выкатил неслабый патч (и все дистрибутивы его к себе утащили), ему тыкали на ошибки, он их правил, ему снова тыкали и т.д. До сих пор не все исправлены.

а возможно, что можно настроить и для порта 631, написав ещё один юнит.

Думаю, что это практически не возможно.

когда нужен веб-интерфейс, принтер уже подключён, поэтому CUPS запущен через printer.target и никакой проблемы нет

Не считая случаев, когда принтер — сетевой. А это чуть ли не большинство.

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

И как это сделать? :)

До systemd таких возможностей никогда не было, ничего непринуждённо не работало.

«Таких возможностей» — это возможностей настройки cups-а по http://127.0.0.1:631/

CUPS просто тупо загружался при загрузке, а не тогда, когда он нужен. Чтобы настроить его так же, как с systemd, но без systemd, нужно будет долго возиться с udev, incrond и xinetd.

Вероятно это потому, что всем было пофиг на cups, занимающий аж 2МБ памяти. Сам systemd больше занимает (и это не считая udev и journal).

Конфиги просты до безобразия. Даже без чтения документации большая часть понятна, остальная быстро понимается при чтении манов.

Ага. Щассс... Рассмотрим простую задачу: как узнать, запустится ли cupsd?

Для начала, как мы должны были найти cups.service? Вероятно, запустили grep -r cupsd /

Очень просто. Во-первых, в /etc/systemd/system/printer.target.wants лежит симлинк cups.service

Действительно, это же очевидно, что надо искать симлинк именно там. Особенно учитывая то, что это не написано даже в документации. :)

поэтому cups.service запустится при активации printer.target

Т.е. когда?

т.е. при подключении принтера.

Откуда известно, что это активирует printer.target? И, кстати, когда именно это произойдет?

Во-вторых, в /usr/lib/systemd/system/cups.socket

Каким образом нужно было найти этот файл?

написано «ListenStream=/var/run/cups/cups.sock» — это значит, что при подключении к этому сокету активируется cups.service

Во-первых, не значит. Во-вторых, из чего следует, что активируется именно cups.service?

В-третьих, в /usr/lib/systemd/system/cups.path

А этот файл мы как нашли?

написано «PathExistsGlob=/var/spool/cups/d*» — это значит, что при появлении файлов /var/spool/cups/d* запустится cups.service.

Опять-таки, во-первых, не значит. Во-вторых, из чего следует, что это должно запустить именно cups.service? Вот, например, в случае sshd.socket это почему-то запускает не sshd.service, а sshd@.service... А если он уже был запущен (из-за активации по сокету, например) — запустится вторая копия, или нет? Как это узнать?

Что в этом не очевидно после прочтения юнитов?

Хм. А что в этом очевидно? Вот `chkconfig --list | grep -i cups` — это очевидно.

А как в CUPS появится этот сетевой принтер?

systemctl start cups.service и добавляй всё, что нужно.

Cups слушал эти порты с тех пор как я его помню

Он и с systemd всегда слушал их. Вот только для активации по сокету надо уметь получать от systemd уже существующий сокет, не создавая его самому.

Но для того, чтобы он работал с systemd, леннарт выкатил неслабый патч

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

Для начала, как мы должны были найти cups.service? Вероятно, запустили grep -r cupsd /

Зная, что в системе systemd, мы посмотрели сначала в /etc/systemd/system/cups.service и, не обнаружив его там, посмотрели в /usr/lib/systemd/system/cups.service. Это универсальный способ. Если бы мы знали, что система грузится через init-скрипты, но не знали, какие, то пришлось бы действительно делать чуть ли не find / -iname '*cups*', потому что это мог быть и /etc/init.d/cups, и /etc/rc.d/cups, и /etc/rc.d/init.d/cups, и /etc/init.d/cupsd, и /etc/rc.d/cupsd, и /etc/rc.d/init.d/cupsd или вообще любое место в ФС. В случае upstart пришлось бы посмотреть, кроме этих мест, ещё и в /etc/init/cups.conf. Очевидно, с systemd всё гораздо проще.

Действительно, это же очевидно, что надо искать симлинк именно там. Особенно учитывая то, что это не написано даже в документации. :)

WantedBy=, RequiredBy=
           Installs a symlink in the .wants/ or .requires/ subdirectory for a unit, respectively. This has
           the effect that when the listed unit name is activated the unit listing it is activated too.
           WantedBy=foo.service in a service bar.service is mostly equivalent to
           Alias=foo.service.wants/bar.service in the same file.

Откуда известно, что это активирует printer.target?

В cups.service прописано «WantedBy=printer.target», что означает, что при systemctl enable cups.service создастся симлинк в /etc/systemd/system/printer.target.wants/, и cups.service будет запускаться при активации printer.target.

И, кстати, когда именно это произойдет?

/usr/lib/udev/rules.d/99-systemd.rules:

SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"

Каким образом нужно было найти этот файл?

Он имеет такую же часть имени до точки, как и cups.service. Ещё он упомянут в cups.service в строке:

Also=cups.socket cups.path

Это означает, что при systemctl enable cups.service также включатся cups.socket и cups.path.

Во-первых, не значит. Во-вторых, из чего следует, что активируется именно cups.service?

Это значит, что systemd будет слушать на этом сокете, а при подключении активирует cups.service, передав ему открытый fd этого сокета. Активируется именно cups.service, потому что имя до точки одинаковое, а в cups.socket оставлено по умолчанию Accept=false.

А этот файл мы как нашли?

Аналогично cups.socket.

Во-вторых, из чего следует, что это должно запустить именно cups.service?

Из того, что у него имя до точки одинаковое, а Unit= не указан в cups.path.

Вот, например, в случае sshd.socket это почему-то запускает не sshd.service, а sshd@.service... А если он уже был запущен (из-за активации по сокету, например) — запустится вторая копия, или нет?

В sshd.socket указано Accept=yes, поэтому будет запущено по экземпляру sshd@….service на каждое соединение.

Как это узнать?

Осилить уже документацию.