Началось (http://lists.centos.org/pipermail/centos-devel/2015-June/013...) формирование сборок дистрибутива CentOS 7 для серверных систем с 32-разрядной архитектурой x86 (i686), которая теперь доступна в CentOS наряду с архитектурами x86_64 и ARM64. В настоящее время 32-разрядные сборки CentOS 7 сформированы (http://buildlogs.centos.org/centos/7/os/i386/) только в минималистичной форме boot.iso (311 Мб) и имеют статус бета-версии. После первичного тестирования планируется подготовить полноценные сборки с инсталлятором.Напомним, что дистрибутив RHEL 7 поставляется только в 64-разрядных сборках, в то время как для 32-разрядных систем рекомендовано использовать ветку 6.x.
URL: http://lists.centos.org/pipermail/centos-devel/2015-June/013...
Новость: http://www.opennet.dev/opennews/art.shtml?num=42368
Зачем сейчас нужна 32 бит платформа?
Экономить ресурсы (RAMу) на тесных виртуалках.
для этого есть docker и проч. контейнеры. или вот то что intel выпустила.
Не всегда ты волен выбирать хостовую ОС
Вы правда не видите разницу между виртуальной машиной и docker?
Лучше бы x32 ABI допилили.
By ex.: В ходу по прежнему платы на атомах, а он настолько урезан, что про 64-бита лучше не заикаться - он эмулируется.
Врешь.
Дополнительный набор регистров, простейшие операции с 64-х битными int'ами и 64-х битное адресное пространство эмулируются?? Ну ничего себе эмулятор.Что Atom N2800 (2011 год) в моем домашнем роутере, что Atopm Z3740 на планшете совершенно нативно работают в 64-х битном режиме.
Да не парьтесь вы по застрявшим в прошлом. Пусть себе экономят. Вот только производительность серверных CPU почти (по сравнению с прошлым) не растёт уже, а размер RAM вполне себе растёт дальше. Так что скоро жизнь заставит экономить вовсе не RAM, а такты.
Для спец.компов/спец.железок которые в прошлом веке разрабатывались но и сейчас справляются со своими спец.задачами, и у которых драйвера только для 32 разрядных систем написаны.
> Для спец.компов/спец.железок которые в прошлом веке разрабатывались но и сейчас справляются
> со своими спец.задачами, и у которых драйвера только для 32 разрядных
> систем написаны.Ну и почему бы на этих платформах не юзать настолько же древние ОС? Они же справляются, а раз справляются - зачем что-то менять?
> Зачем сейчас нужна 32 бит платформа?Затем, что полно серверов, которые нормально работать будут ещё годы, а менять их очень дорого.
> Затем, что полно серверов, которые нормально работать будут ещё годы, а менять
> их очень дорого.А электричество на это "нормально" не дороже обойдётся?
Всякий старый Ъ софт иногда работает только на 32 и который некому уже рефакторить/переписывать.
> Всякий старый Ъ софт иногда работает только на 32 и который некому
> уже рефакторить/переписывать.Пггостите, но под x86-64 замечательно можно собрать этот софт с -m32. Совместимость никто не ломал.
Но зачем?!
А зачем на какой-нибудь дешёвой VPS'ке с полгигом памяти x86_64?
aim, ну предположу, что в серверном мире всё же есть говноприложения вроде skype, которые хотят 32-х битные либы, значит они всё равно нужны, а раз нужны, значит нужно их вместе оттестировать и паковать. Собственно, мы подошли к 32-х битной сборки CentOS7.
> aim, ну предположу, что в серверном мире всё же есть говноприложения вроде
> skype, которые хотят 32-х битные либы, значит они всё равно нужны,
> а раз нужны, значит нужно их вместе оттестировать и паковать. Собственно,
> мы подошли к 32-х битной сборки CentOS7.32хбитные либы в RHEL 7 есть.
А если приложение хочет 32-х битное ядро, то setarch делать? Почему бы не собрать ОСь из имеющихся либ? А если это трудно ввиду каких-то недочётов, то не надо хвалиться, что все либы есть и их можно установить в 64-х битную ОСь.
> А если приложение хочет 32-х битное ядро, то setarch делать? Почему бы
> не собрать ОСь из имеющихся либ? А если это трудно ввиду
> каких-то недочётов, то не надо хвалиться, что все либы есть и
> их можно установить в 64-х битную ОСь.ты не понимаешь - задача избавится от legacy приложений
тут мало кто держит в голове тот факт что ядро фактически давно не разрабатывается для архитектуры x86, только x86_64. и это свершившийся факт. линус сам об этом говорил в одном из интервью - он его даже для x86 не собирает
чтобы был выбор
а зачем гонять 64-разрядную ось на компах с памятью до 4 гигов?
Так что ура товарищи, с добрым утром! :)
Для того, что бы использовать 64 битные регистры, например для арифметики.
И как часто в софте вообще используют int64? На ум приходят только кишки файловой системы, чтение случайных мест файлов имеющих размер более 2Гбайт, иногда индексы баз данных. Общение с сетью в uint16 влазит, криптография под 32-бита заточена, фото и видео больше нуждаются в mmx. А арифметика обычно нуждается в числах с плавающей точкой. Более того не всегда операции с 64 битами стоят дешевле 32-разрядной реализации (а вы думали за 1 такт всё?). Единственный плюс, из за простоты внутренней реализации процессоров AMD, дополнительные 8 регистров работают немного быстрее кеш-памяти, на этом достоинства заканчиваются и вылезают расходы по хранению и обработке 64-битных указателей.
> И как часто в софте вообще используют int64?Практически в каждой собранной например GCC софтине. Операции со строками, например. Или копирование структур.
Про int16 для сети - это вообще нонсенс. Даже на mac-адрес uint32 не хватит, а уж про IPv6 вообще молчу. Криптографии - так вообще, чем больше, тем лучше, в любых проявлениях.
В общем, что-то как-то вы слегка мимо.
> Практически в каждой собранной например GCC софтине. Операции со строками, например. Или
> копирование структур.Операции с файлами, наконец: файлы давно не умещаются в 2^32...
Повод нормально работать с файлами от 2Гбайт уже достаточно весомый для любой современной программы.
Кроме того одна 64-битная операция во многих случаях может заменить 2 любимых вами 32-битных.
По поводу плавучки: Не везде её можно использовать, а фиксированная точка на 64-битах может оказаться более удобной.
> Повод нормально работать с файлами от 2Гбайт уже достаточно весомый для любой
> современной программы.Только реально для программистов ничего не упрощается, а вычисления над файловыми указателями производятся очень редко. На пару операций с 64-битным указателем приходиться IOPS диска, который обрабатывается с точки зрения процессора практически вечность.
> Кроме того одна 64-битная операция во многих случаях может заменить 2 любимых
> вами 32-битных.С чего это вдруг? Это Вам не sse обрабатывающих от 4 чисел за операцию. Я Вам открою страшный секрет, но на уровне ассемблера 64-битная арифметика без особой нужды не используется, то есть только операции над редкими int64 и частыми указателями.
Если бы была реальная нужда 64-битных регистрах, то производители процессоров внедрили бы их отдельно, задолго до дефицита адресации оперативки. Но всех вполне устраивало 2 инструкции. Тем более, что число инструкций в x86 никогда не было мерилом производительности.
Да виртуалки с 256Мб оперативки еще вполне себе в ходу, и 64 бита там совсем не нужны.
Только вот зачем там семерка? Для унификации разве что.
На виртуалках с 256Мб, даже rhel6 во время yum update может так призадуматься что мало не покажется.
> Да виртуалки с 256Мб оперативки еще вполне себе в ходу, и 64
> бита там совсем не нужны.CentOS 7 на виртуалку с 256мб - это совсем для любителей извращений. Туда пятерка то с трудом влазит, с обрезкой всего.
> CentOS 7 на виртуалку с 256мб - это совсем для любителей извращений.
> Туда пятерка то с трудом влазит, с обрезкой всего.А yum к тому же ловит OOM при малейшем поползновении...
для многоплатформенности! А то скоро забудут,что это такое...
3акопайте обратно
Вместе с железом (((