Разработчики проекта PC-BSD сообщили добавлении в стандартное дерево портов FreeBSD нового порта с инструментарием PBI Manager (/ports-mgmt/pbi-manager), позволяющим устанавливать, удалять, обновлять и создавать пакеты в формате PBI 9. Добавление PBI Manager предоставляет пользователям FreeBSD возможность работы с PBI-пакетами без установки дистрибутива PC-BSD.Подробнее об особенностях формата PBI, подразумевающего формирование самодостаточных пакетов, включающих все необходимые зависимости, можно прочитать в анонсе (http://www.opennet.me/opennews/art.shtml?num=29940) переработанной версии PBI.
URL: http://blog.pcbsd.org/2011/05/pbi-manager-now-available-in-f.../
Новость: http://www.opennet.me/opennews/art.shtml?num=30455
на unixway os хотят делают не совсем не unixвейный подход, зачем?
Ну а чо, вот вам MSI-пакеты, но для BSD. Этак скоро и диск цэ сделают.
Да! Уши же микрософта торчат!! Продались, борцы за коммерческую свободу?!
> Да! Уши же микрософта торчат!! Продались, борцы за коммерческую свободу?!А мне нравится.
Хочешь pkg из портов раздавай, хочешь pbi.
Кто-то заставляет разве?
Вы лично давно на Фре?
Он лично унылый тролль ИМХО
чего?
ужс вместо того, что бы трудится на улучшениями системы портов фряхи, создают какой то костыль непонятный
Кто сказал, что вместо? Ничего подобного.
в ос ничего не делают. Это сторонний софт (как и все в портах), ставить или нет - решает сам пользователь.
Основное предназначение таких пакетов - бинарная портабельность при отсутствии интернетов, как я понимаю. На дисках или флешках знакомые люди делются между собой программами, когда никаких сторонних зависимостей потом из репозитория выкачивать не нужно. Только зачем это на серверной оси? Все равно же ведь подобные pbi будут в большинстве своем выкачиваться из репозиториев, этому опять же будет способствовать и то, что самих бздунов не так уж много, так что такого охвата как виндовс во времена пиратства не будет это точно. Да и места они занимают огромное количество, поэтому нововведение конечно же сомнительное.
это всего лишь один из портов
>Только зачем это на серверной оси?FreeBSD — универсальная ОС. //К. О.
неа. фрибсд - это преальфа макоси.
и сабж это как раз подтверждает.
>>Только зачем это на серверной осиДля того чтобы апдейт одной подсистемы, не вызывал падения других подсистем. Типа jail для зависимостей.
о-ля-ля! отличные jail'ы для хранения кучи устаревших и дырявых зависимостей!зыж
вот и мак-(быдло?)-кодер подтверждает откуда ветер дует. :D
> о-ля-ля! отличные jail'ы для хранения кучи устаревших и дырявых зависимостей!
> зыж
> вот и мак-(быдло?)-кодер подтверждает откуда ветер дует. :DА вы, ля-ля, поднимите классический jail и поразвлекайтесь.
Давно вы директивно пакадж раздавали по зверинцу офисных машин?
ого! и давно вы фрюху в офисные машины ставите?зыж
нормальные люди в офисах (и не только) давно уже готовят целые стопки образов клиентской ОС и раздают рут к примеру по нфс, а не занимаются хернёй.
тем более не сравнивают jail с пакетными менеджерами.
Нормальные люди пользуются терминалами для таких случаев.
и терминалами тоже.
кто ж спорит.
или не доходит, что клиентскую ОСь вместе с системными (и не очень) библами и прогами можно тоже грузить и рулить ими централизованно?
> о-ля-ля! отличные jail'ы для хранения кучи устаревших и дырявых зависимостей!1. Новые зависимости прийдут с обновлением pbi.
2. pbi в репе автоматом билдсервером пересобираются, соответственно и обновления придут автоматом.
3. Некоторые зависимости как раз НЕ НУЖНО обновлять именно для конкретного софта.
> 3. Некоторые зависимости как раз НЕ НУЖНО обновлять именно для конкретного софта.Ессно.
Мальчики-зайчики явно не поддерживали спец-софт например на производствах или что-то сложнее тетриса. "Стабильность" API библиотек так-же вызывает сильный гемморой в налаженной среде.
девочкам-белочкам ниже уже ответил каким волшебным образом можно разрулить и эту ситуацию.
это бедные без выхода сабжа так видимо и не смогли "поддержать" этот "спец-софт". как жили то до этого вообще не понятно.
зыж
да, как девочки хлопают глазками, мне всегда нравилось. :D
>3. Некоторые зависимости как раз НЕ НУЖНО обновлять именно для конкретного софта.неа. это как раз этот конкретный софт нужно обновлять вместе с зависимостями.
а не жрать дырявый софт.
а если уж совсем припрёт (купили, обобосрались, заменить не могём), то запускаем софт с вот такой переменной окружения $LD_LIBRARY_PATH и/или $LD_PRELOAD (см. http://en.wikipedia.org/wiki/Dynamic_linker) и/или в черуте. при этом усиленно наблюдаем за этим LIBRARY_PATH с устаревшими библами чем то типа selinux.
зыж
остальное даже обсуждать не хочется. понятно что для этого костыля должны быть и другие подпорки. а то уж совсем фигня получится.
> остальное даже обсуждать не хочется. понятно что для этого костыля должны быть
> и другие подпорки. а то уж совсем фигня получится.Какие у вас сильные ТЕОРЕТИЧЕСКИЕ познания. Того и глядите вендоры дитрибьютивов прочтут это сообщение и перейдут разом на скользящие релизы. Ибо всё просто как два пальца. Чего старье-то поддерживать? Да и переписать пару-тройку миллионов строк учетной системы - это как два пальца, благо со скользящим релизом всё просто - система глючила и будет глючить, зачем что-то менять?
по сабжу есть что сказать или продолжим обсуждать мои личные качества?
зыж
вот и я смотрю, чё огрызок всё разноцветных леопардов то клепает. то 10.5, то 10.6.7 уже.
с таким набором панацей давно уже должен был стать ролинг-релизом.
хотя... бабки за что брать? и то верно. :D
правда это не объясняет ни дыр, ни регрессий, ни невозможности запускать "старый" софт, возле которого по-прежнему нужно бить в шаманский бубен и совершать другие непотребства.
Для этого надо пользоваться снапшотами файловой системы.
Думаю все гораздо проще.Если посмотреть кто именно продвигает этот формат (разработчики PС-BSD), то напрашивается вывод : формат сделан для того, чтобы быстрее и проще проводить установку пользовательского ПО.
В данных пакетах программы уже скомпилированны со всеми своими зависимостями и установка по сравнению с обычными портами не требует обновления портов и последующей компиляции, как это обычно происходит во фре.
Как по мне - нормальное улучшение. Чем проще и быстрее - тем лучше, особенно если есть нормальный канал связи.
> Как по мне - нормальное улучшение. Чем проще и быстрее - тем лучше, особенно если есть нормальный канал связи.Проще? Отлично. Завтра обнаруживают уязвимость в zlib. Ваши действия?
>> Как по мне - нормальное улучшение. Чем проще и быстрее - тем лучше, особенно если есть нормальный канал связи.
> Проще? Отлично. Завтра обнаруживают уязвимость в zlib. Ваши действия?В случае с PBI - заместить директорию Applications -> mapplication содержимым нового PBI.
Как на Маке :)
С zlib скомпоновано полсистемы (утрированно). Сколько PBI придётся пересобрать мейнтейнерам, сколько PBI скачать и переустановить пользователю, насколько оперативно это будет сделано, сколько сотен мегабайт придётся скачать?Утверждать, что PBI, или "C:\Program Files", или другие подобные вещи, — хорошо и удобно, может только человек, не понимающий, как устроена его система и почему она устроена именно так.
> С zlib скомпоновано полсистемы (утрированно). Сколько PBI придётся пересобрать мейнтейнерам,
> сколько PBI скачать и переустановить пользователю, насколько оперативно это будет сделано,
> сколько сотен мегабайт придётся скачать?
> Утверждать, что PBI, или "C:\Program Files", или другие подобные вещи, — хорошо
> и удобно, может только человек, не понимающий, как устроена его система
> и почему она устроена именно так.Впринципе для базовой системы вполне себе работает freebsd-update. Пакеты из базовой системы в pbi не попадают. Для пакетов из портов вполне себе обновляемо и ИМХО вполне себе удобно.
>Утверждать, что PBI, или "C:\Program Files", или другие подобные вещи, — хорошо и удобно, может только человек, не понимающий, как устроена его система и почему она устроена именно так.в точку.
>>Утверждать, что PBI, или "C:\Program Files", или другие подобные вещи, — хорошо и удобно, может только человек, не понимающий, как устроена его система и почему она устроена именно так.
> в точку.Сколько раз вы BLFS поднимали?
Ни одного. так?
пиписками померимся?
у меня и сейчас пропатченная гента с ксенированным ведром
$ uname -a
Linux mylaptop 2.6.39-rc5-git4 #1 SMP PREEMPT Mon May 2 00:06:56 MSD 2011 x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
и с кластером для тестов в виртуалках на ноуте с которого я сейчас пишу.
и терминальный бездисковый клиент для работы в сети ~200 машин на территории в 35000 кв.м я собирал ещё 8 лет назад.зыж
а с какой целью вы задаёте такой вопрос?
или больше аргументов по сабжу не осталось, как давить якобы своим, якобы авторитетом? :D
>> или больше аргументов по сабжу не осталось,PBI, или "C:\Program Files" -- ХОРОШО и УДОБНО.
Как на Маке, например.
В "Applications" мышкой втащил фолдер - установлено и работает.
В трэш фолдер с приложением выкинул - деинствллировал.
И НИКАКИХ зависимостей, ни прямых, ни обратных и никакого засирания несвязной (в смысле математического определеня) лапшой баз пакаджей."C:\Program Files" не вполне канает - там не все, часть либ рассирается по системе в самом неожиданном порядке + под тыщу ключей реестра на приложение.
А на Маке все пучком. Хоть я его и не люблю.
uname -a
Darwin s-Computer.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
>PBI, или "C:\Program Files" -- ХОРОШО и УДОБНО.слова виндо/мако-фила.
это НЕ ХОРОШО и НЕ УДОБНО.а вот что удобно, так это появившиеся магазины приложений и в маке, и в винде, и в убунте.
аля айфон, маемо, этк
где есть описание, скриншоты, рэйтинг, а в бубунте даже можно попробовать не устанавливая.
http://www.bubuntu.spb.ru/test-drive-in-ubuntu-11-04/вот это да, и ХОРОШО, и УДОБНО.
и пользователю положить болт где это валяется.
а под маком и виндой как были наиболее популярными приложения по клианинг системы, так и останутся - чистильщик реестра, убирание кода ппа, не используемых приложений и тд.
так что не нужно выдавать своих тараканов за истину в последней инстанции.
>> Как по мне - нормальное улучшение. Чем проще и быстрее - тем лучше, особенно если есть нормальный канал связи.
> Проще? Отлично. Завтра обнаруживают уязвимость в zlib. Ваши действия?Билд сервер репы пересоберет pbi с zlib в зависимостях. Мне придут апдейты.
билд сервер и без pbi всё собирает и присылает.
только в гораздо меньших размерах.
тем более, что если исправления в zlib не нарушают ни АПИ, ни АБИ, то мне нужно будет скачать только одну либу вообще, а с pbi все те полсистемы в районе 1500 пакетов со 1500 zlib'ами.
>билд сервер и без pbi всё собирает и присылает.
>только в гораздо меньших размерах.
>тем более, что если исправления в zlib не нарушают ни АПИ, ни АБИ, то мне нужно будет
>качать только одну либу вообще, а с pbi все те полсистемы в районе 1500 пакетов со 1500 zlib'ами.Все что в базе идет в pbi не попадает. Если Вы посмотрите на pbidir там >90% апликух сугубо десктопные. Их как показывает практика стоит ну, скажем 20.
ЗЫЖ
1. Кстате, а сколько из 1500 пакетов это именно приложения а не библиотеки (зависимости и зависимости зависимостей)?
2. И еще вопрос - не проще ли на десктопе наблюдать список из 20 апликух чем список из 1500 "паетов"?
3. Да, и хотелось бы иметь возможность ГАРАНТИРОВАНО и БЕЗОПАСНО удалить апликуху под чистую (с зависимостями). Снепшоты не предлагать.
вот именно. чуть стоит изменить базу и этот пакет тоже придётся менять.
другими словами, новая версия дистра - новый пакет.
>1. Кстате, а сколько из 1500 пакетов это именно приложения а не библиотеки (зависимости и зависимости зависимостей)?вопрос не понятен - речь про 1500 пакетов pbi? в которых очевидно как минимум одно приложение и одна сторонняя библиотека (если их будет 10 сторонних, то и обновлять 1500 пакетов нужно будет в 10 раз больше)
а вообще, то прикладух гораздо больше чем количество пакетов. к примеру даже с библой zip идут ещё и приложения
$ equery f dev-libs/libzip
/usr/bin/zipcmp
/usr/bin/zipmerge
/usr/bin/ziptorrent
или вот к примеру библа глибс (да, системная, смена которой pbi не поможет, буде такой под линем появиться), так там приложений -
/sbin/ldconfig
/sbin/sln
/usr/bin/catchsegv
/usr/bin/gencat
/usr/bin/getconf
/usr/bin/getent
/usr/bin/iconv
/usr/bin/ldd
/usr/bin/lddlibc4
/usr/bin/locale
/usr/bin/localedef
/usr/bin/memusage
/usr/bin/memusagestat
/usr/bin/mtrace
/usr/bin/pcprofiledump
/usr/bin/rpcgen
/usr/bin/sprof
/usr/bin/xtrace
.....
зыж
>3. Да, и хотелось бы иметь возможность ГАРАНТИРОВАНО и БЕЗОПАСНО удалить апликуху под чистую (с зависимостями). Снепшоты не предлагать.дело важное конечно, но гораздо важнее чтобы ГАРАНТИРОВАНО и БЕЗОПАСНО эта прикладуха работала. а когда она уже удалена и НЕ работает, то очистка системы не столь критичная вещь (библы то тоже будут апдэйтится даже если и не нужны, но дырок по безопасности не будет), которую можно отложить до ТО (таскать доплибы вам ведь не слабо с pbi? а оставить несколько пакетов на некоторое время слабо? :D)
вот так это делается в генте:
>В Portage существует возможность удаления остаточных зависимосей, но так как зависимости программ меняются со временем, доступность программного обеспечения, прежде всего требуется полностью обновить всю систему, включая реализацию изменений, произведенных путем модификации USE-флагов. После этого можно запустить emerge --depclean, чтобы удалить остаточные зависимости. Когда это сделано, вам потребуется пересобрать приложения, ранее динамически связанные с удаленными пакетами, в которых они теперь не нуждаются.
>Со всем этим управляются следующие три команды:# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild
> зыж
>>3. Да, и хотелось бы иметь возможность ГАРАНТИРОВАНО и БЕЗОПАСНО удалить апликуху под чистую (с зависимостями). Снепшоты не предлагать.ЗАДАЧА PBI : сделать десктоп "ЮЗЕР ФРЕНДЛИ".
Чтобы юзер мог безопасно изнасиловать систему САМОСТОЯТЕЛЬНО установив/удалив сколько ему пожелается пакетов. Речь не об обновлянсе по соображениям вышедшего фикса пакета, а об уствновить/удалить.КТО из присутсвующих не налетал жестоко на обновлении систмы или на установке пакета, который тянет либы НЕ совместимые никаким боком с уже стоящими и не обнаруживал, что АА заработало, а ББ - больше не запускается, давая корку?
PBI живет в своей директории и нихера никому не мешает. В этом сила.
а то юзер не сможет залесть в бандлы и не поудалять там чё-нить нужное, угу.
>КТО из присутсвующих не налетал жестоко на обновлении систмы или на установке пакета, который тянет либы НЕ совместимые никаким боком с уже стоящими и не обнаруживал, что АА заработало, а ББ - больше не запускается, давая корку?и как правило это ВСЕГДА связано с системной библой аля glibc в линухе.
собственно смена подобной библы для пакетного дистра и является поводом смены версии дистра.
и открою секрет - такие библы не идут в pbi, и в маке тоже идут с системой.
и именно поэтому и в маке ОЧЕНЬ часто встречаются требования вида - "для тигра возьмите это, для леопёрда - это, а для сноупёрда - вон то"
и если пользователь кидает не то приложение, то потом зовёт такого как я.
>PBI живет в своей директории и нихера никому не мешает. В этом сила.в это раписяийство, а не сила.
потому что там живёт только не критичные библы, которые и так никому не мешают.
и живут они там бесконтрольно.
>> ...ВСЕГДА связано с системной библой аля glibc в линухе.Никогда не "ВСЕГДА связано".
докажи. :D
> в это раписяийство, а не сила.
> потому что там живёт только не критичные библы, которые и так никому
> не мешают.
> и живут они там бесконтрольно.Ну почему же беcконтрольно? Просто ответсвенность несет создатель конкретного pbi, а не мейнтейнер пакета. В случае централизированой репы на pbidir впринципе все должно быть вполне себе контролируемо. Но не только мейнтейнерами портов а еще и админами билд сервера pcbsd. Им никто не мешает пересобирать pbi при изменении зависимостей порта из которого он собирается. Правда, руку на отсечение не дам делают ли они это автоматом.
>вопрос не понятен - речь про 1500 пакетов pbi?pbi задумывалась для десктопа сугубо. Проще видеть список из 20и явно установленых апликух чем 1500 пакетов большая половина которых приехала по зависимостям. С pbi это банально нагляднее.
Еще приятная штука. Можно собрать pbi для виндового приложения с wine на борту. При этом версия wine будет именно та на которой приложение гарантировано работает и обновление вайна из другого pbi или порта ничего не поломает. А еще наверное бывает комерческий / закрытый софт в котором зависимости прибиты гвоздями. А еще кто-то может требовать патченую либу.
Минус тут только один- количество трафика гораздо больше при обновлении одной либы. При обновлении придут дифы в худшем случае для 20и pbi вместо одной либы, это да.
> 2. И еще вопрос - не проще ли на десктопе наблюдать список из 20 апликух чем список из 1500 "паетов"?Если с zlib скомпоновано 20 аппликух, то их все придётся переустанавливать. Если с zlib скомпоновано 1500 "пакетов", то переустановить придётся только zlib. Так что — нет, не проще.
> Думаю все гораздо проще.
> Если посмотреть кто именно продвигает этот формат (разработчики PС-BSD), то напрашивается
> вывод : формат сделан для того, чтобы быстрее и проще проводить
> установку пользовательского ПО.Проще — для коммерческого ПО.
Для открытого ПО, которое в коллекции портов, проще и быстрее устанавливать и поддерживать ПО в актуальном состоянии через бинарные пакеты ("pkg_add [-r] <устанавливаемый пакет>", "portinstall -PP <устанавливаемый пакет>", "portupgrade -PP <обновляемый пакет>").
PBI нужны, чтобы отвязаться от текущих версий зависимых пакетов в непрерывно обновляемой коллекции портов.
вот именно. спрашивается - и чего спорили?зыж
>Проще — для коммерческого ПО.и даже не проще, а как бы это сказать то....
в общем есть уже примеры комерческого софта с репами для версий убунты, рэдхэта и тд.
не думаю что этот в автомате собирающий скрипт у них на сервере для очередной бубунты слишком обременителен для бизнеса и кошелька. да вон опера всем известная даже.
в общем продал ведро яблок - сверху красные, в середке червивые, внизу гнилые.
опять же, статическую линковку никто не отменял...
Откомпилите один раз на билд-сервере и раздавайте БИНАРНИКИ СО ВСЕМИ ЗАВИСИМОСТЯМИ быстро, компактно и красиво. А главное - без лишнего мусора! Единственное для себя применение данной вещи - делать урезанные по самое небалуйся джейлы не заморачиваясь. Но такие штуки опять же - сам, с мне нужным набором, а не фиг знает чем.
Этот ПБИ не часть системы, и не входит в комплект поставки, а лишь порт-программа.
Честно говоря, приложений в формате PBI маловато, поэтому добавление еще одного инструмента по их созданию это скорее плюс, чем минус. Причем плюс в большей степени PC-BSD, нежеле самой BSD.
> Честно говоря, приложений в формате PBI маловато, поэтому добавление еще одного
> инструмента по их созданию это скорее плюс, чем минус. Причем плюс
> в большей степени PC-BSD, нежеле самой BSD.Что мешает дождаться исполнения make?
Сколько ПОРТОВ во Фре, СТОЛЬКО и PBI.ssh ля-ля-ля
screen -ls
screen -dr
make -> PBI
>> Честно говоря, приложений в формате PBI маловато, поэтому добавление еще одного
>> инструмента по их созданию это скорее плюс, чем минус. Причем плюс
>> в большей степени PC-BSD, нежеле самой BSD.
> Что мешает дождаться исполнения make?
> Сколько ПОРТОВ во Фре, СТОЛЬКО и PBI.portupgrade мешает. К сожалению во фре нормальных бинарных обновлений пакетов как-то нету.
> portupgrade мешает. К сожалению во фре нормальных бинарных обновлений пакетов как-то нету.portupgrade -PP <обновляемый пакет>
env PKG_PATH=/mnt/cdrom/packages/All portupgrade -aPP
Мне кажется, файловая система любого дистра должна быть по аналогии GoboLinux. Любой самодостаточный софт надо записывать на образ виртуального диска через loop и монтировать его к Programm Files и не париться с пакетами, зависимостями и прочей ерундой.
> Мне кажется, файловая система любого дистра должна быть по аналогии GoboLinux. Любой
> самодостаточный софт надо записывать на образ виртуального диска через loop и
> монтировать его к Programm Files и не париться с пакетами, зависимостями
> и прочей ерундой.Во Фре роль каталога "Programm Files" выполняет каталог "/usr/local".
Вот, например, OpenJDK хорошо ложится в схему самодостаточности: основной каталог у него /usr/local/openjdk6, а в /usr/local/bin присутствуют только ссылка от отдельного пакета javavmwrapper на javavm OpenJDK (выбранного в данный момент JDK).
Таким образом, /usr/local/bin,/usr/local/lib* — это каталоги глобальных (основных) пользовательских программ (грубо говоря, в эти кучи свалено всё, что может пригодиться в любой момент). А, вот, отдельные каталоги пользовательских программ в /usr/local представляют собой самодостаточные (слабо зависимые) от глобальных программ подсистемы, которые управляются и сопровождаются всё так же — через системные утилиты pkg_*.
Система PBI же — это уже другой уровень — для каждой программы "свой" каталог /usr/local. Независимость офигенная.
Еще один не осиливший. За исключением отдельных случаев "серьёзного" софта (да, для них можно и PBI или аналоги задействовать) разработчику прикладной софтины в плане требуемых бибилиотек доверия никакого, в отличие от авторов библиотек - так как обычно уровень разработчиков очень отличается, как и фокус их внимания. Поэтому в случае мейнстрима чем более централизованы обновления и стандартизированы бибилиотеки, тем больше шансов, что у вас будет рабочая и надёжная система. Известен тсяча и один пример, когда разработчики чухались править софт, переходя на обновленные версии бибилотек с починенными багами только когда их запинывали дистростроители.
а также pbi не помогает с системными библиотеками, которых в макоси к примеру тоже не мало.
и поэтому очень часто встречается "для тигра установите это", для "леопарта вот это".
вот к примеру для макпорта требования:
>Please note that in order to install and run MacPorts on Mac OS X, your system must have installations of the following components:
>Apple's Xcode Developer Tools (version 3.2.1 or later for Snow Leopard, 3.1.4 or later for Leopard, or 2.5 for Tiger), found at the Apple Developer Connection site or on your Mac OS X installation CDs/DVD. Ensure that the optional components for command line development are installed ("Unix Development" in the Xcode 3.x installer).т.е. выходит что подобный подход если и хорош для чего, то либо для кривых прикладных поделок, либо для "ленивых" проприетарщиуков. вот скайп на моём ведре 2.6.39-rc5-git4 x` выдаёт:
$ dmesg | grep skype
[57280.046129] process `skype' is using obsolete setsockopt SO_BSDCOMPAT
и фиг его поправят жеж.
да кому какое дело что кто-то там добавил в порты ? вот чессслово...
это очень здорово. может быть и до линукса дойдет.