Поддержка FatELF в ядре

>Да уж, мозгами тебя природа похоже обделила.

90% работы за мантейнеров сейчас выполняют билдсервисы

> Если автор скрипта в 1998-м году не предусмотрел запуск своей 32-битной программы на "x86_64", скрипт тоже не сработает, хотя бинарник полностью работоспособен.

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

Этот ваш FatELF — явный соботаж.

>Смеялся весь. Это выходит, что автор в 98-м году должен был предусмотреть появление жирного эльфа и ещё не существующей x86_64 архитектуры.

Нет. Но авторы современных программ смогут все закатать в жирный эльф. И тогда через несколько лет, когда появится архитектура типа x86_128, пускалка жирного эльфа в ядре будет на этой архитектуре спокойно вынимать из FatELF и запускать бинарники x64, если не найдет там версии для x128. А автору не придется быть Вангой.

s/соботаж/саботаж

ррр

>Этот ваш FatELF — явный соботаж.

Ещё один лауреат конкурса "Самый толстый" :)

Вот фантазёр. Никакого x86_128 не будет, даже не надейтесь.

> И тогда через несколько лет, когда появится архитектура типа x86_128, пускалка жирного эльфа в ядре будет на этой архитектуре спокойно вынимать из FatELF и запускать бинарники x64, если не найдет там версии для x128.

Всё же какая-то сущность тут явно лишняя, не находите?

> А почему бы и нет? Скрипты-то тривиальные.

Тред не читал, да?

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

Весь прочитал, много смеялся)

На опеннете отдельные уникумы предлагают пихать ЭТО в embeded

>так это обычно и бывает

Так это обычно и есть, по диску на каждую архитектуру. А с fatelf этого можно избежать. Это написано в первом посте.

Стоп. А накой пихать на диск интерпритатор?

Кстати, про серверы возражений не было.

>Зачем переустанавливать? Их можно по-месту пострипать

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

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

Во-первых, они как лежали на своих местах, так и будут лежать, а во-вторых, пакетный менеджер этим и займётся. pkcon strip-arch и всего делоа.

>Права для /opt/whatever не осилить никак? Ну а вообще в хомяк действительно кладётся многая проприетарщина, как ни крути.

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

>Во-первых, они как лежали на своих местах, так и будут лежать

А супротив этого я и не спорил :)

>пакетный менеджер этим и займётся. pkcon strip-arch и всего делоа.

Из-за мифических плюсов столько приседаний.

>Кстати, технология крайне удобна для постепенной миграции с одной архитектуры на другую. Поставили всё в толстых бинарниках, выключились, поменяли проц, мамку, память...

fixed

>Если бы вы были чуть более глубоко погружены в тему, то знали бы, что это отнюдь не "неизвестно откуда взязвшаяся 1". Пример - libusb и libusb1. Но вы, уж извините, чайник :-)

Не помню чтобы речь шла о "откуда взялись эти единички и прочие"... вы высказались что:

>1. библиотеки именуются одинаково, иначе это разные библиотеки

что является неверным утверждением в ряде случаев. разумеется библиотеки которые изменены подобным образом в названии имеют более радикальные отличия внутри, но это та же библиотека. и притянута под (условно) тот же функционал.

откуда оно берется тоже прекрасно понятно, но перелинковывать чуть, что не мифическому сборщику, а мне.

Не судите и вас не осудят.

>>1. библиотеки именуются одинаково, иначе это разные библиотеки
> что является неверным утверждением в ряде случаев. разумеется библиотеки которые изменены подобным образом в названии имеют более радикальные отличия внутри, но это та же библиотека. и притянута под (условно) тот же функционал.

А я скажу даже так: библиотеки с одним ABI именуются одинаково, иначе это библиотеки с разным ABI.
Кто куда притянут, под какой функционал? О чём речь вообще?

>Да. Потому что очень редкие пакеты содержат ТОЛЬКО бинарники.
Во-первых это проблема пакетов, политики и т.д., но никак не тонких бинарников.

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

>В source.list подключены три репозитария: x86_64, noarch и x86_XX. Максимальный приоритет - у первого. Из x86_XX пакеты будут устанавливаться, только если потребуется соответствующая зависимость. Т.о.

>apt-get install skype

>Совершенно прозрачно для пользователя установит соотв. пакет и обновит необходимые библиотеки до 64/32 meltiarch варианта.

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

>Чушь какая. Просвещайтесь: >http://www.opensolaris.org/os/community/advocacy/articles/solaris-linux-freebsd/
>
>"Solaris has its basis in a combination of BSD Unix and AT&T Bell Labs Unix."
>
>В мире открытого кода писать ось с нуля это идиотизм и никто так не делает. В
>мире закрытого кода кстати тоже, только одни открыто об этом заявляют (Apple
>например) а другие скромно молчат глаза потупив (Microsoft). Да и зачем каждый
>раз Америку открывать? Дорого это, хлопотно и абсолютно бессмысленно.
>A-234 * (*) (24.10.2009 10:27:52)

Где чушь? Всё правильно. Есть BSD UNIX, есть UNIX от AT&T (SystemV и др.), почитайте историю, дистрибутивы BSD перестали содержать код аж с апреля 1980-ого года, когда выпустили версию 2.79BSD весь код, который принадлежал компании AT&T был удалён. Читайте: http://minnie.tuhs.org/Unix_History/2bsd

Solaris - это UNIX, OpenSolaris - это свободная реализация (компания Sun Microsystems открывает код операционной системы Sun Solaris, вносит изменения и публикует как OpenSolaris), так как эта система не прошла сертификацию, она не является UNIX.

Насчёт Microsoft, они ничего не воровали, тот же стек протоколов TCP/IP они взяли из BSD, лицензия BSD не запрещает брать их наработки, закрывать код и продавать за деньги. Никакого воровства нет.

Насчёт копирования чужого кода, охраняемого авторским правом - вы так говорите, будто присутствовали и свечку держали, когда происходило копирование чужого кода. Смехота!

x86 прекрасно эмулируется на ia64. Обработайте :)

Райан забывает, что его патч для ядра сначала должен принять Линус, а потом и все дистрибутивы на которых он игры свои тестирует. С таким же успехом можно попросить дистрибутивы устанавливать его юзерспейсную запускалку для толстого эльфа. _Его_ проблема решается именно таким образом проще чем засовывание толстого эльфа в ядро. Но Райан решил пойти дальше и сделать либы с толстым эльфом, которые на самом деле не нужны.

Пропоненты толстого эльфа все как один в его поддержку приводят аргументы к нему не относящиеся. Обновление было одним из них.

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

>Ага, ещё игры обновлять регулярно менеджером пакетов, не лопнешь?

Твой ведь аргумент, или ты забыл?

>Зачем простому пользователю для выполнения давать права на запись/перезапись бинарей? Вендовые привычки оставьте в венде, пожалуйста.

Вы никогда о suid/sgid не слышали?

С fatelf можно будет постовлять для обновления один бинарик, вместо скриптов

>Стоп. А накой пихать на диск интерпритатор?

А как Вы интерпретировать собрались всю лабуду на диске, если с него загружаетесь?

Зря смеялся. Если через пяток лет появится какая-то ARM64, то инсталлер Райана, основанный на FatELF будет и дальше работать (при условии, что ядро понимает формат), тогда как написанный на шелле не будет. ИМХО, проблема точно также решается изменением uname и всего связанного так, чтобы оно еще выдавало и совместимые архитектуры.

> Учи матчасть: ещё в середине 90-ых на спарках можно было установить PCI-карточку с AMD i386 CPU - для нативного висполнения x86-кода

Можно-то оно можно было, но это была система-на-PCI-карте, со своими процессором, памятью и устройствами ввода-вывода. И ОС там тоже своя работала, отдельная от Solaris'а, который трудился на хосте. Они, конечно, взаимодействовали (например, своего жесткого диска у платы не было), но не так, чтобы в одном адресном пространстве исполняться.

SUID/SGID на несистемном бинарнике с целью дать ему возможность писать _вообще_ везде? Это шутка такая, да?

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

>SUID/SGID на несистемном бинарнике с целью дать ему возможность писать _вообще_ везде? Это шутка такая, да?

Ты вообще знаешь как права работают в линуксовых файловых системах?

>>Да. Потому что очень редкие пакеты содержат ТОЛЬКО бинарники.
>Во-первых это проблема пакетов, политики и т.д., но никак не тонких бинарников.

>А во-вторых, ты в любом случае собрался подключать репозиторий с _дополнительными_ пакетами. Что тебе мешает сделать новые пакеты чисто бинарными?

Это глупо. Придётся статически компоновать программы/библиотеки в пакете со всеми из зависимостями.

А, не уловил мысли. Думал ты предлагаешь вместо изменения прав на /opt. Тогда претензия снимается.

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

Какую "юзерспейсную запускалку" ты предлагаешь для *.so-шек?

Поинтересуйтесь с какой степень кривости реализован биарч на уровне пакетов в дистрибутивах: в RedHat/Fedora, SuSe, Debian, ALTLinux, etc. Везде - по разному, но везде - это ворох костылей с разной степенью кривости.

> _Его_ проблема решается именно таким образом проще чем засовывание толстого эльфа в ядро. Но Райан решил пойти дальше и сделать либы с толстым эльфом, которые на самом деле не нужны.

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

Не понял. Ты сейчас предложил компоновать 32битные приложения с 64битными библиотеками, да еще и статически?

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

Нет. Это те же пакеты, только с другой архитектурой. Вернее, предоставляющие две архитектуры.

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

Рекомендую попрактиковаться:) "Так же прозрачно" в большинстве случаев не получится из-за конфликтов перекрывающихся не-ELF файлов в 32-битных и 64-битных одноимённых пакетах.

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

>Можно-то оно можно было, но это была система-на-PCI-карте, со своими процессором, памятью и устройствами ввода-вывода. И ОС там тоже своя работала, отдельная от Solaris'а, который трудился на хосте. Они, конечно, взаимодействовали (например, своего жесткого диска у платы не было), но не так, чтобы в одном адресном пространстве исполняться.

А кто говорил об "общем адресном пространстве" для x86_64 и ARM'а?

> glibc-common.noarch, glibc.i686, glibc.x86_64;

> xorg-x11-fonts.noarch, xorg-x11-server.i686, xorg-x11-server.x86_64

> Намек понятен?

Спасибо, уважаемый КО:)

Я только обеими руками "ЗА"! Но на практике это не так просто, как на словах:)

>Какую "юзерспейсную запускалку" ты предлагаешь для *.so-шек?
толстые so не нужны.

>Везде - по разному, но везде - это ворох костылей с разной степенью кривости.
Поэтому ты предлагаешь вместо исправления существующих костылей создавать новые?

>в работающей системе, скорее всего, исполняемые FATELF-бинарники врядли понадобятся
Хоть в чем-то мы согласны. А либам оно не нужно. То что проблемы либ изначально были решены путем создания хаков, не делает новый хак более нужным. Собственно в дебиане уже начали разруливать те проблемы, которые были внедрены их "решением".

>Рекомендую попрактиковаться:) "Так же прозрачно" в большинстве случаев не получится из-за конфликтов перекрывающихся не-ELF файлов в 32-битных и 64-битных одноимённых пакетах.
Проблема политики, которую ты хочешь решить путем внедрения нового формата.

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

> Не понял. Ты сейчас предложил компоновать 32битные приложения с 64битными библиотеками, да еще и статически?
Я думал, ты это предложил.

"Чисто бинарный пакет" - это пакет, в котором только исполняемый файл? Или я не понял?
Потому что если я понял, получается страшно. Например, libcdio:
/usr/bin/cd-drive
/usr/bin/cd-info
/usr/bin/cd-read
/usr/bin/cdda-player
/usr/bin/iso-info
/usr/bin/iso-read
/usr/bin/libcdio-paranoia
/usr/bin/mmc-tool
/usr/lib64/libcdio++.so
/usr/lib64/libcdio.so
/usr/lib64/libcdio_cdda.so
/usr/lib64/libcdio_paranoia.so
/usr/lib64/libiso9660++.so
/usr/lib64/libiso9660.so
/usr/lib64/libudf.so
Грубо говоря. На самом деле, там оно чуть-чуть не так.

ldd `which mplayer` | grep libcdio
libcdio_cdda.so.0 => /usr/lib/libcdio_cdda.so.0 (0x00007f3c010f6000)
libcdio_paranoia.so.0 => /usr/lib/libcdio_paranoia.so.0 (0x00007f3c00eee000)
libcdio.so.7 => /usr/lib/libcdio.so.7 (0x00007f3bfe838000)

Как ты себе представляешь содержимое пакета mplayer, если в пакете libcdio будет только некий multy-binary, без .so?

> Если через пяток лет появится какая-то ARM64, то инсталлер Райана, основанный на FatELF будет и дальше работать

Инсталлер будет, а программа? И да, пакетная система / порты куда гибче чем какой-то там бинарный инсталлер.

А, ну если смотреть с такой стороны.
Только давайте каждому собравшему ядро с такой опцией 2 модельки Гандамов на выбор в подарок, и полную DVD-коллекцию всех ТВ-сезонов ?

> Инсталлер будет, а программа?
Очевидно, работать будут оба.

> И да, пакетная система / порты куда гибче чем какой-то там бинарный инсталлер.
"Случаи разные бывают."
Если программа (игра?) собирается один раз и на всю жизнь, мейнтейнерам дистрибутива незачем вешать себе на шею ещё один объект поддержки.
Если программа (игра?) обновляется два раза в день, у мейнтейнеров не останется другого занятия, кроме как следить за тем, чтобы в репозитории всегда была последняя версия. И нагрузка на сервер с репозиторием заметно возрастёт. Путь уж лучше у разработчиков программы голова об этом болит.

Т.е. бинарник собранный под чёрте какую забытую архитектуру чудесным образом заработает на новой? Отсыпьте.

> Т.е. бинарник собранный под чёрте какую забытую архитектуру чудесным образом заработает на новой? Отсыпьте.
Бинарник, собранный для x86, заработает на x86_64 при условии, что в системе будут необходимые библиотеки тоже для x86, или что он будет статически собран с ними. На x86_128 он тоже должен заработать. Вопросы?

Один или несколько. То есть noarch отделено от остального.