Вопрос из разряда "мне кажется, что я тут познал ньюансы, пострадаю-ка я хернёй на собеседовании за счёт конторы". Не познал, даже близко.
"Задержка на UI thread = падение приложения" это, для начала, альфа и омега любой мобильной оси по состоянию "десять лет назад". Никаких там пяти секунд, не надо терзаться. Сразу, иногда и без показа UI. То, что на какой-то оси теперь это по другому, никак не меняет простой основы: так делать нельзя. И это единственный правильный ответ.
Не надо филигранно направлять незаряженный 9мм на человека - потому что не заряжен он сегодня, а завтра очередной копатель в ньюансах решит, что нашел идеальный угол снятого предохранителя, при котором на него можно дунуть и он снимется, а так не, стрелять не будет. Ну, пока оппонент не чихнет.
Копания в нюансах подобного типа с начинающими приведет к тому, что они где-то решат "так не рухнет же сразу, использую". И потом ровно этот же собеседующий будет разгребать последствия в виде лапши, от которой падает очередной билд.
Умельцы работать с деталями, господь жги. А потом после таких умельцев двадцатилетний код, который надо вывести в асинхрон, бо он из-за "знания ньюансов" втыкает на каждом шагу, а умельцы сидят и рассказывают тебе, как же это теперь невыразимо сложно.
Бедный сотрудник Норникеля. Стоит он в -40 и пытается понять, за каким чёртом ему трясти кирпич весом под килограмм и почему нет отдельной кнопки для включения фонарика. А его друг, глядя на пролетающие мимо кирпичи, философски думает "опять поди освещение отключили".
У меня был use-case подключения телефона в работе 24/7 без возможности самому его в случае чего перезагрузить. После вполне продуманной настройки и беспроблемной работы "спутника" первым отказом был вздувшийся от постоянной зарядки аккум. Зарядка при этом была медленная, но влом было разбираться, как уйти от проблемы.
Решение какое-то такое - как правило, нужно кинуть резистор с плюсового контакта на сигнальный, определяющий наличие батареи. Номинал методом тыка - уровень напряжения на контакте даёт планшету понять уровень зарядки. Отсюда, некоторого значения отличного от нуля будет достаточно. На плюс с минусом - либо понижайку с 5в до 4 с лихом, либо (как правило) просто те же 5в медленной зарядки, так как часть вольтажа в любом случае упадет через резистор на сигнальный контакт. У меня так сработало и в итоге спутник уже третий год работает.
Отсюда, заведется почти любой - вопрос в том, чтобы распиновку аккума понять. А оставлять аккум - это гарантия либо проблем с корпусом, оторванным раздувшийся аккумлм, либо внезапного прекращения работы, потому что ампеража от аккума перестало хватать для тяжёлых задач (причем, отказ резкий, рандомный и всегда не вовремя), либо при плохом раскладе - да, пожар.
Я честно, теряюсь в догадках, что значит "ушатать" (убить диск? сделать его медленным?), о какой конкретно связке HA и BT идет речь и так дальше. С возрастом я становлюсь все более ленивым, отсюда я даже прояснять пожалуй не стану, а сразу скажу - что-то вы делаете фатально не так, переделывайте.
Мой конфиг крутится на сервере в докере где-то года три уже. Там не пара устройств, а пара десятков от разных вендоров (Tuya + Xioami + Samsung, что-то там еще, уже не вспомню). Описанный датчик брался сразу в количестве 4-х штук в момент, когда стоковая фирмварь на них отчаянно тупила, описанная мной интеграция была в зародыше, хотя и уже неплохо работала и так дальше, и тому подобное. И мягко говоря, я знаю, о чем говорю, бо все эти прыжки с перепрошивками я уже давно прошел.
Ни разу я не помню каких-то вопросов по скорости из-за "записи логов" при том, что у меня в качестве HDD обычный Seagate Barracuda на 7200 rpm. Потому что дешево и сердито. На текущий момент Xiaomi апнули стоковую фирмварь так, что коннект из их приложения к датчику пошел намного резче, а описанная интеграция работает вообще без проблем, если не крутить настройки, которые, повторюсь, особо нет смысла крутить. Для задач домашней автоматизации частоты отсылки пакетов за глаза, другие задачи решать таким датчиком, мягко говоря, странно. Отсюда, если есть желание использовать и стоковое приложение, и HA - в миллион примерно раз проще остаться на BT.
Не помню, как там с ценами на ZigBee-хабы, но в среднем, если ты берешь какую-то железку для домашнего сервиса компактного размера, это будет либо Rapsberry, либо пободбные ей мини-платы, либо что-то нибудь типа Mele. Bluetooth на борту, никакие хабы не нужны, можно работать. Ну и так, конфиг - не паяльник, BT был дешевле, чем то же самое с ZigBee. Как сейчас, не знаю, ибо просто не нужно.
Ну и финально, я даже не стану спорить на темы типа HA vs Яндекс-хаб. Нет смысла сравнивать по гибкости и возможности втащить в себя так-то три инфры разных "умнодомопроизводителей". Это не говоря о том, что весь Яндекс в плане IoT - это перебрендованная Tuya. И работать с Tuya напрямую без в них в качестве прокладки адски удобнее просто.
На деле, это не проблема с подсветкой синтаксиса, здесь просто наиболее хорошо видно. Это в целом какой-то баг в дереве символов. Из-за этого в конкретном месте, как правило, отваливается сразу подсветка, навигация, автодополнение - ибо, что логично, нет другого пути, чтобы их сделать кроме как пробежаться по дереву символов.
В личку вполне. Но круто будет, если это минимальный, но рабочий проект.
Если коротко, то это совсем не просто запуск симулятора. Это, как минимум, получение surface этого симулятора, определение того, как именно в билд-системе происходит перестраивание бинарника с инжектнутым куском нового кода, отработка всех случаев, когда preview получить не получилось (а они крайне частые даже в банальных примерах), и "многое-многое другое".
Со стороны наверное да, выглядит просто. Но можно просто взглянуть на тот же Injection, который тоже всего лишь выцепляет строку компиляции конкретного файла и подкидывает новый dylib процессу. При внешней простоте все крайне непросто.
Возможно, когда мы немного детерминируем "переваривание кода" в данном конкретном случае. Я верно понимаю, что ожидаемый от подсветки результат - это что .haptic() и следующие вызовы функций подсвечиваются тем же цветом, что и .analyticsScreen()? Или там есть ещё проблемы?
Просто подсветка банально растет от дерева символов и выходит в какой-то дефолтный цвет в случае, если в конкретном месте что-то не получается идентифицировать - допустим, onReceive несколько штук и мы не можем по какой-то причине выбрать конкретную реализацию. Или вообще не можем отрезолвиться.
Пример бы кода минимальный, но рабочий, чтобы не гадать по скриншотам.
Мы не используем именно sourcekit-lsp по ряду причин. Одна из самых очевидных - нам пришлось работать с SourceKit, в том числе и на Linux, задолго до того, как по нему вообще появилась какая-либо документация, появился open-source вариант, и тем более обертка lsp над ним. Вторая - нет смысла использовать LSP, если запрос напрямую к SourceKit быстрее, а это критично. Третья - он слишком ограничен для требований нашей IDE.
SourceKit мы используем в следующих областях: а) для вычитки текстового содержимого Swiftовых модулей, потому что иначе невозможно иметь дерево символов для стандартных библиотек / сущностей в проекте б) для отображения ошибок и предупреждений (потому что нет смысла не использовать стопроцентно корректную выдачу и делать ее самим) в) берем оттуда же fix-its, чтобы добавить к нашим, в ряде случаев они не лишние г) на время индексации и построения кэшей берем список автодополнения из SourceKit, а после индексации творчески его добавляем к нашему списку.
А так, весь функционал IDE это в основном наш движок.
Правила лицензирования не специфичны для AppCode, они одни на все продукты JetBrains. Ну а так, есть perpetual fallback при годовой подписке. Изменений в принципах лицензирования нет, не планируется.
Я понимаю, что так задумано — но в моем случае SDK индексируется каждый раз.
То есть вот именно фаза Processing Swift Modules каждый раз занимает 11 минут? Или вся повторная индексация целиком? Просто то, что там каждый раз мелькают модули SDK значит только то, что прошла проверка на наличие кэша и индексация полетела дальше. Почему так — ну вот скачали вы очередной свифтовый тулчейн, и нет никаких гарантий, что символы в нем те же, приходится перестраивать. Если без изменений, просто поняли, что содержимое модуля по ключу уже закэшировано и проскочили его.
Более того, после неудачного билда я почистил проект и индексация снова запустилась — и снова там мелькали символы из SDK.
Ну, тут спасибо компании Apple за то, что ряд исходников генерится в папке с билдом и соответственно их исчезновение при очистке вызывает переиндексацию.
Идея понятна, но пользоваться чем-то, что фризит всю систему на 5-10 минут во время работы — очень напряжно.
А вот если идет фриз всей системы — это какая-то проблема. А при фризе системы случайно не наблюдается куча процессов clang/swift? У нас там в силу необходимости сгенерить перед индексацией те самые исходники, которые генерятся в папке сборки, происходит определенная квантовая магия, возможно пара заклинаний не сходится.
Решилась подтверждением использования ключа из терминала. В Xcode все работало без проблем почему-то.
Это OC-21826. Если коротко, то ключи для GitHub сохраняются Xcode в свои Accounts, получить информацию из которых, мягко говоря, непросто. Из коробки с xcodebuild они не работают — мы там как бы просто xcodebuild -resolvePackageDependencies зовем.
Сейчас вот запустил новую версию и уже 15 минут жду, пока идет индексация всего подряд при почти полной загрузке проца.
В первый раз индексируется и кэшируется и проект, и SDK. Это долго, тут что можем — оптимизируем, но если проект крупный, в первый раз подождать необходимо. Полная загрузка проца тут by design, потому что если его не использовать весь — будет еще дольше, а мы хотим максимально ускорить данный процесс. Он тяжелый, да, крайне тяжелый.
Причем это происходит каждый раз при перезапуске IDE, хотя не очень понятно, зачем каждый раз индексировать iOS SDK.
Мы не индексируем каждый раз SDK. Мы каждый раз проверяем, что поменялось в проекте от перезапуска к перезапуску. Предсказать, что именно вы изменили (или не изменили) без повторной индексации нельзя — но при этом, она должна быть существенно быстрее. Или она у вас на тех же сорцах без изменений идет каждый раз 15 минут?
В течении этих 15 минут работать невозможно из-за того, что во время индексации не работает никакой функционал кроме базового.
Без дерева символов, увы, не существует магии, которая позволила бы быстрее что-то выдать. Хотя, вот сборка/отладка/тесты у нас работают и без индексации, в отличие от многих других продуктов JB, плюс должно на каком-то этапе включаться автодополнение через SourceKit (хотя и без подсветки)
После индексации поиск и резолв символов в первые разы занимает 5-7 секунд, так что быстрее воспользоваться обычным поиском по файлам.
Ну, кэши имеют свойство достраиваться пока идет подсветка для конкретного файла. Скорее всего, здесь вы пробовали когда они еще не достроились, либо строились для конкретного непростого случая в первый раз — но дальше должно быть быстрее. Вообще, тут бы конечно CPU snapshot к нам в трекер.
Сразу же первая проблема — проект не собирается, AppCode почему-то игнорирует локальные SPM пакеты — не собирает их и ругается на «missing package».
И Select Opened File для файлов из локальных пакетов не работает.
Хм. Вообще проблемы с локальными зависимостями вроде как все поправили. У вас случайно какого-нибудь минимального проекта, на котором воспроизводится, нет в свободном доступе? И нет ли в проекте приватных зависимостей откуда-либо, доступных по ключу в Git?
Ну как владелец скажу просто — в свое время их раздавали под разработку без открытой продажи. В том числе, я свой получил со статьи на Хабре про Nokia Portfolio Challenge. Они тогда пытались сфорсировать наполнение Ovi Store приложениями под Harmattan и даже платили неплохой такой денежный приз каждому, кто успел бы запинать свой прил до декабря 2011-го.
Девайс был хороший, но сырой по софту. Помнится, даже русская раскладка на хардварной клавиатуре не работала нормально. И это так и не пофиксали, в том числе потому что Nokia не выдала ни сорцов драйверов, ничего (ядро кажется дали потом, когда оно уже никому не было нужно).
Сейчас устройства периодически скидывают на ebay, бо за давностью NDA, который запрещал их продавать, уже не актуален.
Мой лежит дома. Это уже не телефон, это память про первый свой проект, и кучу других крутых событий.
По идее, тут на Хабре ещё должны быть те, кто их получил тогда.
Можно. Там надо закинуть бут от 2.0, обновиться через Update Utility строго до варианта STM32, после этого Reflash от J-LINK должен увидеть и перешить. Если не видит — попробовать бут от 2.0, только разлоченный. Либо один, либо другой сработает. Я так два свистка перешил. ST-LINK 2.1 Reflash не увидит, к слову.
Обычно нет. Такое обычно только на перешитых в ST-LINK v2-1. И вообще, конечно, если кто-то увидит это комментарий — не мучайтесь вы с этим ST-LINK, перешивайтесь вот прямо сразу в J-LINK. Настолько, блин, проще. Дрова под любой системой — просто работают, GDB Server — тоже просто работает, не косячит, USART для отладки не нужен, потому что RTT. До кучи еще и пачка утилит полезных, которые тоже — внезапно, просто работают. Я уже не говорю о скорости заливки прошивки — то, что st-link лил секунд 30, j-link вливает тупо за пару-тройку секунд.
О, тогда я знаю, в чем ваша боль. Значит по шагам:
1. Если у вас DFU определяется через DFuse utility, значит у вас стоит STMовский драйвер, который не будет работать с dfu-util. И наоборот — если вы поставите драйвер, который будет работать с dfu-util, у вас DFuse не будет видеть устройства. В обоих случаях девайс будет в Device Manager на Windows.
2. Если надо использовать DFuse, то без шансов — dfu-util при этом работать не будет.
3. Если надо использовать dfu-util, то надо удалить и устройство, и его драйвер из Device Manager, а потом сделать так, как говорят вот тут, то есть накатить драйвер через Zadig. После этого dfu-util начнет видеть устройство и работать, проверено.
Вопрос из разряда "мне кажется, что я тут познал ньюансы, пострадаю-ка я хернёй на собеседовании за счёт конторы". Не познал, даже близко.
"Задержка на UI thread = падение приложения" это, для начала, альфа и омега любой мобильной оси по состоянию "десять лет назад". Никаких там пяти секунд, не надо терзаться. Сразу, иногда и без показа UI. То, что на какой-то оси теперь это по другому, никак не меняет простой основы: так делать нельзя. И это единственный правильный ответ.
Не надо филигранно направлять незаряженный 9мм на человека - потому что не заряжен он сегодня, а завтра очередной копатель в ньюансах решит, что нашел идеальный угол снятого предохранителя, при котором на него можно дунуть и он снимется, а так не, стрелять не будет. Ну, пока оппонент не чихнет.
Копания в нюансах подобного типа с начинающими приведет к тому, что они где-то решат "так не рухнет же сразу, использую". И потом ровно этот же собеседующий будет разгребать последствия в виде лапши, от которой падает очередной билд.
Умельцы работать с деталями, господь жги. А потом после таких умельцев двадцатилетний код, который надо вывести в асинхрон, бо он из-за "знания ньюансов" втыкает на каждом шагу, а умельцы сидят и рассказывают тебе, как же это теперь невыразимо сложно.
Бедный сотрудник Норникеля. Стоит он в -40 и пытается понять, за каким чёртом ему трясти кирпич весом под килограмм и почему нет отдельной кнопки для включения фонарика. А его друг, глядя на пролетающие мимо кирпичи, философски думает "опять поди освещение отключили".
У меня был use-case подключения телефона в работе 24/7 без возможности самому его в случае чего перезагрузить. После вполне продуманной настройки и беспроблемной работы "спутника" первым отказом был вздувшийся от постоянной зарядки аккум. Зарядка при этом была медленная, но влом было разбираться, как уйти от проблемы.
Решение какое-то такое - как правило, нужно кинуть резистор с плюсового контакта на сигнальный, определяющий наличие батареи. Номинал методом тыка - уровень напряжения на контакте даёт планшету понять уровень зарядки. Отсюда, некоторого значения отличного от нуля будет достаточно. На плюс с минусом - либо понижайку с 5в до 4 с лихом, либо (как правило) просто те же 5в медленной зарядки, так как часть вольтажа в любом случае упадет через резистор на сигнальный контакт. У меня так сработало и в итоге спутник уже третий год работает.
Отсюда, заведется почти любой - вопрос в том, чтобы распиновку аккума понять. А оставлять аккум - это гарантия либо проблем с корпусом, оторванным раздувшийся аккумлм, либо внезапного прекращения работы, потому что ампеража от аккума перестало хватать для тяжёлых задач (причем, отказ резкий, рандомный и всегда не вовремя), либо при плохом раскладе - да, пожар.
Я честно, теряюсь в догадках, что значит "ушатать" (убить диск? сделать его медленным?), о какой конкретно связке HA и BT идет речь и так дальше. С возрастом я становлюсь все более ленивым, отсюда я даже прояснять пожалуй не стану, а сразу скажу - что-то вы делаете фатально не так, переделывайте.
Мой конфиг крутится на сервере в докере где-то года три уже. Там не пара устройств, а пара десятков от разных вендоров (Tuya + Xioami + Samsung, что-то там еще, уже не вспомню). Описанный датчик брался сразу в количестве 4-х штук в момент, когда стоковая фирмварь на них отчаянно тупила, описанная мной интеграция была в зародыше, хотя и уже неплохо работала и так дальше, и тому подобное. И мягко говоря, я знаю, о чем говорю, бо все эти прыжки с перепрошивками я уже давно прошел.
Ни разу я не помню каких-то вопросов по скорости из-за "записи логов" при том, что у меня в качестве HDD обычный Seagate Barracuda на 7200 rpm. Потому что дешево и сердито. На текущий момент Xiaomi апнули стоковую фирмварь так, что коннект из их приложения к датчику пошел намного резче, а описанная интеграция работает вообще без проблем, если не крутить настройки, которые, повторюсь, особо нет смысла крутить. Для задач домашней автоматизации частоты отсылки пакетов за глаза, другие задачи решать таким датчиком, мягко говоря, странно. Отсюда, если есть желание использовать и стоковое приложение, и HA - в миллион примерно раз проще остаться на BT.
Не помню, как там с ценами на ZigBee-хабы, но в среднем, если ты берешь какую-то железку для домашнего сервиса компактного размера, это будет либо Rapsberry, либо пободбные ей мини-платы, либо что-то нибудь типа Mele. Bluetooth на борту, никакие хабы не нужны, можно работать. Ну и так, конфиг - не паяльник, BT был дешевле, чем то же самое с ZigBee. Как сейчас, не знаю, ибо просто не нужно.
Ну и финально, я даже не стану спорить на темы типа HA vs Яндекс-хаб. Нет смысла сравнивать по гибкости и возможности втащить в себя так-то три инфры разных "умнодомопроизводителей". Это не говоря о том, что весь Яндекс в плане IoT - это перебрендованная Tuya. И работать с Tuya напрямую без в них в качестве прокладки адски удобнее просто.
Вообще нет никакой боли с BT если знать, что существует Passive BLE Monitor. На стоке спокойно и радостно работает, втаскивается в HASS в полпинка.
И не только лампочки, но и розетки подхватываются Tuya Smart
На деле, это не проблема с подсветкой синтаксиса, здесь просто наиболее хорошо видно. Это в целом какой-то баг в дереве символов. Из-за этого в конкретном месте, как правило, отваливается сразу подсветка, навигация, автодополнение - ибо, что логично, нет другого пути, чтобы их сделать кроме как пробежаться по дереву символов.
В личку вполне. Но круто будет, если это минимальный, но рабочий проект.
Если коротко, то это совсем не просто запуск симулятора. Это, как минимум, получение surface этого симулятора, определение того, как именно в билд-системе происходит перестраивание бинарника с инжектнутым куском нового кода, отработка всех случаев, когда preview получить не получилось (а они крайне частые даже в банальных примерах), и "многое-многое другое".
Со стороны наверное да, выглядит просто. Но можно просто взглянуть на тот же Injection, который тоже всего лишь выцепляет строку компиляции конкретного файла и подкидывает новый dylib процессу. При внешней простоте все крайне непросто.
Возможно, когда мы немного детерминируем "переваривание кода" в данном конкретном случае. Я верно понимаю, что ожидаемый от подсветки результат - это что .haptic() и следующие вызовы функций подсвечиваются тем же цветом, что и .analyticsScreen()? Или там есть ещё проблемы?
Просто подсветка банально растет от дерева символов и выходит в какой-то дефолтный цвет в случае, если в конкретном месте что-то не получается идентифицировать - допустим, onReceive несколько штук и мы не можем по какой-то причине выбрать конкретную реализацию. Или вообще не можем отрезолвиться.
Пример бы кода минимальный, но рабочий, чтобы не гадать по скриншотам.
Конечно
То ли поломали, будет поправлено в первом обновлении (IDEA-283144).
В ближайшем релизе нет.
Мы не используем именно sourcekit-lsp по ряду причин. Одна из самых очевидных - нам пришлось работать с SourceKit, в том числе и на Linux, задолго до того, как по нему вообще появилась какая-либо документация, появился open-source вариант, и тем более обертка lsp над ним. Вторая - нет смысла использовать LSP, если запрос напрямую к SourceKit быстрее, а это критично. Третья - он слишком ограничен для требований нашей IDE.
SourceKit мы используем в следующих областях: а) для вычитки текстового содержимого Swiftовых модулей, потому что иначе невозможно иметь дерево символов для стандартных библиотек / сущностей в проекте б) для отображения ошибок и предупреждений (потому что нет смысла не использовать стопроцентно корректную выдачу и делать ее самим) в) берем оттуда же fix-its, чтобы добавить к нашим, в ряде случаев они не лишние г) на время индексации и построения кэшей берем список автодополнения из SourceKit, а после индексации творчески его добавляем к нашему списку.
А так, весь функционал IDE это в основном наш движок.
Правила лицензирования не специфичны для AppCode, они одни на все продукты JetBrains. Ну а так, есть perpetual fallback при годовой подписке. Изменений в принципах лицензирования нет, не планируется.
То есть вот именно фаза Processing Swift Modules каждый раз занимает 11 минут? Или вся повторная индексация целиком? Просто то, что там каждый раз мелькают модули SDK значит только то, что прошла проверка на наличие кэша и индексация полетела дальше. Почему так — ну вот скачали вы очередной свифтовый тулчейн, и нет никаких гарантий, что символы в нем те же, приходится перестраивать. Если без изменений, просто поняли, что содержимое модуля по ключу уже закэшировано и проскочили его.
Ну, тут спасибо компании Apple за то, что ряд исходников генерится в папке с билдом и соответственно их исчезновение при очистке вызывает переиндексацию.
А вот если идет фриз всей системы — это какая-то проблема. А при фризе системы случайно не наблюдается куча процессов clang/swift? У нас там в силу необходимости сгенерить перед индексацией те самые исходники, которые генерятся в папке сборки, происходит определенная квантовая магия, возможно пара заклинаний не сходится.
Это OC-21826. Если коротко, то ключи для GitHub сохраняются Xcode в свои Accounts, получить информацию из которых, мягко говоря, непросто. Из коробки с xcodebuild они не работают — мы там как бы просто xcodebuild -resolvePackageDependencies зовем.
В первый раз индексируется и кэшируется и проект, и SDK. Это долго, тут что можем — оптимизируем, но если проект крупный, в первый раз подождать необходимо. Полная загрузка проца тут by design, потому что если его не использовать весь — будет еще дольше, а мы хотим максимально ускорить данный процесс. Он тяжелый, да, крайне тяжелый.
Мы не индексируем каждый раз SDK. Мы каждый раз проверяем, что поменялось в проекте от перезапуска к перезапуску. Предсказать, что именно вы изменили (или не изменили) без повторной индексации нельзя — но при этом, она должна быть существенно быстрее. Или она у вас на тех же сорцах без изменений идет каждый раз 15 минут?
Без дерева символов, увы, не существует магии, которая позволила бы быстрее что-то выдать. Хотя, вот сборка/отладка/тесты у нас работают и без индексации, в отличие от многих других продуктов JB, плюс должно на каком-то этапе включаться автодополнение через SourceKit (хотя и без подсветки)
Ну, кэши имеют свойство достраиваться пока идет подсветка для конкретного файла. Скорее всего, здесь вы пробовали когда они еще не достроились, либо строились для конкретного непростого случая в первый раз — но дальше должно быть быстрее. Вообще, тут бы конечно CPU snapshot к нам в трекер.
Хм. Вообще проблемы с локальными зависимостями вроде как все поправили. У вас случайно какого-нибудь минимального проекта, на котором воспроизводится, нет в свободном доступе? И нет ли в проекте приватных зависимостей откуда-либо, доступных по ключу в Git?
Ну как владелец скажу просто — в свое время их раздавали под разработку без открытой продажи. В том числе, я свой получил со статьи на Хабре про Nokia Portfolio Challenge. Они тогда пытались сфорсировать наполнение Ovi Store приложениями под Harmattan и даже платили неплохой такой денежный приз каждому, кто успел бы запинать свой прил до декабря 2011-го.
Девайс был хороший, но сырой по софту. Помнится, даже русская раскладка на хардварной клавиатуре не работала нормально. И это так и не пофиксали, в том числе потому что Nokia не выдала ни сорцов драйверов, ничего (ядро кажется дали потом, когда оно уже никому не было нужно).
Сейчас устройства периодически скидывают на ebay, бо за давностью NDA, который запрещал их продавать, уже не актуален.
Мой лежит дома. Это уже не телефон, это память про первый свой проект, и кучу других крутых событий.
По идее, тут на Хабре ещё должны быть те, кто их получил тогда.
1. Если у вас DFU определяется через DFuse utility, значит у вас стоит STMовский драйвер, который не будет работать с dfu-util. И наоборот — если вы поставите драйвер, который будет работать с dfu-util, у вас DFuse не будет видеть устройства. В обоих случаях девайс будет в Device Manager на Windows.
2. Если надо использовать DFuse, то без шансов — dfu-util при этом работать не будет.
3. Если надо использовать dfu-util, то надо удалить и устройство, и его драйвер из Device Manager, а потом сделать так, как говорят вот тут, то есть накатить драйвер через Zadig. После этого dfu-util начнет видеть устройство и работать, проверено.