Один из разработчиков проекта Debian, используя наработки компании ARM и консорциума Linaro (http://www.opennet.me/opennews/art.shtml?num=36001), сформировал (https://lists.debian.org/debian-devel/2013/02/msg00413.html) первую сборку (http://wiki.debian.org/Arm64Port#Pre-built_Rootfs) Ubuntu 13.04 для 64-разрядной архитектуры ARM64 (ARMv8/AArch64). Так как первые процессоры с набором команд ARM64 ещё не поступили в продажу, оценить работу ARM64-сборки дистрибутива можно только с использованием эмулятора (http://www.arm.com/products/tools/models/fast-models/foundat...). Таким образом Debian и Ubuntu стали первыми операционными системами, поддерживающими работу на платформе ARM64.
Для тестирования подготовлен (http://people.debian.org/~wookey/bootstrap/rootfs/) загрузочный образ Rootfs, позволяющий загрузить ОС с использованием системы инициализации upstart для работы в консольном режиме. В 64-разрядной сборке также обеспечена возможность бесшовного запуска 32-разрядных приложений для архитектуры ARM-hf и сосуществования в одной системе 64- и 32-разрядных приложений. В представленной сборке задействовано 140 пакетов (http://people.linaro.org/~wookey/buildd/raring-arm64/status-...), введён в строй репозиторий пакетов (http://people.debian.org/~wookey/bootstrap.html). Средства для кросс-компиляции и формирования сборок одновременно развиваются для Debian и Ubuntu Linux. Сборки могут быть сформированы как на основе Ubuntu 13.04, так и Debian Unstable.Напомним, что поддержка ARM64 ранее была добавлена в состав ядра Linux 3.7 (http://www.opennet.me/opennews/art.shtml?num=35554), системной библиотеки Glibc 2.17 (http://www.opennet.me/opennews/art.shtml?num=35698) и экспериментальной ветки GCC. 64-рязрядная архитектура AArch64 включает в себя новый набор команд A64, примечательный расширением числа регистров, новыми командами для вычислений с плавающей запятой (FP) и новыми векторными SIMD-инструкциями NEON, такими как инструкции для ускорения работы алгоритмов шифрования AES и SHA-1/SHA-256.
URL: https://lists.debian.org/debian-devel/2013/02/msg00413.html
Новость: http://www.opennet.me/opennews/art.shtml?num=36244
в спецификации для AArch64 -- уже стандартизировали загрузку как через UEFI ? (или всё ещё требуются костыли?)
Нафиг-нафиг такую "стандартизацию". Там к счастью MS'ом и интелем не все зохавано, так что к счастью PE EXE и их парсеров таки не будет. Что к лучшему.
а в чём притензии к UEFI? и почему его плохо на Arm ?не уж-то существуют интерфейсы более стандартизированные и расширяемые?
# P.S.: только не упомянайте пожалуйста SecureBoot. не нужен тут этот холивар.. :)
в эпопеи вокруг ядра линукс и подписыванием pe стаба, читать в рассылке, линукс всем навешал
зачем подписывать что-то?
Бесполезно. UEFI и Secure Boot для них - тождественные понятия, как партия и Ленин,
Вопрос про UEFI давно перерос в годную тему для троллинга, нежели желание обсудить что-либо.
В качестве моего стандартного троллинна:
>а в чём притензии к UEFI? и почему его плохо на Arm ?Таки подлодки (U-boot) хватает для геморроя головного мозга. Нафига нам новые сущности?
>На счет вышеуказанного PE EXE:
> в спецификации для AArch64 -- уже стандартизировали загрузку как через UEFI ?Кто о чем а вшивый о бане. Дайте-ка угадаю - вы пользуетесь дистрибутивом RH/MS ?
> Кто о чем а вшивый о бане. Дайте-ка угадаю - вы пользуетесь
> дистрибутивом RH/MS ?полигон для RH.
тоесть почти угадал :)
Да ладно, стандартизация загрузки (и работы с устройствами) там давно не помешала бы. А что ни устройство - своя фирмварь. Маразм.
Когда деревья были большими, опции загрузки ядра записывали прямо в само ядро. Этот навык ещё не утерян? А уж подгрузить само ядро, вроде бы, проблем нет - подсовывай да ешь.initrd? А он нужен? И, вроде бы, initrd уже тоже научились прямо в ядро засовывать.
Это детские болезни "игла - в яйце, яйцо - в ларце, а загрузчик в первых 512 байтах первого раздела первого диска, на котором надпись СОЛЬ" были свойствены другим ОС. А тут - вот ОС, вот знакомая ФС, вот ядро, загружай его по имени файла с носителя, без всяких бут-блоков и специальных установок загрузчиков. Красота?
По мне, так и uboot только усложняет всё, из прозрачной схемы. Или я чего-то не понимаю?
> тут - вот ОС, вот знакомая ФС, вот ядро, загружай его по имени файла с носителя, без
> всяких бут-блоков и специальных установок загрузчиков. Красота?Не совсем - при такой схеме нужно встроенной SRAM метров 8-10 и стоить это будет недешево. На данный момент загрузка у всех SoC более-менее одинакова - начальный загрузчик считывается с внешнего носителя в IRAM (SRAM) и ему передается управление, он инициализирует контроллер внешней памяти и подгружает вторичный загрузчик во внешнюю память и передает ему управление или делает релокацию, вторичный загрузчик в свою очередь загружает ядро ФС с любого доступного носителя. В принципе можно расположить XIP ядро в параллельной NOR-флеш и сразу стартовать его, но оно тогда должно уметь настроить контроллер внешней памяти, поэтому часто там располагают загрузчик и пропускают первый этап в описанной схеме. Теперь замени слово загрузчик на BIOS и получишь то что было когда-то на PC.
Некоторые SoC имеют небольшой объем памяти на борту, чтобы была возможность записать туда загрузчик. А дальше уже дело самого загрузчика, как он понимает и управляет периферией на борту данного SoC. Хотите от загрузчика больше возможностей научите его это понимать.
Касательно новости, то новость банальная, сейчас все дистрибутивы это делают.А вот касательно нового процессора тоже мало нового и интересного, хотя бы, потому что на данный момент уже существуют хорошие SoC которые многое умеют, но конечные устройства часто стоят столько же сколько стоит такое же устройство но на x86 процессоре. Что в свою очередь понижает интерес к устройствам на arm, и это даже несмотря на то что ARM64 планируется применять в сервером секторе.
я так понимаю, что в серверах ARM 64 будут использовать как сейчас gpu ускорители в серверах ( по крайней мере интерес AMD был в этом ), только не для тяжелых вычислений а для виртуализации, т.е. сервер виртуализации x86 и сами машины на сотне другой армов воткнутых в слоты расширения, со своей памятью и возможно частью ввода вывода.А в обычных устройствах х64 даёт приемущество в памяти, можно будет делать видеоприставки, с большим объёмом оперативки, что позволит на них запусткать всякие JS операционки, ввиду их жадности до памяти, и ещё более упростит прцесс разработки софта ( сейчас тенденция к тому что проще и дешевле память и проц помощнее чем программиста поумнее ;) )
Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают для того чтобы они могли вообще не отлаживать и не оптимизировать свой код. А в вэбе считают что мощности и пропускные способности увеличивают для того чтобы можно было больше рекламмы всунуть.
Может они правы? Может мы вообще существуем для того чтобы есть всё что подают? Может скоро издадут закон по которому пассивные пользователи (не так часто покупающие новые компы и не кликающие по рекламме) будут преследоваться по закону?
> Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
> для того чтобы они могли вообще не отлаживать и не оптимизировать
> свой код. А в вэбе считают что мощности и пропускные способности
> увеличивают для того чтобы можно было больше рекламмы всунуть.Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия. А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.
>Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия.Сейчас тоже.
>А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.
Во всем нужна мера, если оптимизация стоит больше чем железо, то я выбираю железо.
У реальных программистов (а не сферических в вакууме) есть дедлайны, у них нет в запасе пары лет на оптимизацию, им нужно показать работающий код точно в срок. Нет кода -- нет еды.
>>Не могу, не согласится, так как во времена, когда компьютеры были слабее все старались оптимизировать код для максимального быстродействия.
> Сейчас тоже.
>>А теперь недостатки проектирования кода, компенсируют дополнительные ресурсы железа, для обеспечения быстродействия.
> Во всем нужна мера, если оптимизация стоит больше чем железо, то я
> выбираю железо.
> У реальных программистов (а не сферических в вакууме) есть дедлайны, у них
> нет в запасе пары лет на оптимизацию, им нужно показать работающий
> код точно в срок. Нет кода -- нет еды.Абсолютно верно, с радостью бы вылизывали каждый запрос и каждую процедуру, и считали каждый байт переданный по сети, но за это не везде готовы платить :)
> У реальных программистов (а не сферических в вакууме) есть дедлайны, у них
> нет в запасе пары лет на оптимизацию, им нужно показать работающий
> код точно в срок. Нет кода -- нет еды.Ага, а потом приложение на твоем смартфоне вылетает по OutOfMemory
Не стоит обобщать.
> им нужно показать работающий код точно в срок. Нет кода -- нет еды.Ну не все ж за еду работают и с манагерами, которые верят в дедлайн превыше всего (вот такие обычно их и срывают, кстати).
>Ну не все ж за еду работают и с манагерамиЗа еду работают все. Не все с манагерами. Если у Вас лично есть доходы позволяющие не работать, но есть идеи и время на их реализацию, то это уже не работа, а творчество. Хорошо в этом плане некоторым ученным, удовлетворяют собственное любопытство за чужой счет, но не всем так повезло.
>которые верят в дедлайн превыше всего (вот такие обычно их и срывают, кстати).
Дедлайн необходим для разработки. Единственный безотказно действующий на всю команду стимул забыть про все и начать работать.
> Если у Вас лично есть доходы позволяющие не работать, но есть идеи
> и время на их реализацию, то это уже не работа, а творчество.С ~2004 получается зарабатывать на хлеб творчеством. Вот прийти к пониманию того, что хороший результат -- это хороший коллектив, которому нужны хорошие цель, руководство и атмосфера -- некоторое время заняло, зато теперь знаю, что это так и есть.
> Дедлайн необходим для разработки. Единственный безотказно действующий
> на всю команду стимул забыть про все и начать работать.Дедлайны и работа -- они разные бывают. Порой подсовываю дальше людям, которые ближе к тимлидам или манагерам, вот эту толковую книжку: http://pragprog.com/book/jrpm/manage-it
>С ~2004 получается зарабатывать на хлеб творчеством.Рад за вас. Только "зарабатывать на хлеб" и "работать за еду" , практически синонимы, не будь результата в срок плюс-минус, творчеством можно было бы заниматься у мусорных бачков.
>Вот прийти к пониманию того, что хороший результат -- это хороший коллектив, которому нужны хорошие цель, руководство и атмосфера -- некоторое время заняло, зато теперь знаю, что это так и есть.
Этого мало, нужен талант, недюженное здоровье, огромное трудолюбие, и чертовское везение. А только с хорошим коллективом и атмосферой -- бухать хорошо.
>Дедлайны и работа -- они разные бывают.
Дедлайны бывают разные. А вот без них увы никак, в интернетах столько котэ, постоянно кто-то не прав, куча новых идей, семья, друзья, хозяйство, есть большая степень вероятности ничего не сделать.
Особенно когда это касается "проектов на вырост", где необходимо постоянно включать мозг. Люди этого жутко не любят и постоянно находят новые предлоги чтобы не делать этого и заняться чем-то иным. С однотипными проектами гораздо проще.
> Порой подсовываю дальше людям, которые ближе к тимлидам или манагерам, вот эту толковую книжку: http://pragprog.com/book/jrpm/manage-itУвы, но ни одна книжка не заменит практики.
> Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
> для того чтобы они могли вообще не отлаживать и не оптимизировать
> свой код. А в вэбе считают что мощности и пропускные способности
> увеличивают для того чтобы можно было больше рекламмы всунуть.А вы покрутите видео fullhd на стареньком компе, много нового узнаете.
Технологии не стоят на месте. Требуется все большая вычислительная мощность и при этом меньшие размеры и меньшее энергопотребление. Веб 10 лет назад и сейчас это разный веб.
Игры 10 лет назад и сейчас это разные игры. Мобильники сейчас и 10 лет назад это разные устройства.
> Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают
> для того чтобы они могли вообще не отлаживать и не оптимизировать
> свой код. А в вэбе считают что мощности и пропускные способности
> увеличивают для того чтобы можно было больше рекламмы всунуть.
> Может они правы? Может мы вообще существуем для того чтобы есть всё
> что подают? Может скоро издадут закон по которому пассивные пользователи (не
> так часто покупающие новые компы и не кликающие по рекламме) будут
> преследоваться по закону?Вы путаете программистов с работодателями... :)
> Да, программисты всё меньше хотят думать. Они считают что мощности компьютера увеличивают для того чтобы они могли вообще не отлаживать и не оптимизироватьХе, попрогал бы ты под iOS/Android, такого не писал бы.
> Да, программисты всё меньше хотят думать. Они считают что мощности компьютера
> увеличивают для того чтобы они могли вообще не отлаживать и не оптимизировать свой код.
> А в вэбе считают что мощности и пропускные способности увеличивают для того чтобы можно
> было больше рекламмы всунуть.Об этом ещё Вирт писал в какие-то пархатые годы.
Когда UNIX появился, деды смеялись над ним и считали юниксойдов чем-то типа скрипткиддисов: ядро написанное не на ассемблере? ха-ха-ха!
То есть я не к тому, что переход от C/C++ на javascript -- это хорошо. Не знаю. Тучи факторов, которые свести воедино и оценить я не могу. Я к тому это говорю, что ситуация до боли напоминает ту ситуацию со входом C в системное программирование. А уж эти скорбные высказывания о том, что программист всё меньше и меньше заботится об оптимизации программы, что программы всё толще и толще, я полагаю, звучат с тех пор как следом за первым компьютером появился второй.
То, что вы описали, не является виртуализацией. обычный такой AMP (Asymmetric Multiprocessing).
> То, что вы описали, не является виртуализацией. обычный такой AMP (Asymmetric Multiprocessing).по терминологии согласен, но по сути смысловой разницы особо не вижу.
>на сотне другой армов воткнутых в слоты расширенияЭх молодежь и не в курсе что было такое время когда на транспьютеры возлагались большие надежды.
Не выстрелило.
>>на сотне другой армов воткнутых в слоты расширения
> Эх молодежь и не в курсе что было такое время когда на
> транспьютеры возлагались большие надежды.
> Не выстрелило.просто технологии были не на том уровне, а так "всё новое это хорошо забытое старое"
Новость можно было бы назвать скучной, если бы автор не упомянул "плавающую запятую":)
> Новость можно было бы назвать скучной, если бы автор не упомянул "плавающую запятую":)
Процессоров ещё нет, а сборки уже есть?! А Linux и правда впереди планеты всей...
> Процессоров ещё нет, а сборки уже есть?! А Linux и правда впереди
> планеты всей...Типа с тем же USB 3.0 не так было.