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

Нет.

Почему все говорят только о запускаемых бинарниках, но никто не помнит о shared-libraries? IMHO как раз для некоторых из *.so-шек от FatElf'а наибольший профит в системе.

>А компилировать кто будет? Пользователи?

>Они же пользователи, а не программисты.

Понимаешь, милый ребёнок, програмисты - они не компилируют. Компилируют компиляторы. А програмисты - они пишут программы

>я пока даже не уверен как это вообще реализовать можно: сугубо теоретически.

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

>Ну если все такие ОС не называть UNIX-подобными, то как же тогда их звать?
>"частичноPOSIXсовместимые"???
>I-Love-Microsoft * (*) (24.10.2009 2:30:13)
>

Не надо вообще использовать имя UNIX. В наше время я считаю можно уже называть всё своими именами: BSD, GNU или по названию ядра Linux (хотя если речь идёт об операционной системе, то правильно будет GNU/Linux). Это уникальные системы, написаны с нуля. И не похожи они на UNIX.

UNIX - это Solaris от Sun Microsystems, AIX от IBM, HP/UX и Tru64 UNIX от Hewlett Packard (Tru64 принадлежала раньше Compaq), IRIX от Silicon Graphics Inc., UnixWare и OpenServer от The SCO Group. UNIX - это Mac OS X (Leopard & Snow Leopard на аппаратной части Apple на процессорах Intel).

тык ос то не висел на этом коде ? ситуация думаю напоминала больше вариант современных cpu+gpu, а тут юзеру нужно чтобы все переключалось с одного на другой. как ни крути 2 логики придется увязывать как то, чтобы оно с одной на другую переключалось (ничего кроме абстракции не приходит на ум), да еще выделять память под каждую (чтобы они не путались друг у друга под ногами). с ос через пару тысяч лет что нибудь придумают (если оно кому нибудь понадобится, в чем есть сомнения)

Могу конечно ошибаться: спарки не видел. Если так, то заранее прошу прощения.

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

Зачем переключать? Одно в suspend - другое из suspend'а

>Одно в suspend - другое из suspend'а

Карамба!!! Совсем плохой стал.

Однако такое недоразумение всеравно не нужно.

Скорее люди пойдут гуглить или на любимом форуме спросят. В случае с толстоэльфом это не нужно. Собственно вот она - нужность толстоэльфа :)))

Гораздо кошернее нормальный пакетный менеджмент. Инсталляторы - зло.

А кому оно будет нужно, если под его архитектуру бинарник есть и максимум нужно дополнить /etc/apt/sources.list?

Это не фича, это хак :)

Для *.so никакого дополнительного профита нет. Не все системные библиотеки нужны в 32битном и 64битном исполнении. Какие именно - зависит от конкретного пользователя и установленных у него программ. Для проприетарных либ, вроде флеш-плагина к огнелису, это тоже не нужно, потому что существование толстоэльфа подразумевает что разработчики сделали и 64битный и 32битный бинарники, соответственно можно скачать один или другой, а к 32битному сейчас линкуют как раз из-за отсутствия нормальной 64битной версии.

если реч идёт об интернетах (а не об DVD где аттрибуты-то сохраняются)

то запокуй [скачиваемый] исполняемый файл (или всю папку с программой) в ".tar.gz" ..

и вуаля! все аттрибуты в норме! :-) + и рациональность при процессе скачивания.

// p.s.: все комменты ещё не дочитал :-)

>Не все системные библиотеки нужны в 32битном и 64битном исполнении.

glibc

>Для проприетарных либ, вроде флеш-плагина к огнелису, это тоже не нужно

Не нужно.

А для icc-x86_64, например, - нужны 32-битные glibc и libgcc (как это ни смешно). А ради двух-трёх проприетарных бинарников, требущих 32-битные glibc и, возможно, ещё пару тройку либ, мне разводить биарчевый срач в системе неохота.

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

>То есть две папки в каждой из которых бинарники определенной архитектуры - это срач

Да. Потому что очень редкие пакеты содержат ТОЛЬКО бинарники.

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

Нет. А зачем их сканировать? Пакетный менеджер выдаст вам информацию по пакету: Multiarch он, или нет.

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

apt-get install skype

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

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

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

Ну, то есть, для "инсталлятора" пойдет - там можно сделать бандл, опять-таки, аналог макосного. Но как только дело дойдёт до штатной работы и штатного пакетного менеджера - всё, ТолстыйЭльф сдохнет от ожирения.

> впихнуть "1" где нибудь посреди названия и т.д

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

Relan> Во-вторых, есть еще как минимум две архитектуры -- i386 и x86_64.

Сдаётся мне, OS X не поддерживает x86,а поддерживает только x86_64.

anonymous> Pampers - торговая марка. Jeep - торговая марка. Почему тогда вы называете продукты/вещи/средства гигиены защищенной торговой маркой другого производителя?

Вопрос: к какому классу устройств относятся ASUS Eee, MSI Wind, Toshiba NB100, Rover Neo и т.п. ?

> Да. Потому что очень редкие пакеты содержат ТОЛЬКО бинарники.

glibc-common.noarch, glibc.i686, glibc.x86_64;
xorg-x11-fonts.noarch, xorg-x11-server.i686, xorg-x11-server.x86_64
Намек понятен?

А вообще... Icculus таки фигнёй страдает. Я бы с ним поговорил на эту тему и порекомендовал бы вот что:

Универсальный игровой фреймворк.

Суть такова. Есть формат FatELF, есть компутер с той или иной платформой. Набигают стандартные игровые библиотеки и универсальная пускалка игры (загрузчик программ вроде wine). Можно играть в игры.

Ну и реализовать эту штуку для Linux, Windows, OS X и т.д. То есть один толстый бинарник на все платформы. Покупаем в магазине диск, ставим игру, и она будет работать хоть под линуксом, хоть под вендой. И ядро не загрязнено, и игровой фреймворк стандартный без долботни с установкой зависимостей библиотек, который можно обновлять без поломки совместимости и т.п., и игры работают.

Icculus ещё кучу денег на этом сделать может.

Блин... надо к нему пойти и рассказать...

Идея вполне разумная, вот только боюсь, что, если дело дойдёт до реализации, традиционно всё будет сделано криво. Опять же ощущается нехватка реальных специалистов, всё заполонили индусы.

>Не будьте такими пессимистами! Как минимум это позволит создать универсальные инсталляторы софта, в том числе и свободного. Не уверен что в таком формате можно делать софт, а инсталлер в самый раз: вставил диск, а там отработал авторан и под любой ОС поднялся ^_^

>Когда-нибудь вы это оцените...

N лет оценивал. Оценка однозначна: в жопу авторан, желательно его автору в жопу. Налабать инсталлер на интерпретируемом языке/яве религия не позволяет?

Чирканул Icculus'у письмецо.

Я написал:

>Hi, Ryan. I wish to say about FatELF binary format. Yes - its very and very good idea. But part of community says that put this format to kernel its very bad idea. I guess with this part of community. I suggest to make universal game framework which will cover not only Linux, but also all supported operating systems: games can be started in Linux, Win32, OS X, BSD, ... from one distribution of game. Its means need to make binary loader similar to wine. But this loader will support FatELF binaries and libraries. In this framework neet to include libraries for make games and make this libraries standart for this framework. Location of this libraries must be in special directory. As a result will enough install one package (game framework with all libraries and support of FatELF) for support of all games. And all games can be used in all supported platforms from one game distribution or package.

What you think about this?

P.S. Sorry for my bad english.

Его ответ:

icculus> The point of the kernel patch is to streamline things. If you have to have a separate loader, you might as well just ship a regular ELF binary.

As for the framework: SDL covers much of what one would need, and it's easy to ship it with games.

--ryan.

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

а) опция для форсирования определённой архитектуры, правда это не для средних мозгов
б) ежели что-то имеет в своём названии х86, i386 скорее всего будет на нём бегать, не вижу сложности обработать это в инсталлере.

>> Не думаю, что пользователю так трудно выбрать для загрузки свою архитектуру, её название можно уже и выучить :)

>Зря.

HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux x86_64; ru-RU; rv:1.9.0.14) Gecko/2009091008 Iceweasel/3.0.6 (Debian-3.0.6-3)

Тру проприетарщик, подтирающий сопли среднему юзверю, не в состоянии это распарсить и выплюнуть ссылку на нужную архитектуру?

Ценители полной анонимности при таком раскладе идут лесом, но вот они то как раз должны бы сами разбираться в вопросе.

>Ненужно. Все равно что соединить трактор и автобус в одно целое. В итоге получится монструозное поделие.

Нет дружок. Это скорее гибридный автомобиль.

>гибридный автомобиль

Это такая новая членомерка для толстосумчатых? А что ты сделал для экологии в свои годы?

PS
man многотопливный ДВС

>Не надо вообще использовать имя UNIX. В наше время я считаю можно уже называть всё своими именами: BSD, GNU или по названию ядра Linux (хотя если речь идёт об операционной системе, то правильно будет GNU/Linux). Это уникальные системы, написаны с нуля. И не похожи они на UNIX.

Чушь какая. Просвещайтесь: 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). Да и зачем каждый раз Америку открывать? Дорого это, хлопотно и абсолютно бессмысленно.

> Сдаётся мне, OS X не поддерживает x86,а поддерживает только x86_64.

Поддерживает. На Core Duo (1-е поколение макбуков и макмини) 10.6 работает без проблем.

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

У х86 процессоров проблема скорее не в производительности, а в энергопотреблении. А сама идея, конечно, не нова, но она вполне в духе Unix-way: конечный результат получатся из объединения множества небольших специализированных компонентов. Это в отличие от х86, которые "всё в одном".

А всё равно же придётся компилировать под все эти архитектуры, ведь так? Зачем тогда лепить их вместе? Как пользователю генты, мне такая идея не нравится, я собираю то, что мне нужно, на кой мне ещё пакеты для других платформ. Да и в бинарном дистрибутиве: я должен буду поставить вместо N Гб в два раза больше, только для поддержки архитектуры, которой у меня нет? Меня же совесь сожрёт заживо, если я буду знать, что там ~50% ненужных байт.

А прототипы-то уже показывали.

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

А это уже задача для LSB.

> Тру проприетарщик, подтирающий сопли среднему юзверю, не в состоянии это распарсить и выплюнуть ссылку на нужную архитектуру?

А на DVD ты что делать будешь? Скрипты опять накручивать?

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

> И не похожи они на UNIX.

> UNIX - это Solaris от Sun Microsystems, AIX от IBM, HP/UX и Tru64 UNIX от Hewlett Packard (Tru64 принадлежала раньше Compaq), IRIX от Silicon Graphics Inc., UnixWare и OpenServer от The SCO Group. UNIX - это Mac OS X (Leopard & Snow Leopard на аппаратной части Apple на процессорах Intel).

Т.е. только то, что формально сертифицировано на соответствие POSIX вне зависимости от происхождения кода?

Граждане программисты!

Это долбанное предложение решает проблемы кроссплатформенности приложений!

Ещё раз вопрос:

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

Почему нельзя использовать C#, java, питон и прочее кросплатформенные штуки? Почему пользователь должен не эффективно использовать память, а програкммит не эффективно использовать время процессора? Вы представляете, сколько времени процессора займёт кросскомпиляция, отладка?

Это же наркомановский бред! ПО должно эффективно использовать время процессора и ресурсы компьютера! Тут не чего обсуждать! Такие больнгые идеи должны быть изгнаны из OpenSources! На текущий момент только фирма MS требовало отпользователей покупать новое железо, а сейчас на службу интел, амд и прочим хотят поставить OpenSources!!!!!!!!!

>Бесплатная подсказка: чтобы сделать программу самообновляющейся вовсе не нужен fatelf.

Ты топик прочитай сначала, я уже всё сто раз расписал

>Да что ты? Неужели разработчик будет заставлять меня сидеть под рутом? Или бинари в хомяк класть, что некошерно?

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

>Какой зоопарк? Вменяемые разработчики подключаемые к пакетным менеджерам репозитории освоили давно, даже проприетарщики (адоб, опера etc).

У оперы есть что-то кроме деб-репозитория? Про адоб не знаю.

> У дистрибутива сферической игры 90-99% места занято ресурсами: текстурами, звуками и прочей шелухой. Внедрение fatELF снимет головную боль многим игростроителям ценой увеличения размера дистрибутива на несколько %.

Ну наконец то, появилась светлая голова. А я боялся, что ЛОР скатился в сра..е гуано.

>Это не ему нужно, а libX*'у

Я неправильно написал. С libxcb 1.4 либу переименовали, точно не помню, и старый проприетарный софт всё ещё слинкован со старым именем.

>Тем, что можно будет предоставлять только один пакет? Всё равно нужно собирать и тестировать на всех архитекурах. Не думаю, что пользователю так трудно выбрать для загрузки свою архитектуру, её название можно уже и выучить :)

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

>А как это поможет с обновлением?

Независимость от репозитория. Для менеджера пакетов его нужно обновлять перед каждым запросом новой версии, либо нужно писать свой, с преферансом и барышнями. Та самая сферическая игра в вакууме не нуждается в каких-то хитрых зависимостях, миллионе библиотек и т.п. Главное - быть обновлённой по востребованию. Выходит пользователь в лобби - а ему говорят: "Нет, брат, сворачивайся, обновляй репозиторий, пинай мантейнеров, обновляй пакеты"

> apparmor, selinux и прочие работают в ядре, и от библиотек не зависят

А как же /lib/libapparmor.so и /lib/libselinux.so? Некоторые программы с ними слинкованы.

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

В топике уже писали сто раз - никто не заставляет переводить всю систему на fatelf.

Этот Райан Гордон за десять лет портировал на линукс ~50 игр и программ, как самостоятельно, так и в составе Loki Software.

GUNDAM же

>Налабать инсталлер на интерпретируемом языке/яве религия не позволяет?

А кто интерпретировать-то будет?

У Вас в системе нет Python/Perl/bash?

>У Вас в системе нет Python/Perl/bash?

Ты прочитал пост, на который ответил? Интерпретатор то уже будет зависеть от архитектуры

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