Linux version x86 or x64

Все способы узнать версию дистрибутива Linux (а также FreeBSD, MacOS и прочих)

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

Учитывая зоопарк дистрибутивов Linux, иной раз, получая доступ к серверу, не понимаешь, где ты находишься. Особенно это больно, если нужно поставить недостающий пакет. Руки сами пишут

в надежде увидеть

или что-то подобное, но в ответ лишь

Следующее, что приходит в голову:

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

— «правильный вариант» для людей «всё есть файл».

Вообще, это не единственный «релиз», который у нас есть в /etc.

У красноголовых можно встретить redhat-release, например.

Идём дальше по файлам:

(их два на Ubuntu). Ну и

Ещё неплохой вариант «выцыганить» версию из логов dmesg

Или вообще использовать утилиту inxi (в иных дистрибутивах и она стоит, например Linux Mint):

Также можно посмотреть данные по аудио, железу, даже монитору через inxi -F .

A можно глянуть, как ядро Linux запущено:

sysctl также нам поможет:

Окей, нет у нас этих утилит, файлов, но кто-то оставил gcc…

Ну и вообще можно натравить strings на тот же /bin/ls и получить также много информации. Правда, там так просто не найти нужное (или вообще не найти).

Утилита file также может рассказать многое:

Если же ничто из этого не помогло, поищите на экране кнопку «Пуск» ⛧

Есть ещё вариант спросить админа… Но он слишком дзенский.

— Максим, — спросил Федор — в чем смысл дзен?
Максим ответил:
— Смысл дзен — это как налить из чекушки четыре полных стакана водки.
— Да, — сказал Федор — из пустой.
— Да, — ответил Максим — и не выпить.
— Да, — сказа Федор — и водку в стаканы не наливать.

Я уверен, это не все возможные способы. Если вы знаете другие «элегантные» способы узнать дистрибутив Linux и версию ядра — поделитесь ими в комментах. Самые интересные, естественно, добавлю в этот список.

Источник

Linux x64 или x86 + pae на домашний компьютер?

Если adobe flash не нужен, то x64.

PAE кажется «костылем».

На работе При 4хГБ использую 32бит — сложилось исторически. Без PAE удовлетворяет, разве что виртуалбоксу больше пары гиг оперативки не выделишь.

Дома 8гб — 64бит.

Использую PAE с 6GB RAM.
Никаких проблем не замечено, полет нормальный.

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

Читайте также:  Невозможно установить mac os ошибка 3

Источник

Быстрее, выше, сильнее: Clear Linux — самый быстрый дистрибутив для x86-64?

На днях ресурс Phoronix опубликовал результаты тестов скорости работы разных дистрибутивов Linux на системе с Core i9 10980XE.

Тестирование проводилось со сборками Clear Linux 33540 (самая новая на момент теста), Clear Linux 31480 (конец 2019 года), Endeavour OS Rolling, openSUSE Tumbleweed 20200727, Debian Buster Testing, Ubuntu 20.04 LTS и тестовая сборка Ubuntu 20.10.

Подробности тестирования — под катом.

Технические характеристики тестируемой системы:

  • Процессор: Intel Core i9-10980XE @ 4.60GHz (18 Cores / 36 Threads)
  • Плата: Gigabyte X299X DESIGNARE 10G (F1 BIOS)
  • Чипсет: Intel Sky Lake-E DMI3 Registers
  • SSD: Samsung SSD 970 PRO 512GB
  • Графический чип: AMD Radeon RX 64 8GB (1590/800MHz)
  • Аудио: Realtek ALC1220

Что касается Clear Linux, то его характеристики следующие:

  • Ядро Linux 5.7,
  • Компилятор GCC 10.2.1,
  • Python 3.8.4,
  • I/O-планировщик для NVMe-накопителей — BFQ,
  • Графическая оболочка GNOME 3.36.

Тестирование проводилось для того, чтобы выяснить прогресс в разработке Clear Linux. Весной компания Intel, создатель этого дистрибутива, заявила о том, что Clear Linux становится системой для серверных, облачных и встраиваемых систем, где скорость работы и отзывчивость очень критичны.

Пока что обещания постепенно повышать производительность дистрибутива выполняются. Так, время загрузки новой версии Clear Linux по сравнению с предыдущей снизилось сразу в 2,5 раза.

Что касается сравнения с другими системами, то Clear Linux в большей части тестов опередил конкурентов, хотя и не везде. Дистрибутив от Intel оказался первым в 73 из 136 тестов. Результаты авторы проекта визуализировали.

По словам разработчиков, высокая скорость работы дистрибутива Clear Linux объясняется жесткой оптимизацией для архитектуры x86-64.

Второе и третье место заняли Ubuntu 20.10 и Debian Buster. Ubuntu всего на 4% отстал от лидера.

Результаты всех тестов можно просмотреть в итоговом файле.

Источник

Linux x64 — ставить ли?

Что я приобрету, если поставлю 64-битный дистрибутив?

И что потеряю? Flash слышал не работает, openoffice вроде тоже, что еще.

Прикручивать всякие костыли не хочется.

Re: Linux x64 — ставить ли?

> И что потеряю? Flash слышал не работает, openoffice вроде тоже, что еще.

flash работает, правда с 32 битными браузерами 🙂 OO2 есть в 64битной убунте точно

вообще спроси лучше Шамана, у него уже есть опыт наступания на 64битные грабли 🙂

Re: Linux x64 — ставить ли?

Re: Linux x64 — ставить ли?

Flash у меня работает и с Firefox, и с Opera, и с Konqueror (Suse 10.1), с OpenOffice тоже все в ажуре. Ей-богу, не знаю, что теряется, вроде бы все ок. А из приобретений — пожалуйста, Математика 5.2 считает в 64битном режиме подчас процентов на 50 быстрее, чем в 32битном:)

Re: Linux x64 — ставить ли?

бывают траблы с установкой/компиляции софта, особенно если часть из них в lib а часть в lib64, или два варианта либов сразу 32 и 64.

. костыли прикручивать придёццо. Но их не настолько много, шо прям капец.

Re: Linux x64 — ставить ли?

Стоит. ну что сказать. ощущаешь себя несколько меж ягодичных мышц. Выгода? Ну. оптимизация под архитектуру по идее. Минусы? хм. с чего бы начать. Ну, в общем, основное скажу с чем сталкиваюсь — во всех причем дистрибах х64 — ни одного исходника нормально не скомпилишь — пол библиотек сидишь ищешь, а потом в ручную линкуешь. Жить можно, в принципе, но порой напрягает их такая тяжкая совместимость с х32. Сим скомпилил вроде. запускается и после того как пытаешься залогиниться в icq — валится нахрен. Разбираться пока некогда. Ну, вот в целом мои соображения о выгоде х64 дистрибутов.

Re: Linux x64 — ставить ли?

Хотя касательно упомянутых приложений — все нормально.

Re: Linux x64 — ставить ли?

Более года по x86_64 — еще ни разу не пожалел, что пересел. Да, флеша нету — ну и нах его фтопку! Остальное фурычит, даже проги многие уже осилили кофиг для amd64.

Читайте также:  Как сделать чтобы windows не загрузился

Re: Linux x64 — ставить ли?

Ну, а почему нет.. Даже если какого ПО и нет в 64-разрядном исполнении, оно прекрасно будет работать и в 32-разрядном..

Re: Linux x64 — ставить ли?

Полгода примерно на Arch64. Все ништяк. Даже вон Unreal 2003/2004 и HMM3 работают.

Re: Linux x64 — ставить ли?

Если не хочется костылей — придется выкинуть wine и использовать gnash.

Re: Linux x64 — ставить ли?

Если Убунта запускать надо через chroot 32 битные проги ( mplayer, firefox, wine etc ). Если Suse, FC, — то там не полностью 64 битные системы а «смесь» библиотек ( 32 и 64 битных ) — все запускается из «к оробки» — но честно говоря оно и нафиг ненужно. Убунтовцы говорят что amd64 это для Opertonов и Xeonов — для остального 32 бита — так что стоит прислушаться к их совету . Так что если у тебя памяти юзается меньше 4 гигов — то оно просто не нужно .

Re: Linux x64 — ставить ли?

>flash работает, правда с 32 битными браузерами 🙂

С 64-х битными тоже. nspluginwrapper для родного флеша, или gnash. На выбор 🙂

В принципе, полтора года на gentoo на amd64 — полёт нормальный. Памяти только софт жрёт больше 🙂

Re: Linux x64 — ставить ли?

>бывают траблы с установкой/компиляции софта, особенно если часть из них в lib а часть в lib64

В gentoo /lib и /lib64 — синонимы. lib64 — симлинк на lib

Re: Linux x64 — ставить ли?

>Ну, в общем, основное скажу с чем сталкиваюсь — во всех причем дистрибах х64 — ни одного исходника нормально не скомпилишь

Блин, это уже какая-то реклама Gentoo выходит, но тут ВЕСЬ софт компилится из 64-х битных исходников. И весь компилится нормально 🙂

Re: Linux x64 — ставить ли?

Re: Linux x64 — ставить ли?

> Блин, это уже какая-то реклама Gentoo выходит, но тут ВЕСЬ софт компилится из 64-х битных исходников. И весь компилится нормально 🙂

Re: Linux x64 — ставить ли?

> из 64-х битных исходников

Re: Linux x64 — ставить ли?

У меня на 64хбитной убунте не захотел работать атишный драйвер (как из репозитория, так и с офсайта). То есть формально-то он работал, только иксы стартовали через раз и при запуске GLных вещей все валилось или повисало намертво. Есть проблемы с коммерческими приложениями и дровами. Приложения можно конечно запускать в chroot’e, но мне как-то такие костыли не по вкусу. Как обстоят дела с нвидийными дровами, не знаю.
Но думаю, что костыли обеспечены, если ставишь x86_64 🙁

Re: Linux x64 — ставить ли?

В общем: все работает, но то, что жестко завязано на 32 бита (wine, win32codecs, flash (но с флешом какой-то враппер смонстрячили)) пускается довольно геморройно. + по 2 экземпляра основных библиотек.

Re: Linux x64 — ставить ли?

Так а что там с кодеками-то получается?

Re: Linux x64 — ставить ли?

А ничего — либо ставь полностью 32битный mplayer, или не используй Темную Сторону Силы. По скорости кроме спецзадач выигрыша нет, браузер и плееры приходится тянуть 32 разрядными. Если нужен wine — получаем некоторый гемор. А как сервер — все пучком.

Re: Linux x64 — ставить ли?

Вообще, это кодеки не особенно-то и нужны (да и зачем разводить проприетарщину). FFmpeg, ЕМНИС, только с WMV9 не справляется, ну и фиг бы с ним.

Re: Linux x64 — ставить ли?

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

Всякие вычисления в расчет не берем, это не нужно.

Re: Linux x64 — ставить ли?

> > из 64-х битных исходников

Вставим пару слов по теме.

0. Ядро держит трансляцию системных вызовов нормально => иметь полностью нативное 32-битное окружение и 64-битное ядро — вполне реально (за исключением некоторых специфичных системных утилит).

Читайте также:  Как менять права доступа linux

1. 64-битный опенофис получить просто так не выйдет, во всех дистрах — 32-битная версия, зависимая от 32-битных либок (разве что в Генту асилили, но не уверен) => получаем всю эту дублирующую байду в довесок по требованиям к памяти. Возможный выход — засунуть 32-битное окружение для сборки в chroot и собирать статически, но от пожирания памяти тем офис не избавить.

2. Косяки есть с дровами от ATI, любым имеющим ассемблерные вставки для простого х86 и не имеющим возможности сборки без них софтом — grub, rte, ffmpeg (до какого-то периода, если -svn — то нормально), с WINE, ну и вроде все из собираемого у меня. KDE+KOffice собираются нативно и корректно, вообще проблем нет — если юзать их, все пучком.

3. Нативная java-1.4.2 существует только в версии blackdown, каким-то шаманством полученная из сорцов от SUN + патчи, но оных патчей нигде почему-то не найти => остается либо юзать бинари, либо собрать самому нативную 64-битную 1.5.0 из соответствующих сорцов.

Запарила проблема с кучей либок под разные платфомы (m32/m64 => lib/lib64), посему у себя я вырубил поддержку multi-lib патчиками еще в сорцах gcc/glibc/binutils, и получил дерево директорий полностью одинакового с m32 вида — только «lib», никакой запарки с несколькими ld.so и параметрами ld, полностью нативная 64-битная система.

Вообще — никак пока не собирается только OpenOffice, это единственный оставшийся косяк.

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

В реальном мире — ставил «на посмотреть» SUSE 10.1 OSS, вроде как «х86_64»: ситуация — чистый «ужоснах», по-моему 64-битное там только ядро, память жрет — упаси аллах, тормозит по сравнению с самосборной системой — не то что заметно, даже секундомер не нужен — в разы даже при отключенных ненужных сервисах и прочих оптимизирующих шаманствах. Еще бы кто объяснил, зачем нужны опциональные TLS-версии либок, если на amd64 оное не включается «бай дефолт» разве что по скудоумию.

Re: Linux x64 — ставить ли?

С win32-кодеками — полная жопа 🙂

Но не забываем о сладкой парочке XINE+MPlayer, они играют много-много чего, даже сами по себе, без всяких костылей. *приняв позу мудреца и стараясь не заржать, изрекаю* : Озаботившись сией проблемой, я умудрился найти в домонете только какие-то wmv, судя по виду, расположению и названию — явно порнографического характера и слитые с соотвествующих серваков, с какой-то противоестественной защитой и левого формата, играться отказались.

Re: Linux x64 — ставить ли?

x64 — маркетинговое ms-название. Нет x64-архитектуры, есть x86_64 и опять же маркетинговое название Intel — EM64T, которые практически одинаковы между собой.

Re: Linux x64 — ставить ли?

>во всех причем дистрибах х64 — ни одного исходника нормально не скомпилишь — пол библиотек сидишь ищешь, а потом в ручную линкуешь.

Что-то ты какие-то страшные вещи рассказываешь. Ни разу с таким не сталкивался в мандриве 2006 под x86_64

Re: Linux x64 — ставить ли?

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

Если софт не очень активно использует long вместо int, то проигрыш по памяти — в пределах 10% максимум (таблицы экспорта, указатели, etc), иначе — треть максимум (опытным путем на примере КДЕ+Кофис+Гимп с доками-картинками и т.п.), ну а заявы типа «win64 треба рамы в 2 раза шире, так как битиков в 2 раза больше» — действительны только в виндах.

Re: Linux x64 — ставить ли?

Маркетинг маркетингом, но требования Свисты — отнюдь не идеальная абстракция, а будущая суровая реальность 🙂 Не с потолка же они взяты. такое ощущение, что у MS-программеров и (sizeof(byte)==8) является отныне непреложной истиной.

Источник

Оцените статью