31 Ответ от yars

  • yars
  • yars
  • Slacker
  • Неактивен
  • Откуда: Тамбовская область
  • Зарегистрирован: 23.03.2012
  • Сообщений: 10,043
  • Репутация : [ 309 | 1 ]

Ну да, но впоследствии он может и переменить это решение. Я про это не в курсе  bn

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

32 Ответ от Vitri (29.01.2014 02:56:02 отредактировано Vitri)

  • Vitri
  • Vitri
  • Пользователь
  • Неактивен
  • Зарегистрирован: 24.10.2011
  • Сообщений: 1,843
yars пишет:

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

А где слакварщики торчат обычно? LQ?

dyasny пишет:

Везде кроме рунета, таких криков о systemd нет, что характерно.

Настолько нет, что Леннарт ради целого рунета родил этот опус?

«Я устал, я ухожу.»

33 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
Vitri пишет:

Настолько нет, что Леннарт ради целого рунета родил этот опус?

настолько нет что Леннарт написал статью. Причем, заметь, нигде в статье нет бреда о контроле "шапочников" над вселенной и общем геноциде джедаев-праведников. Статья чисто техническая, для тех кто не понимает или сомневается.

34 Ответ от fragment

  • fragment
  • fragment
  • Пользователь
  • Неактивен
  • Откуда: тут
  • Зарегистрирован: 03.03.2012
  • Сообщений: 1,321
yars пишет:
redix пишет:

Редхат вам что то навязывает?

redix, 100500 раз уже говорили. Объединение кода udev'а с кодом systemd - это не что иное как навязывание systemd. Без вариантов.

И 100500 раз пришли к выводу, что навязывание мерещится параноикам.
И про объединение кода udev и systemd тоже всё 100500 раз разжевали.

35 Ответ от fragment

  • fragment
  • fragment
  • Пользователь
  • Неактивен
  • Откуда: тут
  • Зарегистрирован: 03.03.2012
  • Сообщений: 1,321
yars пишет:

Я себе на виртуалку хочу поставить eudev и выложить пакеты со слакбилдами. И сейчас над этим работаю.

Вы бы поосторожнее, а то вдруг Red Hat пришлёт к вам отряд своих ликвидаторов. Ведь вы подрываете их планы по порабощению Линукса.

36 Ответ от urfin

  • urfin
  • urfin
  • Портвейн 13
  • Неактивен
  • Откуда: Новосибирск
  • Зарегистрирован: 16.03.2013
  • Сообщений: 1,413
  • Репутация : [ 54 | 0 ]
yars пишет:

Объединение кода udev'а с кодом systemd - это не что иное как навязывание systemd. Без вариантов.

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

37 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
urfin пишет:

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

наконец-то голос разума

38 Ответ от lone_wolf (10.02.2014 12:58:45 отредактировано lone_wolf)

  • lone_wolf
  • lone_wolf
  • Пользователь
  • Неактивен
  • Зарегистрирован: 04.11.2010
  • Сообщений: 2,016
  • Репутация : [ 47 | 0 ]

Рич Фелкер (Rich Felker), автор системной библиотеки musl, участник проекта Openwall и член группы Austin Group, развивающей и поддерживающей стандарты POSIX, опубликовал заметку "Broken by design: systemd" с критикой systemd. По мнению Фелкера, архитектура systemd изначально является ущербной из-за интеграции в init-процесс сторонних функций, непосредственно не связанных с процессом загрузки. Подобное нагромождение негативно сказывается на надёжности и безопасности.

Фелкер выделяет три основные архитектурные проблемы systemd:

  • В Unix-системах PID 1 имеет специальное назначение, в частности, PID 1 становится родителем для осиротевших процессов и поддерживает специальную семантику сигналов. В случае краха обработчика PID 1, происходит крах всей системы (kernel panic). Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1, в то время как systemd выносит на уровень PID 1 серию демонов, реализующих вторичные функции, что приводит к общему снижению надёжности. Если традиционный init-процесс занимается лишь обработкой сигнала SIGCHLD от осиротевших процессов и реагирует на смену администратором текущего уровня запуска (runlevel), то systemd дополнительно занимается такими вещами, как управление подключением и отключением устройств, изменением точек монтирования, слежение за состоянием элементов в ФС и даже обработка запросов через DBus API.

  • В защищённой системе без systemd, обычно присутствует только один привилегированный процесс, критичный для проведения атаки, - sshd. Все остальные компоненты управляются и получают входные данные только от пользователя root. В случае systemd присутствуют каналы взаимодействия с непривилегированным пользователем. Реализация расширенных функций в systemd приводит к необходимости выполнения на привилегированном уровне лишнего кода по выделению ресурсов, обработки файлов, разбору сообщений и обработке строковых данных, что увеличивает риск возникновения уязвимостей, которые могут быть эксплуатированы непривилегированным пользователем.

  • Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.

Источник : http://www.opennet.ru/opennews/art.shtml?num=39050

Спросить - стыд минуты, не узнать - стыд всей жизни
+ yars