Ради прикола хочу посмотреть на свой непрерывный график пульса за неделю и может быть податамайнить его.

На браслет умный прошивку накатить, чтобы каждые 5 секунд меряло? Аккума у него не хватит да и closed source там всё. Временное разрешение желательно вообще риалтаймовое, ну то есть чтобы измеряющее 10-секундное окно ползло постоянно и каждую секунду фигачило данные на выход.

Есть у меня бинокль 1973 года БПЦ 7x50 - всё круто, картинка нереально светлая и резкая. Иногда для рассмотрения деталей на объекте хочется на что-то опереться - дрожание подбешивает. Резкости навалом навалом, ты эти детали видишь, но они просто дёргаются. И это только 7 крат.

Увидел в продаже 16x50 забугорного производства, тоже 1970-х годов. Японский кажется. Причём габаритами даже поменьше моего.

А 16-кратный дёргается ещё адовее видимо. Я слышал что бинокли больше 8 крат без штатива юзать трудно. И нафига он такой 16-кратный кому нужен? Всмысле, как продуманная мировая индустрия 1970 годов смогла в принципе такое породить, как 16-кратный бинокль в безштативном исполнении? Как его юзать-то?

Кстати, может кто шарит, а за сколько можно купить современный 7-10 кратный бинокль с оптическим стабом по качеству исполнения не хуже советских БПЦ? Что это будет за модель/производитель?

А ещё хочу насадку на БПЦ, которая добавляет цифровую камеру. Смартфон к окуляру подносишь - картинка кайф, но всё дрожит не по-детски.

Зачем: запускать научные алгоритмы на видосе. На одном видосе много раз месяцами и годами. Можно взять ffmpeg и один раз сделать .mp4 -> *.png и потом юзать *.png, но место жалко. Причём декодирование видео в наши дни вроде бы не занимает какого-то существенного времени, особенно на фоне этих моих тяжёлых научных алгоритмов, обрабатывающих кадр, допустим, по 1/10 секунды.

Есть livavcodec или как там её. Лежащая в основе ffmpeg. Можно взять её и она должна жрать любые файлы. Чем это плохо? Она тормозная?

Будет ли лучше пререкодировать один раз все видосы в какой-нибудь H.265 или Vorbis а потом использовать не универсальный livavcodec, а специфический кодек под то, во что я перекодирую? Или этот кодек специфический кодек я всё равно нигде кроме libavcodec не найду и вообще libavcodec нормальная и не надо трахать моск?

Входные видосы закодированы хрен пойми чем (снято разными мобилами), поэтому libavcodec привлекает всеядностью. Незнаю сколько я выиграю CPU перекодировав все эти видосы однократно во что-то более экологически чистое, не думаю что много.

Диск жрать не хочется, т.е. например хранить некие жирные видосы в каком-нибудь raw формате.

Есть такая примитивная хеш-функция для строки:

const char *c = "Hello World Sobaka";
uint32_t h = 0;
const int PRIME = ...;
while (*c) {
  h = h * PRIME + *c;
}

h; // our hash

В чём прикол того, что PRIME будет простым числом? Кому это выгодно?

Из него таблички на домах делают для инженерных сетей.

Вся табличка лёгкая по весу, может чуть тяжелее аналогичного объёма картона. С лицевой части глянцевая. В своей толще - как «мелкопорый» пенопласт. Все материалы белые по цвету.

Хочу из такого заднюю часть солнечной панели запилить. Есть мысли об альтернативах этому материалу для этой цели?

http://www.leonidus.net/data/signs/signs_engineering/russia/Russia_S-Petersbu...

Можно ведь запилить индекс по SIFT keypoints на картинке, резолвящийся в гео-координаты и сделать такой сервис. Должно быть адовым бояном, наверняка есть попытки. Дайте ссыль. Особенно много фоток популярных объектов, типа Спасо-Преображенский Собор в СПб зафотканный наверняка со стапитеста разных позиций. Наверняка этих фоток так много, что можно 3D модель автоматически реконструировать, не то что узнать место.

Так что вангую, что мобильный сервис «а это чо» уже существует.

Ясно, что проще по GPS определить свою локацию, но юзер-модель «показал на объект, оно сказало что это» проще. И смысл не совсем в определении своей позиции, а скорее про рассказ про объект. Допустим на гугло-картах про каждый дом в центре СПБ хрен что написано. Про доходный дом Веге написано, а про соседний доходный дом какого-нибудь другого чувака нет.

1. Ни разу не видел вживую 3D принтер, но технологию понимаю. Нужно напечатать несколько деталей, каждая размером не более компьютерной мыши.

2. Готовых моделей нет. Сваять могу попробовать сам. Скажите в каком формате модель вам нужна, что нужно не забыть, на что обратить внимание? И скажите в какой софтине под убунтой я бы мог дома попытаться сделать модель. Знаю blender со стороны видеомонтажа и если можно применить blender для 3d-модели для вашего принтера, то я бы не проч разобраться. Но нужны какие-то подсказки.

3. В материалах не шарю. Нагрузок на детали можно сказать не будет никаких, пара деталей будут подставкой, пара других будут висеть в магнитом поле на этой подставке. Не знаю из чего там сейчас 3D-модели печатают. У каких принтеров и материалов какие точности техпроцесса. Не нужна точность деталек ЛЕГО, нужна точность допустим 0.2mm. В модели будут такие делали, как например дырка, куда должен без клея силами трения закрепиться круглый магнит диаметром 15мм. То есть я не понимаю как технологически это будет достигаться - наверное я должен в модели сделать эту дырку меньшим диаметром, например 14.5 мм, чтобы 0.5мм были нужны для создания прижима. Но есть какие-то погрешности в печати и на выходе будет 14.8 и будет мало. Или наоборот. Вот это всё есть технологические ноу-хау, на которые мне нужны подсказки.

4. Модеть будет типа такой: https://www.thingiverse.com/thing:2610441 — все белые детальки - речь о них. Мне нужна другая модель, например нижнюю часть я хочу сделать сплошной без соединения через спицы. Длина детали - где-то 15 см.

5. Нужны советы, ссылки на тему создания модели. Самый интуитивно удобный 3D-редактор, например. Хотя и к blender можно привыкнуть. Может чё есть для android/ios чтобы можно было в метро модель дорабатывать?

Нужен сверлильный станок. Надо в бруске длиной 6 см. просверлить сквозное отверстие вдоль идеально по центру.

Точность наверное нужна где-то 0.2 мм. Это действительно изготавливается прибор - Мендосинский Мотор. Речь про изготовление вала. На валу будет деревяшка - параллелепипед длиной 6 см квадратного сечения 2*2 см.

Кто посоветует дрель по дереву из тех что есть в салоне «220вольт» допустим?

Видосы на ходу в телеграмчик постить, видеотрансляции фигарить на ходу. Кто самый дешёвый при приличном качестве связи и низком пинге?

Понимают ли они это? То есть, жжот ли беспроводная зарядка в пустоту, когда мобилы на ней нет?

А чё там за протокол «чувствования» есть мобила на ней или нет? В мобиле есть какой-то умный ответчик «я тут, жги кросавчег»?

Есть опыт лет 15 в C++, под Android пытался лениво начать кодить пару раз, первый раз убила конски развесистая и тяжёлая IDE, где всё это предлагалось сделать. Второй раз убило то же самое - IDE стала ещё более конская и тяжёлая. Я фалломорфирую с того факта, что для простого белого окна с одной кнопкой мне надо видеть 100500 каких-то файлов в иерархии проекта, кучу кнопок в этой студии, запускать какую-то жирную систему сборки с .xml файлами т.п.

Не понимаю как можно начать с чего-то не базового. Такой подход, типа качните нашу IDE под 700 метров, запустите, он отожрёт пару гигов озу, создайте проект и т.п. - какая-то жопа, а не базовость. Базовое - это когда тебе дают голимый notepad, ты пишешь код, потом пишешь Makefile из 4 строк, запускаешь make и получаешь свою софтину. Далее накручиваешь. К IDE приходишь, когда понимаешь что накрутил так дохера, что уже тяжело через vim + mc на всё это смотреть, например.

В общем, хочется какого-то мануала/книги, где подразумевается, что ты можешь создать легитимное android-приложение из минимума говна и палок. Например имея только vim, adb, ещё там что-нибудь относительно редко меняющееся, желательно без всяких gradle систем сборки, а просто запуская java из консоли. И получая легальный современный нормальный .apk, который google play market не забанит ни за что.

Нахрена мне такое надо? А иначе основ не понять. Я бы хотел понимать что там в самых низах (ясно, что низами называется что-то вроде функции main в java, линковалки ресурсов и т.е., пакователя .apk файлов, Manifest.xml и т.п.). Т.е., чтобы, например, я смог собрать android-приложение, которое минимальное по размеру для данного функционала. Т.е. чтобы в него не было включено 100500 каких-то левых метафайлов, дескрипторов самой студии, всяких лицензий, копирайтов, ресурсов сотен иконок разного размера, прочей дефолтной ботвы. Мне не надо потребления лишних 4 КБ в .apk на то, что там для соблюдения этикета лежит какая-нибудь портянка про то, что это собрано такой-то, мать её, студией. И чтобы, скажем, я должен был руками всё это где-то прописывать, на каждом шагу огребая что чего-то не хватает и мог, разбираясь, понять нафига нужен каждый мелкий элемент процедуры.

Т.е. в идеале, среда разработки отсутствует, а есть набор файлов и утилит, а я пишу .sh - скрипты для оркестрации всех говен для получения легального .apk файла.

Хочется прикола ради собрать мощную панель, но для внутри-комнатного использования, причём чисто для рассеянного дневного пасмурного света. То есть, мощная панель нужна для раскрытия 10% своего потенциала и она никогда не окупится. Нет цели сэкономить на электричестве, хочется просто получить прикольную разновидность зарядки для мобилы, типа дорогой игрушки и прикольного предмета интерьера, не более того.

Получил из Китая пачку из 40 кремниевых ваферов 156x156mm 0.5V 9A (ясен хрен, что 9A на экваторе) - вот таких: https://ru.aliexpress.com/item/40-4-8-156/32679279686.html

Если все последовательно соединить, то потенциально можно выжать 20V 9A на экваторе. Такие адовые солнечные элементы нужны, чтобы выжать хоть что-то достаточное для зарядки мобилы в пасмурном рассеянном свете - ещё не тестил, не мерял, может даже это не взлетит - ещё неизвестно, но солнечных элементов круче этих уже почти нет.

Вопросы:

1. Есть обычное оконное стекло, есть оргстекло, есть стекло «оптивайт» (пишут, что типа повышенная светопропускаемость, белое на срезе, а не зелёное) - какое лучше юзать для изготовления панели? Град идти не будет, птицы срать не будут - всё внутри помещения. Подозреваю, что «оптивайт», нет? Оргстекло ушатается даже в помещении думаю. Или есть что-то лучше оптивайта за то же бабло?

2. Имея 40 элементов мы можем соединить их по-разному. Например в 4 последовательные цепочки по 10 элементов, а эти 4 цепочки запараллелить - получим 5V и много ампер. Или тупо все последовательно - получим 20V, меньше ампер в 4 раза. Какой вариант оптимальнее? Чем больше напруга, тем меньше ток и меньше потери в проводах, т.е. провод до панели может быть длиннее. Интересно другое - что эффективнее: поднимать напругу конвертером с 5V до 12V (заряжать аккум жигуля) или понижать напругу с 20V до 12V (аккум жигуля)/5V(заряжать смартфон) - т.е. какая какой вольтаж на выходе всей панели иметь «универсальнее»/«выгоднее» - 5V или 20V.

3. Правильно я понимаю, что если взять источник напряжения 5-5.5V, дающий 10A и воткнуть его НАПРЯМУЮ USB-кабелем в мобилу, то мобила сама себе ограничит ток и на потенциальные 10A ей пофигу, они её не сожгут? Т.е. можно просто параллельно заряжать 5 мобил на fast charge режиме (по 2A).

4. Из чего ваять подложку пока хрен его знает, возможно возьму оргстекло, насверлю в нём дырочек. Потом насобираю по помойкам алюминевых банок, нарежу полосочек алюминия, согну плоскогубцами специальные держалки элементов, прикручу к подложке, повтыкаю элементы. Но это какая-то муторная жесть. Клеить сами элементы на какой-то клей не хочу, ибо желательно чтобы девайс был полностью разборный обратно. При этом понятно, что даже внутри помещения панель должна быть герметичной, иначе панели насобирают мелкой пыли на себя как марсоход.

2 варианта для голосования

1. Разработка под встраиваемую систему, куда валится много данных с 300 датчиков и нужно раз в секунду выдавать некий отчётик о состоянии системы по разным параметрам. Челленджи: вписаться в скудные ресурсы, писать свои аллокаторы и кастомные реализации каких-то алгоритмов.

2. Разработка бекенда вконтакта, куда валится 100500 лайков в секунду. Челленджи: разработка Ынтерпрайзных технологий своими силами, репликаций, шардингов, движков СУБД и т.п. Возможно машинное обучение.

На правах мыслительных экспериментов, никаких задач не стоит, никакие проблемы не решаются (типа «заборем mysql по скорости!»). Наоборот куча новых проблем с консистентностью. Все ставящиеся тут проблемы вымышлены, безумны и не нужны.

Придумаем как можно держать модели данных, нужные для форума, в какой-нибудь NoSQL. Придумаем какие типы данных в NoSQL были бы полезны ещё, кроме key=value.

Желательно рассматривать nosql субд, которая внутри имеет B+-Tree, т.е. умеет упорядочивать ключи, а не просто держит их в огромной hashtable. Или какой-нибудь LSM типа LevelDB - неважно.

Считаем, что транзакций у нас нет, жизнь боль. Бизнес-логика должна так манипулировать БД, чтобы оставлять её в консистентном состоянии, максимум оставляя мусор в ней. Допустим у нас есть некий уборщик мусора в бизнес-логике приложения, который умеет иногда лениво походить по базе и подропать потерявшиеся ключи или что-то ещё, т.е. знает что считать мусором. Предположим, мусор возникает когда у нас падает бизнес-логика посреди многоэтапных модификаций. Т.е. обычно ошибок в проде нет, но когда они есть появляется мусор, но не потеря данных.

Топик (он же тред).

По сути это список (vector, array). Если бы был тип данных List, адресуемый ключём (т.е. key=value, где value поддерживает семантику List) то было бы круто.

Для постинга месаги мы говорим push(«7abedf31», «Hello World»), где первый аргумент - имя списка (ключа, хранящего в value список), второй элемент - месага. В конец списка добавляется ещё одна месага.

Редактирование мессаг и хранение версий

Просто редактировать - это update(«7abedf31.5544», «New Value»), где «7abedf31.5544» - имя списка и индекс в нём.

Хранить версии - уже тяжелее. Будем делать так: скажем что наш движок поддерживает списки списков. Тогда мы можем делать push(«7abedf31.5544», «New Value»). То есть, запушить ещё один элемент в конец списка, лежащего в элементе 5544 списка «7abedf31». Там (в элементе 5544) уже лежала строка, так что движок сконвертит её в список с 1 элементом и добавит второй элемент. Можно передать некий флаг разрешающий так делать.

При рисовании страницы треда будем говорить get(«7abedf31», offset = 1000, limit = 25) чтобы получить массив месаг. У списка в движке удобный «индекс», движок за O(1) может обратиться к элементу 1000 и линейно вычитать остальные, т.к. лежит всё это в памяти пластом (вектор). Некоторые вернутые этим запросом элементы будут строками (это месаги без редактирований), а некоторые элементы будут списками (пачки версий) - код бизнес-логики форума нарисует только последний элемент из списка версий, остальные элементы юзает чтобы нарисовать число версий, например и переключалку доступа к нужной версии.

Список топиков.

Это уже просто множество key=value вида, например, «fid_tu_topicname=7abedf31», где fid - ID форума, tu - это время апдейта топика - оно обеспечивает поднятие топика, ибо ключи в лексикографическом порядке сортируются например в B+-tree где хранятся, topicname - ну это название топика.

Если в топик что-то постят, мы тупо делаем INSERT того же самого ключа, но где tu посвежее. В итоге у нас 2 ключа, но это не «неконсистентность», ибо бизнес-логика легко выкинет второй ключ с тем же названием топика, а в value лежит всё тот же указатель на нужный список с мессагами.

Апдейт мессаг

Как описывалось ранее, это один push в подсписок. При чтении треда, где через одно все сообщения имеют по 20 редакций - это неоптимальная хрень, но маловероятная в жизни. Зато при апдейте это всего один push, оставляющий всё в консистентном виде.

Месаги похоже не удаляются. Я смог представить как можно реализовать список в виде совокупности «чанков» в B+-Tree вперемешку с обычными ключами, но не смог придумать как из такого списка дропнуть первый элемент. Ладно, скажем максимум мы можем пометить элемент как удалённый. Нормально, что на какой-то странице ты видишь пробелы вместо сообщений или надпись «НЛО прилетело» - зато страницы не сьезжают - скажем ты дал кому-то ссылку на страницу 176 и она осталась валидной, когда модеры потёрли пару страниц.

MongoDB?

«Заведи в монге документ с кучей списков и херачь в них» - скажет читатель (нормальный читатель скажет вообще не выпёрдываться и взять готовый движок на mysql). Какая у монги будет производительность, если треды будут по 40К страниц (элементов списка). Сколько в секунду можно будет добавить элементов списка в конец? Как быстро оно может достать N элементов с заданным offset?

Телеграм чатик: https://t.me/joinchat/FqPvww9IXM0RmazHBRiamw

На всех видосах собирают какой-то мелкий мотор.

А если размером с кирпич на больших солнечных батареях собрать? Шоб рев стоял!

Если серьёзно, то хочется понять какие солнечные батареи взять, как их выбрать по эффективности. Рассчитываю на пасмурную питерскую погоду.

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

http://telegra.ph/Ideya-allokatora-01-15

Обсудите пожалуйста.

P.S. Похоже идея не взлетела: чтобы она работала, надо как-то подправлять offset-ы на перемещённые куски, а реализация этого обернётся полной жопою, съедающей все выгоды. Да и косвенный доступ снижает производительность. Автор тупой упырь и не читал литературу по аллокаторам, например http://www.gii.upv.es/tlsf/files/ecrts04_tlsf.pdf

Сформулирую задачу.

Есть множество объектов, каждый из которых выделяет себе в пределе до 16 строк произвольной длины. Объекты делают это в разное время. Условно говоря, объект - это коннект до юзера и строка выделяется когда юзер пишет месагу в чатик. Когда накапливается условно 16 строк, объект их освобождает разом.

Вот ищется максимально производительный аллокатор под такое.

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

Для Ъ (пост из тынца выше)

Обсудите такую идею аллокатора. Юзкейс - выделять объекты размером не более, допустим, 4КБ и иметь минимум оверхеда на служебные структуры. Применять в in-memory nosql хранилке ключей key=value.

Выделяем объекты любого размера (до 4kb) последовательно в странице (как арена аллокатор) (макс размер объекта = не более страницы), при заполнении страницы берём у ОС новую и продолжаем. При освобождении объекта, помечаем его в странице как свободный, но выделение в этой точке невозможно - выделялка максимально тупая и берёт всегда только с конца «текущей».

В процессе освобождения очередного элемента проверяем страницу Q (в которой он только что был освобождён) на суммарное количество свободных фрагментов sum_free. Если sum_free достигает некого критического уровня (скажем, 0.4 от общего размера страницы) - делаем compaction - вытряхиваем все несвободные фрагменты из страницы Q в новую чистую страницу (линейное время), подменяем новой страницей страницу Q, убиваем страницу Q. Помещаем нашу новую страницу в множество страниц где снова можно выделять память с конца (при этом её конец будет уже не в начале, т.к. какое-то кол-во памяти там уже сожрано).

Чтобы работала подмена страниц, юзеры такого аллокатора ссылаются на свои данные не просто указателем, а парой (page_idx, offset), где page_idx - индекс страницы в таблице страниц. То есть, подмена страниц будет делаться заменой указателя в нужном индексе этой таблицы. page_idx и offset могут быть размера 32 bit и 16 bit (если страница на неск. КБ), что суммарно будет не жирнее pointer. Для доступа к своему куску: data_ptr = table[page_idx] + offset. Доступ юзеру к началу страницы нужен, чтобы освобождающий поток мог делать работу с заголовком страницы по увеличению счётчика sum_free.

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

emu 0404 - слишком круто.

emu 0204 - норм, но их мало чё-то стало, может народ пробухается после НГ и выложит.

Чё ещё есть подобного рода тыров за две-три на авите?

Сабж. В гиговых винтах hitachi магниты особо крупные - где-то 3мм, а железка его держащая ~4mm - плоскогубцами это не гнётся.

Битьё молотком по сабжу, зажатому в тиски, с целью сгибания основы с ожидаемым отваливанием в результате этого магнитом даёт только сотрясение верстака.

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

Забить между магнитом и железкой лезвие - пробовал в прошлый раз - результат в принципе даёт, но приводит с сдиранию с магнита тонкого слоя металлической шкуры.

Ещё способы в студию!

Тиски покруче и молоток поадовее - недоступно.

Падали софтины. Terminator в кору падал раз в месяц. Я думал: авторы дебилы. Оказалось icewm старый глючил. В новой убунте с новым icewm падать те же софтины перестали.

Мораль: апгрейдите icewm! Жесть конечно, что глюк в window manager может приводить к сабжевым эффектам. Не бронево как-то это устроено.

Может кто-то в двух словах описать устройство и основную идею Apache Spark? Объяснить в терминах программиста, который бы попытался разработать spark. Типа, описать минимальный spark, который можно написать на коленке. Некая минимальная софтина, которая может быть прообразом spark. И так же на примере объяснить чем это отличается от hadoop.

На что софт тратит время в hadoop, чего не происходит в spark, за счёт чего spark быстрее и на каких задачах, а где всё-таки нельзя им заменить hadoop.