Вышел (http://desktopbsd.net/index.php?id=43&tx_ttnews[tt_news...) релиз десктоп-ориентированной операционной системы DesktopBSD 1.7 (http://desktopbsd.net/index.php?id=94), построенный на базе FreeBSD 7.2, X.Org 7.4, KDE 3.5.10, OpenOffice.org 3.1.1, и снабженных графическим инсталлятором и набором дополнительных GUI утилит для настройки системы. Дистрибутив доступен (http://desktopbsd.net/index.php?id=84) для загрузки в LiveDVD сборках, размером 1.9 Гб, для архитектур i386 и amd64.К сожалению, это последний релиз, подготовленный при участии Петера Гофера (Peter Hofer), основателя и единственного активного разработчика DesktopBSD, который объявил об уходе из проекта. Отныне будущее DesktopBSD зависит от того найдутся или нет энтузиасты, готовые продолжить развитие системы, например, заняться переводом дистрибутива на KDE4. К сожалению несколько месяцев поиска таких энтузиастов не увенчались успехом.
URL: http://desktopbsd.net/index.php?id=43&tx_ttnews[tt_news...
Новость: http://www.opennet.me/opennews/art.shtml?num=23328
Ещё один канул в лету, а жаль
Петеру Гоферу надо было на Опеннете поискать - тут столько почитателей и защитников БСД, что кто-то бы, гляди, и подхватил инициативу...
Ну а что, прочитают, увидят и сами может продолжат развивать проект.
чтоб подхватить инициативу чего-то там, нужно чтоб изюминка была.
какая идеология DesktopBSD ? в чём её идея ? что в ней есть такого, чего нет в других - в PC-BSD, например ? если есть хорошие ответы на такие вопросы - разработчики будут. если нет - ну что ж, пусть расцветают сто цветов, пусть соперничают сто школ...
Последний? Больше релизов не будет? RIP...
Нескромно, но я и пара товарищей пытаемся сделать изначально-русифицированный облегченный дистрибутив на базе FreeBSD, но увы. Времени и опыта откровенно мало...
> Нескромно, но я и пара товарищей пытаемся сделать изначально-русифицированный облегченный дистрибутив
>на базе FreeBSD, но увы. Времени и опыта откровенно мало...Вот-вот, и хорошо что `увы', в следующий раз потратите время с пользой. Локализованные дистрибутивы в прошлом опросе на ЛОР уже обсудили. Если вкратце - они лютое зло.
Это чтоли чтобы инсталлянт не спрашивал а сразу ставил KOI-8 и досовские и виндовские шрифты? Думаю при полном отсутствии опыта делов на выходные максимум.
>Нескромно, но я и пара товарищей пытаемся сделать изначально-русифицированный облегченный
>дистрибутив на базе FreeBSD, но увы. Времени и опыта откровенно мало...А можно подробнее на почту?
А зачем нужен DesktopBSD, если есть PC-BSD? Ничего страшного в смерти этого проекта не вижу, тем более, что остался всего один разработчик.
потому что он лучше. пысыбсд глюкавая поделка. десктопбсд ставил - понравилось.
PC-BSD — это стандарт корпоративного (iXsystems) десктопа, в отличие от "продукта одного автора" DesktopBSD.
Ссылку на ГОСТ можно? Ну или хотя бы на ISO?
>PC-BSD — это стандарт корпоративного (iXsystems) десктопа, в отличие от "продукта одного
>автора" DesktopBSD.чеж она так глючит и страдает идиотским переводом, если сделана корпоративщиками? O_O один текст лицензии чего стоит. кто такой гуртовщик? и что такое всякая фигня?
> кто такой гуртовщик?Гуртовщик? Никогда о таком не слыхали? Ну нате вам, если еще не читали :). http://lib.ru/ANEKDOTY/mouse_driver.txt
это kdetoys, вполне логичная характеристика
> PC-BSD — это стандартНомер стандарта - в студию ;)
А зачем PC-BSD, если есть FreeBSD.
А зачем все *BSD, если есть Винда?
Каждый проект это идеи, умер проект - идей не будет,
вот это и жаль.
Да не было там никаких идей. Просто кое-что сделано разработчиками за юзера.
Назовите хоть один десктоп-ориентированный Линукс где-бы было по другому!!!
Дык о том и речь - очень хорошо что FreeBSD не уподобляется линуксовому зоопарку.
узколобое мнение. в линукс зоопарк возможен благодаря тому что linux целиком модульная система, а BSD монолит и трудозатраты на поддержку несравнимо выше. Причем я не говорю об ядре, я говорю о системе в целом.
Приведите пример пожалуйста.
Про монолит.
Дайте две. Два монолита.
По модульности оно одинаково, может конечно с ходу не получится разные libc на kfreebsd повесить, но и с линуксом это не было сразу. Тут допил нужен минимальный, также и остальные компоненты. Нет между linux+glibc+portage(это так пример) и freebsd такой разницы, чтобы говорить о несравнимо более высоких трудозатратах. Примерно те же идеи, примерно похожие подходы. Да, по разному сделано и тд и тдп. Да, фрибсдшники как и другие бсдишники стараются развивать всё в едином древе, но это непринципиально, это не технологическая разница, а организационная.
Зоопарк linux дистрибутивов возник потому, что линукс впереди по распространённости, так как раньше засветился и по разным другим причинам. И ещё потому, что используется в разных ситуациях и разными потребителями. Кому-то просто необходимо нечто вроде rhel, а кому-то достаточно и arhlinux. Окажись любая из bsd систем на месте линукса - ситуация была бы примерно такой же. Небольшим доказательством этого является существование сабжа и PCBSD. Если бы какая-нибудь NONAME.company использовала бы freebsd на манер redhat, то дистрибутив под названием NONAME.company enterprise freebsd непременно бы появился.
Не согласен насчет одинаковости - линух только ядро а софт я могу подбирать сам, в меру своей испорченности и задач - в абстрактном сферическом линухе в вакууме мне никто не сватает никаких наборов софта. Иногда это удобно. Например в какихнить embedded применениях где места на все про все с кошкин зад и нужны лишь сильно некоторые вещи, данное свойство пингвина дает ему зеленый свет лишний раз.
Это организационная разница, а не техническая. Думаю вам прекрасно известно что при желании можно использовать ядро линукса с бздёвым окружением. И наоборот. Допил тут конечно потребуется, но если задатся целью - это возможно.
Там выше речь шла про модульность, так вот модульность это не понятие организации разработки, а понятие техническое. Означающее, что разные компоненты системы можно заменять, или убирать без переписывания всего и вся. Если бы linux, glibc, binutils, coreutils, grub, portage развивались в одной организации и под началом того же Линуса, то линукс в целом не перестал бы быть от этого менее модульным, так как заменить glibc всё равно можно было бы на ulibc и тд. Также и bsd при всей свой ориентированности на построение единой архитектуры, полноценной OS, не перестаёт быть модульной.
>Не согласен насчет одинаковости - линух только ядро а софт я могу
>подбирать сам, в меру своей испорченности и задач - в абстрактном
>сферическом линухе в вакууме мне никто не сватает никаких наборов софта.
>Иногда это удобно. Например в какихнить embedded применениях где места на
>все про все с кошкин зад и нужны лишь сильно некоторые
>вещи, данное свойство пингвина дает ему зеленый свет лишний раз.Вообще-то существует Debian GNU/kFreeBSD, который вполне доказывает, что FreeBSD это тоже ядро ;)
>>Не согласен насчет одинаковости - линух только ядро а софт я могу
>>подбирать сам, в меру своей испорченности и задач - в абстрактном
>>сферическом линухе в вакууме мне никто не сватает никаких наборов софта.
>>Иногда это удобно. Например в какихнить embedded применениях где места на
>>все про все с кошкин зад и нужны лишь сильно некоторые
>>вещи, данное свойство пингвина дает ему зеленый свет лишний раз.
>
>Вообще-то существует Debian GNU/kFreeBSD, который вполне доказывает, что FreeBSD это тоже ядро
>;)Ничего не доказывает: http://alv.me/archives/413
> в линукс зоопарк возможен благодаря тому что linux целиком модульная система а BSD монолитНачнем с того, что linux - не система. Дальше говорить не о чем.
>BSD монолит и трудозатраты на поддержку несравнимо вышеЧто за глупости?
DesktopBSD появился за год до PC-BSD. И тоже в пору было спрашивать, зачем появился PC-BSD, а теперь совершенно очевидно, что он не только пережил дэсктопину, но и активно процветает. Не вам решать, короче.
DesktopBSD БЫЛ всётаки лучше IMHO.
А за PBI расстреливать надо..
>DesktopBSD БЫЛ всётаки лучше IMHO.Чем? Какие идеи в ней были уникальными?
>А за PBI расстреливать надо..
Это за *.so-hell и решение в виде симлинков надо расстреливать. А за бесконфликтное ПО нужно гладить по головке.
>Это за *.so-hell и решение в виде симлинков надо расстреливать.Что такое *.so-hell? Сами придумали? Чем вам не по душе симлинки?
>>Это за *.so-hell и решение в виде симлинков надо расстреливать.
>
>Что такое *.so-hell? Сами придумали? Чем вам не по душе симлинки?Вот оно:
% portinstall -p java/diablo-jdk16
...
===> Registering installation for diablo-jdk-1.6.0.07.02_5
...
===> Building package for diablo-jdk-1.6.0.07.02_5
...
===> Cleaning for diablo-jdk-1.6.0.07.02_5
---> Cleaning out obsolete shared libraries
[Updating the pkgdb in /var/db/pkg ... - 444 packages found (-0 +1) . done]
% rehash
% java -version
Error occurred during initialization of VM
Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so
% echo "libz.so.4 libz.so.5 #for diablo-jdk1.6" >> /etc/libmap.conf
% rehash
% java -version
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
Мимо, это всего лишь неустранимая проблема закрытого ПО - оно гвоздями прибито к и библиотеками, с которыми собрано. Почитайте про DLL Hell на досуге: http://ru.wikipedia.org/wiki/DLL_hell. Современных UNIX-like систем это никак не касается.
>Мимо, это всего лишь неустранимая проблема закрытого ПО - оно гвоздями прибито
>к и библиотеками, с которыми собрано. Почитайте про DLL Hell на
>досуге: http://ru.wikipedia.org/wiki/DLL_hell. Современных UNIX-like систем это никак не касается.их касается dependency hell и современных nix like систем это касается:P
>их касается dependency hell и современных nix like систем это касается:PМожет быть бинарных недодистрибутивов разве что, debian, например. При это если их использовать как задумывалось, т.е. использовать только родные пакеты от релиза, никаких проблем не будет. Но нам же не хочется компилять, зато хочется новый софт, сами себе hell и создаете. ССЗБ.
А вот с source-based никаких проблем нет и быть не может, я на всех своих FreeBSD серверах и десктопах поддерживаю в актуальном состоянии почти 3500 разных пакетов, никогда никаких проблем не было. portupgrade -a и точка.
>А вот с source-based никаких проблем нет и быть не может,... кроме случаев когда ваше мнение о правильной версии либы X разошлось с мнением автора о правильной версии либы X и в сорце программы от этого автора есть какие-то существенные отличия, прекрасно работающие с его либой, версии которая у него, но мешающие использованию вашей версии либы. И при этом радости то что source-based? Будете перефигачивать полпрограммы заменяя вызовы функций либы? :)
>portupgrade -a и точка.
Угу, как у вас все просто, если загнать себя в некие рамки. С таким подходом и apt-get dist-upgrade прокатит, особенно на всяких дебиян-unstable :P. А вот попробуйте собрать какую-то программу слитую где-то там на стороне, автор которой - отпетый авангардист или наоборот жуткий ретроград, так что у него либы - сильно новые (вплоть до левых позавчерашних svn-ревизий только что счекаутеных из репа авторов этой либы) или напротив древние как помет мамонта (потому что автору влом переписывать прогу на новый манер вызовов в новой версии либы например). И если при этом у либ с тех пор изменились вызовы не дай боже - это попадос, потому что если хочется пользоваться какой-то иной версией либы, нежели посчитал нужным автор - придется самолично переписать половину программы. Всего-то. Ну-ка похвастайте как вы с этим боретесь в source based?
>:P. А вот попробуйте собрать какую-то программу слитую где-то там на
>стороне, автор которой - отпетый авангардист или наоборот жуткий ретроград, так
>что у него либы - сильно новые (вплоть до левых позавчерашних
>svn-ревизий только что счекаутеных из репа авторов этой либы) или напротив
>древние как помет мамонта (потому что автору влом переписывать прогу на
>новый манер вызовов в новой версии либы например). И если при
>этом у либ с тех пор изменились вызовы не дай боже
>- это попадос, потому что если хочется пользоваться какой-то иной версией
>либы, нежели посчитал нужным автор - придется самолично переписать половину программы.
>Всего-то. Ну-ка похвастайте как вы с этим боретесь в source based?В source-based используется система сценариев установки ПО из исходников.
Например, в FreeBSD применена система "коллекции портов".
Там можно встретить ПО разных версий (к примеру):
ports/net-p2p/azureus — Azureus 3.1.1.0
ports/net-p2p/azureus2 — Azureus 2.5.0.4
ports/net-p2p/vuze — Azureus 4.2.0.2ports/lang/perl5.8
ports/lang/perl5.10ports/databases/mysql323-server
ports/databases/mysql40-server
ports/databases/mysql41-server
ports/databases/mysql50-server
ports/databases/mysql51-server
ports/databases/mysql54-server
ports/databases/mysql60-serverПричём из перечисленных категорий можно установить только что-то одно, а не две и более версии, так как между ними неразрешимы конфликты по используемым библиотекам и именам запускаемых файлов (пути в PATH должны быть уникальными и точно идентифицировать рабочие каталоги программ).
Система PBI позволяет держать в системе всё нужное БЕЗ конфликтов и не ограничиваться ограничениями PATH (и LD_LIBRARY_PATH).
Вы задаете настолько глупые и нубские вопросы, что даже отвечать не охота. Тем более, что вы все равно упретесь, не признаете очевидных фактов и сведете все к фанатизму. Но попробую.Depencency hell, ок котором мы говорили, имеет место только в бинарных дистрах. Почему? Из-за жестко прибитых депендов.
Обновилась библиотека jpeg.6 до jpeg.7, и надо вам поставить новенький пакет который требует jpeg.7. Что делать? Старные пакеты явно требуют 6, и с 7 работать не будут. Новый требует 7 и не будет работать с 6. Поставить их вместе нельзя, потому что они конфликтуют. Достаточно, на самом деле, всего лишь сохранить сошку от 6 - старые приложения ее будут использовать и дальше. Но увы, депенды прибиты гвоздями, пакетный менеджер при таком раскладе сходит с ума.
Это и есть ваш dependency hell - фактически, искусственно созданная проблема.
В source based же, обновляется порт jpeg. Юзеры делают portupgrade jpeg, при этом старая сошка сохраняется, установленный софт счастливо использует ее, а новый линкуется с новой. При желании, можно пересобрать все на новую. Можно не пересобирать. Все гибко донельзя.
А то, что вы написали - как обычно, не в кассу. Если в библиотеке ломают API, патчить придется весь софт который ее использует. Это делают как в бинарных дистрибутивах, так и в source-based. Только разработчики (особенно X, это вы очень мимо ее сюда приплели) умные, и API не ломают - это совсем не сложно, достаточно не удалять методы и аргументы, а новые аргументы добавлять в конец и с дефолтным значением. Все. ABI же ломается регулярно, потому что для поломки ABI достаточно изменить поле в любой внутренней структуре или сигнатуру любой функции.
> Угу, как у вас все просто, если загнать себя в некие рамки
Это как раз отсутствие рамок - я могу обновить только то, что мне нужно, не перекачивая и переустанавливая при этом полсистемы.
>их касается dependency hell и современных nix like систем это касается:PАга - в виндах просто таскают с собой все зависимости. В итоге проги распухают до размеров сидюшника иной раз. Или просто посылают в пешее эротическое - "скачайе и поставьте вон те редистрибутаблы и запустите нас снова". И кучи копий одних и тех же либ разбросаны по всей системе а то и вовсе заинтегрированы в бинарь. Кто не верит - ищет по всему диску во всех файлах слово "deflate " и делает выводы о "shared" библиотеках. В типовой виндусе оно встречается раз сто. И если какой-то фрукт вдруг не заапдейтил ее с дырявой версии (помните там клевую дырку находили?) - прога потенциальный кандидат на получение кульного сплойта в любых пожатых злибом данными. Такая же фигня случалась с libpng и еще рядом широко используемых библиотек. И те кто понапихал себе необновляемых приватных копий либ во все дыры - потенциально отличная такая мишенька для хаксоров с сплойтами для старых версий либ.
[tiger@notebook]~%ll /etc/libmap.conf
ls: /etc/libmap.conf: Нет такого файла или каталога
[tiger@notebook]~%java -version
java version "1.6.0_07"
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
[tiger@notebook]~%pkg_info -xI diablo-jdk
diablo-jdk-1.6.0.07.02_6 Java Development Kit 1.6.0_07.02
[tiger@notebook]~%uname -rms
FreeBSD 9.0-CURRENT i386
>[tiger@notebook]~%ll /etc/libmap.conf
>ls: /etc/libmap.conf: Нет такого файла или каталогаДа что вы говорите:
libmap.conf(5):
http://www.freebsd.org/cgi/man.cgi?query=libmap.conf&apropos...
HISTORY
The libmap.conf manual page and libmap functionality first appeared in
FreeBSD 5.1.
>[оверквотинг удален]
>>ls: /etc/libmap.conf: Нет такого файла или каталога
>
>Да что вы говорите:
>
>libmap.conf(5):
>http://www.freebsd.org/cgi/man.cgi?query=libmap.conf&apropos...
>HISTORY
> The libmap.conf manual page and libmap functionality
>first appeared in
> FreeBSD 5.1.и что? в мане где-то написано что файл должен быть?;-) постом выше я показал что не нужно мапить
p.s.:
[tiger@notebook]~%ll /usr/lib/libz*
-r--r--r-- 1 root wheel 79190 4 сен 13:22 /usr/lib/libz.a
lrwxr-xr-x 1 root wheel 14 4 сен 13:22 /usr/lib/libz.so -> /lib/libz.so.5
-r--r--r-- 1 root wheel 81322 4 сен 13:22 /usr/lib/libz_p.a
-r--r--r-- 1 root wheel 276070 29 май 21:18 /usr/lib/libzfs_p.a
[tiger@notebook]~%ll /lib/libz*
-r--r--r-- 1 root wheel 71088 4 сен 13:22 /lib/libz.so.5
[tiger@notebook]~%значит я делаю что-то не так раз у меня jvm запускается, а ты и чувачок из ports@ у которого жава на каррент работать не хотела очевидно все делаете правильно;-)
>Да что вы говоритеlibmap.conf действительно нет по умолчанию
>>Да что вы говорите
>
>libmap.conf действительно нет по умолчаниютам щас в ports@ идет классный троллинг про кошерность хака с libmap.conf:-)
>бесконфликтное ПО нужно гладить по головке.Угу, при том лучше всего - гильотиной, превентивно. Чтоб потом спам с всяких чижиков оптом нам в инбоксы не валился когда они свои либы из куль-сетапов сделанных на манер винды заапдейтить забудут.
Хотя если кому нравится срач из либ по всему диску когда десятки одинаковых либ валяются в разных папках и закоулках системы, жрут в N раз больше памяти и места на диске чем должны а шансы схлопотать сплойтом по древнючей библе и педально-весельные методы устновки софта пришедшие из DOS и Win 3.11 вызывают бурный энтузазизм - посмотрите на Microsoft (R) Windows (tm). Там все это есть, ха-ха :).Но если сравнивать - так, блин, удобно же когда вместо вас вкалывает манагер пакетов и комп. Делать нудную монотонную работу - задача машин, имхо :))
>DesktopBSD БЫЛ всётаки лучше IMHO.
>А за PBI расстреливать надо..+500 :-)
и вообще, не за pbi, а за все это поделие целиком (а за pbi -- даже дважды)
но вообще, desktopbsd-tools есть в портах, так что не страшно.
Ну в конце-концов всё к этому и сводится.
Ну наконец-то. Не нужно зоопарка дистрибутивов как у линукса, хватит одного PCBSD с графическим инсталлятором и PBI (от чего у нормальных разработчиков волосы дыбом встают) - пусть это будет там, подальше от собственно FreeBSD.
>Ну наконец-то. Не нужно зоопарка дистрибутивов как у линукса, хватит одного PCBSD
>с графическим инсталлятором и PBI (от чего у нормальных разработчиков волосы
>дыбом встают) - пусть это будет там, подальше от собственно FreeBSD.
>а как же application bundles? O_O
>а как же application bundles? O_Oчто `как же'? Application bundles идут вслед за PBI в маргинальные поделия, подальше от серьезных систем. Впрочем я уверен что никаких бандлов не будет - эта еритическая идея так всех достала что очередных изобретателей просто не замечают. PBI-то неюзабелен со своей сотней (или сколько там) наглухо устаревших пакетов.
PCBSD победил.
кстати как там с новой псбсд на 8рке ? и будет ли когда нибудь флеш с дрова на 64?
ftp://ftp.pcbsd.org/pub/alpha-iso/x32/PCBSD8.0-ALPHA-2009090...