Напомена унапред остаје иста: пројекат је пред-алфа, прво издање је само за VPS-ове са KVM-ом, а бројке мере код, тестове и одређене огледе, не зрелост у продукцији.

Како је то изгледало у времену

Од прошлог текста (31.10. у 23:00) до данас (1.11. у 20:41) у репозиторијуму је 59 нових commitова, укупно 178. Сви су настали у једном календарском дану, па важи иста опомена као раније: пројекат се гради уз Claude Code (commitови носе Co-Authored-By: Claude), план, код, тестови и ADR-ови настају у кратким затвореним петљама, а бројке испод говоре о количини кода и провера, не о томе колико је људског рада у њима.

Бројке су израчунате истом методом као у прошлом тексту: све .rs датотеке изван vendor/ и fuzz/, #[test] функције, наслови ## ADR- у docs/DECISIONS.md.

Радило се паралелно на више грана, па редослед commitова није стриктно редослед рада. ADR-ови су нумерисани до 232, али нумерација има празнина (део је преименован при спајању грана); бројимо наслове, не највећи број. Издања: v0.2.0 (1.11., 18:45 UTC) и v0.2.1 (1.11., 20:22 UTC), оба означена као pre-release.

H6: SQLite у корисничком режиму рада

Шта смо планирали. SQLite је 254 268 редова C-а који парсира базу, WAL и дневник са диска, а диск може бити направљен или измењен. Дотад је радио у језгру, са правима језгра. Шта смо изградили (ADR-210 до ADR-212): SQLite, његови libc делови и heap премештени су у засебан програм, dbworker, који ради на EL0 (aarch64) односно ring 3 (x86_64), у сопственом адресном простору. Језгро више не линкује SQLite. Радник са језгром разговара кроз заједнички прозор меморије и дванаест системских позива, а свака дужина и померај који се врате проверавају се пре употребе. Грешка у раднику (недопуштен приступ, недефинисана инструкција, прекорачен временски буџет од 30 s) завршава позив, радник се поново покреће и база се отвара из WAL-а као при подизању; након 5 поновних покретања у минуту похрана се проглашава неисправном, а не покреће се у недоглед.

Цена, измерена на aarch64 под HVF-ом, иста VM, језгро са уграђеним SQLite-ом наспрам језгра са радником, шест наизменичних покретања сваке:

Записи на диск (1 572) и flushеви (319) су идентични, како и мора бити. Није изоловано ово: језгро и даље верује ономе што радник врати, након провере облика. Компромитовани радник може да лаже (на пример да врати празну листу опозваних сертификата, а тиме их „одопозове”), али не може да чита меморију језгра, TLS кључеве ни кључеве тикета. Нема KPTI-ја, па цурења типа Spectre/Meltdown нису спречена и не тврдимо ништа о њима; PAC кључ деле EL0 и EL1. На x86_64 цену пребацивања нисмо измерили на KVM-у (под TCG-ом би број био бесмислен), а само фазирање радника и протокола није готово. Скуп тестова за похрану (79 сценарија, сваки врти SQLite у раднику) пролази на aarch64 HVF-у и x86_64 TCG-у, на aarch64 TCG-у 76 (један се прескаче јер TCG нема MSI-X).

H7 је затворен, али не онако како смо најавили. Доња граница времена (ADR-050) и SNTP са консензусом (T1) покривају обим H7; NTS (RFC 8915) остаје изван обима и записан је као преостали ризик, а не као нешто што ради. Не сматрамо да је безбедност времена „решена”, него да је њен доказиви део готов.

Нова мрежна опција. Contabo не даје DHCP прилагођеном ISO-у, па је VPS дотад тражио другу слику од лабораторијске VM. Сада network.mode = "auto" (ADR-214) прво пита DHCP, а ако закупа нема у задатом року (dhcp_timeout_s, подразумевано 15 s) или га изгуби, примењује подразумевану статичку адресу. Испробано ручно на QEMU-у (са DHCP-ом користи закуп, без мреже се након 5 s враћа на статичку адресу); smoke сценарија за то још нема.

X11: поређење са Mosquittom на истом VPS-у

Иста врста машине као у прошлом тексту (Contabo, 4 vCPU AMD EPYC, 8 GiB), оптерећење са Linux домаћина 15 ms даље, узајамни TLS 1.3 са истим сертификатима на обе стране, Mosquitto 2.0.21 на Debianu 13 без трајности. Метода и одлуке су у ADR-213, сирови подаци у docs/perf-results/. Медијан од три покретања.

Шта то значи, а шта не. Руковања су доње границе за оба сервера: генератор оптерећења је дељена VM са 60 до 70% украденог процесорског времена и при 128 нити био је близу сопственог ограничења, а urMQTT-ова радна језгра била су заузета само 12 до 13%. Однос при 128 клијената (око 2,2 пута) најсмисленији је; при 32 и 64 углавном мери чекање клијената. Бројке меморије не броје исто (хип језгра наспрам RSS-а процеса), па је „око 50 пута мање” ред величине, не прецизан однос. Латенција од 14 ms је један круг мреже (око 15 ms), дакле „нема мерљивог времена брокера”; репови (p99 око 100 до 200 ms) су код оба брокера доминирани дељеним домаћинима. Разлике испод око 20% не тврдимо.

Шта није ишло у нашу корист и остало је у табелама: један TCP ток кроз urMQTT носио је 2 до 8 пута мање него кроз Mosquitto, са променама од нуле до 7,7 хиљада порука у секунди међу покретањима, а 20 ms watchdog руковаоца прекидао је живе везе кад је хипервизор зауставио vCPU (у продукцијској поставци action = "drop", 6 до 8 веза по покретању при QoS 0 преплављивању). Обе ствари су описане у следећем одељку јер су имале узроке у нашем коду.

Зашто је један ток био спор: узроци, а не изговори

Најлакше би било рећи „дељени VPS”. Нисмо, него смо уз исти VPS и исту методу тражили узроке. Пронађено је пет узрока, четири у путу података и један у watchdogу (ADR-221 до ADR-224):

Заустављања су стварна: на овом VPS-у језгра 0 до 2 имала су медијан 36 до 80 закаснелих откуцаја по 5 секунди, а најгоре заустављање у прозору било је медијан око 70 ms и до 0,9 s (језгро 3, база и дневник: до 1,55 s), док домаћин не јавља украдено време (host steal 0 us). Зато је watchdogу требао други сат, не већи буџет.

Watchdog: 148 прекинутих веза у 30 оптерећених покретања пре, 0 у 24 покретања после; на локалној направи која одгађа и губи оквире, при губитку од 0,1% један ток од 64 B са 14,3k порука/s (језгро X11) сада има 41,0k, а при 0,5% са 5,0k на 17,7k.

Шта ово не каже. urMQTT и даље није бржи од Mosquitta на једном току: при 64 B објављује око 80% његове брзине, а испоручује око 40%, јер одбацује QoS 0 кад је ток претплатника спорији од издавачевог (Mosquitto без границе ставља у ред). При 1 KiB у 16-парном преплављивању Mosquitto је испред за око 15%, што је унутар шума. Генератор је поново био дељена VM са 58 до 77% украденог времена. Друга рунда (закључавање хипа изван пута података, SACK на страни слања и друго) је на неинтегрисаној грани perf-single-flow-wip; њене бројке још нису тврдње и овде их не наводимо.

Обећање које нисмо дали, али смо га испунили: конфигурација је податак

До сада је свака конфигурација била нова градња: кључеви и ограничења били су уграђени у слику. C1 то окреће (ADR-215 до ADR-219): језгро се гради једном, а конфигурација је податак.

• Блоб urmqtt-cfg (C1a): верзионисан, канонски запис (поља по растућим ознакама, SHA-256 отисак, необавезни одвојени Ed25519 потпис), 70 поља са подразумеваним вредностима и границама, декодер који одбија све неисправно.
• Језгро га чита као Limine модул (C1b), пре било чега другог, на aarch64 и x86_64. Постоји једно издато језгро за сваки ENV осим dev (aarch64 ELF-ови за release, prod и bench имају исти SHA-256; проверено само на aarch64). Издато језгро одбија развојну конфигурацију, а без конфигурације пише „refusing to serve” и не опслужује ништа.
• Инсталирани диск носи конфигурацију и ажурирање је задржава (C1c).
• urmqtt-config и шаблон ISO-а (C1d): pack, show, verify, а pack --iso замењује оба примерка места за конфигурацију и 24 сажетка модула у готовом ISO-у. Резултат је бајт за бајт исти као ISO који mkiso.sh --config гради. Шаблон издања v0.2.0 има 63 111 168 бајтова.
• Изјава о поверењу (ADR-219): конфигурисана слика при подизању исписује отисак конфигурације (config: fingerprint ...), а потпис је необавезан и искључен по подразумеваном. Измењени ISO нема службени сажетак; отисак је начин да се види шта је у њему.

Градитељ на aldo.tech

Исто што ради urmqtt-config pack --iso, ради и веб страница, истим кодом: библиотека алата преведена у WebAssembly (1,06 MB, без увоза и без unsafe блока). Страница је на aldo.tech/sr/proizvodi/urmqtt-builder/ и постоји на свих 15 језика сајта (на пример hr).

• Ништа не напушта прегледач. Сертификати, приватни кључеви и готов ISO остају на рачунару; страница скида само датотеке издања са овог сајта, нема праћења ни скрипти трећих страна. У тесту уживо ниједан захтев није носио кључни материјал.
• Огледало издања (ADR-227): сат по сат (systemd timer, ниског приоритета) копира издања са GitHuba, свако проверава пре објаве, а страница у прегледачу проверава потпис SHA256SUMS кључем уграђеним у страницу, па тек онда уписује конфигурацију у шаблон. Неуспела провера блокира преузимање.
• Једноставно по подразумеваном, напредно по потреби (ADR-232): први екран су три корака (где ради, ваши сертификати, име слике). Једно поље за превлачење датотека разврстава сертификат, кључ и CA по садржају. Напредни приказ отвара свако од 70 поља, претраживање, увоз и извоз TOML-а; оба приказа уређују исто стање. Шаблон (63 MB) скида се док корисник попуњава форму. У проби уживо, са пробним огледалом и пробним кључем, изградња ISO-а у прегледачу трајала је 5 до 18 s.

Емулатор, необавезно. Поред „Преузми ISO” стоји „Испробај у емулатору”: QEMU преведен у WebAssembly покреће управо изграђену слику у картици прегледача. Ништа од њега се не скида пре клика (око 3 MB први пут). Емулатор је BIOS-only, без мреже (да саобраћај корисника не би прошао кроз неког посредника и нарушио „ништа не напушта прегледач”), тражи око 1,5 GB меморије и рачунарски прегледач (тестиран Chrome; Firefox и Safari нису). У њему urMQTT стиже до URMQTT READY за око 8 s (са прескоченим одбројавањем) и исписује исти отисак конфигурације као страница, што је доказ да је подигнута управо та конфигурација. Подизање је око 2 пута спорије од изворног QEMU-а на истом Macu (0,82 s наспрам 1,9 s), а криптографија око 58 пута спорија јер су хардверске инструкције емулиране. Зато из емулатора не извлачимо никакве тврдње о брзини, а страница то каже пре покретања. При изградњи је требало закрпити четири бајта у .wasm-у због грешке у преводу инструкције POPCNT у изворном емулатору (још је нисмо пријавили); сам емулатор је под GPL-ом, уз понуду изворног кода.

Обичан MQTT, само за мреже којима верујете

Обичан MQTT (TCP 1883, без TLS-а) врло је чест у IoT-у: подразумеван је у Mosquittu, у већини firmwarea за Arduino и ESP, у Tasmoti, Zigbee2MQTT-у и Home Assistantu, а користи се и унутар сегментираних индустријских мрежа, иза VPN-а и на приватним LAN-овима, па и на уређајима без сата (сертификати траже датум), без довољно flasha или процесора за TLS. Преко непоуздане мреже није прихватљив: ко је на путу, чита и мења саобраћај. Зато је P1 (ADR-229 до ADR-231) изричит, ограничен избор, искључен по подразумеваном, а TLS порт остаје; TLS се овим не искључује, обичан порт долази уз њега.

• Списак дозвољених мрежа је обавезан (allow_from, CIDR-ови) и проверава се при SYN-у: изван списка нема SYN-ACK-а ни стања. Цео интернет (0.0.0.0/0) тражи засебну изричиту опцију.
• Три начина пријаве: лозинка (подразумевано кад је укључено; PBKDF2-HMAC-SHA-256, со, 10 000 итерација, поређење у сталном времену, закључавање по адреси), анонимно (један конфигурисан идентитет са сопственим ACL-ом) и по адреси (ip). Градитељ лозинку распршује у прегледачу и у меморији држи само сажетак.
• Мање права него mTLS: обичан клијент никад нема сервисна, оператерска ни управљачка права, нема $SYS ни конзоле, има сопствене сесије ($plain/<идентитет>/<id клијента>, само чисте), сопствена ограничења и регистар дозвољених га и даље обавезује.
• Шта се губи, пише у SECURITY.md: поверљивост, целовитост, аутентичност брокера и понављање снимљене пријаве. То се конфигурацијом не може поправити; тако је кад нема TLS-а.

Измерено на лаптопу (Apple silicon, HVF, QEMU корисничка мрежа), 16 парова, 64 B, три покретања од 10 s: при 8 000 порука у секунди TLS и обичан пут испоручују све поруке са истом латенцијом (p50 0,17 ms наспрам 0,13 до 0,18 ms), нове везе у секунди: TLS око 2 600 до 2 750, анонимни обичан око 4 900 до 7 800, а пријава лозинком је скупи део: један PBKDF2 стоји око 2,5 ms, па се број нових пријава ограничава на око 200 по језгру података у секунди (измерено 308 до 342 на два језгра). Преплављивање на тој машини није стабилан инструмент (20k до 440k испоручених у секунди међу покретањима) и из њега не извлачимо закључак. Поређење обичног пута са Mosquittom на VPS-у још није направљено. Тестови: smoke група plaintext 7 од 7 на aarch64 HVF-у и на x86_64 TCG-у, нови fuzz циљ plain_input (2,3 милиона покретања без налаза).

Грешке које је пронашао рад уживо

Две ствари нису ухватили тестови, него прво укључење на правом сајту:

• Страница је датотеке издања тражила један директоријум превисоко, па је свака провера потписа одговорила 404 (исправак 13af301). Тест је користио пробно огледало на другој путањи.
• Тастатура емулатора никад није стигла до госта: узрок није био лош превод тастера, него то што дијалог уопште није слушао тастере (исправак у ADR-232, уз унос за подизање без тастера).

Лекције

• Тражите узрок, не окривљујте окружење. Већина слабости једног тока и све прекинуте везе биле су наше; хипервизор је стваран, али га је требало мерити, не претпостављати.
• Поређење са другим производом мора укључити и губитке. Табела у којој су само наше победе не би била поређење.
• Мерни инструмент има границе. Дељени генератор са 60 до 70% украденог времена мења шта бројке значе; зато пишемо „доња граница” и не тврдимо разлике испод 20%.
• Изолација није доказ. SQLite у EL0 смањује шта грешка у њему може, не оно што може да лаже.
• Стварна инсталација налази оно што тестови не траже: путању која је погрешно сложена и тастере које нико не слуша.

Шта још није доказано

• Потписни кључ издања за сада је пробни кључ; v0.2.0 и v0.2.1 су pre-release, а слике уз њих развојне уз пробне сертификате (осим шаблона, који је без конфигурације).
• 13 превода странице градитеља (и овог текста) написао је AI и проверили су их тестови и узорци, не изворни говорници.
• Поређење са Mosquittom је једна сесија, један пут и један дељени генератор, на дељеном VPS-у; разлике испод 20% нису тврдње.
• Обичан пут није мерен на VPS-у ни против Mosquitta.
• Lighthouse на новом једноставном приказу није потврђен (стари приказ: приступачност 95 или више).
• Bare metal, x86_64 цена радника на KVM-у, Firefox и Safari за емулатор: није мерено.

Шта следи

• D1: јавни демо брокер. Емулатор из прегледача не можемо учинити јавним: живи у картици једног посетиоца, 20 до 100 пута је спорији од KVM-а, нема долазне мреже и нестаје са затварањем картице; преусмеравање интернета у туђи прегледач било би и злоупотреба. Могућ је прави демо брокер: urMQTT на VPS-у иза имена на aldo.tech, са објављеним пробним CA-ом, строгим ACL-ом и малим ограничењима. То је засад само идеја, не градња, и треба изричит пристанак за јавно излагање.
• Друга рунда за један ток (грана perf-single-flow-wip): тек кад је измерена на VPS-у и спојена.
• Обичан пут против Mosquitta на VPS-у, пријава и опозив налога за обичан MQTT преко потписаног управљачког канала.
• После издања: bare metal (X12 до X16), IOMMU и Secure Boot, шифровање диска.

Код је на github.com/zeljan-alduk/urMQTT, а docs/PROGRESS.md и даље је једини извор истине о томе шта стварно ради, docs/PERFORMANCE.md о томе шта је измерено. Пред-алфа, као и раније; пријаве грешака и безбедносне пријаве по упутама у SECURITY.md добродошле су.

Једна напомена унапред: пројекат је и даље пред-алфа. Бројке у тексту мере код и тестове, а не зрелост у продукцији, а прва објава је намерно ограничена на VPS-ове са KVM-ом. Bare metal остаје за касније.

Како је то изгледало у времену

Први commit настао је 28. октобра 2026. у 23:48 (M0). До 31. октобра у 23:00 у репозиторијуму је 119 commitова, распоређених као 3, 39, 38 и 39 по календарским данима. Одмах кажимо и како је то могуће: пројекат се гради уз Claude Code, а commitови носе Co-Authored-By: Claude trailere. Четири календарска дана историје не значе да је једна особа за четири дана написала 90 000 редова; значе да се план, имплементација, тестови и ADR-ови пишу у кратким, затвореним петљама, а сваки корак завршава истим ритуалом провере као и раније. Бројке испод говоре о количини кода и тестова, а не о томе колико је све то спроведено у стварном раду.

График показује три криве које расту готово заједно, што и јесте намера: тестови и записане одлуке прате код, а не касне за њим. Нагиб је најстрмији 29. октобра, када настаје цео пут од језгра до брокера. Даље се редови додају спорије, али тестови расту брже од кода (27 тестова на 1,6 хиљада редова на почетку, 739 на 89,8 хиљада данас).

Редови су све .rs датотеке изван vendor/ и fuzz/, а тестови су #[test] функције. Шта је који део додао, по датуму из git историје:

Обећање 1: један ISO за више платформи

Шта смо планирали. Једна датотека која се подиже на aarch64 UEFI-ју, x86_64 UEFI-ју и x86_64 BIOS-у. Шта смо изградили. Порт на x86_64 (X0 до X10) и универзални ISO са Limine bootloaderom, један хибридни ISO са ког се подижу све те комбинације; smoke тестови га подижу на четири виртуелне машине. Мени има три уноса: urMQTT (живи режим рада, ради из RAM-а, ништа не пише на диск), инсталација на диск машине на којој је покренут (инсталација пише GPT и податке, па гаси машину) и Дијагностика (детекција хардвера и мерења).

Прва стварна мета био је VPS, а не физички рачунар: одлука је да прво издање подржава само VPS (KVM), а bare metal долази после њега. Тестирали смо на Contabo VPS-у са AMD EPYC процесором (породица 23, Zen 1), 4 vCPU-а и 8 GiB RAM-а, са virtio-net мрежом и virtio-scsi диском. Први покушај нас је изненадио: ISO прикључен као виртуелни CD подизао је задати унос, продукцијска слика одбила је да служи са медијума само за читање и ресетовала се, па смо добили бесконачну петљу мени, језгро, ресет без иједне читљиве поруке. Данас фатална грешка у продукцијској слици оставља поруку на конзоли 60 секунди пре ресетовања, а са оптичког медијума исписује да је подигнуто са медијума само за читање и стаје. Живи режим рада у RAM-у (O3) касније је тај проблем заобишао за уобичајени случај.

Дијагностички унос настао је из тог искуства: машину коју не видимо морамо моћи да питамо шта има. Исписује CPU, RAM, мрежу, дискове и PCI уређаје, мери пропусност меморије, диск и криптографију, а иста мерења исписује као JSON на серијски порт. Записивање на диск дозвољено је само у нераспоређеном простору и тек након што се укуца WIPE; на снимку испод то је прескочено.

Шта је отворено. Прави хардвер. После првог издања следи bare metal (USB подизање, NVMe и AHCI, мрежна картица стварног рачунара), заједно са IOMMU-ом и Secure Bootом, јер без IOMMU-а злонамеран или неисправан уређај може писати по целој меморији. У овој верзији о томе не тврдимо ништа.

Руковање: од 1,2 ms до 0,24 ms

Прво мерење дијагностике на VPS-у дало је незгодну бројку: mTLS руковање, само криптографија на страни сервера, трајало је 1,2 ms. На aarch64 смо већ користили хардверске AES и SHA инструкције, али x86_64 није имао ништа слично за јавни кључ: RustCrypto је преносив и constant-time, па и спор. Три промене су то спустиле.

• За P-256 смо преузели nistz256 асемблер из OpenSSL-а и ring-а (ADR-130), уз табеле са фиксном базом за потписивање и проверу потписа CA (ADR-110, ADR-111).
• X25519 је преписан на четири 64-битна уда са MULX/ADX инструкцијама (ADR-131).
• Након тога смо профилисали и остатак (ADR-132, ADR-200).

Бројке се разликују по покретању око 10%, па смо записали распон уместо једне вредности. Укупно је то отприлике пет пута мање CPU времена за руковање.

Шта смо научили о memcpy-у. Кад је криптографија пала, профил је показао нешто што нисмо очекивали: функције mem* (memcpy, memmove, memset) трошиле су 7% руковања, 13 до 39% пута TLS записа (39% за 64 B, 13% за 4 KiB) и 17 до 34% разгранавања PUBLISH-а. Заменили смо их SSE2 асемблером за x86_64 (ADR-200), уз диференцијалне тестове према референтној имплементацији за све величине, поравнања и преклапања. По позиву је то 55 до 75 циклуса према 7 до 12 за 1 до 64 бајта.

Читање графика: што је запис мањи, то већи део времена одлази на копирање, па је и добитак већи. За мале поруке, које су већина MQTT саобраћаја, управо то је оно што се рачуна.

Шта ово не значи. На нативном x86_64 смо OpenSSL 3.5.5 (ADR-130) мерили само као референцу за асемблер, а не као поређење производа. Поређење Linux плус Mosquitto на истом VPS-у (задатак X11) још нисмо урадили. Зато не тврдимо да је urMQTT бржи од Linuxа: није измерено. Бројке изнад пореде urMQTT са самим собом.

Преоптерећење је био други резултат. На VPS-у, са једног Maca (RTT 35 ms), 128 клијената дало је 618 руковања у секунди, 256 клијената 393, а 512 клијената 67, уз хиљаде одбијених веза. То није био плато него урушавање. Узроке смо пронашли у коду (два су потврђена у QEMU-у/HVF-у, на VPS-у се нису могли поновити), више њих одједном: одбијена веза враћала је клијента преко следећег сегмента који носи важећи SYN колачић, одбијање је RST-ом говорило клијенту да одмах покуша поново, а пријем је био O(ред). Исправак (ADR-080 до ADR-082) испушта SYN који не би био прихваћен, памти одбијене токове, држи пријем у O(1) и броји руковања по језгру. Могуће је (хипотеза, није проверено) да је део узрока био и на клијенту: алат за оптерећење је затварао први, па је један Mac са 16 384 ефемерних портова и TIME_WAIT-ом од 30 секунди ограничен на око 550 веза у секунди. Зато прави строп сервера још нисмо измерили.

Обећање 2: сирови диск, али пажљив

Шта смо планирали. Задржати сопствени распоред без датотечног система и додати све оно што датотечни систем иначе даје: поравнање, раст, discard, сигурносне копије и провере. Зашто не датотечни систем. О томе смо расправљали и одлука је потврђена: urMQTT пише једну базу, један телеметријски дневник и сопствене метаподатке, не треба му директоријуми, дозволе, ни имена датотека, а сваки додатни слој био би још кода у поверљивом делу и још један начин да запис тихо нестане. Диск је GPT са ESP партицијом и једном urMQTT партицијом података, на којој је сопствени распоред.

Шта смо изградили (S2 до S6).

• Распоред v2 (S2). Топологија диска, поравнање на 1 MiB или оптималну величину I/O-а, цели физички блокови, A/B пар суперблокова са генерацијом (ADR-140). Распоред v1 кернел одбија уз јасну поруку, а мигрира га ванмрежни алат urmqtt-disk migrate (ADR-141): задато је пробни пролаз, копира се па тек онда пребацује, уз повраћај и убризгавање грешке на сваком запису.
• Раст (S3). При подизању диск може да порасте (никад се не смањује), а на virtio-blk и за време рада, преко прекида промене конфигурације (ADR-142, ADR-143).
• Discard и write-zeroes (S4). Танко додељени дискови враћају простор домаћину. У тесту је qcow2 датотека на домаћину пала са 62 на 16 MiB након што су истекли телеметријски сегменти, а опоравак никад не верује садржају који је одбачен.
• Сигурносна копија базе на диску (S5). A/B копија помоћу SQLite online backup API-ја у корацима по 16 страница: најдужи корак 4,6 ms наспрам 445 ms кад се копира у једном позиву. Комитови током копије имали су максимум 2,4 ms према 2,2 ms без ње. Ако quick_check при подизању не успе, база се враћа из копије.
• Чишћење и ограничено подизање (S6). Scrubber чита диск уз ограничен I/O буџет и пријављује оштећене записе, а подизање чита само најновији сегмент сваке партиције, тако да време подизања не расте са величином телеметријског региона. Тиме смо затворили проблем који смо унапред израчунали: на великом диску потпуни опоравак трајао би од минута до десетина минута.

Цела група smoke тестова за похрану пролази на обе архитектуре: 79 успешних, 0 неуспешних, на aarch64 под HVF-ом и на x86_64 под TCG-ом. Мерили смо и да S4 није успорио базу: 53,3 хиљаде уметања у секунди у пакетима пре и после, без измерљиве разлике.

Шта је изненадило. Колико од „једноставног” распореда отпада на рубне случајеве: virtio-scsi и virtio-blk пријављују топологију на различите начине, а непотпун запис у сред миграције мора увек оставити бар једну важећу верзију. Зато је сваки запис на путу миграције и раста прошао убризгавање грешке.

Шта је отворено. SQLite странице немају контролни збир, па промењен бит унутар вредности у реду база неће открити; телеметријски записи и садржај копија имају CRC и откривају се. Шифровање диска (S7) није готово.

Обећање 3: доказиво безбедно, колико год успемо

Ојачање (H4). Алокатор брише ослобођену меморију и проверава је при поновној употреби, открива двоструко ослобађање, веже показиваче слободне листе XOR-ом и нулира кључеве при ослобађању (ADR-170). Заштита стека (-Zstack-protector=strong, 1315 функција, а SQLite са -fstack-protector-strong, ADR-171). Извештаји о грешкама у продукцији не садрже регистре ни адресе (ADR-172). KASLR на обе архитектуре: кернел је PIE и Limine га помера за око 19 бита, а насумично се постављају heap, стекови и MMIO прозор (ADR-173). На aarch64 MTE означава heap (ADR-174), али само под TCG-ом: HVF и x86 га немају. kCFI смо проценили и нисмо га прихватили јер преводилац на прикаченом nightlyју пада са унутрашњом грешком; IOMMU је одгођен са bare metalом (ADR-175, ADR-176).

Цена је измерена, не претпостављена. На путу руковања (dp-bench, aarch64 HVF, пуна TLS 1.3 + mTLS + CONNECT руковања):

Свеукупно је дакле цена на путу руковања отприлике 5% за делове мерене чисто, а са PIE-јем и ознакама излази око 7% на једном и око 11% на четири језгра, али то је мерење шумовито. Сматрамо је прихватљивом, али нисмо је поновили на x86_64 VPS-у.

Вреди упоредити са бројком из првог текста (862 руковања у секунди на једном језгру). Исти алат данас, са погоном хардверског криптовања на aarch64 (X0b) и низом убрзања која су стигла од тада, даје 1941 пре ојачања. Нисмо изоловали допринос сваке промене, па о узроку не тврдимо ништа.

Како је проверено, и шта није. H5 је додао Miri на подскуп host crateова, Kani доказе, санитајзере, модел-фазер за ACL и извештаје о покривености. Kani је доказао record_len у TLS-у, parse у TCP-у и две аритметике точка тајмера. Није доказано (истекло време): оба MQTT декодера, оба парсирања конфигурације и понашање точка тајмера; CI посао за Kani зато још не блокира. Miri не може да извршава асемблер. Ланац набавке (H9): CycloneDX SBOM са 215 компоненти, cargo-vet пролази са 39 потпуно ревидираних и 140 изузетака, а cargo-deny је конфигурисан да савете о рањивостима третира као пад CI-ја (ти CI послови до сада су проверени само локално, не на GitHubу, а негативни тест није покренут), уз VULNERABILITY-HANDLING.md. Искрено стање: од 67 кернел-линкованих верзија трећих crateова, 53 су изузеци, а не ревизије. Vet доказује да се скуп зависности не може променити без видљиве разлике, а не да је TCB прегледан. Сопствену ревизију ни једног cratea нисмо написали.

SNTP (T1) је у том смислу мала прича о безбедности: опционалан је, само према приватним IPv4 серверима, са максималним скоком и условом да се извори слажу (медијан, већина унутар једне секунде). Сат који било ко на путу може померити није сат коме смемо веровати код важења сертификата.

На Macu: aarch64 изворно и x86_64 емулацијом

Развијамо на Macu, а тај има два начина за покретање истог кода и они су веома различити.

Правило је једноставно: бројке под TCG-ом су емулација и не цитирамо их као перформансе. x86 перформансе мерим само на правом VPS-у. Зато криптографске бројке изнад долазе са Contabo VPS-а, а не са Maca.

Лекције

• Мерите на стварној машини пре оптимизације. Први приступ био је оптимизовати оно што смо мислили да је споро; тек је дијагностика на VPS-у показала 1,2 ms и где тачно одлази време.
• Преоптерећење је засебна функција. Систем који је брз под оптерећењем може се урушити изнад њега; одбијање мора бити јефтиније од прихватања.
• Профил изненађује. Највећи појединачни добитак за мале поруке није био у криптографији него у копирању меморије.
• Диск без датотечног система тражи више посла, не мање. Оно што систем датотека иначе даје (поравнање, раст, discard, копије, провере) морамо написати и проверити сами, сваки корак са убризгавањем грешака.
• Искреност у бројкама. Меморијска мерења на дељеном VPS-у варирају до 10 пута међу покретањима и не говоре ништа о коду, па их не наводимо. Крипто бројке су стабилне до око 10%.
• Брзина развоја није зрелост. Тестови и ADR-ови расту уз код, али четири дана нису прави погон.

Шта следи

• H6: SQLite изолован на нивоу EL0, тако да грешка у бази не отвара језгро.
• H7: остатак безбедности времена (NTS и обрада скокова); SNTP је тек први корак.
• X11: поређење са Linuxом и Mosquittom на истом VPS-у, тек тада има смисла говорити о релативној брзини.
• Издање: прва јавна објава за VPS (KVM), уз потписане артефакте и упутства.
• После издања: bare metal (X12 до X16), IOMMU и Secure Boot, те шифровање диска.

Код је на github.com/zeljan-alduk/urMQTT, а docs/PROGRESS.md и даље је једини извор истине о томе шта стварно ради. Пред-алфа, као и раније; пријаве грешака и безбедносне пријаве по упутствима у SECURITY.md добродошле су.

Тако је настао urMQTT: уникернел који јесте MQTT брокер. Језгро, TCP/IP, TLS 1.3, MQTT и уграђена база података у једном Rust бинарном програму који се покреће са једног ISO-а. Нема процеса, нема системских позива, нема љуске. Прва платформа на којој се гради и тестира је aarch64, а исти код иде ка x86_64, преко UEFI-ја и класичног BIOS-а, и ка правом хардверу: циљ је један ISO који се подиже на свему томе. Пројекат је отвореног кода под лиценцом MIT или Apache 2.0, и у овом тексту желимо да забележимо докле смо стигли, како је изнутра сложен и шта смо успут научили.

Шта тачно значи „уникернел”

Уобичајени брокер је програм који ради на оперативном систему. urMQTT нема оперативни систем испод себе: сам се подиже кроз UEFI фирмвер и Limine bootloader, поставља сопствене табеле страница, програмира контролер прекида и тајмер, проналази virtio уређаје преко PCIe-а, добија адресу преко DHCP-а и слуша на једном порту. Све што би иначе радили језгро, управљачки програми, мрежни стек и апликација, овде је један ELF који ради на нивоу EL1.

Поређење са типичном инсталацијом говори само за себе:

Приоритети су, тим редом: безбедност, скалабилност, вишејезгарне перформансе, мали отисак и непроменљива инсталација. Кад год су два циља у сукобу, побеђује онај који је виши на тој листи.

Где смо сада

Пројекат је у пред-алфа фази, али је затворено седамнаест развојних прекретница, од M0 до M17. Данас urMQTT послужује MQTT 3.1.1 преко TLS-а 1.3 са обавезним клијентским сертификатима, а стање чува у SQLite-у на сировом диску. Укратко, шта већ ради:

• Језгро: сопствени вектори изузетака са декодираним извештајима, сопствене табеле страница са спроведеним W^X-ом, заштитне странице, PAC и BTI где их процесор има, GICv3 и GICv2, генерички тајмер, SMP до 64 језгра.
• Откривање хардвера из DTB-а или ACPI-ја у један опис платформе, са идентичним резултатом из оба извора.
• Управљачки програми: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi и virtio-rng, те CSPRNG засејан хардверском ентропијом.
• Мрежа: сопствени DHCPv4, ARP, ICMP и строги IPv4, па сопствени TCP само за серверску страну: SYN колачићи, хијерархијски точак тајмера, NewReno, спајање ACK-ова, без TIME_WAIT стања.
• TLS: само TLS 1.3, обавезни mTLS, идентитет уређаја из CN-а или SAN URI-ја; руковање ради rustls, а након њега сопствени слој записа са AES-128-GCM-ом и ChaCha20-Poly1305. Наставак сесије PSK улазницама, листа опозива, контрола пријема већ код руковања.
• MQTT: кодек без копирања, фазиран и тестиран са правим mosquitto клијентима; QoS 0 и 1, џокери, задржане поруке, опорука (LWT), трајне сесије, ACL са ограничењем на devices/{id}/#, ограничења брзине по уређају.
• Похрана: SQLite унутар језгра преко VFS-а над сировим диском, у WAL режиму, са провером интегритета при подизању; регистар уређаја, опозиви, задржане поруке, трајне сесије са редовима порука за уређаје који су offline; по језгру засебан телеметријски дневник са CRC-ом по запису и опоравком након пада.
• Погон и надзор: надзорни тајмер за обрађиваче, здравствена провера, ограничено логовање, syslog и statsd преко UDP-а, пријем који преживљава олује поновних повезивања.
• Испорука: битовно идентичне поновне изградње проверене у CI-ју, ISO и сирова GPT слика диска, minisign потписи, упутства за KVM, Proxmox и Hetzner.

Сваки корак је означен прекретницом која га је донела, а датотека docs/PROGRESS.md у репозиторијуму једини је извор истине о томе шта стварно ради.

Архитектура у три слике

Цео дизајн описан је у docs/ARCHITECTURE.md, а разлози за сваку важнију одлуку записани су као ADR-ови у docs/DECISIONS.md. Овде је преглед.

Слојеви

Од врха ка дну: брокер (сесије, стабло тема, QoS, задржане поруке, опоруке, ACL, ограничења), MQTT кодек, TLS, TCP, мрежни слој, па управљачки програми. Поред тог главног пута стоји похрана (SQLite и телеметријски дневник), а испод свега управљање меморијом, откривање платформе и конфигурација која је у време изградње преведена у константе, заједно са уграђеним CA сертификатом, серверским сертификатом и кључем. Хипервизор са virtio уређајима једино је што је изван слике.

Нит по језгру, без дељеног стања

Свако податковно језгро врти сопствену петљу са сопственим TCP стеком, TLS стањима, делом брокера (сесије и стабло тема), кеш меморијом heapа и партицијом телеметрије. Језгра не деле никакво променљиво стање, само ограничене прстенове без брава, по један за сваки уређени пар језгара. Највише језгро покреће SQLite и ништа друго.

Мрежна картица данас има један пар редова који држи језгро 0. Оно сваки MQTT ток према Toeplitz хешу његове четворке усмерава на једно од радних језгара и шаље оно што радна језгра врате. Сесија живи на свом домаћем језгру, одређеном хешом идентификатора клијента, па преузимање, опоруке и трајност никад не прелазе језгра. Веза која слети на друго језгро задржава тамо свој TCP и TLS, а обичан MQTT прослеђује домаћем језгру уз контролу тока заснованом на кредитима. Свака усмерена порука разгранава се и на остале делове брокера, од којих сваки држи реплику задржаних порука.

Три правила држе тај модел на окупу. Обрада до краја: примљени пакет обрађује се у целости на једном језгру, од TCP-а преко дешифровања TLS-а на месту, парсирања MQTT-а и усмеравања до шифрованог одговора, без редова задатака и без копирања у апликационе међуспремнике. Прилагодљиво испитивање: под оптерећењем се редови за пријем активно испитују, а у мировању се језгро враћа на прекиде и WFI; обрађивачи прекида само потврде прекид и означе посао. Надзорни тајмер: откуцај од 10 ms по језгру хвата обрађиваче који премаше свој буџет.

Живот једног PUBLISH-а

Уређај пошаље TLS запис. Мрежна картица га преда петљи језгра дескриптором, без копирања. Петља провери TCP, дешифрује TLS на месту и парсира MQTT из позајмљеног међуспремника, затим у меморији провери ACL, ограничење брзине и пут кроз стабло тема. Ако неко друго језгро занима та тема, добије поруку за усмеравање са референцом на садржај и идентификатором теме; база добије телеметријски запис или ажурирање задржане поруке, у пакету. Одговор PUBACK шифрује се директно у одлазни међуспремник и спаја са TCP ACK-ом, па уређају одлази један сегмент. Друго језгро порука кошта једно шифровање по претплатнику у тренутку слања.

Колико кошта једна веза

Циљ је највише 512 бајтова по неактивној TLS вези, са тежњом ка 256. Док веза мирује, ништа се за њу не држи у међуспремнику: примљени подаци обрађују се директно из мрежног оквира, а међуспремници за слање, записе и MQTT постоје само док је нешто недовршено или непотврђено. Језгро то и само мери: тачни бројачи heapа у траженим бајтовима и у блоковима које заузимају, записани сваких десет секунди као heap изнад основног нивоа по отвореној вези.

Измерено под HVF-ом са четири виртуелна језгра, од тога три радна, при чему сваки уређај држи mTLS везу и једну претплату са QoS 1, укључујући заокруживање алокатора:

Базен мрежних оквира фиксан је око 2 MiB, што је отприлике 200 B по вези при десет хиљада веза и око 2 B при милион. Више од тога нисмо могли да измеримо: QEMU-ово корисничко умрежавање на macOS-у престало је да прихвата везе на 10 197, отприлике на граници од 10 240 дескриптора QEMU процеса. Бројка пада како се фиксни делови распоређују на више веза, па не расте са њиховим бројем.

Безбедносни модел

Безбедност је први приоритет и добија све сукобе са осталим циљевима. Модел има неколико слојева:

• Један порт. TCP 8883, само TLS 1.3, обавезни клијентски сертификати потписани CA-ом уграђеним у слику. Идентификатор MQTT клијента мора бити једнак идентификатору уређаја из сертификата.
• Нема улаза. Нема љуске, конзолног уноса, SSH-а, администрацијског API-ја, динамичког кода, SQL-а доступног мрежом ни датотечног система.
• Меморијска безбедност. Rust, са forbid(unsafe_code) у протоколним пакетима; сваки unsafe блок има коментар // SAFETY: који проверава lint, а на спољни унос нема панике: clippy у пакетима на податковном путу забрањује unwrap, expect, индексирање и panic!.
• Ублажавање искоришћавања. W^X спроводи се кодирањем дескриптора и битом SCTLR_EL1.WXN и ревидира при сваком подизању. Табеле страница након подизања су само за читање, без уписивог алијаса. Доња половина адресног простора је искључена. Сваки стек има заштитне странице, а изузеци раде на засебном стеку. PAC и BTI укључују се кад их процесор подржава, и то проверавају димни тестови.
• Отпорност на злоупотребу. SYN колачићи; пријем одбија нове везе, пре икакве криптографије, кад је heap низак, кад база заостаје, кад је превише руковања у току по језгру или по изворној адреси или кад је брзина руковања превисока. Ограничења брзине по уређају, ограничени редови, TCP прозор везан уз противпритисак брокера, ограничено логовање, надзорни тајмер и здравствена провера.
• Непроменљивост. Конфигурација, CA и серверски кључ уграђени су у слику. Промена било чега значи нову слику.

Модел претњи записан је у docs/SECURITY.md.

Похрана без датотечног система

Подаци живе на засебном диску, virtio-blk или virtio-scsi, на којем нема датотечног система. Распоред је минималан и сопствен:

LBA 0      [ суперблок: магија · верзија распореда · uuid · табела региона · CRC-32C ]
LBA 8, 16  [ табела величина датотека, утори A/B (најновији важећи побеђује) ]
LBA 64     [ SQLite главна база ½ ][ SQLite WAL ⅛ ][ дневник 1 MiB ][ телеметријски дневник: 8 партиција … ]
задња 4 KiB [ простор за самопроверу блок-уређаја при подизању ]

SQLite (вендорисани 3.54.1, са провером сажетка при изградњи) преведен је у језгро clangом, без стандардне библиотеке, и користи фиксни memsys5 heap. Његов VFS пресликава три фиксне датотеке на регионе диска. Ради у WAL режиму са locking_mode=EXCLUSIVE, па му не треба индекс у дељеној меморији, и са synchronous=FULL; ако quick_check при подизању нађе грешку, систем се безбедно зауставља. У бази су регистар уређаја, опозиви, задржане поруке и трајне сесије са редовима QoS 1 порука за уређаје који нису повезани.

Језгро за базу, оно са највишим бројем, покреће SQLite и ништа друго. Податковна раван шаље му промене стања преко SPSC прстена без брава; оно их скупља у једну трансакцију сваких 5 ms или сваких 512 операција и потврде враћа другим прстеном. Празан диск форматира се при првом подизању; све друго се никад не форматира преко.

Телеметрија иде другим путем. Сваки прихваћени PUBLISH на темама из storage.telemetry_topics одлази у партицију телеметријског дневника свог језгра: прстен сегмената са CRC-ом по запису, посољеним секвенцом сегмента, тако да се стари пролази прстена никад не појаве поново. Језгра предају записе бази сопственим прстеном, без копирања, а она их исписује сваких 5 ms или сваких 256 KiB. При подизању опоравак задржава сваки исписани запис, одсеца недовршени реп и наставља у новом сегменту. Задржавање је по величини, кроз прстен, и по старости, кроз retention_days. Проверили смо то са милион записа и са kill -9 усред писања.

Бројке

Алат за оптерећење у tools/loadgen ради три ствари: олују TLS 1.3 руковања са mTLS-ом и CONNECT-ом, дуготрајне везе са PINGREQ-ом које сваке секунде објављују телеметрију, и олује поновног повезивања. make bench на Apple M4 Pro под HVF-ом даје:

Бројка у госту, где су клијент и сервер унутар исте виртуелне машине и свако радно језгро ради само за себе, показује да податковна раван скалира линеарно. Мрежна бројка ограничена је једнонитним корисничким умрежавањем QEMU-а, не гостом; и то је записано као ADR-032.

Олује поновног повезивања тестирамо тако да се сви уређаји повежу одједном, понављају одбијене покушаје са одгодом и онда сви падну без DISCONNECT-а. Параметар heap_limit_mb= у развојном режиму натера пријем да heap сматра мањим него што јесте, па се олуја већа од heapа може испробати са мало сокета. У једном таквом кругу од 3 000 уређаја повезало се 1 368 за 36 секунди, а 5 619 покушаја било је уредно одбијено, уз ограничење од 8 MiB; меморија се након олује вратила.

Како радимо

Пројекат води писана спецификација, PROMPT.md, са планом прекретница, и свака прекретница завршава истим ритуалом: make check и make smoke зелени, један commit са ознаком M<n>, запис у docs/PROGRESS.md и ADR за сваку одлуку која није очигледна. Правила су кратка и не преговарамо о њима: нема панике на спољни унос, unsafe само у хардверским и FFI пакетима и увек са коментаром, нема алокација на врућем путу, коментар уз сваки редослед атомских операција, свако ограничење долази из конфигурације, а намерни привремени делови падају гласно.

CI ради више него што бисмо ручно стигли: fmt, clippy за host и за aarch64-unknown-none, typos, actionlint и shellcheck; тестове на Linuxу и macOS-у на arm64; изградњу језгра за развојну и производну конфигурацију са величином ELF-а у сажетку; подизање под QEMU-ом са свим сценаријима димног теста и чување серијских записа; cargo-deny за савете, лиценце и изворе; минут фазинга по свакој од једанаест мета, а ноћу десет минута по мети са кешираним корпусом. Уз то CodeQL, OpenSSF Scorecard, Dependabot и објава са SLSA пореклом. Свака туђа акција закачена је на пуни commit SHA.

Репродуцибилност схватамо дословно: make repro изгради HEAD двапут у свежим радним стаблима и упореди ELF, ISO и сирову слику бајт по бајт. Објаве су потписане minisignом, а артефакти се могу проверити са gh attestation verify. Производна слика садржи приватни кључ сервера, па је сам ISO тајна; слике уз објаве на GitHubу развојне су, са привременим кључевима, и служе само за испробавање.

Шта смо научили

Неколико лекција које су промениле план:

• Сопствени TCP ипак се исплатио. Прототип је радио на smoltcp-у и добро нам је послужио до M13. Али сервер који држи стотине хиљада веза не треба клијентски TCP, треба SYN колачиће, точак тајмера и стање од 96 бајтова. У M14 смо smoltcp заменили сопственим стеком само за серверску страну, са тестовима симулираног губитка и фазингом сегмената.
• Мерите меморију изнутра. Процене по вези биле су бескорисне док језгро није само почело да броји heap у блоковима алокатора, а не у траженим бајтовима. Тек тада смо видели где 512 бајтова стварно одлази и спустили се на 494.
• Алат за тестирање је део производа. Највеће ограничење није било језгро, него QEMU-ово корисничко умрежавање и број ефемерних портова на развојном рачунару. За сто хиљада и више веза треба vmnet-shared на macOS-у или Linux са KVM-ом, tap интерфејсом и више клијентских адреса.
• SQLite без оперативног система је могућ, али само уз строге услове: фиксни heap, ексклузивно закључавање без дељене меморије, VFS који не зна за датотеке, и пријем који бази не дозвољава да заостане.
• Олује поновног повезивања су нормално стање, не изузетак. Кад падне мобилна мрежа и врати се, хиљаде уређаја куца истовремено. Зато пријем одбија везу пре икакве криптографије, а свака одбијена веза кошта готово ништа.

Шта следи

Рад после M17 планиран је у три смера, а редослед међу њима записан је у docs/PLAN.md. Ништа од овога још није изграђено.

• Један ISO за више платформи. Иста датотека urmqtt-<env>-<verzija>.iso и једна сирова GPT слика које се подижу на aarch64 UEFI-ју, x86_64 UEFI-ју и x86_64 BIOS-у, у виртуелним машинама и на правом хардверу, почев од једног Intel PC-а. И даље уређај са свиме унутра, репродуцибилан и потписан.
• Сирови диск, без датотечног система. Спецификација формата на нивоу бајта, host алат urmqtt-disk који дели парсере са језгром, поравнање региона на 1 MiB, раст диска са подацима, discard за танко додељене дискове, A/B снимци базе, провера битова и, по избору, шифровање AES-256-XTS са хардверским AES-ом.
• Доказиво безбедно. Опозив и листа дозвољених уређаја за време рада преко потписаног контролног канала, без нове слике; диференцијално и конформацијско тестирање сопственог TLS-а и TCP-а; KASLR, заштита стека, kCFI, MTE и ојачани алокатор; SQLite изолован на нивоу EL0; Secure Boot; SBOM и cargo-vet; и на крају пакет за спољну ревизију.

Платформе које нуде само не-virtio уређаје, попут AWS ENA-е или Azure MANA-е, засад нису подржане. Raspberry Pi 4 и 5 као KVM домаћин, Hetzner CAX и Oracle Ampere A1 документовани су и подржани кодом, али још нису испробани на правој услузи.

Испробајте

Репозиторијум је на github.com/zeljan-alduk/urMQTT. Уз Rust са прикаченим nightly ланцем алата и QEMU, make certs, make run и један mosquitto клијент довољни су за први PUBLISH преко mTLS-а на сопственом рачунару. Упозорење са почетка вреди и на крају: ово је пред-алфа, и све што ради пише у docs/PROGRESS.md. Пријаве грешака, питања о дизајну и безбедносне пријаве по упутствима у SECURITY.md су добродошли. О свакој следећој прекретници јавићемо се овде.

На овом блогу желимо да запишемо оно што смо на том путу научили. Не маркетиншке текстове, него конкретне белешке: шта је пошло наопако, како смо то решили и шта бисмо данас урадили другачије.

О чему ћемо писати

• Наплата у јавном превозу. Бесконтактне картице, SAM модули, рад без мреже и све што терминал мора да поднесе у возилу које се тресе дванаест сати дневно.
• Мобилне апликације на терену. Android и Flutter на уређајима који нису обични телефони: са читачима картица, штампачима и батеријама које морају да издрже целу смену.
• Бекенд и надзор флоте. Како знати да уређај у возилу има проблем пре него што га пријави возач.
• Хардвер. Од прототипа на столу до плочице која иде у серијску производњу, и све грешке између.
• Локални AI модели. Где модели на сопственом хардверу имају смисла, а где су облак и API једноставно бољи избор.

Како ћемо писати

Кратко и конкретно, с кодом и бројкама где их има. Објављиваћемо кад имамо шта да кажемо, а не по распореду. Текстове пишемо на хрватском и преводимо их на све језике сајта, а новости можете пратити и преко RSS-а.

Ако вас занима нека тема или радите на сличном проблему, јавите нам се на info@aldo.tech.