уберут ли когда-то поддержку 32-битного режима из процессоров архитектуры x86_64?

А как в DOS загрузиться?

32-bit only юзерспейсных программ я не встречал.

root@desktop2 ~ # apt list --installed | fgrep i386

WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts.

bricscadv13/now 13.1.19 i386 [installed,local]
carla-bridge-wine32/lucid,now 1.9.5+git20150423 i386 [installed]
libgnutls26/now 2.12.23-15ubuntu2 i386 [installed,local]
libjpeg62/wily,now 6b1-4ubuntu1 i386 [installed,automatic]
lmms-vst-full/lucid,now 1:1.1.3-1kxstudio4 i386 [installed]
skype/now 4.3.0.37-1 i386 [installed,local]
ubuntu-emulator-images/wily,now 20141117-0039-0ubuntu11 i386 [installed,automatic]
ubuntu-emulator-runtime/wily,now 20141117-0039-0ubuntu11 i386 [installed,automatic]
wine-gecko1.4/now 1.4.0-0ubuntu2 i386 [installed,local]
wine1.7-i386/vivid,now 1:1.7.38-0ubuntu1 i386 [installed,automatic]
wps-office/now 9.1.0.4945~a16p3 i386 [installed,local]

сплошное ненужно и его зависимости.

Совсем поплыл, дурачок?

Винда утонет без 32 бит.

Согласен. x32 давно уже нужно отправить на свалку истории и воздать ему почести. Как поступили в своё время с Motorola'овскими M68K и PowerPC.

Тем более, что скоро 2038 на дворе будет.

32-bit only юзерспейсных программ я не встречал

загляни в мир windows

Пример нужно брать с Apple <-> OS X. Они не заморачиваются 32-битным говнецом и уже давно перевели всё на x64. Даже айфони.

Даже айфони.

Избыточность?

загляни в мир windows

Но зачем? Зачем туда заглядывать? У GNU/Linux другой, особенный путь.

Они не заморачиваются 32-битным говнецом и уже давно перевели всё на x64.

Там зачастую 32-bit only программы, как и на венде.

а вот интересно, нафига придумали этот UNIX-time и отсчет от 1970 года?

почему бы не записывать даты так, как это делают в SQL: просто пишут YYYY-MM-DD HH:mm:SS

а если в программе нужен отсчет количества секунд прошедших с какого-либо момента, то берется любая дата как точка отсчета «0», и уже исходя от нее делать конвертацию в секунды.

или тогда люди были глупее?

Избыточность?

Критическая масса.

У GNU/Linux другой, особенный путь.

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

или тогда люди были глупее?

Они жили по принципу «На наш век хватит, а там хоть камни с неба».

Потому что у OS X были конкурентные преимущества помимо поддержки легаси. Но даже у них при переезде с ppc было не всё так гладко.

винда не тонет.

Чо, и шкайп 64-битный?

байты дорогими были тогда, и считать медленнее в таком формате

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

тогда люди считались с производительностью

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

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

UPD: ну и да, правильно сказали - производительность. Тогда это было критично.

Не везде есть и нужно столько RAM...

Зачем туда заглядывать? У GNU/Linux другой, особенный путь.

Путь может и другой, но пользователей маловато и все железо под Винду делается.

32-bit only юзерспейсных программ я не встречал

Gens, например. Он на amd64 даже не собирается, ибо там какой-то лютый 32х-битный ассемблер в кишках.

А разве шкайп разработан в компании Apple? Или ты тоже винишь GNU/Linux в том, что под него M$ собирает только 32-битный скайп, заставляя тянуть кучу 32-битных библиотек?

У Apple есть замечательный 64-битный аналог скайпа — FaceTime.

уберут ли когда-то поддержку 32-битного режима

Давно пора, это отлично простимулирует лентяев прогамистов которым просто впадлу написать 64 версию.

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

Это эмулятор Sega?

Давно пора, это отлично простимулирует лентяев прогамистов которым просто впадлу написать 64 версию.

Может не программистов, а тех, кто им бабло платит и экономит на 64 битной версии, ибо и так хавают?

Ага. Имхо лучший.

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

Я PicoDrive юзаю. Он во-первых, легко компилируется под 64-битный GNU/Linux, а во-вторых поддерживает Sega CD и Sega 32x.

суть в том, что обратно совместимыми быть процессорам уже (почти) не с чем. ну вот что из нужного не собирается под x86_64?

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

куча всякого дорогого и проприетарного говнософта под винду

Много всякой современной проприетарщины под винду, старых игр.
Ведь ты не предлагаешь дропнуть 32bit в Linux, а хочешь дропнуть поддержку в процессорах, которые на винде и используются.

В первую очередь дропать 32bit надо в ОС, а уже после она станет ненужна и в железе

Не осилили воткнуть в консоль 16 эксабайт оперативки :3

А как же проприетарщина олдовых времён?

Путаешь x32 с x86. Ещё и x64 вместо x86-64 (amd64).

А вообще начинать надо с 16-битного реального режима, в котором стартуют по дефолту в том числе и последние i7 :) Чего сразу 32 битный, ещё не все на него переползли даже

Ну так ведь использование long long вместо int решает проблемы с 2038 годом даже на 32-битных системах. Собственно, на новой версии glibc этой проблемы уже нет. И в любом случае операции с 64-битным числом будут гораздо быстрее, чем с целой строкой.

При различных операциях с датой и временем (даже при выводе, если надо учесть часовой пояс, что обычно таки нужно) всё равно придётся преобразовывать строку в число или несколько чисел (отдельно каждый компонент), а потом обратно. Сделать внутреннее представление сразу в удобном виде для различных операций гораздо логичнее. Единственной ошибкой было использование 32-битного числа вместо 64-битного, однако в новых версиях glibc эта проблема решена и проблемы 2038 года нет.

Не путаю, а упрощаю.

Говоря x32, я говорю о x86 вкупе со всеми тамошними 8086, 80186, i386, i486, ia-32. Говоря о x64 я говорю от x86_64, AMD64, Intel64, EM64T, AA-64 и ещё куче говна и названий, отображающих одну и ту же суть.

Я уж молчу, например, о том, что IA-32 (Intel Architecture, 32-bit) — это x86, а IA-64 (Intel Itanium architecture, 64-bit), внезапно, несовместимый с x86 Itanium.

Напридумали всякой хрени в названиях? Теперь терпите просто x32 (x86) и просто x64. Кстати, многие компании вертели все эти пляски и называют свои пакеты просто:

qt-opensource-linux-x86-5.4.1.run
qt-opensource-linux-x64-5.4.1.run

И правильно делают.

Не путаю, а упрощаю.

таки путаешь, потому что x32 и x86 это разные вещи. http://en.wikipedia.org/wiki/X32_ABI

Я уж молчу, например, о том, что IA-32 (Intel Architecture, 32-bit) — это x86, а IA-64 (Intel Itanium architecture, 64-bit), внезапно, несовместимый с x86 Itanium.

Напридумали всякой хрени в названиях?

скудоумие, не в силах понять различие между парой-тройкой архитектур и ABI?!

qt-opensource-linux-x86-5.4.1.run qt-opensource-linux-x64-5.4.1.run

всегда знал, что кутэшники упороты, но digia всех переплюнула.

mednafen хватит всем.

А надо?

Дети, да вы очумели!
Итаник то не взлетел, а был весь такой х64 чиста...канкретна.
Никуда х86 не сольется в ближайшее время.

ДОС 1.0 запускается?

если я понил правильно, то от х86(х64) просто наборы команд, скармливаемые внутрь самому процессору, где его внутренняя прошивка уже транслирует в настоящий сегодняшний Штеуд.

А в игры как играть? Абсолютно все старые игры 32-битные. Только в последние пару лет стали делать 64-битные игры.