Какой Slackware лучше: 32-bit vs. 64-bit?

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

Если ты выбрал Слаку, то будь готов читать документацию. И всё у тебя заработает. 32 или 64 выбирают отталкиваясь от железа. Какую-то чушь ты тут понаписал.

По моему опыту с 14й версией у 64 битов много проблем:

qemu работает просто норм, не знаю какие там могут быть проблемы, а что бы работал wine32 в x86_64 битной версии, нужно просто установить multilib.

Wine в 64-битной Слаке работал, если поставить multilib. Остальные 32-битные приложения аналогично.

не знаю какие там могут быть проблемы

Проблемы в пользователе.

1. не работает Wine

Работал в 14.2 и работает в 15.0. И Wine32 и Wine64.

2. не работает Qemu

Работал в 14.2 и работает в 15.0.

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

Неправильно. В 64-битной системе можно запускать и 32-битные программы, а наоборот нельзя. Только надо поставить multilib от alienbob (через slackpkg+ удобно).

multilib

Ставил, но wine не заработал.

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

Какой посоветуешь?
(Lubuntu и Linux Mint уже скачал)

Ещё мне нужно базу пакетов отдельно скачать - есть такие дистрибутивы?

Выкачай репозитории просто, если есть 100 гб свободного места.

qemu работает просто норм, не знаю какие там могут быть проблемы

Она работала только с программной виртуализацией, в отличие от Lubuntu, в к-й Qemu на этом же железе работает с аппаратной виртуализацией.

multilib ставил, но 32-битные прилаги нормально не работали.

slackware-15.0 32-битную версию чтобы все пакеты были у меня на диске?

rsync -avrh --delete --progress --exclude=*source/* rsync://slackware.uk/slackware/slackware-15.0 ./
rsync -avrh --delete --progress rsync://slackware.nl/mirrors/slackpkgplus ./
rsync -avrh --delete --progress rsync://slackware.uk/mirrors/people/alien/sbrepos/15.0/x86/ ./slackware-15.0_alien-sbrepos/
rsync -avrh --delete --progress --exclude=*/x86_64/* rsync://slackware.uk/msb/15.0/ $DIR/slackware-15.0_willy-msb/
rsync -avrh --delete --progress --exclude=*/x86_64/* rsync://slackware.uk/csb/15.0/ $DIR/slackware-15.0_willy-csb/

livecd можно еще, для gparted и бэкапа корня в tar

• https://slackware.nl/slackware-live/

с 14й версией у 64 не работает Wine

да вроде работает, пробовал разные, и готовые, и сам собирал (wine/wine-staging)

• https://slackbuilds.org/result/?search=wine&sv=14.2
• http://slackware.uk/people/alien/sbrepos/14.2/x86_64/wine/
• https://wiki.winehq.org/Download

перед этим (само-собой) весь набор отсюда был установлен

• https://slackware.nl/people/alien/multilib/14.2/

В виртуализации не шарю, но вроде нужно установить qemu-kvm. С multilib ты видимо где то накосячил.

multilib ставил, но 32-битные прилаги нормально не работали

Как и что ты ставил мы не знаем. У всех всё работает.
Если бы хотел решить проблемы, задавал бы конкретные вопросы.

32-bit

а памяти у тебя сколько?

а памяти у тебя сколько?

Я ж говорю, в лубунте на этом же железе всё работает.
Мне просто перестала нравится политика лубунты, что-то много они стали себе позволять на моём компьютере.

Неправильно. В 64-битной системе можно запускать и 32-битные программы, а наоборот нельзя.

Это кстати главная засада, т.к. сейчас многие приложения только в 64-битной версии существуют… Например нужный мне OpenShot. Ну и по крипте тоже большинство приложений в 64..

на этом же железе всё работает

32 битные ОС для адресации памяти используют 2 в 32 степени бит, что составляет 4294967296 бит или 4 Гигабайт (Гб). Это значит, что максимальный объем памяти, к которому может обращаться 32 битная операционная система, составляет 4 Гб.

и это в теории - на самом деле максимальный объем будет еще меньше.

Novator, а можешь кинуть инфу мне для статистики, что у тебя за железо (cpu, gpu, m/b)?

• x86 еще возможен на новом железе?

32 битная система может использовать 64 гб памяти.

Уже на 2-х гигабайтах рамы сказываются эффекты нехватки адресного пространства. Линус вообще говорит, что начиная с 1 гига система обязана быть x86_64.

PAE?

2-х гигабайтах рамы

у меня практически везде 4 гига и заметил такое - swap никогда не используется, есть одна машина с двумя гигами - вот там я вижу использование swap происходит.

система обязана быть x86_64

естественно если железо позволяет

Не знаю, зачем тебе это надо, но:

AMD Athlon(tm) II X2 250 Processor
ASUSTeK Computer INC, M4A77TD PRO
4G RAM, NVIDIA Corporation GT215

Дело не в памяти, в том, что много прог щас тока под 64 бита.

нормальное железо для 64-бит, только видеокарта гавно - sid надо ставить, там в репе 340-ой драйвер есть - который сразу заработает стоит только установить.

Да на видюху я проприетарные дрова нашёл, с ней в лубунте проблем нет. В слаке тоже всё отображается, но я не знаю с какими дровами.

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

340-ой драйвер

• https://slackbuilds.org/repository/14.2/system/nvidia-legacy340-driver/
• https://slackbuilds.org/repository/15.0/system/nvidia-legacy340-driver/

Бред. Для десктопа 64 обычно не нужно. Если только не столкнёшься с 64-only проприетарным софтом.

Десктоп 8G ram, ноут 4G ram, и там и там 32-бит, всё норм.

Для серверов лучше 64, да.

    Your virtual address space needs to bea multiple of the physical one: when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable. You literally do need more virtual memory than physical.

    PAE turned that very simple fact on its head, and screwed things up royally. Whoever came up with the idea was totally incompetent, and had forgotten all the DOS HIGHMEM pains. There’s a damn good reason why we left the 286 behind, and started using 386′s, instead of having HIGHMEM crap with windows into a bigger physical space.

    Repeat after me:

    virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

    Anybody who doesn’t get that is a moron. End of discussion.

© Linus Torvalds

Возможно, ты эту цитату вырвал из контекста, и она относилась только к ядру. Хотя даже там она весьма сомнительна, ядру очевидно не нужен постоянный доступ ко всей физ. памяти в едином адресном пространстве.

Если же там речь была про юзерспейс (ну и то, что ты эту цитату подсовываешь про юзерспейс), то это подмена понятий во всей красе. По факту эти рассуждения подходят для одного единственного сценария: вся система собрана ради одного единственного жирного по памяти процесса. Обычно это не так. Сейчас даже браузеры многопроцессными стали и бывший раньше актуальным пример «комп для браузера» теперь тоже под эти рассуждения не подпадает.

«DOS HIGHMEM» был связан с тем, что в досе адресное пространоство у всех программ было общее.

Насчёт ядра и юзерспейса: систему с amd64 ядром и 32-битным юзерспейсом всё же разумнее считать 32-битной, а amd64-ядро в этом контексте это такое апгрейднутое PAE-ядро (потому что на софт это всё никак не повлияет). Я такой вариант использовал (для запуска всякого 64-only хлама в chroot), хотя сейчас не использую почему-то.

Возможно, ты эту цитату вырвал из контекста

Я просто сократил.

Reasons for why you need a bigger virtual space:

– you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.

– you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

Ergo, a factor-of-two is a requirement. PAE was a total and utter disaster.

Yes, Linux supported it, and probably did so better than anybody else. But “better than anybody else” still wasn’t very good. Because you couldn’t use normal pointers to point to arbitrary physical memory, all the memory that couldn’t be accessed directly (ie anythign that didn’t fit in the virtual address map, which also had the user space memory in it) was basically limited to “special uses only”.

So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).

I’m not at all surprised that Windows didn’t push PAE either. It was a total braindamage. I bet they supported it in the server offerings just because they had to, and I bet they did a much worse job of it than Linux did, and the reason you can do that with servers is that the loads are much easier, and you can expect maintainers to set magic config entries to tweak it to make it appear to work well for any particular load, when in reality it is fragile as hell and works only with duct-tape and prayers.

That kind of “duct-tape and prayers and lots of specialized knowledge about the load” is simply not possible in a desktop environment. Yeah, users have prayers, but they lack the duct-tape and the knowledge to work around the problems.

And dammit, in this age and date when almost everybody has a gigabyte of RAM in any new machine, anybody who still thinks that “not that many people need 64-bits” is simply not aware of what he’s speaking of.

Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits. Until that is the case, anybody who still doesn’t get why 64 bits is a requirement should just shut up rather than make a total fool of himself.

So repeat after me: PAE didn’t ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.

So no, PAE does not mean that you can use more than 4GB of RAM. Even before PAE, the practical limit was around 1GB, and PAE didn’t move that post a fraction of an inch!

«DOS HIGHMEM» был связан с тем, что в досе адресное пространоство у всех программ было общее.

Нет, оно было связано не с этим.

Вобщем, это было про ядро. И даже более конкретно, про ядро которому нужно больше 1гб для своих внутренних нужд. Ну, я уже написал - вполне можно на 32-битной системе использовать amd64-ядро, если ядру так удобнее управлять многозадачностью. Но это никак не влияет на всё остальное, юзерспейс всё так же стоит перед выбором 32/64, и я не вижу зачем выбирать 64 на десктопе без специфических нужд.

а что за дистр у тебя? И чисто 32, или ядро64 + сис32? UEFI / UEFI-CSM / LegacyBIOS / CMOS?

Из дистрибутивов, которые на 32 остались, не считая lts-версии: Debian, Slackware, Gentoo… OpenBSD еще есть, Debian вот вроде как в следующем релизе дропнет 32. Просто, то что ты описываешь

на 32-битной системе использовать amd64-ядро

я вроде бы здесь видел https://wiki.debian.org/X32Port , оно?

Мне не понятно, ядро: 64, софт: 32, lib/либ32 - чисто x86 или все равно lib32 + lib64 надо что бы в системе стояли?

У меня дебиан. И нет это не x32, всё гораздо проще: пишешь

dpkg --add-architecture amd64
apt-get update
apt-get install linux-image-amd64

не понятно, ядро: 64, софт: 32, lib/либ32 - чисто x86 или все равно lib32 + lib64 надо что бы в системе стояли?

Я уже показывал этот скриншот, кстати, в твоей теме. В левом окне MC специально показано, что нет lib64, только i386.

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

Автор темы неправильно воспринимает пользователей Slackware как сектантов. Сектанты это любители Gentoo , Arch Linux , Void Linux и подобного, которые выбирают дистрибутив, чтобы выпендриваться.

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

Автору посмотреть, включён ли в BIOS режим PAE. Если включён, то выключить - при 4 ГБ памяти его использование не имеет смысла.

Даже при таком объёме памяти, я бы выбирал 64 образ.

Впрочем, это лично моё мнение, но оно работает. Ну и не забыть про multilib из репозитория alienbob. У меня проблем не было.

Вобщем, это было про ядро

Нет, не только про ядро. Во-первых, разделяемые библиотеки мапятся в адресное пространство каждого процесса, их использующего. Во-вторых, программы иногда любят делать mmap. Это всё съедает адресное пространство, не трогая физическое. Открываешь большую пдф-ку в окуларе и у тебя сбрасывается дисковый кэш — адресов не хватает. Память есть, а адресов уже нет.

ядро которому нужно больше 1гб для своих внутренних нужд

То есть любое? Кэш, свап, слабы — это всё недоступно через PAE.

я не вижу зачем выбирать 64 на десктопе

64 бита быстрее. Иногда намного. Плюс PAE по определению добавляет оверхед, и чем больше памяти используют приложения, тем больше оверхед. Ну и, наконец, многие разработчики уже давно не тестируют 32-битные сборки, а некоторые даже не собирают. Пользователей полтора человека, посему багрепорты никто не постит, так и висят x86_32-специфичные баги не закрытыми. 32-бита — это боль и страдания.

Arch Linux

чтобы выпендриваться

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

rsync -avrh

Похоже, вместо «h» должно быть «H» - как думаешь?
Ключ h - это ведь показ справки.

UDP. Оказалось ключ «h» может по-разному работать.

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

Конечно мапятся, их размер надо просто прибавить к бинарнику. Никаких спецэффектов это не создаёт.

Во-вторых, программы иногда любят делать mmap.

И причём тут физическая память? Программа, если хочет сделать mmap 10G файла, будет одинаково хотеть это что с 16G памяти, что с 512M. Но да, чтобы сделать mmap файла больше 3G, нужно 64-бит. Но это свойство софта (те самые «специфические нужды», про которые я писал выше, и которых нет у большинства десктопов), повторюсь, объём физической памяти тут совершенно ни причём.

Открываешь большую пдф-ку в окуларе и у тебя сбрасывается дисковый кэш — адресов не хватает. Память есть, а адресов уже нет.

Кэш сбросится если твоя большая pdf (ага, pdf на гигабайты) его вытеснит из маленькой физической памяти. 32/64 тут ни причём. Не пиши ерунду.

То есть любое? Кэш, свап, слабы — это всё недоступно через PAE.

В этой фразе вообще сложно усмотреть смысл.

Плюс PAE по определению добавляет оверхед, и чем больше памяти используют приложения, тем больше оверхед.

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

Ну и, наконец, многие разработчики уже давно не тестируют 32-битные сборки, а некоторые даже не собирают. Пользователей полтора человека, посему багрепорты никто не постит, так и висят x86_32-специфичные баги не закрытыми. 32-бита — это боль и страдания.

Ну, у кого как. Если у тебя 64-only софт (тот, где 32-бит забагованное, относим сюда же), то придётся ставить 64. У меня такого софта нет.

По моему опыту с 14й версией у 64 битов много проблем:

1) не работает Wine

2) не работает Qemu

и так далее.

"бывает что в кругу разумных
 и образованных людей
сидишь и думаешь ну чё ты
ну чё ты блядь несёшь" (с)

Какой Slackware лучше: 32-bit vs. 64-bit?

лучше для чего?

По моему опыту с 14й версией у 64 битов много проблем:
1) не работает Wine
2) не работает Qemu

так ты даже не сказал, нужны они тебе или нет

не работает Wine

Слакварь настолько продвинутый дистр, что там нет мультилиба?

rsync -avrh

Сначала скачал как есть - получилось 6,5Гб.

Потом убрал «exclude» и докачал - получилось 15Гб с сырцами и x86_64.

Ожидал, что будет больше.

За конфиг железа, спасибо.

OpenShot

да вроде нет никакх приписок, что только 64 - openshot, в отличии от например: telegram

ключ «h»

они его по ходу в какой-то версии добавили (изменили). man-1.6g / man-pages-4.0 (28 Jan 2018): man rsync

-h, --human-readable        output numbers in a human-readable format

в man-pages-ru-0.98, которые на koi8r еще (Jan 2004) - нет. Но вот rsync --help что-то помнит

 -h, --human-readable        output numbers in a human-readable format
(-h) --help                  show this help (-h is --help only if used alone)

скачал

да просто iso распаковал бы и на каталог rsync позвал бы, что не доставало бы он докачал бы, в основном это /patches был (и возможно source)

Ну что ж, теперь ставь слаку (можно даже в виртуалку) и sbopkg осваивай, и собирай нужные пакеты, которые нужны еще будут, smplayer например быстро и без проблем соберешь, это так, для пробы пера программа эта вспомнилась

Благодарю за рекомендации.
Ставить буду позже - в этом месяце всё качаю на случай резкого чебурнета.

смотри сам, так по идеи и Manjaro ты мог бы поставить, это арч (и не арч), у них свои пакеты и свой контроль версии, как я понял из последнего что смотрел, PKGBUILD + AUR и pacman используется Arch. Например: в qbittorrent на qt6 у ArchLinux, в manjaro - qbittorrent-qt5, т.е. какой-то контроль версии идет, я думаю это с этим багом связано. По рейтинговому контролю версий обновлений я у LinuxMint еще припоминаю, но там через GUI-приложение у них это идет (вроде бы, т.е. через CLI с apt/apt-get/aptitude не нашел толком), но там именно обновления, пакеты эти и другие преимущественно из ubuntu.

32 bit с новыми ядрами 5.x работает сильно хуже.