Linux x64 - ставить ли?

> И что потеряю? Flash слышал не работает, openoffice вроде тоже, что еще?..

flash работает, правда с 32 битными браузерами :) OO2 есть в 64битной убунте точно

вообще спроси лучше Шамана, у него уже есть опыт наступания на 64битные грабли :)

Про флеш и 64x http://www.opennet.ru/opennews/art.shtml?num=7856

Flash у меня работает и с Firefox, и с Opera, и с Konqueror (Suse 10.1), с OpenOffice тоже все в ажуре. Ей-богу, не знаю, что теряется, вроде бы все ок. А из приобретений - пожалуйста, Математика 5.2 считает в 64битном режиме подчас процентов на 50 быстрее, чем в 32битном:)

бывают траблы с установкой/компиляции софта, особенно если часть из них в lib а часть в lib64, или два варианта либов сразу 32 и 64.

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

Стоит... ну что сказать... ощущаешь себя несколько меж ягодичных мышц.... Выгода? Ну... оптимизация под архитектуру по идее... Минусы? хм... с чего бы начать... Ну, в общем, основное скажу с чем сталкиваюсь - во всех причем дистрибах х64 - ни одного исходника нормально не скомпилишь - пол библиотек сидишь ищешь, а потом в ручную линкуешь... Жить можно, в принципе, но порой напрягает их такая тяжкая совместимость с х32. Сим скомпилил вроде... запускается и после того как пытаешься залогиниться в icq - валится нахрен... Разбираться пока некогда. Ну, вот в целом мои соображения о выгоде х64 дистрибутов...

Хотя касательно упомянутых приложений - все нормально...

Более года по x86_64 - еще ни разу не пожалел, что пересел. Да, флеша нету - ну и нах его фтопку! Остальное фурычит, даже проги многие уже осилили кофиг для amd64.

Ну, а почему нет.. Даже если какого ПО и нет в 64-разрядном исполнении, оно прекрасно будет работать и в 32-разрядном..

Полгода примерно на Arch64. Все ништяк. Даже вон Unreal 2003/2004 и HMM3 работают...

Если не хочется костылей - придется выкинуть wine и использовать gnash...

Если Убунта запускать надо через chroot 32 битные проги ( mplayer, firefox, wine etc ). Если Suse, FC, - то там не полностью 64 битные системы а "смесь" библиотек ( 32 и 64 битных ) - все запускается из "к оробки" - но честно говоря оно и нафиг ненужно. Убунтовцы говорят что amd64 это для Opertonов и Xeonов - для остального 32 бита - так что стоит прислушаться к их совету .... Так что если у тебя памяти юзается меньше 4 гигов - то оно просто не нужно ....

>flash работает, правда с 32 битными браузерами :)

С 64-х битными тоже. nspluginwrapper для родного флеша, или gnash. На выбор :)

...

В принципе, полтора года на gentoo на amd64 - полёт нормальный. Памяти только софт жрёт больше :)

>бывают траблы с установкой/компиляции софта, особенно если часть из них в lib а часть в lib64

В gentoo /lib и /lib64 - синонимы. lib64 - симлинк на lib

>Ну, в общем, основное скажу с чем сталкиваюсь - во всех причем дистрибах х64 - ни одного исходника нормально не скомпилишь

Блин, это уже какая-то реклама Gentoo выходит, но тут ВЕСЬ софт компилится из 64-х битных исходников. И весь компилится нормально :)

>Да, флеша нету - ну и нах его фтопку! 

Да есть, есть он! Сколько можно повторяться! Даже поиск на ЛОРе уже
десятки топиков со ссылками на nspluginwrapper должен выдавать :)

# esearch nspluginwrapper
[ Results for search key : nspluginwrapper ]
[ Applications found : 2 ]
*  net-www/nspluginwrapper [ Masked ]
      Latest version available: 0.9.90
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 125 kB
      Homepage:    http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper
      Description: Netscape Plugin Wrapper - Load 32bit plugins on 64bit browser
      License:     Other

*  www-client/nspluginwrapper
      Latest version available: 0.9.90
      Latest version installed: 0.9.90
      Size of downloaded files: 71 kB
      Homepage:    http://www.gibix.net/dokuwiki/en:projects:nspluginwrapper
      Description: Netscape Plugin Wrapper 32bit plugins on 64bit browser
      License:     Other

> Блин, это уже какая-то реклама Gentoo выходит, но тут ВЕСЬ софт компилится из 64-х битных исходников. И весь компилится нормально :)

даже wine?

> из 64-х битных исходников

?? :-)

У меня на 64хбитной убунте не захотел работать атишный драйвер (как из репозитория, так и с офсайта). То есть формально-то он работал, только иксы стартовали через раз и при запуске GLных вещей все валилось или повисало намертво. Есть проблемы с коммерческими приложениями и дровами. Приложения можно конечно запускать в chroot'e, но мне как-то такие костыли не по вкусу. Как обстоят дела с нвидийными дровами, не знаю.
Но думаю, что костыли обеспечены, если ставишь x86_64 :(

В общем: все работает, но то, что жестко завязано на 32 бита (wine, win32codecs, flash (но с флешом какой-то враппер смонстрячили)) пускается довольно геморройно. + по 2 экземпляра основных библиотек.

Так а что там с кодеками-то получается?

А ничего - либо ставь полностью 32битный mplayer, или не используй Темную Сторону Силы. По скорости кроме спецзадач выигрыша нет, браузер и плееры приходится тянуть 32 разрядными. Если нужен wine - получаем некоторый гемор. А как сервер - все пучком.

Вообще, это кодеки не особенно-то и нужны (да и зачем разводить проприетарщину). FFmpeg, ЕМНИС, только с WMV9 не справляется, ну и фиг бы с ним.

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

Всякие вычисления в расчет не берем, это не нужно.

> > из 64-х битных исходников

> ?? :-)

Вставим пару слов по теме...

0. Ядро держит трансляцию системных вызовов нормально => иметь полностью нативное 32-битное окружение и 64-битное ядро - вполне реально (за исключением некоторых специфичных системных утилит).

1. 64-битный опенофис получить просто так не выйдет, во всех дистрах - 32-битная версия, зависимая от 32-битных либок (разве что в Генту асилили, но не уверен) => получаем всю эту дублирующую байду в довесок по требованиям к памяти. Возможный выход - засунуть 32-битное окружение для сборки в chroot и собирать статически, но от пожирания памяти тем офис не избавить.

2. Косяки есть с дровами от ATI, любым имеющим ассемблерные вставки для простого х86 и не имеющим возможности сборки без них софтом - grub, rte, ffmpeg (до какого-то периода, если -svn - то нормально), с WINE, ну и вроде все из собираемого у меня. KDE+KOffice собираются нативно и корректно, вообще проблем нет - если юзать их, все пучком.

3. Нативная java-1.4.2 существует только в версии blackdown, каким-то шаманством полученная из сорцов от SUN + патчи, но оных патчей нигде почему-то не найти => остается либо юзать бинари, либо собрать самому нативную 64-битную 1.5.0 из соответствующих сорцов.

Запарила проблема с кучей либок под разные платфомы (m32/m64 => lib/lib64), посему у себя я вырубил поддержку multi-lib патчиками еще в сорцах gcc/glibc/binutils, и получил дерево директорий полностью одинакового с m32 вида - только "lib", никакой запарки с несколькими ld.so и параметрами ld, полностью нативная 64-битная система.

Вообще - никак пока не собирается только OpenOffice, это единственный оставшийся косяк...

Фичи - на амд64 больше регистров кучи видов, но в силу большей разрядности операндов и постоянного размера кэша - хз, будет ли выигрыш. По идее должна вырасти скорость работы с файлами большого размера на 64-битных ФС (читай - xfs рулит) и вообще файлами.

В реальном мире - ставил "на посмотреть" SUSE 10.1 OSS, вроде как "х86_64": ситуация - чистый "ужоснах", по-моему 64-битное там только ядро, память жрет - упаси аллах, тормозит по сравнению с самосборной системой - не то что заметно, даже секундомер не нужен - в разы даже при отключенных ненужных сервисах и прочих оптимизирующих шаманствах... Еще бы кто объяснил, зачем нужны опциональные TLS-версии либок, если на amd64 оное не включается "бай дефолт" разве что по скудоумию...

С win32-кодеками - полная жопа :)

Но не забываем о сладкой парочке XINE+MPlayer, они играют много-много чего, даже сами по себе, без всяких костылей... *приняв позу мудреца и стараясь не заржать, изрекаю* : Озаботившись сией проблемой, я умудрился найти в домонете только какие-то wmv, судя по виду, расположению и названию - явно порнографического характера и слитые с соотвествующих серваков, с какой-то противоестественной защитой и левого формата, играться отказались...

"И ты, Брут!" (с) :(

x64 - маркетинговое ms-название. Нет x64-архитектуры, есть x86_64 и опять же маркетинговое название Intel - EM64T, которые практически одинаковы между собой.

>во всех причем дистрибах х64 - ни одного исходника нормально не скомпилишь - пол библиотек сидишь ищешь, а потом в ручную линкуешь...

Что-то ты какие-то страшные вещи рассказываешь. Ни разу с таким не сталкивался в мандриве 2006 под x86_64

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

Если софт не очень активно использует long вместо int, то проигрыш по памяти - в пределах 10% максимум (таблицы экспорта, указатели, etc), иначе - треть максимум (опытным путем на примере КДЕ+Кофис+Гимп с доками-картинками и т.п.), ну а заявы типа "win64 треба рамы в 2 раза шире, так как битиков в 2 раза больше" - действительны только в виндах.

Маркетинг маркетингом, но требования Свисты - отнюдь не идеальная абстракция, а будущая суровая реальность :) Не с потолка же они взяты... такое ощущение, что у MS-программеров и (sizeof(byte)==8) является отныне непреложной истиной...

Надо было просто написать 64бита :)

Главное поняли..)

Что и wine и zsnes?

Стоит, flash и openoffice не особо ведь нужны ;-) Тем более здесь про них уже сказали, что они есть под эмуляцией 32-бит ;-)

Распаковщика обязьянки нет, после сборки ручками - segfault, пришлось явовскую версию использовать, она, конечно, медленней, но лучше, чем ничего.

Ещё потерял бинарные кодеки мплайера, из которых в основном wmv3 требуется.

> flash и openoffice не особо ведь нужны

Иногда лучше жевать.

> Что и wine и zsnes?

Оба хорошо работают из-под 32bit chroot (хотя, кто бы сомневался).

>В gentoo /lib и /lib64 - синонимы. lib64 - симлинк на lib

Ну это ж супер-мега в Генту. А в "Обычном порошке" :) типа мандрива (думаю что и федора) - разные диры :)

>даже wine?

0.9.12 стоит. 0.9.16 не собирается, но, кажется, из-за того, что я чего-то с SDL-либами нахимичил. Руки не доходят разобраться, а на автомате - revdep-rebuild не работает (заводил как-то тему тут :)).

>64-битный опенофис получить просто так не выйдет, во всех дистрах - 32-битная версия, зависимая от 32-битных либок (разве что в Генту асилили, но не уверен)

Какой-то из пререлизов OOo2.0.0 под 64-мя битами собирался без напильника. 2.0.0 - не помню. Уже 2.0.1 не собирался, где-то с Java 1.5 (у меня dual-java (1.4+1.5) и он этого, кажется, не переваривал) нестыковка. Так что с 2.0.1 я на openoffice-bin. Этот работает нормально, хотя интерфейс неидеален (шрифты неровные). Впрочем, 2.0.3 сейчас, вот, у меня и на x86 машине не собирается... Та же Java...

Яву я собрал в пятницу, потом глянул на WS издалека, подумал "как жеж ты достала", почле чего не включал и до выходных вклчюать не буду :)

А все с чего - Опенофис 2.0.2 собирался долго и корректно, чему способствовали патчи вовремя скармливаемые сборке из пакета ooo-build, который с go-oo.org (в этом - ключ ;) ), но почему-то в один прекрасный момент кончился из-за явового глюка... Посему я заменил java с 1.4.2-03-blackdown... на нативный sun-jdk-1.5.0-07, на котором вылез такой же глюк.

Поскольку системным компайлером выступал gcc-4.1.1, и скомпилить саму Яву им - анриал, то откатился на тестовой машинке до gcc-3.4.6, пересобрал Яву и может быть на неделе посмотрю, воспроизводим ли тот глюк с разными Явами... ибо gcc-3.2.2 (SUSE), коим собирается Java - а ну его... к и во славу Ануннаха...

Два ядра и raid 1 мне в помощь, млин :)

А на простой 32-битной х86 - OOo собирается как часы еще с версий 1.1.х, а потом и 2.0.0, там вообще проблем нет. Компайлеры - gcc веток 3.3.х, 3.4.х, 4.0.х, 4.1.х.

>А на простой 32-битной х86 - OOo собирается как часы

Вот у меня сейчас не собирается :) Так что не всё так просто... У тебя Java какая?

>OOo собирается как часы

собрать часы между прочим это довольно нетривиальная задача :)

>собрать часы между прочим это довольно нетривиальная задача :)

браво! :)

FC4 x86_64. Всё кроме flash работает, включая кодеки, wine, dosemu, dosbox, cedega, OOo, unreal, quake2, quake3 (версия 1.33 для 64-bit), quake4, doom3, кучи виндовых игрушек и composite прозрачность в xorg-6.8 с RenderAccel и дровами от nVidia. Flash в x86_64 сборках firefox не работает, потому что влом ставить всякие приблуды для mozilla и totem с rpm.livna.org :) Увеличения потребления памяти особо не заметил, хотя у меня 1.5 Gb RAM :) Единственное, чего до недавнего времени не хватало в x86_64 - это xen. Сейчас всё тип-топ.

P.S: При composite правда игрушки не работают, по этому приходится выбирать между прозрачными окнами и гамесами.

P.P.S: OOo - i386

+1. На первых шагах поимел гемор с кде, ибо сам с юзами нашустрил. Больше проблем не видел. Слава Gentoo!!!

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

> При composite правда игрушки не работают

RTFM. Option "AllowGLXWithComposite" "on"

> quake3 (версия 1.33 для 64-bit)

Оооо... Может поделишься, как собирал? Откуда исходники, какие грабли? А то собрать хочу, да пугаюсь :)

> Вот у меня сейчас не собирается :) Так что не всё так просто... У тебя Java какая?

Тестилась Java 1.4.2 от Санок, пачки саб-релизов (от 04 до 10, кажется) - все надежно и стабильно собирается. С Java 1.5.0 (от 01 до 07) - нужны патчи для корректной сборки. Причем набор патчей особо не меняется аж с 2.0.0, ну и при переходе на компайлеры 4.х ветки добавляется несколько тривиальных. Вместо помершей Мозиллы еще юзается нативный системный Файрфокс, ну и остальное - по максимуму из имеющегося (т.е. все зависимости, кроме КДЕ).

Говорю ж - ничто не мешает скинуть на мыло сборочные скрипты и патчсет для 2.0.2 (2.0.1, 2.0.0), если требуется...