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

А программа может работать если обратную совместимость и ОС и процессор поддерживают.

>Если программа (игра?) собирается один раз и на всю жизнь, мейнтейнерам дистрибутива незачем вешать себе на шею ещё один объект поддержки.
>Если программа (игра?) обновляется два раза в день, у мейнтейнеров не останется другого занятия, кроме как следить за тем, чтобы в репозитории всегда была последняя версия.
Не знаю как об этом сообщить... вообще-то /etc/apt/sources.list можно изменять. Честно-честно! :)

> Один или несколько. То есть noarch отделено от остального.
noarch в пакете - это README, AUTHORS и LICENSE. Всё остальное, как ни странно, "arch". Ну да, ещё иконки для кнопок.
Я спрашивал о том, видишь ли ты .so в этом гипотетическом пакете. Ну так как?

> Более того, я, как пользователь Федоры, ... Но! Эта фича вполне может быть к месту в юзер-ориентированных дистрибутивах.

Я знал!

> Не знаю как об этом сообщить... вообще-то /etc/apt/sources.list можно изменять. Честно-честно! :)
Это не решает проблему.
Почему иметь некоторые программы в репозиториях дистрибутивов неудобно для мейнтейнеров дистрибутивов, я уже объяснил.
Надо объяснять, почему иметь репозитории для всех распространённых дистрибутивов может быть неудобно разработчику программы?
Инсталлятор здесь - компромиссное решение, хотя у него полно своих недостатков.

> Вопросы?

Ваши показания путаются, но завести следствие в тупик вам не удалось.

> Бинарник, собранный для x86, заработает на x86_64

Да, но не заработает

> Если через пяток лет появится какая-то ARM64

О чём, собственно, и шла речь.

Далее, зачем вообще нужен этот fatelf если х86-бинарник работает на х86_64? На этом несуразицы не заканчиваются. Кто вообще пишет программы так чтоб они работали ещё 10 лет и не требовалось никакой поддержки? API ядра не меняется? А с glibc что? Получаем какую-то статично собранную ерунду, которую завести без патченья ядра всё равно не удастся.

>> Бинарник, собранный для x86, заработает на x86_64
> Да, но не заработает
Запусти и проверь.

>> Если через пяток лет появится какая-то ARM64
> О чём, собственно, и шла речь.
Не понял, эти слова мне приписываются?
Всё равно отвечу. Если через пяток лет появится ARM64, и она будет обратно совместима, код, написанный сейчас, будет на ней работать, как на x86_64 работает x86.

> Далее, зачем вообще нужен этот fatelf если х86-бинарник работает на х86_64?
Каша в голове? Он нужен, чтобы получить бинарник, который будет (1) работать на разных платформах, (2) выбор нужного ELF'а для нужной платформы производился не скриптом, а системой, автоматически, и (3) если в FatELF'е не окажется кода точь-в-точь для нужной платформы, но окажется код, совместимый с платформой хост-системы, он всё равно будет загружен. Бинарник для x86 работает на x86_64, но сам же он не запустится, правда? И не факт, что скрипт из обсуждения выше его запустит.

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

> API ядра не меняется?
?! Причём здесь это?

> А с glibc что?
Что? Прототип strncmp() изменился за 10 лет?

> Получаем какую-то статично собранную ерунду, которую завести без патченья ядра всё равно не удастся.

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

>> Бинарник, собранный для x86, заработает на x86_64
> Да, но не заработает

Поясни, о премудрый, ибо недоступны для моего понимания слова твои.

>Далее, зачем вообще нужен этот fatelf если х86-бинарник работает на х86_64?

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

>Кто вообще пишет программы так чтоб они работали ещё 10 лет и не требовалось никакой поддержки?

Хорошие программисты.

Надо сказать, проприетарщики по оффтопиком в этом преуспели более, чем opensource-девелоперы по линухом: они не могут надеяться, что юзеры их исходники пересоберут. Бывают, конечно, еще гнилые проприетарщики, встраивающие в поделия всякие старфорсы, и "кулхацкерные", лезущие куда не надо, а оттого теряющие обратную совместимость, но в целом прикладные проги живут в бинарном виде долго.

> Кто вообще пишет программы так чтоб они работали ещё 10 лет и не требовалось никакой поддержки?

Троллить-то заканчивай, а?

> Надо сказать, проприетарщики по оффтопиком в этом преуспели более, чем opensource-девелоперы по линухом

Да ладно, я всегда привожу в пример надпись после загрузки FreeBSD в консоли, точную я её, правда, забыл, но смысл таков: Ⓒ 1981,1984,1988 Regents of university of California.

Года не помню, но что первый — 1981, это точно. Ну то есть коду 28 лет, и ничего, пашет ;)

Это здорово, но автор-то спрашивал про "вообще без никакой поддержки". Вы же не прямо код 1981 года компилируете и запускаете.

Теоретически при наличии POSIX совместимого софта и POSIX совместимой ОС это тоже возможно, но это реже да. Да и в виндах не всё так гладко, многие вещи для Win95 уже не будут работать, а win3.11 из висты вон вообще выкинули.

>> Кто вообще пишет программы так чтоб они работали ещё 10 лет и не требовалось никакой поддержки?

> Троллить-то заканчивай, а?

И не думал (троллить, а не заканчивать). Само собой подразумевалось, что программы для GNU/Linux. Есть дистрибутивы с десятилетним циклом поддержки? А есть примеры бинарей живущих по 10 лет без пересборки? На ум почему-то приходит только Кулих, который умер 7 лет назад и который не работает на Linux 2.6.

>> Да, но не заработает

> Поясни, о премудрый, ибо недоступны для моего понимания слова твои.

Это ещё не конец предложения, потому как точки нет. А конец был в цитате:

> Если через пяток лет появится какая-то ARM64

>Надо сказать, проприетарщики по оффтопиком в этом преуспели более

Я помню под своей 2000-й успешно пускал PE бинарники, созданные под NT3 (?), c датой файлов в районе 1992 года. Это были какие-то примеры OpenGL, вытащенные из мелкомягкого MSDN'а. Помню тогда очень сильно удивлялся.

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

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

Юзерспейсной запускалки хватит даже для подгрузки библиотек. Тот же WINE занимается как запуском, так и подгрузкой библиотек. Юзерспейсная запускалка.

P.S.
Написал ещё одно письмо ему, но с картинками и более подробными объяснениями, что я предлагаю. Сейчас пойду смотреть, ответил ли он мне что-нибудь.

anonymous> Это можно сделать с помощью shell-скриптов, запускающий нужный бинарник в зависимости от архитектуры.

Я в начале топика тоже так думал...

Вот смотри:

Есть несколько архитектур: x86, x86_64, Cell.

uname их и выводит.

Прошло 5 лет. x86, сдохла, появилась x86_128 и назрела необходимость поддержки ARM для настольных игровых ПК, а также вышла Cell-128.

uname выведет для x86_128 не то, что ожидает скрипт, и не пойдёт игра от x86_64без танцев с бубном, которые приведут к необходимости исправлять скрипт запуска. Аналогично Cell-128. А вот на новой ARM в любом случае не пойдёт.

Ты видел в noarch .so-файлы? Я - нет.

В винде все на инсталяторах держится. И практика такая: скачал экзешник - запускай не думая о вирусах. Хорошее такое компромиссное решение, да?

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

> А есть примеры бинарей живущих по 10 лет без пересборки?

А вот нет FatELF-а, поэтому нет и бинарей, ага.

Есть бинари. Причём древние. Статически скмопилированы, и в результате идут. Проверено мной.

> Есть бинари. Причём древние. Статически скмопилированы, и в результате идут. Проверено мной.

На другой архитектуре? Впрочем, надо попробовать найти что-нибудь древнее у себя.

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

В солярке насколько помню с одного диска держалось несколько сановских архитектур. Также помню что структура инсталляции подаразумевала наличие как минимум библиотек под несколько типов, все эти sun3c, sun4 и тп.

Так что если мечта части ЛОР сбудется насчет например реального паралельного сосуществования arm с x86 с каким нибудь power и mips , то во первых, все дистрибутивы будут под несколько архитектур с одного диска, во вторых с точки зрения в чем держать например бинари на общей nfs инсталляции - так вот, с этой точки зрения такой формат удобнее.

И под реальным паралельным сосуществованием я имею в виду не текущую ситуацию , а реальное паралельное сосуществование. Когда в 99% контор например 50% станций x86, 30% arm , 10% power(cell тот же) и 10% mips. И я про обычные десктопы, а не про запрятанные где то в загашгниках сервера под линупсом на арме и мипсовые телефоны в кармане.

И тут совершенно правильно упомянули arm+x86 ноутбуки. Так как вообще говоря 3d карты очень быстро превращаются уже не в сопроцессор , а в полноценную вычислительную ноду.

То есть, вполне возможно что нас ждет мир где в простом десктопе будут 3 (sic!!!) процессорные архитектуры при чем на каждом десктопе может стоять как 3 разных OS(по ос на процессор) так и одна.

И таком мире вам будет совершенно вломы думать "можно ли запустить xxx на arm/GPU или нет". Вы быдете запускать программу а она автоматически будет запускатся на том процессоре который прописан в конфигах. И возможен вариант когда в зависимости от ситуации вы будете пускать одно и то же приложение на arm/gpu/главном проце.

anonymous (*) (24.10.2009 21:39:17) >> noarch в пакете - это README, AUTHORS и LICENSE. Всё остальное, как ни странно, "arch".

eugene2k (*) (25.10.2009 11:57:41) > Ты видел в noarch .so-файлы? Я - нет.

noarch в пакете - это README, AUTHORS и LICENSE. Всё остальное, как ни странно, "arch".
noarch в пакете - это README, AUTHORS и LICENSE. Всё остальное, как ни странно, "arch".
Так понятнее?

> В винде все на инсталяторах держится.
Пускай держится дальше. Здесь предлагают использовать инсталлятор для *нескольких* программ, которые, скорее всего, будут установлены далеко не у всех. Инсталлятор будет скачиваться с сайта разработчика. Скачавший с warez.com - ССЗБ.

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

Как эту проблему решит FatELF, в котором лежит код только для x86, x86_64 и Cell??? Все равно делать патч для поддержки новых архитектур. И все равно придется заново нарезать болванку с инсталлером, если захотим ставится на новой архитектуре.

Как кто? Мейнтейнер конечно. Они всегда этим занимались, что сейчас мешать начало?

> Да ладно, я всегда привожу в пример надпись после загрузки FreeBSD в консоли, точную я её, правда, забыл, но смысл таков: Ⓒ 1981,1984,1988 Regents of university of California. Года не помню, но что первый — 1981, это точно. Ну то есть коду 28 лет, и ничего, пашет ;)

Наличие года копирайта вообще-то не означает наличия хоть одной строчки кода от этого года.

Хотя, возможно, они там и есть.

Толсто.

Не придется. Если новая архитектура (x86_128, Cell128, etc) ОБРАТНО СОВМЕСТИМА с x86_64 и Cell соответственно - ничего нарезать не придется. Ядро (!!!!!) запустит из FatELF-а бинарник для x86_64 или Cell, опять же, соответственно.

Да-да, ядро-то может и запустит, только грамотно составленный скрипт скажет 'Unsupported architecture', а ядро - cannot find libc.so.6 . Что при этом информативнее для простого юзера вам объяснить?

Мне одному кажется что это еще и новый способ написания портабельной малвари ?

По сути, поддержка кернелом этой фичи - дело не плохое. Вот только я не совсем представляю, ГДЕ это нужно? Супержирные либы и исполняемые файлы.. ведь все равно под разные архитектуры отдельно собирать надо. Не пойму в чем профит (читай "удобство").

Первый шаг.

1. Внедрение сабжа 2. Хочешь иметь FatELF - пиши кросслатформенно 3. Распространение кроссплатформенности 4. Реальное распространение разных архитектур среди клиентов

ИМХО, такой же сценарий, но качественней его можно развить если допилить JIT или Just-during-installation compilation. Программы в байткодах могут быть безопаснее и более портабельными. А FatELF нужно только для высокпроизводительных приложений. Высокопроизводительный в смысле потребности разработчика вручную твикать ассемблер, подгонять под кеш процессора или что-то другое не под силу JIT. JIT - это настоящий universal binary, а не архивчик с бинарниками. Пахнет костылем.

Предыдущий пост мой.

Тем более нет причин ПОСЛЕ ИНСТАЛЛЯЦИИ дежать на винте бинарный код других архитектур. Для вашего процессора - это просто лишний мусор

Вы часто видите на блованках динамически слинкованный софт? Тогда да, придется вам ее перенарезать. И при каждом обновлении библиотек, ломающем ABI придется пересобирать и нарезать, вот незадача-то.

А тем временем, оказалось, что Apple владеет некоторыми патентами на универсальные бинарники...

А для чего нужен многоплатформенный бинарь, если софт в исходниках ?????

То есть, камень в сторону развития Open Source ???

http://en.wikipedia.org/wiki/Ryan_C._Gordon

He has also been involved in porting several non-gaming products such as Google Earth.

Проприетарщик ??

Ну вот, а вы боялись. Иккулуса послали в грубой форме и поделом. С предателями по другому нельзя.

самым оптимальным способом поддержки нескольких архитектур я считаю существующую систему АРТ - всё остально принципиально не нужно...

>Иккулуса послали в грубой форме и поделом.

В грубой форме и без аргументов (пионэрские "агрументы" аргументами не считаются)

>самым оптимальным способом поддержки нескольких архитектур я считаю существующую систему АРТ - всё остально принципиально не нужно...

Ну и дибил