Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Представлен многоплатформенный системный менеджер System XVI..."	+/–
Сообщение от opennews (??), 14-Сен-15, 10:53
В рамках проекта System XVI (https://github.com/ServiceManager/ServiceManager) началось развитие нового системного менеджера, сочетающего функции системы инициализации с механизмом обеспечения работы сервисов. System XVI обеспечивает совместимость с простейшими unit-файлами systemd, но не привязан к возможностям Linux, что позволяет использовать его не только для окружений GNU/Linux, но и для BSD-систем (FreeBSD), а также для Linux-окружений на базе библиотеки muslibc и утилит BusyBox. Особенностью System XVI также является модульная архитектура, соответствующая традиционной организации работы UNIX-систем. <center><a href="https://raw.githubusercontent.com/ServiceManager/ServiceMana... src="https://www.opennet.me/opennews/pics_base/0_1442214563.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center> Для сборки System XVI применяется система kBuild, также используемая в  VirtualBox. Из зависимостей требуется установка только пакетов procps и libkqueue. Код проекта распространяется под лицензией GPLv3. Разработка находится на начальной стадии и пока ограничивается синтетическими тестами. Из проблем systemd, побудивших к созданию нового системного менеджера, отмечается монолитная архитектура, основанная на использовании компонентов, методы интеграции которых затрудняют разработку сторонних альтернативных реализаций данных компонентов. Также отмечается большая раздутость systemd - несмотря на то, что реализация PID 1 является достаточно компактной, функциональность systemd обеспечивается 69 исполняемыми файлами и зависит от достаточно сложный логики разбора файлов конфигурации, обработки вызовов DBus и транзакционной системы разрешения зависимостей. Основные концепции разработки System XVI: -  Ориентация на предоставление стабильных, простых и не меняющихся интерфейсов взаимодействия компонентов; -  Разделение функциональности - каждый компонент реализует минимальный набор возможностей, позволяя строить сложные системы на основе сочетания простых элементов в соответствии с традиционным подходом Unix-систем; -  Заменяемость компонентов - любой компонент может быть легко заменён на стороннюю реализацию; -  Живучесть - крах компонентов не должен негативно влиять на систему и после перезапуска компоненты должны полностью восстановить прежнее состояние. URL: https://news.ycombinator.com/item?id=10212770 Новость: http://www.opennet.me/opennews/art.shtml?num=42958
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (-), 14-Сен-15, 10:53	+37 +/–
Собираем чемоданы, опять переезжать. А если серьёзно, то это намного лучше, чем пассивная критика. Не нравится, что systemd не соответствует unix way? Запилите свой вариант, который будет объединять достоинства systemd с unix way. Название только адовое у этого проекта. Зачем римские цифры было использовать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #7, #75

2. Сообщение от Аноним (-), 14-Сен-15, 10:55	+3 +/–
Сейчас прибегут поттеринг-фанбои и начнут орать, что не нужно, что монолитная архитектура рулез и 69 исполняемых файлов + DBus это круто!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #45

3. Сообщение от slavius (?), 14-Сен-15, 10:58	+/–
ну так намекают на system V)) Не? типа мыявляемся более юникс чем другие)) хотя сильно сомневаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8, #9, #16

4. Сообщение от Аноним (-), 14-Сен-15, 10:59	–3 +/–
Концепция интересная, но кто за этим стоит? На гитхабе владелец репозитория называет себя звучным именем "zx9p", но это мало о чем говорит. Я еще могу понять, когда авторы криптовалют скрывают свои имена, но разарботчкиам систем инициализации чего бояться? У RedHat правда есть карательные отряды, которые наказывают всех, кто не согласен на сами-знаете-что?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #10, #43, #81

5. Сообщение от Фанбой (?), 14-Сен-15, 10:59	+3 +/–
Главное во всём этом - 69 файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (-), 14-Сен-15, 11:01	+1 +/–
У редхата - нет. А вот у АНБ, которому очень нужен большой монолит с возможностью напихать кучу дырок и нелепых умолчаний с открытыми всему миру портами - такие отряды есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

7. Сообщение от Аноним (-), 14-Сен-15, 11:02	+20 +/–
В критике нет ничего плохого. Критика это замечательно. Плохие вещи заслуживают критики. В условиях международного разделения труда каждый человек использует множество вещей разработчиком которых он не является. И все их он имеет полное моральное право критиковать. И это хорошо и правильно. Критики боятся только бездарности типа Поттеринга.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11, #24, #25, #49, #198

8. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 11:03	+3 +/–
> ну так намекают на system V)) Не? типа мыявляемся более юникс чем > другие)) хотя сильно сомневаюсь. А мне напомнило: "Государство это я -- Людовик XIV". ---init(1) это я -- ЛЁня I
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #69

9. Сообщение от IZh. (?), 14-Сен-15, 11:04	+1 +/–
А где S6-S15? ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #63

10. Сообщение от Аноним (-), 14-Сен-15, 11:04	–1 +/–
Астротурферов у редхата хватает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #15

11. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 11:05	–31 +/–
>Плохие вещи заслуживают критики. А вот и общечеловеки и ценители "хороших" правильных 1-way-ticket хватит-для-всех решений подтянулись.  Чего, майдаун, зюстем-ди-то -- рулит, да-а?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #19, #42

12. Сообщение от svsd_val (ok), 14-Сен-15, 11:06	+2 +/–
Хорошая новость, будем надеяться что они то знают что они хотят сделать в итоге в отличии от системД.... Так же надеюсь разработчики смогут без большого вреда вырезать из ядра системД, т.к. эта зараза забита гвоздями на 150 и склеена супер клеем настолько что просто его её не выдернуть...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #23

13. Сообщение от Аноним (-), 14-Сен-15, 11:07	+/–
Против АНБ не поможет же, они будут прозрачно подменять код при скачивании с гитхаба. Автору стоит расположить официальный репозиторий в i2p.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #20

14. Сообщение от Аноним (-), 14-Сен-15, 11:11	+/–
Use Gentoo, Luke
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #17

15. Сообщение от Аноним (-), 14-Сен-15, 11:11	+/–
> Астротурферов у редхата хватает. Ах, так это редхат рассылает дроны с томагавками...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (-), 14-Сен-15, 11:14	–10 +/–
Ждем как зилоты вопившие про то как это плохо - крутанутся на 179.5 градуса и начнут вопить что это хорошо. А на мысль что у них точка зрения крутится как флюгер на ветру - будут кивать что нифига, это не полоборота - разница в целых полградуса!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #41

17. Сообщение от svsd_val (ok), 14-Сен-15, 11:20	+2 +/–
Пока использую systemd-shim на дебе, а так можно перейти на Slackware/FreeBSD/OpenBSD или туже дебу но с ядрами kfreebsd и hurd =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #30, #116

18. Сообщение от Аноним (-), 14-Сен-15, 11:23	+1 +/–
Слава Эло, что не прибито гвоздями к dbus и нормальная модульность, всего хорошего проекту, ждем релиза!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #74

19. Сообщение от Аноним (-), 14-Сен-15, 11:25	+1 +/–
Хорошая иллюстрация на тему того как плевались извозчики в свое время. ...от сокольнков до парка - на метро...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #52

20. Сообщение от Аноним (-), 14-Сен-15, 11:28	+2 +/–
> Против АНБ не поможет же, они будут прозрачно подменять код А сверить хэши в цепочке коммитов не пробовал? Говорят, помогает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #27, #94

21. Сообщение от Аноним (-), 14-Сен-15, 11:29	+/–
> Слава Эло, что не прибито гвоздями к dbus Ну то-есть можно забыть о возможности вызывать услуги этой штуки по шине. Так и запишем - it suxx. С точки зрения программирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #26

23. Сообщение от anonymous (??), 14-Сен-15, 11:36	–1 +/–
systemd в ядре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #50

24. Сообщение от Аноним (-), 14-Сен-15, 11:45	–1 +/–
Вы специально упустили слово "пассивная", вероятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #290

25. Сообщение от Аноним (-), 14-Сен-15, 11:50	+/–
> Критики боятся только бездарности типа Поттеринга. Вы заблуждаетесь, Леннарт срать хотел на вашу критику он работает за бабки на редхат и то что вам не нравиться его это не волнует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #46, #113

26. Сообщение от anonymous (??), 14-Сен-15, 11:52	+/–
не прибит гвоздями != не поддерживает. Вот firefox прибит гвоздями к dbus. Даже если собран с опцией --dbus. В отсутствии dbus спамит ошибки. А у того же gimp dbus идёт как опция. Есть dbus - хорошо, работает с ним, нет dbus - и без него справимся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #34, #73

27. Сообщение от Аноним (-), 14-Сен-15, 11:52	+/–
>> Против АНБ не поможет же, они будут прозрачно подменять код > А сверить хэши в цепочке коммитов не пробовал? Говорят, помогает. это способ для людей с мозгом, не наш путь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #37

28. Сообщение от Аноним (-), 14-Сен-15, 11:56	+4 +/–
<Картинка>Вместо 15 стандартов - 16 стандартов</Картинка>
Ответить | Правка | Наверх | Cообщить модератору

29. Сообщение от Аноним (-), 14-Сен-15, 12:03	–7 +/–
Леннарт Написал systemd теперь другие начали писать типо лучше, а на дели еще хуже, systemd работает уже и внедрено в большинство дистрибутивов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #33

30. Сообщение от Аноним (-), 14-Сен-15, 12:06	+/–
Ещё CRUX, PCLinuxOS, Void linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #104

31. Сообщение от Аноним (-), 14-Сен-15, 12:15	+3 +/–
> Из проблем systemd, побудивших к созданию нового системного менеджера, отмечается монолитная архитектура, основанная на использовании компонентов, методы интеграции которых затрудняют разработку сторонних альтернативных реализаций. Несмотря на то, что реализация PID 1 в systemd является достаточно компактной ну да. стоит тронуть чуть чуть код systemd - (хрена он компактный) как получаешь черный ящик, после sigsev в одном из модулей
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36

32. Сообщение от Аноним (-), 14-Сен-15, 12:16	+/–
он не работает. Попробуй его запустить на системе из ядра которой выключен cgroups. Удачной перестановки системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35, #80, #139

33. Сообщение от Аноним (-), 14-Сен-15, 12:27	+4 +/–
Дели пишется с большой буквы, так как является названием населенного пункта. Что такое "типо" я не в курсе, так как русский язык мой друг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #55

34. Сообщение от Аноним (-), 14-Сен-15, 12:35	+2 +/–
> не прибит гвоздями != не поддерживает. С точки зрения программирования это означает что просто написать работу с фичой - нельзя. Надо писать кучу кода для проверки есть ли оно тут вообще и какие-то костыли и/или заглушки на случай когда фичи не оказалось. А в результате - это будет раза в три больше кода, да еще работает не везде. Не очень привлекательно для програмеров. Поэтому они могут просто достать фак из кармана - и программить это будет только кучка особо упертых зилотов. Сильно повезет, если это число будет отлично от ноля и тем паче больше единицы. Я уже видел как все это работает с иксами. Когда половина софта не заморачивается с обнаружением опций и при активной отрисовке - все просто жутко тормозит. Я считаю что с точки зрения программирования - в системе таки должна быть нормальная шина, кроме совсем уж микроэмбедовки. Да даже там нынче u-bus в опенврт пилят. > Вот firefox прибит гвоздями к dbus. Даже если собран с опцией --dbus. В отсутствии dbus спамит ошибки. Скажи спасибо что не валится с фатальным ассертом. > - хорошо, работает с ним, нет dbus - и без него справимся. Вот что gimp с dbus может делать - я честно говоря не очень в курсе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #39, #115

35. Сообщение от Аноним (-), 14-Сен-15, 12:39	–1 +/–
> он не работает. Попробуй его запустить на системе из ядра которой выключен cgroups. А можно еще веселее - на системе без ядра. Ну а что, grub нынче сойдет за небольшую операционку...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #48

36. Сообщение от Аноним (-), 14-Сен-15, 12:40	–3 +/–
> ну да. стоит тронуть чуть чуть код systemd - (хрена он компактный) > как получаешь черный ящик, после sigsev в одном из модулей Попробуйте код ядра потрогать! Там "sigsegv" выглядит даже интереснее чем в системном софте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #110

37. Сообщение от Аноним (-), 14-Сен-15, 12:48	–1 +/–
> это способ для людей с мозгом, не наш путь Те кто с мозгом - могут попробовать одновременный доступ с разных точек. Если вы одновременно сунетесь из США, Китая, России, Нидерландов, Франции, Пакистана и еще парочки рандомных стран - Тотальный Контроль может пожалуй дать маху и - "treason uncloaked". Кстати если вы думаете что это бывает только теоретически - зря. Многоточечная верификация содержимого ресурса - очень интересна и познавательна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #40

39. Сообщение от Аноним (-), 14-Сен-15, 12:55	+/–
> Не очень привлекательно для програмеров. А ну кажи профиль на гитхате, ыкспертный вы наш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #155

40. Сообщение от аноним10 (?), 14-Сен-15, 13:01	+/–
>> это способ для людей с мозгом, не наш путь > Те кто с мозгом - могут попробовать одновременный доступ с разных точек. > Если вы одновременно сунетесь из США, Китая, России, Нидерландов, Франции, Пакистана > и еще парочки рандомных стран - Тотальный Контроль может пожалуй дать > маху и - "treason uncloaked". > Кстати если вы думаете что это бывает только теоретически - зря. Многоточечная > верификация содержимого ресурса - очень интересна и познавательна. Если сервера github и следилки АНБ находятся в одних и тех же датацентрах, например сервера АНБ стоят на всех каналах в инет из датацентра, тогда хоть подключись к github со всех компьютеров мира, получишь то что захотел АНБ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #135

41. Сообщение от клоун (?), 14-Сен-15, 13:15	+3 +/–
Это не точка зрения, это их корпорации на *** вертят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

42. Сообщение от Адекват (ok), 14-Сен-15, 13:15	+5 +/–
>>Плохие вещи заслуживают критики. > А вот и общечеловеки и ценители "хороших" правильных 1-way-ticket хватит-для-всех решений > подтянулись.  Чего, майдаун, зюстем-ди-то -- рулит, да-а?! Лично я НИХРЕНА не понял что вы хотели сказать - спрашивается зачем писали ? чтобы просот написать ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #56, #57

43. Сообщение от Аноним (-), 14-Сен-15, 13:20	+8 +/–
>zx9p Может, его главный проект — портирование Plan 9 на ZX Spectrum?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

44. Сообщение от Crazy Alex (ok), 14-Сен-15, 13:24	+2 +/–
Хорошая новость, но в упор не пойму, чем SunRPC здеьс лучше, чем DBus.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76

45. Сообщение от Owlet (?), 14-Сен-15, 13:35	+2 +/–
Уж точно лучше, чем > классического TI-RPC/SunRPC
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

46. Сообщение от клоун (?), 14-Сен-15, 13:35	–7 +/–
А кроме того, у него есть цель и он к ней идёт. Рано или поздно ядро Линукс станет пикоядерным. И мне всё равно будет инициатива исходить от Торвальдса, который сидит в центре ядра и уже лет 10 ноет про это, от Поттеринга, который создаёт модульную систему инициализации и не скрывает что его цель - ядро, или от Пинки и Брэйна в рамках их плана по захвату мира. Это как пластиковые карты: обычно их выпускают банки, а затем разные компании одна за другой начинают их принимать к оплате. Но есть и другой путь, он реализован напр. в Японии, когда проездной на электричку сделали пополняемым, затем им стало можно расплачиваться за метро и автобус, затем делать покупки в привокзальных магазинах, и количество мест где можно ими расплатиться растёт с каждым годом. Результат - это как вершина горы, к которой ведут десятки путей. Есть попроще, есть посложнее, есть неприступные отвесные утёсы. Но какую бы дорогу ты не выбрал, если не отступишься, то попадёшь на вершину. Я тут тебя уже давно жду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #66, #86

47. Сообщение от Owlet (?), 14-Сен-15, 13:37	+1 +/–
> Разработка находится на начальной стадии и пока ограничивается синтетическими тестами. Ну, в этом и секрет легковесности и (псевдо)юниксвейности. А вот когда они попробуют это в реальном мире (как Red Hat) - сразу получат systemd. В лучше случае. > при помощи классического TI-RPC/SunRPC, без применения DBus Я так понимаю, местные школьники радуются, посколько не имеют понятия, что такое TI-RPC/SunRPC, верно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

48. Сообщение от svsd_val (ok), 14-Сен-15, 13:38	+/–
Пример, простой, ядрышко от freebsd поставили там любимый SystemD ? или ядрышко от OpenBSD, или hurd ? я что то сомневаюсь что другим системам такой слепленный из трупов (хороших проектов) фрЁнкЁнштЁйн нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #106

49. Сообщение от Адекват (ok), 14-Сен-15, 13:48	–2 +/–
> Критики боятся только бездарности типа Поттеринга. Полностью согласен. А еще такая картина складывается - есть линукс, есть админ "не полный даун", и он понимает "а зачем платить за лицензию винды, если на базе простого компа можно собрать бесплатную файло-помойку, плюс программный рэйд из простых жестких дисков - это как раз то что нужно для нашей конторки из 50 человек" . Сказано сделано - собрал админ из того что было файлопомойку на линуксе, все работает как часы. Шли годы, все работало, линукс обновлялся регулярно, все было хорошо, пока не пришел systemD, и не стал выдавать проблемы, которые до него ДАВНО были решены - смена имен меж собой имен жестких дисков, невозможность загрузки, при недоступности жесткого диска, прописанного в fstab, какие-то непонятные unit-файлы... Все это привело к тому, что raid рассыпался и все данные конторки были потеряны. Админа уволили. потому что он доверял линуксу, доверял как надежной системе, и если бы не systemd - стечения обстоятельств такого не было бы. История выдуманная если что. История вторая, выдуманная наполовину: Тоже админ, только поднял интернет-шлюз на линуксе, все так же работало, и работало некоторе время с systemd, после перезагрузки после обновления сетевые интерфесы именами не менялись (после допиливания), пока однажды ночью не выключили свет, причем несколько раз в минуту выключали - шлюз выключился. потом включился по обратной свзяи, стал загружаться и тут свет опять выключили, шлюзу то пофигу - он на упс был, а вот железка, через которую шлюз получал интернет - была без УПСа, так уж провайдер свое оборудование установил. Вот и получилось, что к моменту, когда systemd попытался назначить ip на сетевую карту, он не увидел линка и....просто не стал назначать никакой ip. Ведь в конфиге для сетевки не было  SkipNoCarrier=yes, а по умолчанию SkipNoCarrier=No. Как результат - полдня контора без инета вообще, потому чтобы вызвать админа из отпуска понадобилось часов 5, но этого хватило, что сорвалось несколько крупных контрактов и контора понесла серъезные убытки. Дорогие мои systemd-funboys - скажите, вы готовы рискнуть своей работой, подняв хоть какое-то решение на systemd ? вы уверены что глюк не проявиться через 10-15 перезагрузок (после длительного отключения света, или после плановых обновлений), не смотря на то, что первые 5-6 перезагрузок прошли нормально :) ? У меня нет, поэтому я systemd не доверяю, и уверен что в целом после таких приколов доверие к линуксу как к ОС сильно поубавиться, и аудитория линукса сильно сократиться. Останется 5-6 преданных фанатов на всем земном шаре, а остальные будут перейти на винды, или bsd, ради уверенности в то, что "ничгео на заглючит".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #53, #54, #60, #70

50. Сообщение от Аноним (-), 14-Сен-15, 13:49	+/–
>>systemd в ядре? Анон имел ввиду, что само по себе systemd прибито гвоздями именно к ядру Linux и его невозможно портировать на отличные платформы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #58

51. Сообщение от Crazy Alex (ok), 14-Сен-15, 13:59	+3 +/–
Чепуха. У редхата не было (и быть не могло) цели дать возможность лёгкой замены компонентов. Они делают ровно обратное - пытаются получить полностью подконтрольную и удобную для себя систему - что логично, но подходит сильно не всем. А вот насчёт RPC - согласен. Чем сановский - уж лучше DBus тащить. Во всяком случае, его мне никогда не требовалось руками перезапускать после невнятных зависаний. Ну и RPC вместо сообщений на шине - это вообще плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #121

52. Сообщение от клоун (?), 14-Сен-15, 14:02	+4 +/–
Извозчиков в Москве тогда уже не было. Да и вообще, знай вы историю получше, то понимали бы, что появление метро (тогда там ходили паровозы на перегретом паре) в Лондоне было воспринято всеми, в т.ч. извозчиками, как неизбежная необходимость. Во второй половине 19-ого века города задыхались не от дыма, как сейчас, а от навоза. Канализация была лишь в домах богатых горожан, мусор и помои просто выливали на улицу. Лошади так и вовсе гадили где придётся. В 1858, а затем в 1860 гг. в Лондоне произошли "Великое зловоние" (это термин), на вики есть кратенькое описание событий тех лет. Развитие промышленности привело к тому, что многие люди стали ездить на работу за много километров, что привело к образованию пробок. Что, с учётом того что лошади гадят, делало летние поездки особенно ароматными. Первая ветка метро строилась за государственный счёт открытым способом и получила название "столичная железная дорога" ("metropolitan railway") или сокращённо "метро". С тех же лет остался ещё одно известное всем слово - "WC" ("Water closet" = "Водный туалет") в котором был смыв водой. Другие города пришли к метро позже, но по тем же причинам. И никаких возражений, за редкими исключениями, не возникало. Первое метро в Москве хотели построить в 1880 г., но против выступили не извозчики, а РПЦ, которая посчитала, что спускаться под землю значит идти на поклон к дьяволу. Пришлось проектировать метро по эстакадам. И опять вмешалось РПЦ. Метро на эстакадах требовало сноса некоторых зданий, а большинство зданий в центре города принадлежало РПЦ. Особенно их возмутил снос подсобных построек одного из монастырей, за что патриарх лично пообещал отречь всех кто примет участие в реализации проекта от церкви.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #59, #84, #149

53. Сообщение от Легион (?), 14-Сен-15, 14:25	+5 +/–
> Как результат - полдня контора без инета вообще То есть он не оставил никого вместо себя? То есть он не построил бэкапный канал, например, по воздуху? > а остальные будут перейти на винды, или bsd, ради уверенности в то, что "ничгео на заглючит". На венды?!! Не заглючит?!! :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #67

54. Сообщение от qwerty (??), 14-Сен-15, 14:40	+/–
>> Критики боятся только бездарности типа Поттеринга. > Админа уволили. потому что он доверял линуксу, доверял как надежной системе Читать по теме - жизнененный цикл технической системы, раздел валидация - управление конфигурациями - управление изменениями Если "админ" выступает архитектором-интегратором, любого маштаба, то отвественность несет соотвествующую. Почему вы предполагаете что IT сотрудник не обязан знать хотя бы базовой профессиональной методологии - АХЗ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #102

55. Сообщение от Аноним (-), 14-Сен-15, 14:52	–5 +/–
>русский язык мой друг А нормальные, невыдуманные друзья у тебя есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #68

56. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 14:55	–2 +/–
>>>Плохие вещи заслуживают критики. >> А вот и общечеловеки и ценители "хороших" > Лично я НИХРЕНА не понял что вы хотели сказать - спрашивается зачем В основном это реакция на "общеевропейскоие" ценности чуть ниже, а в процитированном `>>>` утверждается, что "плохие" заслуживают критики. Видимо больше, чем "хорошие". Я дальше читать не стал, несмотря на то, что плевок-то был в торону Поттерринга. Потому что это не аргумент, а дырка от. И даже на "моей" стороне такие аргУменты видеть противно, тень Георгия Аполлоновича Гапона чудится. > писали ? чтобы просот написать ? Лучше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

57. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 14:57	–2 +/–
> Лично я НИХРЕНА не понял что вы хотели сказать Гыг. Интересно, те +двое плюсующих хотели сказать, что да-таки корреспондент ничего не понял (и они с этим согласны), или не понявших на 3 больше, чем понявших?...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

58. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 15:04	+/–
>>>systemd в ядре? > Анон имел ввиду, что само по себе systemd прибито гвоздями именно к > ядру Linux и его невозможно портировать на отличные платформы. Так  они, вроде ядро уже форкнули -- для kdbus. Правда "девелопят" пока и ретрограды из в мейнлайн kernel.org не пускают. Но вона клоун чуть выше вещает, что и EL-форк не загорами, ретроградов погонят.   Жду этого конного цирка с нетерпением! </?>
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #61, #87, #154

59. Сообщение от жабабыдлокодер (ok), 14-Сен-15, 15:07	+1 +/–
Даю справку. До революции существовало несколько конкурирующих планов Московского метро, различных как по структуре, так и по протяженности. Некоторые варианты большей частью проходили над землей... Причин, по которым метро так и не построили было несколько, в основном, дороговизна и неопределенность с дальнейшим финансированием (проекты предусматривали совместное частно-муниципальное финансирование). Гиляровский, кстати, утверждал, что главная причина - опасность, что все средства будут разворованы. И, самое забавное, патриаршество было восстановлено только в 1917 году - поэтому патриарх никак не мог протестовать против метро... Сколько каши в голове...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #62

60. Сообщение от Аноним (-), 14-Сен-15, 15:35	+/–
Не бугурти, мамка дома их не заругает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

61. Сообщение от anonymous (??), 14-Сен-15, 15:38	–2 +/–
зачем? грег вроде как большой апологет и линус считает что kdbus в ядре скорее быть чем нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #88

62. Сообщение от клоун (?), 14-Сен-15, 15:45	–3 +/–
Упоминания про мракобесие РПЦ вычёркиваются из современной истории России. Читайте не вики, а первоисточник.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

63. Сообщение от Аноним (-), 14-Сен-15, 15:49	+/–
В море Дирака же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

64. Сообщение от anonymous (??), 14-Сен-15, 15:58	–2 +/–
Не взлетит. Если только за ним не стоит крупная контора уровня редхат.
Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от Xaionaro (ok), 14-Сен-15, 16:02	+/–
libkqueue лично у меня segfault-ился на Debian/Jessie (ещё до заморозки) при попытке использовать для наблюдения за событиями в большом файловом дереве. Это не негатив, а просто related воспоминание. Если кому-то интересно состояние бага, то могу перепроверить.
Ответить | Правка | Наверх | Cообщить модератору

66. Сообщение от Аноним (-), 14-Сен-15, 16:04	+1 +/–
А криптовладыки за вами не следят?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

67. Сообщение от Аноним (-), 14-Сен-15, 16:07	–5 +/–
Ты просто не умеешь их готовить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #101

68. Сообщение от Аноним (-), 14-Сен-15, 16:16	+1 +/–
>>русский язык мой друг > А нормальные, невыдуманные друзья у тебя есть? Армия и флот. Пиши по теме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #100

69. Сообщение от Аноним (-), 14-Сен-15, 16:25	+/–
А XVI как раз казнили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #103, #123

70. Сообщение от stas (??), 14-Сен-15, 16:36	–4 +/–
Systemd хорошо документирован, так что все проблемы, не от systemd, а от конкретного системного администратора. Некоторые дефолтные настройки могут быть не оптимальны с этим я согласен, но на то и сисадмин что-бы настроить операционную систему, систему иницилизации, демоны и т.д.. И к слову, вы, до сих пор вольны выбирать систему иницилизации даже несмотря на тот факт, что кажется в многих дистрибутивах systemd прибит навечно гвоздями к ним.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #72, #79

71. Сообщение от mma (?), 14-Сен-15, 16:50	+3 +/–
Ну пускай делают, посмотрим что выйдет. Никто же не заставляет этим пользоваться.
Ответить | Правка | Наверх | Cообщить модератору

72. Сообщение от Andrey Mitrofanov (?), 14-Сен-15, 16:58	+/–
> Systemd хорошо документирован, так что все проблемы, не от systemd, а от Докажи! . http:/openforum/vsluhforumID1/96286.html   Время пошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

73. Сообщение от GotF (ok), 14-Сен-15, 17:06	+1 +/–
> А у того же gimp dbus идёт как опция. Есть dbus - хорошо, работает с ним, нет dbus - и без него справимся. Угу, и каждый файл открывается в отдельном окне.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #95, #111

74. Сообщение от GotF (ok), 14-Сен-15, 17:13	+/–
> не прибито гвоздями к dbus systemd тоже не прибит, JFYI. ~ # apt remove dbus Reading package lists... Done Building dependency tree       Reading state information... Done The following packages will be REMOVED:   caja dbus dbus-x11 gajim gvfs gvfs-daemons gvfs-fuse gvfs-libs kbdd libatasmart4 libpackagekit-glib2-18   libpam-systemd libparted2 libpolkit-agent-1-0 libpolkit-backend-1-0 libpolkit-gobject-1-0 libudisks2-0   libunique-1.0-0 mate-desktop packagekit packagekit-tools parted policykit-1 python-nbxmpp udisks2 0 upgraded, 0 newly installed, 25 to remove and 0 not upgraded. After this operation, 28.4 MB disk space will be freed. Do you want to continue? [Y/n] n Abort. 1 ~ # systemctl --version systemd 225 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN Как можно заметить, удаляется только libpam-systemd, хотя это и немаленькая потеря для системы с systemd в качестве инита (кому как, впрочем).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

75. Сообщение от Vkni (ok), 14-Сен-15, 17:14	–1 +/–
> Запилите свой вариант, который будет Зачем, если он уже давным давно сделан?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #78, #134

76. Сообщение от anonymous (??), 14-Сен-15, 18:40	+/–
>Хорошая новость, но в упор не пойму, чем SunRPC здеьс лучше, чем DBus. Его не собираются пихать внутрь systemd, очевидно же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #141

77. Сообщение от Аноним (-), 14-Сен-15, 18:40	+/–
Пока вы тут обсуждаете, проект уже успел сменить лицензию на BSD.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #82, #85

78. Сообщение от Аноним (-), 14-Сен-15, 18:42	+/–
Действительно, зачем, если вы можете использовать то, что вас не устраивает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

79. Сообщение от Аноним (-), 14-Сен-15, 18:44	+1 +/–
Systemd глючит барин мочи нет, воротай барин как было. Сегфолты окоянные одолели, крэши к горлу подступили спасу нет обычному сисадмину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

80. Сообщение от Аноним (-), 14-Сен-15, 18:47	+1 +/–
> он не работает. Попробуй его запустить на системе из ядра которой выключен > cgroups. Удачной перестановки системы. Systemd раньше запускался и без cgroups! Правда, сразу же падал ... но зато запускался! Хоть и падал. https://bugs.freedesktop.org/show_bug.cgi?id=74589 > systemd segfaults if no cgroups are available > it dies due to a NULL pointer exception in unit_default_cgroup_path() И да, для Свидетелей: народу не нравится не Cам Великий Рыжий Пророк, а его отношение к делу: > Richard Wagner: > On systems without cgroups (like linux containers) systemd takes the following branch in > manager_setup_cgroup() > But later it dies due to a NULL pointer exception in unit_default_cgroup_path(). ... Великий Рыжий Пророк: > To make this work we'd need a patch, as nobody of us tests this. > Lennart Poettering 2014-04-04 14:56:43 UTC > Well, cgroups-less kernels are explicitly not supported by systemd. Аватара Великого Ананима Который Не Забывает И Не Прощает: >> To make this work we'd need a patch, as nobody of us tests this. > Yes, it's clear you don't test for NULL pointers before deferencing. > Nobody else should need to provide a patch to fix the bug you created. > If you can't figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY! > You should never EVER be deferencing any pointer without first sanity checking its value. > NO EXCEPTIONS! > P.S. Please go die in a fire.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

81. Сообщение от Аноним (-), 14-Сен-15, 18:55	+7 +/–
> Я еще могу понять, когда авторы криптовалют скрывают свои имена а вы почему Аноним тогда? зарегистрируйтесь под настоящим именем вроде "Тапкин Николай Палыч 03.04.1999, г.Череззаборногузадерищщенск ул.Плюшкина д.123/4 кв.5". или вы боитесь чего?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

82. Сообщение от Аноним (-), 14-Сен-15, 18:57	+2 +/–
> Пока вы тут обсуждаете, проект уже успел сменить лицензию на BSD. Через пол года сменит на Apache
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #144

83. Сообщение от Аноним (-), 14-Сен-15, 19:19	+1 +/–
"Гарри Поттер" ещё не высказал своё "фи"?
Ответить | Правка | Наверх | Cообщить модератору

84. Сообщение от anonas (?), 14-Сен-15, 19:23	–3 +/–
_>а большинство зданий в центре города принадлежало РПЦ_ Знали бы вы историю, то не несли бы такую ахинею про то, что у РПЦ была собственность, лол. Всей церковной собственностью в России до революции владел и управлял Священный Синод, орган сугубо государственный и никаким древнееврейским культом не страдавшим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #109

85. Сообщение от Аноним (-), 14-Сен-15, 19:56	–1 +/–
Как будто, что то плохое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #89

86. Сообщение от Аноним (-), 14-Сен-15, 19:58	+3 +/–
Клоун хорош, как всегда. Сравнил ядро с пластиковой картой и устроил развесистую демагогию. :) > ... если не отступишься, то попадёшь на вершину. Я тут тебя уже давно жду. О, майн Готт...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

87. Сообщение от Аноним (-), 14-Сен-15, 20:04	+/–
Будем надеяться, что это "каффно" будет хотя бы отключаемым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

88. Сообщение от GotF (ok), 14-Сен-15, 20:26	+/–
> линус считает что kdbus в ядре скорее быть чем нет Торвальдс пока ни слова хорошего не сказал в сторону этого чуда. Я припоминаю по меньшей мере две попытки пихнуть kdbus в ядро, закончившихся провалом и обидами пихальщиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #93

89. Сообщение от Анонизм (?), 14-Сен-15, 20:31	+/–
Как буд-то быть троллем что-то хорошее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

90. Сообщение от Аноним (-), 14-Сен-15, 20:32	+/–
"System XVI is free software. You may use it and its source code under the terms of the Revised BSD licence" Не GPLv3!
Ответить | Правка | Наверх | Cообщить модератору

91. Сообщение от Аноним (-), 14-Сен-15, 20:35	+1 +/–
Я так понял, что картинку в новости никто не посмотрел.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #183

92. Сообщение от DFX (ok), 14-Сен-15, 20:50	+4 +/–
Похоже у systemd нашли Один Фатальный Недостаток... и мы все знаем какой :]
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98

93. Сообщение от anonymous (??), 14-Сен-15, 20:51	–1 +/–
да, я и не говорил что линус его хвалит или что, но склоняется к тому чтобы в итоге принять в апстрим https://lkml.org/lkml/2015/6/23/657
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #96

94. Сообщение от Аноним (-), 14-Сен-15, 20:52	+/–
а коммиты никто не подменит, просто их будут делать псевдобезрукие работники уровня сегельмана и хенсона, и хрен кто узнает о проблемах
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

95. Сообщение от Аноним (-), 14-Сен-15, 20:54	+/–
>> А у того же gimp dbus идёт как опция. Есть dbus - хорошо, работает с ним, нет dbus - и без него справимся. > Угу, и каждый файл открывается в отдельном окне. а в каком же ему ещё окне открываться? в котором уже какой-то файл открыт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #97

96. Сообщение от GotF (ok), 14-Сен-15, 20:55	+/–
> да, я и не говорил что линус его хвалит или что, но > склоняется к тому чтобы в итоге принять в апстрим > https://lkml.org/lkml/2015/6/23/657 Хм, я ухитрился пропустить первую часть письма при чтении. Или это была цитата из последних абзацев. Ну будет так будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

97. Сообщение от GotF (ok), 14-Сен-15, 20:56	+1 +/–
>>> А у того же gimp dbus идёт как опция. Есть dbus - хорошо, работает с ним, нет dbus - и без него справимся. >> Угу, и каждый файл открывается в отдельном окне. > а в каком же ему ещё окне открываться? в котором уже какой-то > файл открыт? Да. Там уже несколько лет мультитабовый однооконный интерфейс. С разморозкой!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

98. Сообщение от Аноним (-), 14-Сен-15, 20:58	+1 +/–
> Похоже у systemd нашли Один Фатальный Недостаток... и мы все знаем какой > :] один? там недостаток на недостатке недостатком погоняет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #105

100. Сообщение от anonymous (??), 14-Сен-15, 21:24	+1 +/–
> Пиши по теме. Стоит заметить, что сообщение про грамматические ошибки, хоть и было справедливо, но так же было не по теме
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

101. Сообщение от Pahanivo (ok), 14-Сен-15, 21:25	+/–
> Ты просто не умеешь их готовить. после того как я увидел первый раз офтоп_8 и понял, что надо сначала почитать краткий мануал по интерфейсу ... я честно говоря оху... аху.... ух как удивился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

102. Сообщение от Аноним (-), 14-Сен-15, 21:35	+/–
Если ты полагаешь что один(фиг с ним несколько людей) могут проверить все возможные варианты поведения системы на внешние воздействия... Ну у меня для тебя плохие новости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

103. Сообщение от slavius (?), 14-Сен-15, 21:45	–1 +/–
а они просто историю не учили))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #146

104. Сообщение от chinarulezzz (ok), 14-Сен-15, 22:27	+/–
http://without-systemd.org/wiki/index.php/Main_Page#Free.2FO...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

105. Сообщение от Красные Глаза (ok), 14-Сен-15, 22:38	–4 +/–
Недостаток на недостатке это вы погоняете. А systemd просто работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #107

106. Сообщение от Stax (ok), 14-Сен-15, 22:38	+/–
Секундочку. systemd знает, какие процессы породил сервис (даже если он после форка завершился), анализируя cgroup этого сервиса. Это позволяет гарантированно отслеживать сервисы даже без ведения pid-файлов (которые процессы со многими детьми нормально обычно все равно не ведут, оставляя только pid мастер-процесса). Это принципиальная разница по сравнению с другими системами, которые не могли отслеживать без pid-файлов и хитрых функций поиска процесса по имени, что было нетривиально для процессов, меняющих имя (поиск требуется для проверки, что процесс не умер, оставив старый pid-файл). А форкающие процессы вообще не могли отслеживать, полагаясь, что отслеживать мастер-процесс и посылать ему сигналы достаточно, чтобы контролировать детей (что не всегда так в реальной жизни). systemd же, наконец, решил эту проблему нормально, используя cgroups. А чем предлагается заменить это в системе, где cgroups отсутствует? Возвращаемся к старым хакам и простыням на bash'е, которые, к тому же, дают сбой в ситуациях, когда дети выживают без процесса-супервизора?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #158

107. Сообщение от chinarulezzz (ok), 14-Сен-15, 22:39	+2 +/–
http://opennet.ru/openforum/vsluhforumID1/96286.html помоги чтоб просто работал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105 Ответы: #108, #122

108. Сообщение от Красные Глаза (ok), 14-Сен-15, 22:44	–3 +/–
Предлагаю начать с этого: http://freedesktop.org/wiki/Software/systemd/Debugging/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #114

109. Сообщение от angra (ok), 14-Сен-15, 23:03	+2 +/–
А отделение церкви от государства большевики просто по приколу придумали, а попы точно также по приколу требовали от большевиков неприкосновенности государственной собственности, находившейся до этого в руках церкви, а потом подбивали народ воевать за это. Можете еще рассказать, что в ближневосточных теократиях тоже всей церковной собственностью владеет государство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #112

110. Сообщение от anonymous (??), 14-Сен-15, 23:13	–1 +/–
systemd таки не ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #140

111. Сообщение от Mihail Zenkov (ok), 14-Сен-15, 23:18	+/–
>> А у того же gimp dbus идёт как опция. Есть dbus - хорошо, работает с ним, нет dbus - и без него справимся. > Угу, и каждый файл открывается в отдельном окне. Это косяк конкретно гимпа. FF/palemoon/geany/etc без всяких d-bus, файлы в новой вкладке открывает. Для себя лично решил этот вопрос патчем гимпа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #138

112. Сообщение от slavius (?), 15-Сен-15, 00:31	–3 +/–
в россии до революции церковь являлась частью государства. это так напоминание. и вся церковная собственность была и государственной тоже. опять же напоминание. а по делу-поздно они спохватились за реализацию системы инициализации . уже 2 года как системд семимильными шагами по линухам))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #120

113. Сообщение от arisu (ok), 15-Сен-15, 01:16	+2 +/–
> и то что вам не нравиться его это не волнует. 1. «-тся» и «-ться». не надо было тебе прогуливать школу. 2. совсем не волнует, аж до истерик в гуглоплюсе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

114. Сообщение от chinarulezzz (ok), 15-Сен-15, 01:18	+3 +/–
помог :-D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #117, #126, #130

115. Сообщение от arisu (ok), 15-Сен-15, 01:23	+5 +/–
> Я уже видел как все это работает с иксами. Когда половина софта > не заморачивается с обнаружением опций и при активной отрисовке - все > просто жутко тормозит. но системная шина, конечно, магически эти проблемы решает. ведь не надо писать код для работы с сервисами, МАГИЯ!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #136

116. Сообщение от kachsheev (ok), 15-Сен-15, 01:28	+/–
В твоём случае проще на Devuan перейти. systemd с либами выпиливается на ура.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

117. Сообщение от arisu (ok), 15-Сен-15, 01:28	+3 +/–
> помог :-D вот такое вот у них понятие про «просто работает», что поделать…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #127, #161

120. Сообщение от angra (ok), 15-Сен-15, 03:07	+/–
Собственностью владеет тот, кто получает с нее доход, может ее продать или сдать в аренду. Де-факто государственной собственностью владела церковь, а не наоборот. Когда большевики начали возвращать собственность государству попы крайне возмутились, как и рядом других действий, связанных с отделением церкви от государства. А в вашей альтернативной реальности они должны были радоваться избавлению от тяжелой пяты государства. Есть любопытный документик на тему того, что хотела церковь от большевиков в 1917-м: http://asnecto.livejournal.com/359728.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

121. Сообщение от Fracta1L (ok), 15-Сен-15, 06:59	–1 +/–
> Они делают ровно обратное - пытаются получить полностью подконтрольную и удобную для себя систему - что логично, но подходит сильно не всем. Силами подкупленных и запуганных программистов, львиная доля которых работает вовсе не в RH. Но какое это имеет значение для воспалённой логики хейтеров, не так ли?)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #125

122. Сообщение от Fracta1L (ok), 15-Сен-15, 07:01	+/–
Тебе должен помогать врач, если ты боевой сервер обновляешь на тестовую ветку дистрибутива)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #124

123. Сообщение от Константавр (ok), 15-Сен-15, 07:03	+1 +/–
Говорите, есть надежда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

124. Сообщение от Xaionaro (ok), 15-Сен-15, 08:13	+/–
> Тебе должен помогать врач, если ты боевой сервер обновляешь на тестовую ветку > дистрибутива) Может вы и правы, хоть и лично у меня до перехода jessie на systemd, он всегда загружался и перезагружался без проблем, даже когда был testing... Более того, где-либо с OpenRC у меня всегда порядком меньше проблем, чем с systemd, несмотря на абсолютно мизерное комьюнити и нестандартность этого решения в Debian. IMHO, оратор чуть выше немного не прав, высказавшись: > А systemd просто работает. И я сейчас не говорю, что systemd -- говно. Просто сама фраза "systemd просто работает" мне кажется очень неискренней. P.S. Хватит уже переходить на личности, учитесь разговаривать как взрослые люди (конструктивно): > Тебе должен помогать врач Полагаю, вы -- разумный человек. Просто ленитесь формулировать свои мысли нормально (см. пирамиду Грэма).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #128, #131, #166

125. Сообщение от Xaionaro (ok), 15-Сен-15, 08:42	+/–
>> Они делают ровно обратное - пытаются получить полностью подконтрольную и удобную для себя систему - что логично, но подходит сильно не всем. > Силами подкупленных и запуганных программистов, львиная доля которых работает вовсе не > в RH. Но какое это имеет значение для воспалённой логики хейтеров, > не так ли?) Львиная доля серьёзных архитектурных вкладов в systemd делается не сотрудниками RH? И притом большинство из них не направлено на развязку компонентов? Поверхностный взгляд на "git log" показывает совершенно обратное. Можете привести несколько примеров, хотя бы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #143

126. Сообщение от Красные Глаза (ok), 15-Сен-15, 08:55	–1 +/–
> помог :-D По той информации, что представлена в вашем топике вам поможет только ясновидящий. Учитесь пользоваться инструментами с которыми работаете, чтобы не забивать микроскопом гвозди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

127. Сообщение от Красные Глаза (ok), 15-Сен-15, 08:58	–1 +/–
>> помог :-D > вот такое вот у них понятие про «просто работает», что поделать… Т.е. проблемы с загрузкой возможны только на systemd?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #185

128. Сообщение от Красные Глаза (ok), 15-Сен-15, 09:05	–1 +/–
>> А systemd просто работает. > И я сейчас не говорю, что systemd -- говно. Просто сама фраза > "systemd просто работает" мне кажется очень неискренней. А мне кажется что проблема не в systemd, а в том, что вам просто лень его изучать. В данном случае без перехода на личности никак не получится, извините :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #129, #132

129. Сообщение от chinarulezzz (ok), 15-Сен-15, 09:20	+/–
прорвало, понимаем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #162

130. Сообщение от Красные Глаза (ok), 15-Сен-15, 09:26	–1 +/–
> помог :-D Но так уж и быть, я вам помогу, если вам лень самому читать документацию. 1. В grub нажимаете 'e' и редактируете параметры kernel, добавив в конце systemd.unit=rescue.target (если с rescue не загрузитесь, пишите emergency) 2. После того, как попадете в rescue, пишите mount -o remount,rw / 3. Набираете systemctl enable debug-shell 4. Перегружаетесь и имеете на 7 консоли шелл во время загрузки, в котором можно смотреть логи и совершать прочие действия от имени рута. (journalctl для просмотра логов вас спасет) 5. После того как почините, не забудьте сделать systemctl disable debug-shell
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #187

131. Сообщение от Fracta1L (ok), 15-Сен-15, 10:42	–1 +/–
> Просто сама фраза "systemd просто работает" мне кажется очень неискренней. Безглючного софта не бывает. Но это не значит, что у кого-то какой-то софт не может просто работать. У меня, например, systemd просто работает. Впрочем, и openrc у меня просто работал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #277

132. Сообщение от Антононим (?), 15-Сен-15, 11:00	+/–
А мне кажется, что и время тратить на изучение этого фи не надо. Хех, на всех серверах написано шесть инит-эрцэ скриптов и о ужас - работает! Главное всегда можно понять что и когда стартует или останавливается, без всяких долбаных юнитов, тормозящих загрузку системы в разы! Ну а если, что-то случилось и в грубе пришлось нажать клавишу 'e', то init=/bin/bash и ведь, тоже работает =))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #133

133. Сообщение от Красные Глаза (ok), 15-Сен-15, 12:24	–1 +/–
> А мне кажется, что и время тратить на изучение этого фи не > надо. Хех, на всех серверах написано шесть инит-эрцэ скриптов и о > ужас - работает! Главное всегда можно понять что и когда стартует > или останавливается, без всяких долбаных юнитов, тормозящих загрузку системы в разы! > Ну а если, что-то случилось и в грубе пришлось нажать клавишу > 'e', то init=/bin/bash и ведь, тоже работает =)) 1. На systemd тоже, ужас, все работает. Только в разы удобней этим управлять :) 2. К вопросу о понимании запуска - аналог systemctl list-dependencies на  systemv? 3. И что вам толку от голого баша, если до проблемного сервиса очередь не дошла и strace на него не запустить и вообще не покрасноглазить? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #137, #148

134. Сообщение от Аноним (-), 15-Сен-15, 13:30	–1 +/–
> Зачем, если он уже давным давно сделан? Действительно, нахрена нужны все эти линуксы и что там еще, если много лет как есть CP/M и Multics? Нафиг сдались самолеты и автомобили, если можно ездить на конской хребтине или даже ходить пешком?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #264

135. Сообщение от Аноним (-), 15-Сен-15, 13:35	+/–
> Если сервера github и следилки АНБ находятся в одних и тех же датацентрах, > например сервера АНБ стоят на всех каналах в инет из датацентра, А не проще тогда АНБ просто обосноваться на серверах гитхаба? :) Но ты знаешь, даже если анб порутает сервера гитхаба, при попытке что-то вбросить задним числом - програмеры очень быстро заметят что тут что-то идет не так. Дело в том что внеплановый отъезд иерархии хэшей - штука довольно паливная, что ни говори. > тогда хоть подключись к github со всех компьютеров мира, получишь то что захотел АНБ Эффективно работать это сможет только в 1 случае: когда АНБ станет основным разработчиком софта и убедит всех пользоваться своей репой, устранив всех кто мог бы аудитить их коммиты... (а потом подумаем кто же из овощей пускающих пузыри будет теперь писать код).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #181

136. Сообщение от Аноним (-), 15-Сен-15, 13:55	–1 +/–
> но системная шина, конечно, магически эти проблемы решает. Системная шина позволяет делать ряд вещей проще чем как-то иначе. В том числе по части обнаружения фич и обмена информацией между заинтересованными в том или ином событии, etc. > ведь не надо писать код для работы с сервисами, МАГИЯ! Если уж мы о птичках, у поцтера его sd-bus имхо наиболее вменяемая либа для работы c d-bus. Ну так, глядя на примеры кода и сравнивая с остальными. Ну и я говоря за себя могу понять зачем мне может быть полезен d-bus и куда его девать. С ним умеет работать туева хуча софта. А зачем мне какой-то сановский RPC из сабжа - вот тут мой фэйс становится столь же недоумевающим как и твой. Шина которой никто не пользуется - это таки оксюморон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #189

137. Сообщение от Xaionaro (ok), 15-Сен-15, 14:01	+2 +/–
>> А мне кажется, что и время тратить на изучение этого фи не >> надо. Хех, на всех серверах написано шесть инит-эрцэ скриптов и о >> ужас - работает! Главное всегда можно понять что и когда стартует >> или останавливается, без всяких долбаных юнитов, тормозящих загрузку системы в разы! >> Ну а если, что-то случилось и в грубе пришлось нажать клавишу >> 'e', то init=/bin/bash и ведь, тоже работает =)) > 1. На systemd тоже, ужас, все работает. # pgrep dbus | wc -l 6 # systemctl Failed to get D-Bus connection: Unknown error -1 И раньше сталкивался с этой же самой ошибкой, но вызванной разными причинами. И меня напрягает не сама ошибка, а то, как о ней сообщается. > Только в разы удобней этим управлять :) Вообще не ощутил. > 2. К вопросу о понимании запуска - аналог systemctl list-dependencies на   > systemv? Запустил на одной из машинок: # systemctl list-dependencies Failed to get D-Bus connection: Unknown error -1 Если глупо пошутить, то аналогом является: «echo 'Failed to get D-Bus connection: Unknown error -1' >&2; false». Но если серьёзно, то в openrc в качестве аналога есть deptree2dot (откуда можно сразу получить отображение графов в произвольном формате). А если имеется желание вручную посмотреть на файл с деревом зависимостей, то лежит он в /run/openrc/deptree. Если хотите, могу быстренько сваять вам утилиту, которая будет печатать древо зависимостей в том же формате, что и systemd. Как-то use case-ов не возникало, обычно простого rc-status и пр. хватало. > 3. И что вам толку от голого баша, если до проблемного сервиса > очередь не дошла и strace на него не запустить и вообще > не покрасноглазить? :) Не понял вопрос. Я вполне после init=/bin/bash с OpenRC дозапускал потихоньку систему. Кривота, но была совсем угробленная система и иначе было не запустить и не узнать причины различных неполадок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #142

138. Сообщение от Аноним (-), 15-Сен-15, 14:02	–3 +/–
> Для себя лично решил этот вопрос патчем гимпа. Да понятное дело что велосипед накрайняк можно и из водопроводных труб в гараже сварить. Но как-то получается что затрат сил много, а на выходе - ржавый, тяжеленный, стремноватый агрегат, который неважно ездит и поэтому интересен лишь своему создателю, в рамках прокачки mad skillz. А остальные недоуменно смотрят - "что это за у..ще?" Ну вот нормальная системная шина должна бы уже устаканиться, имхо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #147

139. Сообщение от Аноним (-), 15-Сен-15, 14:06	–2 +/–
> он не работает. Попробуй его запустить на системе из ядра которой выключен cgroups. А еще в ядре можно отключить sysfs и procfs. Удачи вам после этого вообще в системе поработать. Не забудьте рассказать сколько софта в осадок выпало. > Удачной перестановки системы. У нас снапшоты есть - 2015 год на дворе, дяденька :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #152

140. Сообщение от Аноним (-), 15-Сен-15, 14:11	+1 +/–
> systemd таки не ядро. Но тоже системный софт. Идите вон либцу потрогайте. Это ж не ядро. Но если вы налажаете в стандартных сишных библиотечных функциях - у вас система таки превратится в тыкву. А трогать сишный код системды именно админу - в общем случае довольно странно. Хотелка из разряда "потрогать ядро и либцу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

141. Сообщение от Аноним (-), 15-Сен-15, 14:12	–1 +/–
> Его не собираются пихать внутрь systemd, очевидно же. И правда, это фича а не баг. Не хватало мне какого-то сановского RPC в системде. При том что больше у меня в системе этим никто не пользуется, в отличие от d-bus...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

142. Сообщение от Красные Глаза (ok), 15-Сен-15, 14:14	–1 +/–
Первая ссылка в гугле - это про вас? :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763299
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #145, #192

143. Сообщение от Аноним (-), 15-Сен-15, 14:20	–1 +/–
> Львиная доля серьёзных архитектурных вкладов в systemd делается не сотрудниками RH? Хоть зелеными жителями красной планеты, если у них это получается лучше чем у других. Первым на этом направлении был, пожалуй, землянин Шатлворт. И его таки обставили, на собственном же поле. > И притом большинство из них не направлено на развязку компонентов? Потому что в результате получилось бы как обычно - адовое месиво, которое очень геморно поддерживать. Видели уже в sysv init.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #190

144. Сообщение от Аноним (-), 15-Сен-15, 14:21	+/–
> Через пол года сменит на Apache А через 5 лет загремит в курбюратор опача...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

145. Сообщение от Xaionaro (ok), 15-Сен-15, 14:22	+/–
> Первая ссылка в гугле - это про вас? :) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763299 Во-первых, вы абсолютно проигнорировали, что я вам написал. Меня напрягает не сама ошибка, а то, как о ней сообщается. Во-вторых, смотря когда. В контейнере у меня была ситуация, где systemd был pid1, но была та же самая ошибка. Но прямо сейчас я вызвал эту ошибку специально на машине, где он не pid1 (так как легко повторяется, а в контейнерах я ту ошибку поборол и уже давно). В-третих, даже если предположить, что эта ошибка всегда возникает только в ситуациях, когда systemd не pid1 (что не так), то: - Почему сообщается именно такая ошибка (повтор "во-первых")? - Как мне настроить всё systemd-related до переключения на него as pid1? В общем, читайте комментарии собеседников внимательнее, пожалуйста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #151

146. Сообщение от Аноним (-), 15-Сен-15, 14:26	+/–
>  а они просто историю не учили)) Сейчас казни не в моде. Просто дадут пожизненное и отправят доживать свой век в могильник апача.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

147. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 15:03	+1 +/–
Почему вы решили, что подход gimp правильный, а у остальных приложений нет? Мне лично не нравится идея универсальной системной шины именно потому, что за нее начинают завязываться в тех ситуациях, где без нее можно прекрасно обойтись. Естественно, я только за когда шина используется обоснованно (как jack в аудио).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #157, #180

148. Сообщение от Антононим (?), 15-Сен-15, 15:06	+2 +/–
1. Это про вкус и цвет. Насчёт удобней... вроде одна команда удобней, чем набор параметров к systemctl. 2. Это тоже замечательно, вопрос зачем нужен этот велосипед? 3. Вот тут тоже странно. Баш голым быть не может и strace очень даже работает, и разделы можно маунтить и апачики со сквидами стартовать, только это на этом этапе не нужно здесь, это для того что-бы файлсистем прочекать или ещё-чего починить..., например. А вот с системд банальный инит сети иногда вызывает убийственный фриз. Вот и понимаешь, что весь этот огород заменяется одной или двумя командами (например ifconfig ethX ... up или ip add add ...., это кому как нравится =))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #150, #156

149. Сообщение от Аноним (-), 15-Сен-15, 15:07	+/–
> Извозчиков в Москве тогда уже не было. ...однако песенка хорошо отражает суть явления.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

150. Сообщение от Антононим (?), 15-Сен-15, 15:11	+1 +/–
И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому нужны лишние сущности =))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #153, #164

151. Сообщение от Красные Глаза (ok), 15-Сен-15, 15:19	–1 +/–
1. Вопрос не ко мне. Насчет неинформативности ошибки я пожалуй соглашусь, можно было бы и поподробней. Хотя желание запустить systemd не так, как он должен быть запущен, вызывает интерес :) 2. Я так полагаю, вопрос к гуглу "migration to systemd"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #173

152. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 15:20	+1 +/–
>> он не работает. Попробуй его запустить на системе из ядра которой выключен cgroups. > А еще в ядре можно отключить sysfs и procfs. sysfs и procfs приносят пользу практически в любой системе. cgroups нужен далеко не всем. Зачем делать его обязательным? > Удачи вам после > этого вообще в системе поработать. Не забудьте рассказать сколько софта в > осадок выпало. Ну уж по крайней система инициализации работать будет ;) Да и практически весь софт тоже. Если задаться целью, то можно сделать систему работающую без sysfs, procfs. http://elinux.org/Kernel_Size_Tuning_Guide#Booting_without_S...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #159

153. Сообщение от Красные Глаза (ok), 15-Сен-15, 15:20	–2 +/–
> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому > нужны лишние сущности =)) Удачи. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #170

154. Сообщение от Аноним (-), 15-Сен-15, 15:21	–1 +/–
> Так  они, вроде ядро уже форкнули -- для kdbus. Правда "девелопят" > пока и ретрограды из в мейнлайн kernel.org не пускают. Какой-нибудь Andy Lutomirski из майнлайна - ни разу не ретроград. И выдвинул некие претензии, не везде убедительные, но куда как более адресные, чем позорные визги опеннетовских ретрогоадов. > Но вона клоун чуть выше вещает Алилуйя, вы нашли друг друга. Два шута - пара.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #167

155. Сообщение от Аноним (-), 15-Сен-15, 15:23	+/–
> А ну кажи профиль на гитхате, ыкспертный вы наш. А смысл? Ты вроде не мой кастомер и денег дать вроде не обещал. А растопыривать пальцы перед каким-то анонимом - так и вообще бессмысленно и беспощадно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

156. Сообщение от Красные Глаза (ok), 15-Сен-15, 15:31	–1 +/–
> 1. Это про вкус и цвет. Насчёт удобней... вроде одна команда удобней, > чем набор параметров к systemctl. Какая именно команда? Например systemctl start unicorn гораздо удобней "unicorn -c config/unicorn/production.rb -E production" :) Приведите свой пример? :) > 2. Это тоже замечательно, вопрос зачем нужен этот велосипед? Вы же завели речь о понятном запуске сервисов? Сможете так же легко и непринужденно одной командой  рассказать о своем sysv кто на ком стоял? :) > 3. Вот тут тоже странно. Баш голым быть не может и strace > очень даже работает, и разделы можно маунтить и апачики со сквидами > стартовать, только это на этом этапе не нужно здесь, это для > того что-бы файлсистем прочекать или ещё-чего починить..., например. Ну да, загружаем bash, собираем обратно рэйд, маунтим разделы пишем много ручками, запускаем сервисы в том порядке, чтобы понять, что может привести к ошибке. Не вопрос, можно и так :) В systemd только это делается одной командой :) > А вот с системд банальный инит сети иногда вызывает убийственный фриз. Вот > и понимаешь, что весь этот огород заменяется одной или двумя командами > (например ifconfig ethX ... up или ip add add ...., это > кому как нравится =)) Я все-таки задам это вопрос - вы это про локалхост или про парк серверов? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #160, #211

157. Сообщение от Аноним (-), 15-Сен-15, 15:33	+/–
> Почему вы решили, что подход gimp правильный, а у остальных приложений нет? Вот конкретно в случае gimp - это как раз совсем не факт. И может быть просто особенностью внутреннего устройства, или чем там еще. Однако для множества иных юзкейсов шины работают лучше чем все остальное. > Мне лично не нравится идея универсальной системной шины именно потому, что за > нее начинают завязываться в тех ситуациях, где без нее можно прекрасно обойтись. Ну, знаете, без procfs и sysfs тоже (теореьтически) можно обойтись. А вот всякие тут порасплодились и пользуются ими в хвост и в гриву. И вообще пожалуй работать без них не будут. Это что, теперь procfs и sysfs тоже должны не нравиться? По той же логике, 1 в 1. Ах, вы ими пользуетесь и они делают жизнь проще? Ну так я могу это и про системную шину столь же симметрично сказать - ей тоже софт пользуется и в ряде случаев это удобнее всего и наименее криво. > Естественно, я только за когда шина используется обоснованно (как jack в аудио). Хороший пример сферической вундервафли в вакууме, которой из-за ультраопцоинальности пользуется лишь узкий сегмент профессионального софта. А остальные ... ну им было лень фачить мозг проблемами алсyчки и они хотят пульс. Вот так и получается что пульс вроде бы и не лучший во всем, но good enough и можно рассчитывать на его наличие. И, главное, не фачить себе мозг многочисленными проблемами алсyчки, костылированием опциональных вещей и странных конфигураций, etc. В пульсе это не проблемы програмера выводящего звук. Чем он и хорош.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #174, #196, #228

158. Сообщение от Аноним (-), 15-Сен-15, 15:38	–1 +/–
И вообще, в случае системд более или менее понятно откуда взялась "вон та хрень". А скрипткиди посчитали это неподъемной инженерной проблемой и ... забили. Предложив желающим костылировать pid файлы. С которыми два газилиона проблем. Например, файл может быть тухлым, проверка тухлости и фактического наличия сервиса - весьма отдельное действо. Сабж, кстати, никак не адресует эту проблему, насколько я понимаю. Там точно так же нет трекинга чего и откуда взялось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106

159. Сообщение от Аноним (-), 15-Сен-15, 15:49	–1 +/–
> sysfs и procfs приносят пользу практически в любой системе. cgroups нужен далеко не всем. А теперь он будет такой же очевидной фичой, как эта парочка. И лично мне кажется что возможность для админа понять откуда этот чертов сервис вообще взялся в этой системе - должно быть повсеместной и дефолтной фичой операционки, а не стремным полурабочим костылем на проволоке и скотче, как всякие pid-файлы и прочий глюкавый и проблемный крап. > Зачем делать его обязательным? Потому что гладио^W в смысле, см. выше :). Да, я считаю что это должно быть неотъемлимым свойством большинства систем. Ну кроме совсем уж обкоцаных по ресурсам типа опенврт, где желательно то же самое но маленькое и с утилитками чуть попроще. Они вроде что-то такое и делают с своими procd и ubus-ами... > Ну уж по крайней система инициализации работать будет ;) У меня системд - работает. И берет на себя кучу проблем администрирования, вместо лечилова о том что мне должно быть надо и не надо. Это ему дает пять очков форы вперед. Что мне надо - я и без умников с опеннета как-нибудь разберусь, имхо. > Если задаться целью, то можно сделать систему работающую без sysfs, procfs. Ну вот то же самое теперь можно будет сказать и про cgroups. В ядре линукса можно обрубить очень многое. И на мое нескромное мнение, обрубание cgroups на данный момент уже близко к обрубанию procfs. > http://elinux.org/Kernel_Size_Tuning_Guide#Booting_without_S... Как вы можете догадаться - я в курсе этого ресурса. И в курсе что такой хардкор нужен сильно эпизодически. И что там насчет отрывания proc? Если задаться целью - без него тоже можно, как минимум теоретически :). И вообше, в ядре линукса можно отключить много чего. Можно модули отключить. Зачем они вам? Даешь эталонный монолит! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #175, #200

160. Сообщение от Антононим (?), 15-Сен-15, 15:51	+1 +/–
1. Если про запуск чего-либо, то прямая команда гораздо удобней, например /bin/mount .... /usr/sbin/dhcpd и т.п. 2. Гм, смогу... наверное логика, что если рейд не собран и разделы не подцеплены то и запускать нечего =)) 3. Если система крякнула и не происходит загрузки, то чинить, если надо понять где валится, то и рэйд ручками одной командой собирается (если софтовый естессьно ;) 4. Нет, это на всех серверах, я-ж говорю у меня даже дбаса нет, и иксов.... и инитрд. Просто не понятно зачем это там? Вот на локалхосте этого навалом и системд, который обещал мне пять сек загрузки... хе  =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #163, #165

161. Сообщение от Аноним (-), 15-Сен-15, 15:52	–1 +/–
> вот такое вот у них понятие про «просто работает», что поделать… Ну мне любители sysv init и так не помогали. В том плане что как отлаживать скрипт именно в boot time - эксперты опеннета вообще ни разу не показали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #168, #186

162. Сообщение от Аноним (-), 15-Сен-15, 15:55	+/–
> прорвало, понимаем. Ну еще бы, если питекантроп перфоратор использует для нарезки хлеба - мы ему говорим что он хочет странного и что есть способ лучше. А дикарь обижается - мол, вы что, прикалываетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #179

163. Сообщение от Красные Глаза (ok), 15-Сен-15, 15:56	–1 +/–
> 1. Если про запуск чего-либо, то прямая команда гораздо удобней, например /bin/mount > .... /usr/sbin/dhcpd и т.п. Жесть :) > 2. Гм, смогу... наверное логика, что если рейд не собран и разделы > не подцеплены то и запускать нечего =)) > 3. Если система крякнула и не происходит загрузки, то чинить, если надо > понять где валится, то и рэйд ручками одной командой собирается (если > софтовый естессьно ;) > 4. Нет, это на всех серверах, я-ж говорю у меня даже дбаса > нет, и иксов.... и инитрд. Просто не понятно зачем это там? > Вот на локалхосте этого навалом и системд, который обещал мне пять > сек загрузки... хе  =) Cочувствую админу, который придет после вас и ему надо будет это поддерживать :) Я вас поддерживаю, вам не нужен systemd :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

164. Сообщение от Аноним (-), 15-Сен-15, 15:56	–2 +/–
> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому нужны лишние сущности =)) А procfs ты не отпилил? Это FAIL, я считаю. Без procfs вполне можно обойтись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #171, #177

165. Сообщение от Аноним (-), 15-Сен-15, 16:01	–1 +/–
> 1. Если про запуск чего-либо, то прямая команда гораздо удобней, например /bin/mount > .... /usr/sbin/dhcpd и т.п. Давайте так систему загружать. Набивая все команды самолично. Хотя у меня есть идея лучше, см. ниже. > 2. Гм, смогу... наверное логика, что если рейд не собран и разделы > не подцеплены то и запускать нечего =)) Вот это - бабушка надвое сказала. Очень зависит от конфигурации (а как насчет recovery тулсей в каком-нибудь initrd например?). > 3. Если система крякнула и не происходит загрузки, то чинить, если надо > понять где валится, то и рэйд ручками одной командой собирается (если > софтовый естессьно ;) Давайте уж загрузчик после включения тумблерами на шине набивать. Шелл - это для мягкотелых нубов и прочих скрипткидисов. Вот наколотить самому бутлоадер в оперативку, побайтово - это труЪ. > 4. Нет, это на всех серверах, я-ж говорю у меня даже дбаса > нет, и иксов.... и инитрд. Просто не понятно зачем это там? Предлагаю procfs еще отрубить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #172

166. Сообщение от Аноним (-), 15-Сен-15, 16:08	–2 +/–
> P.S. Хватит уже переходить на личности, учитесь разговаривать как взрослые люди (конструктивно): А конструктивно - ваш OpenRC не решает множество задач, успешно решаемых системд. Cgroups системд использует не для красоты, а для отслеживания кто и откуда взялся, независимо от того какие они там форки-перефорки откаблучивали. Что в этом плане имеет предложить OpenRC, если уж мы о конструктиве? Или почему у меня как у админстратора не должно быть overview системы на предмет того кто и откуда там вообще вылупился? //это другой аноним, если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #169, #195

167. Сообщение от Andrey Mitrofanov (?), 15-Сен-15, 16:11	+2 +/–
>> Так  они, вроде ядро уже форкнули -- для kdbus. Правда "девелопят" >> пока и ретрограды из в мейнлайн kernel.org не пускают. > Какой-нибудь Andy Lutomirski из майнлайна - ни разу не ретроград. И выдвинул > некие претензии, не везде убедительные, но куда как более адресные, чем > позорные визги опеннетовских ретрогоадов. Надо подтянуть эрудицию -- перечитать визги коллег про kdbus, а то прям стыдно. >> Но вона клоун чуть выше вещает > Алилуйя, вы нашли друг друга. Два шута - пара. Уже плАчу, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #259

168. Сообщение от Andrey Mitrofanov (?), 15-Сен-15, 16:21	+1 +/–
>> вот такое вот у них понятие про «просто работает», что поделать… > Ну мне любители sysv init и так не помогали. В том плане > что как отлаживать скрипт именно в boot time - эксперты опеннета > вообще ни разу не показали. Гражданка Никонорова, Вас ожидают, пройдите с Вашим фетишем и хоть оботлаживайтесь его "бут-тайм":      16:58 , 14-Сен-15, (72)         > Systemd хорошо документирован, так что все проблемы, не от systemd, а от      Докажи! . http:/openforum/vsluhforumID1/96286.html   Время пошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #191

169. Сообщение от Xaionaro (ok), 15-Сен-15, 16:46	+1 +/–
>> P.S. Хватит уже переходить на личности, учитесь разговаривать как взрослые люди (конструктивно): > А конструктивно - ваш OpenRC не решает множество задач, успешно решаемых системд. > Cgroups системд использует не для красоты, а для отслеживания кто и > откуда взялся, независимо от того какие они там форки-перефорки откаблучивали. И? qnikst (один из русских разработчиков OpenRC), ЕМНИП, уже давно реализовал поддержку cgroups для отслеживания процессов в OpenRC. Я помню как мы с ним это обуждали года два назад (когда впервые от сообщества OpenRC это попросили) на #openrc. Но в отличие от systemd это опционально. Лично я этим никогда не пользовался, так как у меня в корпоративном секторе все сервисы запихнуты в контейнеры. Хочу что-то опустить — опускаю контейнер. А в HPC секторе тупо таких проблем не возникает. Однако я могу понять нужду использования cgroups для отслеживания процессов, и я бы для этого использовал то, что умеет OpenRC. Я когда-то прикола ради делал аналогичный мониторинг на базе ptrace(), но скорее для proof of concept. Могу и это легко прикрутить к OpenRC, если хотите. Просто OpenRC сделан так, что он легко расширяется чем угодно. И, естественно, мы сейчас говорим про тот мелкий процент случаев, когда либо не хватает обычного pstree, либо хочется перезапускать приложения при падении… > Что в этом плане имеет предложить OpenRC, если уж мы о конструктиве? Что конкретно нужно? P.S.: Чтобы не вводить в заблуждение, на всякий случай проясню: я не являюсь разработчиком OpenRC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #282

170. Сообщение от Xaionaro (ok), 15-Сен-15, 16:49	+2 +/–
>> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому >> нужны лишние сущности =)) > Удачи. :) Нахрена нужен dbus на сервере? Это крайне редко требуется (и только на тех серверах и нужно ставить).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #176

171. Сообщение от Xaionaro (ok), 15-Сен-15, 16:53	+2 +/–
>> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому нужны лишние сущности =)) > А procfs ты не отпилил? Это FAIL, я считаю. Без procfs вполне > можно обойтись. procfs на сервере нужен лишь например для "ps" или чистки xt_recent. А dbus?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #280

172. Сообщение от Антонимум (?), 15-Сен-15, 17:00	+/–
А системд внутри при запуске не команды содержит? Рекавери можно и в отдельном раздельчике, если надо конечно )) Не, есть старый добрый груб, но можно и тумблерами....:)) бывало и такое. Правда на других системах. В некоторых чрутных конфигах /proc и не маунтится :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

173. Сообщение от Xaionaro (ok), 15-Сен-15, 17:01	+/–
> 1. Вопрос не ко мне. Насчет неинформативности ошибки я пожалуй соглашусь, можно > было бы и поподробней. Хотя желание запустить systemd не так, как > он должен быть запущен, вызывает интерес :) Желание systemd ограничивать меня в штатных для меня раньше задачах — вот что вызывает интерес. А что ещё хуже, писать какие-то странные пакости в ответ. > 2. Я так полагаю, вопрос к гуглу "migration to systemd"? То есть с вами лично мне нет смысла общаться, я правильно понимаю? Не хочу сказать ничего плохого, просто хочется разобраться есть ли смысл тратить время. И нахрена гуглить "migration to systemd", если там всё равно будут использовать systemctl _после_ переключения на systemd. Это архитектурная особенность systemd, а не проблема кривых рук пользователей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

174. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 17:11	+/–
>> Мне лично не нравится идея универсальной системной шины именно потому, что за >> нее начинают завязываться в тех ситуациях, где без нее можно прекрасно обойтись. > Ну, знаете, без procfs и sysfs тоже (теореьтически) можно обойтись. А вот > всякие тут порасплодились и пользуются ими в хвост и в гриву. > И вообще пожалуй работать без них не будут. Это что, теперь > procfs и sysfs тоже должны не нравиться? По той же логике, > 1 в 1. Что бы действительно соответствовало моей логике, перечислите приложение которые необоснованно завязываются за procfs/sysfs. > Ах, вы ими пользуетесь и они делают жизнь проще? Ну так я > могу это и про системную шину столь же симметрично сказать - > ей тоже софт пользуется и в ряде случаев это удобнее всего > и наименее криво. Я и не спорю, что в определенных случаях системная шина может быть реально полезно, но пока мне попадались не очень удачные примеры ее использования. >> Естественно, я только за когда шина используется обоснованно (как jack в аудио). > Хороший пример сферической вундервафли в вакууме, которой из-за ультраопцоинальности > пользуется лишь узкий сегмент профессионального софта. Ну да, она нужна только тем, кто профессионально работает со звуком, кому нужна минимальная задержка и максимальная гибкость, естественно все это не бесплатно - ест и память и проц. Если его вместо "ультраопцоинальности" сделают по-умолчанию, то будут плеваться все, в том числе и я. > А остальные ... ну им > было лень фачить мозг проблемами алсyчки и они хотят пульс. Вот > так и получается что пульс вроде бы и не лучший во > всем, но good enough и можно рассчитывать на его наличие. И, > главное, не фачить себе мозг многочисленными проблемами алсyчки, костылированием опциональных > вещей и странных конфигураций, etc. В пульсе это не проблемы програмера > выводящего звук. Чем он и хорош. Напрямую alsa/jack/pa используют те, кто умеет работать со звуком и его задачи отличны, от просто проиграть файл. Те кому действительно нужно просто возьмут высокоуровневую библиотеку/плеер, так как по мимо непосредственно вывода звука еще нужно уметь разбирать формат аудио файла и корректно делать промежуточные преобразования. Для остальных же alsa api позволяет делать куда больше чем pa, в том числе и bit perfect.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #265

175. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 17:23	+/–
>> sysfs и procfs приносят пользу практически в любой системе. cgroups нужен далеко не всем. > А теперь он будет такой же очевидной фичой, как эта парочка. И > лично мне кажется что возможность для админа понять откуда этот чертов > сервис вообще взялся в этой системе - должно быть повсеместной и > дефолтной фичой операционки, а не стремным полурабочим костылем на проволоке и > скотче, как всякие pid-файлы и прочий глюкавый и проблемный крап. То есть в _вашей_ системе вы не знаете откуда взялся тот или иной сервис? >> Ну уж по крайней система инициализации работать будет ;) > У меня системд - работает. Без procfs и sysfs? > Ну вот то же самое теперь можно будет сказать и про cgroups. > В ядре линукса можно обрубить очень многое. И на мое нескромное > мнение, обрубание cgroups на данный момент уже близко к обрубанию procfs. Совсем не близко. У меня все работает без cgroups. Зачем на десктопе cgroups? > Можно модули отключить. Зачем они вам? Даешь эталонный монолит! :) Ну вообще-то я действительно предпочитаю монолитные ядра (без initrd) собранные под конкретную систему, хотя поддержку модулей держу - на случай если понадобится catalyst (для opencl).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #182, #201, #202

176. Сообщение от Красные Глаза (ok), 15-Сен-15, 17:23	–1 +/–
>>> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому >>> нужны лишние сущности =)) >> Удачи. :) > Нахрена нужен dbus на сервере? Это крайне редко требуется (и только на > тех серверах и нужно ставить). dbus нужен для systemd. Кстати, dbus так же нужен, о ужас, для firewalld. :) Предлагаю выкинуть dbus, разворотив тем самым пол-дистрибутива, убив кучу времени на отладку и поиск возникших проблем и продолжая отлавливать глюки. Главное, ведь, не работа сервера, а ковыряние в нем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #178, #194

177. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 17:25	+/–
>> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому нужны лишние сущности =)) > А procfs ты не отпилил? Это FAIL, я считаю. Без procfs вполне > можно обойтись. А ты kde на сервер поставил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #283

178. Сообщение от Xaionaro (ok), 15-Сен-15, 18:05	+1 +/–
>>>> И да кстати, D-BUS-а у меня на серверах вообще нет, т.к. кому >>>> нужны лишние сущности =)) >>> Удачи. :) >> Нахрена нужен dbus на сервере? Это крайне редко требуется (и только на >> тех серверах и нужно ставить). > dbus нужен для systemd. Разве что. Про то и речь, между прочим. > Кстати, dbus так же нужен, о ужас, для firewalld. :) Весь мир уже сидит на RHEL/Fedora? У меня вот в Debian/Gentoo как-то никакими firewalld не пахнет. RH-то и так уже славится идеей lock in-ов всего на всё. Оба примера неудачны и как раз доказывают одну мыслей, которую я пытаюсь донести. Это два самых сильных примера что вы смогли привести? > Предлагаю выкинуть dbus, разворотив тем самым пол-дистрибутива, убив кучу времени на отладку > и поиск возникших проблем и продолжая отлавливать глюки. Главное, ведь, не > работа сервера, а ковыряние в нем. Заходим в контейнер, где я забыл удалить dbus и смотрим: # apt-get remove dbus Reading package lists... Done Building dependency tree       Reading state information... Done The following packages will be REMOVED:   dbus 0 upgraded, 0 newly installed, 1 to remove and 108 not upgraded. After this operation, 1,027 kB disk space will be freed. Do you want to continue? [Y/n] y (Reading database ... 28095 files and directories currently installed.) Removing dbus (1.8.12-1) ... Это было очень сложно… Всё продолжает работать, если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #184

179. Сообщение от chinarulezzz (ok), 15-Сен-15, 18:06	+/–
>> прорвало, понимаем. > Ну еще бы, если питекантроп перфоратор использует для нарезки хлеба - мы > ему говорим что он хочет странного и что есть способ лучше. > А дикарь обижается - мол, вы что, прикалываетесь? Помнится, дикарь даже эссе писал, дескать не обижайте музыканта, играет как умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

180. Сообщение от GotF (ok), 15-Сен-15, 18:59	–1 +/–
> Мне лично не нравится идея универсальной системной шины именно потому, что за > нее начинают завязываться в тех ситуациях, где без нее можно прекрасно > обойтись. Естественно, я только за когда шина используется обоснованно (как jack > в аудио). Вариант «разработчику это удобно» принципиально не рассматривается? Для пользователей dbus-интерфейс тоже может представлять интерес.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #197, #212

181. Сообщение от vi (ok), 15-Сен-15, 19:10	+/–
>> тогда хоть подключись к github со всех компьютеров мира, получишь то что захотел АНБ > Эффективно работать это сможет только в 1 случае: когда АНБ станет основным > разработчиком софта и убедит всех пользоваться своей репой, устранив всех кто > мог бы аудитить их коммиты... (а потом подумаем кто же из > овощей пускающих пузыри будет теперь писать код). Каким образом "устранив"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #257

182. Сообщение от GotF (ok), 15-Сен-15, 19:13	–2 +/–
> То есть в _вашей_ системе вы не знаете откуда взялся тот или иной сервис? Ну, в «скриптовой» системе инициализации на вопрос «откуда» ответить можно далеко не всегда, а достоверно ответить — довольно нечасто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #203

183. Сообщение от GotF (ok), 15-Сен-15, 19:17	–1 +/–
> Я так понял, что картинку в новости никто не посмотрел. Я смотрел. Чуть не разбил лицо лицо фэйспалмом, но до бложика дотащил!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

184. Сообщение от Красные Глаза (ok), 15-Сен-15, 19:18	–1 +/–
Давайте пойдем от обратного - почему вы против dbus на сервере?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #204, #209, #225

185. Сообщение от arisu (ok), 15-Сен-15, 19:34	+1 +/–
> Т.е. проблемы с загрузкой возможны только на systemd? ты сказал «просто работает»? сказал. никто силой это говорить не заставлял. а оно на самом деле просто не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #188

186. Сообщение от arisu (ok), 15-Сен-15, 19:35	+1 +/–
> что как отлаживать скрипт именно в boot time - эксперты опеннета > вообще ни разу не показали. потому что зачем это делать? я тоже в ответ на такой вопрос плечами пожму: не в себе человек, просит непонятно чего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

187. Сообщение от arisu (ok), 15-Сен-15, 19:36	+1 +/–
какой‐такой «дебуг шелл»? какой «в грубе нажимаете»? неа, это не «просто работает», это «немеряное количество телодвижений». «просто работает» выглядит совсем иначе. как обычно, любитель системд соврамши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #193

188. Сообщение от Красные Глаза (ok), 15-Сен-15, 19:37	–2 +/–
>> Т.е. проблемы с загрузкой возможны только на systemd? > ты сказал «просто работает»? сказал. никто силой это говорить не заставлял. а > оно на самом деле просто не работает. Тебе просто что-то сказать хочется? :) Ну скажи еще что-нибудь, не сдерживай себя :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #206

189. Сообщение от arisu (ok), 15-Сен-15, 19:40	+2 +/–
>> но системная шина, конечно, магически эти проблемы решает. > Системная шина позволяет делать ряд вещей проще чем как-то иначе. В том > числе по части обнаружения фич и обмена информацией между заинтересованными в > том или ином событии, etc. ещё раз уточню: системная шина магически добавляет код для проверки capabilities? если нет, то каким образом люди, заведомо клавшие болт на такие проверки, вдруг станут это делать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #262

190. Сообщение от arisu (ok), 15-Сен-15, 19:42	+1 +/–
> Видели уже в sysv init. не видел. отлично поддерживаю, никаких проблем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

191. Сообщение от Красные Глаза (ok), 15-Сен-15, 19:44	–1 +/–
>>> вот такое вот у них понятие про «просто работает», что поделать… >> Ну мне любители sysv init и так не помогали. В том плане >> что как отлаживать скрипт именно в boot time - эксперты опеннета >> вообще ни разу не показали. > Гражданка Никонорова, Вас ожидают, пройдите с Вашим фетишем и хоть оботлаживайтесь его > "бут-тайм": >      16:58 , 14-Сен-15, (72) >      > Systemd хорошо документирован, так что все проблемы, не от systemd, а от >      Докажи! . http:/openforum/vsluhforumID1/96286.html   Время пошло. Андрюша, по этой ссылке случай для доктора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #261

192. Сообщение от arisu (ok), 15-Сен-15, 19:46	+1 +/–
> Первая ссылка в гугле - это про вас? :) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763299 You are using sysvinit as PID 1 as shown by the status message of the dbus service. So the error message you get from systemctl is not suprising. отличная иллюстрация. с «просто работает» — облажатушки, с нормальными сообщениями об ошибках — облажатушки. просто девиз такой у системд: «мы всё облажатушки!»
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #199

193. Сообщение от Красные Глаза (ok), 15-Сен-15, 19:47	–1 +/–
> какой‐такой «дебуг шелл»? какой «в грубе нажимаете»? неа, > это не «просто работает», это «немеряное количество телодвижений». > «просто работает» выглядит совсем иначе. > как обычно, любитель системд соврамши. Але, Москва :)) Этот текст лишь показывает преимущество systemd в случае возникновения проблем :) В sysv ты бы в этом случае сидел и плакал :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #210

194. Сообщение от arisu (ok), 15-Сен-15, 19:49	+2 +/–
> dbus нужен для systemd. хорошо, что сервера отлично работают без этого говна. > Кстати, dbus так же нужен, о ужас, для firewalld. :) хорошо, что сервера отлично работают без этого говна. > Предлагаю выкинуть dbus, разворотив тем самым пол-дистрибутива хорошо, что не все дистрибутивы сделаны больными на череп идиотами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #279

195. Сообщение от arisu (ok), 15-Сен-15, 19:51	+2 +/–
> Cgroups системд использует не для красоты, а для отслеживания кто и > откуда взялся, независимо от того какие они там форки-перефорки откаблучивали. что отлично делается без cgroups, но лёне об этом никто не сказал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #271, #281

196. Сообщение от arisu (ok), 15-Сен-15, 19:53	+2 +/–
> А остальные ... ну им > было лень фачить мозг проблемами алсyчки и они хотят пульс. спасибо, посмеялся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

197. Сообщение от arisu (ok), 15-Сен-15, 19:55	+1 +/–
> Вариант «разработчику это удобно» принципиально не рассматривается? нет. как только разработчик перестаёт пилить это в подвале лично для себя — так сразу и не рассматривается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #268

198. Сообщение от robux (ok), 15-Сен-15, 19:59	–1 +/–
> В критике нет ничего плохого. В критике нет ничего плохого только в том случае, если после этой критики следуют конструктивные предложения. Если же человек ограничивается критикой, то он напоминает карапуза, который обкакался и зовёт мамку решать проблему. При этом сам не собирается ничего делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #291

199. Сообщение от Красные Глаза (ok), 15-Сен-15, 19:59	–1 +/–
>> Первая ссылка в гугле - это про вас? :) >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763299 > You are using sysvinit as PID 1 as shown by the status > message of the > dbus service. So the error message you get from systemctl is not > suprising. > отличная иллюстрация. с «просто работает» — облажатушки, с нормальными > сообщениями об ошибках — облажатушки. просто девиз такой у системд: «мы > всё облажатушки!» Ты дурачок что-ли? :) Запусти два процесса с одним PID 1 где угодно и расскажи что будет? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #214

200. Сообщение от arisu (ok), 15-Сен-15, 20:00	+2 +/–
> А теперь он будет такой же очевидной фичой, как эта парочка. И > лично мне кажется что возможность для админа понять откуда этот чертов > сервис вообще взялся в этой системе - должно быть повсеместной и > дефолтной фичой операционки, а не стремным полурабочим костылем на проволоке и > скотче, как всякие pid-файлы и прочий глюкавый и проблемный крап. я тебе уже неоднократно говорил, что ты не умеешь пользоваться системой. это твоё право, и если тебе лично системдец жизнь облегчает — на здоровье. только не пытайся доказывать, что системдец «вообще» жизнь облегчает. отслеживание взаимоотношений отлично делалось и без cgroups, сервисы и прочее тоже. лично ты делал всё не так, и тебя спас системдец? ну, великолепно, используй. но вот те, у кого давно всё работает, и без проблем, совершенно не в восторге от системдецизации. сабж, кстати, не нужен точно так же, как и системдец. но в отличие от системдеца, сабж просто пилят себе в уголке, не пытаясь вколотить в каждый дистрибутив — поэтому пусть живёт. а системдецу — смерть. за наглое насильное втюхивание полурабочей поделки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159

201. Сообщение от arisu (ok), 15-Сен-15, 20:01	+2 +/–
> То есть в _вашей_ системе вы не знаете откуда взялся тот или > иной сервис? у него «лапша из скриптов» вместо нормального страртапа, поэтому не знает. он уже неоднократно на это жаловался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

202. Сообщение от arisu (ok), 15-Сен-15, 20:03	+/–
> Ну вообще-то я действительно предпочитаю монолитные ядра (без initrd) собранные под конкретную > систему, хотя поддержку модулей держу всегда так делаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

203. Сообщение от arisu (ok), 15-Сен-15, 20:03	+1 +/–
> Ну, в «скриптовой» системе инициализации на вопрос «откуда» ответить > можно далеко не всегда, а достоверно ответить — довольно нечасто. попробуй man bash. изучи основы. тогда ты сможешь посмотреть в скрипт и понять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #208

204. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 20:03	+/–
> Давайте пойдем от обратного - почему вы против dbus на сервере? Больше потенциальных точек отказа. Более сложное/менее прогнозируемое поведение. Больше вероятность получить уязвимость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #213

206. Сообщение от arisu (ok), 15-Сен-15, 20:06	+1 +/–
> Тебе просто что-то сказать хочется? :) ну так тебе‐то больше сказать нечего, с «просто работает» не получилось, тебя сразу носом тыкнули в «не работает». и тут «просто работает» превратилось в чёрти‐что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #245

208. Сообщение от GotF (ok), 15-Сен-15, 20:08	–1 +/–
>> Ну, в «скриптовой» системе инициализации на вопрос «откуда» ответить >> можно далеко не всегда, а достоверно ответить — довольно нечасто. > попробуй man bash. изучи основы. тогда ты сможешь посмотреть в скрипт и > понять. Это такой несмешной троллинг? Из диалектов шелла я разве что csh-подобные не очень знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #215

209. Сообщение от Аноним (-), 15-Сен-15, 20:09	+1 +/–
А давайте пойдем по правильному пути. Не будем умножать сучности без необходимости. Так зачем там серверу дбас?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #217

210. Сообщение от arisu (ok), 15-Сен-15, 20:12	+2 +/–
> Але, Москва :)) Этот текст лишь показывает преимущество systemd в случае возникновения > проблем :) которых априори быть не может, потому что ты утверждаешь, что системд «просто работает». > В sysv ты бы в этом случае сидел и плакал :) представляешь — не сидел и не плакал. вот недавно буквально — одно не грузилось, а у второго рут не перемонтировался в r/o. я понимаю, что для системдешников это конец света и молитвы (в лучшем случае — тасование таргетов с надеждой, что как‐нибудь заработает): они же шелл‐скриптов боятся как огня, и работать с ними не умеют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193

211. Сообщение от Аноним (-), 15-Сен-15, 20:12	+/–
> Я все-таки задам это вопрос - вы это про локалхост или про парк серверов? :) Весь этот ваш парк серверов и прочая системд магия вырождается в: напилили виртуалок-докеров-прочегощита в них стартует один сервис. Кому вы нужны с такими знаниями? Ещё чуть-чуть и тупоадминов системд заменит одна графическая приблуда. С нетерпением жду момента когда ситсемд фанбои окажутся на улице с своими тайными знаниями системд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #220

212. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 20:12	+/–
> Вариант «разработчику это удобно» принципиально не рассматривается? «разработчику это удобно» - недостаточное обоснование, достаточное - один из лучших вариантов для решения _конкретной_ проблемы. А то так можно договорится до того, что разработчикам неудобно ядро на c+asm писать, давайте на java/python/etc переходить. > Для пользователей dbus-интерфейс тоже может представлять интерес. Возможно, но хотелось увидеть реальные примеры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #223, #270

213. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:13	–1 +/–
>> Давайте пойдем от обратного - почему вы против dbus на сервере? > Больше потенциальных точек отказа. > Более сложное/менее прогнозируемое поведение. > Больше вероятность получить уязвимость. Это все слова.   1. Например? 2. Поведение кого/чего? 3. 25 CVE и всего два с severity High. За 10 лет. https://web.nvd.nist.gov/view/vuln/search-results?query=dbus...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #233

214. Сообщение от arisu (ok), 15-Сен-15, 20:13	+1 +/–
спасибо, великолепная иллюстрация того, почему системдешники неадекватны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

215. Сообщение от arisu (ok), 15-Сен-15, 20:15	+1 +/–
а только что признался, что не знаешь. ты уж выбери что‐то одно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #218

217. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:16	–1 +/–
> А давайте пойдем по правильному пути. Не будем умножать сучности без необходимости. > Так зачем там серверу дбас? У меня большие сомнения что ваш путь правильный :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #221

218. Сообщение от GotF (ok), 15-Сен-15, 20:16	–1 +/–
> а только что признался, что не знаешь. ты уж выбери что‐то одно. Ясно с вами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #222

220. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:20	–1 +/–
>> Я все-таки задам это вопрос - вы это про локалхост или про парк серверов? :) > Весь этот ваш парк серверов и прочая системд магия вырождается в: напилили > виртуалок-докеров-прочегощита в них стартует один сервис. Кому вы нужны с такими > знаниями? Ещё чуть-чуть и тупоадминов системд заменит одна графическая приблуда. С > нетерпением жду момента когда ситсемд фанбои окажутся на улице с своими > тайными знаниями системд. Есть мнение, что одна графическая приблуда заменит тех, кто не умеет ей управлять :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211 Ответы: #226

221. Сообщение от Аноним (-), 15-Сен-15, 20:21	+3 +/–
О. То есть мы сейчас услышим что надо умножать сущности? А маленький чайничик, у любителей системд, в космосе не летает?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217 Ответы: #224

222. Сообщение от arisu (ok), 15-Сен-15, 20:21	+1 +/–
это здорово, но bash всё‐таки выучи. пригодится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218

223. Сообщение от GotF (ok), 15-Сен-15, 20:22	–1 +/–
>> Вариант «разработчику это удобно» принципиально не рассматривается? > «разработчику это удобно» - недостаточное обоснование, достаточное - один из > лучших вариантов для решения _конкретной_ проблемы. Ну не лучшее, да. С другой стороны, всё равно это второстепенная функциональность, так что идейные противники dbus могут спокойно прожить без неё. >> Для пользователей dbus-интерфейс тоже может представлять интерес. > Возможно, но хотелось увидеть реальные примеры. Например, я когда-то активно использовал dbus-интерфейс Gajim. В этом году заглядывал в AccountsService ещё, но это немного более другой случай, потому что иных интерфейсов там нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

224. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:22	–1 +/–
> О. То есть мы сейчас услышим что надо умножать сущности? А маленький > чайничик, у любителей системд, в космосе не летает? Я бы хотел услышать конкретику, а не размышления о чайничках :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #227

225. Сообщение от Xaionaro (ok), 15-Сен-15, 20:23	+2 +/–
> Давайте пойдем от обратного - почему вы против dbus на сервере? Вероятно по той же причине, почему я против Xorg на серверах. Просто в меньшей степени. А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс — это неприятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #229

226. Сообщение от Аноним (-), 15-Сен-15, 20:24	+/–
Ну уж нет мой юный системд друг. Это будет для клиентов выглядеть как простой сервис по предоставлению виртуалки в облачке. Зачем нужен будешь ты с своим тайным знанием системд, если тебя любая секретарша заменит? Она пару кнопок нажать сможет глядя в инструкцию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220 Ответы: #232

227. Сообщение от Аноним (-), 15-Сен-15, 20:26	+/–
Конкретика в википедии по словам бритва Оккама.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

228. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 20:27	+/–
> Ну, знаете, без procfs и sysfs тоже (теореьтически) можно обойтись. А вот > всякие тут порасплодились и пользуются ими в хвост и в гриву. > И вообще пожалуй работать без них не будут. Для интереса попробовал отключить монтирование sysfs - система дошла до старта Xorg - он ругнулся что не может найти драйвера по девайсы. Попробовал без procfs - не работает fsck рутового раздела (в причины не вникал) и "mount -o remount,rw,... /", отключил их и загрузчику указал "rw". Больше никаких изменений не производил. Система поднялась - отвалился conky (было бы очень странно, если бы он запустился :), большинство приложений работали, в том числе и тяжелые типа blender/inkscape/gimp. Из нерабочих обнаружил audacity (лезет в /proc/cpuinfo), palemoon (пытается информацию о собственном smaps получить), lo4 (что-то с библиотеками), ну и естественно ps и прочие основанные на procfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #230, #267

229. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:32	–1 +/–
>> Давайте пойдем от обратного - почему вы против dbus на сервере? > Вероятно по той же причине, почему я против Xorg на серверах. Просто > в меньшей степени. > А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс > — это неприятно. С Xorg все понятно, он не используется. Мне непонятен смысл выпиливания куска, необходимого для работы systemd. При этом, аргументов зачем его надо выпиливать так и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #225 Ответы: #231

230. Сообщение от arisu (ok), 15-Сен-15, 20:33	+/–
> palemoon (пытается информацию о собственном smaps получить) вообще‐то, оно должно быть опционально (если я правильно помню, то используется для показывания отчётов о памяти, что как раз и должно быть опционально). странно, надо будет в виртуалке повертеть и отучить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228 Ответы: #235

231. Сообщение от Xaionaro (ok), 15-Сен-15, 20:39	+1 +/–
>>> Давайте пойдем от обратного - почему вы против dbus на сервере? >> Вероятно по той же причине, почему я против Xorg на серверах. Просто >> в меньшей степени. >> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс >> — это неприятно. > С Xorg все понятно, он не используется. Мне непонятен смысл выпиливания куска, > необходимого для работы systemd. А если бы Xorg использовался для bwm-ng? Думаете я бы пользовался bwm-ng на серверах после этого? Нет, я бы выпилил _и_ Xorg, _и_ bwm-ng. А вы бы поступили иначе? > При этом, аргументов зачем его надо выпиливать так и нет. Ещё раз: >> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс >> — это неприятно. У меня есть множество аргументов, начиная о жёстких проблем с диском и ОЗУ (что у нас действительно наблюдается в жёсткой форме: иногда экономим мегабайты), заканчивая безопасностью, но из ваших ответов другим комментаторам я понимаю, что вы просто игнорируете такие аргументы. Поэтому может хотя бы такой аргумент подействует: чистые контейнеры запускаются и переносятся в разы быстрее, чем грязные (замусоренные всякими dbus и прочим шлаком). Для понимания: момент переноса иногда быть связан со временем downtime-а, поэтому там каждые полсекунды решают. Если каждый продукт будет работать только bundle-ом, то тогда у меня не останется никаких технических свобод, делать нужное мне для работы решение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #236

232. Сообщение от Красные Глаза (ok), 15-Сен-15, 20:40	–1 +/–
> Ну уж нет мой юный системд друг. Это будет для клиентов выглядеть > как простой сервис по предоставлению виртуалки в облачке. Зачем нужен будешь > ты с своим тайным знанием системд, если тебя любая секретарша заменит? > Она пару кнопок нажать сможет глядя в инструкцию. Да все нормально, за нас не переживай. Береги localhost.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #234

233. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 20:46	+/–
>>> Давайте пойдем от обратного - почему вы против dbus на сервере? >> Больше потенциальных точек отказа. >> Более сложное/менее прогнозируемое поведение. >> Больше вероятность получить уязвимость. > Это все слова. > 1. Например? Ошибки dbus и на стыке dbus - программа его использующая. > 2. Поведение кого/чего? Системы в целом и приложений в частности. > 3. 25 CVE и всего два с severity High. За 10 лет. А если его убрать, то и их не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213 Ответы: #237

234. Сообщение от arisu (ok), 15-Сен-15, 20:50	+2 +/–
> Да все нормально, за нас не переживай. да как же не переживать? вы же наш хлеб! если бы вас не было, вас надо было бы придумать: после того, как вы напортачите, идут к нам, и цена на приведение всего в порядок с порога в три раза больше, чем на установку с нуля. а работа та же самая: выкинуть ваш шлак и поставить с нуля. а денег в три раза больше. живите долго, дорогие!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232 Ответы: #238

235. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 21:02	+/–
> вообще‐то, оно должно быть опционально (если я правильно помню, то используется для показывания отчётов о памяти, что как раз и должно быть опционально). странно, надо будет в виртуалке повертеть и отучить. Вот полностью, что получил: strace -ff palemoon 2>&1 |grep proc [pid  1819] open("/proc/self/task/1819/stat", O_RDONLY) = -1 ENOENT (No such file or directory) [pid  1819] open("/proc/self/stat", O_RDONLY) = -1 ENOENT (No such file or directory) [pid  1818] open("/proc/self/maps", O_RDONLY|O_CLOEXEC <unfinished ...> P.S. Виртуалку необязательно, можешь просто попробовать "umount -l /proc", протестировать и назад proc примонтировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230 Ответы: #241

236. Сообщение от Красные Глаза (ok), 15-Сен-15, 21:03	–1 +/–
>[оверквотинг удален] > Ещё раз: >>> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс >>> — это неприятно. > У меня есть множество аргументов, начиная о жёстких проблем с диском и > ОЗУ (что у нас действительно наблюдается в жёсткой форме), заканчивая безопасностью, > но из ваших ответов другим комментаторам я понимаю, что вы просто > игнорируете такие аргументы. Поэтому может хотя бы такой аргумент подействует: чистые > контейнеры запускаются и переносятся в разы быстрее, чем грязные (замусоренные всякими > dbus и прочим шлаком). Для понимания, момент переноса может быть связан > со временем downtime-а, поэтому там каждые полсекунды решают. Вообще это большие проблемы, если перенос контейнера связан с даунтаймом. Я не игнорирую такие "аргументы", а прошу написать конкретные ситуации, потому что эти "аргументы" можно использовать вообще для всего :) Про ресурсы довольно странный аргумент, у меня например вот так, но у вас, может, конечно, dbus и прожорливый :) cpu: ps aux|grep dbus|awk '{SUM += $3} END {print SUM}' 0 mem: ps aux|grep dbus|awk '{SUM += $4} END {print SUM}' 0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231 Ответы: #258

237. Сообщение от Красные Глаза (ok), 15-Сен-15, 21:07	–1 +/–
>[оверквотинг удален] >>> Больше потенциальных точек отказа. >>> Более сложное/менее прогнозируемое поведение. >>> Больше вероятность получить уязвимость. >> Это все слова. >> 1. Например? > Ошибки dbus и на стыке dbus - программа его использующая. >> 2. Поведение кого/чего? > Системы в целом и приложений в частности. >> 3. 25 CVE и всего два с severity High. За 10 лет. > А если его убрать, то и их не будет. Ну в общем понятно, все из области "вилами по воде". Но dbus убрали, сломался systemd и сразу начались крики что systemd отстой :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #239

238. Сообщение от Красные Глаза (ok), 15-Сен-15, 21:09	–1 +/–
>> Да все нормально, за нас не переживай. > да как же не переживать? вы же наш хлеб! если бы вас > не было, вас надо было бы придумать: после того, как вы > напортачите, идут к нам, и цена на приведение всего в порядок > с порога в три раза больше, чем на установку с нуля. > а работа та же самая: выкинуть ваш шлак и поставить с > нуля. а денег в три раза больше. живите долго, дорогие! Это я кажется тут уже слышал некоторое время назад. Смени пластинку :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #240

239. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 21:14	+/–
> Но dbus убрали, сломался systemd и сразу начались крики что systemd отстой > :) Нет, возникает закономерный вопрос - почему остальные системы могу работать без dbus, а systemd не может? Насколько оправдано такое поведение? Почему нельзя сделать нормально работающий systemd без dbus/udev/cgroups, пусть и без некоторых функций?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #237 Ответы: #242, #278

240. Сообщение от arisu (ok), 15-Сен-15, 21:16	+2 +/–
> Смени пластинку :) зачем? правду говорить легко и приятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

241. Сообщение от arisu (ok), 15-Сен-15, 21:20	+1 +/–
> Вот полностью, что получил: > strace -ff palemoon 2>&1 |grep proc > [pid  1819] open("/proc/self/task/1819/stat", O_RDONLY) = -1 ENOENT (No such file or > directory) > [pid  1819] open("/proc/self/stat", O_RDONLY) = -1 ENOENT (No such file or > directory) > [pid  1818] open("/proc/self/maps", O_RDONLY|O_CLOEXEC <unfinished ...> после этого оно не запустилось, или таки захромало? там у мозиллы ещё и elf-loader есть немного долбанутый… > P.S. Виртуалку необязательно, можешь просто попробовать "umount -l /proc", протестировать > и назад proc примонтировать. страшно. :-) а на самом деле — виртуалка всё равно есть, в качестве «чистой системы как у пользователя», где я «полновесные» сборки смотрю. мой‐то Pale Moon (два слова, кстати :-) хорошо порезан. спасибо за репорт, будем разбираться. не нужно это браузеру, должен и без /proc работать. p.s. это офрелиз, не бета? новые офрелизы будут без jemalloc, а jemalloc тоже в /proc лазит, емнип.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235 Ответы: #243

242. Сообщение от Красные Глаза (ok), 15-Сен-15, 21:41	–1 +/–
>> Но dbus убрали, сломался systemd и сразу начались крики что systemd отстой >> :) > Нет, возникает закономерный вопрос - почему остальные системы могу работать без dbus, > а systemd не может? Насколько оправдано такое поведение? Почему нельзя сделать > нормально работающий systemd без dbus/udev/cgroups, пусть и без некоторых функций? Ну а какие критерии нормально работающего systemd? Отсутствие зависимости от dbus и udev? Почему эти критерии нормальнее их присутствия? Вопрос в том, умеют ли остальные системы из коробки то, что умеет systemd, чтобы вот просто одной строчкой в юнит файле включить (3 хайлайт для меня): 1. Watchdog 2. Лимитирование ресурсов 3. cgroups
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239 Ответы: #246

243. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 21:45	+/–
> после этого оно не запустилось, или таки захромало? там у мозиллы ещё > и elf-loader есть немного долбанутый… просто не запустилось > спасибо за репорт, будем разбираться. не нужно это браузеру, должен и без > /proc работать. Пользуясь случаем, хочу спросить: есть ли какие-то планы по включению патчей из других проектов, в частности патчи xunxun: http://sourceforge.net/p/lightfirefox/code/ci/default/tree/x.../ > p.s. это офрелиз, не бета? новые офрелизы будут без jemalloc, а jemalloc > тоже в /proc лазит, емнип. Самосбор, 32-бита, с jemalloc, срез гита от 150601 + часть патчей xunxun и кое-что от себя ;) Чего от jemalloc решили отказаться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241 Ответы: #244

244. Сообщение от arisu (ok), 15-Сен-15, 22:01	+1 +/–
> просто не запустилось ясно. > Пользуясь случаем, хочу спросить: есть ли какие-то планы по включению патчей из > других проектов, в частности патчи xunxun: > http://sourceforge.net/p/lightfirefox/code/ci/default/tree/x.../ нет, планов никаких нет. не в смысле «ни за что и никогда», а в смысле «никто не приходил, не описывал, что это и зачем оно надо». лучше всего прийти на форум и сделать топик с описанием вкусностей, и что они дают. тогда будет шанс, что включат — MC обычно не против улучшений, если они не сильно выходят за рамки «браузер для браузинга» и «такое редконужное, что этому место в расширении». > Самосбор, 32-бита, с jemalloc, срез гита от 150601 + часть патчей xunxun > и кое-что от себя ;) можно новый срез взять, там пару багов починили. :-) > Чего от jemalloc решили отказаться? а никакого особого профита не приносит: на глаз, на слух и просто так обычный аллокатор от libc ничем не хуже. возможно, когда‐то это было не так, возможно, для винды это и до сих пор не так, а для GNU/Linux jemalloc никакого существенного выигрыша не даёт. по этому поводу следующий релиз будет собран без него. и gcc 4.9: с -O2 сборки 4.9-м вполне стабильны, по скорости от 4.7 с -O3 тоже различий не заметно. так что можно перестать требовать всенепременно 4.7.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #243 Ответы: #248

245. Сообщение от Красные Глаза (ok), 15-Сен-15, 22:02	–2 +/–
>> Тебе просто что-то сказать хочется? :) > ну так тебе‐то больше сказать нечего, с «просто работает» не получилось, > тебя сразу носом тыкнули в «не работает». и тут «просто работает» > превратилось в чёрти‐что. :)))) Что еще о себе расскажешь? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #247

246. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 22:07	+/–
> Ну а какие критерии нормально работающего systemd? Отсутствие зависимости от dbus и > udev? Выполнение того же набора функций, что и в остальных системах без зависимости от dbus/udev. > Почему эти критерии нормальнее их присутствия? Другие системы прекрасно без них обходятся или работают с аналогами (mdev). > Вопрос в том, умеют ли остальные системы из коробки то, что умеет > systemd, чтобы вот просто одной строчкой в юнит файле включить (3 > хайлайт для меня): > 1. Watchdog > 2. Лимитирование ресурсов > 3. cgroups Вы не верно ставите вопрос: если конкретно для вашей задачи systemd подходит лучше всего - используйте его. Но зачем он там, где его функциональность излишне и только усложняет систему, тянет никем больше не используемые компоненты, бесполезно тратит ресурсы? Вы же не ходите все время в противогазе, дабы контролировать качество воздуха? В нормальных условиях смысла в нем нет - он только мешает. Но вот когда я занимаюсь в гараже покраской, я использую специальный респиратор с двумя фильтрами - без него и пол минуты там не пробудешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242 Ответы: #249

247. Сообщение от arisu (ok), 15-Сен-15, 22:09	+1 +/–
спасибо за содействие, с твоей помощью демонстрация безмозглости любителей системд увенчалась полным успехом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245

248. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 22:18	+/–
> лучше всего прийти на форум и сделать топик > с описанием вкусностей, и что они дают. тогда будет шанс, что > включат — MC обычно не против улучшений, если они не сильно > выходят за рамки «браузер для браузинга» и «такое редконужное, что этому > место в расширении». Вкусностей там нет, зато есть куча избавлений от невкусностей доставшихся от firefox os (telemetry/bluetooth/camera/gamepad/etc). При том в основном все завернуто #ifdef/#endif и вынесено опцией в конфиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #250

249. Сообщение от Красные Глаза (ok), 15-Сен-15, 22:32	–1 +/–
>> Ну а какие критерии нормально работающего systemd? Отсутствие зависимости от dbus и >> udev? > Выполнение того же набора функций, что и в остальных системах без зависимости > от dbus/udev. >> Почему эти критерии нормальнее их присутствия? > Другие системы прекрасно без них обходятся или работают с аналогами (mdev). Зачем нужен еще один upstart или openrc? До сих пор не могу понять, какая между ними _принципиальная_ разница. :) У апстарта, кстати, также есть зависимость от dbus, если мне не изменяет память :) >> Вопрос в том, умеют ли остальные системы из коробки то, что умеет >> systemd, чтобы вот просто одной строчкой в юнит файле включить (3 >> хайлайт для меня): >> 1. Watchdog >> 2. Лимитирование ресурсов >> 3. cgroups > Вы не верно ставите вопрос: если конкретно для вашей задачи systemd подходит > лучше всего - используйте его. Но зачем он там, где его > функциональность излишне и только усложняет систему, тянет никем больше не используемые > компоненты, бесполезно тратит ресурсы? Я с вами согласен насчет решения конкретных задач, но как вы себе представляете поддержку дистрибутива с несколькими разными системами загрузки, если одна из них - systemd? Видимо по причине того, что systemd умеет много из того, что не умеют другие, он и остался. Ну и по причине шкурного интереса RH :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #251

250. Сообщение от arisu (ok), 15-Сен-15, 22:34	+1 +/–
> Вкусностей там нет, зато есть куча избавлений от невкусностей доставшихся от firefox > os (telemetry/bluetooth/camera/gamepad/etc). При том в основном все завернуто #ifdef/#endif > и вынесено опцией в конфиг. избавления довольно своеобразные, вообще: если уж выносить — так выносить. телеметрию, кстати, в PM уже вынесли в полном составе (хотя она и раньше ничего не делала). вообще, я глянул — нет, не думаю, что оно пойдёт в mainline. кое‐что и так уже выкинули, кое‐что таки отключалось и раньше, а добавление 100500 опций сборки приоритетом не является. если что‐то ненужно, то его просто выпиливают без остатков. весь b2g вместе с его API стоит в планах на выпиливание, но это тоже пока не является приоритетной задачей. p.s. всеми горячо любимый social api тоже уничтожили уже. :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #248 Ответы: #253

251. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 22:54	+/–
> Зачем нужен еще один upstart или openrc? Нужен не еще один upstart, а возможность выбора наиболее подходящей системы инициализации для конкретной задачи. > Я с вами согласен насчет решения конкретных задач, но как вы себе > представляете поддержку дистрибутива с несколькими разными системами загрузки, если одна > из них - systemd? А в чем собственно проблема? Насколько я понимаю в debian есть поддержка нескольких систем инициализации. Другое дело, что они допускают, что приложение может быть systemd only. > Видимо по причине того, что systemd умеет > много из того, что не умеют другие, он и остался. Ну > и по причине шкурного интереса RH :) Да, попахивает все это vendor lock :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #249 Ответы: #254

253. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 23:11	+/–
> вообще, я глянул — нет, не думаю, что оно пойдёт в mainline. > кое‐что и так уже выкинули, кое‐что таки отключалось и раньше, а > добавление 100500 опций сборки приоритетом не является. если что‐то ненужно, то > его просто выпиливают без остатков. В общем то правильно, но есть некоторые вещи, типа webgl, которые удобно иметь опцией. Кстати сейчас у pm webgl не весь выпиливается - gfx/angle остается, а она нужна только для webgl. > весь b2g вместе с его API > стоит в планах на выпиливание, но это тоже пока не является > приоритетной задачей. А что приоритетно? Есть какой-то todo? P.S. Случайно не знаешь, как лучше к pm внешний видео плеер (mpv) прикрутить, что бы все видео только через него шло?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250 Ответы: #256

254. Сообщение от Красные Глаза (ok), 15-Сен-15, 23:20	–1 +/–
>> Зачем нужен еще один upstart или openrc? > Нужен не еще один upstart, а возможность выбора наиболее подходящей системы инициализации > для конкретной задачи. Вообще systemd покрывает довольно много юзкейсов, а, не оставив выбора, со временем покроет все, наверное :) >> Видимо по причине того, что systemd умеет >> много из того, что не умеют другие, он и остался. Ну >> и по причине шкурного интереса RH :) > Да, попахивает все это vendor lock :) Я не совсем это имел в виду. Тут наверное стремление подогнать платформу под тренд с контейнерами, atomic host и openshift.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251 Ответы: #255

255. Сообщение от Mihail Zenkov (ok), 15-Сен-15, 23:26	+/–
> Вообще systemd покрывает довольно много юзкейсов, а, не оставив выбора, со временем > покроет все, наверное :) Универсальное всегда хуже специализированного, за исключением когда универсальность и есть специализация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #254

256. Сообщение от arisu (ok), 16-Сен-15, 01:21	+1 +/–
> В общем то правильно, но есть некоторые вещи, типа webgl, которые удобно > иметь опцией. удобно, конечно — но эти опции надо постоянно тестировать, делать кучу сборок. а мозилловских ферм под рукой нет. поэтому опции хорошо, но… вон, опция для отключения аудио, например, работает, да не совсем. потому что ни у кого руки не доходят тестировать. потому лучше не иметь опции, нежели иметь нерабочую, я думаю. > Кстати сейчас у pm webgl не весь выпиливается - > gfx/angle остается, а она нужна только для webgl. спасибо, посмотрим, починим… наверное. >> весь b2g вместе с его API >> стоит в планах на выпиливание, но это тоже пока не является >> приоритетной задачей. > А что приоритетно? Есть какой-то todo? есть, но он у MC в голове, так просто оттуда не добудешь. больше ES6, меньше «поломаного веба» — как‐то так. остальное — хвостиком. > P.S. Случайно не знаешь, как лучше к pm внешний видео плеер (mpv) > прикрутить, что бы все видео только через него шло? неа. я сделал как обычно делаю: кривохаком. protocol handler для протокола mpv:, и userjs, который правит страницы, убирая объекты и вставляя mpv-адреса. для моих нужд мне хватает, потому дальше и не заморачивался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #253

257. Сообщение от Аноним (-), 16-Сен-15, 01:35	+/–
> Каким образом "устранив"? Вариантов много. Можно, например, прикрутить бизнес-аналитику к системе управления дронами. Автоматизация, однако.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

258. Сообщение от Xaionaro (ok), 16-Сен-15, 08:03	+1 +/–
>[оверквотинг удален] >> Ещё раз: >>>> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс >>>> — это неприятно. >> У меня есть множество аргументов, начиная о жёстких проблем с диском и >> ОЗУ (что у нас действительно наблюдается в жёсткой форме), заканчивая безопасностью, >> но из ваших ответов другим комментаторам я понимаю, что вы просто >> игнорируете такие аргументы. Поэтому может хотя бы такой аргумент подействует: чистые >> контейнеры запускаются и переносятся в разы быстрее, чем грязные (замусоренные всякими >> dbus и прочим шлаком). Для понимания, момент переноса может быть связан >> со временем downtime-а, поэтому там каждые полсекунды решают. Вы опять игнорируете что я написал. > Вообще это большие проблемы, если перенос контейнера связан с даунтаймом. Ну да, проблемы. И? Содержимое большинства контейнеров определяется другими подразделениями, у которых совершенно нет времени думать о FT. > Я не > игнорирую такие "аргументы", а прошу написать конкретные ситуации, потому что эти > "аргументы" можно использовать вообще для всего :) Про безопасность вы аргумент другого собеседника не признали, хотя аргумент весьма валиден. Вы просто забываете, что если идти по пути, который предлагаете вы, то это приведёт к очень большому количеству мусора и кроме dbus (так как вы отвергаете правила, которые служили нам много лет, см. ниже). Сам по себе dbus обычно почти не мешает (хотя бывает и мешает), но если этого мусора набрать много, то, например, появляются следующие проблемы: 1. Низкая предсказуемость (больше всякого необходимо учитывать). Например, dbus мог не стартовать из-за какой-нибудь selinux. Каждое лишнее звено -- это дополнительная точка для отказа. 2. Ниже производительность. Чем больше процессов, тем больше жрётся ОЗУ, больше времени тратится на запуск всех этих процессов и т.п. 3. Больше дыр безопасности. 4. Ниже управляемость. Каждый дополнительный пакет может строить какие-то свои зависимости, и в результате может стать сложнее сделать немного custom-ную систему под конкретную задачу. 5. (Знаю, что не признаете этот аргумент, но зря) Хуже чисто эстетически. Когда висят лишние процессы, установлены лишние пакеты и т.п., мозг администратора замусоривается лишним. Лишь например он тратит доли секнды при каждой диагностике, чтобы исключить тот же dbus из причины неполадки. Когда система минимальна, её намного проще понимать. Есть и другие проблемы, но надеюсь, суть и так уже понятна. Существовали простые хорошо себя зарекомендовавшие правила: 1. Не плодить лишних сущностей (действительно лишних). 2. Разбивать сложную задачу на множество простых (в частности, не должно быть lock in bundle-ов). Понимаете, это администратор сервера должен определять как всё должно работать, а не какие-то lock in-ы на пустом месте. > Про ресурсы довольно странный аргумент, у меня например вот так, но у > вас, может, конечно, dbus и прожорливый :) > cpu: > ps aux|grep dbus|awk '{SUM += $3} END {print SUM}' > 0 > mem: > ps aux|grep dbus|awk '{SUM += $4} END {print SUM}' > 0 Повторяю, речь идёт на мегабайты. Из десятков разных контейнеров убиваешь по dbus-у, и уже становится лучше, ибо освобождается куча дополнительного ОЗУ под дисковый кеш. Потом ещё поубивать всякие другие бесполезные вещи (кроме dbus), так вообще сразу становится "можно жить дальше". # grep ^Vm /proc/`pgrep dbus | head -1`/status VmPeak:    47924 kB VmSize:    47916 kB VmLck:         0 kB VmPin:         0 kB VmHWM:      4040 kB VmRSS:      2856 kB VmData:      564 kB VmStk:       136 kB VmExe:       412 kB VmLib:      5652 kB VmPTE:       108 kB VmSwap:        0 kB И ответьте, пожалуйста, на вопрос тут: http://www.opennet.me/openforum/vsluhforumID3/104726.html#178 Вопрос про то, являются ли те примеры самыми сильными из тех, что вы смогли привести. И прошу не забывать, что systemd мне не даёт ничего, из того, что мне не даёт openrc (из того, что мне требуется по работе). И OpenRC лично на моей практике работает лучше и даёт больше технических свобод, чем systemd. Поэтому ваши аргументы по поводу того, что dbus нужно ставить для systemd мне кажутся неприемлемыми. Они лишь доказывают дополнительную лёгкую ущербность systemd. Вообще, systemd-шники мне очень напоминают дотнетчиков. Не в плохом смысле, а скорее своими особенностями мышления. Бывают люди, которые ничего кроме дотнета не пробовали -- это, конечно грустные случаи, обычно. А бывают люди, которые перешли с других ЯП на всякие дотнеты, аргументируя это экономией человекочасов. Я понимаю, что бывают use case-ы, где дотнет (как и systemd) действительно оправдан и его нужно использовать, но данные персонажи считают, что весь мир должен стать дотнетовским. В результате они начинают применять дотнеты, даже когда они совершенно неуместны, и продолжают считать, что они экономят человекочасы. А потом всё заканчивается тем, что игрушка дико тормозит, у неё принципально нельзя сделать простой "save game" до рефакторинга (из-за странноватой культуры использования лямбда-функций и невозможности сериализовать текущее состояние) и мн. др. Тратится огромное количество времени на решение этих проблем и продукт всё равно в результате становится "так себе". И в этом, на самом деле, нет ничего особо плохого, это просто инерция мышления. Все мы ей страдаем. Просто разные люди мыслят в каких-то своих рамках. Я сам тоже творю много всякой (очевидной для другого мировоззрения) херни, о чём понимаю обычно уже слишком поздно. Но весь этот абзац тоже написан исходя из мышления в определённых рамках, поэтому тоже может быть сильно ошибочным, и я не хочу сказать ни про кого ничего плохого. Целью его написания было лишь помочь понять мою позицию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236 Ответы: #266

259. Сообщение от Аноним (-), 16-Сен-15, 10:16	–1 +/–
> Надо подтянуть эрудицию -- Стремление похвальное. > перечитать визги Во первых, там - никаких визгов. А какое-никакое понимание проблематики, но в паре с идеализмом и довольно симпатичным желанием: чтобы в ядро Linux включали подсистемы по критерию "technical excellence". Хорошее желание, мне оно нравится (особенно - если Энди готов показать всем как надо было и сделает это быстрее и лучше). И Энди смог показать некоторые вполне технические моменты которые ему не нравятся в D-BUS как шине. Он при этом не вопит "кому нужны эти шины?!". И вроде согласен что шины - нужны. Код он если и смотрел то совсем по диагонали (но опеннетовские эксперты и близко к этому не подошли - они Мнение Имеют вообще на песке, путем прокачки слухов и предрассудков). Поэтому аргументы местами смотрятся жидковато. Но лучше опеннетчиков и технически валидно. И даже породили много дебатов о производительности D-BUS. По своему интересных. А core его мысли видимо в том, что пользуясь случаем можно было бы сделать редизайн "с ноля" по итогам выявленных проблем, вместо попыток мимикрировать под D-BUS (kdbus не является копией 1 в 1 но ряд вещей из dbus унаследовал). > коллег про kdbus, А ты что, тоже в Runa Capital работаешь, как Энди? И как, много платят проклятые капиталисты, ворочающие капиталами? :) А так то этот Энди зажигает, да. Он там недавно симпатичный такой сплойт выкатил - основанный на дypaцкой обработке NMI в х86. Ядерщики же потопали костылить обработчик NMI еще сильнее. А любители гарцевать старым кернелом - получат just in case повышение прав до рута на халяву в своей систему :P. > а то прям стыдно. Это уже хорошо. >> Алилуйя, вы нашли друг друга. Два шута - пара. > Уже плАчу, ага. Тут и на другую букву можно ударение ставить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #260

260. Сообщение от Andrey Mitrofanov (?), 16-Сен-15, 10:32	+2 +/–
>> Надо подтянуть эрудицию -- > Стремление похвальное. >> перечитать визги > Во первых, там - никаких визгов. Я про твой пассаж "позорные визги опеннетовских ретрогоадов". Ты ж передёрнул с визгов против лёня-дэ-жене-сапоги-дэ на к-дэ-автобус, да? А такой простой ссылки не понял, шлангом прикинулся, айяйяй. > паре с идеализмом и довольно симпатичным желанием: чтобы в ядро Linux > включали подсистемы по критерию "technical excellence". Хорошее желание, мне оно нравится >> коллег про kdbus, > А ты что, тоже в Runa Capital работаешь, как Энди? И как, Штаны на лямках, детсад, песочница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #259

261. Сообщение от Andrey Mitrofanov (?), 16-Сен-15, 10:45	+1 +/–
>>> что как отлаживать скрипт именно в boot time - эксперты опеннета >>> вообще ни разу не показали. #>>      > Systemd хорошо документирован, так что все проблемы, не от systemd, а от #>>      Докажи! . http:/openforum/vsluhforumID1/96286.html   Время пошло. > Андрюша, по этой ссылке случай для доктора. Согласен. Все пользователи зюстем-ды проявляют симптомы. А уж активные агитаторы и сторонники...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

262. Сообщение от Аноним (-), 16-Сен-15, 11:10	+/–
> ещё раз уточню: системная шина магически добавляет код для проверки capabilities? Нет. Но позволяет все это делать просто, ненапряжно, в логичном и устаканеном формате. А без шины - достаточно посмотреть как сейчас обрабатываются вещи типа "закрытие крышки ноута" или "садится батарейка". С реалистичной точки зрения - поймать подобное system-wide событие в моей программе без события по шине - большая проблема, особенно если хочется чтобы это потом работало не только на одной системе в мире - моей собственной. > если нет, то каким образом люди, заведомо клавшие болт на такие проверки, > вдруг станут это делать? Ну вот таким. Одно дело если мне по шине могут прислать событие "юзер закрыл крышку ноута" или "садится батарейка" и можно в 1 закоулке кода проверить есть ли вообще интерсующая сущность в этой системе. И совсем другое - если у народа разнообразное месиво без какого либо устаканеного интерфейса к нему вообще. Выписывать в программе 100500 реализаций на все случаи жизни - малореалистично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #263

263. Сообщение от arisu (ok), 16-Сен-15, 11:17	+2 +/–
>> ещё раз уточню: системная шина магически добавляет код для проверки capabilities? > Нет. тогда сложный вопрос номер два: что обозначали твои слова «Я уже видел как все это работает с иксами», и каким образом системная шина помогла бы сетевому протоколу иксов? note: ответ «я по привычке пнул иксы, забыв подумать» — принимается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262

264. Сообщение от Аноним (-), 16-Сен-15, 11:59	+2 +/–
Сказал человек, который сам не изобрел и не собрал ни одного транспортного средства? И собственно, что вы имеете против ног?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #276

265. Сообщение от Аноним (-), 16-Сен-15, 13:22	+/–
> Что бы действительно соответствовало моей логике, перечислите приложение которые > необоснованно завязываются за procfs/sysfs. Для начала - а кто решает "обосновано ли?", по каким критериям, и почему - именно он и именно вот так, а не кто-нибудь другой и как-нибудь иначе? Я уже не в первый раз спрашиваю, но ни разу не увидел ответа. Или просто пропустил. На всякий случай напомню что эксклюзивно решать как и что - лично вы можете за всех в 1 случае: если вы пишете и систему и программы целиком сами. В остальных случаях это будут какие-то иные критерии и механизмы, к тому же динамически меняющиеся во времени. С чисто технической точки зрения, теоретически ни sysfs ни procfs не являются абсолютно необходимыми. Вон например в винде ни одна программа ими не пользуется. Значит, можно писать произвольные программы и без procfs и sysfs. Они лишь позволяют что-то сделать удобнее, получить какую-то дополнительную информацию, на что-то повлиять. Можно придумать кучу иных методов как сделать то же самое без них. Ну там позаменять все ioctl'ами и syscall'ами, например. Иногда сисколы даже лучше чем файловые операции, как например вызов для получения рандома (работу сисколов сложнее саботировать чем файловые операции, а саботаж получения рандома штука чреватая). ...а мой пойнт - в том, что все то же самое про нужность и использование можно сказать и про системные шины. Единственные отличия - может быть это скажут другие люди для других программ. А нужны ли эти программы лично вам - вообще дело десятое, имхо, т.к. ни Linux ни программы вообще не пишутся для лично вас. И поэтому учитываться должно далеко не только ваше мнение, по логике вещей. > Я и не спорю, что в определенных случаях системная шина может быть > реально полезно, но пока мне попадались не очень удачные примеры ее использования. Это уже другой вопрос. Зачем именно gimp-у шина для вкладое - загадка. А вот например рассылать так события затрагивающие работу системы в целом - очень даже. Ну вон в Nokia N900 (и более ранних Nokia 770, 800 и 810) - нокия конкретно оттянулась с d-bus. И заявы про ресурсы - идут лесом! Знаете, у этих девайсов мало ресурсов. И d-bus там - далеко не основная проблема. Наиболее прожорливы там, пардон, иксы. При том зачем фирма нокия так сделала - я понимаю. Они много ломали голову над сбалансированным набором компромиссов. Потому что ресурсов мало, фичей хочется огого, время на разработку - не резиновое и прочее. И даже несмотря на хилые ресурсы, и d-bus и пульсаудио по итогам им оказались лучше чем самим все велосипедить. Вот это - пример сбалансированного дизайна системы. Где оптимизации которые дают наибольший выигрыш - постарались сделать, насколько это позволяли разумные временные рамки. И кроме всего прочего, результатом просто приятно пользоваться. Он радует глаза и уши и весьма умеренно тормозит если не слишком увлекаться многозадачностью. Ведроид с его явой тормозит и на вчетверо больших ресурсах. На ресурсах как у Nokia 770 и 800/810 - ведроид фундаментально не жилец. А на ресурсах как N900 он ... cильно хуже maemo. А у вас антипатии к d-bus и прочие бряцания оптимизациями имхо завалились в иррациональный и контрпродуктивный формат, когда тормозным и жирным блоатваринам типа иксов, которые к тому же плохо работают - за что-то скидки. Зато под нож почему-то идут какие-то полезные на мой взгляд сервисы, явно не являющиеся лидерами top-списка. > Ну да, она нужна только тем, кто профессионально работает со звуком, кому > нужна минимальная задержка и максимальная гибкость, Ну вот этим и пользуется полторы узкоспециализированые программы на планете. А с точки зрения обычного апликушника - если хочется просто проиграть звук, совершенно не хочется возиться с определением каких-то там поддерживаемых форматов, кучей служебных действий и воркэраундом чужих грабель. И алса в этом плане - не фонтан. > - ест и память и проц. Если его вместо "ультраопцоинальности" сделают > по-умолчанию, то будут плеваться все, в том числе и я. С другой стороны, вас что-то не смущает ломовое потребление ресурсов иксами при мало-мальски активной отрисовке, особенно если апликушник не заморачивался с обнаружением их кучи опциональных расширений (т.к. придется еще и fallback выписывать на случай если их не оказалось). Я это называю двойными стандартами. И к хорошо работающей системе все это ИМХО не ведет. > Напрямую alsa/jack/pa используют те, кто умеет работать со звуком и его задачи > отличны, от просто проиграть файл. Те кому действительно нужно просто возьмут > высокоуровневую библиотеку/плеер, Так тоже бывает, НО это довольно большой пласт зависимостей. А зависимость от внешних программ вообще грабли. Мало ли что там автор завтра поменяет. Он ведь даже не позиционировал плеер как реюзабельную библиотеку. Отличный образчик - libav и их тотальное перефигачивание командлайна. For teh greater good и ... сломавшее все скрипты. Так что как библа их утилиты совсем ни о чем. Именно либа - менее поломана, да, как раз вот поэтому. Но и там breakage начал допекать апликушников :) > так как по мимо непосредственно вывода звука еще нужно > уметь разбирать формат аудио файла Так тоже делают. > и корректно делать промежуточные преобразования. А вот это - отдельная специфичная математика. И грабель там много. И не все делают это хорошо. И вы знаете, да, либы так умеют. Но положа руку на сердце, pulseaudio делает все это намного качественнее чем многие из либ. Из того что на злобу дня - libsdl умеет делать преобразования, но - это такой трэш. Там алгоритм примитивный, поэтому если случился upsample - это ведет к очень мерзотному звучанию с характерными артефактами. Вот и получается - либу вроде приволокли, а звук вроде все-равно поганенький. Логично что половина програмеров предпочтет сплевывать вывод в пульс самолично. Сэкономив на зависимостях и получив качество звука лучше. Сплошной профит... > Для остальных же alsa api позволяет делать куда больше чем pa, в > том числе и bit perfect. И все это круто, только там изначально не было человеческого апи. Остальное при этом уже не важно для 99% задач. Ну да, 1% тех кому надо именно "bit perfect", любой ценой - разопрутся. А остальные 99% програмеров достанут фак из кармана. Потому что им не надо bit perfect. Им надо вывести звук без мытарств и чтобы это не звучало как гомно. А если при этом не надо зависеть от 20 сторонних библ где могут что-то поменять - вообще отлично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #269

266. Сообщение от Красные Глаза (ok), 16-Сен-15, 13:36	–1 +/–
>[оверквотинг удален] >>>>> А вообще, у меня есть тонна минималистичных контейнеров, где каждый дополнительный процесс >>>>> — это неприятно. >>> У меня есть множество аргументов, начиная о жёстких проблем с диском и >>> ОЗУ (что у нас действительно наблюдается в жёсткой форме), заканчивая безопасностью, >>> но из ваших ответов другим комментаторам я понимаю, что вы просто >>> игнорируете такие аргументы. Поэтому может хотя бы такой аргумент подействует: чистые >>> контейнеры запускаются и переносятся в разы быстрее, чем грязные (замусоренные всякими >>> dbus и прочим шлаком). Для понимания, момент переноса может быть связан >>> со временем downtime-а, поэтому там каждые полсекунды решают. > Вы опять игнорируете что я написал. Ну вы хоть тогда * помечайте то, на что надо отвечать :) >> Вообще это большие проблемы, если перенос контейнера связан с даунтаймом. > Ну да, проблемы. И? Содержимое большинства контейнеров определяется другими подразделениями, > у которых совершенно нет времени думать о FT. ok, все бывает. Но это выглядит весьма странно на фоне довольно жестких требований к работоспособности системы. >[оверквотинг удален] > Про безопасность вы аргумент другого собеседника не признали, хотя аргумент весьма валиден. > Вы просто забываете, что если идти по пути, который предлагаете вы, то > это приведёт к очень большому количеству мусора и кроме dbus (так > как вы отвергаете правила, которые служили нам много лет, см. ниже). > Сам по себе dbus обычно почти не мешает (хотя бывает и > мешает), но если этого мусора набрать много, то, например, появляются следующие > проблемы: > 1. Низкая предсказуемость (больше всякого необходимо учитывать). Например, dbus мог не > стартовать из-за какой-нибудь selinux. Каждое лишнее звено -- это дополнительная точка > для отказа. selinux в  контейнерах не используется. > 2. Ниже производительность. Чем больше процессов, тем больше жрётся ОЗУ, больше времени > тратится на запуск всех этих процессов и т.п. см. п4 > 3. Больше дыр безопасности. За 10 лет, два с sev High и то локально. Подобные проблемы с безопасностью решаются своевременным обновлением. Согласен, не всегда это возможно, но не в случае с dbus. > 4. Ниже управляемость. Каждый дополнительный пакет может строить какие-то свои зависимости, > и в результате может стать сложнее сделать немного custom-ную систему под > конкретную задачу. Вот все зависимости dbus на RH: yum deplist dbus | grep provider| awk '{print $2}'| cut -d'.' -f1| sort -u audit-libs bash chkconfig dbus-libs expat glibc libcap-ng libselinux shadow-utils systemd Что из этого снижает вашу управляемость или повышает использование памяти/процессора?  Кроме systemd, конечно :) > 5. (Знаю, что не признаете этот аргумент, но зря) Хуже чисто эстетически. > Когда висят лишние процессы, установлены лишние пакеты и т.п., мозг администратора > замусоривается лишним. Лишь например он тратит доли секнды при каждой диагностике, > чтобы исключить тот же dbus из причины неполадки. Когда система минимальна, > её намного проще понимать. Вы правы, не аргумент совсем. > Есть и другие проблемы, но надеюсь, суть и так уже понятна. Существовали > простые хорошо себя зарекомендовавшие правила: > 1. Не плодить лишних сущностей (действительно лишних). > 2. Разбивать сложную задачу на множество простых (в частности, не должно быть > lock in bundle-ов). > Понимаете, это администратор сервера должен определять как всё должно работать, а не > какие-то lock in-ы на пустом месте. Т.е. когда в бинарнике зависимость от glibc, это не lock in, а когда зависимость от dbus, это lock in? Из всех аргументов, я могу понять только аргумент с памятью. Но проблема с памятью у вас - это не проблема systemd, а исключительно ваша локальная проблема. При этом выпилив dbus, который необходим для работы systemd и естественно получив ошибку, заявили что sysytemd отстой. Я пытался вам доказать что вы неправы в этом заявлении ;) Я согласен, что к вашему кейсу systemd может не подходить, но это ведь не значит что systemd полный трэш? Это был мой поинт, почему я ввязался в спор. Если вы не против, я готов выслушать ваши заключительные аргументы и предлагаю завершить дискуссию, а то она начинает забирать много времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258

267. Сообщение от Аноним (-), 16-Сен-15, 14:57	–1 +/–
> lo4 (что-то с библиотеками), ну и естественно ps и прочие основанные на procfs. Ну так я говорю что они не являются АБСОЛЮТНО необходимыми. Вон в винде их вообще отродясь не было, а pale moon там как-то даже работает вроде. А вон в DOS - вообще много чего не было. Даже защиты памяти и многозадачности. А программы как-то работали. Можно и дальше продолжить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #228

268. Сообщение от Аноним (-), 16-Сен-15, 15:20	+/–
> нет. как только разработчик перестаёт пилить это в подвале лично для себя > — так сразу и не рассматривается. С такими аргументами вы далеко и хорошо пойдете. Шипеть в сторонку что разработчики скурвились и требуют d-bus, например. Да, парни: если вас не интересует мое удобство, меня ваше - и подавно тогда не интересует. При таких раскладах я просто сделаю как удобнее всего мне, на чем наше взаимодействие и закончится. Пробухтев что-нибудь вида "можете не пользоваться, если не нравится, и вообще шли б вы с такими подходами куда-нибудь на openbsd".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #274

269. Сообщение от Mihail Zenkov (ok), 16-Сен-15, 15:26	+/–
>> Что бы действительно соответствовало моей логике, перечислите приложение которые >> необоснованно завязываются за procfs/sysfs. > Для начала - а кто решает "обосновано ли?", по каким критериям, и > почему - именно он и именно вот так, а не кто-нибудь > другой и как-нибудь иначе? Я уже не в первый раз спрашиваю, > но ни разу не увидел ответа. Или просто пропустил. Вопрос сложный и каждый его решает сам. Моя точка зрения: 1. если библиотека/подсистема не является необходимой частью для выполнения ключевых задач проекта, а лишь нужна для второстепенных возможностей - то она должна быть опцией. 2. выбранная библиотека/подсистема должна быть одним из лучших вариантов для решения _конкретной_ задачи. > На всякий случай напомню что эксклюзивно решать как и что - лично > вы можете за всех в 1 случае: если вы пишете и > систему и программы целиком сами. В остальных случаях это будут какие-то > иные критерии и механизмы, к тому же динамически меняющиеся во времени. Слава Столману, мы говорим о свободном софте и каждый сам выбирает какой софт использовать или может изменять его под свои нужды/воззрения, в плоть до форка или создания альтернативных решений. > С чисто технической точки зрения, теоретически ни sysfs ни procfs не являются > абсолютно необходимыми. Для большинства программ - да. > Вон например в винде ни одна программа ими не > пользуется. Значит, можно писать произвольные программы и без procfs и sysfs. О том и речь: ненужно завязываться без реальной необходимости на особенности системы и портировать софт станет гораздо проще. Я выше озвучил свой эксперимент с отключением procfs/sysfs - можно найти приложения излишне цепляющиеся за procfs/sysfs, но в большинстве своем приложениям они не нужны. > Они лишь позволяют что-то сделать удобнее, получить какую-то дополнительную информацию, > на что-то повлиять. Можно придумать кучу иных методов как сделать то > же самое без них. Ну там позаменять все ioctl'ами и syscall'ами, > например. Иногда сисколы даже лучше чем файловые операции, как например вызов > для получения рандома (работу сисколов сложнее саботировать чем файловые операции, а > саботаж получения рандома штука чреватая). Все зависит от конкретной задачи. > ...а мой пойнт - в том, что все то же самое про > нужность и использование можно сказать и про системные шины. Единственные отличия > - может быть это скажут другие люди для других программ. А > нужны ли эти программы лично вам - вообще дело десятое, имхо, > т.к. ни Linux ни программы вообще не пишутся для лично вас. > И поэтому учитываться должно далеко не только ваше мнение, по логике > вещей. Естественно, более того я рад _любому_ открытому проекту, даже если его подход отличается от того, который предпочитаю я. Но мне не нравится когда мне что-то навязывают и делают обязательным - это мешает здоровой конкуренции и сужает круг возможностей. >> Я и не спорю, что в определенных случаях системная шина может быть >> реально полезно, но пока мне попадались не очень удачные примеры ее использования. > Это уже другой вопрос. Зачем именно gimp-у шина для вкладое - загадка. Он сам себе посылает имя файла,который нужно открыть. > А вот например рассылать так события затрагивающие работу системы в целом > - очень даже. Ну вон в Nokia N900 (и более ранних > Nokia 770, 800 и 810) - нокия конкретно оттянулась с d-bus. > И заявы про ресурсы - идут лесом! Знаете, у этих девайсов > мало ресурсов. Просто ответьте - сколько памяти ест голая (без пользовательских приложений) система после запуска? > И d-bus там - далеко не основная проблема. Наиболее > прожорливы там, пардон, иксы. 1. Почему вы решили, что Xorg потребляет ресурсы необоснованно? 2. Если что-то потребляет ресурсы, это еще не повод плюнуть на все остальное. > При том зачем фирма нокия так сделала - я понимаю. Они много > ломали голову над сбалансированным набором компромиссов. Потому что ресурсов мало, фичей > хочется огого, время на разработку - не резиновое и прочее. ИМХО сделали как было проще, а на потребление ресурсов забили. > И даже несмотря на хилые ресурсы, и d-bus и пульсаудио по итогам > им оказались лучше чем самим все велосипедить. Особенно PA - еще одна прослойка, преобразующая достаточно неслабый аудио поток, очень уместна на embedded. Андройдовцы наоборот пилили tinyalsa - им и возможности alsalib казались бессмысленными. > Вот это - пример сбалансированного дизайна системы. Где оптимизации которые дают наибольший > выигрыш - постарались сделать, насколько это позволяли разумные временные рамки. И > кроме всего прочего, результатом просто приятно пользоваться. Он радует глаза и > уши и весьма умеренно тормозит если не слишком увлекаться многозадачностью. А без pa/dbus/и прочих демонов он работал бы медленнее? >  Ведроид > с его явой тормозит и на вчетверо больших ресурсах. На ресурсах > как у Nokia 770 и 800/810 - ведроид фундаментально не жилец. > А на ресурсах как N900 он ... cильно хуже maemo. Андройд вообще забавный зверь - походу его делали две разные команды: нижний уровень (до явы) относительно неплохо сделан, есть интересные моменты, но верхний ... > А у вас антипатии к d-bus и прочие бряцания оптимизациями имхо завалились > в иррациональный и контрпродуктивный формат, когда тормозным и жирным блоатваринам типа > иксов, которые к тому же плохо работают - за что-то скидки. > Зато под нож почему-то идут какие-то полезные на мой взгляд сервисы, > явно не являющиеся лидерами top-списка. То есть надо ждать, пока dbus/sytemd не станут есть больше чем Xorg? >> Ну да, она нужна только тем, кто профессионально работает со звуком, кому >> нужна минимальная задержка и максимальная гибкость, > Ну вот этим и пользуется полторы узкоспециализированые программы на планете. Весь софт создания/обработки звука (+ видеоредакторы и многие плееры) под линукс, включая закрытые коммерческие (тот же pianoteq). Насколько я помню его и под другие ОС портировали, но не знаю зачем и с каким успехом. >[оверквотинг удален] > А вот это - отдельная специфичная математика. И грабель там много. И > не все делают это хорошо. И вы знаете, да, либы так > умеют. Но положа руку на сердце, pulseaudio делает все это намного > качественнее чем многие из либ. Из того что на злобу дня > - libsdl умеет делать преобразования, но - это такой трэш. Там > алгоритм примитивный, поэтому если случился upsample - это ведет к очень > мерзотному звучанию с характерными артефактами. Вот и получается - либу вроде > приволокли, а звук вроде все-равно поганенький. Логично что половина програмеров предпочтет > сплевывать вывод в пульс самолично. Сэкономив на зависимостях и получив качество > звука лучше. Сплошной профит... Приведите конкретный пример когда работа напрямую с pa оправдана. Если человеку нужно например сделать звуковое оповещение при событии в программе - он просто пропишет запуск вешнего плеера и имя звукового файла. В настройках сделает строку, в которой пользователь сам сможет указать любимый плеер/опции/свой звуковой файл. В дебри о том какая там у пользователя подсистема он не полезет - это забота пользователя/маинтейнеров дистрибутива.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265

270. Сообщение от Аноним (-), 16-Сен-15, 15:54	–1 +/–
> «разработчику это удобно» - недостаточное обоснование, Я думаю что для большинства разработчиков это как раз более чем достаточное обоснование. Они это обоснуют задействовав апи, которое им удобно и проигнорировав то которое им неудобно. Оспорить это можно в спортлото. По какой-то такой причине ioctl'ы например считаются дурным апи. Они могут работать. Но даже просто их полный список например получить... > достаточное - один из лучших вариантов для решения _конкретной_ проблемы. Ну вот информирование о system-wide событиях например логичнее всего смотрелось бы через системную шину, имхо. > А то так можно договорится до того, что разработчикам неудобно ядро на > c+asm писать, давайте на java/python/etc переходить. Так они С используют как раз потому что на нем системные вещи удобнее всего делать. Было бы удобнее на чем-то другом - пользовались бы этим. А жаба слишком высокоуровневая. Надо вам записать 0x20 по адресу 0x100500. Потому что там memory-mapped периферия, напимер. А в жабе такого понятия обана и ... нет. Или например GC. У вас тут шедулер процессов, вы за чуть ли не наносекунды давитесь. А тут пришел GC, и поставил все колом на секунду. FAIL. Кстати, эта граблина нашла множество лбешников. Те кто попробовал на JS писать игры, очень скоро заметили что игры начинают непредсказуемо лагать на ровном месте. Когда gc приспичивает мусор собрать. И все бы ничего, только юзеры очень бесятся когда все клинит на секунду. И даже на ведроиде игроделы недвусмысленно потребовали нативный код. Потому что им так проще и результат лучше, а не что-нибудь еще. Допинать жабу с ее GC, малопредсказуемым временем операций и просадками до вменяемого состояния - просто сложно, даже если не требовательные к скорости программы на ней писать и проще, в системных делах и критичных к скорости задачах перевешивают иные факторы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #272, #273, #275

271. Сообщение от pavlinux (ok), 16-Сен-15, 15:56	+1 +/–
ИЧСХ, все кто пишет про фичи системд даже невдупляют чо оно там делает, нужно ли оно, поттер впихнул - значит надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

272. Сообщение от Mihail Zenkov (ok), 16-Сен-15, 17:11	+/–
>[оверквотинг удален] > эта граблина нашла множество лбешников. Те кто попробовал на JS писать > игры, очень скоро заметили что игры начинают непредсказуемо лагать на ровном > месте. Когда gc приспичивает мусор собрать. И все бы ничего, только > юзеры очень бесятся когда все клинит на секунду. И даже на > ведроиде игроделы недвусмысленно потребовали нативный код. Потому что им так проще > и результат лучше, а не что-нибудь еще. Допинать жабу с ее > GC, малопредсказуемым временем операций и просадками до вменяемого состояния - просто > сложно, даже если не требовательные к скорости программы на ней писать > и проще, в системных делах и критичных к скорости задачах перевешивают > иные факторы. Все что вы описали - это не "удобно", а решение конкретных задач и С действительно для них лучше подходит. А вот когда человек тянет Qt только для открытия OpenGL контекста, потому что Qt он когда-то использовал, а другие библиотеки нужно искать и изучать - вот это "удобно", но по моему мнению неправильно. И лично я постараюсь держаться подальше от подобных программ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

273. Сообщение от Mihail Zenkov (ok), 16-Сен-15, 17:15	+/–
> Ну вот информирование о system-wide событиях например логичнее всего смотрелось бы через > системную шину, имхо. Не уверен, был уже спор на эту тему. Я все же пока остаюсь на своем мнении о необходимости дальнейшего развития sysfs, библиотек и утилит для работы с ним.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

274. Сообщение от arisu (ok), 16-Сен-15, 21:12	+/–
ну вот я и не пользуюсь всяким системдецом и пшшшшшаудио, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268

275. Сообщение от arisu (ok), 16-Сен-15, 21:13	+1 +/–
> Так они С используют как раз потому что на нем системные вещи > удобнее всего делать. rotfl.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

276. Сообщение от Аноним (-), 16-Сен-15, 22:11	+1 +/–
Как что против? Он хочет что бы всем принудительно отрезали ноги. А кто хочет может пришить самостоятельно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #264

277. Сообщение от Нечестивый (ok), 21-Сен-15, 11:11	+/–
> Но это не значит, что у кого-то какой-то софт не может просто работать. Windows тоже "просто работает". Вот только если допустить на своем компьютере экосистему Гнома со всеми system-*d, *kit-ами, pulse* и т.п. получается то же самое что и с Windows. Компютер работает. Активно. У него также нашелся и небольшой уголок где потребитель может немного поиграться (много не получиться, интерфейс ведь не напрасно столько лет затачивали под невозможность работать с многими программами одновременно...) не мешая работы. Вот только если вместо правильно воспитанного потребителя там сядет человек, считающий что компьютер - инструмент которым он будет работать вдруг оказывается что здесь уже работают, а он просто мешает. Извините, но я не пиндоевропейский корпоративный бюрократ, которому работать по дефиниции не полагается. Компьютер - _мой_ инструмент. Любая программа, работающая на нем должна делать лишь то, что нужно мне. Если она делает то, что не является необходимым для меня значит она работает на кого то другого. Ситуация где программа делает что то другое допускается только с моим информированным согласием, если меня за это каким то образом компенсируют. А вот те программы, с которыми вдруг оказывается что это я мешаю пользоваться моим компьютером для работы не на меня должны просто исчезнуть. И я должен сделать для этого все что смогу. Вопрос гуманитарной самозащиты. Так что простите, но не тролить против systemd для меня не допустимо, ведь отказ от самозащиты является самым тяжким преступлением против человечества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

278. Сообщение от Аноним (-), 25-Сен-15, 02:31	–1 +/–
> Нет, возникает закономерный вопрос - почему остальные системы могу работать без dbus, Вот пусть эти остальные системы и работают. А я буду считать систему без системной шины дефективной by design. И пользоваться такой хренью соглашусь только по сильно особенным случаям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239

279. Сообщение от Аноним (-), 25-Сен-15, 02:34	–1 +/–
> хорошо, что не все дистрибутивы сделаны больными на череп идиoтами. Но знаешь, кэп, на дистрах которые обычно ставят на сервера (debian, ubuntu, centos, rhel) - нынче таки есть и systemd и dbus :). И говоря за себя - я так например как-то и не буду гореть желать рулить сервером если там нет systemd. Он как-то зело упрощает многие вещи. А к хорошему быстро привыкаешь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #284, #285

280. Сообщение от Аноним (-), 25-Сен-15, 02:35	+/–
> procfs на сервере нужен лишь например для "ps" или чистки xt_recent. По вашей логике, "без этого можно обойтись". Ну а что, можно список процессов получать каким-нибудь перебором pid'ов на предмет использования :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171 Ответы: #288

281. Сообщение от Аноним (-), 25-Сен-15, 02:39	+/–
> что отлично делается без cgroups, но лёне об этом никто не сказал. Ну ты то нам расскажешь, как отследить откуда взялся %s, сделавший несколько форков, так что parent'ы вырубились и он остался с parent'ом в виде PID=1? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #287, #289

282. Сообщение от Аноним (-), 25-Сен-15, 02:51	+/–
> это попросили) на #openrc. Но в отличие от systemd это опционально. Что хорошо для кульсисопа с зудом в ж..., то плохо для администратора. А вот админ в результате не будет знать: можно ли в этой конкретной системе отследить, или нельзя. И брать такую систему на администрирование - нафиг нужно! Такие вещи по моему мнению должны быть более-менее mandatory и если и обрываемы то в микроэмбедовке уровня openwrt. И даже там - невозможность более-менее внятно узнать откуда кто взялся - таки баг а не фича. > я могу понять нужду использования cgroups для отслеживания процессов, и я > бы для этого использовал то, что умеет OpenRC. Используйте наздоровье. А я не буду иметь дело с месивом костылей, где вещи которые я хочу видеть по дефолту - сильно опциональны и не гарантированы. > Я когда-то прикола ради делал аналогичный мониторинг на базе ptrace(), А это вобще жесть и афиг. И просто полкило грабель на обпрыг. > Просто OpenRC сделан так, что он легко расширяется чем угодно. ИЧСХ, месиво из местечковых костылей работать в результате будет как месиво из местечковых костылей. > не хватает обычного pstree, либо хочется перезапускать приложения при падении… Я хочу понимать, что, откуда и почему взялось в моей системе. Для меня это не опция: без этого я систему буду считать куском проблем, а не операционкой. >> Что в этом плане имеет предложить OpenRC, если уж мы о конструктиве? > Что конкретно нужно? Апи вачдога? Обработка всяких там стартов стопов и их таймаутов? Кодов возврата? Сохранение того что программы выдали куда-нибудь в логи? Человеческая смена юзерей, приоритетов, шедулеров, лимиты, CAPS, ...? И чтобы без кучи костылирования и написания вагона системного кода?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #286

283. Сообщение от Аноним (-), 25-Сен-15, 02:52	+/–
> А ты kde на сервер поставил? Нет. Зато у xaionaro вон ... видеокарты на сервере перегреваются. Вот уж у кого не надо учиться делать и админить сервера, имхо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

284. Сообщение от arisu (ok), 25-Сен-15, 07:39	+/–
> И говоря за себя - я так например как-то и не > буду гореть желать рулить сервером если там нет systemd. ну и отлично. когда системдец встанет раком по неизвестной причине — тебе хотя бы не будет скучно. а он всенепременно встанет, потому что ты волшебным образом умудряешься простые и понятные инит‐скрипты превратить в «портянки», и системдец тоже замучаешь. ты вообще иногда любитель странных решений, обычно с парадоксальной мотивацией. навроде «x11 фигня, потому что там расширения, их руками надо! а opengl хорошо, ведь там расширения, и их руками надо!»
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

285. Сообщение от arisu (ok), 25-Сен-15, 07:42	+1 +/–
> А к хорошему быстро привыкаешь... угу. к monit, например. который не пытается подмять под себя всю систему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279

286. Сообщение от arisu (ok), 25-Сен-15, 07:43	+/–
> Используйте наздоровье. А я не буду иметь дело с месивом костылей, где > вещи которые я хочу видеть по дефолту - сильно опциональны и > не гарантированы. странно. а я думал, ты используешь системдец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282

287. Сообщение от arisu (ok), 25-Сен-15, 07:48	+/–
> Ну ты то нам расскажешь, как отследить откуда взялся %s, сделавший несколько > форков, так что parent'ы вырубились и он остался с parent'ом в > виде PID=1? :) конечно. вот так, например: http://bewareofgeek.livejournal.com/2945.html я понимаю, что чтение документации — не твоё, так что получи в виде исключения, у меня сегодня пятница снисхождения к умственно отсталым.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

288. Сообщение от Andrey Mitrofanov (?), 25-Сен-15, 09:34	+/–
>> procfs на сервере нужен лишь например для "ps" или чистки xt_recent. > процессов получать каким-нибудь перебором pid'ов на предмет использования :) Ну, а чё, хиповенькко:  //и, насколько не понимаю, kill-у procfs не нужен $ kill -0 `seq 10` bash: kill: (1) - Операция не позволяется bash: kill: (2) - Операция не позволяется bash: kill: (3) - Операция не позволяется bash: kill: (4) - Нет такого процесса bash: kill: (5) - Операция не позволяется bash: kill: (6) - Нет такого процесса bash: kill: (7) - Операция не позволяется bash: kill: (8) - Операция не позволяется bash: kill: (9) - Операция не позволяется bash: kill: (10) - Операция не позволяется $ kill -0 `seq 999990 999999` bash: kill: (999990) - Нет такого процесса bash: kill: (999991) - Нет такого процесса bash: kill: (999992) - Нет такого процесса bash: kill: (999993) - Нет такого процесса bash: kill: (999994) - Нет такого процесса bash: kill: (999995) - Нет такого процесса bash: kill: (999996) - Нет такого процесса bash: kill: (999997) - Нет такого процесса bash: kill: (999998) - Нет такого процесса bash: kill: (999999) - Нет такого процесса $ _ ЗЫЖ А имя процесса на бейсике PEEK-ом/POKE-ом прямо из kmem-а парсить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #280

289. Сообщение от vi (ok), 25-Сен-15, 23:14	+/–
>> что отлично делается без cgroups, но лёне об этом никто не сказал. > Ну ты то нам расскажешь, как отследить откуда взялся %s, сделавший несколько > форков, так что parent'ы вырубились и он остался с parent'ом в > виде PID=1? :) Уважаемый Аноним! В вашей сентенции немного угадываются нотки грусти и безысходности (это, конечно же, плод моего «интересного» сознания, ну или новый вектор для обсуждения ;). Это от отсутствия доверия, к ядру ОС и программам запускаемым Вами? Постоянная слежка, она утомляет. И занимает ресурсы. (Хотя некоторые умудряются хорошо себя чувствовать даже во времена «сплошного терроризма», и это тоже интересно. Но когда же созидать? Или может хватит уже? А может пора разрушать созданное? Ну хотя бы для поддержания равновесия (чего с чем?)) Да, бывают и баги в программах. Конечно же, в некоторых случаях неплохо было бы посмотреть, что происходит. Но отсутствие доверия может измучить. К тому же, понимание происходящего, доступно очень и очень немногим (было бы лучше, если бы я ошибся ;) Если ты не можешь контролировать свои программы (на подконтрольном тебе оборудовании (а вот здесь все вообще грустно)), то «программы» (и/или оборудование) могут начать контролировать «тебя». Наверняка, при определенных обстоятельствах, можно перепрыгнуть из одной группы процессов в другую. Да и PPID наверняка тоже можно изменить. Ну например при прямом доступе к памяти (я не великий специалист в таких тонкостях). Интересно, как удивится случайный или неслучайный "родитель", своему неизвестно от куда появившемуся "отпрыску"? И что ему вообще с этим делать? Как реагировать? Если он ("родитель") об этом беспокоится, или когда нибудь вообще об этом узнает. ИМХО, программа должна выполнить только то, что требовалось. Или, если количество затраченных ресурсов и времени для нас не критично (как в прочем в данном случае и результат), то тогда «Если долго сидеть на берегу реки, то можно увидеть, как по ней проплывет труп твоего врага». (авторство автора) Или пусть тогда делает то, что ее заблагорассудится. Не важно, кто первый (или второй, вспомнил "хорошо забытое старое") придумал как организовать процессы и их взаимодействие (к примеру), важно что это придумали и реализовали. И за это, честь им и хвала! И главное, это есть сейчас и используется (с каким то там успехом).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

290. Сообщение от Аноним (-), 12-Окт-15, 11:01	+/–
В лексиконе порядочных людей вообще нет такого баззворда как "пассивная критика". Хз вообще что это значит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

291. Сообщение от Аноним (-), 12-Окт-15, 11:05	+/–
Думаю вы еще слишком незрелы чтобы понимать что такое критика и зачем она нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198

292. Сообщение от tester (??), 07-Сен-24, 17:21	+/–
> при помощи классического TI-RPC/SunRPC, без применения DBus А что есть индивидуумы которые считают что DBus использует не SunRPC?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема