标签：#qt

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Written with the help of AI (Claude). The bug, the fix, the validation setup, and every claim below are mine, and were verified against the real codebase and a real full disk. The report Someone lost a Magic: The Gathering decklist. They were playing on Cockatrice — the open-source MTG client — with their decks on a drive that had quietly filled up while Oracle pushed an update in the background. They added a card, hit Ctrl+S, and Cockatrice said it saved. The debug log agreed: [2026-05-28 22:31:42.031 I] Saved deck to "G:/cockatrice300/data/decks/edh-b2-gitrog-reanimate.cod" with format 1 - true - true . Success. The file was 0 bytes. The deck was gone. That was issue #6952 , filed by Mekkiss. The steps to reproduce are four lines long and completely damning: Have a full disk. Open a deck on the full disk Add one card to it Save the deck (ctrl+s) Observe that the deck is now a 0 byte file. Three ways to be wrong at once The save path lived in DeckLoader::saveToFile() . Stripped down, it looked like this: QFile file ( fileName ); if ( ! file . open ( QIODevice :: WriteOnly | QIODevice :: Text )) { qCWarning ( DeckLoaderLog ) << "Could not create or open file:" << fileName ; return std :: nullopt ; } bool success = false ; switch ( fmt ) { /* ... saveToFile_Native / saveToFile_Plain ... */ } file . flush (); file . close (); qCInfo ( DeckLoaderLog ) << "Saved deck to " << fileName << "with format" << fmt << "-" << success ; There are three independent failures stacked on top of each other here, and you need all three to lose data: 1. WriteOnly truncates on open. The instant open() succeeds, the existing deck is 0 bytes. Not after a successful write — at open time . The old deck is already destroyed before a single byte of the new one is written. On a full disk, open() still succeeds: truncating a file doesn't need free space. It frees space. 2. The serializers always returned true . sa

ThingsBoard is one of the most capable open-source IoT platforms out there. But the first time you try to get a device publishing telemetry over MQTT, the documentation sends you in three different directions of device profiles, transport configurations, topic formats, and credential types. There are a lot of setups before you see a single data point on a dashboard. This post cuts through that. By the end, you will have a device sending live sensor data to ThingsBoard over MQTT and seeing it in the Latest Telemetry tab. No fluff, just working code. What You Need Before Starting A running ThingsBoard instance, Community Edition, is fine. You can use the live demo for a quick look, though a local Docker setup is more reliable for following along since the demo instance has usage limits. You also need mosquitto-clients installed for quick command-line testing and Python 3 with paho-mqtt for the scripting part. # Install mosquitto client tools sudo apt install mosquitto-clients # Install Python MQTT client pip install paho-mqtt Step 1: Create a Device and Grab the Access Token In the ThingsBoard UI, go to Entities → Devices and click the + button to add a new device. Name it something like sensor-01. Once created, click on the device and copy the access token from the credentials tab. This token is your MQTT username. No password needed. ThingsBoard uses it to identify which device is sending data. Step 2: Send Your First Telemetry via Command Line Before writing any code, test the connection with mosquitto_pub. This tells you immediately whether the setup works. mosquitto_pub -d -q 1 \ -h "YOUR_THINGSBOARD_HOST" \ -p 1883 \ -t "v1/devices/me/telemetry" \ -u "YOUR_ACCESS_TOKEN" \ -m '{"temperature": 25.4, "humidity": 62}' If you are running ThingsBoard 3.5 or later, you can use the shorter topic format: mosquitto_pub -d -q 1 \ -h "YOUR_THINGSBOARD_HOST" \ -p 1883 \ -t "v2/t" \ -u "YOUR_ACCESS_TOKEN" \ -m '{"temperature": 25.4, "humidity": 62}' Both do the same thing. v2

mqttkit: Elysia-style application framework for MQTT An ordered middleware pipeline, typed topic routes, MQTT 5 RPC, and auto-generated AsyncAPI docs — sitting on top of any MQTT broker. If you've ever built a serious MQTT backend in Node, you've probably written this code at least once: client . on ( ' message ' , ( topic , payload ) => { if ( topic . startsWith ( ' devices/ ' ) && topic . endsWith ( ' /events ' )) { const uid = topic . split ( ' / ' )[ 1 ] // ad-hoc auth check // ad-hoc JSON.parse + validation // ad-hoc error handling // ad-hoc metrics // ... } else if ( topic . startsWith ( ' server/ ' )) { // ... } }) That's the MQTT equivalent of writing an HTTP server with http.createServer((req, res) => { if (req.url === '/users') ... }) . We solved that pattern for HTTP a decade ago with Express, Koa, Fastify, and more recently Hono and Elysia. For MQTT, we haven't. That's the gap mqttkit is filling. The design choice: don't reimplement the protocol There are already excellent MQTT brokers in the Node ecosystem — most notably Aedes , which handles CONNECT, SUBSCRIBE, PUBLISH, QoS, retain, sessions, persistence, and MQTT-over-WebSocket. EMQX and Mosquitto cover production scale. None of these need replacing. What's missing is the application layer — the part where you ask: How do I declaratively say "this topic requires this auth check"? How do I validate payloads with the same schema I already use for HTTP? How do I do MQTT 5 request/response without writing correlation-id bookkeeping? How do I get AsyncAPI docs for free? How do I attach Prometheus / OpenTelemetry without lifting broker internals? mqttkit is purely that layer. It plugs into Aedes via @mqttkit/aedes , but the broker is just an adapter — you can write your own for EMQX, NanoMQ, or any other broker. What the code looks like import { aedes } from ' @mqttkit/aedes ' import { MqttApp , router } from ' @mqttkit/core ' import { z } from ' zod ' const app = new MqttApp < { principal ?: { uid : string

QTRACTOR BIBLE Volume 1 — Foundations PART I — QTRACTOR CONCEPTS & WORKFLOW MODEL Chapter 1 — What Qtractor Is Quick Start Qtractor is a non-destructive, multi-track audio and MIDI sequencer designed primarily for Linux-based production environments. Unlike applications that attempt to integrate every aspect of the audio ecosystem into a single package, Qtractor focuses on recording, sequencing, editing, routing, mixing, and rendering while cooperating with external audio infrastructure and specialized tools. Qtractor is best understood as a timeline-centered production environment where audio clips, MIDI clips, plugins, automation, and routing configurations are organized into sessions. Common uses include: Music production MIDI composition Podcast production Voice recording Sound design Film scoring Hybrid hardware/software studios Live backing-track preparation Design Philosophy Qtractor follows several fundamental principles: Non-Destructive Editing Source media files remain unchanged. When a clip is trimmed, split, faded, moved, stretched, or processed, Qtractor modifies references and parameters rather than rewriting the original recording. Benefits include: Unlimited experimentation Reversible editing Reduced storage requirements Safer project management Session-Based Workflow Every operation belongs to a session. A session contains: Track definitions Clip placements Bus configurations Plugin assignments Automation data Routing information Tempo maps Markers Audio and MIDI source files remain separate from session instructions. Timeline-Centered Production The timeline is the primary workspace. Nearly every task ultimately relates to a position on the timeline: Recording Editing Automation Arrangement Export Qtractor is optimized for linear productions rather than clip-launching performance systems. Open Ecosystem Integration Qtractor assumes cooperation with: Audio servers MIDI systems External synthesizers External samplers Video playback tools Modular audi

There are more IoT protocols out there than most teams will ever need. That sounds overwhelming until you realize most connected products only use two or three; one for local communication, one for cloud connectivity, and sometimes one for device management. The problem is not the number of options. The problem is that the protocol you pick at the design stage gets baked into your firmware, your cloud pipeline, and your data model. Change it later and you are rewriting half of your stack. Here is a practical breakdown of the protocols that matter for most developers building connected products today. The Three Layers You Are Choosing Across IoT protocols sit in three distinct layers, and you typically pick one from each: Application Layer → MQTT, CoAP, HTTP, AMQP (how data reaches your cloud) Network Layer → LoRaWAN, NB-IoT, LTE-M, Wi-Fi, BLE (how data travels physically) Industrial Layer → Modbus, OPC UA, Profinet (machine-to-machine on the factory floor) A soil moisture sensor on a farm might use LoRaWAN at the network layer to push data 10 kilometers to a gateway and MQTT at the application layer to deliver that data to a cloud dashboard. Two protocols, two layers, one product. The Big Three for Cloud Connectivity MQTT - The Default for a Reason Publish-subscribe model. Lightweight. Three QoS levels for delivery guarantees. Run over TCP with TLS encryption. Roughly 70% of cloud-connected IoT deployments use MQTT today. A basic publish looks like this: import paho.mqtt.client as mqtt client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2) client.tls_set() client.connect("broker.example.com", 8883) client.publish("sensors/temperature", '{"value": 23.5, "unit": "C"}') Use when: You need real-time telemetry, bidirectional device control, or guaranteed message delivery across unreliable networks. HTTP - Not for Telemetry, But Still Essential Too heavy for continuous sensor data. But it is the standard for OTA firmware updates, cloud API integrations, and management das

Complete First-Time Setup Guide for Qtractor on Ubuntu 26.04 install and prepare the system verify audio works configure PipeWire/JACK configure Qtractor record audio record while playing other tracks export projects tune latency troubleshoot problems Qtractor is a lightweight Linux DAW (Digital Audio Workstation) for audio and MIDI recording. On Ubuntu, most problems come from: JACK / PipeWire / ALSA conflicts Permissions Wrong audio device selection Monitoring setup Sample-rate mismatches USB devices reconnecting Tracks not armed correctly This guide walks through a strategic / systematic / stable setup from zero, and covers the common failure cases along the way. PART 1 QUICK START SETUP 1. Understanding the Linux Audio Stack Modern Ubuntu audio typically works like this: Applications PipeWire JACK compatibility layer ALSA drivers Audio hardware For Qtractor, the recommended setup is: PipeWire enabled JACK compatibility enabled Qtractor using JACK mode through PipeWire 2. Install the Required Packages Install everything needed: sudo apt update sudo apt install \ qtractor \ pipewire \ pipewire-audio \ pipewire-pulse \ pipewire-jack \ wireplumber \ qpwgraph \ helvum \ pavucontrol \ alsa-utils \ jackd2 \ qjackctl \ ffmpeg Useful tools: Tool Purpose qtractor DAW qjackctl JACK control panel qpwgraph audio routing graph helvum simpler routing pavucontrol audio device management alsa-utils microphone troubleshooting 3. Reboot After installation: reboot This ensures all audio services start cleanly. 4. Verify the Audio System Is Running Check PipeWire: systemctl --user status pipewire Check WirePlumber: systemctl --user status wireplumber Check Pulse compatibility: systemctl --user status pipewire-pulse You should see: active (running) 5. Verify Audio Devices Exist Check Playback Devices aplay -l Check Recording Devices arecord -l Check PipeWire Audio Nodes wpctl status You should see sections like: Audio Devices Sinks Sources Typical onboard audio may appear as: Built-i