LINUX.ORG.RU
ФорумTalks

[LKML] FatELF - аргументы за и против


0

0

Как обычно, в LKML началась дискуссия по поводу добавления FatELF в ядро. Райан Гордон показал основные преимущества, которые должна дать поддержка FatELF:

  • Distributions no longer need to have separate downloads for various platforms. Given enough disc space, there's no reason you couldn't have one DVD .iso that installs an x86-64, x86, PowerPC, SPARC, and MIPS system, doing the right thing at boot time. You can remove all the confusing text from your website about «which installer is right for me?»
  • You no longer need to have separate /lib, /lib32, and /lib64 trees.
  • Third party packagers no longer have to publish multiple .deb/.rpm/etc for different architectures. Installers like MojoSetup benefit, too.
  • A download that is largely data and not executable code, such as a large video game, doesn't need to use disproportionate amounts of disk space and bandwidth to supply builds for multiple architectures. Just supply one, with a slightly larger binary with the otherwise unchanged hundreds of megabytes of data.
  • You no longer need to use shell scripts and flakey logic to pick the right binary and libraries to load. Just run it, the system chooses the best one to run.
  • The ELF OSABI for your system changes someday? You can still support your legacy users.
  • Ship a single shared library that provides bindings for a scripting language and not have to worry about whether the scripting language itself is built for the same architecture as your bindings.
  • Ship web browser plugins that work out of the box with multiple platforms.
  • Ship kernel drivers for multiple processors in one file.
  • Transition to a new architecture in incremental steps.
  • Support 64-bit and 32-bit compatibility binaries in one file.
  • No more ia32 compatibility libraries! Even if your distro doesn't make a complete set of FatELF binaries available, they can still provide it for the handful of packages you need for 99% of 32-bit apps you want to run on a 64-bit system.
  • Have a CPU that can handle different byte orders? Ship one binary that satisfies all configurations!
  • Ship one file that works across Linux and FreeBSD (without a platform compatibility layer on either of them).
  • One hard drive partition can be booted on different machines with different CPU architectures, for development and experimentation. Same root file system, different kernel and CPU architecture.
  • Prepare your app on a USB stick for sneakernet, know it'll work on whatever Linux box you are likely to plug it into.
  • Prepare your app on a network share, know it will work with all the workstations on your LAN.

Алан Кокс не согласился с доводами Райана Гордона и разобрал всё по пунктам:

От: 	Alan Cox <alan@lxorguk.ukuu.org.uk>
Кому: 	Ryan C. Gordon <icculus@icculus.org>
Копия: 	Måns Rullgård <mans@mansr.com>, linux-kernel@vger.kernel.org
Тема: 	Re: FatELF patches...
Дата: 	Mon, 2 Nov 2009 00:01:47 +0000 (05:01 YEKT)


Lets go down the list of "benefits"

- Separate downloads
        - Doesn't work. The network usage would increase dramatically
          pulling all sorts of unneeded crap.
        - Already solved by having a packaging system (in fact FatELF is
          basically obsoleted by packaging tools)

- Separate lib, lib32, lib64
        - So you have one file with 3 files in it rather than three files
          with one file in them. Directories were invented for a reason
        - Makes updates bigger
        - Stops users only having 32bit libs for some packages

- Third party packagers no longer have to publish multiple rpm/deb etc
        - By vastly increasing download size
        - By making updates vastly bigger
        - Assumes data files are not dependant on binary (often not true)
        - And is irrelevant really because 90% or more of the cost is
          testing

- You no longer need to use shell scripts and flakey logic to pick the
  right binary ...
        - Since the 1990s we've used package managers to do that instead.
          I just type "yum install bzflag", the rest is done for me.

- The ELF OSABI for your system changes someday?
        - We already handle that

- Ship a single shared library that provides bindings for a scripting
  language and not have to worry about whether the scripting language
  itself is built for the same architecture as your bindings. 
        - Except if they don't overlap it won't run

- Ship web browser plugins that work out of the box with multiple
  platforms.
        - yum install just works, and there is a search path in firefox
          etc

- Ship kernel drivers for multiple processors in one file.
        - Not useful see separate downloads

- Transition to a new architecture in incremental steps. 
        - IFF the CPU supports both old and new
        - and we can already do that

- Support 64-bit and 32-bit compatibility binaries in one file. 
        - Not useful as we've already seen

- No more ia32 compatibility libraries! Even if your distro
  doesn't make a complete set of FatELF binaries available, they can
  still provide it for the handful of packages you need for 99% of 32-bit
  apps you want to run on a 64-bit system. 

        - Argument against FatELF - why waste the disk space if its rare ?

- Have a CPU that can handle different byte orders? Ship one binary that
  satisfies all configurations!

        - Variant of the distribution "advantage" - same problem - its
          better to have two files, its all about testing anyway

- Ship one file that works across Linux and FreeBSD (without a platform
  compatibility layer on either of them). 

        - Ditto

- One hard drive partition can be booted on different machines with
  different CPU architectures, for development and experimentation. Same
  root file system, different kernel and CPU architecture. 

        - Now we are getting desperate.

- Prepare your app on a USB stick for sneakernet, know it'll work on
  whatever Linux box you are likely to plug it into.

        - No I don't because of the dependancies, architecture ordering
          of data files, lack of testing on each platform and the fact
          architecture isn't sufficient to define a platform

- Prepare your app on a network share, know it will work with all
  the workstations on your LAN. 

        - Variant of the distribution idea, again better to have multiple
          files for updating and management, need to deal with
          dependancies etc. Waste of storage space.
        - We have search paths, multiple mount points etc.

So why exactly do we want FatELF. It was obsoleted in the early 1990s
when architecture handling was introduced into package managers.

Stay tuned!

Deleted

[LKML] FatELF - аргументы за и против

Мне больше понравится уменьшение размера системы. Это было бы жутко полезно для скоростных флэшек и встраиваемых устройств.

И услиление безопасности, нежели расширение возможностей для троянописателей.

nyaka ()

[LKML] FatELF - аргументы за и против

жирный эльф как концепт интересен, но очень сомнителен в практическом применении

Suicide_inc ★★ ()

[LKML] FatELF - аргументы за и против

Говорил же я Райану - юзерспейсный загрузчик FatELF нужен, а не в ядро его пихать... Что ж. Если он неудачу потерпит, буду его донимать, чтобы юзерспецсный загрузчик сделал. Если FatELF окажется удачной технологией и привлечёт игрописателей - будет только хорошо.

Quasar ★★★★★ ()

[LKML] FatELF - аргументы за и против

А как насчет скорости компиляции?

mutronix ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от mutronix

[LKML] FatELF - аргументы за и против

Логично, что возрастает в кол-во раз, сколько платформ нужно

я не думаю что GCC скоро научится генерить машиный код в разные платформы сразу

namezys ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>FatELF
>удачной технологией

/0

>привлечёт игрописателей

Чем? Что до этого надо было уметь писать хороший портируемый код, а не быдлокод, что с FatELF. Чтобы завернуть два блоба в один особого ума не надо.

anotheranonymous ()
Ответ на: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>и привлечёт игрописателей
И да, на винде вроде же ничего подобного нет, почему это не отпугивает игрописателей? Не в ту сторону ты смотришь.

anotheranonymous ()
Ответ на: [LKML] FatELF - аргументы за и против от mutronix

Re: [LKML] FatELF - аргументы за и против

mutronix> А как насчет скорости компиляции?

Собираем бинарники под разные архитектуры, и склеиваем специальной утилитой, которая разрабатывается в рамках проекта FatELF.

Quasar ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

Re: [LKML] FatELF - аргументы за и против

anotheranonymous> Чем? Что до этого надо было уметь писать хороший портируемый код, а не быдлокод, что с FatELF. Чтобы завернуть два блоба в один особого ума не надо.

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

Quasar ★★★★★ ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>Чтобы не делать кучу дистрибутивов игры, а сделать один, и засунуть на диск. Разве будет не лучше купить в магазине диск с игрой, и не париться о том, заработает она на линуксе или нет, и при этом не париться о поддерживаемых дистрибутивах?
И сейчас никто не парится. Статическая компиляция решает проблему отстутствия библиотек. А два бинарника вместо одного не так уж и страшно, виндовые игрушки именно так и делают. Повторюсь, это не проблема для игрописателей, если ты думаешь, что игрушки не пишут по этому поводу, то ты глубоко заблуждаешься.

anotheranonymous ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

[LKML] FatELF - аргументы за и против

anotheranonymous> И да, на винде вроде же ничего подобного нет, почему это не отпугивает игрописателей?

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

Ну и посмотрим вот на что: Допустим, линукс отжуёт 20% рынка домашних компьютеров в ближайшие 2-3 года. И что? Начнёт делать игры и под линукс, а также официально поддерживать. Будут игры под линукс + венду. Разве это намного лучше? А если на солярке захотят поиграть? А если на другой ОС? Что тогда? Плодить кучу дистрибутивов игры? Не проще ли в рамках FatELF делать один дистрибутив для всего?

Quasar ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

Re: [LKML] FatELF - аргументы за и против

anotheranonymous> И сейчас никто не парится. Статическая компиляция решает проблему отстутствия библиотек. А два бинарника вместо одного не так уж и страшно, виндовые игрушки именно так и делают.

1. Вендовые игрушки скомпилированы не статически - они библиотеки с собой таскают.

2. Недостаток помещения кучи бинарников уже обсуждался в предыдущей новости о FatELF. И было доказано, что это недостаток, и что uname + скрипты этот недостаток только усугубляют.

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

Почему не пишут игры - Райан уже писал, причём из личного опыта. См. новости по тегу "игры". А FatELF призван облегчить _распространение_ (заметь - не написание) игр. Отказываться от такого преимущества даже в виде юзерспейсного загрузчика очень глупо. Ну и если кто-то захочет вырвать нужный бинарник - у него есть возможность воспользоваться консольной утилитой (только не надо о том, что обычный юзер захочет это сделать - он вообще не знает, что такое FatELF, либо ему пофиг на это: работает, и ладно.).

Quasar ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>А если на солярке захотят поиграть? А если на другой ОС? Что тогда? Плодить кучу дистрибутивов игры? Не проще ли в рамках FatELF делать один дистрибутив для всего?
Не вижу кучи дистрибутивов. Архив с каталогом data, который платформонезависим и n-бинарей, где n-количество платформ. Ты выдумываешь проблемы, которых у них нет. Есть проблема написать код, который будет собираться под эти все платформы, на который нужно потратить деньги.

anotheranonymous ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

Re: [LKML] FatELF - аргументы за и против

>Посмотрите на mac os x, где это работает хорошо и прямо

mac os x поддерживает две с половиной архитектуры, причём одну из них они уже выкидывают.

dn2010 ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

Re: [LKML] FatELF - аргументы за и против

anotheranonymous> Не вижу кучи дистрибутивов. Архив с каталогом data, который платформонезависим и n-бинарей, где n-количество платформ .Ты выдумываешь проблемы, которых у них нет.

Пользователь обязан искать среди кучи юинарей нужный? Или ты предлагаешь делать спецверсии дистрибутивов игр для гиков? Не надо утверждать, что проблема надуманная - она реальная. В том же Cube её попытались решить скриптами. Решили, но временно. Почему проблема осталась - читай комментарии к предыдущей новости про FatELF.

anotheranonymous> Есть проблема написать код, который будет собираться под эти все платформы, на который нужно потратить деньги.

Повторяю: речь идёт _не о написании кода, а о распространении игры_. Не строй из себя имбецила.

Quasar ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

[LKML] FatELF - аргументы за и против

Мы, конечно, ещё нифига не сделали... но собрать пару библиотек(Ogre, Bullet, pathFinder и пару своих) под несколько платформ - не проблема. Всё остальное, как ты подметил, платформонезависимо.

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

nyaka ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от dn2010

Re: [LKML] FatELF - аргументы за и против

> mac os x поддерживает две с половиной архитектуры, причём одну из них они уже выкидывают.

пять: ppc, ppc64, x86, x86_64, arm

2 штуки уже было достаточно, чтоб создать единый контейнер

namezys ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

В mac os x - 2 платформы (power/intel), только две и ни одной больше. Линукс сильно портируемый, в отличие от.
Ненужно.

nbdarvin ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

>Посмотрите на mac os x, где это работает хорошо и прямо

в макосе это не фича, а вынужденный костыль.

nu11 ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от nu11

[LKML] FatELF - аргументы за и против

> в макосе это не фича, а вынужденный костыль.

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

> снежный барс работает ровно на одной архитектуре.

Снежный барс работает как на x86, так и на x86_64. При этом не зависимо от того, какое ядро, приложение может быть запущено в одном из этих 2 режимах

namezys ★★★★ ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>В том же Cube её попытались решить скриптами. Решили, но временно. Почему проблема осталась - читай комментарии к предыдущей новости про FatELF.

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

nu11 ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

С привязкой к конкретному оборудованию как в макоси фат-бинарники удобней и полезней. Не возникнет ситуации, когда пользователь Macosx@SPARC какой нибудь войдет в ступор изза отсутсвия блоба под свою платформу в фат-бинарнике )

nbdarvin ()
Ответ на: [LKML] FatELF - аргументы за и против от nbdarvin

[LKML] FatELF - аргументы за и против

> Не возникнет ситуации, когда пользователь Macosx@SPARC какой нибудь войдет в ступор изза отсутсвия блоба под свою платформу в фат-бинарнике )

Тоже вопрос двоякий. Мне правда кажеться что мире linux'а бинарники вообще вещь сложная... хотя бы потому что где что лежит не ясно

с другой стороны это было бы очень полезно в процессе перехода на 64 бита

namezys ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

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

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

>Снежный барс работает как на x86, так и на x86_64


джобс с ним, пусть будет две. Но никак не пять.

nu11 ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от nu11

[LKML] FatELF - аргументы за и против

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

В мак оси пользователи не когда не выбирают бинарников. Имхо это более важно для библиотек и взаимодействий. Но опять же при переходе (кстати, а какие аргументы были против совмещение библиотек вместе)?

namezys ★★★★ ()

[LKML] FatELF - аргументы за и против

а нафига для игр делать сборки под процессоры отличные от x86? У меня вот сейчас установлена neverwinter nights и таки работает, что на Дебиане, что на Слаке, все библиотеки в каталоге с игрой

cuki ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от cuki

[LKML] FatELF - аргументы за и против

а нафига для игр делать сборки под процессоры отличные от x86?

Встречный вопрос: а нафига делать сборки игр под x86?

Deleted ()
Ответ на: [LKML] FatELF - аргументы за и против от Deleted

Re: [LKML] FatELF - аргументы за и против

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

cuki ★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

Re: [LKML] FatELF - аргументы за и против

>Мне правда кажеться что мире linux'а бинарники вообще вещь сложная... хотя бы потому что где что лежит не ясно

Ниасилил man hier?

srj ★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от cuki

[LKML] FatELF - аргументы за и против

> а нафига для игр делать сборки под процессоры отличные от x86?

Потому что некоторым играм может не хватать 2-3-4 ГБ памяти, которые можно выделить в 32-битном процессе.

Relan ★★★★★ ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от Quasar

[LKML] FatELF - аргументы за и против

>1. Вендовые игрушки скомпилированы не статически - они библиотеки с собой таскают.
Пусть так, и в линуксе так можно

>2. Недостаток помещения кучи бинарников уже обсуждался в предыдущей новости о FatELF.

Не читал, не вижу пока недостатка. Не надо мне никаких скриптов я сделаю ./foo-$my_arch

>А FatELF призван облегчить _распространение_ (заметь - не написание) игр.

Не будет никакого облегчения, будет никому не нужное увеличение раздела /usr в количество раз равное количеству архитектур и бардак с тем, кто и под какие архитектуры блобы запихнет в этот жирныйэльф. А если это только ради игр. То это тем более не нужно.

>либо ему пофиг на это: работает, и ладно

Внезапно! Поставил макоюзер на свой старенький ppc-мак какой нибудь дебиан. Скачал какой нибудь жирный-эльф с игрушкой, а она не запускается. Ничего не работает. Тупо нету там ppc внутри. Ну и где профит?

anotheranonymous ()
Ответ на: [LKML] FatELF - аргументы за и против от nu11

[LKML] FatELF - аргументы за и против

>>Снежный барс работает как на x86, так и на x86_64

>джобс с ним, пусть будет две. Но никак не пять.

Сторонние приложения часто поддерживают 3, а то и 4 архитектуры, потому что Leopard будет поддерживаться еще несколько лет, а он работает и на PPC тоже.

Relan ★★★★★ ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от cuki

[LKML] FatELF - аргументы за и против

>затем, что на сегодняшний момент у подоляющего большинства процессоров персональных компьютеров, находящихся на руках у пользователей, эта архитектура?
Что за 4.2? Где статистика? То что глупые юзвери себе ставят операционку x86 не обязательно означает, что у них проц x86, а скорее всего подтверждает, что они глупые.

anotheranonymous ()

Решение несуществующей проблемы.

Что вы прицепились к этому "распространению сферических игр в вакууме"? ПО должно устанавливаться package manager'ом. Игроделы не осиливают упаковку своих поделий в deb и создание репозитариев -- в топку таких игроделов. FatELF перекладывание проблем с больной головы на здоровую. Никакие игры вообще не должны скачиваться с сайтов в виде бинарников, которые хрен знает куда потом совать. На сайте должна быть кнопка, которая запускает соответствующую функцию package manager'а, который сам скачает нужный архив, сам скачает распакует его, сам разложит по полочкам бинарники. А если игра на диске, то там пусть autorun.inf (утрирую) пусть запускает установку.

Camel ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от cuki

Re: [LKML] FatELF - аргументы за и против

>>а нафига для игр делать сборки под процессоры отличные от x86?

ох, х86_64 конечно же)

cuki ★★★★ ()
Ответ на: Re: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

>А вот где в любом линухе будет лежать qt последней версии....? /usr или /usr/local?
Окстись. В /usr/local никогда ничего не лежало, кроме того, что туда пользователь сам положил.

anotheranonymous ()

[LKML] FatELF - аргументы за и против

>So why exactly do we want FatELF. It was obsoleted in the early 1990s

+1000

fatELF не нужен. Вот в Plan9 это севершенно по иному решили. :) изящно и красиво. А не .... так ужасно.

robot12 ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от namezys

[LKML] FatELF - аргументы за и против

>Посмотрите на mac os x

Это про Rosetta? Ну так им ПРИШЛОСЬ это сделать. Иначе они бы пролетели с переходом на x86

devl547 ★★★★★ ()

[LKML] FatELF - аргументы за и против

Идея FatELF, созданного на волне Universal Binary от Apple в Линуксе нежизнеспособна. Ибо в Маке это был уровень совместимости между PPC и x86 архитектурами, где размер скачиваемого бандла приносился в жертву во имя глупости типичного Мак-юзера, неспособного выбрать для скачиваемой программы нужную платформу. Это схема Apple, для которого 100% софта скачивается кликаньем по ссылкам в браузере, естественно они пошли навстречу своим потенциальным потребителям.

В Линуксе чуть меньше чем 100% софта ставится из репозиториев. А что не ставится - должно ставиться. Здесь абсолютное большинство пользователей ограждены от проблемы изначально.

Но самое главное преимущество Universal Binary - что в нём на уровне дизайна определены конкретные платформы. Скачивая такой блоб пользователь OSX уверен что он запустится на его Маке. В Линуксе же, как верно заметил Кокс, платформа не определяется одной лишь архитектурой, а следовательно: или пихать в бинарь 1001 вариант кода под всевозможные платформы или пользователь никогда не будет уверен что бинарь поддерживает конкретно его платформу. Второй случай реальнее, а значит пользователю всё равно прийдётся читать описание есть ли поддержка его платформы или нет, что исключает случай "глупого" пользователя, который ничего читать не собирается, а сразу кликает большую зелёную кнопку "Download".

Dendy ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

[LKML] FatELF - аргументы за и против

>Что до этого надо было уметь писать хороший портируемый код, а не быдлокод, что с FatELF

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

Gary ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от anotheranonymous

[LKML] FatELF - аргументы за и против

>И да, на винде вроде же ничего подобного нет

Потому что на винде только одна архитектура и, грубо говоря, только одна версия ОС?

Gary ★★★★★ ()
Ответ на: [LKML] FatELF - аргументы за и против от devl547

Re: [LKML] FatELF - аргументы за и против

> Это про Rosetta? Ну так им ПРИШЛОСЬ это сделать. Иначе они бы пролетели с переходом на x86

Нет. про то что у них файлы могут хранить сразу какой угодно кол-во архитектур

namezys ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.