Хочу на себе портативный девайс как наушник, умный браслет или какой-то кулон, где есть микрофон и кнопка. Ну типа, BT-гарнитура. Смысл: не доставая смартфона из кармана, держать кнопку и говорить мысль. Отпустил кнопку - .ogg файл улетел предустановленному контакту в телеграме. Всё.

Нужно: хороший вибро-будильник на руке. Фичи подсчёта шагов - пофиг. Хотя автоматическое измерялло пульса бы было интересно, чисто позырить потом лог сердца за год, но все там будем.

Ещё интересна гипотетическая возможность расхачить и написать свою bare metal прошивку - но это вряд-ли.

Чё брать, тащемта?

Текущие варианты:

Xiaomi mi band 3: 14 дней. Мало как-то. Самые мелкие.
amazfit bip: 45 дней. Есть GPS/GLONASS внутри, говорят. Можно ставить приложухи. По виду: закос под аппле вотч.
Garmin VIVOFIT 3 - 356 дней (батарейка вместо аккума). Экран жесть мелкий, а корпус жирнейший

А можно не по SMS? Можно ему указать некий URL, по которому он должен засылать JSON через HTTP POST, используя LTE-безлимитный бесплатный тариф какой-нибудь?

Есть вообще у сотовых операторов какие-то тарифы с абоненкой = 0 и наличием вечных 64kpbs?

Просто как-то не очень понятно, чё они все поголовно SMS-шлющие, это же дорого и неудобно. Ясно, что SMS есть в любой деревне, а интернет нет, но всё-таки...

Есть жирный файл, в нём как-то лежат страницы килобайт по 64. Иногда надо сбросить «грязные» страницы на диск. Нельзя просто так взять и перезаписать страницу in-place: сдохнешь по середине записи и жопа тебе.

Какие вы знаете (видели в разных реализациях всяких там СУБД) способы безопасной записи таких вот страничек в файл?

Я чё-то читал про InnoDB: там в файле есть буферная зона на 128 страничек. Когда системе надо перезаписать несколько страниц, она сначала пишет их в сей буфер, делает fsync(), а потом начинает записывать страницы по своим местам. При поднятии после падения, если в буфере лежат страницы, CRC которых отличаются от CRC тех же страниц, находящихся на своих местах - значит что-то из этого буфера в прошлый раз не дописалось на свои места. Система читает страницы из буфера и дописывает их куда нужно снова. Не очень понимаю как в целом оно устроено...

Короче интересуют вот такие истории в кратком изложении про разные замуты с записью страниц на дисочку.

Читал про какие-то футеры в CouchDB, не понял почти ничего: http://guide.couchdb.org/draft/btree.html#figure/1

Я придумал такой боян:

1. Хотим записать группу страниц на диск.

2. Есть отдельный файл, растягиваемый в конец, на любое число страниц, куда мы сначала пишем все эти страницы тупо последовательно, делаем fsync.

3. В наш write ahead log пишем запись «скинуто в буфер, надо записать в большой файл».

4. Идём пишем в большой файл.

5. После записи всех страничек из буфера в «большой файл», делаем fsync, в журнал пишем «буфер вытряхнут успешно».

Но на VDS хостинге столкнулся с тем, что fsync не гарантирует, что отправленное в write() до него запишется на диск ДО того, что уйдёт во write() после него.

Что прикрутить к vim, чтобы он стал обладать умениями:

1. Жрет cmakelists.txt

2. Всасывает в индекс все сишноплюсовые файлы проекта

3. Умеет найти определение, все использования функции, класса и т.п. Не хуже clion. Уметь парсить c++11.

4. Заменить имя функции / метода во всех местах и файлах - это уже не обязательно.

5. Короче, главное - сверхкрутое индексирование имен всего, поиск по ним, т.е. чтобы легче копать исходники постгреса.

Каждый новый трек пишется микрофоном, при этом я слышу все другие треки в наушниках и звук хорошо синхронизирован.

Ну хотя-бы без этого синхронного воспроизведения, но с возможностью двигать треки.

Я тут чё-то поставил, но больше 2 треков оно не умеет записывать с микрофона.

И да, запись с 2 микрофонов (camcorder mode), чтобы стерео.

Перемещено Dimez из talks

Почему все цифровые фотоаппараты мира со времени Сталина научились сохранять картинку в JPEG разного качества, а установка принтера всегда была диким гемором? Драйверов каких-то сотни тыщ всегда.

Почему все принтеры мира не реализуют какой-то примитивный базовый HTTP-протокол, через который принтер нам говорит: «умею печатать A4, для этого засылайте мне растр с разрешением 8000x4000 точек и кодом формата 20». Софтина подготавливает растр, сжимает и шлёт с кодом 20, ей возвращают кодовый номер задачи печати, статус которой доступен для наблюдения через тот же тупой протокол.

У принтера же есть его физическое DPI. Он умножает его на размеры листа бумаги, который печатает и получается размер растра, который надо в него загнать.

Хочешь от принтера чего-то большего - ставь дрова. Хотя чего большего можно хотеть, когда у тебя свобода растеризовать что угодно в DPI вплоть до 100500 и засылать это в принтер пиксель-в-пиксель.

Задача: лежать на полке, мерять температуру, раз в 10 минут сливать её по HTTP по самописному протоколу. Желательно в железке линукс какой-то (роутинг, dhcp) и возможность скомпилить в неё что-то писанное на C++. Поменьше жрать батарейку, скажем до месяца аптайма без зарядки. Ясно, что батарейки бывают разные, ага. Скажем комплект из нескольких 1.2 аккумов.

ESP8266 или ESP32 - там не линукс, я так понял, но всё реализуемо.

На плате не существует точек, через которые можно припаять serial port и загнать туда свой бутлоадер?

Почему до сих пор не расхакано это всё? 6 гигов оперативы, мощные процы, LTE, т.е. неплохой сервак в кармане носим, а андроид оттуда выпихнуть не можем.

Залить туда, скажем, прошивку, которая вообще ничего не умеет, кроме измерения освещённости и передачи каждые 10 минут пакета из последних измерений по LTE, после чего засыпает снова на 10 минут. Такое на одной зарядке недели две протянет. Или раз в 5 минут забирает с сервера задачи, по которым может например записать 5 минут звука и передать.

В идеале хочется что-то похожее на samsung galaxy смартфон по габаритам, но открытое, без экрана, с 2 микрофонами (хороший стереозвук), GPS, GLONASS, BT 4.0, GPRS, LTE. Открытое - там не андроид, а что-то грузящее голое ядро с модулями под все устройства на борту и рутовым доступом через USB шнурок. Ключевое - готовое корпусо-батарейко решение, чтобы девайс запихивался в карман без торчащих проводов.

А смартфон достаточно мощный какой-то есть, который уже раскололи в плане загрузчика, драйверов и разрешили в него лить что попало?

Есть ли проект, который делает из смарта с отсутствующим (разбитым напрочь) экраном железку со всеми коммуникационными возможностями, включая GPS, LTE, GSM, Wi-Fi контролируемую через кабель или сеть по SSH?

Конкретно речь про Lenovo P2. Железка мощная, тонкая, с особо приятной батарейкой на более 5000 mAh.

Хотелось бы сделать из неё, например, GPS - трекер, который раз в минуту через LTE что-то постит по HTTP.

Перемещено Shaman007 из development

1. Запилить кусок кода.

2. Выдать публике.

3. Любое тело бренчуется от него, выкладывает новую ссылку.

4. Сервак как-то защищёт от while(true){char *p = malloc(9000);} и прочего, так что одно тело не мешает другим.

5. На серваке есть кнопка «RUN», которая этот кусок кода быстро запускает. Возможно даже не компилит, а интерпретирует, хз неважно, но лучше конечно GCC напускает честно на него.

Да-да, можно на гитхабе положить файл, а тело пускай на машине GCC запускает. Это не рулез, рулез прямо в браузере не имея под рукой GCC.

http://cpp.sh/ - знаю, но там бренчевалки нет и оно вешается от всяких бесконечных выделений памяти.

Вот это рулит? - http://plomba24.ru/novosti/transcom-t-15-poiskovyy-gpsglonass-mayak-s-funktsi/

Как оно 9 месяцев от одной зарядки работает при таком размере, GPS ведь жрёт дофига?

B-tree лежит в файле в виде россыпи блоков. Дерево оперирует блоками (хранит в одних блоках указатели на другие) в виде ID этих блоков (а не поинтеров в памяти), по которым (ID) код ходит в некий кеш блоков. Если в кеше нет, то кеш знает по какому смещению на диске блок лежит. Блок (страница) имеет фиксированный размер, допустим.

Блоки надо иногда выделять, и обычно сильно реже освобождать.

Выделять блоки можно тупо с конца файла, либо из каталога свободных блоков - данный пост как раз об этом. При освобождении блока, он, естественно, продолжает занимать на диске в файле место какое и занимал, не сдвигать же содержимое файла назад и не фиксить же все ID блоков после него.

Как нормальные люди управляют удалением и переиспользованием удалённых блоков в хранилках СУБД? Первое что приходит на ум:

1) Есть тупой односвязный список удалённых блоков. В заголовке файла лежит один ID, ссылающийся на голову этого списка. Если блок удаляется, мы ставим в качестве головы его, а предыдущую голову крепим к этому. Если надо выделить блок, смотрим не пуст ли этот список. Если да, то потребляем голову этого списка. Недостатки: лишние обращения к диску: чтобы выделить какой-то блок, надо его зачитать в память (чтобы взять из него указатель на следующий блок, дабы поставить теперь его на роль головы этого списка). То есть выделение нового блока - всегда какая-то возня с диском, забивание кеша блоков ненужными данными с диска. Хотелось бы так: мы знаем что по такому-то смещению лежит блок, его статус «свободен», но читать его не нужно, возможно только что мы его потом запишем уже с новыми данными.

2) Хранить специальные блоки, выделяя их на общих правах со всеми, в которых будет тупо лежать FILO очередь свободных блоков. Ну то есть, это такой массив, побитый на блоки, наращиваемый блоками, поддерживающий только push_back + pop_back, хранящий ID свободных блоков. Массив может расти, потребляя блоки, сокращаться, освобождая блоки. Тут рекурсивная проблема хранения уже этих свободных блоков... Плюсы: в памяти всегда есть страничка с кучей ID свободных блоков.

3) Хранить в начале файла специальный массив фиксированного размера на неск. мегабайт, куда можно добавить лимитированное число свободных блоков. Какая-то жопная идея... Про битмаску на все блоки я молчу...

4) Как-то запилить серию специальных ключей в само B-дерево, хранить их на равных правах со всеми остальными ключами и в них как-то держать инфу про свободные блоки. Будут прикольный эффекты: ты освобождаешь блок, пытаешься записать на эту тему новый ключ, а эта операция сразу же потребляет только что освободившийся блок и ключ уже не нужен и блок снова надо освободить )

Пока самым перспективным кажется направление (2). Некий линейный тупой массив INT-ов (ID-шников свободных блоков), без пределов роста, хранящийся как последовательность блоков и блоки эти формируют список. В памяти всегда закеширован хвост этого списка блоков, т.е. большой задний кусок этого массива ID-шников, в нём легко совершать частые манипуляции без похода на диск (возможно отражая оперции в WAL-логе), а новый такой блок нужен только если исчерпали последний. Может понадобиться освобождать и эти блоки и как-то хранить уже их ID. Возможно можно резервировать место под них в их самих...

Чё-то несколько лет уже пишу CMakeLists.txt и не думаю как всё под капотом работает. Недавно понадобилось в Makefile поковыряться - «клёвая система», подумал я. Не забить ли на лишнюю прослойку в виде cmake? Что мешает забить на cmake в 2018 году и писать только Makefile? Геморность чего именно возрастёт?

Топ ответов:

1. Кросс-платформенность: cmake генерит MS - сборочные файлы (проджект для Visual Studio, видимо).

2. минус Makefile - для больших проектов это ЖОПА. Но у больших проектов она покругу и можно не обращать внимания :-) (афтар не указал, в чём именно эта Makefile-жопа у больших проектов, афтар выше него сказал что всё делается через некие переменные красиво)

Если инсертить в дерево возрастающие ключи, что часто и бывает, то самый правый листовой блок будет всё время линейно расти. Потом он поделится, например пополам, пробросив разделитель наверх, и правая половинка снова начнет линейно расти вправо.

А «левые», наполовину заполненные блоки, так и будут лежать, вечно храня половину пустого пространства.

Вот что почитать на тему разных алгоритмов деления? Например в случае выше можно было для листового блока завести две статистики - «число вставок в левую половину» и "-//- в правую". Делить блок обратно пропорционально - т.е. в случае выше «левые» продукты деления бы получались жирные, а правый пустой (и средняя заполненность блока в дереве была бы под 99%, а не 50%), а деления случались бы реже в 2 раза.

Короче интересны такие статистическо-эвристические штуки и мировой опыт. Сырцы постгреса почитываю бывает, до сабжеыой части не дошел.

Интересно повесить на себя браслет, законнектить его по BT с линуксом и написать софтину, которая раз в минуту заставляет браслет померять пульс и передать в эту софтину. Если браслет не находится по BT (я ушел), то ничего не ломается, а при появлении меня в радиусе всё снова работает.

У всех этих браслетов через BT какой-то свой протокол общения с их андроидными приложухами? Может на гитхабе кто-то их расковырял?

У B-tree есть блоки, на диск оно ходит «блоками».

1. Оно пишет изменившиеся блоки прямо в те места, где блоки лежали ранее?

2. Если блок стал жирнее, нужно аллоцировать новый блок. Есть проблема фрагментации или блоки фиксированного размера и любой блок в на диске физически лежит как 16кб (например)? То есть, возникает ли проблема фрагментации, когда мы взяли с диска блок в 1КБ, дописали туда 160 байт и не можем втиснуть туда, где он лежал?

3. Про double write buffer или как его там я слышал, но это другая тема.

Майнеры же общаются с видяхами как-то. Есть стандартные цивилизованные способы запитки внешних топовых видях и коннекта к ним по сети или USB с возможностью выдирания провода в любой момент без креша ядра?

Как это делается? Какие девайсы гуглить?

Есть штук 20-30 написанных в C++ функций. Или методов классов (ну, функция с аргументом this по-сути).

Хочется в рантайме сгенерить кусок машинного кода, который чуть более чем полностью будет представлять собой длинную череду (штук 1000) вызовов этих 20-30 функций и выполнить этот код.

Вопросы:

1) Как можно в принципе передать управление на любые сгенерённые данные? Сегменты кода же защищены обычно от записи, а у сегментов данных нет флажка executable... Так взлетит?

char *code = new char[1024];
// my machine code
memset(code, 123, 1024);
int (*bugaga)(int, int);
// скастить вероломно, ага
bugaga = code;
// вызовем
int result = (*bugaga)(100, 500);

2) Как узнать адреса методов, адреса которых я могу употреблять в своём динамически генеримом машинном коде? Динамический линкинг же всякий там...