форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от opennews (ok) on 02-Фев-15, 23:33
Разработчики системного менеджера systemd намерены (http://www.heise.de/open/meldung/Systemd-will-Linux-Start-pe...) интегрировать в состав пакета поддержку загрузчика gummiboot (http://freedesktop.org/wiki/Software/gummiboot/) для обеспечения верификации процесса загрузки на системах с  UEFI Secure Boot. Верификация загрузки позволит гарантировать отсутствие посторонней активности во время начальной загрузки, в том числе присечь попытки запуска подконтрольных злоумышленникам приложений, внедрённых, например, для перехвата ввода паролей к зашифрованным разделам. Ранее поддержка верификации как правило ограничивалась проверкой загрузчика или верификацией загрузки ядра и связанных с ним модулей. Разработчики systemd предлагают расширить число проверяемых компонентов, дав возможность пользователю разрешить загрузку только специально подписанных системных образов начальной загрузки (initramfs). Даже получив доступ к системе атакующие не смогут внести изменения в initramfs чтобы запустить кейлоггер и перехватить ввод пароля к зашифрованному корневому разделу. Загрузчик gummiboot выбран так как он является разработкой (http://www.opennet.dev/opennews/art.shtml?num=34222) Red Hat, изначально поддерживает интеграцию с systemd и не требует (https://plus.google.com/u/0/+KaySievers/posts/GisPmPBsqfK) специальной настройки - он автоматически выявляет конфигурацию ядра и наличие на диске заверенных цифровой подписью EFI-образов и добавляет их в меню загрузки. <center><a href="http://freedesktop.org/wiki/Software/gummiboot/gummiboot-men... src="http://www.opennet.dev/opennews/pics_base/0_1422903487.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Дополнительно можно отметить публикацию (http://ma.ttias.be/whats-new-systemd-2015-edition/) тезисов выступления     Леннарта Поттеринга (Lennart Poettering) на конференции FOSDEM,  в котором он рассказал о последних тендерция в разработке systemd и планах на ближайшее будущее. Некоторые интересные выдержки из доклада: -  В systemd появится поддержка перезапуска сервисов без потери состояния - каждый демон сможе сохранять на диске своё минимальное состояние и после перезапуска восстановить исходное состояние (systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их сервису).-  Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов. Например, вместо определения правил доступа к 80 порту, можно будет привязать правила к http-серверу apache, без оглядки на то, на каком порту он принимает соединения. -  Приоритетным остаётся подход, при котором большая часть подсистем systemd, за исключением journald, не являются обязательными и могут быть отключены; -  Работа над компонентами  пространства пользователя для dbus практически завершена;-  Nspawn вырос из системы тестирования системы инициализации без необходимости перезагрузки в систему управления изолированными контейнерами, поддерживающую RAW-образы и docker-подобные контейнеры;-  Под впечатлением от концепции Solaris zone развивается machined - менеджер регистрации виртуальных машин;-  В будущем ожидается появление новых возможностей, связанных с изолированными контейнерами. В конечном счёте, целью является обеспечение работы всех инструментов systemd с оглядкой на контейнеры, например, journald может показывать как логи/сообщения основного хоста, так и всех работающих на нём контейнеров; -  В следующем выпуске  systemd появится дополнительная поддержка btrfs; -  В consoled появится поддержка экранов high DPI и Unicode;-  Утилиты systemctl-cat и systemctl-edit позволят отобразить и отредактировать файл конфигурации выбранного юнита (например, "systemctl-cat apache2.service"), без необходимости определения пути. -  Команда "ping gateway" позволит автоматически определить всех доступные сетевые интерфейсы и проверить их работу утилитой ping;-  Развитие networkd и средств для автоматической настройки сетевой конфигурации в изолированных контейнерах. Создание собственной библиотеки для работы с DHCP (dhcpv4 и dhcpv6);-  Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможность чтения сохранённых в journald логов;-  Обеспечение работы систем, не сохраняющих своё состояние (stateless). Генерация содержимого /etc и /var для таких систем. -  Возможность journald-remoting (http://www.freedesktop.org/software/systemd/man/systemd-jour...) для передачи бинарных логов на удалённый хост с использованием  HTTP  вместо протокола syslog. Поддержка в journald моделей  pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST. Поддержка данных режимов позволит существенно упросить отправку логов из различных программ, вместо поддержки syslog в которых достаточно будет отправить запрос по HTTP. -  Возможность определения минимальных пространств имён и sandbox-изоляции для сервисов, например, сделать для выбранных сервисов доступ к /usr и /home в режиме только на чтение или вообще скрыть или запретить доступ. Возможность использования отдельных директорий /tmp для определённых сервисов. Возможность ограничения доступа к файлам устройств /dev/*, с сохранением возможности работы с /dev/zero, /dev/null и т.п. -  Развитие простого ntp-клиента timesyncd (https://wiki.archlinux.org/index.php/systemd-timesyncd) в качестве минималистичной альтернативы ntpd;-  Автоматическое определение разделов GPT (GUID Partition Table) без их явного перечисления в etc/fstab; URL: http://www.heise.de/open/meldung/Systemd-will-Linux-Start-pe... Новость: http://www.opennet.dev/opennews/art.shtml?num=41592
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Sluggard (ok) on 02-Фев-15, 23:33
> Приоритетным остаётся подход, при котором большая часть подсистем systemd, за исключением journald, не являются обязательными и могут быть отключены Вопрос, сколько и чего в бинарных дистрибутивах скомпилят-включат мейнтейнеры.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 03:05
	Тем временем где-то в районе 3.19 появилась возможность проверки цифровой подписи init...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	72. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
	Сообщение от Аномсис on 03-Фев-15, 11:04
	Ответ, сколько и чего посчитают нужным, столько в бинарных дистрибутивах и скомпилят-включат мейнтейнеры.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	141. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Алгоним on 04-Фев-15, 03:38
	journald периодически создаёт проблемы (забирает себе весь CPU, блокирует переключение раздела в режим ro).
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	160. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 12:47
	> journald периодически создаёт проблемы (забирает себе весь CPU, блокирует переключение > раздела в режим ro). Ну, он же знает, что после ro уже ничего не допишешь (как же так, он же журнал (ядро пофиг) ;)
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

2. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+4 +/–
Сообщение от A.Stahl (ok) on 02-Фев-15, 23:34
>каждый демон сможе сохранять на диске своё минимальное состояние и после перезапуска восстановить исходное состояние Гм. Ну программы так обычно и работают. Или Поттеринг утверждает, что это каким-то образом будет делаться средствами systemd без модификации кода демона?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+7 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:18
	Да нет, конечно. Просто хочет чтобы вообще все демоны имели в зависимостях libsystemd
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	77. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 11:48
	если это действительно так то это полный ахтунг, если раньше ты хотел перенести функционал какого либо сетевого сервиса на систему без системд(например мобильный девайс), то тебе приходилось как минимум мучиться с кросс компиляцией, а сейчас помимо всего прочего придется руками выпиливать зивисимости от этого барахла? что скажут на это системд фаны?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	81. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:09
	> если это действительно так то это полный ахтунг, если раньше ты хотел > перенести функционал какого либо сетевого сервиса на систему без системд(например мобильный > девайс), то тебе приходилось как минимум мучиться с кросс компиляцией, а > сейчас помимо всего прочего придется руками выпиливать зивисимости от этого барахла? > что скажут на это системд фаны? Необходимо, кодить больше разных "падучих" демонов, что бы системд смог подать им руку при падении?!?!? Ну это только в том случае если оформлена подписка на "поднятие" ;)
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	121. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:19
	Библиотеку назвать libsystemd-viagra :)
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	142. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–3 +/–
	Сообщение от pavlinux (ok) on 04-Фев-15, 04:52
	> что скажут на это системд фаны? Они ничего не скажут, ибо лохи и не понимают, что и как работает.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	180. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от AlexAT (ok) on 08-Фев-15, 20:53
	--without-systemd в autoconf спасёт отцов русского ретроградства
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	74. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+4 +/–
	Сообщение от Аномсис on 03-Фев-15, 11:23
	> Ну программы так обычно и работают. Они обычно так не работают, а они обычно после перезапуска заново производят инициализацию, подключение и т.д. Здесь же каким-то образом будет сохранятся то, что необязательно вычислять заново после перезапуска и таким образом будет экономится время и ресурсы.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	99. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 13:10
	А как это будет выглядеть-то? Вот перезапущенному сервису systemd отдал кучу файловых дескрипторов — как сервис должен узнать номера этих дескрипторов, узнать что за ресурсы они обозначают, и в какой стадии работы с ними они находятся? Пример — файловый дескриптор 35 для TCP-соединения 0.0.0.0:80-x.x.x.x:12345, оттуда уже было получено 40 байт (HTTP/1.1 строка запроса и кусочек первого заголовка). Как перезапущенный сервис обо всем этом узнает — что есть открытый дескриптор 35, что он TCP-сокет, что из него пришло 40 байт, и какие именно байты?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	104. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
	Сообщение от Andrey Mitrofanov on 03-Фев-15, 13:44
	> А как это будет выглядеть-то? Что-за-истерика-ТМ? Прочитай-ложик-Б-бога-уже-R! Example 4. Store a File Descriptor in the Service Manager To store an open file descriptor in the service manager, in order to continue operation after a service restart without losing state use "FDSTORE=1": sd_pid_notify_with_fds(0, 0, "FDSTORE=1", &fd, 1); +++Пять строчек, пять переменных -- to rule th^W^W^Wдовольно с них, со всех!
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	122. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:19
	То есть если я хочу этой штукой пользоваться, мне надо при остановке засериализовать куда-то все контексты для открытых сокетов и запихнуть эти сокеты в sd_pid_notify_with_fds(), а потом при запуске разсериализовать контексты и продолжить как ни в чем не бывало. Вызывать sd_listen_fds() по желанию, чтобы проверить, все ли FD_STORE'нные сокеты были возвращены. Ну, в принципе неплохо. Надо, конечно, будет вместе с контекстами сокетов хранить изначальное окружение/настройки и потом сравнивать его с новыми, и решать, не стоит ли закрыть какой-то из восстановленных сокетов, но это и так неизбежно, если ты пишешь snapshot-able программу. С другой стороны, такие сложности редко когда оправданы.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	181. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от AlexAT (ok) on 08-Фев-15, 20:56
	> С другой стороны, такие сложности редко когда оправданы. Оправданы например с долгоживущими TCP-соединениями.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	143. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от pavlinux (ok) on 04-Фев-15, 04:56
	>> А как это будет выглядеть-то? > Что-за-истерика-ТМ? Прочитай-ложик-Б-бога-уже-R! Example 4. > Store a File Descriptor in the Service Manager Ага, а другом конце сокета тебя уже три раза нах послали, выслав TCP_RST или shutdown()
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	153. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 11:23
	А смысл-то вообще в чем? НАФИГА? Нет таких реальных ситуаций, где бы это действительно нужно было. Конфиг перечитать - все равно придется все потом переоткрывать, потому что что-то изменилось. Просто так остановить и потом снова запустить - это вообще бессмысленно само по себе и уже есть SIGSTOP/SIGCONT.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	155. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 04-Фев-15, 11:32
	> А смысл-то вообще в чем? НАФИГА? Нет таких реальных ситуаций, где бы Логр Воландепоттр сказал -- значит, нужно! Неосиляторы бьются в истерике на обочине истории, нет им места в Профессии(тм). Один Комбайн to rule 'em all, олл ёр бэйз билонг, суррендер ёр шилдз, OBEY^WSIGOBEY! > есть SIGSTOP/SIGCONT.
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	165. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 04-Фев-15, 20:31
	В теории можно вообразить службу, которая сохранит текущее состояние, перечитает конфигурацию, восстановит состояние, решит, что в нем надо исправить, чтобы оно соответствовало новым настройкам (условно говоря, какие соединения стоит оборвать, а какие могут продолжать работать), и продолжит работать как ни в чем не бывало. Делать это через "прибить процесс-изменить конфиг-запустить процесс" раньше было невозможно потому, что сетевые соединения на первом шаге умирают. Другое дело, что это действительно нахрен не надо: если вы умеете корректно накатывать новые настройки, так обрабатывайте SIGHUP. Опять же, SIGSTOP/SIGCONT - любая сетевая программа умеет обрабатывать внезапный обрыв соединения, это не проблема. Задержки из-за переподключений? Так большинство протоколов устроено так, что при резком изменении настроек одной из сторон протокол следует прервать и начать заново. Рядом в комментариях кто-то вообще шутил насчет восстановления *упавшего* сервиса, но это уж совсем — вы его восстановите (точнее, состояние из последнего снапшота), а он тут же опять упадет по той же самой причине. Ну и понту?
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	169. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 05-Фев-15, 14:50
	Если сервис падает, то каким макаром он сможет systemd передать свои файловые дескрипторы? Тут либо придется на sigsegv вешать передачу, но это чревато как раз тем самым бесконечным повтором с загрузкой сервера на 100% (да и проще сразу новую копию себя запустить из обработчика и ему напрямую - systemd-то дергать зачем?). Либо обязать ядро отдавать все дескрипторы упавших программ этому самому. Но это уже вообще за гранью добра и зла будет.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	170. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Аноним (??) on 05-Фев-15, 18:48
	Очевидно, он должен их отдавать до того, как упадет — открыл файл, дернул systemd, куда-то положил снапшот своего текущего состояния. И так на каждый чих. Такое вполне возможно, даже пара ОС такого типа была написана, но это дорого, очень дорого...
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	171. "graceful restart и его други..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 05-Фев-15, 19:14
	> Очевидно, он должен их отдавать до того, как упадет — открыл файл, > дернул systemd, куда-то положил снапшот Никакого отношения к _падению это иметь не может. И Ленарт тоже идиот. http://httpd.apache.org/docs/2.4/stopping.html#gracefulstop То же самое есть и у nginx. И у кучи других сетевых сервисов, скорее всего. +++ Только существующие соединения (=без разрывов и переподключений для клиенсов) продолжают обслуживать старые воркеры, которые больше не принимают новых соединений и _завершаются, когда клиент закончит или кто-то прибьёт их, воркеров (таймаут, килллл). Свет же наш Солнышко Ленарт предлагает, видимо, прерываться посреди отдачи файла, например, по ftp:, быренько-быренько скинуть с воркер-процесса внутреннее состояние и fd сокета клиентского соединения в тёмный и прохладный s-d, перезапустить сервис, который уже должен быть научен, отдельно от s-d, прогрессивными монтёнерами [того ftpd] и исполнить танец святого Ленарта: восстановить внутреннее состояние, взять сокет и _продолжить обслуживать клиента. Типа, "как ни в чём не бывало". И пусть у _них, тех прогрессивных ребят, голова болит про изменение конфигурации (=+ а вдруг теперь клиента и не надо обслуживать?), изменение версии сервера (=+ формата "сохранения сосотояния") и кучи прочих _плодов _с _куста ленартова. Но Ленарт не может быть обвинён ни за что -- то уже будут _не _его проблемы. By "design". +++Когда-то уже же Ленарт расскажет нам о бесшовном перезапуске икс-сервера?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	172. "lennertos и други..."	+/–
	Сообщение от Andrey Mitrofanov on 05-Фев-15, 19:24
	>> Очевидно, он должен их отдавать до того, как упадет — открыл файл, >> дернул systemd, куда-то положил снапшот > Никакого отношения к _падению это иметь не может. И Ленарт тоже идиот , который хочет http://lwn.net/Articles/434821/rss?format=printable быть Линусом??! ---Это не дирижабль, это последний выдох господина ПЖ!
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	173. "graceful restart и его други..."	+/–
	Сообщение от Аноним (??) on 05-Фев-15, 22:58
	Во-во, именно так, потому что больше ни к чему и не приделать эту фичу. Я же, собственно, какую мысль имел в голове? Что в теории-то найти этой фиче применение можно, но на практике она нафиг никому не сдалась — те проблемы, которые она может помочь решить, либо ни фига не проблемы, либо решаются уже имеющимися методами гораздо проще и яснее. Это просто "крутая фича": "Глядите, теперь сервис может сохранить файлы открытыми между перезапусками, а раньше не мог!" Вот только задаться вопросом "ну это конечно круто, а какую проблему это решает?" очевидно, руки не дошли.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	175. "graceful restart и его други..."	+/–
	Сообщение от Аноним (??) on 06-Фев-15, 12:38
	Проблему оно решает единственную - надо чтобы большое количество демонов имело бы libsystemd в зависимостях. Захват плацдарма и последующее его расширение. Человек реально уже в войну с миром "консервативных линуксоидов" играет.
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	182. "graceful restart и его други..."	+/–
	Сообщение от AlexAT (ok) on 08-Фев-15, 20:59
	> Только существующие соединения (=без разрывов и переподключений для клиенсов) продолжают > обслуживать старые воркеры, которые больше не принимают новых соединений и _завершаются, > когда клиент закончит или кто-то прибьёт их, воркеров (таймаут, килллл). В реале это приводит к тому, что на graceful restart новые соединения ВООБЩЕ не принимаются, пока не умрут все воркеры.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	185. "graceful restart и его други..."	+/–
	Сообщение от Andrey Mitrofanov on 09-Фев-15, 11:43
	> В реале это приводит к тому, что на graceful restart новые соединения > ВООБЩЕ не принимаются, пока не умрут все воркеры. Я слышал про другой "реал", где ставый мастер шлёт старым воркерам сигнал, они все откоючаются от _слушающего сокета, но не разрывают и продолжают обрабатывать ранее установленные соединения. После этого новый мастер (да, кстати, и пославший старому мастеру тот сигнал) открывает слушающий сокет, пускает воркеров, и они, кооперативом, обрабатывают новые вх.соедиения. А старые воркеры ко всему, когда старые соединения закрываются [все], "просто" завершаются. Другое дело, что и с таком виде это никому не надо, 99,99% админов довольно простого рестарта.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	186. "graceful restart и его други..."	+/–
	Сообщение от AlexAT (ok) on 09-Фев-15, 20:31
	> Я слышал про другой "реал", где ставый мастер шлёт старым воркерам сигнал, > они все откоючаются от _слушающего сокета, но не разрывают и продолжают > обрабатывать ранее установленные соединения. После этого новый мастер (да, кстати, и > пославший старому мастеру тот сигнал) открывает слушающий сокет, пускает воркеров, и > они, кооперативом, обрабатывают новые вх.соедиения. А старые воркеры ко всему, когда > старые соединения закрываются [все], "просто" завершаются. Проверил на подручной площадке (благо кластер, и выпадение одного httpd к отказу в обработке запросов не приводит xD). 2.2 и 2.4 ведут себя в точности, как я написал. А простой рестарт плох тем, что DL'ящие длинные файлы или ждущие длинного запроса клиенты получают кукиш...
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	78. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Moomintroll (ok) on 03-Фев-15, 11:49
	(systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их сервису)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	82. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:13
	> (systemd сохранит открытые сокеты и файловые дескрипторы и после перезапуска передаст их > сервису) systemd-keyd для передачи сеансовых ключей, к подключениям которые были открыты в момент падения! ;)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	123. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:26
	NSA одобряет ;)
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

3. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–4 +/–
Сообщение от MPEG LA (ok) on 02-Фев-15, 23:37
>дав возможность пользователю разрешить загрузку только специально подписанных системных образов начальной загрузки (initramfs... в котором уже лежит systemd, и если подписи недоступны, то systemd может стать невыпиливаемым на кривых UEFI и всяких лок-инах. зы. даешь UEFI с QR-кодами и веб-сервером!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Xasd (ok) on 03-Фев-15, 00:13
	> systemd может стать невыпиливаемым на кривых UEFI и всяких лок-инах. на кривых (забагованных) реализациях UEFI -- просто отключи режим Secure Boot. и не мучийся
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	24. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 03:07
	> просто отключи режим Secure Boot. и не мучийся Учитывая что там априори прописаны ключи микрософта, которому я ни разу не доверяю, потому что они подписывают своими подписями даже БОЕВЫЕ КОМПЛЕКСЫ ДЛЯ САБОТАЖА - секурность этого бута очень преувеличена, скажем так.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	27. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–8 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 04:30
	А давайте без FUD? Есть возможность их удалить (либо просто не устанавливать. Да, они есть в фирмвари, но не используются для проверки, пока не выбрать "Install default Secure Boot keys" или подобное). Обычно это рядом с пунктами по установке своих ключей. Секьюрность бута заключается исключительно в возможности проверить загружаемый код на предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено. И кстати, Microsoft *ГАРАНТИРУЕТ*, что на любой x86 системе с Secure Boot и ключами винды - даже если она была предустановлена с виндой и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft и установить свои ВМЕСТО них. Если в фирмвари нет такого пункта - материнка никогда не получит сертификации с Windows 8 и не имеет право использовать логотип. Так что не надо тут разводить панику без повода.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	41. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+11 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 08:19
	> И кстати, Microsoft *ГАРАНТИРУЕТ*, что на любой x86 системе с Secure Boot и ключами винды - даже если она была предустановлена с виндой и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft и установить свои ВМЕСТО них. Только благодаря тому, что люди во время поднимали шум. А так изначально они лоббировали исключить такую возможность.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	83. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:18
	> А давайте без FUD? > Есть возможность их удалить (либо просто не устанавливать. Да, они есть в > фирмвари, но не используются для проверки, пока не выбрать "Install default > Secure Boot keys" или подобное). Обычно это рядом с пунктами по > установке своих ключей. > Секьюрность бута заключается исключительно в возможности проверить загружаемый код на > предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено. birus-ы все исправят! Другое дело что это очень трудоемко. Но когда все унифицируют...
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	87. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:38
	> А давайте без FUD? А давайте без давайте? > Есть возможность их удалить (либо просто не устанавливать. Да, они есть в > фирмвари, но не используются для проверки, пока не выбрать "Install default > Secure Boot keys" или подобное). Обычно это рядом с пунктами по > установке своих ключей. Внимание, коронный вопрос: как мне с разумными затратами усилий проверить что блоб-онли фирмвара по факту перестала доверять всем кроме апрувнутого мной ключа? Раз уж мы про секурность... > Секьюрность бута заключается исключительно в возможности проверить загружаемый код на > предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено. Спецификацией - да. А вот если какой-то микрософт и их друзья, ну и просто хаксоры спершие ключи, смогут на моей системе запускать какое-нибудь боевое программное обеспечение, которое я совсем не заказывал - какая ж это секурити? > и ключи уже установлены - ОБЯЗАТЕЛЬНО есть возможность убрать ключи Microsoft И как мне проверить что все ключи по факту убраны и что фирмвара перестала доверять кому попало? Сорцов то нет. А дизассемблером колупать десятиметровый блобик как-то утомительно. Мне предлагается поверить на честное слово мутному многометровому блобу от штатовских проприерасин прогнувшихся под микрософт? Секурити такая секурити... > Так что не надо тут разводить панику без повода. Так это не паника, это капитанинг. Вы, простите, глупый, если готовы на честное слово верить огромному многометровому блобу без сырцов но с чужими ключами что мамой клянус, будет безопасно.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	102. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 13:36
	> Внимание, коронный вопрос: как мне с разумными затратами усилий проверить что блоб-онли > фирмвара по факту перестала доверять всем кроме апрувнутого мной ключа? Раз > уж мы про секурность... Никак. Используйте Coreboot какой-нибудь или еще что. Строго говоря, даже честная фирмварь не может знать, что ее не обманывают, если она хранит ключи в внешнем TPM-модуле - она скажет "очистить" и запишет туда ключ, а он ей потом дополнительный ключ будет доставать. А еще Computrace может некий код выполнять и что-то делать http://betanews.com/2014/08/12/computrace-back-door-could-ma.../ В общем, в страшном мире мы живем. Но это не повод валить все зло на конкретные технологии. Можете обойтись без них - рад за вас. Не можете - не надо распространять мифы, что Secure Boot это зло и там "вшита левая функциональность". Она и без него вшита в места, которые вы выключить не можете. >> Секьюрность бута заключается исключительно в возможности проверить загружаемый код на >> предмет подписи, никакой конкретики - какими ключам - спецификацией не оговорено. > Спецификацией - да. А вот если какой-то микрософт и их друзья, ну > и просто хаксоры спершие ключи, смогут на моей системе запускать какое-нибудь > боевое программное обеспечение, которое я совсем не заказывал - какая ж > это секурити? Не смогут. Не надо исходить из неверных предпосылок. Убираете ключи и левый код не запустится. (кроме того, я думаю, если MS подпишет ключами какую-нибудь малварь или допустит, что ключи своруют, будет скандал такого масштаба, что вы про это точно заранее узнаете) >> Так что не надо тут разводить панику без повода. > Так это не паника, это капитанинг. Вы, простите, глупый, если готовы на > честное слово верить огромному многометровому блобу без сырцов но с чужими > ключами что мамой клянус, будет безопасно. А вы переворачиваете ситуацию с ног на голову и вините Secure Boot как источник угроз. В то время как именно он *дает* вам возможность предотвратить запуск левого "боевого программного обеспечения". А вот без него как раз - запускай кто угодно что угодно. Я ж не предлагаю вам на 100% верить, что включение Secure Boot обезопасит вас ото всех угроз. Современный хакер вообще поставит вам какое-нибудь расширение в браузер и будет спирать оттуда ваши аккаунты и другую приватную информацию - сейчас информация = деньги (а глядишь, и номер кредитки подвернется). И плевать ему на то, что там при загрузке. Но в текущей реализации Secure Boot только может безусловно увеличить безопасность системы, ограничивая запуск кодом, подписанным MS или же админом вашей организации (по вашему желанию). Без него у вас нет такой возможности. Никаким образом его включение не может скомпрометировать безопасность по сравнению с его выключением или отсутствием - или будьте добры, приведите такой пример. А то вы разводите какие-то теории "а что если фирмварь не исключила ключ" (наверное, в MS не идиоты сидят и проверили, что функциональность работает, а не просто пункт в меню во время сертификации?). А что если фирмварь только притворяется, что грузит линукс, а на самом деле быстро грузит винду или еще что, включает виртуализацию, в ней загружает ваш линукс, а на самом деле контролирует гипервизор и секретно выполняет там и другой код, о котором вы не знаете? Это намного более вероятно, чем то, что она мухлюет с ключиками! Во всяком случае, тут хотя бы профит какой-то есть.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	109. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 14:12
	>[оверквотинг удален] > выключением или отсутствием - или будьте добры, приведите такой пример. А > то вы разводите какие-то теории "а что если фирмварь не исключила > ключ" (наверное, в MS не идиоты сидят и проверили, что функциональность > работает, а не просто пункт в меню во время сертификации?). > А что если фирмварь только притворяется, что грузит линукс, а на самом > деле быстро грузит винду или еще что, включает виртуализацию, в ней > загружает ваш линукс, а на самом деле контролирует гипервизор и секретно > выполняет там и другой код, о котором вы не знаете? Это > намного более вероятно, чем то, что она мухлюет с ключиками! Во > всяком случае, тут хотя бы профит какой-то есть. Может ли фирмварь обновится в то время как уже операционная система загружена и работает?
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	115. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 15:27
	> Может ли фирмварь обновится в то время как уже операционная система загружена > и работает? Ну "обновить прошивку" из ОС можно (тупо записывается новый код во флешку) - но я не уверен, что новый код начнет выполняться прямо сейчас, я не со следующей загрузки. UEFI также может обновлять сам себя, но опять же работает начиная со следующей загрузки.. Определенный код UEFI работает во время работы ОС - не тот, который загружает, а отдельные т.н. runtime-сервисы - например, задумывалось, что UEFI может предоставить драйверы устройств, незнакомых операционке, реализованные в виде кода для нее. Но практически ОС (как минимум винда и линукс) не обращаются к runtime-сервисам, т.к. это сложно организовать безопасно. Поэтому как-то сказать UEFI, что нужно выполнять новый залитый код или подобное не выйдет. Из http://vzimmer.blogspot.ru/2012/12/accessing-uefi-form-opera... >  The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid.   The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point.  The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999.   Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks).  Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	161. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 13:01
	>[оверквотинг удален] > UEFI также может обновлять сам себя, но опять же работает начиная со > следующей загрузки.. > Определенный код UEFI работает во время работы ОС - не тот, который > загружает, а отдельные т.н. runtime-сервисы - например, задумывалось, что UEFI может > предоставить драйверы устройств, незнакомых операционке, реализованные в виде кода для > нее. Но практически ОС (как минимум винда и линукс) не обращаются > к runtime-сервисам, т.к. это сложно организовать безопасно. Поэтому как-то сказать UEFI, > что нужно выполнять новый залитый код или подобное не выйдет. > Из http://vzimmer.blogspot.ru/2012/12/accessing-uefi-form-opera... >>  The net result is that you cannot get to the UEFI RT or the system table at OS runtime, I'm afraid.   The Linux sysfs is the closest but even there it doesn't expose each UEFI RT call point.  The reason that the UEFI variable services are exposed in the fashion they are via Win32 calls is that OS installer programs have needed them since EFI1.02 back in 1999.   Writing UEFI RT code is pretty tricky because of things like the OS owning the hardware, the virtual mapping of the firmware, etc.(i.e., tough for firmware folks).  Also, the OS guys don't necessarily trust firmware and the UEFI RT code/data isn't hardware isolated from the other OS kernel components and drivers. Это я не к тому, что бы сказать очевидную вещь, а для того что бы сказать еще более очевидную вещь: аппаратный триггер необходимо ставить. Который переключается только в одну сторону и только один раз (до следующего "аппаратного" reset-а). Фирмварь по завершению работы переключит этот триггер, и тем самым (аппаратно) снимет напряжение питания (для записи) с соответствующей ножки микрухи.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	116. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 15:48
	> Но в текущей реализации Secure Boot только может безусловно увеличить безопасность системы, ограничивая запуск кодом, подписанным MS или же админом вашей организации (по вашему желанию). Ходят слухи что админ "нашей" организации не имеет право подписать код. Это может сделать только МС. Либо это не секуребут.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	119. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 18:00
	> Ходят слухи что админ "нашей" организации не имеет право подписать код. Это может сделать только МС. Либо это не секуребут. Не надо слухов, берете signtool от MS или оупенсорсный аналог под линукс (ссылка есть ниже) и подписываете вашим ключем. Ключ записываете на флешку или любой fat32 раздел, в фирмвари выбираете "установить пользовательский ключ" и выбираете его. Включаете secure boot. MS вообще не имеют отношения к технологии Secure Boot - и ее реализация никак не завязано на существование MS. Просто была договоренность от MS с производителями материнок, что те будут поставлять ключи MS в фирмвари. Почитайте наконец секцию про Secure Boot тут https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-.../ и прекратите верить слухам.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	128. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 20:59
	> MS вообще не имеют отношения к технологии Secure Boot - и ее реализация никак не завязано на существование MS. >  Ключ записываете на флешку или любой fat32 раздел Да вааааще мс тут не при чём. Просто так fat в стандарте самозародился. Точно так же как и secureboot. И оказывается что пока ещё это разрешено делать на х86 процах. С остальным в сад. Так мс решил, в своих "рекомендациях".
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	132. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:37
	> С остальным в сад. Так мс решил, в своих "рекомендациях". А потом эти редмондские фаготы удивляются когда их НАВЯЗЧИВОГО ВТЮХИВАНИЯ какой-то там "защиты от проблем" кто-то опасается. Наверное потому что очень уж напоминает поведение крышевика ларьков, навязчиво предлагающего защиту от проблем.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	135. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 23:04
	А вы знаете ФС, более совместимую между всеми ОС, чем FAT с его 35-ти летней историей? Про "самозарождение" secure boot я даже комментировать не буду. По ссылке выше все настолько понятно разжевано (на тему что это такое, зачем нужно и как появилось), что смысла цитировать это нет. В конце концов, если ничего не помогает - почитайте оригинальную спецификацию UEFI. Она открыта.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	131. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:36
	> Почитайте наконец секцию про Secure Boot тут А еще можно почитать заметки Мэтью Гарретта как он прыгал по граблям со всем этим уефанством. Когда то установка операционки девайс убивает, то девайс готов запускать на выбор целый виндус и редхат, etc.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	130. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:34
	> Никак. Используйте Coreboot какой-нибудь или еще что. Ну вот о том и речь. Выглядит как защита, а по факту - лапша на уши. Чем и плохо, собственно. Притупляет бдительность путем навешивания лапши на уши. А потом чего доброго будет использовано для взломов. > если она хранит ключи в внешнем TPM-модуле - она скажет "очистить" > и запишет туда ключ, а он ей потом дополнительный ключ будет доставать. Поэтому TPM - еще одна порция лапши на уши. Единственный вариант когда оно может быть trusted - это если сие сделано на каком-нибудь микроконтроллере с открытой фирмварой. В остальных случаях это еще порция лапши на уши. Мало ли что там этот модуль делает и какие у него бэкдоры есть. > А еще Computrace может некий код выполнять и что-то делать Ну так бэкдор же откровенный. При том не подконтрольный толком тому лоху который его себе впендюривает. > не надо распространять мифы, что Secure Boot это зло Это зло. Потому что вешает много лапши на уши, разводя много бла-бла про какую-то там секурити, при том что эти бла-бла НИЧЕМ НЕ ПОДКРЕПЛЕНЫ. А навешивание лапши на уши лохам это зло. И гемор с загрузкой легитимных ОС - тоже. > и там "вшита левая функциональность". Она и без > него вшита в места, которые вы выключить не можете. Для начала секурбут с нахрапом втюхивается как некая защита от проблем, а по факту - больше похож на форму ларечного рэкета от MS с мутными типами которые фиг поймешь на кого работают. Какая там безопасность когда возле тебя тусует парочка мутных рэкетиров - большой вопрос. > Убираете ключи и левый код не запустится. Кто это гарантирует? Какой-то мутный многометровый проприетарный блоб, делающий невесть что? В котором по закону жанра найдут "случайно забытый инженерный ключ" или "досадную уязвимость". > (кроме того, я думаю, если MS подпишет ключами какую-нибудь малварь Они уже подписали парочку милых вещиц - stuxnet и duqu. Боевые комплексы саботажного программного обеспечения, если вы вдруг не в курсе. Ну да, все обтяпано так что микрософт вроде как не очень виноват. Но факты таковы что их валидная цифровая подпись - налеплена на боевое программное обеспечение, которое предназначено для выведения из строя инфраструктуры, промышленного шпионажа и проведения атак. > точно заранее узнаете) Так я уже в курсе про валидные подписи stuxnet и duqu. По поводу чего доверять мелкомякоти и их ключам ни разу не собираюсь. И даже тем кто интегрирует их ключи. Если кто засыпался на валидных цифровых подписях на боевой малвари - это все, пиндык доверию, особенно когда его с нахрапом навязывают на уровне дефолтных ключей UEFI. > А вы переворачиваете ситуацию с ног на голову и вините Secure Boot > как источник угроз. В такой реализации да, он - источник угроз. Потому что врет о своем функциональном предназначении и нет внятных возможностей проверить что этот мутный тип будет делать именно то что и заявлено, а не что-нибудь другое, втирая очки, отвлекая внимание и являясь скрытым плацдармом для проведения неожиданных атак. Как раз очень круто - втереть про то что может выполняться только подписанный вами код. А потом окажется что не только он, но и код тех то знает какой-нибудь небольшой секрет. Но кто ж будет это подозревать, если со всех сторон пиндят что секур, секур! Только ваши ключи, блаблабла. А возможности проверить что только наши - нет. Потому что многометровый мутный блоб. От господ, сто лет как попавшихся на вещах по типу AWARD_SW. > В то время как именно он *дает* вам возможность предотвратить запуск > левого "боевого программного обеспечения". Не, не так. Оно втирает очки что якобы дает такую возможность. А вот насколько это по факту будет именно так как обещали - фиг проверишь! Исходников же нету. А биосописателей не раз ловили на инженерных паролях и даже бэкдорах в BMC (как у супермикры). Да и микрософт активно впаривающий свои ключи отличился подписыванием боевого саботажного ПО. > А вот без него как раз - запускай кто угодно что угодно. Там по крайней мере не вешают лапшу на уши и у пользователей не формируется каких-то ложных, ничем не обоснованных ожиданий. А тут втирают очки внаглую с нахрапом про секурность. При полном отсутствии пруфов этой самой секурности. > Я ж не предлагаю вам на 100% верить, что включение Secure Boot > обезопасит вас ото всех угроз. Вы предлагаете мне верить что оно от чего-то обезопасит. Вот я и спрашиваю: а как проверить что оно себя ведет именно вот так? > Но в текущей реализации Secure Boot только может безусловно увеличить безопасность А я вижу нахрапистое втирание очков с козырянием безопасностью. А попутно - рэкет с узакониванием позиции микрософта в роли решателя того кто допущен к кормушке, много ничем не подкрепленных обещаний, проблемы с запуском легитимных операционок и прочая. И почему все это хорошо - мне совсем не очевидно. Особенно если Б. Франклина вспомнить... > образом его включение не может скомпрометировать безопасность по сравнению с его > выключением или отсутствием - Вообще-то может. Путем формирования каких-то там ожиданий, которые по факту ничем не подкреплены. Ну и результирующее ослабление бдительности всех причастных. Что позволяет проводить ВНЕЗАПНЫЕ атаки которые никто для начала не ожидает. Ну в общем еще один SSL. > или будьте добры, приведите такой пример. А что - пример? Притупление бдительности под действием сказок про секурность и как результат недооценка угроз буткитов - вполне возможны вроде.  Да и у микрософтушки появляются рычаги глобального давления на производителей железа и манипулирования рынком софта, что вообще целая глобальная угроза. > ключ" (наверное, в MS не идиoты сидят и проверили, что функциональность > работает, а не просто пункт в меню во время сертификации?). Да, duqu и stuxnet эти НеИдиoты проверили. Значит того хуже: заведомые саботажники и диверсанты будут нам про безопасность рассказывать и обеспечивать нашу безопасность. Это так круто. А так я видел как они софт и драйвера проверяют на logo. Называя вещи своими именами - никак. Формально смотрят что требоания выполнены и ... все. Поэтому все эти сертификации гроша ломаного не стоят. Чтобы кого-то там завернули - он должен настолько сказочно лохануться, что это заметят даже малокомпетентные индусы. Для этого талантище надо иметь.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	137. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Stax (ok) on 03-Фев-15, 23:26
	> Вы предлагаете мне верить что оно от чего-то обезопасит. Вот я и спрашиваю: а как проверить что оно себя ведет именно вот так? Я не вижу смысла отвечать на такой агрессивный поток сообщений об одном и том же :) Отвечу на этот "главный вопрос". Secure Boot - это спецификация, описывающая, как с помощью криптографии на открытом ключе гарантировать, что загружается только подписанный код и не запускается левого. (подписанный лично вами, для примера). Это отличная идея, отличная настолько же, насколько отличной идеей является подписывание модулей ядра в вашем дистрибутиве и подписывание пакетов дистрибутива, чтобы гарантировать, что вам их не подменили при скачивании. Спецификация - это спецификация, она по определению (да, я понимаю что бывают дыры в криптографии и тд, но не будем еще и в это углубляться) ведет себя "именно вот так". Вести себя иначе может конкретная реализация. Вы можете написать свою реализацию UEFI фирмвари, или посмотреть сорцы открытого TianoCore и убедиться, что криптография реализована корректно и что никаких левых ключей нет. Убедиться, что в абстрактной бинарной реализации UEFI все корректно вы не можете (хотя есть много оснований верить, что это так. Например, попытались загрузить левый код - получили ошибку. Подписали, вставили ключ - загружается. Так что остается разве что вариант "лишнего ключа"). Но там можно скрыть лишний код кучей других более серьезных способов. В том числе теоретически возможно и так, чтобы он выполнялся и после загрузки ОС. Поэтому я не вижу причин обвинять Secure Boot в какой-либо угрозе безопасности. Есть возможность использовать свободную фирмварь - используйте. Можно там включить Secure Boot (в TianoCore можно) - еще лучше! Безопаснее. Причины нападать на бинарную фирмварь я вижу, на Secure Boot - никакого. Это просто опциональная возможность еще в одном месте проверять код. > недооценка угроз буткитов - вполне возможны вроде Не надо недооценивать. Даже Secure Boot можно выключить в одно движение. Никакая защита не является абсолютной. Но возможность ограничить загружаемый код подписью - лучше, чем отсутствие такой возможности. Да, даже с ключами MS. Я без понятия деталей истории со stuxnet и причем там вообще MS и Secure Boot, но я знаю, что среднестатическому пользователю угрожают совсем другие вещи и другие малвари. И среднестатическая малварь не будет подписана каким-либо ключом, который есть у кого-то в фирмвари.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	157. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от user (??) on 04-Фев-15, 12:30
	Название TPM такое же ложное, как и SD.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	156. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от user (??) on 04-Фев-15, 12:28
	Только ССЗБ доверяют TPM.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	50. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от ryoken on 03-Фев-15, 09:40
	> зы. даешь UEFI с QR-кодами и веб-сервером! накаркаете...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	126. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:36
	>даешь UEFI с QR-кодами и веб-сервером! и настройками в облаках!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
Сообщение от Сергей (??) on 02-Фев-15, 23:58
Старший брат теперь будет старшим... А кто-нибудь знает, когда Леннарт собирается выпустить свой дистрибутив?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+5 +/–
	Сообщение от an (??) on 03-Фев-15, 00:48
	А зачем? Он круче. скоро все дистрибутивы будут "его". GNU/Linux плавно перетечет в Леннарт/Линукс ну или systemd/linux
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	29. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–9 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 04:52
	> А зачем? Он круче. скоро все дистрибутивы будут "его". > GNU/Linux плавно перетечет в Леннарт/Линукс > ну или systemd/linux Вы так говорите, как будто это что-то плохое!
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	51. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от an (??) on 03-Фев-15, 09:46
	в принцыпе я то не против. проблема в том что это происходит почти безальтернативно. и по живому. при том что с качеством говорят проблемы.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	66. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от ананам on 03-Фев-15, 10:40
	а говорят, что из бабки девочку сделали
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	61. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:24
	Разумеется, плохое. Когда монополия была чем-то хорошим для конечного пользователя?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	53. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:09
	В марте 2014-го обещали.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+23 +/–
Сообщение от Аноним (??) on 03-Фев-15, 00:14
>Утилиты systemctl-cat и systemctl-edit позволят отобразить и отредактировать файл конфигурации выбранного юнита (например, "systemctl-cat apache2.service"), без необходимости определения пути. Господи, спаси линукс от этого графоманствующего ламера! И да, считать cat утилитой для отображения текстовых файлов на экран - это все равно, что считать плоскогубцы девайсом для раскалывания орехов. То есть, можно, конечно, но не для этого придумывалось.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от oWeRQ (??) on 03-Фев-15, 01:45
	Странно, в man'е написано, что для вывода файлов: "cat - concatenate files and print on the standard output", да, stdout не экран, но про экран никто и не говорил, вероятно в оригинале было что-то типа "print", а не "отобразить"... Нашли к чему придраться, при таком-то списке фитч.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	30. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от tensor on 03-Фев-15, 05:26
	Фич? Вы хотели сказать "велосипедов"? Или в списке действительно есть что-то инновационное?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	136. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от freehck (ok) on 03-Фев-15, 23:14
	Всё-таки ключевое слово здесь "concatenate", а не "print".
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	148. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 04-Фев-15, 09:50
	> слово здесь "concatenate", а не "print". Не-не, Дэвид Блэйн, если Леннарт сделает _конкатенацию юнит-файлов, то они ж резко станут длиннее 5 строк. Ц.А. будет потеряна, дизайн гоул профукан. </>
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	56. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:20
	Да ладно, скоро он сделает systemctl-editd и все будет хорошо.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	73. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+8 +/–
	Сообщение от EHLO on 03-Фев-15, 11:07
	> Да ладно, скоро он сделает systemctl-editd и все будет хорошо. systemctl-regedit ты хотел сказать?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	178. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от count0krsk (ok) on 07-Фев-15, 07:59
	>> Да ладно, скоро он сделает systemctl-editd и все будет хорошо. > systemctl-regedit ты хотел сказать? Тьфу-тьфу...
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	118. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от user (??) on 03-Фев-15, 16:12
	emacsd
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

13. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–2 +/–
Сообщение от sage (??) on 03-Фев-15, 01:21
Это замечательная новость! Наконец-то замена TrustedGRUB.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	42. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 08:30
	TrustedGROB
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+12 +/–
Сообщение от Аноним (??) on 03-Фев-15, 01:26
Какое-то безумие. Если бы мне лет 10 тому назад сказали, что удар придёт именно с этой стороны..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от chinarulezzz (ok) on 03-Фев-15, 03:10
	какой такой «удар»? P.S. Насчёт безумия - согласен) шизофазия какая-то.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	179. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от count0krsk (ok) on 07-Фев-15, 08:00
	> какой такой «удар»? > P.S. Насчёт безумия - согласен) шизофазия какая-то. UEFI же. Мелкософт долго наверное думали, как поднагадить всем прочим ОС.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

19. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
Сообщение от Аноним (??) on 03-Фев-15, 02:33
Означает ли это что я смогу скомпилить свою версию systemd и подписать каким-то специальным ключом (на сколько я понимаю в этом суть UEFI Secure Boot) и это будет работать или что в составе systemd появится проприетарный закрытый загрузчик?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+5 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 04:38
	> Означает ли это что я смогу скомпилить свою версию systemd и подписать > каким-то специальным ключом (на сколько я понимаю в этом суть UEFI > Secure Boot) и это будет работать или что в составе systemd > появится проприетарный закрытый загрузчик? Да, вы сможете подписать загрузчик gummiboot своим собственным ключем, добавить этот ключ в фирмварь (в UEFI есть соответствующий пункт), и после этого данная материнка будет соглашаться грузить только этот (и другие подписанные данным ключем) загрузчики. (по секрету - вы это можете сделать и сейчас. Просто подписывать надо shim, а он будет запускать grub. С gummiboot просто упрощают цепочку - его подписываем, он же и загружает ядро. Но хозяин барин, если нужно - подписывайте сейчас. Инструменты тут: https://github.com/rhinstaller/pesign).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	90. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:45
	> материнка будет соглашаться грузить только этот (и другие подписанные данным ключем) > загрузчики. Правда проверить что это именно так - вы не сможете. Это "мамой клянус" обеспечивает многометровый проприетарный блоб. Поэтому если так окажется что блоб слегка приврал в пользу АНБ и прочих мелкософтов - будет довольно наивно удивляться. AWARD_SW мы уже видели. Ну и мастер-ключ для вламывания на любой комп смотрелся бы логично...
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	177. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от count0krsk (ok) on 07-Фев-15, 07:51
	Поддерживаю. Сколько можно заставлять сотрудников АНБ хранить потертую бумажку с паролями от всех БИОСов? Не зря UEFI так шомполом всем вендорам заталкивают.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

20. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от grec on 03-Фев-15, 02:54
Через сколько десятилетий все это начнет работать нормально?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 03-Фев-15, 03:29
Вижу столько негатива, вот только не могу понять почему? в чем причина? обосновано можно на пальцах объяснить, чтоб потом на этот пост ссылаться всегда?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+10 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 08:35
	Так плохая программа же. Никакого негатива, только заслуженное презрение.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	91. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–5 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:46
	> Вижу столько негатива, вот только не могу понять почему? в чем причина? В том что Поттеринг посмел осознать ряд проблем администрирования и постарался их разрулить. А хотя-бы и послав в пешее эротическое кучу костыльных устаревших подходов создающих проблемы, по типу скриптов sysv init.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	138. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+5 +/–
	Сообщение от freehck (ok) on 03-Фев-15, 23:41
	> Вижу столько негатива, вот только не могу понять почему? в чем причина? > обосновано можно на пальцах объяснить, чтоб потом на этот пост ссылаться > всегда? Ну, проблема в общем-то в том, что от него все устали. Устали потому что он, по мнению большого количества людей, заменяет нужные работающие вещи на не нужные и не работающие. Многие плевались на PulseAudio, когда его проталкивали. Я сам до сих пор его выпиливаю из систем, что ставлю друзьям. Почему - почитайте мои посты здесь же, небось не сложно отыскать. А теперь он написал то, что сначала планировалось как система инициализации, а теперь превратилось в таблетку ото всех болезней, и он активно пытается придать своему продукту вид хорошего востребованного поделия, чтобы на него завязывались недальновидные разработчики. Да и вообще, он больше упор делает на внедрение новых фич, нежели на отладку уже написанного кода. Вот о чём стоит подумать: окружение GNU/Linux писалось и отлаживалось десятилетия - и результатом этой работы была стабильно работающая среда. А он тут за четыре года налабал среду, в которой переписал чуть ли не всё, да к тому же навесил дополнительного функционала... Когда ему, казалось бы, всё это отлаживать? Он не делает ничего принципиально нового. Нахватался парнишка разных идей оттуда-отсюда. Наспех реализовал какие-то реализации - и теперь вовсю трубит, будто шагает впереди планеты всей. Задумайтесь: Pulse он забросил, а нам с ней теперь жить. SystemD он теперь внедряет, понимаешь ли. PS: очень устал, да и накипело
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	140. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от freehck (ok) on 03-Фев-15, 23:55
	Да кстати, хочу вдогонку сказать одну вещь. Есть два способа создать программный комплекс. В первом случае он делается настолько простым, что в нём явно нет изъянов. Во втором случае он делается настолько сложным, что в нём нет явных изъянов.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

31. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
Сообщение от Аноним (??) on 03-Фев-15, 06:09
В далёком 2007-м году, когда никаким systemd ещё даже не воняло, уже были вполне себе серьёзные загрузчики, которые могли проверять чексуммы/ключи для отдельных чанков файловой системы, и хрен ты туда подсунешь кейлоггер без физического доступа к машине. Зачем нужно было городить весь этот цирк?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	33. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 06:45
	>В далёком 2007-м году, когда никаким systemd ещё даже не воняло, уже были вполне себе серьёзные загрузчики, которые могли проверять чексуммы/ключи для отдельных чанков файловой системы, и хрен ты туда подсунешь кейлоггер без физического доступа к машине. Зачем нужно было городить весь этот цирк? NIH-синдром. RedHat хочет закрепиться в определенном сегменте рынка. Да пусть разрабатывают, главное чтобы умный народ проверенный инструментарии не выкидывали, т.к. приведет к монополии и неявному вендор-локу (да-да, можно все форкнуть, знаю..).
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	38. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 07:58
	Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	46. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 09:10
	>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО. Хм..это интересно. >Это не NIH-синдром, это результат партнёрства редхета и микрософта. А можете вот с этого места подробнее пожалуйста и с ссылками на новости/документы? - Ко мне в криокамеру не поступили эти события :(
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	71. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от ZiNk (ok) on 03-Фев-15, 10:53
	>>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО. > Хм..это интересно. >>Это не NIH-синдром, это результат партнёрства редхета и микрософта. > А можете вот с этого места подробнее пожалуйста и с ссылками на > новости/документы? - Ко мне в криокамеру не поступили эти события :( Потому что чтобы уловить эти события надо одеть шапочку из фольги для улучшения приёма сообщений из космоса и принять расширяющие создания вещества.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	139. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от freehck (ok) on 03-Фев-15, 23:45
	>>>Это не NIH-синдром, это результат партнёрства редхета и микрософта. >> А можете вот с этого места подробнее пожалуйста и с ссылками на >> новости/документы? - Ко мне в криокамеру не поступили эти события :( > Потому что чтобы уловить эти события надо одеть шапочку из фольги для > улучшения приёма сообщений из космоса и принять расширяющие создания вещества. Ха. А ты поди-опровергни его. ) Собственно, если у нас паранойя, это не означает, что за нами не следят и не стоят против нас заговоры.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	162. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 13:05
	>>Это не NIH-синдром, это результат партнёрства редхета и микрософта. По результатам редхет получает часть микрософтовых клиентов с миллиардом денег, а микрософт — свалку костылей похожую на вантуз вместо конкурирующей операционки и лающуюся свору вместо сообщества СПО. > Хм..это интересно. >>Это не NIH-синдром, это результат партнёрства редхета и микрософта. > А можете вот с этого места подробнее пожалуйста и с ссылками на > новости/документы? - Ко мне в криокамеру не поступили эти события :( можешь считать это оригинальным исследованием, выполненным на базе анализа новостей и разговоров с живыми людьми
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	48. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Какаянахренразница (ok) on 03-Фев-15, 09:34
	> это результат партнёрства редхета и микрософта. Именно так. Коротко, ясно и по существу. Между M$ и RedHat определённо существует соглашение. Обе стороны это признают (правда, не спешат делиться деталями). РедХат запускает апликухи Моно на своём ОпенШифте, Микрософт запускает RHEL на своей Азуре, RHEL единственная ОСь, подписанная ключами M$...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	70. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от ZiNk (ok) on 03-Фев-15, 10:52
	>> это результат партнёрства редхета и микрософта. > Именно так. Коротко, ясно и по существу. Между M$ и RedHat определённо > существует соглашение. Обе стороны это признают (правда, не спешат делиться деталями). > РедХат запускает апликухи Моно на своём ОпенШифте, Микрософт запускает RHEL на > своей Азуре, RHEL единственная ОСь, подписанная ключами M$... То есть RHEL - ОСь, а Ubuntu и Suse - не считаются?
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	149. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Какаянахренразница (ok) on 04-Фев-15, 10:35
	> То есть RHEL - ОСь, а Ubuntu и Suse - не считаются? А что, M$ подписала их загрузчики? Я не в курсе. Если подписала, то они тоже ОСи (в глазах M$), но ведь остаются другие...
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	150. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от ZiNk (ok) on 04-Фев-15, 10:48
	>> То есть RHEL - ОСь, а Ubuntu и Suse - не считаются? > А что, M$ подписала их загрузчики? Я не в курсе. Если подписала, > то они тоже ОСи (в глазах M$), но ведь остаются другие... То есть не в курсе, но обязательно надо теорию заговора вбросить? Ещё когда убунта покупала подпись у МС эту тему обсосали со всех сторон. Если что - загрузчики заглушки с подписью для убунты или того же RHEL (и Fedora, если уж на то пошло) имеются в открытом доступе и представляют из себя простейшую минимальную затычку для запуска grub. Но я мешать не буду, продолжайте рассказывать о том как красношляпа и МС вступили в заговор чтобы сделать linux plumbing layer более однородным^W^W поработить мир дистрибутивов.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	151. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Какаянахренразница (ok) on 04-Фев-15, 11:03
	> То есть не в курсе, но обязательно надо теорию заговора вбросить? Обязательно. А как ещё развлекаться, если не вбрасывать и не вестись на чужие вбросы? Вы слишком серьёзны, мой виртуальный собеседник. На самом деле, тот факт, что ещё кто-то прогнулся под Микрософт, никак не опровергает гипотезу о сговоре. Микрософт является врагом опенсорса и всё, к чему она прикасается, нечисто.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	152. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от ZiNk (ok) on 04-Фев-15, 11:06
	>> То есть не в курсе, но обязательно надо теорию заговора вбросить? > Обязательно. А как ещё развлекаться, если не вбрасывать и не вестись на > чужие вбросы? Вы слишком серьёзны, мой виртуальный собеседник. Вбрасывать тоже можно по-разному. Вкидывать дезинформацию - засорять ресурс. Вкидывать критику по существу - провоцировать интересные срачики.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	167. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 05-Фев-15, 10:46
	согласен на 100 %
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	79. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Аномсис on 03-Фев-15, 11:50
	Если это действительно было, значит это и есть до сих пор, только почему ментейнеры выбирают systemd, а не эти крутые программы, которые уже давно есть ? Ответ прост -- им намного легче поставить systemd и не мучиться, и не искать все эти программы по разным углам, налаживать их совместную работу между собой с помощью скриптов и постоянно самостоятельно это всё поддерживать в работоспособном состоянии. systemd можно рассматривать как комплекс утилит, где его создатели несут ответственность, как за работу каждой утилиты в отдельности, так и за связь их между собой. Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd всё сильно облегчит, идея systemd -- чтобы всё работало сразу из коробки.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	84. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+4 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:25
	Недавно было интервью с Солнцеликим, где Он сказал о системде: >it's the job of the distro to pick a release, integrate it into their OS, stabilize it when it is needed То есть, с точки зрения мейнтейнеров "поставить и не мучиться", "не налаживать и не поддерживать" не получится. Поживем - увидим, конечно, но что-то мне подсказывает, что кое-кого ждет большое разочарование в этом плане. >systemd можно рассматривать как комплекс утилит, где его создатели несут ответственность Ну-ну. Лицензию почитайте. Ответственность они несут, лол. >Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd всё сильно облегчит, идея systemd -- чтобы всё работало сразу из коробки. С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет. Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	96. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:57
	>С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет. systemd создает очень хреновую проблему - если что-то валится, то просто на коленке во время обеда систему поднять не получится >Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше? мне приходилось, правда я не совсем обычный пользователь: и в ядрах приходилось копаться (почти всегда из-за драйверов), а сейчас например у меня X11 пропатчен (нужны были доп. опции для старта).
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	100. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аномсис on 03-Фев-15, 13:12
	> То есть, с точки зрения мейнтейнеров "поставить и не мучиться", "не налаживать и не поддерживать" не получится. Поживем - увидим, конечно, но что-то мне подсказывает, что кое-кого ждет большое разочарование в этом плане. Согласен, что ещё не доделано, но его ведь развивают постоянно, не известно, что будет в будущем. "Ну-ну. Лицензию почитайте. Ответственность они несут, лол." Про ответственность я имел ввиду другое. Конечно я понимаю, что в СПО никто и никому ничего не должен, значит и нет ответственности, но я главным образом подразумевал то, что любые ошибки пытаются исправить, если в остальных проектах их авторы исправляют ошибки только самих программ и развивают эти программы, то тут всё развивается в комплексе -- все утилиты развиваются одновременно и с учётом зависимостей между ними, любые несостыковки должно исправлять сообщество systemd, все результаты тестируются тоже совместно в результате качество продукта повышается. Вообщем про ответственность может быть я не правильно выразился. "С точки зрения пользователя все и так работало из коробки уже много лет, системда тут ничего нового не принесет. Или у вас есть офигительная история, как вам приходилось ковырять инит-скрипт на баше?" Ну я главным образом сказал о системе в целом. Из коробки работает не всё и конечно у меня есть такие истории, например, на моей ноутбучной видеокарте(nvidia) не работал OpenCL и и мне пришлось вручную всё настраивать. Сами же Nvidia жаловались на недоработки в Линукс системах из-за которых у них возникают трудности в развитии всяких технологий. Я так понимаю, что EGL им облегчит жизнь, который придёт вместе с Wayland`ом и Mir`ом. Но если Wayland и Mir наводят порядок в одной сфере, то systemd в другой. Например у меня были проблемы - после обновления дистрибутива некоторые функции переставали работать и приходилось заново настраивать и вот продуманная система юнитов в systemd должна решить такие проблемы обновления(ну или часть их). У меня ещё есть притензии к стабильности некоторых моментов, но они скорее всего не относятся к systemd. Это например то, что надо сделать транзакционное обновление системы, чтобы сбой не смог всё запороть, а то у меня было так, после чего компьютер вообще перестал загружаться и пришлось самому вручную переустанавливать(обновлять). А вообще в целом у меня всё работает хорошо, но читая чужие комментарии, вижу, что кто-то постоянно в чём-то там ковыряется, у одного одно не работает, у другого - другое и т.д. И вот они все всё это настраивают своими руками.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	112. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 14:27
	>я главным образом подразумевал то, что любые ошибки пытаются исправить, если в остальных проектах их авторы исправляют ошибки только самих программ и развивают эти программы, то тут всё развивается в комплексе Тавтология какая-то. Ну да, авторы программы исправляют свои ошибки, по отношению к системде это утверждение тоже справедливо*. Ну и что с того? *на самом деле, не совсем: помните, тот эпичный патч с командной строкой ядра и debug от сиверса? >второй абзац К чему все это? Причем здесь системд? >А вообще в целом у меня всё работает хорошо, но читая чужие комментарии, вижу, что кто-то постоянно в чём-то там ковыряется, у одного одно не работает, у другого - другое и т.д. И вот они все всё это настраивают своими руками. В высшей степени наивно полагать, что системда что-то здесь изменит. Ну не существует золотой пилюли от всех болезней сразу.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	85. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:27
	> Вообще у Линукса такая репутация, что в нём постоянно надо ковыряться, чтобы > что-то наладить, чтобы исправлять какие-то ошибки, чтобы заставить что-то работать. systemd > всё сильно облегчит, идея systemd -- чтобы всё работало сразу из > коробки. Где профитЪ?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

34. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Fracta1L (ok) on 03-Фев-15, 06:47
> Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов отлично
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
Сообщение от Ананас on 03-Фев-15, 07:17
> Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможности чтения сохранённых в journald логов; Теперь он будет изобретать собственный греп по бинарным логам. Они же теперь бинарные, а надо же как-то ими пользоваться.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:22
	Да, grepd всем нам не хватает. И еще awkd и sedd.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	69. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от ZiNk (ok) on 03-Фев-15, 10:47
	>> Создание средств для проведения системного аудита, например, для ведения полного лога системных вызовов, связанных с /etc/passwd. Добавление средств аудита в journald и реализация в audit-tools возможности чтения сохранённых в journald логов; > Теперь он будет изобретать собственный греп по бинарным логам. Они же теперь > бинарные, а надо же как-то ими пользоваться. Вот только бинарныая в логах только метадата, по логфайлам так же отработает и grep и awk и sed. Но разбираться в теме сейчас не модно, сейчас модно повторять что-то где-то услышанное, причём чем меньше знаешь о сабже критики, тем лучше.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

37. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от PavelR (??) on 03-Фев-15, 07:57
>Ожидается минимальная поддержка средств управления межсетевым экраном в привязке >к сервисам, а не номерам портов. Например, вместо определения правил доступа к >80 порту, можно будет привязать правила к http-серверу apache, без оглядки на >то, на каком порту он принимает соединения. Из процесса апача с mod_perl / mod_php / троянским so-модулем форкнется какой-нибудь "потомок", откроет свой сокет - и ему sysD  тут же порт в файрволле откроет? Вот это сервис! Классно придумали.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	86. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:33
	>>Ожидается минимальная поддержка средств управления межсетевым экраном в привязке >>к сервисам, а не номерам портов. Например, вместо определения правил доступа к >>80 порту, можно будет привязать правила к http-серверу apache, без оглядки на >>то, на каком порту он принимает соединения. > Из процесса апача с mod_perl / mod_php / троянским so-модулем форкнется какой-нибудь > "потомок", откроет свой сокет - и ему sysD  тут же > порт в файрволле откроет? Вот это сервис! Классно придумали. Может там прописывать возможный порт, или диапазон портов в конфигурилке необходимо. Все равно не вижу необходимости. Уже сейчас можно iptables настроить в привязке к процессу (подробностей не помню, пока нет необходимости). Ну разве что "типичные" настройки давать всем. А там кто сам подправит, а кому то придется в RedHat обратится за помощью ;)
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

39. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
Сообщение от Аноним (??) on 03-Фев-15, 08:05
> Ожидается минимальная поддержка средств управления межсетевым экраном в привязке к сервисам, а не номерам портов. Например, вместо определения правил доступа к 80 порту, можно будет привязать правила к http-серверу apache, без оглядки на то, на каком порту он принимает соединения. Админы поколения MTV нынче и так тупые донельзя, а теперь от них и вовсе OSI скроют (а точнее ее частный случай - TCP/IP)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Во всех постах о systmd "	–1 +/–
Сообщение от Аноним (??) on 03-Фев-15, 08:05
Сборище хейтеров и неосиляторов
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Во всех постах о systmd "	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 08:37
	Ты какой-то слишком агрессивный. Поменьше агрессии и негатива, плиз.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	59. "Во всех постах о systmd "	+2 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:23
	Ну, это скорее леннартовские неосиляторы не сумели настроить файрволл и научиться читать текстовые логи.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

45. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
Сообщение от Аноним (??) on 03-Фев-15, 09:03
/itt белки истерички.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

47. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
Сообщение от Аноним (??) on 03-Фев-15, 09:22
да прибудет тот день когда тыщи дистров начнут отличаться только картинкой десктопа! вангую чтобы поц после системды взялся за единый пакет манагер!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	52. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от ssh (ok) on 03-Фев-15, 09:58
	Packaged. omen!
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	57. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от twilight (ok) on 03-Фев-15, 10:20
	systemd-packaged, блджад
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	125. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:34
	>тыщи дистров начнут отличаться только картинкой десктопа! Да Поцтер тут не первый, много их уже. Первым был Попов?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

49. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Engineer (??) on 03-Фев-15, 09:34
Сплошные контейнеры и изолированные среды, а чем тогда будет ОС заниматься - только запуском systemd?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:24
	И еще бэкдоров АНБ.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	158. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от user (??) on 04-Фев-15, 12:33
	Наоборот, ОС будет в виртуалке под софтом от АНБ.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

62. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–2 +/–
Сообщение от Нанобот (ok) on 03-Фев-15, 10:27
systemd теперь будет загружать UEFI-биос как одну из своих подсистем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Andrey Mitrofanov on 03-Фев-15, 10:41
	> systemd теперь будет загружать UEFI-биос как одну из своих подсистем? Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	89. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:43
	>> systemd теперь будет загружать UEFI-биос как одну из своих подсистем? > Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает. Ну так ничего удивительного, каждый одеяло на себя тянет. И RH здесь не исключение. Другое дело, что "осадочек" то накапливается.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	101. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от EHLO on 03-Фев-15, 13:18
	>>> systemd теперь будет загружать UEFI-биос как одну из своих подсистем? >> Вы не понимаете, оно сжирает linux-инфраструктуру, Майкрософт оно не трогает. > Ну так ничего удивительного, каждый одеяло на себя тянет. И RH здесь > не исключение. > Другое дело, что "осадочек" то накапливается. Red Hat против Линукса? Удивительного ничего нет. Хорошего еще меньше.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

63. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+7 +/–
Сообщение от Аноним (??) on 03-Фев-15, 10:29
Меня одного смутило упоминание high dpi экранов при рассказе о возможностях системы инициализации? И где тогда поддержка HTML5?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	64. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:33
	После включения поддержки high-DPI мышек в systemd - это уже не так шокирует.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	68. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–2 +/–
	Сообщение от ZiNk (ok) on 03-Фев-15, 10:45
	В udev. Но это уже звучит не так интересно, да?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	76. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 11:48
	udev - часть systemd
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	94. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:50
	> udev - часть systemd Надеюсь что это будет именно так и вам придется съесть этот факт.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	124. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+3 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:31
	У нас уже есть рабочий eudev - равноценная замена udev и без systemd.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	133. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:42
	> У нас уже есть рабочий eudev - равноценная замена udev и без systemd. Ну вот и скатертью дорожка к этим гентушным пЫонерам.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	147. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 04-Фев-15, 08:21
	С лета использую eudev на всех системах. Полёт нормальный!
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	107. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Mihail Zenkov (ok) on 03-Фев-15, 14:09
	Какое отношение имеет udev к dpi у мышки? ИМХО кроме драйвера мыши и программы ее использующей это никого касаться не должно.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	110. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 03-Фев-15, 14:15
	> Какое отношение имеет udev к dpi у мышки? ИМХО кроме драйвера мыши > и программы ее использующей это никого касаться не должно. Ну, мышевозилам http://who-t.blogspot.ru/2014/12/building-a-dpi-database-for... не достат плюгнплюя в мышых, они подпирают сей недостаток переписью мышей. И кто же, как не ude^Wlibsystemd-mouse-hwdb -- именно то место, куда надо сложить добытое непосильным трудом?!
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	65. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 10:34
	Тс-с-с-с, тебя сейчас хейтером и неосилятором обзовут.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	105. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Stax (ok) on 03-Фев-15, 13:46
	> Меня одного смутило упоминание high dpi экранов при рассказе о возможностях системы > инициализации? И где тогда поддержка HTML5? Там есть реализация консоли в пространстве пользователя http://www.opennet.dev/opennews/art.shtml?num=38543 Это позволяет теперь поддержать удобную консоль даже на high dpi устройствах (сейчас оно по факту неюзабельно, т.к. возможности ядра по рендерингу шрифтов сильно ограничены и усложнять код в ядре никто не собирается). Поддержка HTML5 - это ваши фантазии :) Требуйте это от lynx вместо systemd! И будет поддержка в этой консоли.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

75. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 03-Фев-15, 11:25
Всё это так вкусно, что аж слюнки текут. Молодцы разработчики, скорее бы всё это реализовали. А там и до микроядра недалеко.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

80. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
Сообщение от Аноним (??) on 03-Фев-15, 11:55
Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты, отдает их systemd, а потом принимает обратно? Mysql приостановить на пару минут и потом снова запустить? Соединения все позакрываются по таймаутам. Текстовый редактор приостановить, а потом продолжить редактирование? Так уже есть CTRL-Z, да и заново открыть несколько текстовых файлов - доли секунды.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	88. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–2 +/–
	Сообщение от Eucalyptus on 03-Фев-15, 12:41
	Админишь локалхост?
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	93. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:49
	Да нет, поэтому и не понимаю. В энтерпрайзе это вообще какой-то бред. Там если сервисы запустят, то они работают, пока конфигурацию не поменяют. А для изменения конфигурации все равно нужно все закрывать и переоткрывать.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	92. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:49
	> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально это требует нефиговой поддержки в коде сервера, но если системный стартер подыграет - авторам сервера не придется кодить кучу не совсем простой логики, которая без такой поддержки со стороны системы делается только изрядным местечковым костылем.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	95. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 12:51
	>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? > Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально > это требует нефиговой поддержки в коде сервера, но если системный стартер > подыграет - авторам сервера не придется кодить кучу не совсем простой > логики, которая без такой поддержки со стороны системы делается только изрядным > местечковым костылем. Что есть "рестарт сервера"? Просто на ровном месте все перезапустить - это к чему? Конфигурация если поменялась, то в подавляющем количестве случаев - нужно все переоткрывать все равно.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	98. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 13:06
	>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? > Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально > это требует нефиговой поддержки в коде сервера, но если системный стартер > подыграет - авторам сервера не придется кодить кучу не совсем простой > логики, которая без такой поддержки со стороны системы делается только изрядным > местечковым костылем. libd-systemd
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	103. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от EHLO on 03-Фев-15, 13:37
	>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? > Ну вот так - сделать рестарт сервера без сброса пользователей, например. Реально > это требует нефиговой поддержки в коде сервера, но если системный стартер > подыграет - авторам сервера не придется кодить кучу не совсем простой > логики, которая без такой поддержки со стороны системы делается только изрядным > местечковым костылем. Смысл придумай. Там где нужно, оно и так перезапускается естественным путем. Пример sshd перезапускается без прибивания дочерних процессов. И никаких костылей и у Поттеринга разрешения спрашивать не надо.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	106. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 14:03
	Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти? А не парься, просто сбрось текущие данные на диск и перезапустись через системд. Авось память освободится.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	111. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от EHLO on 03-Фев-15, 14:21
	> Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти? > А не парься, просто сбрось текущие данные на диск и перезапустись > через системд. Авось память освободится. systemd в роли garbage collector? А ведь ты прав в некотором смысле.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	184. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от AlexAT (ok) on 08-Фев-15, 21:10
	> Все что сумел придумать - поощрение криворуких программеров. В демоне утечка памяти? > А не парься, просто сбрось текущие данные на диск и перезапустись > через системд. Авось память освободится. В реальной жизни мемликов реально полно (да, программисты тоже люди), и рестартить сервис даже при обновлении бывает очень накладно. Так что эта тема действительно имеет право на жизнь.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	97. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 03-Фев-15, 12:58
	> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? > Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты, > отдает их systemd, а потом принимает обратно? systemd-init(pid 1) слинкован с кучей хдама, начиная от glibc и заканчивая... , ну, скажем полуэкт. Реалистичненько: перезапуск pid-1 без перезагрузки! Сервис!!
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	113. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
	Сообщение от EHLO on 03-Фев-15, 14:45
	>> Кто-нибудь может описать реалистичное применение этого идиотизма с перезагрузкой без перезагрузки? >> Как можно использовать эту фигню, которая оставляет открытыми файлы и сокеты, >> отдает их systemd, а потом принимает обратно? > systemd-init(pid 1) слинкован с кучей хдама, начиная от glibc и заканчивая... , > ну, скажем полуэкт. Реалистичненько: перезапуск pid-1 без перезагрузки! Сервис!! В смысле systemd подержит сокеты в то время как systemd перезапускается? А systemd-singularityd Леннарт уже написал, новость была?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	134. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:43
	> systemd-singularityd Леннарт уже написал, новость была? Еще нет, но мы работаем над этим.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

117. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 03-Фев-15, 16:08
В systemd есть опция при компиляции которая скомпилирует только udev?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

120. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от klalafuda on 03-Фев-15, 19:17
Я таки одно не понимаю - почему ядро все ещё не часть systemd? Это явное упущение.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	127. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 19:54
	Очевидно потому что Поттеринг переписывает все с нуля, повторяя функционал существующих инструментов. Дак вот чтобы сделать ядро частью systemd, его надо написать с нуля (NIH-синдром же). А написать ядро аналогичное Линукс у Поттера с его то квалификацией и 10 жизней не хватит.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	129. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
	Сообщение от Аноним (??) on 03-Фев-15, 21:20
	> Очевидно потому что Поттеринг переписывает все с нуля, повторяя функционал существующих > инструментов. Дак вот чтобы сделать ядро частью systemd, его надо написать > с нуля (NIH-синдром же). А написать ядро аналогичное Линукс у Поттера > с его то квалификацией и 10 жизней не хватит. Более того systemd завязан на специфичных функциях glibc, и вообзе жаль что эта бездна поглотила udev
	Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

144. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
Сообщение от Аноним (??) on 04-Фев-15, 06:13
а Таненбаум че на это коментирует, годно не годно?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	159. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
	Сообщение от user (??) on 04-Фев-15, 12:35
	Он пока что не может вертеться в гробу.
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

145. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 04-Фев-15, 06:13
а то какая то шняга непонятная уже
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

146. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 04-Фев-15, 08:18
Было -бы очень смешно если бы небыло всё так печально. Взяли бы своё ядро написали и отстали наконец от Линукса и Линкус дистров.. Но нет, засовывают зонд не только в глубь но и ворочят им в разные стороны...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	163. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+2 +/–
	Сообщение от Аноним (??) on 04-Фев-15, 15:19
	Поттеринг - просто проект АНБ по запихиванию в линукс новых закладок и их унификации через один большой блоб. Старые уже многие поотлавливали, а объяснять зачем нужны еще тысячи вариантов TCP и SSL, да еще сотням создателей разных дистрибутивов - становится все сложнее. Редхат подкармливают деньгами через выгодные контракты от своих фирм, те платят поттерингам и гномостроителям всяким, чтобы те друг на друга вязались все больше, заодно подсаживая всех остальных.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

154. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 04-Фев-15, 11:25
Поттеринг никогда не читал man signal и не в курсе, что есть SIGSTOP/SIGTSTP. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

164. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от СвидетельЛинуксАпокалипсиса on 04-Фев-15, 19:21
Как долго я ждал этого события! До завершения осталось следующее. Убрать устаревшую и вызывающую проблемы безопасности возможность вызова из systemd скриптов инициализации. Поместить пользователя в виртуализованное, безопасное для системы окружение, предоставив ему права просителя у systemd. В рамках обеспечения безопасности потребовать RedHat-у исключения возможности регистрации левых ключей в UEFI Secure boot. Что не должно вызвать такого возмущения как с MS по поводу монополизации рынка ПК. Ведь теперь вы можете поставить не только единственную ОС MS Windows, но так же Linux! Пускай даже если это единственный RH. (Кто еще претендует на тарелку с борщем?) В результате каждый пользователь сможет сделать свободный выбор: поставить платную хорошую версию проприетарного продукта (будь то MS Windows или даже, ура, Linux-RedHat), или поставить диструбутив из гуманитарной помощи (например всеми уважаемый CentOS или несущий просвещение ScientificLinux). Ведь обеспечение всеобщей безопасности должно достигаться безоговорочными превентивными мерами, упреждающими нападки хакеров на драгоценные фоточки пользователя. Ой, да о чем я! Это всего лишь шаг к светлому будущему, где нет места проблемам людей со взаимодействием с лично-собственническим компьютером. Зачем разделять мировую вычислительную массу на неэффективные ящички, отражающих разве что финансовое благополучие некоторых личностей. Каждый человек сможет получить столько терминалов доступа в мировые облака, насколько хватит креативности его мЫшленья. Кто должен задумываться о том под какой ОС работает его холодильник, микроволновка, утюг и терминал доступа! Даешь развитие равенства, присущее браузерам, в вычислительные средства!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

166. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 05-Фев-15, 06:08
Ядро ! когда они уже добавят в системД ЯДРО !!!! и будет Windows 2 прийдёт майкософт и скажет, извините но этот мальчик работает на нас и всё это наше ! а ваш Линукс - маст дай !!!  гоните бабло !
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

168. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+1 +/–
Сообщение от Andrey Mitrofanov on 05-Фев-15, 10:56
> Разработчики системного менеджера systemd намерены > Разработчики systemd предлагают расширить >он рассказал о последних тендерция в разработке systemd и >  -  Приоритетным остаётся подход, при котором большая часть подсистем systemd, >Под впечатлением от концепции Solaris >целью является обеспечение работы всех инструментов systemd с Последние директивы: Спасибо лично товарищу Потерингу за 64-бита, звук и USB!!!1 -- http://www.phoronix.com/scan.php?page=news_item&px=GNU-Hurd-...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

174. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	+/–
Сообщение от Аноним (??) on 06-Фев-15, 09:51
https://twitter.com/samhocevar/status/562408610182230016/pho...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

176. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
Сообщение от count0krsk (ok) on 07-Фев-15, 07:46
Ждём новость "В системд включен minix. Ну так, чисто поржать, и для тех кто хочет unix без systemd, а то задрали орать".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

183. "Добавление в systemd загрузчика для UEFI Secure Boot и други..."	–1 +/–
Сообщение от AlexAT (ok) on 08-Фев-15, 21:05
Я, кажется, знаю, что получится, когда к systemd наконец прикрутят оконный GUI :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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