>как вы себе представляете его статически скомпонованным с kdelibs
представить можно и 11-мерное пространство, но не всегда реализовать. Должны же быть грани у разумного.
>Кому надо-то? Вам вы один её не решите!
Поэтому если это надо не только вам, то организуются команды, компании нанимают людей, если им надо. Так в-общем всё устроено в разработке по. Но если хотя бы часть будет уже готова, то в идеале должно быть проще прийти к конечному результату.
> потому что уже есть arm ubuntu например.
набор ПО под него такой же богатый, как и под x86?
>Там один в один одинаковые либы для arm, x86, mips.
Поверю Вам на слово. Остается за оптимизациями и редкими архитектурными особенностями.
В-общем предлагаю прийти к консенсусу. В сборке сильных различий нет. Не всё конечно сильно проще, но исходный набор бинарников и исходников под x86 побогаче.
Так ли не напрягаясь? Китайцев-то миллионы.
Да и потом вклад в R&D не всегда выгоден сегодня, но может выстрелить завтра. Чтобы предсказывать риски и знать будущее надо быть экстрасенсом или играть нечестно.
1) Будут серые телефоны как обычно.
2) Я лично такого не заметил ни для нативных, ни для ARM-приложений.
Если у вас есть с Play'a хороший пример «тяжелого» приложения, который именно тормозит из-за загрузки процессора, а не из-за кривости софта, было бы интересно тогда сравнить. Ну или если знаете, то оптимизированные под многопоточность. По бенчмаркам у San Diego вроде как хороший результат.
>зачем вам на телефоне тяжелые приложения
Я такого не писал. Я только снова вопрошаю, что же у вас так жрёт ресурсы. Да, браузер, но это больше в огород памяти, а не CPU\GPU.
>«Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield.»
Тысяча чертей! Вы правы. Там должно было быть добавлено «статически скомпонованное». И малая доля динамически. Прошу меня простить.
> а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену
Да, про что я и говорю. Это титанический труд, но задача решаема, если её надо решить. Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.
>Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков
У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? Само наличие библиотек не означает их внутреннюю идентичность. И дело не только в ключах оптимизации. Если есть где сравнение, было бы любопытно посмотреть, я не в курсе.
Этот вопрос мне любят задавать. И любимый комментарий к нему: 1ГБ ОЗУ мало.
Ну если любители запускали и Vista на непредназначенных для этого девайсах, то у San Diego все шансы опробовать на себе десятки операционок.
Ок, по поводу запуска. Имея абстрактное 32-битное приложение, оно в 90% случаях пойдёт на Medfield. По поводу сборки не всё так гладко, но опять-таки, некоторая доля программ соберётся обычным путём, как и под linux, без необходимости искать костыли. Насчёт ARM я столь не уверен и не имею богатого опыта, однако, думаю, не все используемые функции\библиотеки одинаковы, а потому требуют костылей для адаптации к архитектуре. Если тут я не прав, то поправьте, пожалуйста, насколько велика разница между arm \ x86 набором в NDK.
> а в чем будет разница при сборке
глобально ни в чём, по факту — в разнице в реализации библиотек\функций.
>сейчас невозможно
Согласен, многое сейчас невозможно.
Вы ставите сложные задачи. Со временем, уверен, сделают. x86 более удобная и привычная платформа для работы, где процесс портирования должен быть проще, т.к. просто опыта у людей для работы с ней больше.
>Вас не смущает отсутствие в android библиотек XWindow?
чем сложнее цель, тем больше цепочка всех зависимостей. Если у вас есть такая цель — пересоберите XWindow, системные библиотеки Android, если надо.
Я Вас понимаю, но всё дело во времени. По сути появляение смартфонов с x86 должно размыть границы между обычными компьютерами и телефонами и форсировать изменения самого Android, пусть даже путём в том числе и вашего вмешательства, если вы готовы работать как открытое сообщество.
NDK в перспективе — почему бы и нет? Но по сути вся адаптация состоит в прописывании NDK-шного компилятора за место linux-gcc, sysroot'a и сборка 32-битного кода. В конечном итоге все библиотеки и зависимости тоже можно пересобрать без костылей и ndk-make'ов.
Кстати говоря, реализация может существенно отличаться в зависимости от CPU. Хотя и стараются использовать код вторично, это не всегда эффективно. Например, в TMS320C28 есть свои рекомендации и механизма отлавливания Overflow против забития сигнатуры в область стека как c C166.
К сожалению, код является закрытым.
Прецедентов, чтобы какой-либо код открывали — не было. Во всяком случае во время эксплуатации самолёта, во всяком случае официально.
Что касается использования open source решений, как я и писал раньше, если надо использовать что-то стандартное, оно должно быть переписано. Другими словами, просто анализируется существующее решение, оценивается его оптимальность (обычно оно максимально эффективно, но к нему добавляется дополнительная защита и проверки) и затем внедряется с изменениями в виде стиля кода.
В зависимости от задач прыгаю с редактора на редактор Qt, Eclipse, Code::Blocks, MS VS, Notepad++, SCiTe, Borland\Embarcader, Emacs. Раньше недолюбливал консольные, сейчас vim'ом иногда пользуюсь.
Хотя чисто по удобству мне больше нравится Сode::Blocks.
Автор, почему нет варианта а-ля «Пользуюсь всем, т.к. всего не хватает»?
Пользуюсь, правда иногда на страницах не хватает функциональности — например один Like, а я хочу Share или наоборот. Или Adblock Plus обрезает кнопки. Поэтому, если чем-то хочу поделиться делюсь через плагин браузера AddThis. Либо через IM.
Спасибо автору за видео.
Кстати, интересно, действительно ли есть ли связь между гармоничностью и эффективностью?
Может тогда алгоритмы можно будет оценивать очень интересным образом.
Спасибо. Я достаточно подробно описал в прошлой статье процессы тестирования и инструменты.
Если интересно поподробнее узнать методологию составления тест кейсов, почитайте о систематическом тестировании.
Что касается ваших примеров — это сценарные тесты, обычно выполняются на полнофункциональной модели самолёта на земле либо уже в полёте на реальном самолёте. Наши лётчики-испытатели умудрялись тестировать «разрыв связи» и «отключение питания» в воздухе для всех систем сразу путём физического насилия, ну как и посадку без флаперонов. Наши — суровые ребята. В Airbus, к примеру, такое редкость.
Хороший вопрос. Самолёт в стадии разработки. Начало лётных испытаний планировалось на начало текущего лета. Речь идёт о C Series. Когда я над ним работал, его рисунок выглядел именно так, как модель в аэродинамической трубе + рендер с окошечками и бликами. Но в интернете ходят такие фотографии:
Быть может вы и правы, спорить не буду. Фото взято с aviationnews.
>>компилятор
>Вопрос желания.
Помимо желания это стоит больших денег и времени, которое тоже преобразуется во время. И без того дорогая разработка будет дороже.
> Atom
это замечательно, что есть такой Haskell. Теперь вокруг него надо выстроить техпроцесс, сертифицировать всё, написать стандарты, что тоже стоит денег. Бизнес не всегда благороден. Что это принесёт в конечном итоге? Через 5? 10 лет? Через 2? 3 проекта? В чём преимущества? Выгоднее ли это того, что есть? Думаю, не самые далёкие люди от техники такой анализ производят.
>Кроме того, в каких именно местах у вас такие требования
Вы точно читали статьи? Системы управления. Решения принимаются в зависимости за микросекунды, чтобы парировать ветер, чтобы избежать ошибки, если дрогнет рука пилота. Да даже если шасси, если они не выпустятся при посадке, то поднимать самолёт может быть поздно (особенно в случае аварии), кондиционирование? Не знаю, какие там системы и какие к ним требования, но при разгерметизации салона за секунды, а то и доли секунд нужно среагировать, чтобы спасти жизнь людям и выпустить те же кислородные маски.
>ужасающая трудоёмкость написания кода
Вы утрируете. Всё просто, что знаешь. Этот код писать просто, если изучить заблаговременно Software Design и Coding Standart. Код схожий и блочный. Только для пущего удобства IDE как в MS VS не хватает.
>>неуместность для работы с железками
>Это как?
Всё ли, относящееся к железу легко написать на них? Как быстро будет это работать? Как haskell работает с Interrupts (насколько я знаю — это наибольшая проблема)? Я знаю очень мало примеров низкоуровнего программирования на этих языках. То, что есть — начало появляться лишь намедни.
То, что используется в авиации — это прошедшие долгие процедуры технологии 5-10 летней давности, тщательно отобранные, задокументированные и разобранные вплоть до бита. Проверенные и надёжные.
Возможно, это изменяется и изменится и они будут применяться, если это будет просто и дёшево. Возможно, у них всё впереди.
представить можно и 11-мерное пространство, но не всегда реализовать. Должны же быть грани у разумного.
>Кому надо-то? Вам вы один её не решите!
Поэтому если это надо не только вам, то организуются команды, компании нанимают людей, если им надо. Так в-общем всё устроено в разработке по. Но если хотя бы часть будет уже готова, то в идеале должно быть проще прийти к конечному результату.
> потому что уже есть arm ubuntu например.
набор ПО под него такой же богатый, как и под x86?
>Там один в один одинаковые либы для arm, x86, mips.
Поверю Вам на слово. Остается за оптимизациями и редкими архитектурными особенностями.
В-общем предлагаю прийти к консенсусу. В сборке сильных различий нет. Не всё конечно сильно проще, но исходный набор бинарников и исходников под x86 побогаче.
Да и потом вклад в R&D не всегда выгоден сегодня, но может выстрелить завтра. Чтобы предсказывать риски и знать будущее надо быть экстрасенсом или играть нечестно.
2) Я лично такого не заметил ни для нативных, ни для ARM-приложений.
Если у вас есть с Play'a хороший пример «тяжелого» приложения, который именно тормозит из-за загрузки процессора, а не из-за кривости софта, было бы интересно тогда сравнить. Ну или если знаете, то оптимизированные под многопоточность. По бенчмаркам у San Diego вроде как хороший результат.
>зачем вам на телефоне тяжелые приложения
Я такого не писал. Я только снова вопрошаю, что же у вас так жрёт ресурсы. Да, браузер, но это больше в огород памяти, а не CPU\GPU.
Тысяча чертей! Вы правы. Там должно было быть добавлено «статически скомпонованное». И малая доля динамически. Прошу меня простить.
> а его там нет и не будет пока кто-то не пересоберет сам андроид таким образом, что бы они там появились или не напишет им замену
Да, про что я и говорю. Это титанический труд, но задача решаема, если её надо решить. Тем не менее в данном случае откинув андроид в сторону 32-битный linux должен заработать.
>Я исхожу того что набор допустимых библиотек у android_x86 и android_arm одинаков
У вас есть точные данные, что там полностью совместимый набор заголовков и интерфейсов? Само наличие библиотек не означает их внутреннюю идентичность. И дело не только в ключах оптимизации. Если есть где сравнение, было бы любопытно посмотреть, я не в курсе.
Ну если любители запускали и Vista на непредназначенных для этого девайсах, то у San Diego все шансы опробовать на себе десятки операционок.
> а в чем будет разница при сборке
глобально ни в чём, по факту — в разнице в реализации библиотек\функций.
>сейчас невозможно
Согласен, многое сейчас невозможно.
>Вас не смущает отсутствие в android библиотек XWindow?
чем сложнее цель, тем больше цепочка всех зависимостей. Если у вас есть такая цель — пересоберите XWindow, системные библиотеки Android, если надо.
Я Вас понимаю, но всё дело во времени. По сути появляение смартфонов с x86 должно размыть границы между обычными компьютерами и телефонами и форсировать изменения самого Android, пусть даже путём в том числе и вашего вмешательства, если вы готовы работать как открытое сообщество.
Orange San Diego price: £15.50 (24-month contract), £199.99 (PAYG)Прецедентов, чтобы какой-либо код открывали — не было. Во всяком случае во время эксплуатации самолёта, во всяком случае официально.
Что касается использования open source решений, как я и писал раньше, если надо использовать что-то стандартное, оно должно быть переписано. Другими словами, просто анализируется существующее решение, оценивается его оптимальность (обычно оно максимально эффективно, но к нему добавляется дополнительная защита и проверки) и затем внедряется с изменениями в виде стиля кода.
Хотя чисто по удобству мне больше нравится Сode::Blocks.
Пользуюсь, правда иногда на страницах не хватает функциональности — например один Like, а я хочу Share или наоборот. Или Adblock Plus обрезает кнопки. Поэтому, если чем-то хочу поделиться делюсь через плагин браузера AddThis. Либо через IM.
Кстати, интересно, действительно ли есть ли связь между гармоничностью и эффективностью?
Может тогда алгоритмы можно будет оценивать очень интересным образом.
Если интересно поподробнее узнать методологию составления тест кейсов, почитайте о систематическом тестировании.
Что касается ваших примеров — это сценарные тесты, обычно выполняются на полнофункциональной модели самолёта на земле либо уже в полёте на реальном самолёте. Наши лётчики-испытатели умудрялись тестировать «разрыв связи» и «отключение питания» в воздухе для всех систем сразу путём физического насилия, ну как и посадку без флаперонов. Наши — суровые ребята. В Airbus, к примеру, такое редкость.
Если есть подробные вопросы — задавайте, отвечу.
Быть может вы и правы, спорить не буду. Фото взято с aviationnews.
>Вопрос желания.
Помимо желания это стоит больших денег и времени, которое тоже преобразуется во время. И без того дорогая разработка будет дороже.
> Atom
это замечательно, что есть такой Haskell. Теперь вокруг него надо выстроить техпроцесс, сертифицировать всё, написать стандарты, что тоже стоит денег. Бизнес не всегда благороден. Что это принесёт в конечном итоге? Через 5? 10 лет? Через 2? 3 проекта? В чём преимущества? Выгоднее ли это того, что есть? Думаю, не самые далёкие люди от техники такой анализ производят.
>Кроме того, в каких именно местах у вас такие требования
Вы точно читали статьи? Системы управления. Решения принимаются в зависимости за микросекунды, чтобы парировать ветер, чтобы избежать ошибки, если дрогнет рука пилота. Да даже если шасси, если они не выпустятся при посадке, то поднимать самолёт может быть поздно (особенно в случае аварии), кондиционирование? Не знаю, какие там системы и какие к ним требования, но при разгерметизации салона за секунды, а то и доли секунд нужно среагировать, чтобы спасти жизнь людям и выпустить те же кислородные маски.
>ужасающая трудоёмкость написания кода
Вы утрируете. Всё просто, что знаешь. Этот код писать просто, если изучить заблаговременно Software Design и Coding Standart. Код схожий и блочный. Только для пущего удобства IDE как в MS VS не хватает.
>>неуместность для работы с железками
>Это как?
Всё ли, относящееся к железу легко написать на них? Как быстро будет это работать? Как haskell работает с Interrupts (насколько я знаю — это наибольшая проблема)? Я знаю очень мало примеров низкоуровнего программирования на этих языках. То, что есть — начало появляться лишь намедни.
То, что используется в авиации — это прошедшие долгие процедуры технологии 5-10 летней давности, тщательно отобранные, задокументированные и разобранные вплоть до бита. Проверенные и надёжные.
Возможно, это изменяется и изменится и они будут применяться, если это будет просто и дёшево. Возможно, у них всё впереди.