LINUX.ORG.RU

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

 , ,


0

2

Обновил гном 3.4 на арче до гнома 3.6. Перезагрузился, сразу меня порадовал плавный переход от консоли к gdm (а это значит, что можно устанавливать plymouth и всё будет красиво) и новый дизайн gdm. Залогинился, обнаружил, что в настройках беспроводных сетей теперь видно все сети, к которым я подключался, и их оттуда можно удобно удалять всегда, а не только тогда, когда подключение активно. Отвалились все расширения, кроме скрывалки значка accessibility. Кажется, всё замечательно, но тут я заметил...

...что у меня одна раскладка. Тут я вспомнил, что читал на ЛОРе о сломанной переключалке, но потом читал, что её починили. Не тут-то было. Добавление раскладки ru+ruu никак не действует - индикатора просто нет, переключение не работает. Для проверки добавил ru+winkeys - то же самое. Раскладка будет увидена только тогда, когда она без модификации, например, просто ru. Меня же это не устраивает, т.к. я пользовался русско-украинской раскладкой. Дальше - больше. Переключать раскладки теперь можно только мышкой или хоткеем модикикатор+клавиша, например, Ctrl+Alt+K. Естественно, это жутко неудобно, поэтому я лезу в gnome-tweak-tool за нормальным переключателем, но не тут-то было: там есть только модификатор+модификатор, а переключения по Caps Lock больше нет. Вот что говорят разработчики по этому поводу:

Rui Matos

AFAICT, it's not possible to do this currently from an X client without also triggering Caps Lock itself, that's why I didn't add combinations with CapsLock.

и ещё:

Rui Matos

Wayland should allow us to that.

А всё из-за того, что они решили не использовать средства xkb для переключателя раскладки, а ловить хоткеи самостоятельно. Мало того, что теперь нельзя использовать самый удобный способ переключения, так ещё и их переключалка жестоко лагает. Сейчас повесил на Ctrl+Shift, но при нажатии оного окно Firefox становится блеклым (как неактивное) на 2 секунды, после этого возвращается обратно, после чего ещё проходит секунда до реального переключения раскладки (а в течение этих 3 секунд можно продолжать печатать старой раскладкой). Куда это вообще годится? И ещё одна проблема, более фееричная: переключалка клавиатуры в таком виде не работает в режиме overview (там поиск есть, которым теперь стало невозможно пользоваться) и в режиме блокировки экрана. Если бы нельзя было переключить раскладку мышкой на экране блокировки, я бы вырубил комп и не дописал бы это сообщение. Также теперь нельзя включить misc:typo или раскладку ru+ruu, поэтому в этом сообщении я не смог использовать нормальные кавычки, троеточие, и тире.

Может, всё не так безнадёжно и где-то есть патчики для возвращения старого поведения?

Ах да, чуть не забыл: ещё была выпилена кнопка завершения сеанса. А теперь вспоминаем, что язык интерфейса не меняется, пока не перезалогинишься, а перезагрузка не катит, потому что система многопользовательская и другие пользователи залогинены. Конечно, можно нажать на выключение - это не разлогинит других пользователей. А если других пользователей нет, то перезагружаться ради перезалогина? Бред.

Хотел было свалить на Trinity, но вспомнил, что переключалка раскладок там тоже немного лагала, и заметил, что до сих пор они не выпилили зависимость от hal. А ведь KDE3 было лучшим DE, которое видел мой нетбук в своё время.

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

Перемещено svu из talks

Ответ на: комментарий от gentoo_root

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

Зная, что в системе systemd, мы посмотрели сначала в /etc/systemd/system/cups.service

Но почему мы искали именно cups.service? Почему, например, не cupsd.service?

и, не обнаружив его там, посмотрели в /usr/lib/systemd/system/cups.service.

А также в /usr/lib64/systemd/system/cups.service, /usr/share/systemd/system/cups.service, /lib/systemd/system/cups.service, /lib32/systemd/system/cups.service, /lib64/systemd/system/cups.service, /run/systemd/system/cups.service, /usr/local/lib/systemd/system/cups.service, /etc/systemd/user/cups.service, /usr/lib/systemd/user/cups.service, /usr/share/systemd/user/cups.service, /usr/local/lib/systemd/user/cups.service... И это далеко не полный список мест, в которых могут лежать юниты.

Это универсальный способ. Если бы мы знали, что система грузится через init-скрипты

то сделали бы: chkconfig --list | grep -i cups

Очевидно, с systemd всё гораздо проще.

Ага. Однозначно! :)

[code]WantedBy=, RequiredBy=[/code]

Только вот почему мы искали симлинк именно в том каталоге? (см. выше список каталогов, в которых он на самом деле мог лежать)

/usr/lib/udev/rules.d/99-systemd.rules:
SUBSYSTEM==«printer», TAG+=«systemd», ENV{SYSTEMD_WANTS}+=«printer.target»

Наверное, это тоже очевидно, даже без прочтения документации. :)

Это значит, что systemd будет слушать на этом сокете

Не значит. Потому что мы не проверили, активирован ли юнит сокета. Для того, чтобы он был активирован, просто положить его в один из каталогов не достаточно. (кстати, интересно, откуда мы должны были об этом узнать?) То же касается и path-юнита.

... Активируется именно cups.service, потому что имя до точки одинаковое, а в cups.socket оставлено по умолчанию Accept=false. ...
... Из того, что у него имя до точки одинаковое, а Unit= не указан в cups.path. ...

Йопт. Очевидно же. :)

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

Эх. Всё так оптимистично начиналось:

Даже без чтения документации большая часть понятна

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

Вот так, обманом, systemd и завоевывает популярность. «Юниты systemd намного проще чем initscripts». Но эта простота — всего лишь маркетинговый обман, чтобы заманить побольше тестеров в это глючное поделие. И всё ради чего? Чтобы удовлетворить честолюбие Леннарта?

anonymous
()
Ответ на: комментарий от anonymous

маркетинговый обман

А смотрел на странице «Why systemd?» прекрасные сравнительные таблицы в стиле «iPhone vs. камень»? :)

Binary ★★★★★
()
Ответ на: комментарий от gentoo_root

По ssh и так можно же через xinetd, а с cupsd реально получается экономия на спичках, но только в минус, я сравнил на генте cupsd с арчем, там хоть и совсем чуть-чуть, но cupsd выходит дешевле, чем systemd. Так и кому нужен этот геморрой, если анонимусу федору в KVM то так и не загрузили? :-D

Binary ★★★★★
()
Ответ на: комментарий от anonymous

Но почему мы искали именно cups.service?

Действительно, наверное, следовало искать sgfasdsglahkqjhtr.service. Как же я сразу не подумал, что под этим именем может скрываться cups.

Почему, например, не cupsd.service?

cupsd.service тоже должен работать, потому что там симлинк лежит cupsd.service -> cups.service.

А также в

Бред только не надо писать.

/usr/lib64/systemd/system/cups.service

lib -> lib64

/usr/share/systemd/system/cups.service

Никогда там юниты не лежали, не придумывай.

/lib/systemd/system/cups.service

/lib -> usr/lib

/lib32/systemd/system/cups.service

Снова мимо.

/lib64/systemd/system/cups.service

/lib64 -> usr/lib

/run/systemd/system/cups.service

И опять мимо.

/usr/local/lib/systemd/system/cups.service

И сюда systemd не смотрит.

/etc/systemd/user/cups.service, /usr/lib/systemd/user/cups.service, /usr/share/systemd/user/cups.service, /usr/local/lib/systemd/user/cups.service...

А это вообще толстый вброс — первые 2 каталога относятся к systemd в пользовательском режиме, а это вообще отдельный демон, мы же рассматриваем системный systemd, который запускает cups. Остальные каталоги — это тоже плод твоей буйной фантазии.

Итого, как было, так и остаётся 2 каталога: /usr/lib/systemd/system и /etc/systemd/system. Так что это тоже мимо:

(см. выше список каталогов, в которых он на самом деле мог лежать)

то сделали бы: chkconfig --list | grep -i cups

И снова не попал, потому что это работает только с одной реализацией init-скриптов. Как минимум в debian, gentoo, archlinux с их реализациями init-скриптов это не заработает. Там есть update-rc.d, rc-update, текстовый редактор для этих целей. В systemd же всегда один способ настройки, независимый от дистрибутива.

Не значит. Потому что мы не проверили, активирован ли юнит сокета. Для того, чтобы он был активирован, просто положить его в один из каталогов не достаточно. (кстати, интересно, откуда мы должны были об этом узнать?) То же касается и path-юнита.

Ну извини, я не подумал, что для кого-то может быть неочевидно, что чтобы что-то заработало, надо это включить. Ты же не рассчитываешь, что принтер начнёт печатать, когда он выключен? Очевидно, что нужно сначала сделать systemctl enable cups.service (который при этом включит cups.socket и cups.path, создав симлинки).

Наверное, это тоже очевидно, даже без прочтения документации. :)

А почему должно быть неочевидно, что printer.target активируется при налилии принтера, а bluetooth.target — при наличии bluetooth-адаптера?

Эх. Всё так оптимистично начиналось:

Пользователю для выполнения его круга задач можно обойтись даже без документации. Мы же углубились уже во внутреннее устройство — тут уже нужна документация. И она здесь хотя бы есть, потому что если бы мы начали читать init-скрипты, то разбираться пришлось бы дольше из-за большего объёма кода и полного отсутствия документации.

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

А теперь сравни жалкие 5 строчек с 5 килобайтами кода на баше, который они заменили. Чтобы понять эти 5 КБ, нужно выучить язык программирования, а чтобы написать init-скрипт, нужно помнить все команды из /bin, /sbin, /usr/bin и /usr/sbin и все их параметры. В systemd же ни о каких сотнях опции речи не идёт, а из документации я не прочитал и трёх страниц.

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

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от Binary

По ssh и так можно же через xinetd

А так можно без xinetd. При этом systemd следит за всеми запущенными им процессами, а xinetd — нет.

Так и кому нужен этот геморрой, если анонимусу федору в KVM то так и не загрузили?

У меня работает, я доволен.

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от gentoo_root

При этом systemd следит за всеми запущенными им процессами, а xinetd — нет

Вы так говорите, будто это что-то хорошее.

Binary ★★★★★
()
Ответ на: комментарий от gentoo_root

Чтобы понять эти 5 КБ, нужно выучить язык программирования, а чтобы написать init-скрипт, нужно помнить все команды из /bin, /sbin, /usr/bin и /usr/sbin и все их параметры. В systemd же ни о каких сотнях опции речи не идёт, а из документации я не прочитал и трёх страниц

Недавно поимел дело с CentOS против своей воли и даже согласен что то, что там творится в init никуда не годно. Но посмотрите на OpenRC, чем не решение? Я уже давно пользуюсь гентой, но т.к. это десктоп, инит-скриптов своих писать не приходилось, и вот в связи с этой истерией о systemd глянул в её скрипты, это ж просто праздник! Вопрос, чего такого решает systemd, чего нельзя без него, до сих пор для меня открыт.

Binary ★★★★★
()
Последнее исправление: Binary (всего исправлений: 1)
Ответ на: комментарий от Binary

Но посмотрите на OpenRC, чем не решение? Я уже давно пользуюсь гентой, но т.к. это десктоп, инит-скриптов своих писать не приходилось, и вот в связи с этой истерией о systemd глянул в её скрипты, это ж просто праздник! Вопрос, чего такого решает systemd, чего нельзя без него, до сих пор для меня открыт.

И они вынуждены использовать start-stop-daemon для запуска демонов и ненадёжные PID-файлы для остановки. В отличие от этого, systemd автоматически запихивает каждый демон (со всеми его потомками) в отдельную группу cgroups. Для надёжной остановки демона нужно всего лишь прибить все процессы из группы. В случае PID-файлов во-первых, нет возможности установить, действительный ли он, или демон уже давно упал, а под этим номером работает другой процесс; а во-вторых, PID-файл хранит номер одного процесса — как надёжно убивать его потомков, остаётся неясно.

Это одна из проблем, которую решает systemd. Но не стоит забывать, что systemd не только управляет демонами. Он также предоставляет удобное API для управления локалью, раскладками клавиатуры, шрифтами в консоли, временем, хостнеймом и многими другими вещами. Это повышает интеграцию DE с системой. Например, прямо из гнома можно установить в настройках времени галочку для синхронизации с NTP, гном через D-Bus сообщит новую настройку systemd-timedated, а последний включит или выключит time-sync.target, в котором выполняется ntpd. Если бы такого не было, мейнтейнерам каждого дистрибутива пришлось бы патчить гном, чтобы он вызывал дистрибутивоспецифичные методы для включения и отключения ntpd.

Кстати, относительно недавно в портедже появилась программа, предназначенная для работы под OpenRC, предоставляющая интерфейсы systemd на D-Bus для вышеперечисленного. Если бы не systemd, вряд ли кому-нибудь пришла в голову идея написать такую прослойку для унификации дистрибутивозависимых вещей.

gentoo_root ★★★★★
() автор топика
Последнее исправление: gentoo_root (всего исправлений: 1)
Ответ на: комментарий от gentoo_root

ненадёжные PID-файлы

Почему-то systemd рекомендует использовать те же PID-файлы, когда речь идёт о форкающихся демонах, а опцию GuessMainPID объявили ненадёжной. Ой?

Но не стоит забывать, что systemd не только управляет демонами

Вот именно это и странно, зачем это всё пихать в инит? А если мне нужна система без этих плюшек? А если оно глючит?

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

А теперь смысла в разных дистрибутивах скоро вообще не будет :)

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

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

Binary ★★★★★
()
Ответ на: комментарий от Binary

Почему-то systemd рекомендует использовать те же PID-файлы, когда речь идёт о форкающихся демонах, а опцию GuessMainPID объявили ненадёжной. Ой?

Это не туда. Это нужно, чтобы PID-файлы были корректными и можно было определить основной процесс в группе. При остановке сервиса всё равно убиваются все процессы группы.

Вот именно это и странно, зачем это всё пихать в инит?

Действительно, в ините это было бы излишним, поэтому в инит это и не пихали. Для каждой из этих плюшек есть отдельный исполняемый файл, который запускается только тогда, когда он нужен (активируется по D-Bus).

А теперь смысла в разных дистрибутивах скоро вообще не будет :)

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

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от gentoo_root

Это не туда. Это нужно, чтобы PID-файлы были корректными и можно было определить основной процесс в группе. При остановке сервиса всё равно убиваются все процессы группы

Нифига себе не туда. PID-файлы остались, без них нормально убить нельзя, а кричим, какие они нехорошие. Ещё как туда.

Действительно, в ините это было бы излишним, поэтому в инит это и не пихали. Для каждой из этих плюшек есть отдельный исполняемый файл, который запускается только тогда, когда он нужен (активируется по D-Bus).

MATE в моём минте прекрасно управляется с ntpd без systemd.

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

Здесь как с недополученной прибылью: то, что станет невозможно делать много дистрибутивов, совсем не значит, что усилия пойдут именно на то, что _вы_ считаете нужным.

А вообще, отличия дистрибутивов должны быть в чём-то серьёзном и реально нужном (например, бинарный или компилирующийся из исходников), а не в разных велосипедах для загрузки системы и для управления пакетами

Если развить мысль, бинарный и компилирующийся из исходников тоже не серьёзное отличие (собрать из генты бинарный дистр ­— раз плюнуть и неделю компилировать). Но, как я уже говорил, системы без свободы уже есть, зачем ещё одна?

Binary ★★★★★
()
Ответ на: комментарий от gentoo_root

lib -> lib64, /lib -> usr/lib

Так только в арче.

Бред только не надо писать. ... Никогда там юниты не лежали, не придумывай. ... И сюда systemd не смотрит.

Да ну? Чтобы знать systemd, надо и в его исходниках поколупаться. Очевидно?

первые 2 каталога относятся к systemd в пользовательском режиме, а это вообще отдельный демон, мы же рассматриваем системный systemd, который запускает cups.

Вопрос был­ — запустится ли cups? Кто его знает, как systemd его запустит? В initscripts вариант один. А тут разработчики могли решить, что cups на десктопе нужен только пользователю, разве нет?

то сделали бы: chkconfig --list | grep -i cups

это работает только с одной реализацией init-скриптов.

Это работает в любом дистре с initscripts. Не работает только в арче, потому что там был bsdinit. Но тупой:

ls -la /etc/rc.d/ /etc/init.d/ | grep -i cups
сработал бы даже там. И да, инитскрипт должен быть только в /etc/init.d/. Арч — исключение.

Очевидно, что нужно сначала сделать systemctl enable cups.service (который при этом включит cups.socket и cups.path, создав симлинки).

Очевидно после нахождения и прочтения всех трех юнитов и десятка страниц документации?

А почему должно быть неочевидно, что printer.target активируется при налилии принтера?

Потому что он мог активироваться на каком-то этапе загрузки (как многие другие target-ы). Или при логине юзера из группы lp или print. Или мог требовать ручной активации. Или запуска магической команды systemd-start-printing. Без копания в мануалах это совсем не очевидно.

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

У абстрактного «пользователя» в абстрактном дистрибутиве в вакууме все работает из коробки, быстро и без глюков, потому ему не надо ни юниты systemd, ни инитскрипты. Но у реальных людей рано или поздно что-то работает не так (а у systemd это постоянно), и приходится ковыряться. В инитскриптах это — легко, а в systemd — жуть.

Мы же углубились уже во внутреннее устройство — тут уже нужна документация.

Какое внутреннее устройство? Вопрос был прост: запустится ли cups. Он может возникнуть у обычного юзера. И даже на этот простой вопрос в systemd нет простого ответа.

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

А теперь сравни жалкие 5 строчек с 5 килобайтами кода на баше, который они заменили.

Сравним с этим? Да, строчек много. И что в них понятно? Да всё! Понятно, что при запуске cups-а будут подгружены некоторые модули ядра, что принтеры будут сконфигурены (udev-configure-printer), и что при рестарте будет перезапущен xprint, если он есть. А как всё это «понять» в systemd?

Чтобы понять эти 5 КБ, нужно выучить язык программирования, а чтобы написать init-скрипт, нужно помнить все команды из /bin, /sbin, /usr/bin и /usr/sbin и все их параметры.

Наоборот. Чтобы их понять не надо ничего. И все команды/параметры знать не надо, это ж не systemd, отсутствующие команды на код не влияют. Чтобы писать скрипты, знать надо только баш, его ман короче чем у systemd, и знать его полезно даже в повседневной жизни.

В systemd же ни о каких сотнях опции речи не идёт, а из документации я не прочитал и трёх страниц.

Не знаю, сколько опций сейчас, но больше сотни. И чтобы понять юнит, знать их нужно все, т.к. на юнит влияют даже опции, которых в нём нет. У cups-а опций Unit= и Accept= нет, и это определяет поведение юнитов. А чтобы писать юниты, надо и за апдейтами следить, ведь это не баш, синтаксис иногда меняется. И все эти знания в повседневной жизни бесполезны.

anonymous
()
Ответ на: комментарий от gentoo_root

Вопрос, чего такого решает systemd, чего нельзя без него, до сих пор для меня открыт.

Ответа фанаты systemd обычно не знают. Они просто верят, что systemd очень нужен, ведь им так сказали. А сами они не задумывались, ведь как всё было раньше они не знают.

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

И они вынуждены использовать start-stop-daemon для запуска демонов и ненадёжные PID-файлы для остановки.

И юниты systemd вынуждены использовать systemd и ненадежные cgroups для остановки. Но у скриптов есть выбор, а у юнитов — нет.

В отличие от этого, systemd автоматически запихивает каждый демон (со всеми его потомками) в отдельную группу cgroups.

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

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

Нет. В общем случае не известно, каким процессам в группе надо посылать сигнал остановки. Иногда — одному главному процессу, иногда нескольким. Если тупо убить все процессы сервера DB, то можно остаться без базы. Даже systemd так не делает.

В случае PID-файлов во-первых, нет возможности установить, действительный ли он, или демон уже давно упал, а под этим номером работает другой процесс;

Море способов. Мне нравится `readlink /proc/PID/exe`.

а во-вторых, PID-файл хранит номер одного процесса — как надёжно убивать его потомков, остаётся неясно.

Да что вы прицепились к PID-файлам? PID-файл init-скрипту нужен только чтобы знать, кому посылать SIGTERM по команде stop.

Зачем ему для этого pid-файл? Затем, что таких демонов может быть много. Почти любых демонов может быть много. Может быть несколько http или ftp-серверов, если они висят на разных портах. Может быть даже несколько init/udev демонов, если один из них запущен в чруте или контейнере.

Плюс у демона может быть много форков, а сигналить нужно одному из них. Даже если инитскрипт отслеживает форки, он не знает, кому из них посылать сигнал. Единственный, кто это знает — сам демон. Потому придумали универсальный способ на все случаи жизни: демон пишет в PID-файл список PID-ов, которым надо посылать сигнал. Всё, проблема решена, 20 лет назад!

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

Он также предоставляет удобное API для управления локалью, раскладками клавиатуры, шрифтами в консоли, временем, хостнеймом и многими другими вещами.

Зачем нужно АПИ, если можно поправить текстовый конфиг? Кстати, причем тут init?

Например, прямо из гнома можно установить в настройках времени галочку для синхронизации с NTP, гном через D-Bus сообщит новую настройку systemd-timedated, а последний включит или выключит time-sync.target, в котором выполняется ntpd.

Например, то ли с KDE2 то ли с KDE3, в настройках времени есть птичка «Выставлять время автоматически с [тут можно выбрать адрес сервера]». И это работало без systemd и dbus-а. Невероятно.

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Ну ты подумай, прям Заговор Давящей Красной Шляпы - и suse обманули, и arch, и даже в дебьян с генту обманом проникли - один лишь всезнающий аноним бдит :-D Или бздит - за обилием бессвязных слов сложно понять :)

Lennart
()
Ответ на: комментарий от Kor03d

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

Мне стала нужна в плеере поддержка DLNA. Оказалось, что Amarok его не поддерживает, несмотря на то, что для него есть плагин, потому что kio-upnp-ms крашил его и Dolphin при попытке им воспользоваться (а года 3 назад у кого-то всё работало). Плюс ещё тот баг с kio, из-за которого файлы передавались на сервер только после полного закрытия редактора (подозреваю, что KDE почему-то думало, что kate не умеет kio, но почему, я не разбирался). Плюс ещё вспомнил, как часто ломали kwin, из-за чего он не работал на моей видеокарте в нетбуке. Вот из-за того, что в KDE постоянно что-то ломают, мне и захотелось чего-то другого. А тут и гном пошёл вслед за KDE, сломав раскладки. А потом я запустил MATE и Xfce и увидел, как быстро они запускаются по сравнению с KDE 4 или гномом 3.

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от Lennart

Ну ты подумай

А я и думаю, своей головой. В отличие от...

прям Заговор Давящей Красной Шляпы

Красной Шляпе это выгодно. Если у нее будет глючный systemd, а у всех остальных — нормальная рабочая init-система, то все юзеры тупо разбегутся на другие дистры. Если же они протолкнут systemd везде, то юзерам так или иначе придется его использовать, но самая последняя версия всегда будет у RedHat, и чтобы оно хоть чуть-чуть меньше глючило юзеры будут юзать RedHat... PROFIT!

Поэтому редхатовцам выгодно пропихивать свои systemd-патчи в апстрим, поэтому редхатовцам, которые пишут гном, выгодно завязать гном на systemd, и т.д. Коммерческая выгода.

и suse обманули, и arch

Этих не сложно обмануть. SUSE ничего не изобретает уже очень давно, и держится чуть лучше мандрейка мандривы магейи только за счет большего количества юзеров. Арч вообще никогда ничего не изобретал, но раньше у него был хотя бы Arch Way (KISS), а сейчас не осталось ничего. У этих дистрибутивов мало юзеров и совсем мало мейнтейнеров. Они просто плетутся в хвосте за теми, за кем легче идти. А в хвосте RedHat идти легко.

даже в дебьян с генту обманом проникли

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

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

Или бздит - за обилием бессвязных слов сложно понять :)

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

anonymous
()
Ответ на: комментарий от anonymous

Когда ему показывают, где он не прав

То есть вот этот вот неаргументированный бред про Всемирный Заговор и поголовно обманутых разработчиков дистрибутивов, которые не думают своей головой в отличии от Всезнающего Анонимуса - вот это вот теперь называется «показал где не прав»?

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

Lennart
()
Ответ на: комментарий от Lennart

То есть вот этот вот неаргументированный бред про Всемирный Заговор и поголовно обманутых разработчиков дистрибутивов, которые не думают своей головой в отличии от Всезнающего Анонимуса - вот это вот теперь называется «показал где не прав»?

Нет, чушь про медленный баш, и бред на счет переписывания скиптов на си (что, уже забылось? а ведь systemd начинался именно с этого), дурацкая идея с заменой всех компонентов (readahead, consolekit, hostname, mount, кусков fsck и acpi, менеджеров сессий, tmpwatch, ntpd, cryptsetup, locales, kbd, sysctl, modprobe, ulimit, cat и diff) на собственные велосипеды и их запихивание в систему инициализации, изобретение собственного журнала и его перепиливание с постоянным выдаванием каждого переписывания за какое-то дикое новшество (каждый раз каждое его очередное «изобретение» опускали в говно, но он не унимался). Вот это называется — показать где не прав.

Вспомните, почему хотели отказаться от HAL, за что его ругали? За глюки, раздутость и сложный синтаксис, так? И к чему мы теперь пришли?

Systemd — это самая распухшая, самая глючная и самая сложная система инициализации с самым жутким синтаксисом, который только можно было придумать. Хуже, наверное, только Malbolge. Но разве его это остановило?

«все кто делают - идиоты, один я нихрена не делаю, зато я лучше всех всё знаю» проходят именно по разделу «Бред. Кобылы сивой.»

Скажи об этом Леннарту.

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

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

anonymous
()
Ответ на: комментарий от anonymous

самая глючная и самая сложная система инициализации

номер бага или бздишь.

Когда ему указывают на несоответствие стандартам, он говорит, что стандарты надо менять.

Именно так - наример изменения в FHS с заменой /var/run -> /run назрели очень давно и потому с радостью были приняты разработчиками дистрибутивов. А ты что - предлагаешь молиться на стандарты?

пульс как глючил раньше, так и глючит до сих пор

номер бага или бздишь.

Lennart
()
Ответ на: комментарий от Lennart

самая глючная и самая сложная система инициализации

номер бага или бздишь.

Это не баг — это фича! Systemd — единственная система инициализации, в которой отсутствующие в конфиге опции влияют на её поведение. Только ненормальный мог до такого додуматься.

Именно так - наример изменения в FHS с заменой /var/run -> /run назрели очень давно и потому с радостью были приняты разработчиками дистрибутивов.

Да всем пофиг было. Эта фича нужна только для авторов инит-систем. Больше никто её не использует, дебиановцы даже рекомендацию где-то выкладывали использовать /var/run вместо /run тем кто не пишет early boot tools. И, кстати, это не фича, а костыль, попытка починить некоторые кривые скрипты. Ничего хорошего, как и ничего плохого, в ней нет, не считая захламления корневого каталога.

А ты что - предлагаешь молиться на стандарты?

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

пульс как глючил раньше, так и глючит до сих пор

номер бага или бздишь.

www.linux.org.ru/search.jsp?q=pulseaudio хрип www.linux.org.ru/search.jsp?q=pulseaudio заикается www.linux.org.ru/search.jsp?q=pulseaudio трещит Попроси их написать багрепорты. А лучше сам попробуй на форуме помочь каждому, кто пишет об очередной проблеме со звуком. Заодно сможешь и багрепорт составить.

anonymous
()
Ответ на: комментарий от anonymous

Systemd — единственная система инициализации, в которой отсутствующие в конфиге опции влияют на её поведение.

Вот это ты загнул. В любой программе предусмотрены настройки по умолчанию, используемые при отсутствии явного указания их в конфиге или самого конфига. Берём то же OpenRC, идём в /etc/conf.d, удаляем любой файл или переменную в файле и видим, что используются дефолты из /etc/init.d. Точно так же и в юнитах systemd дефолтами являются Accept=false и Unit=такоежеимя.service.

gentoo_root ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Попроси их написать багрепорты. А лучше сам попробуй на форуме помочь каждому, кто пишет об очередной проблеме со звуком.

А задницу тебе не подтереть? Или сам худо-бедно справляешься? Вообще-то в мире открытого ПО принято что пользователи рапортуют баги в трекер, а авторы стараются их воспроизвести и исправить.

Ты этого не знал? Ну тогда тебе ещё не один Великий Заговор предстоит открыть :-D

Lennart
()
Ответ на: комментарий от gentoo_root

Вот это ты загнул. В любой программе предусмотрены настройки по умолчанию

Да, ясное дело, есть настройки, их можно менять. В баше тоже можно, например, сделать set -x и каждая выполняемая команда будет выводиться на экран, что очень удобно при отладке. Но! Я могу не знать про эти настройки, и ничего не потеряю, могу точно так же читать и писать скрипты.

Точно так же и в юнитах systemd дефолтами являются Accept=false и Unit=такоежеимя.service.

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

anonymous
()
Ответ на: комментарий от anonymous

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

А команды баша в памяти держать не приходится? Или каждый раз лезешь в man bash, чтобы понять, что делает скрипт?

Отличие в том, что в systemd у меня нет выбора.

либо постоянно держать их в памяти

либо лезть в маны

Разве не выбор? Третьего не дано — либо помнишь, либо не помнишь.

gentoo_root ★★★★★
() автор топика
Последнее исправление: gentoo_root (всего исправлений: 1)
Ответ на: комментарий от Lennart

Вообще-то в мире открытого ПО принято что пользователи рапортуют баги в трекер, а авторы стараются их воспроизвести и исправить.

С дуба рухнул? По-твоему разработчики в мире открытого ПО должны постоянно что-то ломать по велению левой пятки, а юзеры — это их бесплатные тестеры, которые должны находить за них баги (я хочу переписать все на коболе... нет, теперь я хочу на хаскеле... нет, теперь я перепишу на Ada, а вы потестируйте и найдите ошибки)? Это только в мире Леннарта так. Хотя идиотов в мире тоже много, и они почему-то все думают, что другие им что-то должны. Леннарт подает дурной пример, да.

Даже в мире коммерческого ПО если разработчик начнет так поступать со своими юзерами, то они просто уйдут к другому. Собственно, потому systemd так старательно пропихивают во все дыры — чтобы юзерам некуда было уйти.

А в мире открытого ПО принято, что разработчики уважают своих пользователей, заботятся об их удобстве и совместимости. Так зародился GNU, так появился GPL — я показал мой код, покажи и ты свой. Уважение и сотрудничество положили основу юникс и его базовых принципов. Если бы не они — линукс бы вообще никогда не появился, была б только кучка кривых недоделанных велосипедов. Хотя да, если ты урод, который никого не уважает, и считает, что он умнее всех, то тебе базовые принципы юникс будут казаться устаревшими.

А вообще, мир — он такой, каким мы его делаем.

anonymous
()
Ответ на: комментарий от anonymous

А в мире открытого ПО принято, что разработчики уважают своих пользователей

И вот этот клоун, только что публично обвинявший авторов systemd в подлоге, лжи и всемирном заговоре теперь требует «уважения», которое, похоже, для него заключается в том, что вместо того, чтобы пользователи репортили баги в трекер - разработчики должны бегать по форумам и сами собирать багрепорты.

И ведь, что удивительно, он искренне уверен, что не несёт бред.

Lennart
()
Ответ на: комментарий от gentoo_root

А команды баша в памяти держать не приходится?

Не приходится. Баш намного проще, чем юниты systemd. В нём всего десяток ключевых слов (if, for, while, case...) и несколько простых конструкций. Есть еще встроенные команды (builtins), но их мне тоже не приходится помнить, сейчас сходу могу назвать только read и set, и даже их опций не помню.

Или каждый раз лезешь в man bash, чтобы понять, что делает скрипт?

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

Разве не выбор? Третьего не дано — либо помнишь, либо не помнишь.

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

anonymous
()
Ответ на: комментарий от Lennart

И вот этот клоун

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

только что публично обвинявший авторов systemd в подлоге

Подлог? Что ты называешь этим словом?

лжи

Как иначе это назвать? Человек использует неправдивые аргументы для продвижения любимой программы и агитации других пользователей — если это не ложь, то что?

и всемирном заговоре

Про всемирный заговор — это твои слова, а не мои.

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

Это — тоже твои слова, а не мои. Получается, именно так выглядит твое мнение?

anonymous
()
Ответ на: комментарий от anonymous

Это — тоже твои слова, а не мои

«С дуба рухнул? ... юзеры — это их бесплатные тестеры, которые должны находить за них баги» - твоя возмущённая реакция на моё утверждение о том, что общепринятая практика это когда пользователи репортят баги в трекер, а разработчики их воспроизводят и устраняют.

Про всемирный заговор — это твои слова, а не мои.

«за счет давления RedHat, постоянной агрессивной рекламы и обмана», «Этих не сложно обмануть. SUSE ничего не изобретает уже очень давно», «Арч вообще никогда ничего не изобретал», «У этих дистрибутивов мало юзеров и совсем мало мейнтейнеров. Они просто плетутся в хвосте за теми, за кем легче идти.» - да, разумеется это не Всемирный Заговор Красной Шапки Обманувшей Всех. Мне просто показалось :-D

Ещё носом натыкать или уже достаточно наелся?

Lennart
()
Ответ на: комментарий от Lennart

Я не хочу сказать, что твой оппонент прав. Но, глядя на твою аргументацию, M$&Google&Oracle&IBM&ets. уже не кажутся «страшными корыстными монстрами».

yyk ★★★★★
()
Ответ на: комментарий от yyk

Но, глядя на твою аргументацию

Покажи в каком именно месте я по-твоему не прав. Не только же с невменяемыми анонимусами дискутировать :)

Lennart
()
Ответ на: комментарий от Lennart

Покажи в каком именно месте я по-твоему не прав.

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

твои слова даже не допускают мысль, что ты можешь быть не прав

крайне любопытно, какая именно фраза произвела на тебя столь сильное впечатление :)

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

Lennart
()
Ответ на: комментарий от Lennart

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

Цитата правильная. Но вывод не верен.

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

Но когда стабильные программы заменяют на глючные. Когда не работают даже базовые функции, которые работали чуть ли не десяток лет, и это объясняют «устаревшими стандартами». Когда простое и привычное в использовании заменяют на сложное и трудно поддерживаемое, да ещё и аргументируют это тем, что вы ничего не понимаете, а мы хотим так и нам виднее (см. переход арча на systemd). И всё это разработчики делают насильно для сотен тысяч пользователей, не смотря на недовольства, то такие разработчики не заслуживают того, чтобы юзеры тестировали их программы и репортили баги в багзиллу.

Представь себе, что твой сосед заложит кирпичами твою входную дверь, потому что ходить через дверь — это устаревший стандарт, и надо ходить через окно. Какой будет твоя реакция?

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

Ты считаешь, такой человек заслуживает того, чтобы люди добровольно ставили себе его лестницы, ломали себе ноги а потом шли к нему и показывали, как это воспроизвести?

да, разумеется это не Всемирный Заговор Красной Шапки Обманувшей Всех.

Нет, это не всемирный заговор. Это заговор красной шапки. Скорее даже не заговор, а бизнес-стратегия. Nothing personal, it's just business.

Ещё носом натыкать или уже достаточно наелся?

Если тебе ещё какие-то мои слова не понятны — конечно, цитируй, мне не сложно их тоже объяснить.

anonymous
()
Ответ на: комментарий от Lennart

Ты предлагаешь мне цитировать твой бред по второму разу?

Нет, я спрашиваю, какой смысл ты вкладываешь в слово «заговор» — есть такое слово в русском языке. Я под словом «заговор» или «сговор» понимаю согласованные действия по достижению какой-либо цели. А ты?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.