PC-BSD 7.1

>Кстати, чтобы пример был нагляднее: представь себе, что ты ставишь программу, предназначенную для работы на Mac OS X в девятку или же программу под Vista на Windows 98 или 2000.

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

>Мне вот что интересно - значит к каждой проге идут свои библиотеки.

Да, свои. Библиотеки определённых версий для запуска приложений, которые установлены из PBI. Да, такие библиотеки не "пересекаются" с теми библиотеками, которые установлены из обычных бинарных пакетов/портов FreeBSD. Поэтому и приложения не нужно пересобирать при обновлении общих библиотек.

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

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

>И второй вопрос - не проще ли тогда было собрать статикой?

Тогда понизится эффективность файлового кэша. У приложений из PBI-пакетов наверняка много собственных одинаковых библиотек.

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

>А это ведь ты обычно вещаешь о том, как офигительно использовать *BSD?

Я такого не говорил. Но лично для себя я нашёл идеал среди ОС.

>Что, проблемы с портами? :)

К счастью — решаемые. :)

>Программы упакованы в собственный формат пакетов — PBI, суть которого в избавлении от зависимостей, путём помещения всех необходимых библиотек в каждый пакет.

Простите, а в какой версии у них появится аналог DLL-Hell'а как в офтопики? Спасибо!

>>Программы упакованы в собственный формат пакетов — PBI, суть которого в избавлении от зависимостей, путём помещения всех необходимых библиотек в каждый пакет.
>Люто-бешено ненавижу.
>//гентушнег. И да, цвет глаз - красный.

Когда я ставил сестре PC-BSD 7.0.1, то из набора предлагаемых к установке PBI-приложений выбрал где-то штуки четыре или пять. :))

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

Чем это было вызвано? Тем, что в PC-BSD предлагается ТРИ параллельных ветки сопровождения: одна для операционной системы, вторая для установленных пакетов FreeBSD, третья — для PBI-приложений. Первые две ветки никто не отменяет и в обычной FreeBSD, а вот третья — явно избыточна, когда число установленных PBI-приложений под сотню, или же их почти нет (два краевых случая).

> а в какой версии у них появится аналог DLL-Hell'а

Тогда же, когда исходники Win 3.1 выложат под BSDL ;-)

Но никто же не мешает НЕ устанавливать ни одного PBI, а собирать всё из портов? KDE4 и вся PC-BSD-шная обвязка всё равно лежит отдельно, в каталоге /PCBSD.

>Простите, а в какой версии у них появится аналог DLL-Hell'а как в офтопики? Спасибо!

Ни в какой.

Dll-hell характеризуется тем, что все библиотеки свалены в один общий каталог.
Приложения из PBI, напротив, имеют собственную каталожную структуру библиотек и не пересекаются с установленными из портов.

>Но никто же не мешает НЕ устанавливать ни одного PBI, а собирать всё из портов? KDE4 и вся PC-BSD-шная обвязка всё равно лежит отдельно, в каталоге /PCBSD.

Несовсем. KDE4 устанавливается не из PBI, а бинарными пакетами как в обычной FreeBSD /по крайней мере в предыдущей версии PC-BSD утилиты работы с коллекцией портов — portupgrade — видели библиотеки KDE4 как ПО, установленное из коллекции./

Не исключаю, что KDE4 можно установить PBI-пакетом, но в этом случае теряется связь базы данных установленного ПО с коллекцией портов, и контроль за обновлением ПО полностью переходит к PBI-менеджеру. В предыдущей версии PC-BSD я такого не наблюдал — система управления PBI в ней была сугубо вторичной, "надсистемной".

В каталог /PCBSD устанавливаются пользовательские приложения.

>Вообще _ВТОРОЙ_ амарок не предназначен для KDE 3.x. Он сделан для четверки и под четверку - такой дизайн.

>И даже имея PC-BSD, у тебя в пакете будет половина четвертого KDE. Спрашивается, нафига козе баян? Как stand alone программа не проектировалась.

Да ладно вам - такое надо. Что - ни рпазу не сталкивались с ситуацией когда вышло обновление (или просто единственная версия такая) программы X depends on library Z, в то время как программа Y зависит от той же либы другой версии версии. И единственный выбор который дает пакедж менеджер это: не обновлять(не ставить) X/снести Y? С дистрибутивными программа которые делает производитель дистрибутива такое редко бывает, а со сторонними репами сплош и рядом.

Так что этот баян козе полезен.

PC-BSD 7.1 ни в какую не желает ставиться на VirtualBox 2.2, при копировании файлов в окошке инсталлятора пишет "Seek failed: Invalid argument", а на stderr "write failed, filesystem is full".

В каком месте руки выпрямлять надо?

Может надо увеличить место под образ PC-BSD? Хотя бы до 15 ГБ.

8 ГБ ему не хватит? Может быть, я не совсем понимаю квантовую механику UFS2, но дело в том, что оно с самого начала это пишет, и сам образ HDD занимает стабильно 1.03 МБ. Хотя, чем чёрт не шутит, сейчас попробуем...

У меня сейчас такая раскладка разделов в слайсе:
> df
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad4s1a    4.3G    2.3G    1.6G    59%    /
/dev/ad4s1d     11G    3.6G    6.5G    36%    /usr/local
/dev/ad4s1g    273G    239G     11G    95%    /usr/home
Но это под Xfce рассчитывалось. И под то, что каталог с дистфайлами будет лежать не там, где обычно.

Да ещё SWAP на отдельном разделе в том же слайсе под 1ГБ (который используется когда в каком-нибудь приложении начинает подтекать память).

Щедрой рукой увеличил образ до 24 ГБ - результат такой же. Где-то в другом месте копать надо...

BSD RIP

Рядом ругались на глюки VirtualBox, попробуй vmware

> Невероятная стабильность нового Flash 9

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

А она в принципе и не обязана на VirtualBox ставится http://www.virtualbox.org/wiki/Guest_OSes Тоже когда-то пытался...

>Поэтому и приложения не нужно пересобирать при обновлении общих библиотек.

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

>Да. каждое приложение, если оно использует "свою" библиотеку, будет отжирать память для этой "собственной" библиотеки. А что в этом такого?

Если мы посмотрим в тред о джаббер-клиенте на моно, то поймем, что программы и так очень много кушают. И памяти хоть и хватает, но ситуация прямо скажем не фонтан. Тут, выходит, еще больше кушать будут?

>Но никто же не мешает НЕ устанавливать ни одного PBI, а собирать всё из портов?

Это так же "удобно", как собирать в виндах что-то под cygwin, а что-то под mingw - куча геммора с неизвестным и заведомо худшим результатом, чем при использовании нормального линукса/bsd и т.п.

>Dll-hell характеризуется тем, что все библиотеки свалены в один общий каталог.

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

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

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

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

Но он прав в том что размазанные dll в хелле не учавствуют. Хелл есть в общих каталогах и в зарегистрированных дллинах (ком объекты, автомейшен и прочий активикс) - вот там когда кто что хочет тот и ставит - начинается хелл.

>Поэтому я не использую сторониие.

НУ все конечно рады что лично тебе хватает дистрибутива для жизни - но в сторонних репах не только левые сборки хранятся но и программы которых в официальном дистре - нет.

>Ну или собрать самому и залочить программу на предмет обновления.

Перечитай что я написал - конфликт возникает в шареной библиотеке когда синхронной сборки нет в природе. Так что указанній вариант вполне жизнеспособен. К стати весьма неплохой вариант конфликт резолюшена package managerов - мол "поставить изолировано" - чтобы он не ставил зависимости по обычному сценарию а впаял бы всему конфликту жесткий prefix и поставил все куда-нить в /opt раз уж по другому разрешить конфликт нельзя а пользователю надо.

>К счастью — решаемые. :)

+1 Порты во фре - это лучшее, что только может быть [в ней].

можно попробовать пересобрать X или Y софт со статической линковкой конфликтующей библиотеки? Не панацея, но локальное решение?

> суть которого в избавлении от зависимостей, путём помещения всех необходимых библиотек в каждый пакет

А на самом деле это хорошее решение. В смысле, надо делать "установка/удаление" чтоб были с зависимостями, а если скачивать - сразу всё.

>Невероятная стабильность нового Flash 9 позволяет использовать на новом уровне такие сайты как, например, Hulu и Youtube.

Дожили, невероятная стабильность:) для youtube и gnash-0.8.6 прекрасно работает.

>К стати весьма неплохой вариант конфликт резолюшена package managerов - мол "поставить изолировано" - чтобы он не ставил зависимости по обычному сценарию а впаял бы всему конфликту жесткий prefix и поставил все куда-нить в /opt раз уж по другому разрешить конфликт нельзя а пользователю надо.

Ну собственно да, это более прямой путь, имхо.

Но тогда получается - баян козе таки не нужен?

Вообще у Гентушников на этот счет вполне изящное решение есть - называется слоты, позволяет ставить несколько версий одной и той же либы

>Правда, потом систему переделал в нормальную FreeBSD

А в чем тогда смысл не ставить сразу FreeBSD?

>Вообще у Гентушников на этот счет вполне изящное решение есть - называется слоты, позволяет ставить несколько версий одной и той же либы

вообще, в нормальных системах, имхо, этот вопрос говна не стоит. Вариантов решений - масса, от установки в /opt, до установки в отдельной VM. Проблемы начинаются, когда костыли (в данном случае - системы PM) начинают конфликтовать между собой.

>А в чем тогда смысл не ставить сразу FreeBSD?

Прочувствовать захотелось.

Для начинающего пользователя PC-BSD, конечно, дружественна и беспроблемная — знай только, ставь всё нужное тебе ПО из PBI, пользуйся этим — этим она не отличается от Windows.

С другой стороны в этом случае труднее поддерживать присутствующее в системе ПО, установленное из коллекции портов, в актуальном состоянии (да и теряется в этом всякий смысл): как только я первый раз запустил синхронизацию каталога коллекции портов в PC-BSD и посмотрел на пакеты, нуждающиеся в обновлении, то там было порядка 500 единиц, нуждающихся в обновлении — это 90% из всех.

Что в этом случае делать? Подключать по NFS каталоги "packages/All", где собраны бинарные пакеты, ports/distfiles с другого компьютера, задействовать механизм UnionFS (потому что на другом компьютере дистфайлы не все по очевидным причинам — Xfce имеет меньше зависимостей, чем KDE4). Обновить установленные пакеты какие бинарниками, какие из портов.

Да ещё по-хорошему нужно всё время отслеживать новые версии приложений в PBI-репозитории. В общем, лучше что-то одно использовать, а не всё сразу, иначе сопровождение системы выливается в только в сопровождение и никакой работы/развлечений не будет. :))

>Вообще у Гентушников на этот счет вполне изящное решение есть - называется слоты, позволяет ставить несколько версий одной и той же либы

Смотрим ширее.
Пользователям нужны приложения, а не конкретные "либы". Поэтому и придуманы бесконфликтные PBI.

>НУ все конечно рады что лично тебе хватает дистрибутива для жизни - но в сторонних репах не только левые сборки хранятся но и программы которых в официальном дистре - нет.

Например? Я вот только axel не нашел к федора. В убунту eclipse версии 3.2, но репозитарий со сборкой такой, что лучше ставить ту версию, что лежит на сайте.

А все остальное - у fedora в extras, считай, что их репозиторий. У убунты вообще сразу все из коробки.

>Так что указанній вариант вполне жизнеспособен. К стати весьма неплохой вариант конфликт резолюшена package managerов - мол "поставить изолировано" - чтобы он не ставил зависимости по обычному сценарию а впаял бы всему конфликту жесткий prefix и поставил все куда-нить в /opt раз уж по другому разрешить конфликт нельзя а пользователю надо.

Это да. Может, к этому еще и придут.

>Да ещё по-хорошему нужно всё время отслеживать новые версии приложений в PBI-репозитории.

Демоном?

>Пользователям нужны приложения, а не конкретные "либы". Поэтому и придуманы бесконфликтные PBI.

А откуда возник тезис о том, что в противном случае(не-PBI) непременно должны быть конфликты? Это головная боль мэйнтейнеров, не пользователей.

>А откуда возник тезис о том, что в противном случае(не-PBI) непременно должны быть конфликты?

Ниоткуда.

Концепция дистрибуции ПО (в данном случае пакеты PBI представляют такую возможность) сводит на нет зависимость от действий/бездействий каких-то там "мантейнеров". ;)

>Концепция дистрибуции ПО (в данном случае пакеты PBI представляют такую возможность) сводит на нет зависимость от действий/бездействий каких-то там "мантейнеров". ;)

Пакеты PBI откуда берутся?

Поздравляю всех! :)

А стабильность Flash 9 - это действительно невроятно! :-D

>У меня работает композит в Xfce4.6 и на "ati", и на "radeonhd" есщё с FreeBSD 7.1-RELEASE (когда карточку AMD купил). ЧЯДНТ?

НЕУДАЧНИК!!!!!!!!

>Концепция дистрибуции ПО (в данном случае пакеты PBI представляют такую возможность) сводит на нет зависимость от действий/бездействий каких-то там "мантейнеров". ;)

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

Вообще не вижу сложностей.

yum install mediawiki - сразу ставит апач, медиавики, php, необходимые либы.

apt-get install amarok - кодеки, руби (нафиг он там - хз).

apt-get install eclipse - выкачает все, включая нужные версии java.

Не вижу особых проблем.

>можно попробовать пересобрать X или Y софт со статической линковкой конфликтующей библиотеки? Не панацея, но локальное решение?

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

>Но тогда получается - баян козе таки не нужен?

Ну - при таком аккордеоне - можно и без баяна:)

>Например?

Для сусе навскидку:

jad, rezound, mldonkey, до некоторого времени не было ocaml, hugs, ghc, а даже сейчас в стандартном репе ocaml 3.09.3, а в пакмане 3.10.2.

А что с сайтом pcbsd.net и pbidir.com?

Первый пишет: Joomla! PC-BSD

This site is temporarily unavailable. Please notify the System Administrator

А второй:

ERROR !!

an e-mail has been sent to the staff we are sorry for this problem

LOR-ЭФФЕКТ?

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