Вот допустим работаю я себе в тёплом уютном яндексе за 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 и всё вокруг этого.

Почти ansible, да не совсем. Почти rsync, да не совсем. Почти apt-get, но надо проще.

1. Есть 10 одноплатников, у каждого / смонтирован «ro», чтобы не портили. Файловые системы могут отличаться только разными настройками сети, плюс у каждого в /etc/my-role.conf лежит своё имя «роли» этого одноплатника. Роль - это основное, чем он характеризуется для внешнего мира, десять штук с одинаковой ролью - одинаковые. Одноплатник тут упомянут зачем, чтобы сделать акцент на копеечных масштабах и нагрузках. Бывает одноплатник для видеонаблюдения, бывает одноплатник для измерения температуры, бывает одноплатник для пожарной сигнализации. И т.п.

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

3. Нужно чтобы на каждом одноплатнике работал некий не обновляемый прибитый гвоздями процесс R, запускаемый как systemd «simple» сервис, который бы периодически ходил на центральный прибитый гвоздями домен, отправлял туда описание каталога W и свою роль. В ответ бы он получал пути, которые нужно удалить или обновить. Описание каталога W - это список путей до существующих файлов в каталоге W, где про каждый файл изестен sha1 и размер. Какбэ индекс W. Центральный сервер в ответ на описание каталога W выдаёт новое описание W1. Далее процесс R скачивает недостающие или не правильные файлы и обновляет и атомарно подменяет их в W (rename downloading.tmp goodname.so). Так же процесс R удаляет файлы, которых нет в новой версии W1.

4. Так же нужно, чтобы процесс R служил неким простым systemd, который бы умел простую вещь: понимать список запущенных процессов, их sha1 и их аргументов. Если у процесса A это меняется (поменялся sha1 и был скачан новый бинарник), то старому надо послать TERM или -9 и запустить его заново. То есть, помимо W1 передаётся некий список RUN1, где перечислены бираники и их sha1, которые щас должны работать.

В общем, обмен списком содержимого каталога и поддерживальщик запущенности бинарников таким sha1, которые есть в списке «должно быть запущено». Всё лежит на рамдиске, теряется при первом же ребуте. Единственно стабильные вещи это:

• имя роли
• запущенные процесс R с флешки
• гвоздями прибитый домен «дистрибьютора», куда можно прийти с ролью и сказать «чо почём, как дила, я роль N, мой W такой-то, дай новый W1 и RUN1».

Белых айпишников нет, в железки никто пойти не может.

Такие дела. Есть чё?

P.S. За пару вечеров нафигачил на C++ костяк собственного решения. Не сложное что-то. Оно же будет служить и заменой systemd для моих «демонов». Сделать fork() + execve() оказалось легко и не больно, а получать SIGCHLD и узнавать кто подох и перезапустить через заданный таймаут тоже проще простого. В общем, получается такой компактное решение, которое всё что надо делает из коробки…

1. Есть железка cubieboard3/cubietruck, но проблема вряд-ли специфична. На неё месте мог бы быть любой Raspberry. На ней есть распаянная флешка, там стоит какой-то неведомый линукс - он не важен. Важно, что этот распаянный линукс после загрузки умеет посылать запросы по BOOTP/DHCP в etnerhet-сеть и успешно получать себе IP-адрес. Дальше на распаянный линукс можно прийти по ssh и успешно получить официальный отлуп (паролей я не знаю). В общем, сеть работает в две стороны. Кроме распаянной флешки, железка умеет грузиться с SD-карты, если таковая воткнута.

2. У других людей была такая же железка, которую долго грузили с SD-карты, причём readonly (ну не важно). На SD-карте была свежая Armbian - ну считай Debian/Ubuntu, скомпилённая под этот Allwinner A20 ARM cortex-A7. Я взял у людей эту флешку и тупо скопировал себе корень. Как файлики. Тупо через tar -czvf весь корень. (да-да, я просто мог скачать образ Armbian и официально накатить, но были нужны накопившиеся изменения и оптимизации в системе, сделанные этими людьми; да-да, можно было скопировать флешку как образ, но это была бы другая история наверное). Далее взял вторую флешку, создал там таблицу разделов и 1 раздел ext4 (поставил ещё на нём галку BOOT, возможно это ни на что не влияет), распаковал в этот новый ext4 свой архив. Далее ещё немного страданий: скомпилил U-Boot, накатил на флешку U-Boot, пофиксил в /boot конфиге UUID корневой ext4 на правильный. В общем, успешно удаляя зубы через ноздри, заставил железку грузиться с моей франкенштейн-флешки.

3. Втыкаю свою новую флешку в свою железку. Косвенно по миганиям лампочек я вижу, что теперь загружается не что-то с распаянной флешки, ибо мигания совсем не характерны, а кое что и вообще не мигает! Грузится именно система с моей SD. Причём успехово загружается, видимо даже доходит до исполнения /etc/network/interfaces и начинает посылать BOOTP/DHCP запросы. Ну и по логам на DHCP-сервере я вижу, что запросы приходят, но немного другие… И тут-то самый цимес!

4. ВОПРОС-ПРИКОЛ. Прикол в том, что у системы с флешки сеть как будто односторонняя! С распаянной флешки приходит один MAC, а система с SD-карты говорит другой MAC (это не самое страшное, подумаешь разные MAC). Но системе с распаянной флешки IP-адрес выдают - она проходит успешно все 4 этапа: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK. Но система с SD-карты как будто физически не видит пакетов от DHCP-сервера. От SD-карты приходит DHCPDISCOVER, DHCP-сервер отвечает обратно DHCPOFFER и на этом конец до следующего повтора цикла. Как будто у системы на флешке этот MAC где-то забит, который конфликтует с физическим: как будто на исходящие пакеты проставляется какой-то левый, а входящие отбрасывает сама сетевуха физически, т.к. думает, что это пришло не для неё. Но нет! Замена MAC на SD-карте (написанием hwaddress ether 00:11:22:33:44:55 в /etc/network/interfaces где следует) не меняет ситуацию - точнее на DHCP-сервер SD-карта теперь приходит с тем же MAC, с каким приходила распаянная флешка, но толку нет. Свитчей между устройствами нет: клиент прямо кабелем UTP воткнут в сервер. Покопаться в системе в распаянной флешке возможности нет, чтобы что-то позучать, да и неинтересно. Грепание MAC-адреса, с которым в DHCP-сервер приходила SD-карта на этой SD-карте успехов не принесло, видимо это таки настоящий MAC, а на распаянной флешке забит левый, но это тоже не важно. Пробовал поставить статический адрес на SD-карту: эффект ещё интереснее: когда SD-карту пингуешь с хоста A, то SD-карта начинает вещать в сеть ARP-запросы: «а кто из вас тут A?», на что A отправляет ответы в сеть, но их как будто никто не видит. Скорее всего ARP-запросы от железки с пингом не связаны, а связаны с тем, что адрес A был случайно забит на SD-карту как default gateway, а с пингом просто по времени совпало. В общем, чудесный прикол: как будто слепая на приём сеть на cubieboard-3/cubietruck при загрузке с этой странной флешки. Я бы понял, если бы на флешке побились модули ядра про сеть, но в одну сторону-то сеть работает!

Кто что думает хорошего про всё это - поделитесь! Спасибо.

Немного дампа трафика с запросами DHCPDISCOVER и уходящими вникуда DHCPOFFER:

03:25:23.646663 02:0b:04:02:22:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:0b:04:02:22:20, length 300
03:25:23.646814 28:d2:44:bd:f8:8a > 02:0b:04:02:22:20, ethertype IPv4 (0x0800), length 342: 192.168.30.1.67 > 192.168.30.16.68: BOOTP/DHCP, Reply, length 300
03:25:39.412397 02:0b:04:02:22:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:0b:04:02:22:20, length 300
03:25:39.412829 28:d2:44:bd:f8:8a > 02:0b:04:02:22:20, ethertype IPv4 (0x0800), length 342: 192.168.30.1.67 > 192.168.30.16.68: BOOTP/DHCP, Reply, length 300

SOLVED Решено. Но вопросов осталось ещё больше: надо было пересобрать U-Boot с конфигом не для Cubieboard3, а для Cubieboard2, потому что тот конфиг взводит какие-то не те GPIO-пины, в результате чего из-за особенностей разводки платы сетевуха впадает в полуглухой режим работы. Это жепь-ебрилло и понять без бутылки это невозможно, но это работает.

Вот есть файлик /etc/network/interfaces. Это конфиг для бинарников ifup и ifdown.

1. Когда они запускаются? Как физически они видят, что у какого-то etnerhet появилась несущая и надо отработать? Какой процесс смотрит за этим?

2. Если у интерфейса написано auto, значит надо получить адрес по DHCP на него. А какой бинарник физически этим занят? dhclient? dhcpd? Кто его запускает? Его форкает ifup?

3. Какая сязь ifup/ifdown с NetworkManager? Почему NetworkManager не заменил собой всё?

Хочется почитать всё это до уровня физических основ «какой процесс порождает какой». Конечная цель - выпил NetworkManager из железки-одноплатника с целью упрощения работы с сетью до уровня почти-ручного запуска dhclient, wpa_supplicant и т.п. элементарных сервисов. Конечно, оформлено всё будет в пару каких-то своих systemd сервисов. Десктопа нет, DE нет, графики нет, переключение между разными сетями для разных юзеров (и всё то, для чего NetworkManager придумали) не нужно. Нужно только чтобы железка была максимально тупой и предсказуемой - получала себе на ethernet по DHCP адрес, если есть несущая (провод воткнули) и чтобы всё время стабильно коннектилась к wifi точке доступа с помощью wpa_supplicant и просила там себе на интерфейсе IP-адрес по DHCP так же. Плюс будет какой-то вотчдог, который пингует какую-нибудь фигню и через пять минут неуспешности начинает всех бить ногами, включая модуль ядра сетевого интерфейса.

Область применения: терминал продажи еды в торговом центре, куда очень бы не хотелось ездить и который бы был максимально тупым и надёжным в плане попыток «найти интернетик».

UPDATE Штош, господа, начитавшись западных интернетов, радостно снёс NM без последствий. Предварительно позаботившись о накатывании годного /etc/network/interfaces конфига.

После ребута DHCP-сеть на eth0 поднялась, по ssh смог зайти. Осталось разобраться с автоподьёмом всех этих wpa_supplicant-оперденей, потом наваять какой-то вотчдог переподнятий и убийств.

1. Есть 3…20 железок-одноплатников.
2. Грузят armbian с SD-карты, mount ro, чтобы флешку логами не портить.
3. На железках крутятся какие-то самописные на C++ бинарники или сервисы типа motion, которые грябят jpg с USB веб-камеры раз в секунду и пихают по сети на большого брата.
4. Всевозможны бинарники на железках оформлены как сервисы systemd. То есть, для администрирования железки, чтобы там запустить какой-то новый бинарник, мне надо закинуть каких-то бинарей в /root и что-то помутить в /etc/systemd/…, чтобы эти бинари запускало на старте. Для дебага, могу пойти по ssh на железку, позапускать руками.
5. Образы SD-карт могут быть различны только в области сетевых настроек: каждая железка работает в разной wi-fi сети или в разных 4G-сетях и всякие пароли и SSID-ы должны быть как-то прибиты. Эти настройки делаются очень редко так: ssh -> remount / rw -> make changes -> fsync -> reboot
6. Белых IP у железок нет, не будет, и не нужно. Это чисто клиенты в глубинах пользовательских домашних сетей. Ходить на железку по сети можно только приехав к клиенту с ноутом и воткнувшись в eth кабелем и такой сервис нужен крайне редко, обычно один раз при развёртывании.

В чём задача:

1. После старта железки вытягивать из сети с центрального сервера файл-архив с оверлеем корня, в котором (оверлее) лежат необходимые изменения базовово образа, содержащие нужные для этой железки бинари и сервисы. Монтировать этот оверлей на корень и переинициализировать systemd, чтобы он учёл изменения.

2. Железка ходит на центральный сервер по доменному имени и предъявляет свой токен, что позволяет центральному серверу понять кто пришёл и какой образ оверлея подсунуть. То есть, железка дергает center.ru/token/17237123879187239164

3. Железка раз в 10 секунд дёргает какой-нибудь управляющий URL, в котором ей могут сообщить, что надо ребут или стянуть новый образ.

Короче, не намутить ли такой велосипед руками с нуля? Может есть готовый проект на подобную тему?

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

Слышал, что microsd карты выдерживают максимум ~10-100 полных перезаписей и потом помирают. Хочется продлить жизнь microsd карты до нескольких лет, запретив запись. Аргументы в духе «16 гиговую карту брендовую фирменную можно найти за 150 руб, чё ты паришься, меняй их как перчатки, да и 16 ГБ 10 раз ты не перезапишешь за всю жизнь, грузя я неё линукс» я вроде понимаю, но во-первых вопрос чисто технически любопытен, во-вторых мы не знаем когда кукуха уедет у какого-нибудь сервиса, который решит насрать 10 гигов логов за сутки и поротировать. Если я воткну SD-карту с каким-нибудь armbian в одноплатник, то по дефолту на эту карту будет постоянно идти запись всяких логов, а мне эти логи нафиг не нужны. Может я захочу засетапить такую железку в точке, до которой 5 лет не захочу доехать и хотелось бы, чтобы карточка всё ещё работала.

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

1. Двинуть задвижку на SD карте в положение readonly? Это поможет? Этот железный флажок адекватно прокидывается на все уровни софта и ядро не посмеет замонтировать ничего с разрешением на запись? Этот способ вообще надёжен, или он просто передаёт системе информацию рекомендательного хатактера и рут может перемонтировать флешку на запись? Этот переключатель ведь просто пластиковая штука, которая внутри самой карты ничего не переключает, а просто триггерит контакт-кнопку-фотодиод в самом разьёме картридера…

2. Передать ядру какие-то опции?

3. Как-то завернуть все логи systemd в ram с ограниченным размером, мегабайт на 100, и автоудалением, чтобы за год работы девайса трубы не забивались и все файлы самоудалялись? Завернуть как-то весь /var/log в RAM и гори оно синим конём? Но это я избавлюсь только от одного подозреваемого, а мало ли какая сволочь решит ещё что-то там куда-то позаписывать - какие-нибудь конфиги в /home и т.п. Хочется отрубить запись надёжно, чтобы всякий пишущий просто терпел неудачу до особых распоряжений, так сказать.

4. В идеале губа не дура и хочется вот чего: на SD-карте - базовая система, которая обновляется крайне редко или никогда. После поднятия, система качает апдейты apt-пакетов в RAM, возможно даже качает ядро в RAM и перезагружается на скачанное в RAM ядро. Возможно без ядра. Тут можно что-то посоветовать? Памяти всего гиг, хотелось бы больше 100 мегабайт под такие задачи не тратить.

P.S.

1. Тест показал, что на «аппаратный» флажок на флешке корню пофиг - всё равно монтируется как rw.

2. Написал тут для корня «ro»:

$ cat /etc/fstab

UUID=bbad9182-bacd-9281-1171-a24c1c2ba44 / ext4 defaults,noatime,commit=600,errors=remount-ro,ro 0 1
tmpfs /tmp tmpfs defaults,nosuid 0 0

Перезагрузил. / стал ro. Наверное это годнота. В любой момент перемонтировать как rw никто не мешает. Куда systemd будет срать в этих условиях логами не представляю, надеюсь он не взорвётся.

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

возможно тред надо закрепить, ибо вопрос насущный и актуальности ещё лет 50 не потеряет

Интересно собрать перечень разных недооценённых и малоизвестных железок, которые можно находить на Авито по 300-1000 руб, имеющих на борту eth/wifi, 32-2048 MiB RAM, ARM/MIPS/другой проц и возможность запустить там linux (armbian допустим) в любом виде, желательно конечно свежайшее ядрище. С целью дёшево запускать простые приложения, скрипты, домашнюю автоматизацию и прочую хрень.

Примеры:

Атол HUB-19 - коробочка для алкоучета ЕГАИС, вроде вышла из обращения и её иногда скидывают на авито, внутри Cubieboard2 (Allwinner A20 + 1G ram + приятный корпус + wifi + eth + 6 USB портов) - цена 700 - 1000 руб на авито - по тестам жрёт 200-400 мА тока (простой/wi-fi передача). Может быть запитана от powerbank и долго работать в рюкзаке. Если повесить веб-камеру на руль, то можно через такой девайс, программы motion и телефона с LTE в кармане, куда коробочка смотрит по wi-fi, раз в секунду транслировать фотки своей поездки онлайн.

D-link DIR-620 - 200 руб на авито - (пример плохой, т.к. всем известный и за 200 руб можно найти девайсы и посолиднее) - роутер D-Link из категории «чуть получше, чем полное дно DIR-300» - 32-64M RAM, 8M ROM, минимом ресурсов, на котором работает не особо свежий, но и не сильно древний OpenWRT, что вполне себе полноценный линукс. Его можно цеплять как клиента к домашнему wifi и девайс заменяет raspberry для запуска простых скриптов или сложных, если на сишечке пейсать.

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

Всё время считалось, что в РФ слушать ты имеешь право всё, но выкладывать - только то, что «изначально было публичным». Например записи переговоров пилотов в авиадиапазоне - таких трансляций много. Переговоры охранников пятерочек через китайские баофенги рангуются по степени важности ещё меньше, чем пилоты. Выкладывать нешифрованных спецслужб - тоже «ничо не будет, но не сильно желательно» (знакомый два года вещал ГАИ - надоело и перестал платить за хостинг). Плохо - это уже выкладывать ментов (другой чел вещал год, но юридически пришла бумага, что он ничего не нарушил, хотя я это осуждаю морально - зачем помогать криминалу хоть на 1%), а совсем плохо - выкладывать расколотые криптухи - тут уже явно у тебя недобрый умысел: чуваки зашифровались, а ты их раскалываешь.

Правда ведь, что юридически к такому телеграм-каналу с LPD и PMR дампом всего происходящего невозможно прикопаться юридически?

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

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

По теме: http://live.radioscanner.pro/ - что народ транслирует (пока не пересажали на лесоповал).

Выкладыванию будут подлежать файлики вида: http://0x0.st/Hjrl.ogg

Старый срачь на похожую тему на «радиосканере»: http://www.radioscanner.ru/forum/topic25145.html

http://live.radioscanner.pro/audio/40797_1 - а тут чел транслирует каких-то городских служб, ездящих по каким-то вызовам и он до сих пор не на лесоповале!