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

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

Теперь внимание вопрос. Как лучше всего делать такой перезапуск?

1. Примерно как телега. Если я правильно догадываюсь, то там базовый/основной бинарник не является приложением, а микро-приложением или скриптом, который смотрит в спецпапочку с бинарниками и запускает самый свежий, который уже таки приложение. Для обновления нужно просто скачать новую версию себя и положить рядом со старой, а потом просто сдохнуть с условным кодом «-5» - родительский микробинарник пойдёт снова запускать и поднимет самую свежую версию. Тут даже можно строить приколы с откатами: если после запуска новой версии какие-то условия не были выполнены, то посчитать её багованной, переименовать в .trash и снова уйти в перезапуск, запустив в итоге предыдущую.

2. Скачать новую, положять рядом. Но не сдыхать, а провести некое освобождение ресурсов, позакрывать сокеты и файлы и просто вызвать execve(). PID останется тот же, но «все структуры» старого приложения заместят новым стартующим. Почему это плохо? Кажется только тем, что (1) проще и понятнее: и pid меняется и не надо париться о том, что ты там недозакрывал из дескрипторов и т.п.

Юзкейс.

Есть 10 серваков с readonly корнем.

На них через systemd всегда запускается некая софтина, которой дается имя Name и путь Root (смотрит в ramdisk).

У каждой железки разный Name.

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

Вот посоветуйте такую софтину.

У железок нет белых ип.

Есть гора фоток. Надо выбрать «хорошие». Надо простую софтину как «eog», но чтобы на текущей фотке можно было нажать клавишу и она mv в указанный в настройках каталог. То есть, я сижу быстро мотаю фотки и на каких-то из них жму спецклавишу, по которой они из «неразобранное» кидаются в каталог «good». Теги не хочу, хочу именно запуск своего спецскрипта. Всё. Спасибо.

P.S. Запустить midnight commander и жать на каждой enter и потом какое-то решение ещё принимать - это в разы медленнее указанного идеального сценария.

«apt install eog-plugins» подвозит плагин «export to separate directory» - оно делает почти что я хочу, но через контекстное меню и КОПИРОВАНИЕМ, а надо именно mv

Самое гениальное решение в текущей ситуации: Delete жать на текущей картинке, она улетает в Trash каталог на том же смонтированно диске. Это почти что приемлемо и годно!

А правда ли, что на современной андроид мобиле данные на флешке шифрованы каким-то ключом, который генерится на этапе последнего factory reset и потом в спецразделе лежит и поднимается оттуда системой при загрузке и ФС расшифровывается наподобие LUKS?

То есть, если мне надо гарантировать, чтобы выпаивание флешки не читало мои фотки, то я просто делаю factory reset, который просирает ключ и вся файловая система остаётся какая и была, просто теперь она нечитаемый мусор?

Или как оно работает - вот это вот «factory reset удаляет все пользовательские данные»? Не флешку же всю нулями затирает - это же долго на 512 гигах было бы. А гарантировать непрочтение данных ловкими выпаивателями nand flash микрухи же как-то нужно, а то паял с фенами много развелось. Так как же это работает?

1. Воткнуть туда jack 3.5 гарнитуру 4 контактную.
2. Спейрить это с телефоном. И шоб оно передавало туда микрофон, а не только музон в наушники.
3. li ion usb c заряжаемое.

Спасибучко.

p.s. Накупить на алике рулеза и спаять самому - ясно, надо готовое предложить.

Щас не будет речи про mysql, postgres и т.п. B про какие-либо реляции не будет - то есть, отношения между таблицами не волнуют. Не волнуют и транзакции.

Вот предположим у вас есть хранилка key=value. Казалось бы, в такую хранилку можно упихать примерно всё и выразить через кучу key-value любые данные и схемы и я даже знаю как на двух redis в разных кусках планеты бабки между клиентами атомарно переводить без блокчейна (CAS только прикрутить к key-value хранилке, но это примитивно делается). Это всё не ново и понятно.

А теперь предположим, что у вас есть хранилка табличек. В ней можно:

1. Создать табличку со статически типизированной строгой схемой, т.е. задать набор колонок с фиксированными типами (string, int, float и т.п.).
2. Добавлять/удалять колонки.
3. Апгрейдить типы (sting на int поменять и хранилка сама скастит все числа из строк в инты, например).
4. Хранить широкие строки (с кучей колонок), а выбирать только нужные.
5. Замутить нижний слой хранения колоночный, тогда выбор отдельных колонок будет оптимизирован, а полная строка выбираться медленнее ну и пофиг.

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

Про реляции, джойны, транзакции мы тут не говорим, они сами по себе к таблицам никакого отношения не имеют и тут не интересны. SQL тоже ни при чём, в таблицу вы можете ходить по самодельному бинарному протоколу любой степени жопности, так же как и в key-value хранилку ходить через SQL (select from A value where key = K).

Например:

1. Можно добиться компактности, если числа больше 999 хранить в инте, а не в строке.
2. Статической типизацией колонок можно несколько ограничивать разнообразие бреда.
3. Ненужные колонки можно целиком выкинуть (за разную цену в row и column движках хранения конечно, но можно) или добавить новые. Хотя в key-value можно тоже перестать пейсать какое-то поле в json или начать его пейсать, подготовив код к факту наличия этого поля.
4. Великая мудрость о том, что хранение json-ов - признак дебилов, поскольку в итоге набор и типы полей в объектах достаточно фиксированы и если вы схему не зафиксировали в хранилке, то вы чёрт обоссаный наверное, который вечно живёт на временном решении - всё ещё продолжает выполняться.
5. Если создать таблицу (key : string, value : string), то можно этим частным случаем таблицы поглотить всю предметную область key-value сразу целиком. Работать будет за то же время. Физически хранить это в памяти или на диске можно в итоге точно так же. Это позволит унифицировать доступ к key-value и к другого типа данным через одну хрень.
6. Если в одной и той же key-value хранилке два разных отдела пытаются хранить свою инфу, то им придётся отделяться друг от друга некими «префиксами» у ключей: ключ «sobaka» у разных отделов будет выглядеть так: department1.sobaka=123, department2.sobaka=551, в итоге всё хранилище засрано этими префиксами, хотя решение тупое и надо просто поднять два разных редиса под такое, но всё-таки. А в случае табличек это просто две разные таблички, которые лежат компактнее, т.к. не надо хранить префиксы в каждой записи. Да, можно в случае key-value сжать рядом лежащие ключи по префиксам.
7. Можно пилить разные интересные индексы: например по какой-то десятой int-колонке создать индекс, который упорядочивает все записи по ней и потом быстрее выбирать. А в случае key-value это надо будет те же данные налить в нужном порядке в другое хранилище и потом ещё следить за согласованностью двух.

В общем, хочется подобной фигни почитать. Чисто на уровне системы хранения, без отсылок к каким-то там продуктам уровня postgres. И это не тред о том, что мне взять - redis или postgres, речь о фундаментальных различиях в возможностях key-value и табличек.

Документ-ориентированную хрень не рассматриваю, это какой-то лютый треш и содомия, да - люди пытались улучшить key-value для рукожопов, не осиливших постгрес.

Allwinner A20
1GB DDR3
SD card boot
LAN 100/1000
Wifi 2.4 ghz/usb bus
7 USB ports
VGA
HDMI

Вот такая железка типа cubieboard-3 по средней производительности (учитывая число ядер и аппаратные кодеки h264, обьём ОЗУ) на какую raspberry больше похожа?

Второй вопрос: чё бы из неё сделать полезного, кроме как прикрутить вебкамеру и запилить motion-detection в прихожей?

Надо открыть каталог с 2К мелких mp3 файлов и оперативно их выборочно позапускать. Почти как в семплере быстро позапускать. Представьте, что я за кулисами сцены и мне надо мотать ПРОСТОЙ список файлов и БЫСТРО запускать нужный без лишних ссаных приколов с какими-то плейлистами, альбумами, артистами, годами, жанрами и прочей перди меломанской.

rhytmbox: это жесточайшие танцы с бубном, ориентировано на меломанов и плейлистофагов: собери плейлист, импортируй - жопа отвалится пока наконец удастся что-то послушать, а при прослушивании элементарных функций нет: если у тебя куча файлов по 3 секунды, то сказать софтине не воспроизводить следующий просто невозможно. Непонятно как отображать просто файлы с теми именами, которые у них изначально есть - вылезают всякие артисты, альбумы и прочая хрень. А я хочу просто список файлов с сортировкой по времени их создания. Этот rhytmbox к тому же тупо затыкается, если по очереди воспроизведения ему попадается файл длиной меньше секунды - какие-то лютые глюки-баги и неудобства на каждом шагу. Хочется софтину в разы ПРОЩЕ и ОТЗЫВЧИВЕЕ.

Спасибо!

P.S. Кажется audacious годится на озвученную роль. Весьма тупая (прям как надо) и простая софтина, хотя и альбумы и артисты и годы в ней есть, но их можно выкинуть из отображения и показывать filename. Так же удалось заставить не воспроизводить все треки подряд, а останавливаться после каждого. Интерфейс прост, выглядит как софт из НИИ ракетостроения, быстр, работает вроде бы как надо. Хотя на высоко-DPI мониторе оно не смогло понять, что шрифты надо делать побольше пока.

Долго юзаю Logitech MX anywhere 3. Пробовал Logitech MX master 3S - в первом руке свободнее, во втором как будто приковали к раскладушке в одном положении!

Использую только bluetooth коннект в ноут, айдейт частоты курсора намерянный этой штукой https://devicetests.com/mouse-rate-test - не выше 120 per second.

Так вот, там у меня 4000 dpi. А ещё бывает 8000 dpi в «anywhere» 3S (зато там тихий курсор).

Короче, как вообще можно заметить эту разницу-то и нафиг она кому упала? Люди же даже в плотности 300 dpi точек не увидят на принтере, мыши-то нафига больше? Короче какой наркоман заметит 8000 vs 4000? Геймеры с подключением не через BT а через фирменный logitech радиосвисток? Чё, правда заметно что-ли? Правда правда?

Такой вот вопросик, спасибушко.

P.S. А ещё объясните разницу на практике между лазерным глазом и «LED». Ну что такое когерентное электромагнитное излучение я понимаю, но интересует практическое про мышь. На полированном зеркале типа отлично работает, а на обычной тряпке будет глючить, да? Но на anywhere тоже вроде бы laser написано, но пока ни на чём не глючила.

P.P.S. нафига мне блютус - удобненько без провода. Но честно да, лаги заметить можно ЕСЛИ ПРИГЛЯДЕТЬСЯ прямо пристально и увидишь прямо очень мелкий лаг, но в сравнении с какими-то первыми радиомышами 15-летней давности, где лаги были просто жопа, тут всё уже мало отличимо от провода для офисно-программерской работы. А чо, по фирменному радиосвистку logitech лаги ощутимо меньше и даже геймеры уважают?

Что-то, что даже IP не умеет получать под DHCP, а светит в сеть своим мак-адресом только. Что-то, что позволяет получать доступ к подключенному к этой железке 2.5 SATA диску через ethernet по какому-то стандартному в индустрии простому примитивному протоколу адресации секторов носителя.

Юзкейс: замена SATA<->USB шнурка на ethernet-шнурок и потенциально повышение полосы пропускания где-нибудь до гигабита.

Очередной тупой вопрос про работу в стиле «расскажите как там оно».

В чем минусы работы в Postgres Pro, а точнее не в самой этой организации, в которой наверное много умных людей, а работы над самим движком постгреса? Как устроены движки СУБД в целом представляю и с какими-то изнутри работал и вопрос не в этом. Вопрос именно в особенностях кодовой базы постгреса и сообществе. Говорят, у них там есть главный дед-шаман, который может во время доклада ответить на звонок и поговорить, не уважая аудиторию! Может и врут. Насколько такая работа будет вечным скучным багофиксом, мерженьем патчей, сидением в gdb? Тяжело ли там быть разработчиком чего-то нового (новые типы индексов, систем хранения, типов данных, оптимизаторов, статистик, фич), исследователем и бороздить просторы как в моём любимом яндексе, в котором всегда есть шанс запилить очередное NIH на go/C++ с нуля со своим гениальным алгоритмом, который конечно уже где-то придумали по 10 раз, и раскатать в прод?

Известно пока только одно: работать в яндексе над NIH - менее перспективно для карьеры, славы, денег и тупо наличия работы в будущем, чем умение пилить постгрес изнутри. В конце-концов после пары-тройки лет пиления постгреса изнутри можно пойти возглавить любой отдел постгресистов в любом банке и купить бентли с зарплаты, т.к. постгрес помирать совершенно не собирается и «экспертиза» в нём будет востребована нехило, причём не только в нашей стране. Знать постгрес изнутри - очень неплохой скилл, позволяющий выруливать в любом споре с админами-алкашами или пойти работать в перкону! Но возможно всё это крайне скучно и требует усидчивости, доступной только 55-летним в силу возраста?

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

Здравствуйте. Ламерский вопрос! Есть Openwrt-железка D-Link DIR-620 настроенная как надо какое-то время назад. Не скажу версию, какая-то древноватая уже конечно типа 15.что-то там. Проблема: иногда (раз в сутки или после выключения роутера) отваливается WAN Как отваливается: непонятно физически как. В Network -> Interfaces WAN показывает какой-то полученный по DHCP IP-адрес и сколько-то пакетов TX,RX, но «в браузере яндекс не открывается». При этом прописаны DNS 8.8.8.8 и пара яндексовских в дополнительных свойствах этого WAN. Но стоит нажать кнопочку Connect в этом WAN, так всё быстро поднимается на отличненько. Что это и как автоматизировать поднятие? В целом дружу с линуксом, но через консоль изучать ничего не пытался, настроил всё через встроенную Люси-вебморду. Нужны какие-то гипотезы того «что бы это могло быть».

Ещё раз по пунктам:

1. Подключение клиентской железки - один из LAN-портов.
2. Кабель от провайдера ethernet воткнут в другой LAN-порт.
3. Эти разные порты разбиты на разные группы, первая названа LAN, вторая WAN
4. Всё это как-то вжух-вжух настроено (2 дня заняло, ага), включая фейрвольно-натовые вещи и на IP-уровне работает, потому что «интернет на компе есть».
5. Но иногда надо в WAN ходить руками кнопку Connect нажимать.

Перемещено hobbit из general

Вот допустим работаю я себе в тёплом уютном яндексе за 3-4 килоевро на руки, ко всему привык, кругом цивилизация, доставки, такси, друзья.

Говорят, Кипр - это «грязненько, жарко и дорого» - рязань с климатом сочи и ценами овер-Москвы, и ничего толком нет (кроме недвиги с видом на море) и вокруг одни полукриминальные стартапы, всмысле высокорискованые. После тёплого лампового предсказуемого яндекса может стать грустно. Или повиг, 9 килоевро - это всё таки 9 килоевро - всегда можно вернуться в Москву и на накопленный капитал купить хату с видом на Кремль?

Да и ещё щас на БВ всякие войны, захотят Турки остров отжать…

Пост не про политику, а тупо про деньги, профитность, выгодность.

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

Это коллективный пост от трёх рыл сразу. Есть примитивная самописная на C++ СУБД. Некая не сложная софтина, внутри имеющая самописное B+-Tree или даже не B+-Tree, а что-то ещё более тупое и простое, но умеющее в сравнимый по эффективности доступ к части данных на диске. Реализована семантика таблиц. Таблица - это последовательность строк. Строка - это последовательность строго типизированных полей (колонок). Строка - это кортеж. Строки лежат отсортировано в порядке Primary Key. PK - это конкатенация (суб-кортеж) каких-то колонок, по которой (суб-кортежу) сортируются строки (ну в общем тут всё как везде, как в mysql внутри). Физически строка - это тупо конкатенация всех колонок. Например при схеме (id : int32, age : int32, time : int32) строка будет представлять собой три четырёхбайтных поля и занимать 3*4 байта. Со строками переменной длины может чуть сложнее, но вы поняли. Ну и ещё у таблички хранится схема (один раз), чтобы понимать, где в этих 12 байтах искать поле time (отступи 8 байт и вот оно).

Код очень тупой и там не особо много строк. Он настолько тупой, что нет реляционности и она не нужна - ну то есть база не понимает отношений между таблиц, форин кеев и джоинов. Таблица - это тупо «неймспейс со схемой», в который можно навалить строк. Таблица - это как каталог, куда можно напихать строк согласно схеме этой таблицы. Всё это - буквально key=value хранилка, где каждое key=value - это строка таблицы, а в качестве key рассматривается PK этой строки. Ну, логически оно и внутри MySQL такое, только MySQL умеет транзакции, ACID, реляции и всё такое, а здесь ничего этого нет. Есть какие-то простые гарантии, типа что таблица всегда в каком-то целостном состоянии. Но гарантии того, что ты прочитаешь то, что записал до этого - нет, потому что перед твоей операцией чтения кто-то другой мог зайти и насрать. Транзакций-то нет. Ну ладно, не суть. Они и не нужны. Задача только в том, чтобы пользователь видел семантику таблиц, потому что таблицы всем удобны наличием схемы и строго типизированые строки удобны потому, что есть семантика полей и типов этих полей. А, ну ещё оно умеет add column, drop column, alter column - ну бывает захотелось поле добавить или тип поменять. А, ну ещё оно умеет несколько индексов на таблицу - то есть PK может быть один, а ещё 5 индексов других типов по другим под-кортежам - это всё тоже не очень сложно и не очень интересно - каждый индекс - это просто ещё одна какая-то поисковая-индексирующая структура данных сбоку от таблицы.

Ко всему этому прикручен WAL и чекпоинты. В общем, данные не просираются - все пишущие запросы дописываются в конце файлика (который рубится на куски по 512 МБ) - (это наш WAL), и периодически делаются чекпоинты - примерно как в терминологии постгреса, но чуть проще.

Данный код работает максимально близко по производительности к какому-нибудь redis или memcache, потому что он жесть какой тупой (ни транзакций, нихрена). Максимум умного что там происходит - это выпаршивание отдельных полей из пачки байтиков по имени этих полей - то есть не тупое key=value, а умное key=value, которое понимает стурктуру value. Иногда и не понимает - есть тупые запросы типа get_all(), которые не думая отдают в сеть всю строку без её парсинга и валидации. Ну и ещё иногда происходит доступ к диску для подгрузки каких-то страниц, которых в памяти не оказалось - вот это наверное максимально умное. Даже планировщика запросов нет - в языке запросов надо явно указать каким индексом пользоваться при селектах, само не догадается. Таким образом, индексы - это как-бы отдельные структуры данных, которые смотрят в ту же таблицу и которые явно указывает юзер. Очень тупо, да, зато надёжно как кусок кирпича.

Тянет один такой процесс на сервере сейчас 20K RPS любых типов (чтение или запись) в один поток (если данные в памяти конечно есть и на долгий диск не пришлось ходить). Надо больше - горизонтально масштабируем и готово (ну да, чтобы посчитать число строк, в которых time > 123 AND time < 888, придётся послать запрос на все процессы и проагрегировать на запросчике, но это редко нужно). Опять же не суть, рассматриваем один процесс.

Тут приходит Петрович и говорит - поцоны, вы грибов хапнули, зачем вы всё это пишете на С++ с нуля? Можно же просто взять SQLite, залинковать со своим сетевым интерфейсом и DBMS готова! И думать не надо и всё оттестировано сотнями миллиардов леммингов и быстро работает - применяемость sqlite на самых слабых смартфонов для хранения конфигов и куки соврать не дадут.

Вопрос - где будут просадки по производительности или по какому-то другому важному параметру, например по поддерживаемости и изменяемости кода?

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

Второй пункт, вытекает из первого. Хоть в SQLite багов и нет, но применяя SQLite мы уже не умеем отвечать на вопрос «почему тормозило». Надо инвестировать полгода-год в чтение исходников SQLite фуллтайм и в становление SQLite-хакером. Сходу мы становимся рабами готовой библиотеки, про которую можем отвечать только «да хрен его знает почему не больше 4К запросов в секунду, день такой!».

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

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

Есть старое интервью с разработчиков Reiser4, Эдуардом Шишкиным. Вокруг интервью было много срача и политоты, но это меня мало волнует. Заинтересовало выказывание (или наброс) Эдуарда о том, что «B+-Tree - устарело» (мог напутать точный вид структуры данных).

Хотелось бы разворачивания этой мысли. Почему устарело?

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

Вопрос об аутентификации Алисы и «мире электронных подписей». Алиса хочет прислать Бобу токен (строку), по которому Боб может сказать, что строка сформирована именно Алисой.

Алиса формирует строку вида:

<HASH>-<TIME>-HELLOWORLD-<RAND-128>

где

<HASH> - хеш всей строки, за исключением самого ; предполагается, что алгоритм хеширования достаточно упорот и надёжен в меру важности этого спецзадания - какой-то распространённый SHA256, например или же самодельный с известным (или неизвестным) риском.

<TIME> - текущее время, нужное тут низачем, кроме как влиять на значение и внести немного рандома, ну и отчасти показать свои часы.

HELLOWORLD - заведомо известная всем строка.

<RAND-128> - рандомные 128 бит с потолка (одна задача - влиять на значение хеша).

Алиса шифрует эту строку каким-то симметричным алгоритмом, типа AES, используя Ключ К. Ключ К - сгенерированные ранее и сохранённые рандомные 512 байт.

Тот же ключ есть у Боба. И больше ни у кого.

Алиса передаёт зашифрованную строку Бобу. Боб расшифровывает её ключом К, вычисляет хеш от строки (кроме поля ) и сверяет вычисленный хеш с полем . А так же удостоверяется, что после лежит строка , ну и у строки какой-то известный размер. Ну, например, что не слишком в прошлом. Если все проверки - true, тогда Боб делает вывод, что строка пришла от Алисы, а не кого-то другого.

Вопросы:

1. считается ли такой способ ответа на вопрос «Алиса ли прислала строку» мало-мальски вменяемым? В чём уязвимости?
2. Достаточно ли будет выкинуть , а передавать просто <RAND-128>-HELLOWORLD и проверять только наличие HELLOWORLD в строке на нужном месте? Тут замысел в том, что <RAND-128> будет непредсказуемо менять стейт машины шифрования так, что к моменту шифрования HELLOWORLD, шифровалка будет уже в достаточно рандомном состоянии, чтобы HELLOWORLD шифровался постоянно в разные байтики. Будет ли это работать?

Кража ключа у одного из них считается провалом, конечно же.

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

В X230 стоит 35-ваттный проц вроде, что сказывается на батарейке.

Хотелось бы найти что-то из thinkpad-ов с

1. 14+ экраном, хотя наверное не критично - как-то жил на X230 же.
2. 15W процом пофиг какого поколения
3. съёмным аккумом
4. не припаянной памятью
5. IPS матрицей
6. тыщ за 20 на авито.

Какую модель гуглить?

P.S. Похоже я хочу X270.

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

Сложно-философский вопрос. Не будем рассматривать транзакции и какую-либо связь между таблицами, то есть не будет слова «реляционные (нет реляций между)». Рассмотрим просто таблицу. Таблица - набор строк, каждая строка - набор строго типизированных колонок. Хранит данные - построчно или поколоночно - неважно - зависит от задачи чтения. Главное, что таблица.

Утверждение: в форму таблицы впихивается очень существенное число разных данных. А которые не впихиваются - впихиваются при допиле движка таблиц специальными хаками, но остаётся внешне таблицей. Например мы хотим хранить key:string=[множество-uint64]. Возможно для какой-то задачи, оптимально будет сохранить и на диске и в памяти структуру данных вида (key_len, key, потом тупо последовательность всех uint64 отсортированных). И рядом хеш-табличку по key возможно. Но если бы мы записывали это в таблицу, у нас бы было N число строк вида (key, uint64), где N - число разных uint64, а key бы повторялся. Сходу это выглядит неоптимальным, потому что кучу раз key повторили, но умная таблица не будет хранить повторяющиеся key и получится так же оптимально, как в наивном подходе и расположит всю таблицу прямо как в примере выше - не как последовательность кортежей (SEE_PREV_VALUE, uint64), а прям как один список (uint64, uint64, …., uint64). Я ж говорю - с хаками, но таблица.

А теперь вопрос. Предположим вы бекенд-C++-тимлид в каком-то инновационном банке (которому не жалко рискнуть наняв вас, а не поставив везде Oracle) или в каких-нибудь там одноклассниках или в гугло-яндексе. Тут давайте не будем вспоминать, что в этих организациях реально используется или говорить, что все они давно закоренели и там таких опытов не ставят, а работает YDB - пытаюсь показать масштаб.

1. Предположим у вас есть C++ фреймворк, куда входит сетевой код принятия запросов (протокол-буфферс, например), какой-то движок хранения данных произвольного формата в файлах, код записи-воспроизвдеения WAL, код репликации, код статистики… И этот фреймворк позволяет за 20 минут под нужный формат данных наклепать на коленке новую «СУБД», написав буквально какой-то std::unordered_set в функции main() и «завернув» этот контейнер в данный фреймворк, выдав к нему доступ из сети и сериализацию/десериализацию на диск целиком и запись в WAL и т.п. То есть, к вам приходят люди, которые хотят хранить key=value, вы оформляете им новую «СУБД» с 2 методами - set и get и катите на прод, все юзают, все счастливы. Приходят другие люди, хотят по 64-битному числу хранить множество из миллиона других 64-битных чисел и искать в нём. Вы тоже быстро фигачите какую-то структуру данных на готовых контейнерах или даже достаёте из закромов какую-то свою супероптимальную, заврорачиваете в фреймворк, куяк-куяк и в продакшен. Не нужна какая-то СУБД - выкинули, не жалко, кода было мало.

2. И у вас есть второй вариант: сделать один хороший табличный «движок». Все эти клиенты получают всегда одно и то же представление, один и тот же интерфейс (возможно даже SQL). В особо упоротых сценариях вы дорабатываете этот движок под их формат данных (доработка повышает эффективность использования памяти/диска данной таблицей) и эта доработка оформляется просто в отдельный типа индекса или в некое хитрое слово, указываемое на этапе CREATE TABLE.

По какому пути вы бы двигались и ПОЧЕМУ?

1. Кажется достаточно симпатичным путём, потому что хотя каждая новая «СУБД» - снова какой-то велосипед, но трудозатраты смешны - описать центральную структуру данных, остальное готово. Более того, у сторонников супер-оптимизаций тут все козыри: мол вы в «табличном движке общего назначения» никогда не задрочитесь так, как можем мы, зная конкретную структуру данных пользователя. Что, кстати, спорно - не факт, что задрачивальщики решают какую-то реальную проблему.

2. Выглядит тоже круто, поскольку многие моменты унифицируются. Тайм Ту Маркет ещё ниже - не надо даже ждать пока под твою структуру данных разраб почешется и напишет новый (хоть и крошечный) код, ты можешь уже сейчас CREATE TABLE и в 95% случаев тебе хватит. Не хватит - тогда и придёшь ныть-оптимизировать. Универсальные моменты: способы доступа, способы анализа, язык общения между командами (все говорят про таблицы, а не каждый про свою абстрактную опердень, выраженную в каждый раз новом C++ коде), способы конвертации данных (переливка между таблицами - это понятнее, чем писать конвертеры данных между одним форматом (1) и другим форматом (1) и т.п., проще дорабатывать всякие автоматические решардинги или переливаторы данных - один раз сделали для таблиц и работает у всех, не надо каждый раз думать как оригинальный формат данных (1) обрабатывать. В конце-концов, можно сделать DROP COLUMN, что в случае (1) оборачивается жестью и конвертацией старых данных).

Спасибо.

Упрощённо:

1. Есть самописный сервер на C++, в котором есть необходимый набор чего угодно из разряда: epoll-принималка коннектов, набор OPUS-кодера-декодера, цифровые фильтры, смешивалки сигналов, всякое нужное DSP и т.п. На этой стороне всё прозрачно понятно, дорабатываемо в любом направлении. Вопросов по этой части не будет.

2. Android-приложение, которого пока нет. В нём только 2 кнопки «старт» и «стоп». Стоп делает его неактивным, интереснее что происходит в режиме «старт». В этом режиме приложение в фоне находится в состоянии постоянного «звонка». Под звонком понимается открытое соединение к серверу, в которое наше приложение постоянно шлёт поток OPUS-моно-20kbps, закодированный с микрофона телефона (или с гарнитуры) и параллельно получает аналогичный поток с сервера, декодирует и пихает в наушники. Строго говоря, приложение и сервер шлют свои потоки не постоянно, а возможно по сигналу от Voice Activity Detector, но это детали.

Как это делается у взрослых IP-телефонных чуваков или в браузерах, SIP, WebRTC - всё это не интересно, ибо это переусложнено для моего вышеописанного случая. Да, можно припахать, но зачем. Да и хочется сделать с нуля и очень примитивное.

Вопросы тут в другом:

1. Андроид - штука сложная и у него существует много разных понятий «звонок». Звонком является не любое состояние, при котором включен микрофон и динамик. Например, если ты звонишь по GSM то отрубается mp3-плеер с музоном. Если ты звонишь в зуме, то это выглядит как-то иначе, но плеер тоже отрубается. А если ты звонишь в телеграме, то музон в плеере становится монофоническим, не отрубаясь. Короче «звонки» - это какое-то сложное глобалное состояние системы, которое влияет на другие приложения и на аудиосистему андроид-железки в целом. Нельзя просто так взять и написать приложение «диктофон», которое данные с микрофона будет отправлять в сеть, а данные из сети - в динамик и назвать это звонилкой. Короче тут вопрос в том, как правильно оформаляется «звонок» в приложении, чтобы он был по «статусу» хотя-бы как телеграмный звонок, когда ты заходишь в голосовой чат в телеге.

2. Верно ли, что нельзя просто так взять сырые данные с микрофона андроида в указанном тобой формате, типа 48000/16bit/mono, а потом спокойно засунуть их в свой libopus-кодек, скомпилированный сишным компилятором и отправить в сеть? Андроидные микрофоны, видимые уровню приложения, способны отдать только какой-то готовый закодированный во что-то типа AAC или там mp4 поток? Если я хочу послать своему серверу OPUS-поток или вообще изобрести свой кодек, то мне надо сначала раскодировать кодированный поток в сырые байтики, а потом закодировать в нужный мне кодек? Зачем мне именно OPUS - ну потому что лучше ничего нет и потому что я хочу контролировать все нюансы звука, выбирать битрейт в зависимости от нагруженности сервера или ещё каких-то своих приколов, ну и потому что я уже умею с ним хорошо работать и не хочу переставать.

В общем, хотелось бы получить некоторых ключевых слов из мира java/android разработки, копая в которые я выйду на нужные имена классов/сущностей в SDK андроид девелопмента и почитаю, что правильно в таких случаях читать.

P.S. Советы «возьми такую-то либо и не мучайся» не нужны, цели не мучаться нет, цель больше самообразовательная, чем разработка продукта с выходом на IPO в сжатые сроки.

Хочется неформальное объяснение всего связанного с apt до глубины глубин. Не столько то, как это работает на системе, сколько социально-организационные аспекты. Например, какие пакеты попадают в репу, какие бывают репы, кто админит и заведует репами, как патлаты эти люди, какие у них свитера, какие политические взгляды, где живут, что думают о мире, насколько легко занести вирусы в репы, кто кеширует репы, насколько велики гарантии доступности реп или зеркал, какие ещё кроме apt бывают пакетные менеджеры (snap) и на тех же самых распространённых дебианах и убунтах в мире, почему пакет попадает туда, но не попадает сюда. Кто компилит и тестит пакеты, где стоит компиляторная ферма для реп.

Разные там срачи и споры о версиях, обновлениях, порядке раскаток, компилений, распространений. Политиках обновления дистров, придумывания названий новых убунт и как всё это связано с apt и так далее.

Короче какой-то такой сюжетец документальный в духе «Настоящее Время» канала про apt и всё вокруг этого.