Новогодний релиз Battle Tanks 0.7.5800 xmas edition

Предлагаю ЛОРовцам кучно сыграть, а то надоело уже с ботами играццо

Спасибо, anonymous (*) (23.12.2007 13:08:17), помогло. Авторам спасибо за игру :)

> error: invalid option argument '-O3 -Wall -pedantic -Wno-long-long -pipe -pthread ' scons: *** [build/release/ai/base.os] Error 1

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

А почему нельзя делать как например у Мозилы - одна бинарная сборка под все дистрибутивы?

initializing resource manager... и сегфолт :(

конец тревоги, исправил :)

> ждём ебилдов - у меня сын от этой игры тащится, перестал просить винду :)

http://bugs.gentoo.org/show_bug.cgi?id=203138

> > error: invalid option argument '-O3 -Wall -pedantic -Wno-long-long -pipe -pthread ' scons: *** [build/release/ai/base.os] Error 1

> О да, юзерам только этого не хватало. Мало того, что компилировать игрушки еще и патчить проблемы сборки придется. Вобщем, положение на десктопе у *nix систем плачевное. Вот так всегда, под винду - рабочий бинарь под любую версию винды. Для *nix - компелируйте и разгребайте проблемы сборки.

Ну иди в венду и запускай свои бинари с вирями и прочей муйней. Ну нет у меня в арче официального пакета с танками, взял PKGBUILD из коммунити, изменил версию в нем, makepkg и готов пакет. Что у тебя за дистр, что даже коммунити не участвует в развитии ни фига.

Вобщем установил, запустил, работает :)

Ubuntu 7.10, ATI x1900, Catalyst 7.11.

Сенкс разработчикам за игру и с наступающим Новым годом!

> по поводу геймпада: попробуйте нажать g или j в диалоге настроек - только эта фича кривая и мы её переделаем. чтобы пропустить контрол которого нет на вашем джойстике - нажмите esc.

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

Спасибо - помогло, с джойстиком веселее :)

Фря не поддерживается?

> scons
scons: Reading SConscript files ...
Checking for sigc::signal1<int,int> sig in C++ library sigc-2.0... (cached) yes
Checking for XML_ParserCreate(NULL) in C library expat... (cached) yes
Checking for zlibVersion() in C library z... (cached) yes
Checking for SDL_Init(0) in C++ library SDL... (cached) yes
Checking for IMG_Load(0) in C++ library SDL_image... (cached) yes
Checking for ALuint s; alGenSources(1, &s) in C++ library openal... (cached) yes
Checking for ov_open(0, 0, 0, 0) in C++ library vorbisfile... (cached) yes
version: 0.7.5802M
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated BuildDir targets: build/release
g++ -o build/release/mrt/tcp_socket.os -c -march=native -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -I/usr/local/include/SDL -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -fPIC -O3 -Wall -pedantic -Wno-long-long -pipe -pthread -DUSE_GLSDL -DV3_DISABLE_Z -D_REENTRANT -DRELEASE -DPREFIX="\"/home/ra/compile\"" -DRESOURCES_DIR="\"/home/ra/compile/share/btanks\"" -DMRTAPI=DLLEXPORT -Ibuild/release/mrt -Imrt -Imrt -Ibuild/release/mrt/src -Imrt/src -Imrt/src -I. -Isrc mrt/tcp_socket.cpp
In file included from mrt/tcp_socket.cpp:29:
/usr/include/netinet/ip.h:157: error: 'n_long' does not name a type
/usr/include/netinet/ip.h:160: error: 'n_long' does not name a type
scons: *** [build/release/mrt/tcp_socket.os] Error 1
scons: building terminated because of errors.

> ident /usr/include/netinet/ip.h
/usr/include/netinet/ip.h:
$FreeBSD: src/sys/netinet/ip.h,v 1.32 2007/10/19 12:46:15 rpaulo Exp $

Под фрю все собирается, только игрушка не работает. Я выше писал. Сейчас попробую debug собрать и поковырять.

Во:

(gdb) run
Starting program: /usr/home/amdmi3/projects/ports/btanks/btanks-0.7.5800/bt 
[New LWP 100139]
[New Thread 0x28b01100 (LWP 100139)]
[17:53:34.303][src/main.cpp:44]  [notice] starting up... version: 5800D 
[17:53:34.303][src/main.cpp:46]  [notice] mem avail: -1 mb
terminate called after throwing an instance of '__gnu_cxx::__concurrence_lock_error'
  what():  __gnu_cxx::__concurrence_lock_error

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x28b01100 (LWP 100139)]
0x28645ecf in kill () from /lib/libc.so.7
(gdb) bt
#0  0x28645ecf in kill () from /lib/libc.so.7
#1  0x28645e2e in raise () from /lib/libc.so.7
#2  0x28644bd8 in abort () from /lib/libc.so.7
#3  0x284d9730 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6
#4  0x284dd90a in std::set_unexpected () from /usr/lib/libstdc++.so.6
#5  0x284de2aa in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#6  0x284de052 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#7  0x285750eb in _Unwind_Backtrace () from /lib/libgcc_s.so.1
#8  0x2857564c in _Unwind_RaiseException () from /lib/libgcc_s.so.1
#9  0x284dd859 in __cxa_throw () from /usr/lib/libstdc++.so.6
#10 0x284f1ff6 in __cxa_guard_acquire () from /usr/lib/libstdc++.so.6
#11 0x28334991 in IGame::get_instance () at src/game.cpp:74
#12 0x08049a90 in mrt::Accessor<IGame>::operator-> (this=0x804a3c8) at singleton.h:29
#13 0x08048e26 in main (argc=1, argv=0xbfbfeae0) at src/main.cpp:53

У меня: 8.0-CURRENT #0: Thu Dec 20 07:57:45 MSK 2007

А у тя че? 7-ка?

> А у тя че? 7-ка?

Да, вчерашняя.

тогда в чем интересно дело у мя, в ip.h v1.31? Че-то не верится:
@@ -82,11 +82,6 @@ CTASSERT(sizeof (struct ip) == 20);
#define IPTOS_THROUGHPUT 0x08
#define IPTOS_RELIABILITY 0x04
#define IPTOS_MINCOST 0x02
-#if 1
-/* ECN RFC3168 obsoletes RFC2481, and these will be deprecated soon. */
-#define IPTOS_CE 0x01
-#define IPTOS_ECT 0x02
-#endif

/*
* Definitions for IP precedence (also in ip_tos) (hopefully unused).

вот мой options.cache:
CC = 'gcc'
CXX = 'g++'
CCFLAGS = '-march=native -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -I/usr/local/include/SDL '
CXXFLAGS = '-march=native -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/local/include -I/usr/local/include/SDL '
prefix = '/home/ra/compile'

твой?

> Ну иди в венду и запускай свои бинари с вирями и прочей муйней.

Т.е. официальным бинарникам с сайта автора ты не доверяешь? Может быть ты все исходники на наличие троянов проверил? Или ты доверяешь каким-то мантейнерам какого-то арча больше, чем самому автору?! BTW когда развлекался взломом на archlinux.org был рутшелл и доступ к cvs, это так, к слову о троянах/вирусах. :)

> Ну нет у меня в арче официального пакета с танками, взял PKGBUILD из коммунити, изменил версию в нем, makepkg и готов пакет.

Когда ж вы все поймете, что юзер это ПОЛЬЗОВАТЕЛЬ, а не программист и не мантейнер пакетов, поэтому контактировать с исходниками совершенно не обязан. С таким отношением к юзерам и советами "иди на винду" все юзера на нее и сбегут, пока местные будут мачтать о захвате десктопов и вендекапеце, когда любая тетя Дуся будет уметь компилировать PKGBUILD для пасьянса.

> Что у тебя за дистр, что даже коммунити не участвует в развитии ни фига.

Ubuntu на десктопе. Ушел с Gentoo, поюзав ~4 года потому, что затрахался с компиляциями, проблемами после обновлений и регулярными накатываниями багрепортов и как только появился нормальный анлим ушел на дистрибутив, который просто работает, без проблем обновляется, не заставляет часами ждать когда же наконец дособерется пакет и не жрет электроэнергию.

> твой?

Мой пустой c chflags schg, чтобы scons вела себя хоть четь-чуть предсказуемо.

Собираю так:

scons CPPPATH=/usr/local/include LINKFLAGS="-L/usr/local/lib -L/usr/local/lib/lua51 " mode=debug

плюс куча хаков в Scons{truct,cript}
плюс, разумеется, добавить #include <sys/in_systm.h> там где sys/ip.h инклудится.

> Т.е. официальным бинарникам с сайта автора ты не доверяешь? Может быть ты все исходники на наличие троянов проверил? Или ты доверяешь каким-то мантейнерам какого-то арча больше, чем самому автору?! BTW когда развлекался взломом на archlinux.org был рутшелл и доступ к cvs, это так, к слову о троянах/вирусах. :)

Это я вообще, в принципе. Да и не нужны мне виндовые бинарники :) Доверять везде приходится, что делать.

> Когда ж вы все поймете, что юзер это ПОЛЬЗОВАТЕЛЬ, а не программист и не мантейнер пакетов, поэтому контактировать с исходниками совершенно не обязан. С таким отношением к юзерам и советами "иди на винду" все юзера на нее и сбегут, пока местные будут мачтать о захвате десктопов и вендекапеце, когда любая тетя Дуся будет уметь компилировать PKGBUILD для пасьянса.

Естественно, но тем не менее кто-то должен побеспокоиться о создании пакета, мантейнера в арче в данном случае я уведомил, что новая версия пакета есть, то есть тот кто не в силах сам справиться с редактированием PKGBUILD'а просто дождется его обновления. Правда специфика арча такова что собирать из исходников все равно придется, хотя и одной командой при наличии правильного PKGBUILD'а, потому что btanks unsupported пока.

> Ubuntu на десктопе. Ушел с Gentoo, поюзав ~4 года потому, что затрахался с компиляциями, проблемами после обновлений и регулярными накатываниями багрепортов и как только появился нормальный анлим ушел на дистрибутив, который просто работает, без проблем обновляется, не заставляет часами ждать когда же наконец дособерется пакет и не жрет электроэнергию.

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

> Это я вообще, в принципе. Да и не нужны мне виндовые бинарники :) Доверять везде приходится, что делать.

Вот-вот. Когда софт в репозитарии приходится верить и автору и мантейнерам. Так что не знаю как это уменьшает угрозу получить троян в сравнении со случаем, когда приходится верить только автору и его сборке.

> А в убунту по-моему (честно не знаю) нет пользовательского репозитария как в арче.

Что-то вроде оверлея? Есть.

P.S.

Имхо то, чем сейчас занимаются дистроделы - глупость. Система одна, GNU/Linux, а пакеты от одного дистра не подходят к другому. Дошло уже до маразма - несовместимые RPM-пакеты. Переизобретают тысячу раз одни и те же велосипеды yum/yast/apt/apt-rpm и строят свои репозитарии вместо того, чтобы выработать единый стандарт, объединиться и организовать ЕДИНЫЙ репозитарий вместо того, чтобы распалять усилия на сотни велосипедических репозитариев, которые все равно не охватывают даже половины доступного ПО. Есть LSB. Но почему-то не видно LSB-пакетов словно и нет LSB вовсе.

> Естественно, но тем не менее кто-то должен побеспокоиться о создании пакета, мантейнера в арче в данном случае я уведомил, что новая версия пакета есть

Если бы зоопарк дистрибутивов не создавал проблем автору, то универсальный пакет для GNU/Linux мог бы создавать сам автор, как он делает единый универсальный пакет для Windows, так что пользователь мог бы, если в репозитарии пакета нет, зайти на сайт автора и скачать самую свежую версию пакета, а затем поставить его в один клик(не думаю, что для того, чтобы играть в пасмьянс или танчики юзеру необходимо обязательно сильно подумать головой, осовить инструементы сборки и потанцевать с бубном вокруг, чтобы установить игрушку)

> Если бы зоопарк дистрибутивов не создавал проблем автору, то универсальный пакет для GNU/Linux мог бы создавать сам автор, как он делает единый универсальный пакет для Windows, так что пользователь мог бы, если в репозитарии пакета нет, зайти на сайт автора и скачать самую свежую версию пакета, а затем поставить его в один клик(не думаю, что для того, чтобы играть в пасмьянс или танчики юзеру необходимо обязательно сильно подумать головой, осовить инструементы сборки и потанцевать с бубном вокруг, чтобы установить игрушку)

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

Еще одна беда, это куча платформ под которые надо собирать пакеты. Венда-то работает только с x86, а линукс извините меня... :)

Не знаю что у вас за проблемы были с Gentoo, но я, суда по 5летнему опыту общения с портами FreeBSD могу сказать что таки подход портов/portage/pkgsrc/и т.д. наиболее универсален.

Gentoo использовал довольно мало, но ни под ней, ни под FreeBSD проблем не было (за исплюченим случаев, описанных в UPDATING, где нужно набрать пару комманд руками). Сейчас /root/bin/up делает portsnap fetch update && portupgrade -a. Этим обновляется десктоп и 2 сервера и проблем я не припомню (вот года 3 назад иногда что-то ломалось, да).

- Для простого пользователя проблем как раз никаких нету. make search key= и make install. Люди, которым я первый раз показывал как работать с FreeBSD это понимают сразу и в дальнейшем проблем не имеют. (В portage я, признаться, сам до конца не въехал - как там, например, отключить нафиг маскирование пакетов и как посмотреть список файлов для установленного пакета?) Вобщем, думается, любое GUI к портам будет 1:1 synaptic. - На современных процессорах софт собирается минуты, так что сборка является проблемой только при свежей установке системы

Это были т.н. минусы. А плюсы:

- Паранойя может отдыхать, ибо все в исходниках. Даже если есть шанс, что у автора в tarball попадет бяка, всегда можно залезть и посмотреть, ибо для исходников есть diff, в отличие от - Меня лично радует возможность положить свой патчик в порт если надо, а также пересобрать падающее приложение с WITH_DEBUG и натравить на него gdb. Это все-таки к тому, что если юзеры не будут собирать и отлаживать софт сами, то кто-то это делать должен и такая возможность должна быть. Проценты гиков из числа пользоватетей все-таки лучше чем один maintainer. Это опять таки улучшает стабильность репозитория в целом - Опять же возможность собрать порт с нужными опциями. Все-таки и качать меньше и собирать быстрее, и потенциальных дыр меньше - Обновление пакетов происходит быстро. Если maintainer спит или умер, патч к порту может отправить кто угодно (разве что maintainer timeout все равно 2 недели-месяц). Не знаю, распространяются ли с бинарными пакетами скрипты для их сборки, но тут с этим проблем нет. - Ни в одном репозитории все-таки нет всего. Значит что-то может понадобиться собирать руками. Это на порядок проще в системе, где все уже собрано их исходников. Значит есть компилятор, toolchain, и библиотеки, с которыми скорее всего проблем нет. Есть все include, т.е. не надо ставить кучу devel пакетов. - API ломают все-таки гораздо реже, чем ABI. Поэтому ситуация, что для пакета `нужна libfoobar именно версии 1.44.17.98' крайне редка. - С исходниками есть возможность иметь один репозиторий для кучи дистрибутивов (и даже ОС). Пока ближе всего к этому pkgsrc, хотя до нативных PM эму очень далеко.

В общем ключевая мысль такая - используем все-таки opensource софт, значит в корне любых PM должны лежать исходники. А пакеты собрать на кластере - не проблема. Зато лишняя проверка совместимости и целостности.

Ну вот млин, user line breaks как обычно забыл.

Не знаю что у вас за проблемы были с Gentoo, но я, суда по 5летнему опыту общения с портами FreeBSD могу сказать что таки подход портов/portage/pkgsrc/и т.д. наиболее универсален.

Gentoo использовал довольно мало, но ни под ней, ни под FreeBSD проблем не было (за исплюченим случаев, описанных в UPDATING, где нужно набрать пару комманд руками). Сейчас /root/bin/up делает portsnap fetch update && portupgrade -a. Этим обновляется десктоп и 2 сервера и проблем я не припомню (вот года 3 назад иногда что-то ломалось, да).

- Для простого пользователя проблем как раз никаких нету. make search key= и make install. Люди, которым я первый раз показывал как работать с FreeBSD это понимают сразу и в дальнейшем проблем не имеют. (В portage я, признаться, сам до конца не въехал - как там, например, отключить нафиг маскирование пакетов и как посмотреть список файлов для установленного пакета?) Вобщем, думается, любое GUI к портам будет 1:1 synaptic.
- На современных процессорах софт собирается минуты, так что сборка является проблемой только при свежей установке системы

Это были т.н. минусы. А плюсы:

- Паранойя может отдыхать, ибо все в исходниках. Даже если есть шанс, что у автора в tarball попадет бяка, всегда можно залезть и посмотреть, ибо для исходников есть diff, в отличие от
- Меня лично радует возможность положить свой патчик в порт если надо, а также пересобрать падающее приложение с WITH_DEBUG и натравить на него gdb. Это все-таки к тому, что если юзеры не будут собирать и отлаживать софт сами, то кто-то это делать должен и такая возможность должна быть. Проценты гиков из числа пользоватетей все-таки лучше чем один maintainer. Это опять таки улучшает стабильность репозитория в целом
- Опять же возможность собрать порт с нужными опциями. Все-таки и качать меньше и собирать быстрее, и потенциальных дыр меньше
- Обновление пакетов происходит быстро. Если maintainer спит или умер, патч к порту может отправить кто угодно (разве что maintainer timeout все равно 2 недели-месяц). Не знаю, распространяются ли с бинарными пакетами скрипты для их сборки, но тут с этим проблем нет.
- Ни в одном репозитории все-таки нет всего. Значит что-то может понадобиться собирать руками. Это на порядок проще в системе, где все уже собрано их исходников. Значит есть компилятор, toolchain, и библиотеки, с которыми скорее всего проблем нет. Есть все include, т.е. не надо ставить кучу devel пакетов.
- API ломают все-таки гораздо реже, чем ABI. Поэтому ситуация, что для пакета `нужна libfoobar именно версии 1.44.17.98' крайне редка.
- С исходниками есть возможность иметь один репозиторий для кучи дистрибутивов (и даже ОС). Пока ближе всего к этому pkgsrc, хотя до нативных PM эму очень далеко.

В общем ключевая мысль такая - используем все-таки opensource софт, значит в корне любых PM должны лежать исходники. А пакеты собрать на кластере - не проблема. Зато лишняя проверка совместимости и целостности.

а у гентушников такой проблемы нет, скопировал ебилд с новым именем, сделал digest, а потом просто emerge btanks. А виндузятники пусть ждут пока под их дистр сделают пакеты

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

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

Но ведь должно же быть решение? Например, автоудовлетворение зависимостей компонентами из репозитария при установке конкретного пакета, чего не умеет ни dpkg ни rpm.

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

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

> Еще одна беда, это куча платформ под которые надо собирать пакеты. Венда-то работает только с x86, а линукс извините меня... :)

Сорсы никто не отменяет. Хочется KDE на ARM - вперед извращаться. Единый репо как в дебе не исключает возможности держать в нем пакеты для разных архитектур.

>Ubuntu 7.10, ATI x1900, Catalyst 7.11.

>Сенкс разработчикам за игру и с наступающим Новым годом!

дай рецепт, а? что ему по записимостям ещё поставить?

> Но ведь должно же быть решение? Например, автоудовлетворение зависимостей компонентами из репозитария при установке конкретного пакета, чего не умеет ни dpkg ни rpm.

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

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

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

> Сорсы никто не отменяет. Хочется KDE на ARM - вперед извращаться. Единый репо как в дебе не исключает возможности держать в нем пакеты для разных архитектур.

Ну, в общем да, а если смотреть со стороны сборки пакетов, то валяются все они в репозитории себе и ладно, если не поддерживает такую архитектуру дистрибутив, то и не нужны они ему. Вот только вопрос, тогда на кой фиг вообще нужны будут разные дистрибутивы, и чем они отличаться будут? =)

>>Ubuntu 7.10, ATI x1900, Catalyst 7.11.

>>Сенкс разработчикам за игру и с наступающим Новым годом!

>дай рецепт, а? что ему по записимостям ещё поставить?

Все что в ридми + lua (девелоперские пакеты естественно, если у тебя в дистре они отделены от основных)

> дай рецепт, а? что ему по записимостям ещё поставить?

ставил scons + то что шло в файле реадми + lua.

на какую библиотеку у тебя ругается при отработке сконса?

> а у гентушников такой проблемы нет, скопировал ебилд с новым именем, сделал digest, а потом просто emerge btanks. А виндузятники пусть ждут пока под их дистр сделают пакеты

У виндузятников как раз проблем нет потому, что для них всегда есть пакет. Поэтому для того, чтобы поиграть им необязательно читать хауту оверлей, создавать оверлей, качать туда ибилд, делать digest, emerge, ждать от пяти минут до пары суток пока соберется, порой решать проблемы со сборкой и пытаться собрать снова, а затем запускать revdep-rebuild и etc-update чтобы ничто не отвалилось. Если бы виндузятникам рассказали что им предстоит пройти, чтобы поиграть на десктопе в танчики(сборку из стейдж 1 или 3, конфигурирование и сборку ядра, прикручивание драйверов, ручное конфигурирование иксов и пр.) они бы, скорее всего посчитали, что все линуксоиды ударенные на голову красноглазики. У убунтеров, кстати, танчики есть, ставятся в два клика: http://www.getdeb.net/app.php?name=Battle+Tanks. И не надо рассказывать сказки, что в генте все есть. Например, GOSA нету, поддержки LSB нет вообще. А для того, чтобы получить отладочные символы QT приходится ждать ~6 часов пока пересоберется фреймворк пересоберется и так при каждом обновлении вместо одной команды apt-get install qt-x11-free-dbg, которая отрабатывает за минуту. :)

капча breved :D

Ну да, только ты забыл сказать что там целых 34 игрушки, и всего пакетов просто огромное количество - аж 123.

http://www.getdeb.net/browse.php

> Они и не должны, они работают с пакетами а не с репозиториями.

Как это не нужны? Есть .deb-пакет не из репозитария. У него - ряд зависимостей, которые есть в репозитарии. Если бы dpkg или rpm были умнее или apt/yum умели ставить пакет не из репозитария, то пакетный менеджер бы автоматически подсосал все зависимости, а не трахал бы юзеру мозги требуя от него вручную доустановить десяток пакетов-зависимостей.

> Я говорил про центральный репозиторий для всех дистрибутивов, т.е. мантейнер будет делать работу один раз для всех дистрибутивов. Это было бы идеально, но к сожалению, мне кажется пока это нереально.

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

> Вот только вопрос, тогда на кой фиг вообще нужны будут разные дистрибутивы, и чем они отличаться будут? =)

Честно говоря, не знаю кому и сейчас-то нужны тысячи недоделанных дистрибутивов с парой мантейнеров. Разработчики как-то не особо спешат поддерживать ньюансы, форматы пакетов и глюки каждого, а юзеры как-то не все шибко радуются ручному разруливанию зависимостей и дедовскому configure&&make когда пакета или ибилда в репозитарии/порте нет.

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

Вообще, удивительно, что так много игрушек. Остальное в официальных портах. :) Жалкие 15 тысяч приложений в портах это тоже очень мало. Сравнительно мало.

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

Не удивительно что оно падает. Похоже, в коде огромное количество рэйсов и то, что оно вообще работает - нонсенс. Отладить это будет очень сложно :/

>>добавили быдло-скриптинг на луа

пол столом!!!! хыхыхыхыхы..

anonymous_incognito в президенты, whoozle в премьер-министры!!

>ждём ебилдов - у меня сын от этой игры тащится, перестал просить винду :)

Так игруха эта и под винду есть, так что стоит ему токо узнать :))))

А правда, как обратно в танк залезть?

как моргал под виндой, так и моргает.

> А правда, как обратно в танк залезть?

тупо идти в танк

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

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

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

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

Может пора уже с травой завязывать? Покажите мне arcomage под что либо кроме 9x? Он в очень редких случаях после больших плясок с бубном запускается на XP, в подавляющем большинстве же случаев винда нам рассказывает что это не win32 приложение. После чего можете показать crysis на win98. Что тоже нет? Ну тогда хотя бы на winxp с directx10. Что десятого directx нет для XP, которая до сих пор является самой распространенной версией windows? Ну и где же тут счастье для пользователя?

А насчет единого репозитария это вообще бред. Попробуйте применить логику и ответить на вопрос "почему их стало больше чем один в начале развития линукса и почему их количество лишь растет".

> вообще под виндузятниками понимались вот те плаксивые пользователи которые в этом топике жалуются что у них что-то не собирается или пакета нетую

А труЪ линуксоиды молча жуют глюки, сжав зубы переносят неудобства, пишут ибилды и компилируют-компилируют-компилируют? А почему редхат или новелл не идут по тмоу же пути и не обеспечивают юзером счастьем компиляции? Эх помню как это было весело обновлять установленные 2000+ пакетов в генте, компилируя более суток, разрулив все взаимно блокирующие зависимости, экспортируя и импортируя обратно ldap, обходя несобирающиеся пакеты, а затем revdep-rebuild и компилирует еще полдня. Засуньте советы собирать все из исходников на фрях и гентах на десктопе и рассказы о простоте знаете куда?

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

Я этого не говорил, так что не надо передергивать. Пользователи виндос избавлены от счастья потрахаться с некомпилирующимися игрушками в отличие от линуксоидов и фряшников. Есть возражения?

О каком будущем настольного Linux можно говорить, если пользователям предлагается поставить и изучить инструменты сборки, вручную скачать все зависимости и собрать ИГРУШКУ из исходников. Спрашивается, нахрена плодить лишние сущности и проблемы юзеру, котоыре хочет просто пользоваться, а не собирать, патчить, дебажить? Вы сами верите в такое будущее, когда простые юзеры ставят фрю или генту из stage1 и работают emerge и cvsup-ом с portupgrade-ом? Пока разработчики будут относится к пользователям UNIX-систем как к гикам, ими и будут пользоваться только технические гики, т.е. ни официальных драйверов ни портов профессионального настольного софта.

Небольшой пример. Провайдер предоставляет подключение к Интернет по технологии Ethernet. Есть некая программа-авторизатор без которой в Интернет не выйти. На удивление есть исходники для UNIX. Пакетов для Linux, естественно нет, потому что даже формат пакетов нестандартизован. Поэтому знакомство с Linux для большинства пользователей заканчивается после безуспешных попыток собрать авторизатор и эти пользователи возвращаются на винду с твердым убеждением, что Linux для красноглазых фанатов, а не для людей.

Вместо того, чтобы пороть чушь "линукс не для ламеров", "вендекапец", "жри исходники что дают и не жалуйся, вендузятник" и пр. я сделал еще один небольшой, но реальный вклад в дело популяризации Linux на десктопе - собрал авторизатор в универсальный deb-пакет. Почему deb? Потому что Debian один из немногих качественных стабильных дистрибутивов, а Ubuntu - популярнейший десктопный свежий Debian. Исправил баги, переписал часть кода, портировал на AMD64. Пакет завязан по зависимостям только на libc, поэтому работает на любом Debian, Ubuntu, Knoppix, вобщем, на любых Debian-based. Пример универсального пакета, который ставится без бубна, без прикручивание оверлеев, digest, компиляций и пр. В один клик. Это удобно! Это дружественно к пользователю, что бы ни говорили красноглазики, считающие что установка даже игрушки должна превратиться в танцы с бубном!

Решил сделать авторизатор еще более дружественным(смотреть баланс в логах не очень удобно). Решил сделать GUI-версию, которая будет висеть в трее и показывать баланс в дополнение к консольному демону. Ну и как сделать аналогичный универсальный пакет, который встанет на любой Debian, K/X/ED/UBUNTU? Как это сделать? QT3 нативно работать с треем не умеет. Только QT4. Заставлять юзера вручную тянуть QT4? Завязываться на KDE? А если у пользователя Gnome или XFCE? Завязываться на GTK и заставлять пользователя тянуть GTK нужной версии? Что должен делать разработчик, чтобы сделать универсальный GUI пакет хотя бы для Debian-бейзед и не мучить юзеров удовлетворением зависимостей вручную(кстати, где гарантии, что в новом дистрибутиве не выкинут старые версии QT/GTK)? В ругаемой винде с понолитным WinAPI и единым GUI есть стандартные средства для работы с графикой, в т.ч с треем. Никаких зависимостей. Я бы мог написать простейший под WinAPI Win95 и он работал бы на любой системе от 95-ой до свисты. А при попытке сделать универсальную программу хотя бы для Debian-based - такие сложности, что проще просто забить на саму задумку... Один разработчик столкнулся и забил, второй забил, третий в итоге имеем то, что имеем - систему для некоторых хакеров, админов и программистов, которые мучаются из-за инорирования разработчиками железа и проф. коммерческого софта с прикручиванием железок, глюкавого вайна, dosemu или vmware с виндой...

Думаю, что если бы разработчики дистров не были сами себе врагами и стандартизовали бы формат пакетов, зависимости, стандартные GUI фреймворки для десктопа, уделяли бы большее внимание совместимости, то освободили бы разработчиков от лишней головной боли. Меньше гимора разработчикам и меньше гимора юзерам => больше разработчиков и юзеров, больше доля Linux на десктопе, лучше поддержка железа.

> Не знаю что у вас за проблемы были с Gentoo, но я, суда по 5летнему опыту общения с портами FreeBSD могу сказать что таки подход портов/portage/pkgsrc/и т.д. наиболее универсален.

Имея 4-летний опыт общения с Gentoo и давний опыт развлечений с фрей меня как-то не улыбает возиться на десктопе с обновлением 2284 пакетов из исходников и сборкой ядра. Наверное, обленился. Хочется жить в комфорте, как белый человек, использовать систему как инструмент, а не самоцель, фетиш, с которым нужно постоянно колупаться. Поэтому и ушел на Debian и настольный Debian Ubuntu.

> Сейчас /root/bin/up делает portsnap fetch update && portupgrade -a. Этим обновляется десктоп и 2 сервера и проблем я не припомню (вот года 3 назад иногда что-то ломалось, да).

У фри проблемы в генах - с поддержкой железа(хуже чем в Linux ) и софта(Skype, Google Earth, Quake, Oracle, eDir и пр.) Я уже молчу, что сборка из исходников ИГРУШЕК на НАСТОЛЬНОМ ПК - какой-то сюрреализм, почти как в том анекдоте про секретаршу монтирующую флоп из консоли.

> В portage я, признаться, сам до конца не въехал - как там, например, отключить нафиг маскирование пакетов

ACCEPT_KEYWORDS=~arch в /etc/make.conf и /etc/portage/package.unmask.

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

Например, epm -ql blah

> На современных процессорах софт собирается минуты, так что сборка является проблемой только при свежей установке системы

На современном процессоре сотня обновляемых пакетов собирается до суток. А затем еще revdep-rebuild...

> - Паранойя может отдыхать, ибо все в исходниках.

Что правда, то правда.

> Даже если есть шанс, что у автора в tarball попадет бяка, всегда можно залезть и посмотреть

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

> Меня лично радует возможность положить свой патчик в порт если надо, а также пересобрать падающее приложение с WITH_DEBUG и натравить на него gdb.

Меня не радует, что пользователь ВЫНУЖДЕН патчить ядро или программу чтобы получить поддержку железки, поддержку конвертора, нормальный шрифт и т.п. Нормального пользователя не радует вместо того, чтобы поиграть в battle tanks, играть в gdb... Если пользователь разработчик, то установить инструменты сборки в виде метапакета build-essential в бинарном дистре и сделать apt-get build-dep и apt-get source не составляет для него труда. Открытый код означает его доступность, а не сумасшествие с обязательной сборкой иксов, ядра и всех программ из сорса.

...

> Проценты гиков из числа пользоватетей все-таки лучше чем один maintainer.

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

> Это опять таки улучшает стабильность репозитория в целом

Мантейнеры репозитариев source-based систем типа Gentoo утопают в багах не связанных с реальными проблемами. У кого-то руки не оттуда, кто-то перетвикал CFLAGS, кто-то чего-то не дособрал, кто-то встал на грабли всплывающие с определенной комбинацией версий инструментов сборки... Векторов глюков гораздо больше, чем в системах, где пакеты уже собраны. Загружаемые плагины гораздо удобнее сборки с USE-флагами, динамическая оптимизация под SIMD там, где это действительно надо опять же удобнее плясок с CFLAGS и заточкой под конкретный тип процессора, модули ядра удобнее статически собранного заточенного под конкретное железо ядра, которое позорно упадет в панику при смене материнки прямо как винда. Поэтому никаких весомых преимуществ для пользователя, кроме узкоспециализированных случаев где требуется экономить каждый килобайт и такт процессора по сравнению с модульным подходом бинарных программ с динамической оптимизацией у сборки из исходников нет.

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

Ну виндузятникам-то не приходится? И они не страдают от того, что им не приходисят собирать программы. Чем мы хуже?

> В общем ключевая мысль такая - используем все-таки opensource софт, значит в корне любых PM должны лежать исходники.

Они и лежат в корне, но это не означает, что пользователя нужно ПРИНУЖДАТЬ компилировать открытые программы. Для пользователя это лишняя сущность

> А пакеты собрать на кластере - не проблема.

Не у всякого пользователя есть персональный кластер.

> Зато лишняя проверка совместимости и целостности.

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

>Есть .deb-пакет не из репозитария. У него - ряд зависимостей, которые есть в репозитарии. Если бы dpkg или rpm были умнее или apt/yum умели
ставить пакет не из репозитария, то пакетный менеджер бы автоматически подсосал все зависимости, а не трахал бы юзеру мозги требуя от него вручную
доустановить десяток пакетов-зависимостей.

$ dpkg -i package_not_from_repository.deb
$ apt-get -f install