>В дистрибутивном конфиге я смогу получить маленькое безмодульное ядро?

Безмодульное не сможешь. Теперь объясни, зачем ты хочешь выпилить модули.

> FreeBSD RIP

4.2

Если бы FreeBSD была одна (Если б не было Linux), больше софта писалось бы под нее, и были бы адекватные видеодрайверы и нативный скайп под FreeBSD. А сейчас она никому не нужна, потому что пользуется ею (на десктопе) 5% от 5%

Разве ALSA не является заменой устаревшего OSS?

устарело оно только в линухе

Важно не то, что оно не в базовой системе, а то, что udev под FreeBSD нет.

а на кой оно там ? там devfs есть

make localyesconfig спасет отца мирового пролетариата

А по-вашему, какие проблемы еще остались у проекта FreeBSD?

В ней нет ядра Linux. ;)

http://nuclight.livejournal.com/128712.html

1. Для изменения состава базы систему можно только пересобрать с опциями src.conf, при этом никакой информации о составе и поддерживаемых фичах скомпилированной системы в бинарном виде не сохраняется, нельзя бинарно обновить любой кастомный вариант, даже просто собранный из сырцов с опциями по умолчанию -STABLE.

/etc/src.conf — информация о составе и поддерживаемых фичах скомпилированной системы.

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

/var/db/ports/portname/options — информация об опциях сборки пакета.

3. Жесткая привязка к имени файла в зависимостях пакетов, что означает и жесткую привязку к конкретной версии.

Не понял утверждение про конкретную версию.
У меня Xfce4 4.6.2 предыдущей версии, чем сейчас в портах, стоит на домашнем компе. Никаких конфликтов с обновлёнными версиями программ из портов не заметил.

4. Собственно, из привязок к имени вытекает много других неудобств, например, дурацкие конфликты между вариантами одного и того же пакета, геморрой при обновлении кучи пакетов (обновление одного может повлечь за собой пересборку почти всей системы).

Какие конфликты между версиями одного и того же пакета? Xfce 4.6.2 нельзя держать вместе с Xfce 4.8 что ли и пользоваться ими одновременно? :))

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

Бред.

6. Всё то же самое с базовой системой, плюс отсутствие связок между базовой системой и пакетами — например, пакеты (/usr/local) прямых зависимостей от базовой системы не имеют, как и от её конкретных фич из src.conf (так что легко сломать по неосторожности в кастомных конфигурациях).

ЧТО можно сломать по неосторожности, если они не имеют связок? Разве х.й можно сломать по неосторожности, надевая трусы через голову?

Требующие более глубоких изменений, но и менее актуальные проблемы с ветками (как HEAD/STABLE, так и samba34/samba35) и devel-ветками, версиями и devel-вариантами (это которые хедеры/дебаг и т.п.), альтернативными репозиториями (и их приоритетом). То есть с тем, что требует более одного измерения, не только лишь category/progname.

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

А зачем мне модули?

Монолитное ядро грузится быстрее.

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

> если сообщество прямо сейчас не осознает необходимость серьезных изменений и не начнет воплощать их в жизнь

Это они про «взять в руки лопаты и дружно закопать»?

> Во freebsd можно сделать свой репозиторий с пакетами?

Ты чё, не знал что ли?

% env PKG_PATH=/path/to/mntnfsrepo/packages/All portupgrade -aPP

>А зачем мне модули?

И при смене любой железки конпелять? Мусье знает толк в извращениях.

Монолитное ядро грузится быстрее

Выкинь свой 486й.

а по ftp ? а если пакет из твоего репозитория тянет по зависимостям пакет из официального ?

Давно ли FTP стал файловой системой? Нет, конечно можно использовать FUSE-FTP и примонтировать официальный репозиторий с бинарными пакетами, либо всё сразу из официала обновлять бинарно (по FTP):
% portupgrade -aPP

Но обычно уважающие себя конторы делают собственный локальный централизованный репозиторий бинарных пакетов (/usr/ports/packages сервера сборки и/или тестирования), доступный в сети по NFS и обновляют продакшен-сервера из него, а то мало ли, какой нужный пакет окажется недоступным или собранным не с теми опциями, какие нужны...

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

то есть ты предлагаешь всю туеву хучу пакетов пересобрать под себя?

А что, не интересно? Я много раз так делал и делаю — пока жив. На юзерфильный десктоп с Xfce4 и GNOME-программами уходит от 6 до 8 часов — в зависимости от того, чем ещё машина занята кроме компиляции. KDE4 с нуля вся собирается за 12 часов. OpenOffice — за 4 часа. Сама операционка [amd64] на живом десктопе пересобирается за 1 час 15 минут ([i386] пересобирается за 20 минут) + пять минут на переинсталляцию и перезагрузку.

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

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

и на каждое обновление так делать?

Всю систему и ПО обновлять на каждое обновление? Нет, конечно. Я бы сдох. :))

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

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

BATCH-сборки пакетов мало кому интересны. Разве что новичкам, которые ещё не привыкли устанавливать и поддерживать установленное ПО, собираемое из исходников с помощью make|portupgrade|portmaster.

чего? есть 1000 одинаковых серверов на них надо поставить пакеты 90% дистрибутивных, 10% своих. в линухе это решается подключением официального и конторского репозитория, как это сделать во фряхе? при этом 90% пакетов из офрепа пересобирать нельзя.

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

Всмысле запаковать /usr/local и везде распаковать? А обновлять как? А если 1% из тех 10% понадобится в других проектах на других серверах? Всегда был с тобой согласен, но сейчас ты какую-то чушь говоришь.

Всмысле запаковать /usr/local и везде распаковать?

Снапшоты и компрессия — ортогональные вещи.

А обновлять как?

Чего обновлять? Снапшот — это и есть «обновление». Обновляется только ОДИН тестовый сервер, а снапшоты с него рассылаются серверам.

А если 1% из тех 10% понадобится в других проектах на других серверах?

То есть? В условии задачи сервера ОДИНАКОВЫ.

Чего обновлять? Снапшот — это и есть «обновление». Обновляется только ОДИН тестовый сервер, а снапшоты с него рассылаются серверам.

что при этом происходит? какие файлы будут перезаписаны, какие сервисы перезапущены ?

То есть? В условии задачи сервера ОДИНАКОВЫ.

Так бывает только в сферических конторах в вакууме. В реальности есть 1000 серверов под задачу A, 10000 под задачу B, 500 под задачу C ... Подзадачи задач могут пересекаться ...

http://lurkmore.ru/%D0%A4%D0%B0%D0%B9%D0%BB:Ms_windows_vs_freebsd.jpg
не нуачо, мне нравится, лучше чем виндовс.

нет нормальных пакетов и ебилдов.

какие файлы будут перезаписаны, какие сервисы перезапущены ?

Просветитесь насчёт снапшотов, что это такое и с чем их едят.

В условии задачи сервера ОДИНАКОВЫ.

Так бывает только в сферических конторах в вакууме. В реальности есть 1000 серверов под задачу A, 10000 под задачу B, 500 под задачу C ... Подзадачи задач могут пересекаться ...

Так бы и написал.

На каждый сервис (задачу) выделяется один тестовый сервак. Далее сервера монтируют его шаред-каталог /usr/ports/packages/All и обновляются обычным образом бинарно по крону. Пропала шара — нет обновления, появилась — есть. Что тут неясного?

нет нормальных пакетов и ебилдов.

Вздор. Всё есть.

Просветитесь насчёт снапшотов, что это такое и с чем их едят.

Ну так объясни что это такое.

На каждый сервис (задачу) выделяется один тестовый сервак. Далее сервера монтируют его шаред-каталог /usr/ports/packages/All и обновляются обычным образом бинарно по крону. Пропала шара — нет обновления, появилась — есть. Что тут неясного?

Непонятно как это поддерживать. В линухе разбиваются репозитории по подзадачам, с каждой подзадачей работает отдельная команда. Когда админы выделают сервант под конкретную задачу, то они подключают нужные репозитории. Если серверов в конторе много (>10000 как у нас в конторе), то выделять под репозитоий один сервак это будет жопа, надо делать кластер под репозиторий. Как это нормально сделать во freebsd ? То что ты предлагаешь это какой-то геморрой.

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

http://ru.wikipedia.org/wiki/Снимок_файловой_системы

На каждый сервис (задачу) выделяется один тестовый сервак. Далее сервера монтируют его шаред-каталог /usr/ports/packages/All и обновляются обычным образом бинарно по крону. Пропала шара — нет обновления, появилась — есть. Что тут неясного?

Непонятно как это поддерживать.

Как и везде. Поддержка актуальности ПО не зависит от операционки. //К.О.

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

Аналогично для FreeBSD.

Когда админы выделают сервант под конкретную задачу, то они подключают нужные репозитории.

Аналогично: собирается из портов и поддерживается рабочий набор ПО для определённой задачи на тестовом серваке. Если работает как надо — каталог с бинарными пакетами расшаривается в локалке.

Если серверов в конторе много (>10000 как у нас в конторе), то выделять под репозитоий один сервак это будет жопа, надо делать кластер под репозиторий. Как это нормально сделать во freebsd?

Элементарно. Если не хватает мощностей на файловый хостинг каталога с пакетами, то делаются файловые зеркала.

То что ты предлагаешь это какой-то геморрой.

То, что я предлагаю, делаются везде одинаково. Только в GNU/Linux для таких операций есть отдельно написанные разработчиками дистрибутивов утилиты управления распределённой установки ПО.

Крон — это один из видов сигналов.

То, что я предлагаю, делаются везде одинаково. Только в GNU/Linux для таких операций есть отдельно написанные разработчиками дистрибутивов утилиты управления распределённой установки ПО.

Ага, а во фряхе нету. Уверен на 200%, что в нашей организации используется самописный велосипед для этих целей ибо то что ты говоришь похоже на какую-то феерию и каменный век. Как-нибудь при случае поинтересуюсь у ребят их отделов, которые работают с фряхой ...

Как-нибудь при случае поинтересуюсь у ребят их отделов, которые работают с фряхой ...

Только сначала покажи им ВСЮ нить обсуждения твоей проблемы, хорошо?

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

Это детали — повесить ответственность шаринга обновлений на определённое лицо, способное принимать взвешенные решения.

факт в том, что cron тут не нужен

Серваки по крону монтируют каталоги тестовых серверов. Если монтирование не удаётся — откладывают обновление.

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

Немного не понял, что им конкретно не понравилось. Или у них просто FreeBSD спецы померли или свалили и дешевле поставить Linux чем искать новых?

FreeBSD все лучше и лучше от релиза к релизу, не надо.

Похоже на то, что перед выходом девятки специально поднят чёрный пиар вокруг якобы «изъянов» операционной системы. Кому-то из «руководящего состава» GNU/Linux-мейнстрима не выгоден быстрый прогресс FreeBSD в сторону десктопа и тем более оставление её в серверном сегменте.

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

Фрибсд не нужна из за бсд, пущай хоть на сддл перепишут, а лучше гпл3.

Давайте уже признаем свербящую открытую рану: вам нужен очередной клон Linux, а не конкурент в области систем хранения информации и сетевого роутинга. Чтобы этот клон не отрывался от обЧества, не выпячивал свои академические фичи, реализованные на практике — слишком умных в школьном классе не любят и всячески стараются поддеть.

Ведь так?

Вот только жизнь это не только школа. И не только бизнес, но и творчество, когда хочется реализоваться просто так. Задаром.

BSD - более здоровая в идеологическом плане система, в ее сообществе ни кто от проприетарщины не плюется и религиозным экстремизмом не страдает. И если бы Freebsd была доминирующим Unix`ом на рынке, было бы лучше.

Что мешает творить под жпл?

Что мешает творить под жпл?

Растворение авторского смысла в чужом говнокоде.

Эпичненько

Ссылка: http://www.opennet.ru/openforum/vsluhforumID3/79595.html#339

Функции сетевых серверов неодинаковы, и если на каждый сервер поставить то программное обеспечение, которое разрабатывалось именно для решения тех задач, которые должен решать данный сервер, суммарные расходы на администрирование будут меньше, чем были бы, если заставлять программное обеспечение решать несвойственные ему задачи. Взять, к примеру, задачу о 'light server partitioning': есть FreeBSD/Jail (технология, которой много лет), есть Linux Containers (экспериментальная). Они обе в общем-то довольно прилично работают, но в Линуксе вылезают странные архитектурные проблемы, которых во FreeBSD почему-то нет: /dev в Jail'е работает великолепно, в LXC отсутствует, как класс, ибо ядро не умеет вызывать udev helper в пятнадцати виртуальных машинах. Нет, не то, чтобы это СИЛЬНО мешало — mknod никто не отменял — но неприятно. Во FreeBSD есть разделение файловых иерархий на базовую систему и пакеты => базовую систему можно смонтировать по nullfs в сотню jail'ов и атомарно их патчить в случае проблем с безопасностью, просто перестроив мир в базовой системе. В Линуксе так сделать по очевидным причинам не получится. И вот тут-то и вылезает overhead на системное администрирование: когда у вас на сервере чуть больше, чем LAMP крутится, всё становится очень и очень печально с Линуксом.

> Ага, поэтому наверное список рассылки нжинкса пестрит сообщениями о очень стабильной работ фряхи, которая норовит там и тут повиснуть или спаниковать.

Что касается вызова panic(), то не надо забывать, что если бы Линукс вызывал panic() всё время вместо OOPS(), тогда с системой вообще работать нельзя было бы. :)

Линуксоиды эпично зафейлили отладить ядро до работоспособного состояния, и отказались от концепции паники при ошибках ядра, пытаясь рестартануть подсистему. Получилось такое вот «ни два, ни полтора» — и не микроядро, сервисы которого рестартуются очевидно, как, и не честный monolithic, который ОБЯЗАН считать, что ЛЮБОЙ OOPS() — это ВОЗМОЖНОЕ повреждение управляющих структур ядра. Соответственно, всё, что не panic() — то небезопасно.

А OOPS()'ится Линукс совершенно эпично. Просто большинство админов локалхоста не имеют возможности с этим проэкспериментрировать. А я имею такую возможность. У меня есть USB-хабы с десятком однотипных USB-модемов. Вот если его включить в машину с Линуксом... :))) Да ещё несколько раз «повтыкать-повытыкать»... :))) У меня Debian v6 зависал «вхолодную», до reset'а. :)

Википедия почему-то не падает,

Да. Как и Plasma в KDE. Не знаю, что все так на KDE 4 ополчились... ;)

Главная проблема *BSD - толпа фанатиков с лопатами, упорно пытающаяся закопать ОС, которая работает и никому не мешает.

Главная проблема *BSD - толпа фанатиков с лопатами, упорно пытающаяся откопать ОС, которая мертва и никому не мешает.

очевидный фикс

Главная проблема *BSD - толпа линуксовых фанатиков с лопатами, упорно пытающаяся откопать ОС, которая по их мнению мертва, удостоверится, что она всё же жива, и со злости закопать её обратно, чтобы она им не мешала.

FIXED.

:)))

я не линуксовый фанатик