только собраны с опциями по умолчанию

Хочу иконки во fluxbox-е а в том который в пакете их нету-у-у… :’( Какое тут может быть доверие?

В чём проблема автоматизировать действия, которые можно автоматизировать?

юзер фряхи должен понимать что и как работает, а для этого надо читать мануал.

вручную обходить дерево зависимостей

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

Зачем ему рекурсивно делать enable всем зависимостям, если у него есть адекватное разрешение этих зависимостей при запуске?

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

выкинуть не нужные драйвера

ядра то модульные, дрова грузятся только для тех устройств что есть в наличии.

включить оптимизацию для типа процессора

чего там в ядре оптимизировать под тип процессора

Почти, но если очень хочется бороться за каждый байт и Hz. :)

это… пустая трата времени.=)

а в virtualbox для FreeBSD нельзя прокинуть отдельный USB-порт... а драйвер клавиатуры мне пришлось патчить, чтобы кнопки заработали, а ...

У меня на VirtualBox гостевой линь зависает из-за ошибки клиентских драйверов VB, которые ломают tmpfs в ядре, из-за чего система зависает или просто перестают mmap-иться файлы. А ты про какие-то пустяки с USB и клавой говоришь.

юзер фряхи должен понимать что и как работает, а для этого надо читать мануал.

Это не ответ на исходный вопрос «В чём проблема автоматизировать действия, которые можно автоматизировать?».

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

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

Чтение документации важно и нужно, но не следует подменять ей отсутствие функциональности.

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

«А при установке пакетов их нужно устанавливать, а не заниматься разрешением зависимостей.»

Демагогия как она есть.

дрова грузятся только для тех устройств что есть в наличии.

Воу-воу, это что — автоматизация?! Не-не-не, вы должны отстаивать точку зрения, что грузиться должны лишь те модули, которые явно прописаны пользователем, который прочитал мануал по имеющимся устройствам… дважды! 😉

тебе ответили, поддержка зависимостей там есть.
как она работает - смотри в скрипт
не нравица? - пиши разработчикам

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

«А при установке пакетов их нужно устанавливать, а не заниматься разрешением зависимостей.»

Демагогия как она есть.

действительно, только с твоей стороны =)

такое поведение в OpenBSD =)

тебе ответили, поддержка зависимостей там есть.

На что я спросил, какой от неё толк, если она не выполняет такую функцию как собственно запуск этих зависимостей при старте сервиса.

как она работает - смотри в скрипт

Что, даже не в мануал? 🤭

не нравица? - пиши разработчикам

Это довольно неуклюжая попытка уйти от ответа на вполне конкретный вопрос.

действительно, только с твоей стороны =)

«Нет ты!» 🤦‍♂️

На что я спросил, какой от неё толк, если она не выполняет такую функцию как собственно запуск этих зависимостей при старте сервиса.

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

сиди на линуксе.

выполняет так, как решили разработчики фряхи.

«Оно реализовано так, как его реализовали.»

с моей точки зрения решение правильное.

Почему?

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

Имеем:

1. В сервисе А указано, что для его работы требуется сервис Б.

2. init-система видит, что запрошен запуск сервиса А, и знает, что для работы ему требуется сервис Б.

3. …Но не запускает сервис Б, хотя знает, что он необходим сервису А, и ограничивается лишь попыткой запуска одного лишь сервиса А, которая, разумеется, завершается провалом, что было заранее известно init-системе.

Почему вы считаете, что данное поведение правильное?

сиди на линуксе.

Спасибо, но я не нуждаюсь в ваших советах по данному вопросу.

ядра то модульные, дрова грузятся только для тех устройств что есть в наличии

Да модульные, да грузятся. Но вот, к примеру, в /sys/amd64/conf/GENERIC указан

device          snd_emu10kx             # Creative SoundBlaster Live! and Audigy

А у меня в системе нету этого Creative SoundBlaster Live! and Audigy и что, этот драйвер загружен не будет? Я не сэкономлю какие-нибудь килобайты если его удалю, и соберу своё ядро без device snd_emu10kx?

какой от неё толк, если она не выполняет такую функцию как собственно запуск этих зависимостей

Наверное она выполняет какую-то другую функцию? :) Кроме собственно запуска ведь имеет значение в каком порядке этот запуск происходит.

если всё равно требуется немало ручного вмешательства

Это уж вы преувеличиваете. Довольно не много.

Открыл Диспетчер задач - Chromium

Объем потребляемой памяти у всех процессов ­— 0K.

ЦПУ — 0.0.

Сеть — показывает трафик по вкладкам.

Идентификатор процесса — все есть.

Потому что она выполняет ровно то что должна выполнять, а именно: запуск демонов (с учетом зависимостей), прописанных в rc.conf.
А прописывать их туда должен юзер своими руками. https://docs.freebsd.org/en/books/handbook/x11/#x11-wm
Такова политика партии.

А у меня в системе нету этого Creative SoundBlaster Live! and Audigy и что, этот драйвер загружен не будет?

Если закомментировать строчку в ядре, то он не войдёт в бинарный код kernel.ko, а соберётся модулем, который можно будет подгрузить отдельно, если в этом возникнет необходимость (добавить соответствующую строчку в rc.conf или loader.conf).

Фик знает
А ты глянь kldstat -v | grep snd
Там точно драйвера на звук есть?
У меня никогда звук из коробки не работал пока не укажешь какой драйвер грузить.

Update:
Действительно, в конфиге появился звук, когда я последний раз пытался водружать на ноут фрю я интеловский драйвер руками прописывал.
Кстати, раз уж хочется минимализма, есть готовый минимальный конфиг https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/MINIMAL
Или этот =)) https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/DEFAULTS

Наверное она выполняет какую-то другую функцию? :) Кроме собственно запуска ведь имеет значение в каком порядке этот запуск происходит.

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

А уж если всё равно требуется указывать запуск зависимостей в rc.conf вручную, то зачем тогда автоматическое упорядочивание, если его можно точно так же делать вручную, раз уж всё равно весь список руками прописывать?

Т.е. порядок запуска мы будем определять автоматически согласно зависимостям, и вмешательство пользователя для этого не требуется; но вот то, какие сервисы требуется запускать по зависимостям, мы автоматически определять не будем (хотя у нас есть вся необходимая для этого информация) — какое-то половинчатое решение, не находите?

Это уж вы преувеличиваете. Довольно не много.

В конкретном случае gdm — да, немного. В общем же случае может быть и по-другому.

Какой ты непонятливый. Юзер фряхи должен познать дзен и впасть в нирвану после окончания всех настроек. :)
А если он переконпеляет мир, ядро и порты конпелятором на который забил мейнстрим, то его ждёт рай с амброзией и девственницами. Тут один такой тусуется.
Для остальных есть убунта.

порядок запуска не имеет значения, если те сервисы, запуск которых необходимо упорядочить, не запускаются вовсе

Ручного вмешательства в случае «указать нужные для запуска сервисы» гораздо меньше чем в случае «указать нужные для запуска сервисы и указать им очерёдность запуска относительно друг друга и всех системных сервисов».

какое-то половинчатое решение, не находите?

Вообще как будто бы да, но я так к нему привык, что не задумываюсь об этом. За то теперь вы совершенно отчётливо знаете что именно у вас в системе запускается ― исключительно то, что вы сами указали. Мне нравится.

Ручного вмешательства в случае «указать нужные для запуска сервисы» гораздо меньше чем в случае «указать нужные для запуска сервисы и указать им очерёдность запуска относительно друг друга и всех системных сервисов».

Не преувеличивайте. Раз уж всё равно вписывать все сервисы вручную, и вы уже знаете все зависимости, то несложно вставлять зависимые сервисы после их зависимостей.

За то теперь вы совершенно отчётливо знаете что именно у вас в системе запускается ― исключительно то, что вы сами указали. Мне нравится.

Стало быть, вам не нравится система портов и пакетов — ведь там устанавливается не исключительно то, что вы сами указали? 🙂

несложно вставлять зависимые сервисы

Иной раз приходится в это вмешиваться и менять дефолтный порядок запуска. Бывало огребал с того проблем. :) А вот с тем какие именно сервисы стартовать ― там вроде бы всё очевидно.

устанавливается не исключительно то, что вы сами указали

Ну так оно просто устанавливается и лежит себе спокойно. Вопросов «WTF? Что ЭТО и откуда оно запустилось???» не вызывает.