Спустя почти три недели с момента выхода (http://www.opennet.me/opennews/art.shtml?num=33955) финальной версии Fedora 17 для систем x86 увидел свет (http://lists.fedoraproject.org/pipermail/announce/2012-June/...) релиз Fedora 17 (http://fedoraproject.org/wiki/Architectures/ARM/Fedora_17_GA) для платформы ARM. Готовые установочные сборки сформированы (http://ftp.heanet.ie/mirrors/fedora-secondary/releases/17/Im.../) для архитектур armv5tel (ARM soft-float) и armv7hl (ARM hard-float). Обеспечена поддержка аппаратных платформ Tegra 2, OMAP, IMX, Kirkwood и Highbank, а также сформирован вариант для запуска в Qemu.
Сборки оформлены в трёх вариантах: базовые консольные приложения, минимальный набор X-компонентов и сборка с полноценным графическим окружением на базе Xfce. Подготовленные образы могут быть записаны непосредственно на SD-карту, USB-накопитель или SATA-диск. Дополнительно представлены архивы с ядром и пакетами для формированием своих рабочих образов.URL: http://lists.fedoraproject.org/pipermail/announce/2012-June/...
Новость: http://www.opennet.me/opennews/art.shtml?num=34139
кто знает можно ли откомпилить программу которая написана под x86(порядок байт)
так что бы не меняя код она работала на ARM c другим порядком байт.то есть программа не учитывает что будет запускаться на компьютере с другим порядком байт.
Всё зависит от используемого ЯП, и уровня абстракции. Если вы используете низкоуровневые трюки, и вручную перелопачиваете данные в определённом порядке - то не будет работать. А если используются вызовы библиотек, работающих в том числе и под ARM - то почему бы приложению и не работать. Низкоуровневый код обычно пишут для каждой платформы специфичный, так что логично что вам прийдётся делать то, что давно стало стандартом в мире разработки ПО.
> кто знает можно ли откомпилить программу которая написана под x86(порядок байт) так что бы не меняя код она работала на ARM c другим порядком байт. то есть программа не учитывает что будет запускаться на компьютере с другим порядком байт.о чем ты? я как обладатель 5-ти различных компьютеров на базе ARM могу сказать что проблем с порядком байт не знаю, а знать их могут только те кто пишут драйверы
кроме того, современные дистрибутивы и ядра используют LE-режим если не ошибаюсь это так называется
LE (как в x86) - little endian - порядок бит MSB-to-LSB, ты имел ввиду порядок бит?
добавлю что ты можешь использовать QEMU и эмулировать различные ARM-системы в разных режимах и разными дистрибутивами - там всё сам и узнаешь что как работает
>LE (как в x86) - little endian - порядок бит MSB-to-LSB, ты имел ввиду порядок бит?Добавлю, что
1. с точностью до наоборот. У остроконечников LSB находится по наименьшему адресу.
2. Порядок байтов, а не битов.
> а знать их могут только те кто пишут драйверыНе совсем так. При нужде сохранить на диск или полслать в сеть данные в виде понятном другим (сериализация-десериализация) - вам кой-что придется узнать про это и в махровой прикладухе.
ну ява или разделение архитектуронезависимого кода и написание архитектурозависимих ланчеров и сецифичных библиотек под обе архтектуры.. в общем если программа не учитывает что будет запускаться на компьютере с другим порядком байт то нет.
Сабж и без явы обошёлся. Думаю что xfce вообще никто не трогал.
На заметку.
О, сори.
Тут про блобы.
Не, тогда жаба, питон и тд.
Или какой-нить экстфат с блобами для всех архитектур.
Дело даже на в литл/биг-ендиан, до него ещё с эльфом надо разобраться.
Похоже, урожай травы в этом году задался. Кого-то уже вштырило и он дампит сюда свой мыслительный процесс. Судя по бреду - какой-то виндузятник пытается судорожно втиснуть в свой мозг идею что оказывается в природе есть не только винда, фат и блобы, а на дотнете мир не заканчивается.
То есть один бинарик для нескольких архитектур? Не-не-не, разве что если интерпретируемые языки, но так уже и не бинарик. Другое дело, если один исходный код для разных архитектур - это запросто, достаточно ifdef-ов понапихать в нужные места. Да и вообще, зачем большинству приложений знать порядок байт?
> кто знает можно ли откомпилить программу которая написана под x86(порядок байт)Нормальные люди пишут программы так чтобы порядок байтов ни на что не влиял. Поэтому если программа кроссплатформенная, 99% что она просто скомпилится и просто заработает.
А в чём, кстати, разница? А то я себе в chroot на cortex a9 поставил и squeeze armel, и sid armhf. Оба работают. В чём разница-то основная, и преимущество?
Hard-float если я правильно понимаю это когда операции с плавающей точкой считаются на FPU, отсюда и название хардверный-плавающий =). По факту armel тоже использует FPU инструкции если они есть в наличии, но сохраняет совместимость с чипами без FPU, соответственно имеет некоторый оверхед. Armhf не работает на чипах без FPU и должен быть по слухам на 30% быстрее. По факту я на глаз разницы не змачаю.
> По факту я на глаз разницы не змачаю.Нормальный метод бенчмаркинга. А запустить хоть какой-то бенч, типа SSL или LZMA?
> armel, и sid armhf. Оба работают. В чём разница-то основная, и преимущество?разница - armhf не использует NEON вообще, так что это не преимущество а недостаток гнилого gcc который до сих пор не может нормальную векторизацию делать, второе "преимущество" - счас все блобы написаны для armel и работать с ABI armhf не будут.
а как это чудо поставить на iPhone 4 Gs
В поддержку apple уже обращались?
Где найти iPhone 4 Gs?
у дядюшки ляо, не?
да. и он уже с федорой идёт
> а как это чудо поставить на iPhone 4 GsНикак - эппл залочил загрузчик, так что у вас есть выбор:
- Вы можете ходить строем за эпплом.
- Если курс партии показался неверным, вы можете прибить +1 экспонат на стену.