Pull to refresh
4
0

Embedded system architect

Send message

Либо я ничего не понимаю, либо кто-то вешает лапшу на уши.


Браузер собирает информацию во время сеансов просмотра веб-страниц и передает в децентрализованную сеть.

Информация будет предоставляться в руки пользователя, а не третьей стороне

Хм… Есть пользователь, есть браузер и есть некая децентрализованная сеть — уже 3? Или они пользователя не считают?


[Браузер] представляет собой систему для хранения информации с сохранением конфиденциальности

То есть, массив данных о том, что я делаю в сети, лежащий где-то в облаке и привязанный к некоему криптографическому идентификатору и вся конфиденциальность строится вокруг того, как ассоциировать этот идентификатор со мной, так? Зато согласно идее блокчейна я не могу отредактировать, почистить или полностью удалить историю и прочие данные, верно?
Спасибо, я как-нибудь постаринке…

+1
Хотел написать ровно тот же коммент. Структуры и отдельные секции памяти — техники стары как мир. А размещение данных в ром я всегда рассматривал исключительно как инструмент сокращения потребления памяти. Обычно это относится к строкам и крупным статическим конфигурационным структурам, типа системного меню или дескрипторов dma. Так в одном проекте цепочка дескрипторов для обработки данных с ADC занимала почти десяток килобайт, дублировать всё это в Ram ваще не комильфо.

> он есть в каждой системе по умолчанию, даже в Windows уже.

А вот это спорное утверждение. В бсд, например, по умолчанию нету, пока не вытянется с чем-нибудь по зависимостям. Более того, /bin/sh там ВНЕЗАПНО действительно указывает на sh.
Но это ещё ладно, его, неожиданно, по дефолту нету в Убунте, а под его именем скрывается dash, который хоть и совместим с башем в большей части, но бывают сюрпризы (иначе откуда бы я узнал, что там на самом деле не баш?).
Ну и да, в эмбеддед обычно бизибокс, который тоже не совсем баш.
Вообще, ситуация с этими подменами маразмотична, ИМХО, а тема башизмов давно избита. Поэтому я лично никогда не буду использовать эти 'неожиданные' переменные, дабы не выстрелить себе в ногу. И вообще, писать предпочитаю на sh.
PS: в интерактивной режиме баша ещё раздражает например, что по умолчанию стрелки вверх/вниз тупо листают историю, а pgup/pgdown работают не везде, и что ^W стирает весь путь целиком. Поэтому всю жизнь пользовался tcsh, zsh или fish.
Ну понятно, ресурсы на разработку жалеют. А по-хорошему просто выкинуть китайский сервер и покупать только железки.
А что это такое за бизнес-причины такие, можно поинтересоваться? Вопрос в ресурсах на разработку или принципиальная позиция?
Кстати, интересная тема. А кто-нибудь знает подобные часы (ну или хотя бы просто с GPS логгером) для которых есть опенсорсная прошивка? Задумываюсь о том, что бы снабдить такими детей, но реально напрягает, что они вся как чёрные ящики, сливающие всё что можно на какой-то неизвестно кому подконтрольный сервис. Вроде некоторые китайские часы можно подружить с traccar, развёрнутым на собственном сервере, но информации об этом мало, да и часы всё равно остаются чёрным ящиком — фиг его знает, куда они там ещё стучатся.
Алексей, очень крутая тема, спасибо!
Пара мыслей:
1) «Идеи и советы» в окне about смотрится чересчур скромно. Напишите честно о, собственно, самом важном — «автор базы данных».
2) В комментах уже пару раз проскакивало что-то подобное, н всё равно напишу своё видение:
Если штрихкода нет в базе, предлагать сразу заполнить мини-карточку с необязательными полями — бренд (набор с автодополнением по списку имеющихся), название, цоколь, мощность и прочее, что написано на коробке. После этого пользователю выдавать список похожих ламп от того же производителя, а вам — пополнять базу известных лампочек. Дальше на эту «базу запросов» можно будет натравить аналитику всякую.

В своё время делал интеграцию кодблокса с квартусом: писал код, ситезировал и заливал чип в C::B, а квартус запускал только для конфигурирование проекта.
http://we.easyelectronics.ru/CADSoft/integraciya-ide-codeblocks-s-programmnym-kompleksom-altera-quartus-ii-chast-i.html

Несколько однобокая статья, очень много сомнительных утверждений, с которыми можно поспорить. Вот например:
> Это безопасней, создание дублей карт 125 Кгц, как HID Proximity, так EM-marine…
Прочему-то напрочь проигнорированы карты Мифар, которые при правильном использовании не так уж и легко копируются.
> Преимущество мобильного доступа в том, что смартфоны реже теряют, ломают и забывают дома.
Как правило, у меня пропуск висит на связке ключей или в бумажнике. Или на поясе/бейдже пристёгнут. Не помню когда я последний раз оказывался без пропуска, телефон забываю гораздо чаще. И я с трудом представляю, как пропуск сломать. А вот современные телефоны имеет неприятную тенденцию превращаться в кирпич — да, не часто, но в самый непредсказуемый момент. Выскочил из рук/кармана, неудачно приземлился и привет. А вот сломать карточку — это надо действительно постараться.
> Это дешевле, даже если виртуальные идентификаторы стоят денег, их нельзя потерять, сломать
Безопасность и цена — сам заморачивался этим вопросом, когда лет 5 назад разворачивал скуд в своей конторе. В итоге выбрал решение на базе карт Mifare с защищенными считывателями СP-Z 2MF по 1.5к рублей и скуд от русгард (10к за контроллер на две двери) с бесплатным локальным софтом. В итоге получили защищённое от копирования решение для контроля дверей и учёта времени и, что не маловажно, полностью локальное и не зависящее от наличия инета и внешних сервисов. Дёшево и сердито. А сами карточки стоят копейки (от 50р.) и выпускаются почти в любом формфакторе.
А там где я живу сейчас поголовно распространено использовать мифар + 4 циферный пин.
> Ну, и самый печальный факт, ваши IMSI и IMEI, естественно, известны мобильным операторам…
На минутку, чуть выше написано что у всех производителей токены хранятся в централизованных БД. То есть у кого надо доступ всё равно ко всей этой информации есть.
> Это экологичней… одной этой причины достаточно, чтобы отказаться от использования пластиковых карт.
Боюсь, телефоны в этом плане ни разу не лучше.

Но неудобство использования телефона вместо карты доступа убивает ИМХО вообще всё. Современные флагманы с их прожорливостью и маленькой ёмкостью батареи, очень часто живут меньше суток. Забыл вечером поставить на зарядку и сиди утром в электричке трясись — как бы так и инетик почитать и что бы до работы батарейку дотянуть. А что если телефону внезапно снесёт крышу и придётся хард-резет делать?
Это точно так же, как почему я всегда ношу с собой банковские карты — пасивные чипы гораздо предсказуемее чем телефон.
Так что ИМХО только в дополнение к обычному пропуску.
>>Так что мы назначили Termin, и через неделю мне за полчаса открыли счет, на который мы со вздохом облегчения положили наши привезенные из России наличные сбережения.
Хех… У меня в Швеции на это ушло больше полутора месяцев и это мне ещё повезло — некоторые говорили, что у них месяца на три затянулось.
Зато отношение тут как-то более гуманное )
> git status
> git diff comments.js
> git add comments.js

Я выполняю их столько раз, сколько файлов изменил.


А не удобнее ли git add --interactive? Я вот без него жить не могу: очень удобно и ревьювить перед коммитом и разбивать код на микрокоммиты.
Есть, например, такой класс задач, как UltraLowPower — это когда каждый микроапмер считают. Тут, в большинстве своём, РТОСы плохо подходят. Хотя от конкретной задачи зависит — надо проектировать и просчитывать, в некоторых случаях Tickless RTOS большого оверхеда не добавляет. Впрочем даташиты в любом случае надо зачитывать до дыр и режимы работы периферии настраивать вручную. А вот от HAL'а (того, который от ST) 100% надо избавляться (ну хотя бы в пользу LL) — более неудобной и глючной и прожорливой либы ещё поискать надо! Благо под задачи ULP есть куда более вменяемые производители контроллеров.
Подтверждаю: месяц назад зарегил три аккаунта на гмейле без номера телефона с использованием моего смарта на Андроид 6.
Кстати, делал аккаунты для детей с целью зергистрировать их в аэрофлот-бонус. Гмыл удалось убедить работать без номера мобилы, а вот с синенькими возникли проблемы: фейковые номера отсекает, несколько аккаунтов на один номер привязать не даёт, без телефона вообще ни в какую. И это при том, что они активно рекламирую мол, подключите детей к аэрофлот бонус джуниор. Да у меня младшее дитё вообще не разговаривает ещё, какой телефон? В итоге правда саппорт мне подсказал, как привязать их всех к одному номеру, но делается это, мягко говоря, не интуитивно.
Ну то есть, я хотел сказать, что мощность пучка в точке реза зависит от длины оптического пути, а покуда в таких станках оптический путь воздушный, то рассеивание переменное. В оптоволоконных станках оптический путь, а следовательно и рассеивание, выличина постоянная во всей рабочей зоне. А уж кто именно в этом рассеивании виноват — не столь важно.
Ну скорее некогерентность пучка — фокусирующая линза на это не влияет, только сама трубка. Ну и может зеркала чуток рассеивают.
КПД питальника лазера? Если не в пару раз повысили, то шло бы оно лесом :) там на рассеивание в воздухе потери куда больше проблем доставляют — на поле 600х900 уже реально заметно разницу между правым верхним и левым нижним углами. Вот если бы они научили мозг автоматически компенсировать рассеивание — вот тогда да, это был бы крутой прогресс.
А ещё юстировка — это боль. Я тогда чуть ли не пару недель на пусконаладку потратил, целую методику изобрёл с участием бумажек, резинок, ручки и усб камеры :). Хоть какая-то автомазицая этого процесса очень бы не помешала.
Лет 6 назад выбирал китайский лазерный резак для компании — почти всё, что тут описано тогда было стандартом для относительно приличных моделей. Разве что возможности подключать мышку не было :) Ну и головы разных размеров не прилагались. То есть за всё это время только мозг эволюционировал?
Что касается металла — его гравирибт с помощью специальных составов, которые наносят я на поверхность и впекаются в металл под действием лазера
Насколько я знаю, в подобных системах есть функции типа sleep_us. Их и следует использовать для маленьких задержек. Компилятор вполне может превратить вызов функции sleep_us в обыкновенный простой цикл, но это уже особенности реализации. Руками же писать такие циклы задержки некрасиво и опасно.


Очень далеко не везде. Обычно производители контроллеров поставляют библиотеки, сфокусированные на упрощение работы с периферией контроллера, а формирование задержки больше алгоритмическая вещь. Чаще всего реализации этих sleep_us ищутся на форумах производителя.
Что же касается приведённого for-а — правила работы оптимизатора в мире эмбеддеда ничем не отличаются и при -O2 это цикл будет выкинут. Что бы это избежать, можно поставить _NOP. Ну или да, volatile на счётчик. Но и то и другое не годится в качестве реализации sleep_us, так как очень неточно (сильно зависит от оптимизации, требует отключения прерывания и тд). На армах я обычно использую реализацию на основе DWT счётчика.

А в целом спасибо. Я как раз прогнал проект, над которым работаю, через IAR-ровский анализатор, разочаровался в его качестве и начал задумываться, чем бы его ещё прогнать. Наверно теперь попробую PVS.

:))) до этого речь шла о сотне метров. Километры это да, уже сложнее.

100мА в импульсе? Это вы какой мощьностью свистите? Самые прожорливые трансиверы вроде не больше 25мА на 10мВт-ах хотят. А вообще, посмотрите в сторону BLE, сейчас много интересного предлагают.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity