Ilia Vereshchagin @wwakabobik
SDET
Информация
- В рейтинге
- 1 114-й
- Откуда
- Сербия
- Зарегистрирован
- Активность
Специализация
Test Automation Engineer, Quality Assurance Director
Lead
От 10 000 €
Python
Git
English
Software testing
Selenium
Cypress
People management
Test Automation
Quality assurance
Site testing
представить можно и 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 летней давности, тщательно отобранные, задокументированные и разобранные вплоть до бита. Проверенные и надёжные.
Возможно, это изменяется и изменится и они будут применяться, если это будет просто и дёшево. Возможно, у них всё впереди.