[FatElf] Король мертв! И поделом.

>Неужели добавление FatELF в ядро значительно увеличит его объём, а к времени запуска обычного ELF-файла прибавит секунды?

А как же пробегавшие заявления, что ядро уже слишком толстое? :}

>Если речь идёт о "сферических играх в вакууме", то это незаметное увеличение объёма загрузки. А учитывая, что ряд игр в любом случае обновляет все бинарики, это вообще ноль.

Чем это лучше 1 (одного) предложения в прямоугольнике с надписью какую команду выполнить, чтобы узнать какая архитектура у пользователя? И вообще никаких изменений не нужно. Если убунтоидам так сложно это, можно при загрузке на сплешскрине рисовать AMD64 или что там у них. Меньше кода, меньше вектор угрозы, меньше проблем и геморроя (о ядре).

Чем это лучше sh-скрипта также остаётся непонятным. И, да, sh есть везде (Windows в данном случае не рассматриваем, там фатэлфа нет).

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

Серьезно говоря, а зачем нужен FatELF рядовому пользователю? От него одни проблемы, если оно не работает из коробки, а плюсов - ноль. Возможность запуска бинарников на куче платформ - конечно круто, но проблемы с _наличием_ кода к определенной архитектуре и обратной совместимостью оно не решает.

>Изначальный выбор делает менеджер пакетов

%)

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

>Нагрузка на апдейт серверы вырастет многократно

С чего вдруг?

>Нифигасебе!!1

Успокойтесь :) Вы меня не правильно поняли. При каком-либо изменении в структуре бинарей игры нужно переписывать скрипт, значит надо писать обновлятор для обновлятора?

>Да и не особо нужны скрипты для этого...

Ну бесскриптовый вариант предложите.

1. Никто не требует использовать FatELF во всей системе - это бессмысленно. Смысл есть только на установочных дисках.

2. FatELF увеличивает размер только исполняемых файлов

>Серьезно говоря, а зачем нужен FatELF рядовому пользователю?

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

>От него одни проблемы, если оно не работает из коробки, а плюсов - ноль

Вот это основной аргумент противников FatELF :) Хороший, консервативный, но пустой аргумент. Никто не может назвать ни одного минуса этого нововведения. Если что-то не работает из коробки, от этого всегда одни проблемы, а плюсов - ноль.

Не отвечайте пожалуйста в тему, не прочитав предыдущие посты.

Но заметь, что никто и не запрещает это делать.

> При каком-либо изменении в структуре бинарей игры нужно переписывать скрипт

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

> значит надо писать обновлятор для обновлятора?

Такие обновляторы я тоже видел. Под виндой. Как минимум, у HOMM3 и у какой-то онлайн игрушки про космос. А чем тут должен был помочь толстый эльф?

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

Библиотечные FTP клиенты есть практически на любом языке. На чем написана игра, на том же можно написать и обновлялку.

Я просто взял ваш паттерн про пульс. Давайте рассмотрим такую ситуацию. Пользователь на своем нетпуке на арме (ну вдруг они будут к моменту выпуска ядра с FatELF :D ) запускает бинарник в котором код к X86 и X86_64. Не работает. Какая разница между FatELF и просто ELF? Никакой. Я понимаю, что чувак видимо рассчитывает на то, что это будет совмещенный код с X86 и X86_64 и решать проблему т.н. "простого пользователя" для константного числа архитектур, но это какая то мура.

Минус я назвал - возможное неадекватное поведение мантейнеров.

Я о том же.

+1

>На чем написана игра, на том же можно написать и обновлялку

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

>Но заметь, что никто и не запрещает это делать

Никто не запрещает засовывать пальцы в электрическую розетку, но человечество со времён изобретения оных только увеличило свою популяцию

> Никто не может назвать ни одного минуса этого нововведения.

FatELF удобен для распространяющих закрытые бинарники. Многих это бесит, но признаться они стесняются :)

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

Вы так говорите, будто это что-то плохое

> Никто не может назвать ни одного минуса этого нововведения.

Ненужная энтропия. Бритва оккама зовет и требует.

Многие любят говорить за всех, но признаться они стесняются :}

> и в чем же минусы?

Минусы обсудили в предыдущем треде:

http://www.linux.org.ru/view-message.jsp?msgid=4193293&page=2&lastmod...

mironov_ivan> Нет. Совсем не одинаково практически во всех реальных случаях (т.е. реальные игры, а не тесты). А то и вообще просто не работает =).

Объясни мне, как один и тот же код может работать в корне по разному на Windows и Linux?

mironov_ivan> Этот код придётся портировать постоянно. Или ты думаешь что в ELF не будут добавляться новые фичи и делаться прочие изменения?

Какие фичи в ELF введены за последние 10 лет? Ну и никто не мешает дёргать функции из ядра.

mironov_ivan> Ты считаешь, что добавить свой пакет сомнительной полезности в стандартный install cd федоры или убунты проще, чем добавить примерно такой же код в ядро?

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

mironov_ivan> Готов поспорить, что в этом случае начнётся та же дискуссия, что и недавно в LKML. И с тем же результатом.

Ну спорь. Только в дистрибутивы чатстенько гораздо менее нужные пакеты пихают.

mironov_ivan> Нет загрузчика - не откуда взяться и востребованности.

Ага. Нет дров нвидии в стандартной поставке - не будут покупать карточки от нвидии... Офигеть логика.

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

То есть по-твоему 3D ускорение на убунте на нвидиевских карточках мало у кого реально работает?

linuxfan> Реакция человека вполне понятна и он вовремя остановился: Рейзер на почве постоянных отказов принять reiser4 в ядро свою жену замочил.

Докажи.

Evil_Wizard> А пачму просто неззя два бинарника рядом положить?

Потому, что их реально не два будет, а как минимум 5. Кроме x86 есть ещё куча платформ - MIPS, POWER, ARM, SPARC, и другие. И не только линукс есть.

Вот смотри:
Игродел решил выпустить игру под кучу платформ. Какие у него варианты:

1. Выпустить по диску на платформу.
2. Выпустить на диске один дистрибутив, но с кучей бинарей.
3. Выпустить на диске один дистрибутив и с одним бинарём в FatELF.

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

Второй случай: это конечно здорово, но что делать чайнику - искать нужный бинарь?

Третий случай: всё идеально, всё работает, всех устраивает (кроме красноглазых малолеток, которые выступают за "труЪ" форматы)

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

mironov_ivan> В месте выбора нужных файлов под конкретную архитектуру?

В одном дистрибутиве RPM, в другом DEB,в третьем вообще портеж. А задача стоит так: сделать дистрибутив на одном диске для кучи платформ, и без мозгопарки для пользователя и разработчика. Возникает вопрос: ты вменяем?

>Второй случай: это конечно здорово, но что делать чайнику - искать нужный бинарь?

В видновсе же как-то находят, хотя там такой срач в каталоге программы.

Macil> И даже не загрузчик, а stub, по аналогии с NE и PE под виндой.

Интересно, как он будет себя вести под линуксом и вендой. Ну и stub... Дело такое, что есть задача поддержки кучи архитектур. А stub в DOS/Windows сделан x86-only. Выходит, что такой stub не решает проблему.

>В одном дистрибутиве RPM, в другом DEB,в третьем вообще портеж. А задача стоит так: сделать дистрибутив на одном диске для кучи платформ, и без мозгопарки для пользователя и разработчика.

.tar.gz с каталогом, содержащим всё, что нужно программе.

ппкс

причём "опомнятся" - это если очень сильно повезёт. В противном случае будут думать, что "hello world" размером в пару десятков мегабайт - это так и должно быть.

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

И в предыдущем треде вам обяснили, что FatELF никак эту проблему не решает тоже. Склеить разные архитектуры в один файл можно с помощью run-файлов, обьединяющих скрипт и блоб.

Вас не смущает что чтобы скачать Firefox, OpenOffice или драйвер Nvidia вы должны пройти небольшой квест на сайте. Если пользователель не может отличить архитектуру своего компьютера - он даже не отличит версию Windows от версии Linux. Предлагаете их тоже склеить, чтобы упростить жизнь хомячкам? И вообще та же Nvidia сама выкладывает пакеты с драйверами в собственный репозиторий yum, благодаря чему обновляются они безопастно, быстро и у всех сразу.

> Никто не может назвать ни одного минуса этого нововведения.

Странно, а о чём тогда был разговор в этом треде? http://www.linux.org.ru/view-message.jsp?msgid=4193293&page=2&lastmod...

Вы тут говорите о мнимом прогрессе, мол FatELF - рывок для софта на десктоп пользователя, а его противники - консерваторы. Постарайтесь заглянуть немного в будущее, представьте, что эту фичу таки приняли в ядро и на сайтах начали появляться FatELF блобы. Какие там лежат по-вашему архитектуры? Я даже подскажу: x86 + x86_64 only. В итоге через время таких блобов расплодилось как грибов с подписями: "Не знаешь какая у тебя ОС? Просто скачай FatELF!" (утрирую).

Про небезопастность Линукса, в схему установки софта у которого входит привычное нам с Windows "click and run trojan horse" я воообще молчу.

А теперь представьте ситуацию, что на рынке появляется другая архитектура, в моду входит тот же ARM. Заходит юзер скачать игру под ARM, видит красивую надпись, качает , запускает и получает шиш. На вопрос в поддержку ответ будет типа: так там же FatELF, не знаем мы ни про какой ARM.

Ситуация ровно такая же как "Скачайте версию под PC", не уточная что имеется в виду PC с Windows.

В итоге преимущество качания инсталятора одним файлом под все платформы сводится в ноль, пользователь всё равно должен искать Fat ли ELF это? А какие архитектуры в нём? И всё равно это не решит проблему с зависимостями и прочим, так как платформа определяется не одной лишь архитектурой.

Прогресс говорите...

Manhunt> Хотите одинаково - кагбе OpenGL.

OpenGL - только графика. Тогда уж SDL (который после анабиоза не успели ещё допилить).

А так - можно winelib предлагать. API знакомый, все нужные функции есть, версия и под линукс, и под венду есть. Итого вместо Direct X под вендой будут ставить WINE. Может игроделы даже деньги выделят на допилку WINE до хорошей кондиции, и на кучу платформ портируют - только выигрыш будет, если Direct X действительно неплох как игровой фреймворк.

Mystra_x64> написать небольшую заметку

И ты всерьёз думаешь, что они будут что-то читать?

Большими буквами на красном фоне над ссылкой скачивания — будут. Геймеры они вообще на удивление сообразительнные. Инструкции к крякам и кейгенам же читают. И тут будут.

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

У ALSA dmix не справляется со своей задачей - вместо нормального микширования сплошные заикания. В PulseAudio (который из коробки, кстати, работает, и я им с удовольствием пользуюсь) же это работает замечательно. И ни одной проблемы с PulseAudio у меня ещё не было.

> 1. Выпустить по диску...
> 2. Выпустить на диске...
> 3. Выпустить на диске...

Дальше читать не обязательно. FatELF никак не помогает софту, расспространяющемуся на диске. Для этого в корне будет лежать какой-нибудь Setup.sh, который сам найдёт нужный пакет в поддиректории.

Вон товарищи из соседнего Китая пилят Unified Linux Kernel, тоже якобы из лучших побуждений. Хотя в всё это исключительно для проприетарщины, и настолько опасно для Линукса, что лучше закатать весь проект под асфальт, для верности с самими разработчиками.

Unified Linux Kernel и FatELF - корни одного зла. Wine - маленькое зло в юзерспейсе, в принципе жить не мешающее.

Manhunt> posix shell

Он проблему запуска нужного бинарника не решает.

Manhunt> Им в любом случае это выбирать не нужно. Изначальный выбор делает менеджер пакетов.

А если игра на диске, и куплена в магазине? Что тогда? Репозиторий добавлять? А ты прикинь - на RPM диск не расчитан, или на DEB. Что тогда? Не поиграет пользователь в игру без навыков Console Text Action? То-то и оно, что FatELF _нужен_ в игровой индустрии.

>Manhunt> posix shell
>Он проблему запуска нужного бинарника не решает.

Почему же?

Dendy> Дальше читать не обязательно. FatELF никак не помогает софту, расспространяющемуся на диске. Для этого в корне будет лежать какой-нибудь Setup.sh, который сам найдёт нужный пакет в поддиректории.

Не найдёт. Доказано.

Dendy> Unified Linux Kernel

Оно никому не нужно. Пользы никакой от интегрирования WINE в ядро.

Да и я не предлагаю в ядро засунуть FatELF -я его предлагаю в userspace. Или ты считаешь, что WINE - зло? Если так - тебе сюда: http://antigreen.org/bioreactor/

Решает, после скрипта в файле можно положить код.

Mystra_x64> Почему же?

Потому, что arch не выдаст x86 на процессорах x86_64 и x86_128, а выдаст x86_64 и x86_128 соответственно. И скрипт просто перестаёт решать задачу. В случае же с FatELF на x86_64 и x86_128 работают бинарники от x86.

Dendy> Решает, после скрипта в файле можно положить код.

Нет - не решает. Так как скрипт определяет архитектуру, что он в общем случае сделать не может в принципе.

LOLWUT? Ты о чём?

Случай 1.

Имеем 3 бинарника. Скрипт получает arch и грузит game_{arch}.bin (или что там).

Случай 2.
Имеем 1 бинарник. Скрипт получает arch или не опрашивает его вовсе и грузит (пытается грузить 1 и тот же, возможно, дефолтный) бинарник.

В чём проблема то?

> Не найдёт. Доказано.

Мне нравится ваш ход мыслей.

> Оно никому не нужно. Пользы никакой от интегрирования WINE в ядро.

Wine - не самоцель. Это прослойка для исполнения Win32-вирус^W программ в среде Linux. Если прослойки в юзерспейсе не хватает - её пихают в ядро. Цель Wine и ULK в принципе одинакова.

> Если так - тебе сюда: http://antigreen.org/bioreactor/

Когда аргументы заканчиваются...

> настолько опасно для Линукса, что лучше закатать весь проект под асфальт, для верности с самими разработчиками

+100500

Чайнику надо запустить скрипт installme.sh. Все. И никакого баллшита.

> А ты прикинь - на RPM диск не расчитан, или на DEB.

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

> То-то и оно, что FatELF _нужен_ в игровой индустрии.

Он не решает никаких сколько-нибудь существенных проблем.

Mystra_x64> Имеем 3 бинарника. Скрипт получает arch и грузит game_{arch}.bin (или что там).

Смотри обсуждение первой новости про FatELF. Там это разжёвано до самых мельчайших деталей. И не задавай глупые вопросы. arch не выдаёт требуемую архитектуру - он выдаёт _текущую_.

Dendy> Wine - не самоцель. Это прослойка для исполнения Win32-вирус^W программ в среде Linux. Если прослойки в юзерспейсе не хватает - её пихают в ядро. Цель Wine и ULK в принципе одинакова.

Нет - не одинакова. В юзерспейсе WINE достаточен.

Dendy> Когда аргументы заканчиваются...

Аргументы я привёл, но ты их проигнорировал.

vasily_pupkin> Чайнику надо запустить скрипт installme.sh. Все. И никакого баллшита.

Нельзя. См. обсуждение первой новости про FatELF.

Manhunt> Он не решает никаких сколько-нибудь существенных проблем.

Он решает проблему распространения в удобном виде как для разработчика, так и для пользователя.

> Ты сможешь назвать хоть одну альтернативу pulseaudio?

ALSA. EsounD. aRts.