LINUX.ORG.RU
Новости — Open Source  

systemd 219

 


3

4

16 февраля был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые вспомогательные задачи (т. н. plumbing layer) — от настройки подсистемы VT (systemd-vconsole-setup) и первичного конфигурирования системы (systemd-firstboot) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

Большая часть изменений, вошедших в этот релиз, была направлена на расширение возможностей по работе с контейнерами. Эти изменения сконцентрированы в компонентах systemd-machined и systemd-nspawn и нескольких сопутствующих утилитах.

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

Изменения в ядре systemd:

  • При остановке mount-юнита, соответствующего директории, на которую примонтировано более одного устройства, теперь производится отмонтирование всех устройств на этой точке монтирования. [Раньше, надо полагать, отмонтировалось только последнее. Более того, примонтировать несколько устройств на одну директорию средствами mount-юнитов по-прежнему невозможно. — Прим. пер.]
  • device-юниты, соответствующие приводам оптических дисков, теперь считаются активными только при наличии диска в приводе.
  • Все mount-юниты теперь автоматически получают зависимость BindsTo= от «своих» device-юнитов. Вкупе с предыдущим изменением это обеспечивает автоматическое [небезопасное, но так хотя бы /etc/mtab не захламляется — Прим. пер.] отмонтирование дисков и других носителей при их извлечении.
  • Введена концепция «неподдерживаемых» типов юнитов. Так, например, при попытке активировать busname-юнит на системе без kdbus он будет помечен как сбойный с комментарием «unsupported».

    Список типов юнитов, не поддерживаемых на некоторых конфигурациях:

    • .busname — на системах без kdbus;
    • .swap — в контейнерах; на системах с CONFIG_SWAP=n;
    • .automount — в контейнерах; на системах с CONFIG_AUTOFS4_FS=n;
    • .device — в контейнерах.
  • Суммарное потребление памяти всеми процессами юнита (атрибут memory.usage_in_bytes соответствующей контрольной группы) теперь экспортируется как свойство MemoryCurrent объекта юнита на шине и отображается в выводе команды systemctl status. Например:
    $ systemctl status systemd-journald
● systemd-journald.service - Journal Service
[...]
 Main PID: 210 (systemd-journal)
   Status: "Processing requests..."
   Memory: 90.4M
[...]

$ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1/unit/systemd_2djournald_2eservice org.freedesktop.systemd1.Service
NAME                                TYPE      SIGNATURE      RESULT/VALUE                             FLAGS
[...]
.MemoryAccounting                   property  b              true                                     -
.MemoryCurrent                      property  t              94887936                                 -
[...]

    [Стоит отметить, что это свойство отражает суммарный RSS и объём файлового кэша процессов в контрольной группе. Также, разумеется, это возможно только при задействовании контроллера memcg, т. е. CONFIG_MEMCG=y в конфигурации ядра и DefaultMemoryAccounting=true в /etc/systemd/system.conf. — Прим. пер.]

  • Генераторы юнитов теперь можно маскировать (по аналогии с самими юнитами), размещая в /{etc,run}/systemd/system-generators/ пустые файлы (или симлинки на /dev/null).
  • Для юнитов, присоединённых к терминалу (StandardInput=tty, StandardOutput=tty), будет автоматически устанавливаться переменная окружения TERM=vt220 (вместо vt102, как было ранее). Это должно исправить ошибки в приложениях, использующих нетривиальные возможности терминала (например, клавиши PgUp/PgDn).
  • Добавлен механизм, позволяющий процессам «сохранять» в PID 1 открытые файловые дескрипторы (например, на время собственного перезапуска). Эта возможность уже задействована в systemd-journald для того, чтобы избежать потери сообщений при перезапуске.

    Таким образом, все три «ключевых» компонента systemd (systemd, logind, journald) теперь способны перезапускаться с сохранением состояния.

    Технически этот механизм реализован через расширение API sd_notify(3) (функция sd_pid_notify_with_fds()). Для прикрепления файловых дескрипторов к сообщению используется концепция fd passing, а само сообщение должно содержать строку FDSTORE=1.

    Количество файловых дескрипторов, которое процессы юнита могут единовременно «сохранить» таким образом, ограничивается значением директивы FileDescriptorStoreMax= в секции [Service] unit-файлов (по умолчанию 0, т. е. нисколько).

  • Нажатие Ctrl-Alt-Del более семи раз в течение двух секунд теперь вызывает аварийный перезапуск системы, эквивалентный результату выполнения systemctl reboot -f (т. е. при этом все процессы завершаются, а файловые системы демонтируются или переводятся в режим «только для чтения»). Этот механизм стоит рассматривать как более «щадящую» альтернативу Alt-SysRq-B.
  • В файле /etc/crypttab (за его обработку отвечает systemd-cryptsetup-generator) добавлена поддержка параметра header= (как в Debian). Этот параметр позволяет указать расположение LUKS-заголовка, если он хранится на отдельном устройстве.
  • При копировании куда-либо каких-либо файлов (например, в контексте действия C в systemd-tmpfiles) компоненты systemd теперь сначала пытаются создавать reflink (на тех ФС, которые это поддерживают, в частности, btrfs и ocfs2). При отсутствии поддержки выполняется обычное копирование.

Изменения в утилитах и вспомогательных компонентах:

  • Команды loginctl user-status, loginctl session-status и machinectl status теперь также выводят (подобно systemctl status) последние несколько строчек из лога, ассоциированных с данным пользователем, сессией или контейнером соответственно. При этом в последнем случапе имеется в виду не внутренний лог самого контейнера, а лог того юнита, в котором он запущен (т. е., например, вывод systemd-nspawn).
  • Все подкоманды loginctl, которые принимают в качестве аргумента идентификатор сессии или имя пользователя (например, две вышеупомянутые), теперь могут быть вызваны без аргумента. В этом случае они применяются к той сессии, в которой (к тому пользователю, от имени которого) запущены.
  • В systemd-run добавлен параметр командной строки -t (--pty), позволяющий перенаправить ввод/вывод запускаемого процесса в текущую консоль (при этом он всё равно запускается как дочерний процесс systemd). Стоит отметить, что это также поддерживается при запуске процесса в другом контейнере.

    Например, команда systemd-run -t /bin/bash запустит рутовую оболочку в обход PAM и регистрации сессии.

  • В systemd-tmpfiles добавлено действие v — создание btrfs subvolume по указанному пути. В случае невозможности (если используется другая ФС) создаётся обычная директория (эквивалентно действию d).
  • В systemd-tmpfiles добавлено действие a — назначение файлу заданных ACL.
  • В комплект поставки включён скрипт для xinitrc.d, который сообщает systemd --user текущие значения переменных $DISPLAY и $XAUTHORITY. Это позволит «из коробки» запускать с помощью systemd --user графические приложения, взаимодействующие с X-сервером.

    [При этом никаких дополнительных зависимостей не проставляется, поэтому при завершении работы X-сервера все эти приложения не будут корректно прибиты и упадут вслед за сервером. Но лучше так, чем никак. Ждём, пока кто-нибудь придумает, как вписать иксы или вейланд в эту концепцию. — Прим. пер.]

  • В спецификацию формата файла /etc/os-release добавлено новое поле PRIVACY_POLICY_URL=, позволяющее создателям дистрибутива указать ссылку на его Privacy Policy.

Изменения в udev:

  • Часть API libudev, относящаяся к работе с hwdb (декларативной базой данных оборудования), вынесена в отдельную библиотеку sd-hwdb (заголовочный файл sd-hwdb.h), отделённую от libudev.

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

  • Эта самая hwdb теперь включает в себя информацию о «разрешающей способности» колёс прокрутки мышей (что-то вроде «повороту на какой угол соответствует одно событие») и различные сведения о тачпадах.

    [Напомню, что в версии 218 в hwdb начали собирать информацию о разрешающей способности самих оптических сенсоров мышей. Это делается для того, чтобы настройки ускорения курсора и скорости прокрутки работали одинаково на любом оборудовании. Разумеется, необходима поддержка этих свойств со стороны того, кто будет обрабатывать события с устройств ввода; насколько мне известно, это пилят в libinput. — Прим. пер.]

  • Физические размеры сенсорных экранов теперь отражены в атрибутах соответствующих им устройств ввода.

Изменения в journald:

  • systemd-journald теперь устанавливает btrfs-специфичный флаг FS_NOCOW на файлах журнала. Это должно повысить производительность на btrfs, поскольку типичная последовательность обращений к этим файлам [то, как journald работает с этими файлами] достаточно плохо ложится на механизм Copy-on-Write.

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

    Ещё одно изменение состоит в том, что systemd-journald теперь более корректно обрабатывает события переполнения диска (а именно — сигнал SIGBUS для файлов, отображённых в память) в тех случаях, когда использование fallocate(2) по тем или иным причинам не гарантирует выделения места. [Видимо, имеются в виду Copy-on-Write-ФС, отличные от btrfs. — Прим. пер.]

  • При удалении текущего файла журнала (того, в который сейчас ведётся запись) systemd-journald теперь это замечает и немедленно начинает запись в новый файл.

В networkd добавлена поддержка:

  • FDB-таблиц для соединений типа «мост» (секция [BridgeFDB] network-файлов);
  • сбора LLDP-оповещений (отображаются в выводе утилиты networkctl);
  • нескольких новых типов виртуальных сетевых устройств, а именно ipvlan, gretap, ip6gre, ip6gretap и ip6tnl (директива Kind= секции [NetDev] netdev-файлов);
  • автонастройки link-local IPv6-адресов (директива LinkLocalAddressing= секции [Network] network-файлов);
  • настройки перенаправления и маскарадинга IPv4/IPv6 отдельно для каждого интерфейса (директивы IPForward=, IPMasquerade= секции [Network] network-файлов);
  • явного задания scope (global, link, host) для создаваемых маршрутов (директива Scope= секции [Route] network-файлов);
  • явного задания нижних 64 бит IPv6-адреса при задействовании SLAAC (директива IPv6Token= секции [Network] network-файлов);
  • перечислений и wildcard'ов в директивах секции [Match] всех файлов конфигурации.

    [например, можно указать список MAC-адресов, к которым нужно применить link-файл, или же что-то вроде Name=en* — Прим. пер.]

Другие изменения в networkd:

  • Утилита systemd-networkd-wait-online теперь позволяет указывать подмножество интерфейсов, настройки которых требуется дождаться, и таймаут этого ожидания.
  • systemd-networkd теперь автоматически завершается, когда ему нечего делать (это случается, когда все присутствующие интерфейсы либо не требуют настройки, либо конфигурируются статически). При появлении в системе новых интерфейсов networkd запускается заново, для чего используется вариант механизма сокет-активации.

Изменения, связанные с поддержкой контейнеров:

  • Директория /var/lib/containers, предназначенная для хранения файловых систем контейнеров и образов ВМ, переименована в /var/lib/machines ради единообразия терминологии.
  • Добавлен юнит machines.target, группирующий все автозапускаемые контейнеры в системе.
  • В утилите systemd-nspawn добавлены следующие параметры командной строки:
    • --template (только btrfs) — указание эталонного дерева ФС, которое будет скопировано в корневую директорию контейнера (--directory) в случае отсутствия последней;
    • --ephemeral (только btrfs) — запуск контейнера без внесения изменений в его корневую директорию посредством создания временного btrfs-снапшота этой директории (например, можно сделать systemd-nspawn --ephemeral --directory / и запустить в контейнере копию ОС хоста, не мешая самому хосту);
    • --image — запуск контейнера из образа диска с таблицей разделов MBR или GPT (при этом раздел должен быть один — или, в случае GPT, все разделы должны быть помечены согласно спецификации);
    • --machine, -M — запуск контейнера из дерева ФС или из образа c указанным именем в /var/lib/machines;
    • --network-veth, -n — создание для контейнера собственного veth-интерфейса (теперь для этих интерфейсов по умолчанию задействована вышеописанная директива IPMasquerade=yes, что даёт контейнеру доступ ко всем сконфигурированным на хосте сетям);
    • --port, -p — «проброс» указанного порта из контейнера в хост-систему (в сочетании с --network-veth это позволяет запускать в контейнерах серверные приложения так, как будто они запущены на хосте).
  • Прочие изменения в systemd-nspawn:
    • На директорию /tmp внутри контейнера теперь автоматически монтируется tmpfs
    • Реализована защита от повторных запусков одного и того же образа (read-write блокировка)
    • Почти вся иерархия контрольных групп (/sys/fs/cgroup) теперь отображается внутрь контейнеров (в режиме read-only, за исключением собственного поддерева контейнера)
  • В команде machinectl, предназначенной для взаимодействия с менеджером контейнеров systemd-machined, добавлены следующие подкоманды:
    • machinectl list-images, machinectl image-status — отображение информации об образах контейнеров в /var/lib/machines;
    • machinectl start — запуск контейнера с помощью systemd-nspawn -M (эквивалент systemctl start systemd-nspawn@<имя>);
    • machinectl clone (только btrfs), machinectl rename, machinectl read-only, machinectl remove — различные операции с образами в /var/lib/machines;
    • machinectl copy-from, machinectl copy-to — копирование файлов из контейнера на хост или в обратном направлении;
    • machinectl bind (только systemd-nspawn) — bind-монтирование директорий из хоста в контейнер;
    • machinectl pull-tar, machinectl pull-raw, machinectl pull-dkr (на данный момент только btrfs) — загрузка и распаковка в /var/lib/machines, соответственно, архивов ФС, образов дисков и образов Docker.
  • Последние три подкоманды, предназначенные для загрузки образов контейнеров из Интернета, обеспечивают реализованы посредством нового демона — systemd-importd. Он обеспечивает загрузку данных в фоновом режиме.

P. S.: Да будет срач.

>>> Объявление о релизе

★★★★★

Проверено: beastie ()
Последнее исправление: beastie (всего исправлений: 7)
← Представлен первый кандидат в релизы ядра Linux Kernel 4.0
PulseAudio 6.0 →
  1 2 3 4 5 6 7 8

Ненужно написало новость про ненужно. Найди уже себе девушку и перестань дрочить на говнокод

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

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

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

Оверхед на индексирование (он невелик) не мешает, потому что 1) сообщения всё равно генерируются медленнее (почти всегда), 2) есть буфер, 3) периоды «всплеска» интенсивности появления новых сообщений в нормальных условиях невелики.

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

Опять же вопрос: _зачем_ нужно индексирование???? Ускорить поиск. На кой нужно ускорять поиск при записи? В журнале!!

Опять изначально кривой дизайн приводит к героическим поступкам по устранению последствий. Леня, по-ходу из СССР — наша логика, «зачем думать? прыгать надо». Или ему за строчки кода платят, как индусам, вот он и строчит всякую хрень, чтобы бабло шло.

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

Приведите пример хотя бы 3 «очевидных причин», причем для десктопа.

С точки зрения формата файла — по постановке задачи.

Про это вам и говорят, что изначально кривая постановка задачи типа «вдруг кому-то захочется» или «это будет круто» приводят к таким уродским дизайнам и, соответственно, к реализации.

Что касается вопросов про текст: в текстовый файл, безусловно, тоже можно всё это впихнуть, но тогда он станет практически нечитаемым (будет слишком много метаданных). Поэтому это не несёт реальной выгоды, а оверхед создаёт.

Какие метаданные вам нужны в текстовом файле журнала? Про позиционное разделение полей в тексте вы не слышали или про CSV? Что такое пишется в журнал, что ему нужны развернутая система именования полей? Вы не путаете текстовые файлы с JSON или XML?

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

Что за ерунда? Вы когда-нибудь выковыривали что-то из бинарных файлов руками? Или чисто умозрительный опыт? А не проще было оставить текст?

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

Следуя вашей логике, спрошу, если для предобработки журнала перед анализом/чтением, нужно использовать спец-преобразователи, почему нельзя было использовать предобработку простых текстовых логов вместо создания велосипеда с индексами?

dr_dobermann ★
()
Последнее исправление: dr_dobermann (всего исправлений: 1)

когда на нём можно будет слушать фильмы и смотреть музыку?

anonymous
()

Господа хейтеры забывают, что до системд было такое лютейшее говно как Policy Kit, ConsoleKit и им подобные

buddhist ★★★★★
()
Ответ на: комментарий от like-all

buddhist

polkit никуда не делся, но его перепилили недавно (собственно, и переименовали из PolicyKit в polkit). Теперь там правила можно на js писать, что меня неимоверно радует.

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

Хватит устраивать клоунаду. Начиная с самого первого ответа — очевидно, что под «что захочется сделать» подразумевается «по какому полю потребуется отфильтровать». Дальше — я на всё уже отвечал, и неоднократно. Повторяться не желаю.

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

Согласен, хватит, улыбнули неоднократно.

От души вам аплодирую, особенно с учетом фильтрации и индексации по бинарным данным в логах.

Похоже вы более уперты, чем даже сам Лёня, если на корректно заданные вопросы отвечаете какой-то бред.

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

Нет, пусть лучше дрочит на говнокод. От девушки такое же ненужное потомство появится.

anonymous
()

Нажатие Ctrl-Alt-Del более семи раз в течение двух секунд теперь вызывает аварийный перезапуск системы

Ну офигеть теперь, фанаты systemd будут пианистов косплеить

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

Ну и наконец, действительно ли Линукс-сообщество хочет сосредоточить все ключевые подсистемы в руках одного вендора?

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

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

мне тоже в systemd много чего не нравится и уж тем более много чего непонятного. Приходится пересобирать.

Непонятно лечится чтением документации, а не пересборкой. Если, конечно, ты не упоротый гентушник - тогда вопросов нет.

anonymous
()

Столько надрыва, разрыва и срыва нет, пожалуй, ни по одному тегу.

Systemd, спасибо, что ты есть!

Deleted
()
Ответ на: Почему на самом деле не нужен systemd от Croco

Я могу себе позволить заявить, что я НЕ ХОТЕЛ это осиливать, потому что у меня есть существенно лучшие идеи, как потратить время.

Сколько бы мне потребовалось времени, чтобы понять, как обращаться с systemd? День? Два? Неделя? Примерно представляя масштабы катастрофы, я скорее склонен думать, что да, неделя.

Ну конечно, мог, но это потребовало бы времени.

Т.е., обобщая, Вам жалко тратить драгоценное время на изучение новых технологий.

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

А здесь Вы говорите, что всё-таки тратили время на изучения линукса. Иначе говоря, те (устаревшие) знания, которыми Вы обладаете, не появились вдруг, единовременно. Вы потратили время на изучение.

Раньше знал, а теперь вот со всеми этим апстартами и прочими systemd — получается, что не знаю. Эй, вы куда дели мои возможности?

Так Вы же отказываетесь изучать новые технологии. А прогресс не стоит на месте.

Раньше я знал, как раскочегарить паровоз и сдвинуть его с места, а теперь вот со всеми этими тепловозами и прочими электровозами — «получается, что не знаю. Эй, вы куда дели мои возможности?»

Интересно, в своё время, например, когда отменили ipchains и внедрили iptables, Вы так же возмущались?

Между тем, наблюдаю, как вокруг люди тратят время на изучение systemd.

Чтобы не оказаться как Вы — у разбитого корыта со своими устаревшими никому не нужными знаниями.

И, кстати, для новых, молодых специалистов Linux, приходящих сейчас, в общем нет альтернативы и они вынуждены изучать именно systemd, как Вы в своё время были вынуждены изучать именно SysV init — другого не было.

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

Это можно сказать про любую новую технологию. Вот, например, с точки зрения виндузятника:

Господа сторонники Linux, я обвиняю вас в серийных убийствах.

P.S. До сороковника мне ещё немного не хватает и с Linux'ом работаю с 1998 года, но меня не страшит systemd, grub и NetworkManager. Может их достоинства и не всем очевидны (и grub, и NetworkManager меня поначалу тоже раздражали), но я не хочу вслед за Вами отправляться на свалку истории.

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

Не у всех. У некоторых этой кнопки вообще нет.

По крайней мере, пока systemd не включает в себя оконный менеджер.

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

Ты — примерно пятый петросян за тред.

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

Т.е., обобщая, Вам жалко тратить драгоценное время на изучение новых технологий.

Минуточку, вот чего с детства не люблю, так это подобной подмены предмета. Впрочем, в эту игру можно играть вдвоём: скажите-ка, а вы всерьёз полагаете, что любая технология достойна изучения только потому, что она новая? Ну так я сейчас своих студентов попрошу кусочек чего-нибудь ненужного (но безусловно нового) слепить специально для вас, причём специально попрошу, чтобы было побольше и поненужнее, у меня студенты толковые, слепят. Будете изучать? :-)

Возвращаясь к теме: мне жаль (действительно жаль) тратить драгоценное (во всех смыслах) время на изучение НЕНУЖНЫХ технологий. Systemd очевидным образом создаёт проблемы, при этом все утверждения о том, что он какие-то проблемы решает, заведомо несостоятельны: я этих проблем за двадцать лет работы с Линуксом не видел ни разу, то есть их просто нет, они чисто мнимые.

А прогресс не стоит на месте.

К дьяволу, какой это прогресс?! Это мракобесие называется. Прогресс — это когда решают реально существующие проблемы. А тут, прикрываясь решением несуществующих проблем, нам (ну хорошо, лично мне) создают на ровном месте новые.

Интересно, в своё время, например, когда отменили ipchains и внедрили iptables, Вы так же возмущались?

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

Когда вводится _нужная_ новая технология, у пользователя всегда есть возможность выбора. Те же паровозы работали на одних железных дорогах с тепловозами и электровозами в течение почти полувека.

Чтобы не оказаться как Вы — у разбитого корыта со своими устаревшими никому не нужными знаниями.

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

Впрочем, я вам одну интересную вещь скажу: я знаю только один дистрибутив Linux, который реально можно использовать на серверах, и это Openwall. Там SysVinit, и это вряд ли изменится. Больше того, там LILO. Так что ещё поглядим, кто у какого корыта останется в итоге.

Это можно сказать про любую новую технологию.

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

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

Господа хейтеры <…>

Господа хейтеры — вообще зверушки забавные. Кто-нибудь еще помнит, как народ в свое время разорялся по поводу udev? Мол, раньше раз и навсегда созданные файлы устройств всех устраивали (а кого не устраивали, у тех был rm /dev/whatever), но нет, надо было сделать devfs, потом выкинуть devfs, сделать hal, выкинуть hal… А потом тот же самый народ в тех же самых выражениях разорялся по поводу включения кода udev в дерево исходников systemd. А сколько эмоций было по поводу UTF-8 (не будем показывать пальцем на ненавистников "хрюникода", у которых эмоции остались по сию пору)? А с каким скрипом слезали с lilo на grub (а затем на grub2)? Хейтерз гонна хейт, что тут еще сказать.

NB: сугубо для протокола — systemd не отменяет и не подменяет собой polkit.

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

Интересно, в своё время, например, когда отменили ipchains и внедрили iptables, Вы так же возмущались?
В принципе, нет, поскольку ни тот, ни другой интерфейс я наизусть не помнил, а в какой из двух манов смотреть — мне более-менее всё равно. Но принцип вы уловили верно: да, подобные замены являют собой повод для возмущения.



Появление iptables вместо ipchains было огромным прорывом. Например, ipchains не умел пробросить порт внутрь, например так:


-A PREROUTING -p tcp -m tcp -d INET_IP -i eth2 --dport XXX -j DNAT --to-destination INNER_IP:YYY

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

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

Действительно, интересно, чем он лучше той же центоси?

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

Появление iptables вместо ipchains было огромным прорывом.

Да кто бы спорил, уж точно не я — я сам static nat использую, и, помнится, меня даже несколько бесил тот факт, что на cisco это можно было сделать, а на linux box нельзя.

Но суть не в том, что это был прорыв (хотя в этом плане, я готов согласиться, оно существенно отличается от обсуждаемого здесь никому не нужного монстра). Основная суть в том, что static nat нужен далеко не всем, а изучать новый (и, заметим, несколько более заковыристый) интерфейс заставили всех. Именно заставили, не оставив никакого другого выхода. Вот был отстроенный и годами не меняющийся набор настроек, про него давно думать забыли, тут хрясь — и всё, иди изучай, как то же самое сделать на новом инструменте, и быстренько, быстренько, пока через дыру, образовавшуюся на месте исчезнувшего пакетного фильтра, кто-нибудь не просочился.

Канделябром за такое отношение к людям, канделябром.

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

Дык ещё бы интересно было, ага. Особенно если учесть, что я ваши тезисы (все) предусмотрел, когда писал свой исходный коммент, и на них (опять же, все) заранее ответил, и про новые технологии, и про разбитое корыто; это было несложно, у сторонников подобных проявлений «технического прогресса» аргументы каждый раз одни и те же. Но вы всего этого предпочли не заметить, привели аргументы, которые уже опровергнуты, а потом вас неприятно удивило, что это не сработало; мне-то, замечу, оставалось только переформулировать то, что уже сказано. Дык это, не интересно — не дискутируйте :-)

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

Мне почему то вспомнились windows 95

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

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

Воу! Да ты еще и профнепригоден. Старпер, вали из IT, тебе тут не место.

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

перечислю тебе критерии обоссаности: - в дистре используется dpkg - дистр просто набор пакетов последнего софта и кроме этого общедоступного софта не имеет никакой добавочной стоимости

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

запихивая systemd + busybox + ядро на дисковое пространство размером с дискету.

А нахрена? Уже давно 21 на дворе.

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

«Вот официальный стабилити промис, вот более детальный расклад, вот» вы что смеетесь? вот это 'Some of the «special» unit names and their semantics. To be precise the ones that are necessary for normal services, and not those required only for early boot and late shutdown, with very few exceptions. To list them here: basic.target, shutdown.target, sockets.target, netw' или 'The D-Bus interfaces of the main service daemon (!) [ An additional restriction applies here: functionality we consider legacy might not be available based on compile-time options,' тоесть то что мы (я ЛеняП) хотим считать зарезервированным мы будем считать зарезервированным тогда когда захотим. а то что захотим считать устаревшим (точнее то что я великий ЛенП) посчитаю устаревшим то и не буду поддерживать.

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

А что мешает тем, кому не по душе systemd просто его не использовать, а использовать дистрибутив не использующий systemd?

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

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

хрень кторая начинается со слов - «We are making this available primarily to allow review and provide documentation. Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right» документацией на формат журналд не является. это предварительные набороски на салфетке которые надо проверять сравнивая с исходниками каждой свеже[ну сами поняли какой] версии.

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

«Господа хейтеры забывают, что до системд было такое лютейшее говно как Policy Kit, ConsoleKit и им подобные» первый вроде некуда не делся. но главное это были локальные фигни не втаскивающие в себя половину утилит и главное не лезущие туда куда не просят.

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

X-Plane — нахожу его более реалистичным...

Может ещё и на CPL примериваешься?

Всё может быть :] 

ATC: Cessna G-ABCD, what are your intentions?
Cessna: To get my Commercial Pilot's Licence and Instrument Rating.
ATC: I meant in the next five minutes, not years.

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

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

И какая же у винды философия?

anonymous
()

Кстати, в это воскресенье очередной open source meetup в Берлине. Кто хочет дёрнуть по пиву со мной и Леннартом?

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

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

Всё верно, кроме последнего: ты видал как технично баттхёртиан на лохах бабло поднял? И ведь юридически не подкопаешься! Так что ни программировать, ни администрировать они, конечно, не умеют, но соображают будь здоров :)

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

Философия — это тоже важно. Она дала основу для создания системы, которой пользуется большинство посетителей этого сайта. Поэтому не стоит относиться столь презрительно к ней. :)

ты очередной неуч, который думает что от философии произошла математика?

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

и где сейчас udev?

В ред хэте (и производных), сусе (и производных), дебиане (и производных). А что, где-то его нет?

dexpl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5 6 7 8
← Представлен первый кандидат в релизы ядра Linux Kernel 4.0
Open Source
PulseAudio 6.0 →