Systemd 29

>> В Debian pidof в sysvinit-utils, mountpoint - в initscripts.

sysvinit-utils собирается из исходников sysvinit.

И что? Ты можешь удалить sysvinit, но оставить pidof. В генте так можно?

> SysVinit объединяет в себе совершенно несвязанные программы. Как сказал анонимус, «объединять httpd, gdm, udev и git в одном демоне - это маразм»

Для протокола: sysvinit не объединяет pidof, mountpoint и init в одном демоне.

Это вполне нормально. Разработчики не делают пакет, они делают программу. Разбивать по пакетам — не их работа.
Ещё бы о freebsd начал рассуждать тут, блин.

>Для протокола: sysvinit не объединяет pidof, mountpoint и init в одном демоне.

Согласен. Но что делают исходники 3 совершенно разных программ, ничем не связанных, в одном архиве? Почему разработчик так вообще поступил? ИМХО pidof должен быть в procps, а mountpoint в coreutils. Может, в других пакетах, которые ближе по смыслу, но никак не в ините.

> Но что делают исходники 3 совершенно разных программ, ничем не связанных, в одном архиве? Почему разработчик так вообще поступил?

Потому что на момент написания sysvinit этих программ не существовало, и разраб их написал - специально для sysvinit // К.О.

>Но что делают исходники 3 совершенно разных программ, ничем не связанных, в одном архиве? Почему разработчик так вообще поступил?
Потому, что он их сделал, ёпт. Он же не бинарники запаковал.

mountpoint в coreutils

coreutils вроде бы делают совершенно другие люди.

>Потому что на момент написания sysvinit этих программ не существовало, и разраб их написал - специально для sysvinit // К.О.

Их надо было не в свой пакет пихать, а в procps и coreutils. Там они уместнее.

>> Потому что на момент написания sysvinit этих программ не существовало, и разраб их написал - специально для sysvinit // К.О.

Их надо было не в свой пакет пихать

Твой идеализм не позволит тебе выжить в этом мире %)

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

> какого чёрта команды pidof и mountpoint делают в пакете sys-apps/sysvinit?

Попробую угадать - они используются в этом пакете и потому в нем и лежат, да?

>Попробую угадать - они используются в этом пакете и потому в нем и лежат, да?

Не угадал. Голый init без скриптов (который в этом пакете) их не использует. Значит, по-нормальному, нужна зависимость пакета _скриптов_ от procps и coreutils, в которых должны быть pidof и mountpoint.

Удачи тебе в мире скриптов на С. И веба на С++, чтоб жизнь раем не казалась.

Удачи тебе в мире скриптов на С. И веба на С++, чтоб жизнь раем не казалась.

Ты не понял - С для скриптов никто и не использует а вот использовать для этого Лисп - нахер не нужно, так же как и C++ для веба. Для загрузочные скриптов хорошо подоходит Lua например:

-- vim:set ft=lua:

local lxname = "vmlinuz";
if L4.Info.arch() == "arm" then
  lxname = "vmlinuz.arm";
end

vbus_l4lx = L4.default_loader:new_channel();

L4.default_loader:start(
  {
    caps = {
      icu = L4.Env.icu,
      sigma0  = L4.cast(L4.Proto.Factory, L4.Env.sigma0):create(L4.Proto.Sigma0),

      l4lx = vbus_l4lx:svr(),
    },
    log      = { "io", "y" },
    l4re_dbg = L4.Dbg.Warn,
  },
  "rom/io rom/arm-rv.io");

L4.default_loader:start(
  { caps = {
      log = L4.Env.log:m("rws"),
      vbus = vbus_l4lx,
    },
    l4re_dbg = L4.Dbg.Warn,
    log = { "l4linux", "yellow" },
  },
  "rom/" .. lxname .. " console=ttyLv0 root=/dev/mmcblk0p1 rootwait");

> Заслуга Lennart'а заключается в том, что он понял, что большая часть этих зависимостей на самом деле не нужна.

Тиво-тиво? У него весь systemd крутится вокруг зависимостей, реализуемых через реакции на события.

>Удачи тебе в мире скриптов на С.

Кстати - это похоже всеобщее заблуждение тут, что systemd это скрипты на С, d - это от daemon. Достаточно вспомнить демон hotplug который пытались сделать на скриптах - это была невообразимая каша что даже гении скриптинга заплакали через короткое время.

> Тиво-тиво?

Да тут просто рассадник эротических фантазий. У каждого энтузиаста свое виденение systemd. Совпадает ли оно с мнением Леннарта и что же собой представляет systemd на самом деле - вот задача достойная истинных Пинкертонов!

для этого Лисп - нахер не нужн

И ты конечно можешь обосновать своё мнение? Кстати, а ты вообще уверен, что знаешь лисп достаточно, чтобы иметь право на своё мнение?

>И ты конечно можешь обосновать своё мнение? Кстати, а ты вообще уверен, что знаешь лисп достаточно, чтобы иметь право на своё мнение?

Я уже обосновал - пример тебе на Lua привел _рабочий_, а вот ты только трындишь про теоретическую крутость Лиспов и наверняка счас про guile чего-нибуть попытаешься стеоретить. Иди книжки читай, учись ;-)

полез качать сырки, будем курить..

я видел этот псто с 666 коментариями

>скриптов на С

Скрипты на C - это уже что-то новое. На C# видел тут где-то на ЛОРе, но на C ещё не встречал.

>я видел этот псто с 666 коментариями

+1, кстати. Когда сюда пришёл, зашёл на глагле, а там 666.

Я уже обосновал

И лиспа ты не знаешь, и логике тебя не учили.

пример тебе на Lua привел

Ну замечательно. Ты доказал тезис «на луа можно писать скрипты». Только:

а) с этим никто не спорил;

б) это к теме дискуссии не относится;

в) из этого не следует, что на луа следует писать скрипты;

г) не на луа нельзя писать скрипты.

а вот ты только трындишь про теоретическую крутость Лиспов

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

;;; init.el --- Where all the magic begins
;;
;; Part of the Emacs Starter Kit
;;
;; This is the first thing to get loaded.
;;
;; "Emacs outshines all other editing software in approximately the
;; same way that the noonday sun does the stars. It is not just bigger
;; and brighter; it simply makes everything else vanish."
;; -Neal Stephenson, "In the Beginning was the Command Line"

;; Turn off mouse interface early in startup to avoid momentary display
;; You really don't need these; trust me.
(if (fboundp 'menu-bar-mode) (menu-bar-mode -1))
(if (fboundp 'tool-bar-mode) (tool-bar-mode -1))
(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))

(setq fill-column 157)
(global-set-key [f5] 'compile)

;; Load path etc.

(setq dotfiles-dir (file-name-directory
                    (or (buffer-file-name) load-file-name)))

;; Load up ELPA, the package manager

(add-to-list 'load-path dotfiles-dir)

(add-to-list 'load-path (concat dotfiles-dir "/elpa-to-submit"))

(setq autoload-file (concat dotfiles-dir "loaddefs.el"))
(setq package-user-dir (concat dotfiles-dir "elpa"))
(setq custom-file (concat dotfiles-dir "custom.el"))

(require 'package)
(package-initialize)
(require 'starter-kit-elpa)

;; These should be loaded on startup rather than autoloaded on demand
;; since they are likely to be used in every session

(require 'cl)
(require 'saveplace)
(require 'ffap)
(require 'uniquify)
(require 'ansi-color)
(require 'recentf)


;; backport some functionality to Emacs 22 if needed
(require 'dominating-file)

;; Load up starter kit customizations

(require 'starter-kit-defuns)
(require 'starter-kit-bindings)
(require 'starter-kit-misc)
(require 'starter-kit-registers)
(require 'starter-kit-eshell)
(require 'starter-kit-lisp)
(require 'starter-kit-slime)

;;(require 'starter-kit-perl)
;;(require 'starter-kit-ruby)
;;(require 'starter-kit-js)

(regen-autoloads)
(load custom-file)

;; You can keep system- or user-specific customizations here
(setq system-specific-config (concat dotfiles-dir system-name ".el")
      user-specific-config (concat dotfiles-dir user-login-name ".el")
      user-specific-dir (concat dotfiles-dir user-login-name))
(add-to-list 'load-path user-specific-dir)

(if (file-exists-p system-specific-config) (load system-specific-config))
(if (file-exists-p user-specific-config) (load user-specific-config))
(if (file-exists-p user-specific-dir)
  (mapc #'load (directory-files user-specific-dir nil ".*el$")))

;;; init.el ends here

а теперь удавись.

Хорошо - на Лиспах можно писать загрузочные скрипты для emacs, но для Linux он нахер не нужен, кстати если ты не заметил у меня загрузчик ОС а не редактора, так что с логикой у тебя плохо - иди читай, сколько раз можно повторять.

а теперь удавись.

сходи утрись сперва :-)

Хорошо - на Лиспах можно писать загрузочные скрипт

Нашёл в себе силы это признать. Молодец.

но для Linux он нахер не нужен

Ты постоянно это повторяешь, но ещё ни разу не объяснил почему так думаешь.

кстати если ты не заметил у меня загрузчик ОС а не редактора

emacs --- операционная система общего назначения.

иди читай

С удовольствием.

> Удачи тебе в мире скриптов на С. И веба на С++

Ты вечно придумываешь какие-то страшилки - initd на Лиспе, скрипты на Си... Этого не бывает.

>emacs --- операционная система общего назначения.

А - ну все понятно тогда - тут не в библиотеку а к психиатру ;-)

>не на луа нельзя писать скрипты

Внезапно. А я-то думал, что SysVinit крутится вокруг скриптов, написанных не на луа.

Читать научись, пожалуйста.

А чем тебя так init на лиспе напугал?

> А чем тебя так init на лиспе напугал?

Кто сказал, что он меня напугал? Твои страшилки такие страшилки... не более страшнные, чем Страшила.

Блин, ты опять перешёл на язык загадок.

>Читать научись, пожалуйста.

Я-то умею, а вот ты, видимо, не умеешь формулировать свои мысли.

не на луа нельзя писать скрипты

Означает, что на других языках, например, bash, нельзя писать скрипты. Или имелось в виду !(на луа нельзя писать скрипты), т.е на 'луа можно писать скрипты'?

упс. опечатка. Правильно так:

г) из этого не следует, что не на луа нельзя писать скрипты.

> Блин, ты опять перешёл на язык загадок.

Не, это ты опять включил режим шланга.

упс. опечатка. Правильно так:

г) из этого не следует, что не на луа нельзя писать скрипты.

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

>Скрипты на C - это уже что-то новое. На C# видел тут где-то на ЛОРе, но на C ещё не встречал.

почему нет? Для этого tcc придумали.

Ты ошибаешься, когда думаешь.

Вот тебе и ответ - почему Лиспы не подходят для загрузки ОС

Из глупой опечатки ты развёл целую философию.

почему нет?

Потому что юникс умрёт в страшных сегфолтах.

Ты все же неисправим в своем упорстве - ее бы на благие цели направить ;-) тебе в принципе никто не мешает написать инит на Лиспе, когда напишешь - покажи плз, может что-то интересное будет.

> Ты ошибаешься, когда думаешь.

Бывает, как и со всеми. Например, почти каждый твой пост в этом топике - ошибка (надеюсь, ты думал над ними).

>Обоснуй.

сервисы не являются ни постоянными ни обязательными объектами. Даже имена у них необязательны. Несколько сервисов могут реализовывать одно и тоже. Например, network и NetworManager. На кого из них ставить зависимость у сервиса sshd?

поэтому прописывать надо зависимости на ресурсы.

> сервисы не являются ни постоянными ни обязательными объектами.

И что? По аналогии - пакеты тоже не являются ни постоянными, ни обязательными. Отменяем зависимости в пакетных менеджерах?

Даже имена у них необязательны

Это где так?

>Например, network и NetworManager. На кого из них ставить зависимость у сервиса sshd?

Вот поэтому есть network.target.

тебе в принципе никто не мешает написать инит

Я не люблю изобретать велосипед. Я люблю на них кататься.

>Я не люблю изобретать велосипед. Я люблю на них кататься.

Ну так иди уже, катайся или катись ;-)

Жаль, что ты так и не объяснил почему инит на лиспе --- это плохо.

Дык я уже 8 лет на BSD-style (кстати странно, что о нём вообще не вспомнили) и sysv-init'е катаюсь.

> Жаль, что ты так и не объяснил почему инит на лиспе --- это плохо.

Объясняю еще раз: потому что людей, знающих Лисп, мало. И потому, что нетривиальная рантайм система для инита - это плохо.

Объясняю еще раз: потому что людей, знающих Лисп, мало. И потому, что нетривиальная рантайм система для инита - это плохо.

Не показатель. К примеру:

http://en.wikipedia.org/wiki/Open_Firmware

Open Firmware, or OpenBoot in Sun Microsystems parlance, is a standard defining the interfaces of a computer firmware system, formerly endorsed by the IEEE. It originated at Sun, and has been used by Sun, Apple, IBM, and most other non-x86 PCI chipset vendors. Open Firmware allows the system to load platform-independent drivers directly from the PCI card, improving compatibility. Open Firmware may be accessed through its Forth language shell interface. It achieves essentially the same functionality as the later EFI standard initiated at Intel, with lower overhead

или http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/forth/