CRUX отказывается от поддержки x86

сейчас, может, и нет, но когда я его ставил - в RTCW играть было нереально.

То, что ты не знаешь этих причин, еще не значит, что их нет.

Озвучьте, пожалуйста.

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

В CRUX и так пакетов немного, одним больше, одним меньше - не так уж и важно.

3D работало

это где это и какой идиот предлагал?

какая-то нерусская идиотка. Жирная как слон. Тут было...

CRUX is a lightweight, i686-optimized Linux distribution

речь про преальфу. Как будет релиз, так может и пора закапывать.

а где и кто сейчас выпускает x86 процессоры? (без x86_64)

выпускать не выпускают, но юзают много где. Не все же геймеры-задр0ты, иные просто работают. Например мне 64 на фиг не нужен вобщем-то. Разве только для тестов (в продакшене давно уже 64)

а где и кто сейчас выпускает x86 процессоры?

А зачем на роутере 64 бита?

Не все же геймеры-задр0ты, иные просто работают.

Геймеры как раз не практикуют x86_64, вы всё перепутали %)

Не только четвертые пни.

четвёртые пни 64х битные. В большинстве своём. Вот мой например:

model name : Intel(R) Pentium(R) 4 CPU 3.20GHz

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr

Linux dt 3.2.28 #2 SMP Thu Aug 23 12:43:19 CDT 2012 x86_64 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux

Геймеры как раз не практикуют x86_64, вы всё перепутали %)

это ты про олдфагов, которые рубятся во вторую кваку на третьем пне?

Покажите мне современные игры, у которых есть 64-битные сборки.

pni

Значит у тебя модный P4 с SSE3 :)

что за бред? Уже есть адекватная замена?

девушка против проводов в её офисе. Вот и борется. Типа «мне не нужен, значит и из ядра выкинем». Детали её не волнуют.

А зачем на роутере 64 бита?

в роутерах вообще ARMы и MIPSы

Ладно, пусть будут не роутеры, всякая военная техника. Там вообще до сих пор Intel 386 широко применяются.

Извращенцы - это те, кто ради legacy-приложений пользуется x86 (других причин-то нет).

для них можешь поставить multilib. УМВР.

А я хочу kvm, spice, современные мультимедийные инструкции и быстродействие. Другими словами, использовать весь потенциал своего процессора.

кто заставляет использовать для этого 64х битные CPU? Даже сам Патрег давно не собирает под i80486. Что до быстродействия, то тут вопрос далеко не такой однозначный - если собрать софтину со всеми плюшками (кроме 64х битности), то не факт, что она заработает медленнее. Далеко не факт. Просто маинтейнеры часто считают «32х битное == первый пень», вот оно и тормозит.

Покажите мне современные игры, у которых есть 64-битные сборки.

покажите мне современные игры, которые пойдут на CPU без 64х бит?

Значит у тебя модный P4 с SSE3 :)

не говори - «модный»...

SSE3, Streaming SIMD Extensions 3, also known by its Intel code name Prescott New Instructions (PNI), is the third iteration of the SSE instruction set for the IA-32 (x86) architecture. Intel introduced SSE3 in early 2004 with the Prescott revision of their Pentium 4 CPU.

А при чём тут CPU? Речь разве не об ОС?

А при чём тут CPU? Речь разве не об ОС?

тут фишка в том, что страдают от этого лишь «счастливые» обладатели 32х битных третьих пней. Даже олдфаги типа меня уже давно юзают четверопни, на которые прекрасно ставится 64х битная ОС.

Что касается недобуков, дык они и так такой отстой, что там разве что Vim без иксов не тормозит.

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

для них можешь поставить multilib. УМВР.

ЗАЧЕМ??? Мне не нужны 32-битные приложения, прочитай ещё раз то, что я написал, пожалуйста.

кто заставляет использовать для этого 64х битные CPU?

64-битные инструкции заставляют.

http://spice-space.org/faq.html

KVM на 32 битах работает очень плохо. :(

если собрать софтину со всеми плюшками (кроме 64х битности)

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

ЗАЧЕМ??? Мне не нужны 32-битные приложения, прочитай ещё раз то, что я написал, пожалуйста.

я рад за тебя, однако бывают ещё закрытые 32х битные приложения. И если тебе они не нужны, то это мало о чём говорит.

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

привет, К.О. Речь как раз и идёт о том, что нет никакого смысла собирать под 64х битный первый пень - во всех 64х битных процессорах имеются необходимые фичи. Вот именно за счёт этих фич, 64х битное работает быстрее. А что-бы ускорение было реально заметно именно от 64х битности, тебе надо _очень_ специфическое приложение. Например такое, которое активно работает с 10..20 Гб ОЗУ, отсутствие PAE-костыля будет заметно. Можно было-бы конечно заюзать 64х битную целочисленную арифметику, но зачем, когда есть 128и битное SSE и 80и битный FPU?

я рад за тебя, однако бывают ещё закрытые 32х битные приложения. И если тебе они не нужны, то это мало о чём говорит.

Ещё раз, теперь по слогам. Я назвал извращенцами тех, кто использует x86-дистрибутивы для запуска legacy-софта, ты мне ответил, что можно использовать multilib. Спасибо, я знаю, что на 64 битах можно использовать multilib. Кроме этого я объяснил, что предпочитаю pure64.

Речь как раз и идёт о том, что нет никакого смысла собирать под 64х битный первый пень - во всех 64х битных процессорах имеются необходимые фичи. Вот именно за счёт этих фич, 64х битное работает быстрее.

Ну так все и собирают как минимум под Athlon 64.

Тут у меня встречный вопрос, зачем отказываться от преимуществ 64 бит, если можно их прекрасно использовать?

Спасибо, я знаю, что на 64 битах можно использовать multilib. Кроме этого я объяснил, что предпочитаю pure64.

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

Ну так все и собирают как минимум под Athlon 64.

очевидно.

Тут у меня встречный вопрос, зачем отказываться от преимуществ 64 бит, если можно их прекрасно использовать?

отвечу вопросом на вопрос: а какие в 64х битной архитектуре преимущества? Лично для меня ответ далеко не очевиден, ибо данные уже давно обрабатывают по 128 бит за раз, а что касается адресов, то 64х битный адрес нужен лишь тем, у кого приложения захавают десятки гиабайт RAM, а лично у меня дома нет ни таких приложений, как нет и десятков гигов памяти. У тебя есть?

Озвучьте, пожалуйста.

• Intel Atom (N2xx and Z5xx series)
• Geode
• VIA C3/VIA C7
• менее 4Gb RAM
• lightweight, lightweight на 64битах не получится
• ...more...

А потом такие фанаты прогресса страдают на хабре:

При переезде с 32-битного (на Core2Quad) Ubuntu на 64-битный (на Athlon 64 X2) Debian оказалось, что все процессы, будь-то PHP или старый добрый Apache2, стали потреблять вдвое больше памяти. Знающие люди подсказали то, о чем сразу не подумал сам — рост потребления памяти обусловлен вдвое большей длиной указателей. Совершенно справедливо напрашивается вопрос — в чем тогда выигрыш для простого сервера? Было 2Гб памяти на 32-битах, стало 4Гб на 64-битах, при этом сhild-процессов Apache2 в памяти может жить примерно одинаковое количество, потому как на старом сервере один процесс занимал 20Мб, а на новом — все 50Мб.

речь про преальфу. Как будет релиз, так может и пора закапывать.

Так я и написал «Как дропнут»

При переезде с 32-битного (на Core2Quad) Ubuntu на 64-битный (на Athlon 64 X2) Debian оказалось, что все процессы, будь-то PHP или старый добрый Apache2, стали потреблять вдвое больше памяти.

кого ты слушаешь? хабробл... Эх...

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

знающие люди также подсказали, что в памяти хранятся _только_ указатели?! Откуда такой бред? А уж «одна бабка сказала, что один дедка сказал»...

Было 2Гб памяти на 32-битах, стало 4Гб на 64-битах, при этом сhild-процессов Apache2 в памяти может жить примерно одинаковое количество, потому как на старом сервере один процесс занимал 20Мб, а на новом — все 50Мб.

бред сивой кобылы. Очевидно настройки php+apache соответственно изменились, как это и положено для 2Гб->4Гб. У меня ничего не поменялось, разве что VIRT действительно выросла до 1500Мб, но то VIRT, спутать его с RES может только совсем неграмотный.

кого ты слушаешь? хабробл... Эх...

Ты неправильно понял, о чем эта цитата. Это не аргумент о недостатках 64бит, а иллюстрация той глубины разочарования, у таких вот «фонатов прагреса», которая постигает их, когда они осознают, что 64бит это не silver bullet, не волшебная лампа Алладина и уж тем более не кнопка «зделать з*****ь»

Ты неправильно понял, о чем эта цитата. Это не аргумент о недостатках 64бит, а иллюстрация той глубины разочарования, у таких вот «фонатов прагреса», которая постигает их, когда они осознают, что 64бит это не silver bullet,

ну лично я никаких чудес и не ждал. Лично мне просто удобнее тестировать ПО на 64х битах. В принципе я получил то, что хотел. А эта ваша цитата сродни разочарования, которое постигло автора мема «девочки тоже какают». Ну да, чудес-то не бывает...

x86 надо закопать для того чтобы перестали выпускать x86-only поделия(2012 год, а до сих пор есть куча софта, который без глюков только на x86 работает, существование multilib тому в подтверждение). молюсь на то чтобы венда поскорее выбросила поддержку x86, тогда разрабы начнут наконец шевелится и оптимизировать под x86_64, а не под гомно мамонта.

ну лично я никаких чудес и не ждал. Лично мне просто удобнее тестировать ПО на 64х битах.

ну так и про «фоната прагреса», это не к тебе относилось, если че.

А эта ваша цитата сродни разочарования, которое постигло автора мема «девочки тоже какают».

Именно.

VIRT действительно выросла до 1500Мб, но то VIRT, спутать его с RES может только совсем неграмотный.

Кстати, о птичках.

В ядре есть возможность (ulimit) ограничить максимально допустимый объём VIRT-памяти, выделяемой на процесс. Есть ли возможность ограничить RSS? man ulimit говорит, что RLIMIT_RSS не работает.

А то получается, что мне толку, что софтина расходует 50М RSS, если ограничить я могу лишь VIRT, а её в наши дни никто уже не считает, особенно на x86_64.

Бида-бида, в зоопарке проблемы, здох какой то срух.

Ну и правильно

x86 надо закопать для того чтобы перестали выпускать x86-only поделия

с одной стороны ты прав, но какой смысл скажем в 64х битном контроллере холодильника? Многие высокопроизводительные специализированные системы также не нуждаются в 64х битных указателях. Многим приложениям (десктопным) вообще достаточно <1048576 байт. Таких AFAIK не менее 80%.

2012 год, а до сих пор есть куча софта, который без глюков только на x86 работает, существование multilib тому в подтверждение

1990 - 640kB хватит всем! Как-то пережили... И 4х гиговый лимит тоже переживём.

В ядре есть возможность (ulimit) ограничить максимально допустимый объём VIRT-памяти, выделяемой на процесс. Есть ли возможность ограничить RSS? man ulimit говорит, что RLIMIT_RSS не работает.

Если ты про RES в смысле man 1 top, то как его ограничит ядро? Приложение захавало 100Мб, и единственное, что может сделать ядро - прибить этот процесс. Как ты представляешь процесс ограничения?

А то получается, что мне толку, что софтина расходует 50М RSS, если ограничить я могу лишь VIRT, а её в наши дни никто уже не считает, особенно на x86_64.

именно так и получается. а что делать? Вот мой ФФ сейчас жрёт 244Мб, и единственное, что я могу сделать - закрыть пару вкладок с быдлосайтами. ЛОР жрёт поменьше (хотя тоже немало, ибо на странице 100 постов)

с одной стороны ты прав, но какой смысл скажем в 64х битном контроллере холодильника?

А зачем вообще в холодильнике архитектура x86? ARM или MIPS, но никак не x86

Как-то пережили... И 4х гиговый лимит тоже переживём.

Там лимит был более жестким и меньше legacy накопилось, чем сейчас. IPv4 еще бы пережить и вообще хорошо будет.

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

Ну вообще насколько я помню(давно уже на С не писал) malloc может и null вернуть если памяти нет, а ядро может просто не дать память выделить выше лимита.

молюсь на то чтобы венда поскорее выбросила поддержку x86

В девятой винде 32-ух бит уже не будет.

а какие в 64х битной архитектуре преимущества?

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

В девятой винде 32-ух бит уже не будет.

3 года релиз-цикл + сколько там лет поддержки старых версий останется... имеем не меньше 6-8ми лет на то чтобы x86 начала хоть как-нибудь ощутимо дохнуть

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

SIGKILL, возможно с предварительным SIGSEGV. В данном случае этого было бы достаточно. Если кто-то ставит RSS-лимит, он отдаёт себе отчёт в том, что он делает.

Посоны говорят, что там скорее важна видеокарта.

А зачем вообще в холодильнике архитектура x86? ARM или MIPS, но никак не x86

а зачем в мой диалапный модем засунули 80186? всё просто - уже во времена 80486, 186й стОил копейки, но для него было Over9000 SDK и 100500 рабочего ПО любого назначения. Сейчас ситуация изменилась не сильно.

Там лимит был более жестким

как сказать...

и меньше legacy накопилось, чем сейчас.

да ладно! тогда ЕМНИП вообще OpenSource в продакшене не было.

IPv4 еще бы пережить и вообще хорошо будет.

ну это проблемы виндейцев, *NIXы уже готовы к IPv6.

Ну вообще насколько я помню(давно уже на С не писал) malloc может и null вернуть если памяти нет, а ядро может просто не дать память выделить выше лимита.

дело не в этом. Если ты напишешь такой код

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
	char *p = malloc(1048576UL*90UL);
	if(!p)
		return 1;
	sleep(100);
	free(p);
	return 0;
}

PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
27070  0.0  0.0  96320   348 pts/1    S+   09:26   0:00 ./mem

ЗЫЖ и да, ты про разряжённые матрицы когда-нить слышал? очень востребованный алгоритм, когда есть матрица N*N, в которой _почти_ все ячейки пустые. Но не все. Очевидно, решить задачу можно софтово, а можно и железно, тупо выделив памяти под всю матрицу. Также очевидно, что железный путь как минимум на порядок быстрее. И также очевидно, по каким причинам кодеры не могут выделить жалких 100Гб - 32 бита же! И не выделяют ЧСХ. Т.ч. 64и бита таки нужны IRL, только кодер должен быть УВЕРЕН, что у заказчика тоже 64и бита. Пока - не уверен. ИЧСХ речь идёт не про прикладного кодера, который юзает php и прочие жабы, и о битности не задумывается, а о создателях хотя-бы бэкэндов, типа СУБД. А тут всё совсем плохо - девелоперы MySQL даже не собираются сделать истинный 64х битный INT, и по своему они правы (ибо если прикладные кодеры начнут его юзать в массовом порядке, взвоют enduser'ы, даже те из них, что сидят на 64х битном железе, но на 32х битной ОС)

отмирают тупиковые ветви
это хорошо

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

там будет и 10и кратный выигрыш. Но конечный юзер это заметит не ранее, чем лет через 5. А пока незначительный выигрыш лишь на _синтетических_ тестах, и к RL это не имеет отношения.

3 года релиз-цикл + сколько там лет поддержки старых версий останется... имеем не меньше 6-8ми лет на то чтобы x86 начала хоть как-нибудь ощутимо дохнуть

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