необходимость в 64 на 2013

очень дорого. программно апаратный комплекс.

вотчдог который апаратно сообщает системе об ошибки памяти при привышении «90% использовании планки» и система которая перезапускает наблюдаемое приложение ")

не пробовал, везде грязный мёд. а по сути мне гарантия нужна.

прости, но ты странный человек. Разве я это впервые объясняю?

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

Но откуда у тебя опыт аварий, если у тебя «всё работает»?

Да всё очень просто. Было время я не мог по определённым причинам работать в Linux иначе как в виртуалке. Причём памяти было очень мало, а виртуалок иногда две. Поэтому приходилось урезать им память иногда даже до 256 Мб. Это я про KDE 3 и 4. Ну и стало интересно при каком минимальном объёме это всё сможет работать и сможет ли без свопа. Результат - KDE 4 с 256 Мб работать может, отсутствие свопа при большом объёме оперативной памяти как правило не летально.

Ты это говоришь гентушнику?:-)

Ну кроме твоей не компетенции.

ИЧСХ, ни одной ссылки я так и не увидел, только твой бесценный опыт и умозаключения.

Заметь, 32 битного говнеца в твоем фетише в 12 раз больше чем 64 битного.

Что, подсчитал объем папок System32 и SysWoW64?
Ай, молодца. Только вот ты не учел, что в System32 лежат 64-битные бинарники. А в SysWoW64 - наоборот, 32-битные.
Так что соотношение между 32-х и 64-х разрядным кодом получается прямо противоположное.
Так сделано потому, что system32 захардкожена во многих программах, а цель у M$ - чтобы 32-битный исходник можно было откомпилировать под 64 бита вообще без изменений.

И что ты этим хотел сказать, чушок? Ты в курсе, когда винда перестала выполнять 16-бит приложения, или сам найдёшь?

а разве показатель «занятая память» что-то говорит о чём-то?

Он говорит о том, сколько достанется кешу и буферам. И, соответственно, насколько отзывчивой и плавной будет система.

бред. От битности это никак не зависит.

Зависит. 64-битные браузеры жрут почти вдвое больше оперативки, чем 32-х битные.

Если ей мало памяти, надо память покупать, а не битность понижать.

Ога. Знакомый аргумент :D

Ты это говоришь гентушнику?:-)

Даже гентушник должен понимать, что означает новая архитектура (x32 - это именно новая архитектура).

ты бы запустил «нонешнии» среды без свопа - теперь чаще ту или иную ошибку выдаст и закончится исполнение приложение - если что и рушится то тока приблуда ибо сама ос уже с буферами сидит .

при чём тут «сама ос»? иксы — точно такая же программа, как и все остальные. Просто нынешние среды достаточно умны для того, что-бы понимать то, что я выше излагал. Потому сами проверяют, можно-ли _сейчас_ выделить память. Проблема в том, что _сейчас_ может и можно, а через час ты ещё что-то запустишь, памяти станет меньше, но среда об этом не узнает. И всё будет так, как я писал выше.

очень дорого. программно апаратный комплекс.

дык я и говорю, 512Мб дискового пространства на несколько порядков дешевле. Даже если речь о маленьком единственном SSD.

а по сути мне гарантия нужна.

100% гарантии даёт только морг. Думай...

в Linux иначе как в виртуалке.

в данном случае работа виртуальной памяти кардинально отличается. Не пруф.

Результат - KDE 4 с 256 Мб работать может, отсутствие свопа при большом объёме оперативной памяти как правило не летально.

а на реальном железе — 50%. То иксы рухнут, то редактор с важным и нужным текстом.

Впрочем, определять степень «летальности» конечно только тебе. Просто другим не нужно советовать.

ИЧСХ, ни одной ссылки я так и не увидел, только твой бесценный опыт и умозаключения.

Зачем мне ссылки, если я и сам разбираюсь в происходящем? Может мне ещё и пруф привести того, что снег белый, а вода мокрая?

Так что соотношение между 32-х и 64-х разрядным кодом

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

Чем огорчают? Своим фактом наличия?

Ну меня например в генте огорчают тем что обновляются раз в год. Это я про месу. Когда в основной х86_64 системе уже пол года как меса 9.2, в emul-linux-* меса все еще 9.1 и когда появится 9.2 неизвестно. Собирать мультилиб пробовал, глючит пока что сильно с зависимостями.

а разве показатель «занятая память» что-то говорит о чём-то?

Он говорит о том, сколько достанется кешу и буферам. И, соответственно, насколько отзывчивой и плавной будет система.

с чего ты взял, что FireFox на 1Гб будет жрать столько же, сколько и на 8Гб? Смотри:

27766 14.6 21.3 598128 216396 ? Ssl 15:05 6:32 firefox

всего 216К. Уверен, у тебя цифра намного больше. А разгадка проста: здесь 1015Мб всего.

Зависит. 64-битные браузеры жрут почти вдвое больше оперативки, чем 32-х битные.

это если есть что жрать, т.е. есть 4+ гигов. А если их нет, то и разницы почти нет. Я проверял на 1500Мб.

Если ей мало памяти, надо память покупать, а не битность понижать.

Ога. Знакомый аргумент :D

ну попробуй битность понижать, это всё равно не помогает.

Зачем мне ссылки, если я и сам разбираюсь в происходящем? Может мне ещё и пруф привести того, что снег белый, а вода мокрая?

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

шел 2013 год. Дистрибутивы гну/линукс все еще осиливали поддержку запуска 32битного по в 64 битной ос.

Да, я читал/слышал про лучшее распределение памяти на 64, но в обще как-то это ощутить можно, при, скажем, 8Гб ОЗУ

Разницы никакой нет, что б ни писали аналитики. Ядро х86+PAE или ядро x64 - один хрен, все 8Гб памяти используются. Я не думаю, что у тебя будут приложения, которым будет надо > 2-4Гб на процесс.

Только вот хлама в система больше, всё равно в х64 систему понаставишь х32 приложение и либ.

Ты про обозначение? Так написано в menuconfig ядра. То, что это неправильно, а правильно - x86 и x86_64 можешь сказать не мне, а тем, кто составлял menuconfig:-)

Нет. Я про то, что x32 - это новая архитектура, со всеми атрибутами новой архитектуры.

Проблема в том, что _сейчас_ может и можно, а через час ты ещё что-то запустишь, памяти станет меньше, но среда об этом не узнает.

moar

А, даже так. Ну тем не менее, в Gentoo это не проблема, главное чтобы флаг был)

с чего ты взял, что FireFox на 1Гб будет жрать столько же, сколько и на 8Гб?

Я просто вижу, сколько тот же Firefox жрёт на 4Гб в 32-х и 64-х битном виде. Или Опера. Или Хром :)

Я проверял на 1500Мб.

У меня как раз есть две машины с 4Гб. На одной Ubuntu 64 bit, на другой — 32 bit PAE. Так что могу в равных условиях сравнивать.

Ещё несколько лет назад было две аналгичных Gentoo с 3Гб. Итог примерно такой же был. Где на 32бит Фокс занимает ~350..400Мб, на 64-х он жрёт уже 700+Мб. Я ещё в те времена писал об этом.

Я так понимаю, объяснение банальное — основные массивы имеют разрядность int.

Ты свой комментарий причитай, причем тут 16 бит?

Про венду ходили байки, что свап ей нужен даже если полно оперативки.

Вообще-то 64-битные дублёры лежат в SysWoW64. С какого перепуга в 64-битных приложениях должен быть захардкоден system32 и как ты собрался держать в одном каталоге 2 файла с одним названием?

Дык я тебя и спрашиваю, к чему ты вывалил свои листинги? Показать, что в 64бит системе куча хлама для поддержки 32бит софта? Так вот 32бит Вин8 ДО СИХ ПОР несёт в себе костыли для поддержки 16бит софта. Ты думаешь с поддержкой 32бит софта в 64бит винде будет как-то по-другому?

ЗЫ: Про то, что мне показали, что 8 винда есть и в 32бит версии, я отписался ещё на первой странице. Ну а сколько лет прошло между переходом на 32бит и выходом на домашний десктоп полностью 32битной винды незаставшие могут почитать в интернетах.

Вообще-то 64-битные дублёры лежат в SysWoW64

Английским владеешь? http://en.wikipedia.org/wiki/WoW64

Оно как-то плохо поддерживается?

Да. На Debian amd64 как-то непонятно ставится Skype. Даже если включить мультиарч. И что бы фанатики не пищали, мне скайп нужен.

Вообще-то 64-битные дублёры лежат в SysWoW64

64-битные бинарники лежат в Sytem32. А в SysWoW64 - наоборот, 32-битные. Название SysWoW64 говорит само за себя: «Windows on Windows64». Т.е. это эмуляция Windows (32-разрядной) поверх Win64. Потому там и лежат 32-битные бинарники.

С какого перепуга в 64-битных приложениях должен быть захардкоден system32

System32 захардкожен во многих 32-битных приложениях. Если такие приложения понадобится перенести на 64 бита, то это можно сделать простой перекомпиляцией исходников, _вообще_ без изменений.

и как ты собрался держать в одном каталоге 2 файла с одним названием?

Почитай, что-ли, про File System Virtualization.
Когда 32-битное приложение открывает файл в system32, его перенаправляют на такой же файл в SysWoW64. Для 64-битных приложений это не действует, ибо в System32 и так лежат 64-битные бинарники.

№2 и №3 опционально. Обоснуй.

От обоснуя слышу)
Даже не знаю, что сказать, на самом деле. Это как объяснять, зачем переходить дорогу по «зебре»

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

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

Ты, впрочем, можешь набивать и свои шишки, я разрешаю.

шел 2013 год. Дистрибутивы гну/линукс все еще осиливали поддержку запуска 32битного по в 64 битной ос.

ну есть гну/линуксы, которые ещё и писать не начали, например легендарный болженос на HTML с русскими комментариями.

Только вот хлама в система больше, всё равно в х64 систему понаставишь х32 приложение и либ.

4.2

я не поставил. УМВР, ЧЯДНТ?

Откуда я знаю, может тебе Linux нужен только установить/гордиться фактом. А мне вот как минимум Skype нужен. И тут начинаетс 250 мегабайт x86 библиотек и хреновая работа с 64хбитным pulseaudio)

с чего ты взял, что FireFox на 1Гб будет жрать столько же, сколько и на 8Гб?

Я просто вижу, сколько тот же Firefox жрёт на 4Гб в 32-х и 64-х битном виде. Или Опера. Или Хром :)

а я вижу, сколько он жрёт на 64 и на 32 с 1.5Гб. Кто из нас более информирован в работе при дефиците RAM?

Я так понимаю, объяснение банальное — основные массивы имеют разрядность int.

ВНЕЗАПНО: int имеет размер 32 бита в x86_64.

Если не веришь, возьми gcc, и распечатай sizeof(int), вот:

#include <stdio.h>
/* для компиляции набери gcc -Wall test.c && ./a.out 
*/
int main()
{
  printf("%d\n", sizeof(int));
  return 0;
}

Про венду ходили байки, что свап ей нужен даже если полно оперативки.

да, было дело в начале нулевых. А мой друг мне говорил тут по пьяне, что в его восьмёрке всё нормально. Хотя может и врёт.

Даже не знаю, что сказать, на самом деле. Это как объяснять, зачем переходить дорогу по «зебре»

аналогия мимо кассы. По зебре переходить — сплошные профиты. А вот насчёт 32х бит ты не прав — да, с одной стороны конечно на указатели надо памяти много больше, это факт. Но есть и другая сторона: у аллокатора больше свободы. У него ВСЕГДА есть непрерывный кусок любого размера. Включи голову, какова вероятность того, что у тебя найдётся _непрерывный_ кусок размером 512Мб, если памяти(виртуальной) 4096Мб? Эта вероятность строго равна нулю, ибо память через час работы похожа на шахматную доску(такая же дырявая, аки швейцарский сыр). Приходится аллокатору заморачиватся со сборкой мусора, расчищая завалы. Ну а если у тебя 4 294 967 296Гб памяти, то ничего расчищать не нужно годам, просто создаёшь кусок в полгига на новом месте. Посему 64 бита здорово экономят время, ибо фрагментировать 4294967296Гб попросту невозможно (даже ты столько не проживёшь, не говоря уже о процессе)

Важный профит 64х бит в том, что приложения собираются под четвёртый пень и SSE3. А не под первый пень, как 32х битные. Их(32х битные) _можно_ собрать и под нужный процессор, но так делают только гентушники.

Что касается экономии, то тут тоже не всё так просто: программисты даже на 64х битах часто используют 32х битные целые индексы. Программисты-то тоже не дебилы! Ну если мне нужно индексировать 100500 элементов по 1 байту, то зачем мне для этого индекс в 8 раз больше самих данных?! Сделать копию такого индекса ровно вдвое дольше, чем индекса из int'ов. Очевидно жеж!

там дело не в размере, а в выравнивании. в 64 битных системах, для более быстрого доступа, данные по умолчанию выравниваются по 8 байтным границам, а в 32-битных — по 4. поэтому эти 32-битные целые все равно занимают 64-бита.

Откуда я знаю, может тебе Linux нужен только установить/гордиться фактом. А мне вот как минимум Skype нужен. И тут начинаетс 250 мегабайт x86 библиотек и хреновая работа с 64хбитным pulseaudio)

я что-то не встречал виндузятника, который-бы нее имел-бы аськи, но имел-бы скайп. Ну кроме случаев терминальных «минимизаторов». А вот pidgin на 64х битах отлично работает, я проверял. Т.ч. IM это не показатель.

ЗЫЖ если тебе игрушки нужны, поставь себе Windows, и не нервируй здешнюю аудиторию своей «работой»

И тут начинаетс 250 мегабайт x86 библиотек

делить на ноль нельзя. Если у тебя в компе нет лишних 250Мб, то зачем тебе скайп?

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

Спасибо всем за ответы

--

все таки прочел) и вывод такой сложился, если меня эти мультилибы так напрягают - юзать x86

--

на счет swap же здесь упоминалась, я то же в нем не видел обходимости, но пользовался (при 6 Гб) и сейчас пользуюсь (8Гб) , т.к. просто потому что машину хоть и порой, но отправляю в спящий режим (в KDE4)

Ubuntu.com будет предлагать по дефолту скачать 64 битные образы

Почитай, что-ли, про File System Virtualization.

хм, гуглежь этого термина ведет на совсем отдельную тему

ты умный конечно, слово «выравнивание» знаешь, куда уж мне... Всё же попробуй для прикола написать malloc(100500*sizeof(int)), и посмотри, сколько получится...

который-бы нее имел-бы аськи, но имел-бы скайп

делить на ноль нельзя

Уроки русского языка прогуливал, на математике что-то запоминал?:)

сорри, надо гуглить File System Redirection.
Virtualization - это в UAC.

Свежих релизов нормальных операционных систем под x86 уже не делают.

На работе x86 встречается, да. Но там и Unixware встречается, так что это не показатель.