Комментарии 125
Этакий qemu-user. Тот тоже сисколлы хостовому ядру перенаправляет.
Нереально круто. По факту конкуренция на рынке планшетов увеличится, что не может не радовать.
И это не говоря уже обо всяких планшетах на Win x86-64, там цена процессора вообще превышает все разумные пределы даже с учётом их достоинств. А за разумные деньги в таких планшетах стоят только атомы, от которых волосы встают дыбом. Так что если Qualcomm дотянется своими ARM-овскими руками до полноценной Windiws, то это положительно скажется и на рынке планшетов в том числе. Да и на рынке смартфонов, возможно. В общем успехов им в начинании!
РРЦ и настоящая цена для OEM — две абсолютно разные вещи, в случае с Intel.
Нужен инсайд от OEM сборщиков. Просто так, под запись, вам это никто не скажет. Партнерские соглашения, более чем уверен, содержат NDA.
Но можете попробовать посчитать самостоятельно. К примеру, с этими процессорами продаются fanless PC на aliexpress, за 200-250 долларов предлагаются в barebone формате (корпус + бп + мать + проц).
ну вообще то для неё и arm компилятором можно было что-то собрать, и ставить в обход магазина. Вроде тот же 7-zip собирали
Моя мечта — 8 дюймов на Винде со стилусом. Три-четыре года назад был на этот счет Asus vivotab 8 на Intel Atom, но этой модели были свойственны проблемы со стилусом; я их вполне словил на своем экземпляре, который со временем как-то совсем захворал (пошли проблемы с аккумулятором) и сдох. А нынче либо стилус, либо винда, либо 8 дюймов, либо цена заоблачная и не в России. Хочу надеяться, что с переходом на ARM количество моделей на Windows расширится достаточно, чтобы среди них нашлись 8-дюймовые модели со стилусом.
Переход на x86 был, в том числе, обусловлен тем, что их производительность была выше. А тут пытаются перейти, потому что арм дешевле и менее жруч. Так что вряд ли будет как в OS X
я года четыре назад поставил 10.6 хакинтош на нетбук 1.6ghz Atom (типа сделал утилизацию в милый сувенир), это было ноздря в ноздрю с iBook's G4 1.2ghz.
CS2 фотошоп (а он был только PowerPC!) на ощупь был даже малька пошустрей, чем до этого на XP. из-под Rosetta.
Возможно, когда-нибудь в будущем самой популярной операционной системой в мире снова будет Windows.
Хмм. Понимаю, что недавно у Андроида была важная веха и всё такое (самая распространенная ОС). Но таки сравнивать мобильные ОСи и десктопные как-то пока всё-таки ну нельзя. И если сбросить мобильные ОСи со счетов — Винда не самая ли популярная ОСь до сих пор?
Вообще это здорово, что софт от х86 будет совместим, это даст жизнь планшетам на windows 10 и возможно займет место офисных десктопов. Вот бы посмотреть как фотошоп работает на ARM, если adobe еще выпускает x86 версии.
Х86 он выпускает. Хоть сейчас можно взять какой нибудь планшет на атоме и посмотреть, как собственно все это дело работает. По моим ощущениям не очень.
Большинство профессионального софта с тачскрина не юзабельно, только подключив мышку можно нормально пользоваться.
Да и с производительностью проблемы — практический на любом ноутбуке все это работает ощутимо быстрее.
https://www.youtube.com/watch?v=A_GlGglbu1U
По цене — наличие виндовых планшетов за 5-7 т.р. с клавиатурой (в местных магазинах!) не показывает высокой стоимости атома.
Понятно, что если винда будет на АРМе запускать легаси-приложения, то выбора будет больше. Но в целом — это не похоже на перемену мира.
… а благодаря повышенному объему внутренней памяти до одного гигабайта пользователь сможет комфортно выполнять любые задачи с помощью данного устройства.
А уже более-менее вменяемые мобильные-мобильные процессоры Intel идут по ценам в районе $280 — 400. Я, конечно, понимаю, низкий TDP и всё такое, но это всё таки явный перебор.
Внутре же вашего примера списанный процессор четырёхлетней давности. Неудивительно, что их хоть как-то пытаются сплавить.
А в нормальный запуск виндового легаси я не верю вообще. Это скорее стратегия постепенного перетягивания всех на новые .NET приложения, которые будут работать куда быстрее на этих камнях благодаря JIT.
Отец некоторое время назад купил планшет на Windows с атомом, Irbis какой-то. 2 Гб ОЗУ, 32 Гб ssd (emmc?), где-то тысяч за 10 плюс-минус. С аналогичным объемом памяти 10" android-планшеты были дороже.
Спустя некоторое время друг купил тоже Irbis, другой модели, там уже 4 Гб ОЗУ и 64 Гб накопителя.
Так что я поспорил бы с тем, что arm-ы дешевле идут.
Хотел прям тоже самое написать, прям опередили)) Только я Ирбис брал за 6700 руб. Неплохая машинка, брал для редкого девелопа в полевых условиях. Тянет визуал студию 2015 вполне неплохо. Правда если в Опере открыть больше 10-15 кладок — то начинаются тормоза жуткие. Батарейка долго живет, клава в комплекте с тачпадом и это чехол одновременно — это вообще круто. Одним словом очень понравилось и софт любой поставить можно.
Из минусов тачскрин не успевает правильно обрабатывать касания если быстро набираешь и ошибается и жмет соседнюю клавишу или точку.
они смогут запускать любые приложения для x86, от «Фотошопа» до старых игр.В статье не сказано, какой пользовательский интерфейс использовался на демонстрации. Если привычный графический под курсор и мышку, то да, смогут. Если же плашечный ModernUI (что гораздо вероятнее на смартфонах и планшетах), то не смогут — слишком мелки элементы графического интерфейса, а пятно контакта пальца слишком велико.
Ну разве что придумают какой-нибудь преобразоватор… Но даже в этом случае придётся тренировать себе новый навык управления.
Необходимости компилировать под ARM нет, так как x86 код в этой системе и так хорошо работает.
При этом система 64-битная.
Хотя, если я правильно понял статью, запускается именно ARM код, который генерируется перед первым запуском приложения из x86 кода.
Раз уж 7-Zip гордо демонстрируют, продемонстрировали бы и результаты его бенчмарка.
А все из-за того что ARM очень не хило подняли производительность за последние 5 лет.
А apple os X перепишет для работы на своих А процах )
Может и Интел снизит цены раздутые дальше некуда на свои камни.
А главное что Snapdragon 835 полноценный и очень крутой SOC
LTE модем и производительная графика и прочие вкусности на борту )).
А теперь как я думаю о главном:
Если еще не будет вендор лока… т.е. винда в отличии от андроида обновляется то централизованно и долго ))
Это будет супер ведь мне ничего не помешало на 8 ноут накатить 10 диск только на SSD поменял.
А попробуй так с андроидом том вообще может и такого производителя телефонов уже не быть года как 2.
И главное добавить нативный запуск андроид приложений…
и не забывать про интеграцию с линуксом которую потихоньку пилят…
Кардинально иная ситуация с телефонами — получить официальный апдейт на 3-4 летний флагман (к слову, скорее всего купленный за те же 700-800 долларов, что и мой ноут) скорее всего невозможно. Более того, вполне возможно что и поставить самый последний андроид — тоже.
Так что с вашим утверждением, что со старыми ноутами существуют проблемы — не согласен, если не брать все ноутбуки, вплоть до тех, которые были во времена выхода windows xp и приводить их в пример плохой экосистеме обновлений на андроїде.
На рынке Windows+железо ситуация с поддержкой на порядок лучше, на мой взгляд.
Так что на Windows+Intel ситуация может быть и лучше, но на Windows+Qualcomm — смотрите Windows Phone, где обновления приходят точно так же, как и на Android (не приходят).
У меня Lumia 930 обновляется регулярно.
Речь видимо про предыдущие модели — мелкомягкие с нокией кинули всех с обновлением. Сам обладатель люмии 800. Когда брал объявляли что будет доступно обновление, взял купил, а они выкатили одно обновление до 7.8 и на этом гудбай Вася, жуй опилки. И народ слышал ковыряли платформу, говорят что ничего не мешало выкатить обновление до 8 виндовс, но не сделали. Софта в магазине как не было, так и нет, от слова "с куриную ширинку". Увы, телефон стал просто тупой звонилкой, вкидывать теперь жалко, продать — никто не возьмет. До того единственного обновления было все печальней.
Лично на мой взгляд тут только одна цель — бабки. Людей специально кинули чтобы они встали и пошли купили новый аппарат. Выкатить обновление могли бы, но не захотели. Ну понятно что кроме случаев откровенно слабого железа.
Причём, если судить по всяким туманным намекам-экивокам от ОЕМов, Квалком как-то по хитрому лицензирует свои BSP вендорам, то есть вендор смартфона имеет право выпускать BSP только с определенными версиями ОС. Если BSP используется для разворачивания другой версии ОС, то это нарушение лицензионного соглашения со всеми вытекающими. И получается ситуация, что для того, чтобы выпустить официально новое обновление, вендор должен заплатить Квалкому за поддержку вне стандартной поддержки. Естественно, никому это не надо, и получается, что самые лучшие железки Квалкома поддерживаются от силы 2-2,5 года даже Гуглом или Микрософтом.
Квалком очевидно зажрался, и вполне понятно, почему Эпл пытается соскочить с их модемов и судится с ними.
так это связано с тем что abi у ядра linux для драйверов не стабильно и меняется от версии к версии, поэтому нельзя загрузить модуль ядра от одной версии в другой, в отличии от винды.
Так-так-так, можно ли надеятся, что вот, наконец-то, в ARM-мире будет унифицированный загрузчик, предположительно UEFI? Наконец-то хоть какие-то подвижки в этом плане.
Чем именно текущая ситуация не устраивает?
Потому что сейчас нет единого загрузчика. Каждый SoC грузится как умеет, у одного IPL загружает начало флеш-памяти и прыгает на нее (примерно как загрузчик MBR), у другого — загружает SPL с первого FAT32-раздела флешки. Один в качестве SPL использует устаревший u-boot без поддержки загрузки по сети, у другого свой проприетарный, у третьего вообще Android-загрузчик и Android Recovery.
Из-за этого у нас нет единого формата образов. На компьютере я могу скачать iso, записать его на флешку и загрузить его на любом компьютере. Я могу разметить диск, установить загрузчик и быть уверенным, что он загрузится и на другой материнской плате с другим процессором.
Для ARM, если вы хотите поддерживать, скажем, Allwinner, Amlogic, iMX, и Broadcom, нужно знать все особенности загрузки конкретного SoC, особенности и недостатки SPL, и делать образы для каждого конкретного SoC, а зачастую и каждой конкретной платы. В самом Linux-ядре есть Device Tree, можно сделать одно ядро для одного SoC, а не для каждой платы. А хотелось бы унификации, чтобы хотя бы можно было сделать один образ для разных SoC.
Поскольку ARM-то продает свои ядра одинаковыми для семейства :) а вот остальную периферию каждый производитель лепит как на душу ляжет.
Один пример, чтобы закрыть этот спор. Intel FSP — Firmware Support Package. Погуглите подробности, если заинтересуетесь. FSP производит начальную инициализацию Интеловского SoC-а, еще до операционки — в UEFI, точнее, PI. Казалось бы — Интел, гигант, процессы, стандартизация и все такое, уж свои-то SoC-и может сделать если не унифицированными, то хоть совместимыми снизу вверх. Ага. Смотрим на страничку Интела с версиями FSP:
https://github.com/IntelFsp/FSP
Впечатляет, да? При том, что это закрытый код, бинарники, поскольку содержит фиксы для различных версий чипов, и то, что будет работать на одной версии, может подвесить или вообще сжечь другую.
А теперь представьте себе не более-менее управляемый Интел, а независимое и конкурирующее сообщество. Их-то как привести к единому стандарту? Каждый — КАЖДЫЙ — SoC имеет свои баги, для которых нужны свои программные фиксы, и разумеется, один фикс не подходит к другому даже в пределах одного производителя. Я уж не говорю, что любой SoC — это десятки и сотни конфигурационных регистров, которые не обязаны быть одинаковыми и располагаться по одному и тому же адресу опять-таки даже для чипов одного производителя.
На самом деле, процедура загрузки довольно несложна: надо найти консоли ввода и вывода, найти на шине контроллер диска (или ethernet), найти там диск, на нем найти файл загрузчика и передать ему управление. Однако в практических реализациях этих простых, на первый взгляд, вещей наличествует такой зоопарк, что про какое-то единство не стоит и задумываться.
Существует также проект coreboot, выросший из стремления к быстрому единому загрузчику. Вот здесь — список исходных кодов для разного железа — материнки, мосты. Посмотрите на это раскидистое дерево:
https://github.com/coreboot/coreboot/tree/master/src
Мне жаль, что я разрушил Вашу мечту о едином загрузчике, но мир, увы, сложнее, чем кажется. UEFI — наше все, именно благодаря поддержке стандартов UEFI (и Legacy BIOS) для PC Вы можете «разметить диск, установить загрузчик и быть уверенным, что он загрузится и на другой материнской плате с другим процессором». А на копеечных платах с АРМами он не поддерживается — нашли единственный работающий (хоть и через одно место) путь для загрузки, и ладно
Либо вы не поняли мою мысль, либо вы где-то видите противоречие, где не вижу его я.
Я бы хотел, чтобы каждый производитель, вместо того, чтобы писать свой форк u-boot или проприетарный загрузчик, реализовывал бы минимальный стаб с самой низкоуровневой инициализацией (CPU, память, SEC-стадия в UEFI, грубо говоря), а производитель платы (условной Rasiberry Pi) реализовывал бы инициализацию периферии (PEI-стадия), и чтобы эти данные хранились не на MicroSD, а на отдельной памяти, как на x86. Это совершенно не обязательно должен быть UEFI как таковой, главное — договориться о типе хранения payload. Т.е. пусть это будет такой coreboot с внешним стандартизированным payload на SD-карте. Да пусть хоть обычный u-boot, который бы загружал стандартизированный файл со стандартизированного раздела на карте и прыгал по его EP.
К тому же, UEFI есть и для ARM, и некоторые (немногочисленные) платы идут сразу с ним.
А под одним образом для разных SoC я имел в виду унификацию на уровне IPL, например, хотя бы такую, чтобы все SoC пытались загрузить SPL с одного и того же фиксированного адреса на флешке. Например, чтобы загружались 4 КБ с начала флешки и исполнялись. Так можно было бы сделать один большой образ без загрузчика, в котором была бы куча ядер и настроек для разных SoC и плат, и кучу маленьких загрузчиков для каждой платы, каждый из которых инициализировал бы оборудование и загружал ядро для этой платы. Таким образом, можно распространять только один большой образ, который будет работать на всех платах, и кучу маленьких загрузчиков для каждой платы отдельно, которые нужно однократно записать в начало флешки при записи образа, по стандартизированному адресу.
Пожалуйста, прочитайте хотя бы первую главу из книги «Embedded Firmware Solutions». Я Вам сейчас ее пересказываю. Книга написана отличным, доступным стилем, а я чувствую, что пересказываю ее довольно коряво :)
UEFI, вроде даже с EDK2, есть и для Raspberry :) Детально не вникал, просто запомнилось, когда читал о другом. Погуглите. В i2c чип прошивается, что есть на expansion board.
IPL — это, грубо говоря, UEFI BIOS. Он на плате (внутри SOC его сделать сложновато) в микросхеме NVRAM.
SPL — это загрузчик, соответствующий UEFI стандарту. Он находится на диске, флешке, где угодно еще. Его не надо специально писать, он и так есть, в исходниках, Линуксовый или чей-то там еще.
Собственно, все так сейчас и есть в мире РС. В мире дешевых плат на АРМ не так, но тут уж производители сами себе буратины.
Тут вот какое дело. Существующая сейчас философия разделения функций UEFI и ОС гласит следующее: в BIOS (IPL) мы производим только минимально необходимую инициализацию периферии, достаточную, чтобы получить консоли ввода-вывода отладочной информации, получить доступ к диску и загрузить в в память загрузчик (SPL), находящийся по стандартному пути (аппаратура + файловая система), а затем передать ему управление. Далее загрузчик грузит ОС и уже она — именно она — производит всю остальную инициализацию SoC.
Причин данного разделения несколько. Одна из них, очевидная — не нужна аппаратура (программатор), чтобы править обнаруженные с течением времени баги в железе путем перепрошивки BIOS — не всякий юзер подцепится программатором (где его взять?) к материнке, одно неосторожное движение — и вместо компа кирипич. Вместо этого на ОС накатывается обновление от производителя чипов, пользователь жмет кнопку Ок и все счастливы. Второе — людей, которые могут работать с BIOS, сильно меньше, чем людей, которые могут работать с ОС.
Как-то так.
IPL — минимальный загрузчик, который инициализирует минимальное количество оборудования (CPU, память на минимальную частоту) для SPL и что-то внешнее (SD-карту, USB для загрузки с USB-флешки, NAND). У Allwinner он расположен на 32 КиБ ROM внутри SoC. Он загружает следующий загрузчик (SPL) определенного формата (у каждого производителя SoC он свой) по определенному смещению и передает ему управление.
SPL — u-boot под конкретный SoC или плату, от производителя. Он инициализирует больше оборудования, инициализирует память под более высокую частоту, и загружает ОС.
Если бы хотя бы формат файла SPL был одинаковый между разными производителями, а IPL ожидал бы найти его по одному и тому же смещению на SoC разных фирм, это уже бы сильно улучшило ситуацию (для меня).
Если сформулировать до конца, Вам нужна поддержка некоего стандарта IPL. Но не уже существующего UEFI BIOS, а какого-то другого :) Вот я и спросил в самом первом вопросе — зачем?
Либо производитель поддерживает UEFI и идет со всеми вместе по широкой ровной дороге, либо, если нет ресурсов/времени/желания это делать, ищет узкие кривые проприетарные дорожки загрузки.
Программа максимум: перенести всю инициализацию оборудования на саму плату, т.е. чтобы оборудование было полностью инициализировано до попытки обращения к, скажем, MicroSD, на которой записана ОС, и унифицировать загружаемые данные на MicroSD в смысле формата (заголовка) payload, смещения и/или путей. Скажем, чтобы одноплатники разных производителей умели, по аналогии с компьютерным Legacy Boot, полностью инициализировать оборудование, загружать первые 446 байт MicroSD-карты, начиная с нулевого смещения, по фиксированному адресу в памяти (или адреса из заголовка payload), и прыгать на них. Если сделать загрузку описанным образом, наши 446 байт на MicroSD не будут содержать код под конкретный SoC или конкретную плату, и смогут выполняться на любом процессоре ARMv7 или ARMv8.
Насколько я понимаю, сейчас так не делают в основном из-за того, что внутрь SoC перезаписываемую память вставлять дорого, делать SPL внутри SoC неперезаписываемым неприемлемо (пропадает возможность управления инициализацией оборудования), внешняя память тоже дорогая, не всегда есть возможность ее вообще подключить только для загрузки (например, у SoC только линия для MicroSD и eMMC, отдельный чип для хранения SPL подключать некуда).
Преимущества программы максимум: чтобы поставлять ОС, скажем, Debian, достаточно собрать ядро с DeviceTree под все необходимые SoC (это возможно уже сейчас, можно сделать ядро, которое будет запускаться на AmLogic, Tegra, i.MX) и написать 446 байт кода, который бы загружал ядро и прыгал на него. Получится один образ MicroSD-карты под все SoC, а не для каждого свой.
Программа минимум: сделать стандарт способа загрузки SPL из IPL, унифицировать загружаемый SPL с MicroSD в смысле формата (заголовка) payload, смещения и/или путей. Пусть это так же будут совершенно разные SPL, которые инициализируют оборудование, но чтобы они все загружались с ожидаемого места. Чтобы точно знать, что IPL ожидает SPL на MicroSD-карте, с таким-то стандартным заголовком, с нулевого смещения карты.
Преимущества программы минимум: чтобы поставлять Debian, достаточно сделать один общий образ ОС, первый мегабайт которого забит нулями (т.е. без SPL), и кучу маленьких мегабайтных SPL к нему, для каждой платы.
Что имеем сейчас: для Allwinner нужна одна разметка SD, запись SPL по одному смещению на MicroSD и специальные fex-файлы для инициализации оборудования (DeviceTree не поддерживается стандартным SPL), для Amlogic своя разметка и смещения, для других SoC тоже все разное.
В процессе поиска обнаружилось, что в последних i.MX применен подход программы максимум:
…some modern SoCs (for example, Freescale i.MX6) have a vendor-provided boot loader with device tree on a separate chip from the operating system.https://en.wikipedia.org/wiki/Device_tree
Если мы переходим в волчий мир капитализма и хотим выпустить миллионнным тиражом, например, что-то типа наручных фитнес-часов на высококонкурентном рынке, то из технической сферы мы уходим в бизнес и к нам сразу же начинают приставать всякие приземленные люди. Сначала финансисты, которые думают о прибыли компании с данного продукта, что есть, главным образом, разница между отпускной ценой устройства с завода и ценой комплектующих. И если Вы финансистам скажете, что надо поставить флешку ценой дороже хоть на 1$, чтобы в него влезли не только наши проприетарные драйверы-инициализаторы, а весь Device Tree, то встретите очень агрессивное неприятие. Например, обратите внимание, что Windows лезет за драйверами на свой сайт, вместо того, чтобы хранить их на локальном диске, хотя, казалось бы — диск-то не их. И то…
Далее. Инициализация, точнее поиск «всех возможных» шин и всех возможных устройств на всех возможных SoC также занимает время. Тут уже придется бодаться с маркетологами, которые скажут нечто вроде «Слушай, ты мне сейчас предлагаешь объявить среднему потребителю в американской глубинке, фермеру Джону, что ему придется глядеть на пустой экран целую минуту, потому что у нас самый лучший софт, который обнаруживает все возможные чипы? А что, если он задаст вопрос „А мне-то какая разница? Я хочу иметь рабочий экран через пару секунд, как у всех остальных производителей. Либо вы это сделаете, либо я куплю продукт конкурентов“.
Есть еще множество нетехнических причин, но этой полутехнической пары хватит вполне. ARMы ведь не ограничиваются Allwinner и Broadcom. Их ОЧЕНЬ много типов, и именно этот факт портит всю картину. Наверное, на более чем половину типов ARM SoC информация (в том числе — документация) не поступает наружу вообще, это очень закрытый B2B рынок — как в целях сокрытия от конкурентов, так и как лишняя ступень защиты от взлома хакерами путем эксплуатации аппаратных багов.
К тому же есть сильное подозрение, что дьявол — в деталях, точнее, в Интеловских оптимизирующих библиотеках. gcc, конечно, великая вещь, но Винда — это ОЧЕНЬ большая операционка, и Microsoft в ее нутре копаться с тонкой оптимизацией ради одного процессора не будет, разве что действительно получилось нечто реально экстраординарное.
Давайте подождем результатов тестов. Может быть, мы стоим на пороге переворота в мире РС. А может быть, с обычным разрекламированным частным случаем
"в Интеловских оптимизирующих библиотеках"
не думаю что винду с mkl собирают.
Интеловские библиотеки — это не только FFT, это еще и пузырьки конвейера, мультитредовость, счетчики производительности и много всего другого. Если от этого зависит скорость работы ядра — хочешь не хочешь, а поиграешься с тулзами. Тем более, что консультанты же есть, были бы деньги, а их у MS вроде хватает
Причем кину камень конкретно в огород майкрософта — архитектурно это то еще мессиво из новых недоработанных фич и старых костылей для совместимости, к тому же маркетинговые дешевые уловки не делают им чести… Документооборот уже десятилетие топчится на месте, в основном из-за их офиса. До этого десятилетие топтался веб из-за осла. Те же области куда их не пустили — сервера и мобилки развились наиболее прогрессивно.
А по поводу «не пустили в мобилки» — это вы пошутили, я полагаю? Windows Mobile был по факту стандарт для коммуникаторов долгое время. Просто ребята долго почивали на лаврах и продули конкуренцию всяким борзым iOS и Android
Подробнее можно глянуть, например, здесь: https://www.youtube.com/watch?v=w4WAPTJM8E0
Совершенно неудивительно, что он занял 95% рынка. Потом, правда, Microsoft остановила его развитие на 5 лет. За это время конкуренты подтянулись. Стандарты также потихонечку подтягивались, правда, описывая те же вещи не так, как они были реализованы в IE6 за годы до этого, что конечно же добавило головной боли веб-разработчикам и испортило репутацию браузеру за то что он не поддерживает стандарты. Ну не было нужных стандартов когда браузер вышел, что поделаешь. А поддерживать IE6 приходилось и 10 лет после его релиза. Вот потому и все такие злые на этот браузер :)
Сегодня же факт предустановки IE/Edge как-то не сильно помогает популярности этих браузеров — Chrome гораздо популярнее, даже если считать только по десктопам.
Я правильно понимаю что при динамической рекомпиляции образ инструкций в памяти будет другой и все программы считающие хэш от какого-нибудь куска кода навернутся. Или рекомпилируемый код идёт в отдельный бинарь загружаемый отдельно при вызове горячего метода. Тогда вопрос где они хранятся и не может ли кто их подменить?
Прощай Windows…
Под вопросом только сами драйвера, которые уже сейчас очень сложно пилить Opensource (Для х64 требуется цифровая подпись, которая стоит огого сколько, а отключить эту проверку с каждым
… С одной стороны M$ конкретно потеснят Linux/Android… С другой — Intel и AMD придётся тоже переходить на ARM, поскольку технология очень популярна и продолжает захватывать рынок всего и вся…
Причём WinXP вполне себе производительная получается (Если учесть слабую производительность флешки и огромный Оверхед от не самой быстрой эмуляции).
А тут — «Нативный код» и всё такое. Тоесть на какомнить H3 должна тормозить примерно также, как на обычном компе с soc.775.
Простите, но вам не проще ли купить на авито б\у ноутбук, вскрыть его и дернуть с него материнку с некоторыми потрахами — запилить все это в свой корпус и накатать на него все что нужно и нативно с неплохой производительностью? Высокая производительность, отсутствие шума, нативно x86, низкоеНеужели есть смысл крутить на апельсинке? Дернув плату с ноутбука можно сделать очень тонкий и небольшой девайс с богатой периферией.
Я сам время от времени работают над таким проектом, есть ноут с разбитым в хлам корпусом, планирую дернуть только материнку из него. Ноут хоть и древний, но накатил на него виндовс 10 — работает очень шустро. Замер толщины материнки прям кричит сделай корпус для меня тоньше 1 сантиметра) пока думаю сделать из него мультимедиа плеер.
Есть еще вариант — распотрошить и оставить дисплей, сделав например мультимедиа фото рамку с возможностью отображения разных данных жмакая на пару внешних кнопок через ардуино. Или утром встал, жмакнул на кнопку включился дисплей — глянул погоду, может какие короткие новости.
Вендекапец всё равно настанет!
Кого как, а меня больше беспокоит тот факт, что secure boot на arm uefi неотключаем...
Планшеты нафиг не нужны…
Производительность таких решений вызывает вопросы.
Мне кажется пойдут ответвления, кто-то станет ярым полклоником виртуальной реальности, тому надо будет супер производительные стационарные машины, ибо другие пока не тянут эту дребедень, а кому 2д достаточно тот и «мобилой мегамонстром» обойдется =)
Если же проблемы будут, то коснется ли это программ способных эмулировать x86 комманды (эмулятор boschs например)
Windows 10 Pro нативно работает на ARM-процессоре Snapdragon 835