После почти пяти месяцев разработки Леннарт Поттеринг (Lennart Poettering) представил (http://lists.freedesktop.org/archives/systemd-devel/2014-Feb...) релиз системного менеджера systemd 209 (http://www.freedesktop.org/software/systemd/), примечательный обеспечением полноценной поддержки kdbus, включением в состав нового компонента systemd-networkd для настройки параметров сети, большим числом новых опций и API. Новый выпуск ориентирован в первую очередь на наращивание функциональности и содержит большую порцию нового кода, поэтому он требует дополнительной стабилизации и не рекомендуется для включения в состав веток дистрибутивов с длительным временем поддержки. В ближайшее время с интервалом в несколько недель планируется выпустить несколько корректирующих выпусков, устраняющих выявленные проблемы.
Systemd сочетает в себе функции системы инициализации, механизм для контроля за выполнением фоновых процессов, службу для журналирования событий и средства для управления сервисами, сеансами пользователей и подключаемыми устройствами. Для определения параметров сервисов в Systemd используется набор конфигурационных unit-файлов, вместо оформления сценариев запуска в виде shell-скриптов. Система (http://www.opennet.me/opennews/art.shtml?num=26447) нацелена (http://www.opennet.me/opennews/art.shtml?num=27218) на интенсивную параллелизацию выполнения сервисов на этапе загрузки системы, вобрав в себя лучшие черты таких систем, как launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, старые версии Fedora). В настоящее время на использование systemd уже перешли такие дистрибутивы, как Fedora, openSUSE, Mandriva и Arch Linux, одобрен переход на systemd дистрибутивов Debian и Ubuntu.Основные улучшения:
- Полноценная поддержка работы с использованием сервиса kdbus (http://www.opennet.me/opennews/art.shtml?num=36067), реализованного на уровне ядра и не требующего запуска традиционного демона DBus, выполняемого на уровне пользователя. Для работы задействована новая библиотека sd-bus с реализацией универсальной прослойки для организации обмена сообщениями, способной работать как поверх kdbus, так и с использованием DBus. Библиотека libdbus исключена из числа обязательных зависимостей.
Поддержка kdbus интегрирована непосредственно в процесс, обслуживающий PID 1. При включении работы с использованием kdbus появляется поддержка нового типа юнитов ".busname", которые позволяют использовать технику активации по запросу с шины kdbus (запуск обработчика при поступлении связанного с ним имени шины), работающую по аналогии с юнитами .socket" (активация по сокету). Для преобразования классических файлов с параметрами активации по шине dbus1 в юниты .busname и .service добавлен специальный конвертер. Для включения работы с использованием kdbus требуется сборка systemd с опцией "--enable-kdbus". Поддержка классического DBus сохранена и пока остаётся рекомендованной по умолчанию.
Напомним, что в рамках проекта Kdbus развивается надёжная, быстрая и безопасная система обмена сообщениями, поддерживающая доставку сообщений как в мультикаст-режиме (от одного отправителя к группе получателей), так и в режиме точка-точка. Функциональность Kdbus выходит за рамки DBus, но позволяет создать реализации DBus поверх рассматриваемой подсистемы ядра, не требующие запуска в пространстве пользователя отдельного демона D-Bus. Kdbus пока не входит в состав основного ядра Linux и ожидается не раньше ядра 3.15. Для тестирования рекоендуется использовать свежий срез git-репозитория (https://github.com/gregkh/kdbus) kdbus.
- Новый компонент "systemd-networkd", предназначенный для унификации компонентов дистрибутивов, используемых для настройки параметров сети (скрипты /etc/network, /etc/sysconfig/network, /etc/sysconfig/network-scripts/ifcfg-* и т.п.). Сервис systemd-networkd реализован в форме фонового процесса и может выполняться параллельно с традиционными скриптами и демонами настройки сети. Настройка systemd-networkd производится через создание файлов конфигурации /etc/systemd/network/*.network.
Из поддерживаемых в настоящее время возможностей отмечаются средства для настройки VLAN, агрегирования интерфейсов (bonding) и сетевых мостов. Поддерживается настройка параметров локальных сетевых интерфейсов как через статические правила, так и через DHCP. Средства для интеграции с интерактивными конфигураторами сети относятся к планам на будущее, поэтому область использования "systemd-networkd" пока ограничена настройкой сети для initrd, контейнеров, встраиваемых систем и серверов.
При выборе файла конфигурации для текущего устройства используется логика сходная с выбором ".link"-файлов, при которой осуществляется линейный разбор файлов в алфавитном порядке и применение первого подходящего условиям файла конфигурации. В отличие от файлов ".link", для категории ".network" доступна возможность сопоставления по именам сетевых интерфейсов, учёта состояния линка и привязки обработчиков горячего подключения интерфейсов по маске. Например, можно обойтись одним конфигурационным блоком для автоматического добавления в сетевой мост всех имеющихся Ethernet-интерфейсов.
Пример файла конфигурации:
<font color="#461b7e">
[Match]
MACAddress=
Path=
Driver=
Type=
Name=[Network]
Description=[IP]
Gateway=192.168.1.1
Address=label at 192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64<font color="#461b7e">
</font>
</font>
- Ранее разрозненные компоненты libsystemd-journal.so, libsystemd-id128.so, libsystemd-login и libsystemd-daemon объединены в одну общую библиотеку libsystemd.so, что позволило заметно сократить дублирование кода в разных частях systemd и избавиться от цикличных зависимостей. На уровне экспортируемых символов новая библиотека полностью соответствует старым библиотекам. При указании опции "--enable-compat-libs" предусмотрена возможность сборки заглушек, транслирующих старые библиотечные вызовы в libsystemd.so.- Добавлена новая программа "systemd-socket-proxyd", которую можно использовать в качестве двунаправленного прокси для TCP-сокетов. В частности, программа будет полезна для обеспечения поддержки активации по сокету в сервисах, которые сами по себе не предусматривают возможность такой активации, в том числе для запуска виртуальных машин.
URL: http://lists.freedesktop.org/archives/systemd-devel/2014-Feb...
Новость: http://www.opennet.me/opennews/art.shtml?num=39135
а Gentoo до сих пор использует форк?
форк чего?
Вероятно, имелся в виду systemd-free eudev
тогда отвечу.
В gentoo можно использовать sys-fs/udev, sys-apps/systemd (собранный с флагом gudev), sys-fs/eudev и sys-apps/busybox (собранный с флагом mdev).
В общем выбор довольно широкий.
спасибо
А лучше всего использовать mknod.
>А лучше всего использовать mknod.но зачем? devtmpfs сама уже давно создает файлы устройств. Udev другим занимается.
Если ядро с devtmpfs собрано, то да.
А если нет - то нет.
mknod ничем не хуже - только меньше лишней автоматики
Если система, не работает без mknod/udev/systemd ... и прочей PNP-куеты
- у вас куёвое железо, кривая система, и руки из жопы. :)И вообще, ГРАМОТНЫЙ АДМИН НЕ РАЗБИРАЕТСЯ В СИСТЕМАХ ИНИЦИАЛИЗАЦИИ.
Вот я Upstart так и не попробовал, а он уже умер. :)
>mknod
>PNP-куетыВаша точка зрения понятна.
>ГРАМОТНЫЙ АДМИН НЕ
> Вот я Upstart так и не попробовал, а он уже умер. :)С "модными" ребятами из гнезда ленартова, _админы ещё имеют все шансы вспомнить _разрабов Upstart добрым словом. Посмотрим, как оно будет, когда и если _придётся разбираться в сортах поттерова продукта.
Оно что, скоро съест NetworkManager?
Хорошо, если ядро не съест:(
:)))
> Оно что, скоро съест NetworkManager?надеюсь что съест. более унылой говяшки не найти. может в системд будет нормальная реализация
systemd подготавливает "большого брата". Как LocalSystem в масдае.
Как Google Play Services в андроиде.
C:\Windows\system32\svchost.exe -k LocalServiceNetworkRestricted^U
/bin/systemd -l LocalMetworkdeeee
>systemd подготавливает "большого брата".Вот и мне приходит та же мысль, анонимный брат.
Интересно, Сноуден, в своих речах не упоминал про агента Поттеринга?
Никогда не упоминал и в будущем не упоминать не будет, потому, что закралась существенная ошибка. Агент Поттер, а не Поттеринг.
"Оно" упростит NetworkManager.
NetworkManager вместо поддержки разрозненных велосипедов из разных дистров будет генерить унифицированные конфиги.
Унифицированные конфиги, поддержку которых в разные дистры будут планомерно допиливать ещё год. У кого там NetworkManager только-только заработал?
> "Оно" упростит NetworkManager.
> NetworkManager вместо поддержки разрозненных велосипедов из разных дистров будет генерить унифицированные конфиги.Не стоит так откровенно показывать свою некомпетентность.
NetworkManager отродясь использовал свою конфигурацию (в /etc/NetworkManager/).
Поэтому во всех дистрах вы пользуетесь либо статической конфигурацией присущей дистру (как правило сервера предпочитают этот стиль), либо динамической из NetworkManager (как правило десктоп).Для NM есть так же и кучка альтернатив (с фронт-эндами под кеды/птщьу/…), например net-misc/connman (в частности используется в Qt — dev-qt/qtnetwork-5.2.1 (connman ? net-misc/connman))
Благодарю за разъяснения.
> "Оно" упростит NetworkManager.Ага, "оптимизирует"... :)
Не удержусь и процитирую (с ibash.org.ru):
<rexim> Утилита rm при указании флага -r (от слова refactor) начинает выполнять эффективный рефакторинг.
Сделал мой вечер
>NetworkManager вместо поддержки разрозненных велосипедов из разных дистров будет генерить унифицированные конфиги.Как бы он ключи реестра не начал генерить со временем ;)
Документацию бы внятную!
Будет тебе гуй с одной кнопкой вместо документации.
Пора бы уже синий экран смерти сделать.
А то как-то не солидно. Раньше то без кернел-паников (и тд) он и не нужен был, а теперь… выглядит не солидно.
http://storage7.static.itmages.ru/i/14/0220/h_1392894110_905...
> Пора бы уже синий экран смерти сделать.Ага, со смайликом.
> Документацию бы внятную!Внятная документация может идти только к внятному совту, так что…
Да как бы тебе сказать. Документация systemd - одна из самых подробных в FOSS.
постыдился бы хоть. Postgres, modx, да тот же php, python, django. Системде - это пародия на документацию. Например, оно больше не предоставляет статические файлы для /usr/share/dbus-1/interfaces. Где об этом в документации? А вот где:diff --git a/NEWS b/NEWS
+CHANGES WITH 209:
...
+ * systemd will not generate nor install static dbus
+ introspection data anymore to /usr/share/dbus-1/interfaces,
+ as the precise format of these files are unclear, and
+ nothing makes use of it.
+Бугага :-D При таком подходе к разработке - фиг, а не документация. Сам код является документацией. А так как поттеринг тот еще кодер...
> постыдился бы хоть. Postgres, modx, да тот же php, python, django.Сравнил, млять, систему инициализации с фреймворками и немеряными БД.
> А так как поттеринг тот еще кодер...
Я думаю что большинство критиканов типа тебя - еще более плохие кодеры. И кроме всего прочего, теперь, к счастью, последствия жизнедеятельности таких как ты будут пореже попадаться в продакшновых системах. Это хорошо. Я лучше с поттеровым кодом и его граблями попинаюсь чем с тем что такие как ты генерят в простынях инита.
>> постыдился бы хоть. Postgres, modx, да тот же php, python, django.
> Сравнил, млять, систему инициализации с фреймворками и немеряными БД.Ну да. Теперь это снова просто "система инициализации" :-D
Цитата: Документация systemd - одна из самых подробных в FOSS. Читал? Всё, какие вопросы))
В системах инициализации не бывает поддержки QR-кодов.
> одобрен переход на systemd дистрибутивов DebianНе переход, а использование по умолчанию, sysvinit никуда не девается и на него всегда можно будет переключиться обратно.
Всегда - это первые пару месяцев, пока не протухнут инит-скрипты, которые никто не будет поддерживать?
> не будет поддерживать?Ну раз никто не поддерживает - значит настолько всем надо. Правда просто?
> Всегда - это первые пару месяцев, пока не протухнут инит-скрипты, которые никто
> не будет поддерживать?А с чего им протухать? sysvinit часто меняется? У меня есть самописные init скпипты с woody, до сих пор работают, start stop restart, чему там ломаться? А на не работающие init скрипты пишут багрепорты, да и самому написать скрипт по шаблону - дело одной минуты, кстати, у некоторых программ и сейчас нет init скриптов. Развели панику на пустом месте...
>> sysvinit никуда не девается и на него
>> всегда можно будет переключиться обратно. всегда можно будет переключиться обратно...ДА НУ??? :) :) :)
«Переключиться», перекомпилировав и ядро, и юзерлэнд? :) :) :) :) :) :) :) :) :) :)Что, кстати, НЕ гарантировано. Если использован systemd, — то без systemd работать не будет ваще.
Прощай, posix.
вот вот, испортили линукс. Уже и posix неподдерживает в отличии от винды
Типа, сарказм?
А вот всякий FAM привязан станет к systemd наглухо? Вот уж posix, так posix!
> Уже и posix неподдерживает в отличии от виндыЭто как? И давно ли винда начала нормально поддерживать Posix? То что там было как unix services было полным пэ.
> Если использован systemd, — то без systemd работать не будет ваще.Забористые вещи вы курили! Недавно как раз вспоминали про E17 — поддержка systemd есть, но без этого самого systemd можно запросто жить.
Я не уточнил.
Говоря «если использован systemd», я имел ввиду, что возможно существование софта, безальтернативно привязанного к systemd.
Жить в Е17? В этом кадавре, лишенном софта на своем тулките и не поддерживающем визуальную интеграцию стороннего? Это не жизнь.
если и гента прогнется, придется на FreeBSD уходить.
Нужно срочно plan9 допиливать.
А то в фряхе свой маразм (только шланги, только svn,…, только айзены).
> Нужно срочно plan9 допиливать.Тем более лицензия правильная, концепции могучие. В общем для академиков и концептуалов - очень даже.
>правильная
>могучиежгёошь! :-D
Линукс порождает интересные белезни.
Время от времени вспыхивают очаги заражения тулкитофобией.
А теперь вот инитофобия.
Что дальше?
Вангую игрофобию и в частности стимофобию. Она уже начинает набирать обороты
Думаешь? Мне кажется даже у идиотов должен быть некий физический предел тупизны...
Тут есть одно существенное отличие от systemd: стим и прочие игры, если где и являются невыпиливаемой частью, так только в стимовской сборке. А вот вышеупомянутый - упорно лезет без мыла во все дистрибутивы, куда только может. А так как претендует на статус "инновационной нанозамены" всего, блджад, системного и, по возможности, сразу...
В общем, лично я буду пока юзать Debian, как совсем кисло станет (прекратится поддержка sysvinit и начнётся внедрёж во все поля) - переведу сервера на FreeBSD, а сам уйду в монас^W^W на Gentoo/
Не думаю, что это отличие будет сильным препятствием для стимофобии. Ведь "хоть я им и не пользуюсь, но не могу спокойно спать, пока эта мерзкая проприетарщина существует, ведь одна идет в разрез с принципами Свободного ПО!!!11111" или "игрошкольники заполонили уютный линукс, уйду на *bsd".PS: Я не противник свободного ПО, даже наоборот. Просто я считаю, что конкуренция между двумя этими мирами - только плюс.
> А теперь вот инитофобия.systemd давно уже не инит. Тут скорее неприятие комбайнов всё в одном.
>> А теперь вот инитофобия.
> systemd давно уже не инит. Тут скорее неприятие комбайнов всё в одном.вполне годное и правильное решение для серверного рхел, кто то ведь должен платить за сапорт.
Саппорт софта не означает "мы админим серверы за вас"
Вообще-то означает, просто в чуть иной формулировке.
"Вы можете не админить свои серверы, валите всё на нас если что"
а так это делать не хочется :)
Не дёргайся — дебиановцы уже в процессе допиливания FreeBSD до совместимости с systemd.
https://wiki.freebsd.org/launchd
Ну вот у свежекупленного за 100500 денег WhatsApp'a серверы на FreeBSD.
А что вообще про системд говорит товарищ Линус?
Линус выбирает палец для демонстрации
Линус владелец акций касношляпы. Ему это выгодно. А вы - как обычно - сожрёте ...
А также ждём, что скажет товарищ основатель движения СПО.
> А также ждём, что скажет товарищ основатель движения СПО.Тебе лишь бы кто по-авторитетнее чего-нить сказал - сам-то ничтожество без мозгов и собственного мнения.
Хотя Бородатого и я бы послушал - всё-таки Отец. Учитель. И что удивительно до сих пор ни разу не ошибался. То-ли везёт как ненормальному, то-ли действительно гений.
>> А также ждём, что скажет товарищ основатель движения СПО.
> Тебе лишь бы кто по-авторитетнее чего-нить сказал - сам-то ничтожество без мозгов
> и собственного мнения.
> Хотя Бородатого и я бы послушал - всё-таки Отец. Учитель. И что
> удивительно до сих пор ни разу не ошибался. То-ли везёт как
> ненормальному, то-ли действительно гений.:D фанаткодетектор.
> А также ждём, что скажет товарищ основатель движения СПО.Судя по одному из его писем, он ничего против systemd не имеет :(. Ссылку привести не могу, это private-переписка.
Ну хоть своими словами смысл перескажи.
> Ну хоть своими словами смысл перескажи.Ну, если я правильно понял, то для него имеет смысл только юридическая свобода ПО, а не техническая.
>> А также ждём, что скажет товарищ основатель движения СПО.
> Судя по одному из его писем, он ничего против systemd не имеет
> :(. Ссылку привести не могу, это private-переписка.Ну правильно, systemd прибит гвоздями к Linux, который теперь правильно называть "GNU плюс Linux", поэтому ограничивает использование ПО со свободными лицензиями на всех ОС, кроме единственно верной. Про бедный Hurd RMS, видимо, уже и сам позабыл. Та же логика, что и с GCC, и из-за которой GCC начал сливать в развитии. Потому что люди не любят, когда им указывают, как им жить, и при этом называют это их свободой.
Это все замечательно, но кто-нибуть скажите Лёнчику, что можно бы и разнести функционал, обеспечив модульность. А то так он скоро к системд пшпшаудио прикрутит.
Я надеюсь тебя не шокирует то, что он модульный?
journald выпилить нельзя, значит не модульный.
systemctl stop systemd-journald.service
systemctl disable systemd-journald.serviceНет?
disable с ним не работает. Можно только выключить запись лога на диск, но сервис все равно остается запущенным. Его вообще нельзя выключить, не говоря уже о полном удалении из системы (это монолитная часть systemd, без него он не будет работать)
Пичалька. А так хотелось выпилить эти логи, там столько непонятных буковок и ии одной картинки!
> Пичалька. А так хотелось выпилить эти логи, там столько непонятных буковок и
> ии одной картинки!О да, ведь единственное как можно писать логи — это только через journald, иначе никак!
>Пичалька. А так хотелось выпилить эти логи, там столько непонятных буковок и ии одной картинки!И ни одной картинки? Да непорядок. Но это скоро исправят.
Проверил, действительно так.Тогда вот так:
/etc/systemd/journal.conf
Storage=none
ForwardToSyslog=yesС такой конфигурацией сервис будет выполнять роль прокси между systemd и старыми системами логгирования и получается, что выключать его не имеет смысла тогда. Попаболь только у тех, кому надо выпилить вообще всё логгирование из системы, чтоб и следов не осталось.
А вот на счёт монолитной части ты перегибаешь палку. Его можно заменить. Другое дело, что почему-то все готовы орать, но никто не хочет дело делать. С чего бы это?
Расскажи как использовать весь такой качественный логгер от системд не используя сам системд? И вообще как скомпилять один журналд?
Модули systemd предназначены для работы с systemd. Если ты им предоставишь окружение, аналогичное systemd, то они будут работать и там. Но вот не думаю, что сейчас можно скомпилировать только его. Просто никому это всерьёз не нужно.
>Модули systemd предназначены для работы с systemdНу и в чём тут модульность тогда?
Влинкуйте их в systemd статически, эти "модули", ничего не изменится.
Ты их можешь заменить без перекомпиляции, ты их можешь использовать в другом демоне инициализации, если он будет предоставлять аналогичные интерфейсы. Это изменится. То, что не на что и некуда, это совсем другая история.
> Ты их можешь заменить без перекомпиляции. Это изменится. То, что не на
> что, это совсем другая история.А в винде можно все сервисы поменять и заменить файл user32.dll - ура винда модульная.
Вообще-то винда это ОС, состоящая из огромного числа модулей. Да, она модульная и ты можешь свободно их менять на своё усмотрение. Многие из этих модулей можно даже притащить в Linux и запустить через WINE (напоминаю, что это акроним от WINE Is Not Emulator). Включая виндовые сервисы.Кстати, в винде можно полностью остановить Event Log.
> Вообще-то винда это ОС, состоящая из огромного числа модулей. Да, она модульная
> и ты можешь свободно их менять на своё усмотрение. Многие из
> этих модулей можно даже притащить в Linux и запустить через WINE
> (напоминаю, что это акроним от WINE Is Not Emulator). Включая виндовые
> сервисы.А если они в одном бинарике то можно шестнадцатеричным редактором вырезать кусок или вставить другой - модульность по мнению сторонников Леонида.
> Кстати, в винде можно полностью остановить Event Log.
Прекрасно. А ещё там есть какой-то сервис связанный с рпц и остановив его можно поднять только поправив ключ в реестре. Чтоб любителям системд такая фигня всё время обламывалась в их новой системе.
> Ты их можешь заменить без перекомпиляции, ты их можешь использовать в другом
> демоне инициализации, если он будет предоставлять аналогичные интерфейсы. Это изменится.
> То, что не на что и некуда, это совсем другая история.Понимаете, с точки зрения UNIX-way, это не модульность, а монолитность. Модульность - это когда вы свободно можете заменить одну реализацию на другую. А тут такая свобода отсутствует.
Представим некий абстрактный "модульный" компьютер. Но, к сожалению, мат. плата требует установки компонентов только от того же вендора, а эти компоненты могут взаимодействовать далее тоже только с продуктами этого вендора.Чтобы компьютер работал, вы вынуждены покупать *весь* компьютер (иначе он тупо не будет работать) у одного и того же вендора, хотя вендор заявляет, что компьютер модульный и вы вправе заменять любой из модулей. И вы никуда не денетесь; для вас, как для покупателя, этот продукт — монолит, и это никак не обойти. То есть по факту же покупатель получает hardware lock-in, а вся "модульность" ограничивается лишь свободой покупать обновлённые версии этих же модулей у этого же вендора.
Абсолютно аналогично systemd вводит software lock-in, который очень не нравится людям, которые хотят сохранить свои свободы, ибо они знают, что где-то среди этого огромного кода systemd есть проблемы (уязвимости, баги, неудобства или ещё что), которые их не устроят [иначе быть не может чисто статистически]; а заменить реализацию никакого из "модулей" никак нельзя. Отсюда, с точки зрения UNIX-way, «systemd» - это монолит.
> Модульность - это когда вы свободно можете заменить одну реализацию на другую.Не на любую другую, а на совместимую по интерфейсам. Вполне естественное и очевидное требование для любой модульной системы, но почему-то очевидное не для всех.
А вообще среди аналитиков и экспертов по системах инициализации на опеннете своё понимание модульности - это когда что-то выкидываешь, а оно должно работать. А если не работает - значит не модульное. Если journald нельзя выкинуть - значит не модульное. Если компьютер без блока питания не работает - значит тоже "монолит".
> Представим некий абстрактный "модульный" компьютер. Но, к сожалению, мат. плата требует установки компонентов только от того же вендора, а эти компоненты могут взаимодействовать далее тоже только с продуктами этого вендора.
>Абсолютно аналогично systemd вводит software lock-in
> а заменить реализацию никакого из "модулей" никак нельзя.Это просто откровенная ложь. Вполне очевидно, что можно переписать любую часть systemd, при сохранении совместимости в плане взаимодействия с другими частями. Абсолютно никаких препятствий этому нет - исходники есть, документация есть, никакого реверс-инжиниринга не нужно, никакие патенты этого не запрещают, никто получать лицензии на реализацию интерфейсов и протоколов не заставляет.
>> Модульность - это когда вы свободно можете заменить одну реализацию на другую.
> Не на любую другую, а на совместимую по интерфейсам. Вполне естественное и
> очевидное требование для любой модульной системы, но почему-то очевидное не для
> всех.Да, но в UNIX-way очень стараются использовать уже существующие интерфейсы (в худшем случае расширять их или чуть-чуть ломать), вместо изобретения собственных. А если не получилось, то тогда пытаются как можно лучше документировать эти новые интерфейсы. Более того, когда приходится разработать какой-то собственный интерфейс (даже просто один и великолепно документированный, а не дикое множество, как в systemd), то это создаёт огромное количество очевидных проблем для сообщества, что вызывает соответствующее возмущние (это справедливо и всегда так было), так как это ограничивает технические свободы конечных пользователей.
systemd просто изначально делался, делается и, похоже, будет делаться по принципу — "плевать на всё что было до меня и свободу выбора, буду делать по-своему".
> А вообще среди аналитиков и экспертов по системах инициализации на опеннете своё
> понимание модульности - это когда что-то выкидываешь, а оно должно работать.
> А если не работает - значит не модульное. Если journald нельзя
> выкинуть - значит не модульное. Если компьютер без блока питания не
> работает - значит тоже "монолит".Как это вообще относится к моему посту на который вы отвечали? Я говорил про свободу заменить, а не про свободу выкинуть, читайте внимательнее, пожалуйста.
>> Представим некий абстрактный "модульный" компьютер. Но, к сожалению, мат. плата требует установки компонентов только от того же вендора, а эти компоненты могут взаимодействовать далее тоже только с продуктами этого вендора.
>>Абсолютно аналогично systemd вводит software lock-in
>> а заменить реализацию никакого из "модулей" никак нельзя.
> Это просто откровенная ложь. Вполне очевидно, что можно переписать любую часть systemd,
> при сохранении совместимости в плане взаимодействия с другими частями. Абсолютно никаких
> препятствий этому нет - исходники есть, документация есть, никакого реверс-инжиниринга
> не нужно, никакие патенты этого не запрещают, никто получать лицензии на
> реализацию интерфейсов и протоколов не заставляет.IMO, большинство программистов в каком-нибудь коде с IOCCC разберётся быстрее, чем в systemd, несмотря на открытость и якобы "документированность".
Забавно, что всё что вы мне ответили после "это просто откровенная ложь" фактически никак не противоречит тому, на что вы это отвечали.
Допустим, vendor этого абстрактного компьютера тоже никак лицензиями не ограничивает использование других компонентов, составил якобы "документацию" и никак не ограничивает патентами. Единственное — vendor заявляет, что в случае "замен" он не даёт никакой гарантии даже на свои продукты. Однако это хоть и неприятно, но основная проблема всё равно не в этом, а в потенциальном барьере на отвязку от продуктов этого vendor-а. Становится порядком проще тупо вообще отказаться от этого vendor-а, и выбрать того, кто не делает такого рода мягкие hardware interface lock-in-и.
> Да, но в UNIX-way очень стараются использовать уже существующие интерфейсы (в худшем случае расширять их или чуть-чуть ломать), вместо изобретения собственных.Иногда существующие интерфейсы просто не соответствуют решаемым задачам. Поэтому когда это становится необходимо, витую пару заменяют на оптоволокно.
> А если не получилось, то тогда пытаются как можно лучше документировать эти новые интерфейсы. Более того, когда приходится разработать какой-то собственный интерфейс (даже просто один и великолепно документированный, а не дикое множество, как в systemd), то это создаёт огромное количество очевидных проблем для сообщества, что вызывает соответствующее возмущние (это справедливо и всегда так было), так как это ограничивает технические свободы конечных пользователей.
Чушь. Например, в mesa в свое время появился gallium, и многие драйверы вообще переписали практически с нуля под новый интерфейс. И что, какие свободы пользователей ограничены? Что-то не припомню толпы рыдающих пользователей по этому поводу. Видимо, в том случае они понимали, что слишком мало разбираются в теме, чтобы лезть туда с критикой и советами. Где толпы жалующихся на то, что в mesa добавляют новые модули, превращая ее в комбайн, обслуживающий и 3d графику, и аппаратную обработку видео, и OpenCL, и все это на самом разном железе? Где толпы жалующихся на слишком большую сложность mesa и отсутствие внятной документации? Сейчас развивается wayland - где толпы возмущенных пользователей, озабоченных сменой интерфейсов и протоколов? Так что бурление вокруг systemd, где каждый почему-то считает себя экспертом, это скорее что-то специфическое и "модное", а вовсе не обычная реакция пользователей на новые проекты и перепиливание старых, якобы ограничивающее их свободу.
> А вообще среди аналитиков и экспертов по системах инициализации на опеннете
> Как это вообще относится к моему посту на который вы отвечали?Никак, кроме близкой темы. Это что-то вроде лирического отступления, на что недвусмысленно намекают буквально первые слова "А вообще..."
> IMO, большинство программистов в каком-нибудь коде с IOCCC разберётся быстрее, чем в systemd, несмотря на открытость и якобы "документированность".
Ну это лишь Ваше личное "IMO". А в реальности многие проекты уже вполне стыкуются с systemd для реализации новых возможностей, и им, очевидно, ничто не мешает разобраться с интерфейсами и прочим - ни личные предубеждения, ни "сверхсложность" systemd, ни "плохая" документация, ни даже то, что иногда мешает танцорам.
> Единственное — vendor заявляет, что в случае "замен" он не даёт никакой гарантии даже на свои продукты.
Есть один продукт - systemd, состоящий из нескольких поставляемых вместе компонентов, и любые гарантии могут существовать только на весь продукт, т.к. он не поставляется по частям. Очевидно, что его компоненты взаимосвязаны и тестировались только вместе друг с другом. Если Вы что-то в нем меняете на сторонние компоненты, то не слишком ли большая наглость с Вашей стороны требовать от производителя каких-то гарантий на счет неизвестно как модифицированного Вами продукта. Никто и никогда таких гарантий не давал и не даст, и это как раз вполне естественно, потому что никто ничего не может гарантировать насчет чужих компонентов и их корректной работы в составе продукта.
Но это опять скорее было лирическое отступление, потому что разговор о гарантиях в опенсорсе вообще имеет мало смысла. У Вас есть гарантийный талон на ядро или какой-то другой софт? Если нет, то не надо пытаться изобретать несуществующие проблемы systemd, это уже просто смешно.
вы только что признали что системд монолит, и потом речь не о переписаных интерфейсах, а о том, что системд выполняет кучу задач никаким образом не входящих в его компетенцию и нет никаких убедительных докахзательств его превосходства над имеющимися системами.
Что касается вейланда, так его пишут с целью облегчить систему и избавиться от дикого колличества костылей, а системд делает в точности до наоборот. (про месу ничего не скажу, тут я мало компетентен, но помоему всё вышеперечисленное входит в его компетенцию)
> вы только что признали что системд монолитВам показалось. Если Вы купили автомобиль в собранном виде, а не как россыпь запчастей, и никто отдельную гарантию на каждую деталь Вам не давал, то это еще не означает что он монолит и пепельницу в нем заменить невозможно.
> и потом речь не о переписаных интерфейсах, а о том, что системд выполняет кучу задач никаким образом не входящих в его компетенцию
> Что касается вейланда, так его пишут с целью облегчить систему и избавиться от дикого колличества костылей, а системд делает в точности до наоборот. (про месу ничего не скажу, тут я мало компетентен, но помоему всё вышеперечисленное входит в его компетенцию)О чем я и говорю, мало кто берется рассуждать о mesa или других сложных проектах, но, как ни странно, каждый тут - эксперт по systemd и решаемым им задачам. То ли systemd такой простой, что буквально каждому не составляет труда разобраться в его коде за пять минут и вынести свою экспертную оценку... Хотя при этом те же самые люди нередко утверждают, что systemd невероятно сложный и разобраться в нём никто и никогда не сможет. Парадокс.
> нет никаких убедительных докахзательств его превосходства над имеющимися системами.
Нет никаких убедительных доказательств того, что Вас кто-то силой заставляет использовать systemd у себя. Используйте то, что Вам больше нравится. Я уверен, что при Вашем высочайшем уровне компетенции в системах инициализации и сопутствующих вещах, для Вас будет несложно поддерживать такие простые и интуитивно-понятные проекты, как sysvinit с initscripts, тем более что они, как здесь известно каждому, "просто работают".
Нет, я один вижу что вот текст выше ахинея? Куча слов вообще не по делу и аналогии шизоидные. А под конец враньё. Вот оно:
"для Вас будет несложно поддерживать такие простые и интуитивно-понятные проекты, как sysvinit с initscripts, тем более что они, как здесь известно каждому, "просто работают"."
Оказывается надо всего сисвинит в дистре поддерживать самому. Ничего же больше на системд не привязали и не привяжут.И такие люди вещают за системд.
> Нет, я один вижу что вот текст выше ахинея?Вряд ли, скорее всего другие systemd-хейтеры видят примерно так же.
> Оказывается надо всего сисвинит в дистре поддерживать самому. Ничего же больше на системд не привязали и не привяжут.
Поддержка работоспособности остального софта совместно с sysvinit подразумевается, когда речь идет о поддержке sysvinit. Если гном или что-то еще не работает с sysvinit, то это проблемы именно sysvinit а не гнома, так как без sysvinit он вполне будет работать.
И если что, такого рода поддержка всегда была нужна, просто до сих пор для вас её другие делали, и пока sysvinit был дефолтом везде, это воспринималось как обязательное и само собой разумеющееся. Вы об этом, конечно же, не задумывались и просто пользовались. А когда начинаете осознавать, что теперь всё придется своими руками, и что не всё так легко и радужно с sysvinit как Вам казалось, то в этот момент у многих случается когнитивный диссонанс и легкая истерика. И конечно же виноваты в этом именно systemd, Поттеринг, некомпетентность всех разработчиков и мэйнтейнеров линукса, отсутствие справедливости во вселенной, и <любая другая причина>, но только не ваше собственное непонимание ситуации.
> Вряд ли, скорее всего другие systemd-хейтеры видят примерно так же.Странно. Особенно странны две вещи. Первое что много народа видит тоже самое. Второе что вменяемые люди называются системдхейтеры.
> Поддержка работоспособности остального софта совместно с sysvinit подразумевается, когда
> речь идет о поддержке sysvinit. Если гном или что-то еще не
> работает с sysvinit, то это проблемы именно sysvinit а не гнома,
> так как без sysvinit он вполне будет работать.Гражданин знаток ответь на два вопроса без привлечения интернетов и манов:
1. zypper up - что делать после этого для восстановления sysvinit?
2. Пример с лора
ConditionPathExists=/dev/sda1
ConditionPathExists=!/dev/sda2
ConditionPathExists=|/dev/sdb1
ConditionPathExists=|/dev/mmc1
напиши логическое выражение по этому. а,б,в,г и отношение между ними для конечного результата.> И конечно же виноваты в этом именно systemd, Поттеринг, некомпетентность всех разработчиков и мэйнтейнеров линукса, отсутствие справедливости во вселенной, и <любая другая причина>, но только не ваше собственное непонимание ситуации.
Дай я проще скажу. Виноваты ч^Wудаки которые лезут чинить то что не ломалось. Расскажи зачем компаниям системд. У компании нет ексченджа - как его заменит системд? У компаний нет единой системы авторизации и управления кучей компов, ничего, тут фриипа на подходе.
У компании нет лунка - как его заменит твоё копошение в потрохах системы запуска?
Скажем просто. Граждане хотят получить деньги за то что они красивые. А деньги и хорошее влияние можно получить только в эпоху перемен. Поэтому все интеграторы бегают с с ситемд как с писаной торбой - они могут по результатам вылезти на верх. И остальные писюлькавые злыдни думают что их этой волной тоже подымет. А большинству это не надо.
>> Нет, я один вижу что вот текст выше ахинея?
> Вряд ли, скорее всего другие systemd-хейтеры видят примерно так же.Я устал повторять. Лично мне насрать на systemd, пока мне его в глотку не пихают. А как только начинают пихать, я хочу разобраться, что мне подсовывают. И в результате выясняется, что это кусок говна.
Я не против обновления rc или init в Debian. Но пусть это будет что-то соответствующее философии UNIX.
Тут очень мало systemd-hater-ов. Тут просто люди, которые хотят сохранить свои свободы. Проблема только в этом. Если бы systemd не force-ился всюду, то и хрен с ним… А вот systemd-lover, кстати, тут хватает. :(
>> Оказывается надо всего сисвинит в дистре поддерживать самому. Ничего же больше на системд не привязали и не привяжут.
> Поддержка работоспособности остального софта совместно с sysvinit подразумевается, когда
> речь идет о поддержке sysvinit. Если гном или что-то еще не
> работает с sysvinit, то это проблемы именно sysvinit а не гнома,
> так как без sysvinit он вполне будет работать.Нет, уважаемый, это проблема не sysvinit, а именно gnome-а, который чудесным умом сами знаете кого был завязан именно на systemd.
Пояснительная аналогия:
Если производитель каких-то сотовых телефонов начнёт вдруг делать аппараты с какой-то совершенно нестандартной частотой (которая встречается только у одного оператора во всём мире), то это будет проблема именно этих сотовых телефонов, а не всех остальных операторов сотовой связи в мире.И ещё момент. В gnome-е не работает только lock-screen, если я правильно помню. Поправьте, если ошибаюсь. Вообще не понимаю, почему из этого делают такую трагедию.
> И если что, такого рода поддержка всегда была нужна, просто до сих
> пор для вас её другие делали, и пока sysvinit был дефолтом
> везде, это воспринималось как обязательное и само собой разумеющееся.Поддержка чего? Имеется в виду развязка software lock-in вводимых компанией Red Hat что ли?
> Вы об
> этом, конечно же, не задумывались и просто пользовались. А когда начинаете
> осознавать, что теперь всё придется своими руками, и что не всё
> так легко и радужно с sysvinit как Вам казалось, то в
> этот момент у многих случается когнитивный диссонанс и легкая истерика.Вы вообще сейчас про что? Я вас не понимаю. Вы про то что Debian maintainer-ы буду поддерживать сервисы под systemd после всех известного решения? А причём тут "радужность в sysvinit"? Тут проблема не в sysvinit, а в том что maintainer-ы просто будут оказывать поддержку только для systemd.
> И
> конечно же виноваты в этом именно systemdВ говёности systemd виноват только systemd… Ну и его авторы, конечно же.
А вообще, комментатор выше уже хорошо ответил —
http://www.opennet.me/openforum/vsluhforumID3/94244.html#187> , Поттеринг, некомпетентность всех разработчиков
Поттеринг со своими приспешниками вообще много чего натворили, притом всё это укладывается в одну единую и грустную картину.
> и мэйнтейнеров линукса,
А они тут причём? Они просто слушаются указаний свыше.
> отсутствие справедливости во вселенной, и <любая другая причина>,
…
> но только не ваше собственное непонимание ситуации.
Мы-то вроде как раз понимаем. А вот вам приходится повторять раз за разом с разных сторон, ибо вы отказываетесь слушать и продолжаете говорить то, что противоречит уже сказанному (но не опровергнутому).
> Вам показалось. Если Вы купили автомобиль в собранном виде, а не как россыпь запчастей, и никто отдельную гарантию на каждую деталь Вам не давал, то это еще не означает что он монолит и пепельницу в нем заменить невозможно.пепельницу в автомобиле заменить можно только сломанную на точно такую же. заменить на пепельницу с перламутровыми пуговицами нельзя.
аналогично в системд вы можете заменить либу пожратую вирусом на чистую из репозитория.
к стабильному документированному АПИ/АБИ, т.е. модульности, это никакого отношение не имеет.удачи вам
> Иногда существующие интерфейсы просто не соответствуют решаемым задачам. Поэтому когда это становится необходимо, витую пару заменяют на оптоволокно.А кроме этого выносят езернет и переходят на фиберченел. Причём делают это особо одарёно - выпиливая всё что связано с езернетом отовсюду. Кроме этого выпиливают усб, 220В и всё запихивают в этот же фиберченел.
>> Да, но в UNIX-way очень стараются использовать уже существующие интерфейсы (в худшем случае расширять их или чуть-чуть ломать), вместо изобретения собственных.
> Иногда существующие интерфейсы просто не соответствуют решаемым задачам. Поэтому когда
> это становится необходимо, витую пару заменяют на оптоволокно.Замечательно, но:
- Эти переходы делают эволюционно, а не революционно.
- Всё очень тчательно документируют. По всем стандартам Ethernet составлена весьма исчерпывающая информация.
- Сейчас витой пары намного больше, чем оптоволокна.
- Для замены витой пары на оптоволокно были очень серёзные причины, повышающие вполне конкретные численные характеристики в десятки раз за ту же цену. Иначе бы не дёргались.
- Комментарий выше хорош :) — «А кроме этого выносят езернет и переходят на фиберченел. Причём делают это особо одарёно - выпиливая всё что связано с езернетом отовсюду. Кроме этого выпиливают усб, 220В и всё запихивают в этот же фиберченел.»Некорректный пример вы привели…
>> А если не получилось, то тогда пытаются как можно лучше документировать эти новые интерфейсы. Более того, когда приходится разработать какой-то собственный интерфейс (даже просто один и великолепно документированный, а не дикое множество, как в systemd), то это создаёт огромное количество очевидных проблем для сообщества, что вызывает соответствующее возмущние (это справедливо и всегда так было), так как это ограничивает технические свободы конечных пользователей.
> Чушь. Например, в mesa в свое время появился gallium, и многие драйверы
> вообще переписали практически с нуля под новый интерфейс. И что, какие
> свободы пользователей ограничены? Что-то не припомню толпы рыдающих пользователей по этому
> поводу. Видимо, в том случае они понимали, что слишком мало разбираются
> в теме, чтобы лезть туда с критикой и советами. Где толпы
> жалующихся на то, что в mesa добавляют новые модули, превращая ее
> в комбайн, обслуживающий и 3d графику, и аппаратную обработку видео, и
> OpenCL, и все это на самом разном железе? Где толпы жалующихся
> на слишком большую сложность mesa и отсутствие внятной документации?Честно сказать, никогда не работал с Gallium, поэтому мало чего могу ответить по данному примеру. Вы про этот Gallium — [1]?
[1] http://ru.wikipedia.org/wiki/Gallium3D
Если да, то тут нет толп жалующихся тупо по той причине, что само использование Gallium-а не вводит никаких software lock-in-ов. Он не завязан на конкретную собственную реализацию сервера логов и т.п. Другими словами, вся радость с Gallium связана с тем, что он в отличие от systemd — UNIX-way.
Просто на секунду представьте, если бы Gallium тянул за собой собственную реализацию сервера логов, несовместимую по протоколам с общепринятыми. Это было бы нормально?
Однако не удивлюсь если и Gallium подвергался весьма хорошей критике. Я просто не в курсе.
> Сейчас развивается
> wayland - где толпы возмущенных пользователей, озабоченных сменой интерфейсов и протоколов?Вы явно пропустили кусок жизни. Вообще-то толпы возмущающихся были и есть до сих пор. :). Однако опять же, даже wayland порядком более UNIX-way, чем systemd, поэтому с ним (с wayland) смириться относительно легко, несмотря на отсутствие native client-server прозрачности. Его отдельно можно легко заменить на Xorg, не требуя при этом отказа от привычного сервера логов.
> Так что бурление вокруг systemd, где каждый почему-то считает себя экспертом,
> это скорее что-то специфическое и "модное", а вовсе не обычная реакция
> пользователей на новые проекты и перепиливание старых, якобы ограничивающее их свободу.Нет, systemd действительно развивается по идеологии software bundle-ов, что не есть UNIX-way. Это создаёт ограничения свобод по техническим причинам. И именно это вызывает такую бурную реакцию.
Во всех приведённых вами примерах ничего такого не было. Более того, всем было бы насрать на systemd, если бы он не force-ился как default в таких дистрибутивах как Debian, Arch и другие. Тут люди понимают, что либо им придётся смириться с этим, либо уходить на другой дистрибутив. А ведь то и другое неприятно, вот отсюда и возмущение.
>> А вообще среди аналитиков и экспертов по системах инициализации на опеннете
>> Как это вообще относится к моему посту на который вы отвечали?
> Никак, кроме близкой темы. Это что-то вроде лирического отступления, на что недвусмысленно
> намекают буквально первые слова "А вообще..."«А вообще» обычно пишут перед обобщением, а не перед отступлением, как мне казалось. На это недвусмысленно намекает само слово «вообще» (всё в общем).
>> IMO, большинство программистов в каком-нибудь коде с IOCCC разберётся быстрее, чем в systemd, несмотря на открытость и якобы "документированность".
> Ну это лишь Ваше личное "IMO". А в реальности многие проекты уже
> вполне стыкуются с systemd для реализации новых возможностей, и им, очевидно,
> ничто не мешает разобраться с интерфейсами и прочим - ни личные
> предубеждения, ни "сверхсложность" systemd, ни "плохая" документация, ни даже то, что
> иногда мешает танцорам.Чем больше вы переходите на личности, тем менее конструктивным делаете диалог.
А по поводу «множества проектов», покажите хотя бы одну альтернативную реализацию journald, пожалуйста, про что речь была изначально.
>> Единственное — vendor заявляет, что в случае "замен" он не даёт никакой гарантии даже на свои продукты.
> Есть один продукт - systemd, состоящий из нескольких поставляемых вместе компонентов, и
> любые гарантии могут существовать только на весь продукт, т.к. он не
> поставляется по частям.Совсем-совсем не UNIX-way. Одна из основных черт UNIX-систем (и UNIX-подобных), которая делает их такими хорошими, это то, что каждая программа делает только одну вещь, но делает её хорошо. В результате получается некоторый конструктор, где ты из подходящих для себя блоков можешь свободно собрать подходящую для тебя систему.
Разве вы не видите, что вы сами доказываете какой systemd создаёт software lock-in?
> Очевидно, что его компоненты взаимосвязаны и тестировались только
> вместе друг с другом. Если Вы что-то в нем меняете на
> сторонние компоненты, то не слишком ли большая наглость с Вашей стороны
> требовать от производителя каких-то гарантий на счет неизвестно как модифицированного
> Вами продукта.Знаете, вот фактически везде кроме systemd это считается нормальным в UNIX/UNIX-подобных дистрибутивах. Каждая программа делается как отдельный продукт, позволяя свободно менять компоненты, на которые компоненты на которые она опирается.
И, чёрт подери, именно _это_ и вызывает отварищение в systemd. Именно то, что ему насрать на твои свободы.
> Никто и никогда таких гарантий не давал и не
> даст, и это как раз вполне естественно, потому что никто ничего
> не может гарантировать насчет чужих компонентов и их корректной работы в
> составе продукта.Чушь. Программа просто должна корректно использовать хорошо документированные интерфейсы. Тогда можно легко будет понять, проблема в данной программе, или в компоненте, который был использован по зависимости. За этим уже последует исправление. Не вижу никаких проблем распространении поддержки продукта на ситуации с заменой реализации различных компонентов.
> Но это опять скорее было лирическое отступление, потому что разговор о гарантиях
> в опенсорсе вообще имеет мало смысла.Аналогией гарантии имелось в виду намерение автора оказывать поддержку.
> У Вас есть гарантийный талон
> на ядро или какой-то другой софт? Если нет, то не надо
> пытаться изобретать несуществующие проблемы systemd, это уже просто смешно._
> просто смешно."Очень"…
> Модули systemd предназначены для работы с systemd. Если ты им предоставишь окружение,
> аналогичное systemd, то они будут работать и там. Но вот не
> думаю, что сейчас можно скомпилировать только его. Просто никому это всерьёз
> не нужно.svchost.exe мать его.
Вообще-то нет. Смысл svchost.exe в том, что он запускает сервисы, собранные в форме dll-библиотек. Ты их вообще никак иначе не запустишь, кроме как через него.
> Вообще-то нет. Смысл svchost.exe в том, что он запускает сервисы, собранные в
> форме dll-библиотек. Ты их вообще никак иначе не запустишь, кроме как
> через него.А демоны ссистемд будут спокойно работать без самого системд?
Если ты им предоставишь все необходимые интерфейсы, то почему бы им не работать? Просто сейчас только он им их все предоставляет. Но это не значит, что пропатчить тот же Upstart (который оказался никому не нужен) до совместимости с ними просто невозможно.Или ты сам systemd обозвал svchost-ом? Вообще svchost придумали для того, чтоб снизить потребление памяти и нагрузку на систему от множества процессов запуская пачку сервисов в форме одного процесса. Да, без него было бы ещё хуже.
> Если ты им предоставишь все необходимые интерфейсы, то почему бы им не
> работать?И это уже зафиксировано в доках и Леонид кровью подписался что менять не будет? Или как обычно надо лазить по исходникам?
> Просто сейчас только он им их все предоставляет. Но это
> не значит, что пропатчить тот же Upstart (который оказался никому не
> нужен) до совместимости с ними просто невозможно.А в винде файловые системы кроме нтфс оказались не нужны. Зачем в линухе их кучу развели не понятно.
Ну давай начнём с того, что сервисы systemd это полностью самостоятельные бинарники и их можно взять и запустить без его участия в этом процессе. В unit-файлах прописано как именно их нужно запускать и что им может быть нужно для запуска. Другое дело, что они могут ожидать наличия других сервисов, с ними совместимых, и общаться с ними по dbus. Поднимешь не в том порядке — не заведутся. Проводить эксперимент мне лень.
> Ну давай начнём с того, что сервисы systemd это полностью самостоятельные бинарники
> и их можно взять и запустить без его участия в этом
> процессе. В unit-файлах прописано как именно их нужно запускать и что
> им может быть нужно для запуска. Другое дело, что они могут
> ожидать наличия других сервисов, с ними совместимых, и общаться с ними
> по dbus. Поднимешь не в том порядке — не заведутся. Проводить
> эксперимент мне лень.Ну расскажи что лдд скажит на бинарик журналд. И как без компонентов системд он будет работать.
Он зависит от libsystemd-daemon.so и libudev.so, хотя последнее можно заменить, да и первое при желании можно переделать под свои требования (да оно так и было до того, как несколько разных либ свели по одну крышу, тут даже об этом написано). Тебя не устраивает конкретно эта либа? Тебя не устраивает то, что сервис пользуется разделяемой библиотекой, используемой ещё в нескольких других сервисах и то, что библиотеке дали неугодное тебе название?
> Он зависит от libsystemd-daemon.so и libudev.so, хотя последнее можно заменить, да и
> первое при желании можно переделать под свои требования (да оно так
> и было до того, как несколько разных либ свели по одну
> крышу, тут даже об этом написано). Тебя не устраивает либа?А давай я вопросом на вопрос отвечу? Тебя не устраивает винда? Она вся модульная, можно кусок бинарика вырезать и "запустить" под нужной ос или вставить свой кусок. Меняй что хочешь в системе. Так чем тебя не устраивает винда?
Я твой бред уже даже понимать перестал. Что тебе так не терпится сравнить ОС с демоном инициализации? Да, можно взять бинарник и запустить его в WINE, например. В том числе и виндовые сервисы. Не устраивает отсутствием детальной и корректной документации к API как минимум, чтоб не нужно было писать прослойку из библиотек, предоставляющих эти API методом обратного инженеринга из бинарников. Тут у тебя есть и сырцы, и документация, и готовые библиотеки. Что не так?
> Я твой бред уже даже понимать перестал. Что тебе так не терпится
> сравнить ОС с демоном инициализации? Да, можно взять бинарник и запустить
> его в WINE, например. В том числе и виндовые сервисы. Не
> устраивает отсутствием детальной и корректной документации к API как минимум, чтоб
> не нужно было писать прослойку из библиотек, предоставляющих эти API методом
> обратного инженеринга из бинарников. Тут у тебя есть и сырцы, и
> документация, и готовые библиотеки. Что не так?Что не так? Ты свой бред то слышишь? Спрашивают - модульный? Ты в ответ, придумав свою модульность, говоришь а как же. Оукей. Спрашиваешь: можно скомпилировать, запустить только один демон из системд; можно вместо демона системд подсунуть свой другой; написана ли исчерпывающая дока и не будет ли всё ломаться каждый релиз? В ответ бред про просто как два пальца об асфальт, главное окружение создать. Ну иди тогда, раз как два пальца, в проект реактос и запили там по быстрому аналог винды. Или возьми выпили фат32 из винды и запили туда бтрфс а заодно системд. Это же как два пальца, модульность же там есть. На уровне шестнадцатеричного редактора уровень, но тебе же пофиг.
-_-> можно скомпилировать, запустить только один демон из системд
Скорее всего нет, кто-то должен отвечать на их dbus-запросы, например, и если ответ будет ожидаться от systemd, то работать без него или его замены не будет. И, кстати, общение по dbus у низ пока не стабилизировано, хотя они обещают стабилизировать, а пока только обещают не ломать слишком часто.
> можно вместо демона системд подсунуть свой другой
Можно. Напиши и подсунь.
> написана ли исчерпывающая дока и не будет ли всё ломаться каждый релиз
Написана, раздел "Documentation for Developers".
http://www.freedesktop.org/wiki/Software/systemd/
В частности см. тут о стабильности: http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt.../
И ещё тут: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo.../И ты путаешь модульность с совместимостью и переносимостью. Никто не обещал, что модули systemd можно запускать без systemd или аналога.
И, кстати, в винде можно запилить другую FS. Вот не знаю можно ли ухитриться эти драйвера подсунуть инсталлятору и поставить саму винду на ext4, например, но как минимум получить доступ к разделу на ext4 можно. Но при чём тут файловые системы в винде, когда мы говорим о демоне инициализации? Давай может про виндовые сервисы говорить и возможность их заменять на свои или запускать вне винды. По крайней мере сравнение будет более честным. Кстати, тут ты слишком широко применяешь значение слова «модульный». Может ты мне CFS на BFS поменяешь без пересборки ядра, например?
Заходишь ты в туалет пописать, сделал дело, хочешь смыть, а на унитазе установлен вачок который тебе ещё и *** моет и жопу подтирает и волосы в ушах стрижёт, причём реализован так, что если размер ***я не как у разработчика, то он его отрезает, а на его место другой лепит... резиновый, зато как у разработчика. и зашита вся эта система в хитрый монолитный корпус... Нет, в документации конечно сказано, что это не монолит, и ненужные функции можно убрать, всего то пару раз стукнув кувалдой... И всё бы ничего, но там не сказано, то чтобы лишнее отломалось правильно тебе нужно самому сделать пару зажимов и втулок и расчитать силу удара очень точно, иначе сработает дитонатор взрывающий всю квартиру...извините за упоротость, просто всё что вы писали звучит примерно также...
> Он зависит от libsystemd-daemon.so и libudev.so, хотя последнее можно заменить, да и
> первое при желании можно переделать под свои требования (да оно так
> и было до того, как несколько разных либ свели по одну
> крышу, тут даже об этом написано). Тебя не устраивает конкретно эта
> либа?Хм. А в новости написано:
> Ранее разрозненные компоненты libsystemd-journal.so, libsystemd-id128.so, libsystemd-login и libsystemd-daemon объединены в одну общую библиотеку libsystemd.so, [...]
Самое главное упустил:
> позволило заметно сократить дублирование кода в разных частях systemd и избавиться от цикличных зависимостей
> избавиться от цикличных зависимостей
> избавиться от цикличных зависимостей
> избавиться от цикличных зависимостейЭто вот модульность.
> Вообще-то нет. Смысл svchost.exe в том, что он запускает сервисы, собранные в
> форме dll-библиотек.Может и в более вменяемой форме запустить. Но с длл-библами конечно дец полный.
В данном случае нет. От dll-ек сервисов никто не зависит, а потому и dll hell они не создают. Это просто бинарный модуль без своего собственного лаунчера, роль которого выполняет svchost (который может поднять сразу несколько таких библиотек в пределах одного процесса — потому их и сделали в форме dll-ок, а не самостоятельных исполнимых файлов). В винде ещё есть dll-файлы тупо с иконками, например, и больше ничего там нет, кроме блока ресурсов.
Его нельзя заменить, он все равно будет в системе, выполняя роль прослойки. Внимание вопрос: а зачем он тогда там нужен, если я хочу испозьзовать другую систему журналирования? Такой способ не что иное как костыль.
замена klog - сообщения ядра
> Проверил, действительно так.
> Тогда вот так:
> /etc/systemd/journal.conf
> Storage=none
> ForwardToSyslog=yes
> С такой конфигурацией сервис будет выполнять роль прокси между systemd и старыми
> системами логгирования и получается, что выключать его не имеет смысла тогда.То есть это нормально добавлять дополнительную сущность напрямую взаимодействующую через хитрые механизмы с pid1, единственной функцией которой является вызов функции «syslog()», я правильно вас понял?
> Попаболь только у тех, кому надо выпилить вообще всё логгирование из
> системы, чтоб и следов не осталось.IMHO, что чем больше интерфейсов и модулей имеет systemd, тем он бажнее и имеет большую поверхность для атаки. А унификация такой хрени сквозь большниство популярных дистрибутивов Linux может сделать реально живым термин «вирус под linux». =\
(честно сказать, формулировка не моя, но я полностью согласен с этой позицией изначального автора)И не надо говорить про паранойю. До того как Сноуден сказал очевидные вещи, нам отвечали что а-ля «PRISM» — это тоже паранойя. [offtop]И до сих пор продолжают так говорить про возможность анализа неочевидных социальных связей и другой информации через социальные сети[/offtop]
> А вот на счёт монолитной части ты перегибаешь палку. Его можно заменить.
Кого «можно заменить»? «journald»? Киньте, пожалуйста, ссылку на HOWTO.
> Другое дело, что почему-то все готовы орать, но никто не хочет
> дело делать. С чего бы это?С чего вы это взяли? Я вот дело делаю, например. В этом году активно учавствую в развитии OpenRC, например. Просто любопытства ради, а Вы?
>То есть это нормально добавлять дополнительную сущность напрямую взаимодействующую через хитрые механизмы с pid1, единственной функцией которой является вызов функции «syslog()», я правильно вас понял?Для Леннарта - вполне нормально. В пульсе для ALSA-умеющих программ такой же был путь.
> То есть это нормально добавлять дополнительную сущность напрямую взаимодействующую через хитрые механизмы с pid1, единственной функцией которой является вызов функции «syslog()», я правильно вас понял?Нет, но если хочешь получить логи от самого systemd, то пока придётся.
> IMHO, что чем больше интерфейсов и модулей имеет systemd, тем он бажнее и имеет большую поверхность для атаки.
А куча отдельных решений, каждое со своим набором багов и глюков тебе кажется более надёжным?
> А унификация такой хрени сквозь большниство популярных дистрибутивов Linux может сделать реально живым термин «вирус под linux». =\
А то, что у них общее ядро и иксы тебя не смущает? Ну да, у всех есть свой набор патчей, но это применимо и к systemd. Разные велосипеды это лишь иллюзия защиты и ничего хорошего в этом нет. Возможно они не позволят создать скринлокера, пригодного для всех, но зато если надо сломать конкретный сервер, то это может очень сильно облегчить задачу из-за дыр в конкретном одном решении. Ну и людей, которые качают из интернета фотографии с расширением exe под виндой и потом «открывают» их ты этим не вылечишь.
> Кого «можно заменить»? «journald»? Киньте, пожалуйста, ссылку на HOWTO.
Ну как я тебе кину ссылку на то, что никто ещё не написал? По крайней мере я не видел, чтоб написал. Возьми код journald (http://cgit.freedesktop.org/systemd/systemd/tree/src/journal) и выкинь оттуда всё, что не требуется для работы тех двух опций. Не думаю, что это займёт больше пары дней. Будет тебе минимальный демон-потребитель для сообщений журнала. Дальше можешь что угодно из него сделать. Или ты мне предлагаешь это сделать за тебя? Так мне ж это не нужно.
> С чего вы это взяли?
Как-то привык, что тут очень много народу, которые даже не пытаются разобраться в проблеме. Ну что ж, значит вы — приятное исключение с опытом.
> Просто любопытства ради, а Вы?
Работаю «на дядю» и для себя на Qt поделки делаю, в серьёзных открытых проектах пока не участвую.
> А куча отдельных решений, каждое со своим набором багов и глюков тебе кажется более надёжным?Сейчас, мы конечно же, увидим статистику по открытым багам системд и сторонних решений а так же это в динамике...ну за последний год. Конечно прекрасно было бы увидеть степень критичности багов в обоих системах. Но пока подождём ответа в виде простой статистики. Тебя же я смотрю не затруднит это сделать.
> А то, что у них общее ядро и иксы тебя не смущает?
А уже линух без иксов не поставить? Сильно ситуация изменилась пока я час отсутствовал вне пределов линух-компа.
> Ну как я тебе кину ссылку на то, что никто ещё не написал? По крайней мере я не видел, чтоб написал. Возьми код journald (http://cgit.freedesktop.org/systemd/systemd/tree/src/journal) и выкинь оттуда всё, что не требуется для работы тех двух опций. Не думаю, что это займёт больше пары дней.
А может ты сначала что-нибудь на рельсы положишь если формат логов в этом журналд поменяется и придётся всё переписывать? А так же обеспечишь работу настроенных систем у людей. Там graylog2, logstash какой-нибудь? Как ломать и совать в дистры свою дрянь так они первее всех. А как оставить рабочее решения внеся минимум изменений так они в кусты и ну рассказывать сказки про местные велосипеды. Наши чиновничьё прям. Те регулярно какие-то законы принимают и меняют так что без бутылки не разберёшься.
>А уже линух без иксов не поставить?Бинарные дистрибутивы - практически не поставить ("--force" - не наш метод), там каждая мелкая шняга, которая может быть теоретически собрана с иксами, будет таки собрана с иксами и их за собой тащить. Максимум - для нескольких самых-самых распространенных скостылят отдельные пакеты типа vim-nox.
>>А уже линух без иксов не поставить?
> Бинарные дистрибутивы - практически не поставить ("--force" - не наш метод), там
> каждая мелкая шняга, которая может быть теоретически собрана с иксами, будет
> таки собрана с иксами и их за собой тащить.У меня 80% дистрибутивов на серверах — бинарные. И ни на одном сервере нет X-ов. Не знаком с вашей проблемой.
>> То есть это нормально добавлять дополнительную сущность напрямую взаимодействующую через хитрые механизмы с pid1, единственной функцией которой является вызов функции «syslog()», я правильно вас понял?
> Нет, но если хочешь получить логи от самого systemd, то пока придётся.Ну всё как я и сказал. Вы действительно создали машину Голдберга для логирования. Поздравляю.
>> IMHO, что чем больше интерфейсов и модулей имеет systemd, тем он бажнее и имеет большую поверхность для атаки.
> А куча отдельных решений, каждое со своим набором багов и глюков тебе
> кажется более надёжным?Когда у меня есть свобода выбора? Другими словами, когда я могу выкидывать глючные реализации и заменять их менее глючными? Да, мне это кажется более надёжным. Честно.
>> А унификация такой хрени сквозь большниство популярных дистрибутивов Linux может сделать реально живым термин «вирус под linux». =\
> А то, что у них общее ядро и иксы тебя не смущает?Начнём с того, что я на серверах на ставлю Xorg, не знаю, конечно, как вы. А то что Xorg - очень опасная хрень все вроде и так знают, сколько раз мы уже натыкались на серьёзные проблемы безопасности с ним связанными. На большинстве установок Linux в мире никакого Xorg не стоит.
Теперь по поводу ядра:
- Ядро сопровождают действительно грамотные специалисты с многоуровневой проверкой каждого коммита. Я бы даже сказал, элита свободного сообщества. А на самом верху находится Торвальдс.
- Системные администраторы обычно намного более тчательно следят за ядром, чем за всеми user-space приложениями.
- В силу того, что у ядра огроооомнеешее комьюнити, все найденные баги там очень быстро и грамотно исправляют.
- Разные дистрибутивы Linux используют весьма разные версии ядер.
- Забавную вещь вы заявлете, а именно, что в каждом дистрибутиве Linux используется Linux. Хм..В общем, отвечая коротко на ваш вопрос — немного смущает, но лишь совсем немного.
> Ну да, у всех есть свой набор патчей, но это применимо
> и к systemd. Разные велосипеды это лишь иллюзия защиты и ничего
> хорошего в этом нет. Возможно они не позволят создать скринлокера, пригодного
> для всех, но зато если надо сломать конкретный сервер, то это
> может очень сильно облегчить задачу из-за дыр в конкретном одном решении.
> Ну и людей, которые качают из интернета фотографии с расширением exe
> под виндой и потом «открывают» их ты этим не вылечишь.Согласен. Да, только что вредного сделает этот "exe" на системе, где он не знает как навредить? А вот если везде будет одна и та же дырка, то тогда очень просто понять как наверидить.
>> Кого «можно заменить»? «journald»? Киньте, пожалуйста, ссылку на HOWTO.
> Ну как я тебе кину ссылку на то, что никто ещё не
> написал?Ок, тогда в принципе дальше не о чем говорить по данному вопросу, sorry. :)
> По крайней мере я не видел, чтоб написал. Возьми код
> journald (http://cgit.freedesktop.org/systemd/systemd/tree/src/journal) и выкинь
> оттуда всё, что не требуется для работы тех двух опций. Не
> думаю, что это займёт больше пары дней.А я вот думаю это займёт порядком больше времени. А как же отладка? Проверка на всеразличных платформах во всеразличных ситуациях? Я не знаю как у вас, но у меня написание собственного стабильного journald займёт немало времени. А что ещё обиднее, мне journald вообще не нужен, это для меня лишняя сущность, единственная потенциальная функция которого — прослойка.
> Будет тебе минимальный демон-потребитель
> для сообщений журнала.И будет отдельный специальный демон, который через какой-то сложный протокол сообщается с pid1 только лишь для того, чтобы вызывать функцию «syslog()». Спасибо, "очень нужно". Но я так, не совсем по теме. А по теме говоря, вы призвали меня проделать серьёзный труд (IMHO, вы очень сильно недооценили масштабы работ) ради очень простой вещи — заменить одну реализацию на другую. Такие проблемы не свойственны UNIX-way.
> Дальше можешь что угодно из него сделать. Или
> ты мне предлагаешь это сделать за тебя? Так мне ж это
> не нужно.Нет, я просто предлагаю не отдавать приоритет самозапертым software-ные bundle-ам.
>> IMHO, что чем больше интерфейсов и модулей имеет systemd, тем он бажнее и имеет большую поверхность для атаки.
> А куча отдельных решений, каждое со своим набором багов и глюков тебе
> кажется более надёжным?Бернштейн, глядя на qmail, думаю с тобой не согласится.
А тут PID1!
>С такой конфигурацией сервис будет выполнять роль прокси между systemd и старыми системами логгирования и получается, что выключать его не имеет смысла тогда.
> systemctl stop systemd-journald.service
> systemctl disable systemd-journald.service
> Нет?Нет.
У ленарта извращенное понимание слова модульный
Ты имеешь в виду, что на место модулей systemd нельзя засунуть какой-нибудь другой софт? Ну так это у тебя извращённое понимание слова «модульный». Модульность не означает совместимость со всем, что было до него.
> не означает совместимость со всем, что было до него.Хорошая критика, правильно подметил.
>Ты имеешь в виду, что на место модулей systemd нельзя засунуть какой-нибудь другой софт?нет, сам модуль - нельзя вынуть из "модульного" системде :D
>Модульность не означает совместимость со всем, что было до него.
это обратная совместимость. мы тут вообще о другом.
Ок, конкретно этот нельзя. Нужно же systemd и прочим сервисам как-то отдавать логи в какой-либо форме? Не хочешь хранить их в journald — настрой его в качестве прокси к старым системам логгирования и все логи будут падать в них. Кстати, никто не мешает написать модуль-заглушку для journald или модуль, перенаправляющий логи в старые системы логгирования и делающий _только_ это, но почему-то никто до сих пор этого не сделал (видимо потому, что journald так может), зато орать на всю сеть, что выпилить его нельзя, ничто не мешает. Или вам просто из принципа нужно его отпилить и хоть тресни? Ну так это ваши половые трудности.И таки это всё ещё модуль, хоть и критически важный модуль, с точки зрения авторов systemd. Невозможность его выключить не отменят модульность systemd. Его всё ещё можно заменить и это не вина Леннарта, что этого почему-то не делают.
> Ок, конкретно этот нельзя.Да и другие не особо можно. Убунтовцы насколько я понимаю уже натрахались, пытаясь logind к апштарту припилить)
> Ок, конкретно этот нельзя.и другие тоже.
>Нужно же systemd и прочим сервисам как-то отдавать
> логи в какой-либо форме?нет, системде это не нужно. Это нужно логгеру :D
> Не хочешь хранить их в journald —
> настрой его в качестве прокси к старым системам логгирования и все
> логи будут падать в них. Кстати, никто не мешает написать модуль-заглушку
> для journald или модуль, перенаправляющий логи в старые системы логгирования и
> делающий _только_ это, но почему-то никто до сих пор этого не
> сделалЗачем мне это делать? Чтоб после этого мог только подтвердить: да, системде грёбанный монолит?
> И таки это всё ещё модуль, хоть и критически важный модуль, с
> точки зрения авторов systemd. Невозможность его выключить не отменят модульность systemd.Для лённарта модульность - это когда 69 файлов. Своё понимание модульности у чувака.
> Его всё ещё можно заменить
journald? хватит врать)
> и это не вина Леннарта, что этого почему-то не делают.
вина леннарта только в том, что не он один такой придурок.
> нет, сам модуль - нельзя вынуть из "модульного" системде :Dрасскажи-ка нам как ты используешь модуле ядра без самого ядра??? может я что-то пропустил? И это самые удобные проги?
>> нет, сам модуль - нельзя вынуть из "модульного" системде :D
> расскажи-ка нам как ты используешь модуле ядра без самого ядра???Расскажу как вам, и лично тебе, что ядро позволяет не компилировать модуль, и использовать ядро без модуля. В отличие от системде, где системде и журналдэ прибиты один к другому. Но в любом случае, ядро тоже монолитно-модульно, так что даже на него ориентироваться не стоит :D
> может я что-то пропустил? И это самые удобные проги?
ты пропустил.
>> нет, сам модуль - нельзя вынуть из "модульного" системде :D
> расскажи-ка нам как ты используешь модуле ядра без самого ядра???И? Ядро-то «Linux» монолитное [1], дальше-то что? Очень неудачный пример вы привели, честно говоря :). Придерживался бы я вашей позиции выбрал бы… Хотя нет, для защиты вашей позиции не удаётся придумать ниодного примера, sorry)
Модульный, но только чуть-чуть модульный. )Не, спасибо конечно, что не вообще всё в pid 1 пихнули, ага.
Картина ближайшего будущего, порожденная разгоряченным умом.
Командную строку с присущими ей POSIX-штучками упразднена за ненадобностью.
В systemd интегрирован загрузчик. Теперь в системе запускаются только те проги, которые прописаны в конфигурационных файлах systemd. Нужные приложения пользователь может запустить только в файл-менеджере, или системном меню DE, которые в свою очередь стартуют из systemd. Когда пользователь запускает нужное ему приложение, то, например, файл-менеджер передает запрос через super-Dbus в systemd, а уже systemd грузит с диска прогу при помощи встроенного загрузчика и запускает процесс.
Весь обмен данными только через super-Dbus. Конечно, никакого X-го клипбоарда давно нет - весь обмен данными только через super-Dbus (оконные менеджеры с дисплейным сервером и клиентскими програми, клиентские проги с дисплейным сервером, и т.д. и т.п.).
Даже сетевые приложения не соединяются через сокет с удаленными хостами. Они подключаются к super-Dbus, super-Dbus дает запрос systemd, а systemd запускает необходимый сервис, который уже ведет обмен с удаленным хостом через сетевой сокет.
А если серьезно, то может кто-нибудь объяснит к чему все это? То и дело все читаю, как в systemd интегрирован udev, дисплейный менеджер, менеджер сети и т.п. и т.д.
Но ведь systemd это вроде как всего лишь средство для старта и остановки в нужный момент определенных сервисов. По логике для systemd вообще должно быть безразлично, какой сервис запускается, или останавливается. Главное соблюсти нужную последовательность и не нарушить зависимости. А что какой сервис конфигурит, или обслуживает, ему должно быть по барабану. Вот тогда это правильная модульная система.
А сейчас, чем дальше, тем больше получается нечто монстрободобное, делающее все.
systemd-OS
> По логике для systemd вообще должно быть безразлично, какой сервис запускается, или останавливается.У вас и ленорта совсем разная логика. Основная фишка сделать systemd критическим компонентом системы, без интеграции нечего работать не будет. Это интерпрайс детка. В MS уже давно такое, да и в большенстве корпоративных систем. Заказчик должен платить бабло. А бабло за скриптики наколенные не кто платить небудут,
а вот за 10к строк на си в которых разбираются 100 человек в мире. Вполне можно слупить бабла. И тут даже ленарт не виноват это просто бизнес, а он просто исполнитель. Но нужно себя утешать чемто и внушать что ты делаешь благое дело и это полезно.
> Командную строку с присущими ей POSIX-штучками упразднена за ненадобностью.
> Нужные приложения пользователь может запустить только в файл-менеджере, или системном меню DE, которые в свою очередь стартуют из systemdЭта фантазия становится ещё веселей, если вспомнить, что даже микрософт уже давно всё осознал и давно впиливает в свои серверные системы штуки типа powershell или core mode.
нифига.
systemd грузит с диска ядро, а потом уже прогу
>Когда пользователь запускает нужное ему приложение, то, например, файл-менеджер передает запрос через super-Dbus в systemd, а уже systemd грузит с диска прогу при помощи встроенного загрузчика и запускает процесс.fixed: Когда пользователь запускает нужное ему приложение, то, например, файл-менеджер передает запрос через super-Dbus в systemd, systemd, посредством сетевой подсистемы, передаёт запрос в АНБ, в случае утвердительного ответа, systemd грузит с диска прогу при помощи встроенного загрузчика и запускает процесс.
API. Новый выпуск ориентирован в первую
очередь на наращивание функциональности и содержит большую порцию нового кода, поэтому он требует дополнительной стабилизациидаааааа, давайте выпустим велосипед с не затянутыми болтами, и по переломам пользователей опрпделим как переделать раму.
больше глюков скрытных и разных!!
да здравствует леннарт.
С каждым подобным релизом дебиановцы будут обливаться потом в три ручья. Занятный гемор себе наголосовали
> С каждым подобным релизом дебиановцы будут обливаться потом в три ручья. Занятный
> гемор себе наголосовалиэто их проблемы, дебиан видители начал подбираться к корпоративным системам, а теперь ему там нечего не светит.
хотя и раньше перспективы были не ахти. Могу потлько поздравить менеджмент редхата с успешным внедрением.
> дебиан видители начал подбираться к корпоративным системам, а теперь ему там нечего не светит.Ну почему же... В свете последних событий вполне вероятно, что RedHat не откажет в платной поддержке серверов на Debian. ;D
Когда в *BSD будет?
> Когда в *BSD будет?http://openbsdfoundation.org/gsoc2014.html (где-то посередине)
Всех поздравляю с новой версией хорошего инструмента!
> Всех поздравляю с новой версией хорошего инструмента!Кaйлo и лoпата для зaкaпывания линукса действительно знатные вышли :)
> Кaйлo и лoпата для зaкaпывания линукса действительно знатные вышли :)Это кайло по крайней мере не пытается втирать очки относительно того что боингом можно рулить и путем дергания элеронов за веревочки, честно признавая что парочка бортовых компьютеров - не лишние.
>> Кaйлo и лoпата для зaкaпывания линукса действительно знатные вышли :)
> Это кайло по крайней мере не пытается втирать очки относительно того что
> боингом можно рулить и путем дергания элеронов за веревочки, честно признавая
> что парочка бортовых компьютеров - не лишние.Странно что такие тупые в мс начали выпиливать весь этот гуй боингов. И переходят на веревочки и сопли из пауршелла и прочей скриптотни.
вот в этом и есть вся беда отрасли
только уголовная ответственность за баги пасёт мир
Ну да - нет программистов, нет кода, нет багов, нет проблемы.
> вот в этом и есть вся беда отрасли
> только уголовная ответственность за баги пасёт мирВы хотели сказать, что беда отрасли в излишне разумных индивидуумах в этой отрасли занятых.
Уголовная ответственность это для тех людей, которые сами себя контролировать не могут. Мне кажется, что в этой отрасли таких немного, или я не прав?
Может все таки "Золотая середина"!?!?! Где то же она все таки есть!
GNU/Linux всё дальше и дальше катится от той операционной системы, которая мне когда-то нравилась.
> GNU/Linux всё дальше и дальше катится от той операционной системы, которая мне
> когда-то нравилась.Gentoo вроде далёк от этих проблем. ;)