С качеством жизни там, похоже, начинаются проблемы. В том числе - и из-за эмиграции бизнесов и амбициозных людей, способных самим оплачивать себе "социалку", не делясь с разными бездельниками.
У Самсунга вообще какие-то странные отношения с блокировкой. Когда у меня был S21 - после одного из обновлений он стал "оживать" (включать экран) в кармане, и автоматически звонить в полицию - видимо, забыли проверить сенсор приближения перед активацией этой функции. Через пару месяцев это починили - но осадочек остался.
Я ж не против. Просто до боли напоминает известную байку про то, как унификация 13 стандартов приводит к появлению несовместимого ни с одним из них 14-го.
А если ниши пересекались - то начинались танцы с бубнами. Например - когда практически цельнотянутые с Запада компьютеры (например, СМ) производились каждым заводом с другими разьемами системной шины - и платы с одного не подходили к другому.
Согласен с большинством утверждений. Единственное - NPU это (в теории) еще и про короткий путь от камеры до инференса, при условии синхронизации по кадрам. Это подход, который продвигает Nvidia в своих Jetson-ах, в которых ISP "ближе" к GPU/NPU чем центральный процессор - а также Kendryte и некоторые другие компании. К сожалению, у них не получается снизить цену так, чтобы Jetson-ы можно было встраивать в камеры (все-таки 400+ долларов без обьектива за Advantech это очень много для массового рынка) - да и CSI не самый удобный интерфейс в смысле монтажа. А с USB или сетью - производительность сразу падает. Но для серверных применений Nvidia активно продвигает принцип "из сети - прямо в DLA", собственно за этим они Mellanox и покупали. Интел же пытаются идти тем путем, которым идут компании в областях обороны и других "небюджетных" решений - в которых и модели, и ISP, и пре/пост-процессинг тупо конвертируются в FPGA. Но получается пока неэкономично по питанию/теплу и сложно для использования.
Ведь указатель - естественный (и единственный) способ доступа к памяти в низкоуровневом программировании
Вы ошибаетесь.
Даже в современных процессорах - вы не можете записать ничего в память без определенных ухищрений, по умолчанию данные будут записаны в кэш и потом уже выгружены в RAM - адресация которой не имеет ничего общего с выделенными вашей программе виртуальными адресами. А по дороге может случиться, что соответствующая страница была свопнута на диск - придется ее оттуда доставать, класть куда-то в реальную память, отображать на адресное пространство и так далее. GPU и другая периферия - там свои заморочки в виде DMA, мэйлбоксов и т.п.
А в те годы - RAM у компьютера могло не быть вообще, память могла быть последовательной или допускать чтение/запись только блоками. И все то, что сегодня "скрывается" ОС и драйверами, позволяя использовать простые указатели - приходилось кодировать "ручками" (возможно, сохраняя в виде библиотек - как оно и происходит до сегодняшнего дня в мире embedded, где OC зачастую компилируется и линкуется вместе с вашей программой).
У нас в универе архитектуру компьютеров преподавал дедушка лет 70, умело поддерживавший образ соратника упомянутых в статье "корифеев". К сожалению, дедушка не умел в абстракции, задалбывая нас всякими 13-битными регистрами, в которых порядок битов нужно было помнить наизусть - потому что это какой-то суровый хак, типа "при сдвиге на один бит волшебного числа то-то и то-то включается, а что-то другое выключается или меняет состояние". Большинство группы имело опыт построения клонов Радио-86, Спектрума или чего-то подобного, и могло бы в принципе оценить такие решения - если бы дед обьяснял сначала, чего они пытались достичь, а не сразу ударялся в хаки и оптимизации.
Разумеется. Дело в том, что действие меток основано на том же самом протоколе, по которому Блютус-устройства находят друг друга и устанавливают соединения. И ключевые данные (адрес устройства, RSSI, поддерживаемые профили и некоторые другие) - там передаются в открытом формате.
как же на самом деле работает event-loop в node.js
Не приходилось работать с node.js - но .NET-чиков я всегда спрашиваю, как работает Task. Для разработчика нагруженных приложений важно понимание, как выполняется написанный код - и как следствие, каких паттернов лучше избегать и где искать при появлении каких-то "тормозов" и прочих non-functional проблем. Или - что и где нужно поменять в настройках, если у вас 32-ядерный сервер (или одноядерная система-на-чипе - такое тоже бывает). При этом, разумеется, я никогда не спрашиваю и не оцениваю знание наизусть имен классов, методов и набора их параметров - т.к. я и сам это не помню, благо есть IDE и Гугл.
"Вам шашечки - или ехать"? Метки просто передают определенный пакет (advertisement в терминах BLE) - содержащий их ID, тип устройства = "метка" и еще буквально один-два параметра. Это приложение для разработчиков, и в нем есть по умолчанию включенный фильтр - позволяющий видеть только ваши метки и отсеивать метки Apple и Google. Если же этот фильтр настроить по-другому - я смогу, например, отслеживать приход-уход соседки (у нее какой-то "свежий" айфон), а собрав немного логов - и различить с приличной вероятностью, в доме она, загорает во дворе или играет там с собакой (по изменениям RSSI).
о существовании технологии стелс-вертолётов не было известно общественности
Работы по снижению ЭПР боевых вертолетов ведутся примерно с того времени, как появились первые промышленные образцы оных. А в конкретных аспектах рассеяния/поглощения радиоволн "общественность" и так ничего не поймет.
Я бы в этом случае смотрел бы в сторону device tree. Драйверы ядра работают с абстракциями типа "пин_RxD" и "пин_ТxD" - а соответствие физическим "ножкам" микроконтроллера и параметрам конкретной платы задается именно там.
Кто у кого был - я не знаю. Но своими глазами видел китайские а-ля industrial планшеты на плате - абсолютно совпадающей с devkit от Quallcomm (DragonBoard или что-то вроде того). Причем весь планшет стоил дешевле этого самого дев-кита - правда, хитрые производители поменяли перемычками кое-какие линии, поэтому камера и по-моему звук работали только на их прошивке.
Проблема с OrangePI - то, что это остатки от производимых компанией заказных плат. У них на сайте с десяток моделей, но никак не гарантируется что производство выбранной вами не закончится прямо сегодня вечером - вместе с изначально "такой себе" поддержкой периферии или путей использования, не важных для заказчиков крупных партий.
По поводу ЛЭП - они же практически все трехфазные, если какой-то импульс наводится на все фазы - то по идее, он должен нейтрализоваться (на этом эффекте основана та же "витая пара").
С качеством жизни там, похоже, начинаются проблемы. В том числе - и из-за эмиграции бизнесов и амбициозных людей, способных самим оплачивать себе "социалку", не делясь с разными бездельниками.
У Самсунга вообще какие-то странные отношения с блокировкой. Когда у меня был S21 - после одного из обновлений он стал "оживать" (включать экран) в кармане, и автоматически звонить в полицию - видимо, забыли проверить сенсор приближения перед активацией этой функции. Через пару месяцев это починили - но осадочек остался.
Я ж не против. Просто до боли напоминает известную байку про то, как унификация 13 стандартов приводит к появлению несовместимого ни с одним из них 14-го.
Советую вам прочитать Datasheet на датчик и понять, для чего у него входы CS и SDO и что с ними делать в режиме I2C
А если ниши пересекались - то начинались танцы с бубнами. Например - когда практически цельнотянутые с Запада компьютеры (например, СМ) производились каждым заводом с другими разьемами системной шины - и платы с одного не подходили к другому.
Если у вас "центральный сервис аутентификации" не требует, например, токена с телефона - то ИБ нужно нахрен уволить.
Согласен с большинством утверждений. Единственное - NPU это (в теории) еще и про короткий путь от камеры до инференса, при условии синхронизации по кадрам. Это подход, который продвигает Nvidia в своих Jetson-ах, в которых ISP "ближе" к GPU/NPU чем центральный процессор - а также Kendryte и некоторые другие компании.
К сожалению, у них не получается снизить цену так, чтобы Jetson-ы можно было встраивать в камеры (все-таки 400+ долларов без обьектива за Advantech это очень много для массового рынка) - да и CSI не самый удобный интерфейс в смысле монтажа. А с USB или сетью - производительность сразу падает. Но для серверных применений Nvidia активно продвигает принцип "из сети - прямо в DLA", собственно за этим они Mellanox и покупали.
Интел же пытаются идти тем путем, которым идут компании в областях обороны и других "небюджетных" решений - в которых и модели, и ISP, и пре/пост-процессинг тупо конвертируются в FPGA. Но получается пока неэкономично по питанию/теплу и сложно для использования.
Не "повезло" - а они довольно долго "висели" над поверхностью, выбирая подходящее место.
Авторы не смогли в HAL и прочие device tree? Уже в микроконтроллерах это поддерживается...
Чуть более чем все - у которых есть входы на 3.3 вольта. Можно даже на малине I2C включить (или SPI)
Вы ошибаетесь.
Даже в современных процессорах - вы не можете записать ничего в память без определенных ухищрений, по умолчанию данные будут записаны в кэш и потом уже выгружены в RAM - адресация которой не имеет ничего общего с выделенными вашей программе виртуальными адресами. А по дороге может случиться, что соответствующая страница была свопнута на диск - придется ее оттуда доставать, класть куда-то в реальную память, отображать на адресное пространство и так далее.
GPU и другая периферия - там свои заморочки в виде DMA, мэйлбоксов и т.п.
А в те годы - RAM у компьютера могло не быть вообще, память могла быть последовательной или допускать чтение/запись только блоками. И все то, что сегодня "скрывается" ОС и драйверами, позволяя использовать простые указатели - приходилось кодировать "ручками" (возможно, сохраняя в виде библиотек - как оно и происходит до сегодняшнего дня в мире embedded, где OC зачастую компилируется и линкуется вместе с вашей программой).
У нас в универе архитектуру компьютеров преподавал дедушка лет 70, умело поддерживавший образ соратника упомянутых в статье "корифеев". К сожалению, дедушка не умел в абстракции, задалбывая нас всякими 13-битными регистрами, в которых порядок битов нужно было помнить наизусть - потому что это какой-то суровый хак, типа "при сдвиге на один бит волшебного числа то-то и то-то включается, а что-то другое выключается или меняет состояние". Большинство группы имело опыт построения клонов Радио-86, Спектрума или чего-то подобного, и могло бы в принципе оценить такие решения - если бы дед обьяснял сначала, чего они пытались достичь, а не сразу ударялся в хаки и оптимизации.
Разумеется. Дело в том, что действие меток основано на том же самом протоколе, по которому Блютус-устройства находят друг друга и устанавливают соединения. И ключевые данные (адрес устройства, RSSI, поддерживаемые профили и некоторые другие) - там передаются в открытом формате.
Не приходилось работать с node.js - но .NET-чиков я всегда спрашиваю, как работает Task. Для разработчика нагруженных приложений важно понимание, как выполняется написанный код - и как следствие, каких паттернов лучше избегать и где искать при появлении каких-то "тормозов" и прочих non-functional проблем. Или - что и где нужно поменять в настройках, если у вас 32-ядерный сервер (или одноядерная система-на-чипе - такое тоже бывает).
При этом, разумеется, я никогда не спрашиваю и не оцениваю знание наизусть имен классов, методов и набора их параметров - т.к. я и сам это не помню, благо есть IDE и Гугл.
"Вам шашечки - или ехать"? Метки просто передают определенный пакет (advertisement в терминах BLE) - содержащий их ID, тип устройства = "метка" и еще буквально один-два параметра.
Это приложение для разработчиков, и в нем есть по умолчанию включенный фильтр - позволяющий видеть только ваши метки и отсеивать метки Apple и Google. Если же этот фильтр настроить по-другому - я смогу, например, отслеживать приход-уход соседки (у нее какой-то "свежий" айфон), а собрав немного логов - и различить с приличной вероятностью, в доме она, загорает во дворе или играет там с собакой (по изменениям RSSI).
Работы по снижению ЭПР боевых вертолетов ведутся примерно с того времени, как появились первые промышленные образцы оных. А в конкретных аспектах рассеяния/поглощения радиоволн "общественность" и так ничего не поймет.
Метки элементарно обнаруживаются любым приложением с поддержкой сканирования BLE - например, от Nordic.
Я бы в этом случае смотрел бы в сторону device tree. Драйверы ядра работают с абстракциями типа "пин_RxD" и "пин_ТxD" - а соответствие физическим "ножкам" микроконтроллера и параметрам конкретной платы задается именно там.
Кто у кого был - я не знаю. Но своими глазами видел китайские а-ля industrial планшеты на плате - абсолютно совпадающей с devkit от Quallcomm (DragonBoard или что-то вроде того). Причем весь планшет стоил дешевле этого самого дев-кита - правда, хитрые производители поменяли перемычками кое-какие линии, поэтому камера и по-моему звук работали только на их прошивке.
Проблема с OrangePI - то, что это остатки от производимых компанией заказных плат. У них на сайте с десяток моделей, но никак не гарантируется что производство выбранной вами не закончится прямо сегодня вечером - вместе с изначально "такой себе" поддержкой периферии или путей использования, не важных для заказчиков крупных партий.
По поводу ЛЭП - они же практически все трехфазные, если какой-то импульс наводится на все фазы - то по идее, он должен нейтрализоваться (на этом эффекте основана та же "витая пара").