CIRCLE WITH A DOT

Three levels of AI in software development 🧠After my recent posts about vibecoding and devibecoding I want to zoom out a bit. I think there are three levels of using AI in software development — and they are really about risk.🟢 Level 1: passive AI usage. Autocomplete, code review, planning, answering coding questions, writing documentation. You stay in full control, AI just saves you time. Almost zero risk, immediate productivity gains.🟡 Level 2: vibecoding non-production code. Tests, internal tools, CI/CD scripts, prototypes. This is the sweet spot most teams underestimate. The upside is high but the blast radius is small — if a generated test is wrong it fails, if an internal tool has quirks nobody outside your team notices. Great place to learn what AI can and can't do. Level 3: vibecoding production code. This is where it gets real. By my definition from the earlier post: vibecoded code is code nobody on your team has fully understood. Shipping that to production is a conscious risk decision. The key insight: these aren't steps you walk through sequentially. It's a risk assessment. Level 1 and 2 are almost always worth it. Level 3 depends on your situation — a startup that needs an MVP in three months has a different equation than an enterprise with compliance requirements. And when level 3 code needs to grow up? That's where devibecoding comes in — turning code nobody fully grasps into code your team truly owns.Where does your team sit on this spectrum right now? #SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #RiskManagement

@radicalabacus Love the archaeology metaphor. And I think you nailed the core difference — legacy code has a story, vibecode doesn't. Digging through an old codebase you can always ask "why did they do this?" and find an answer. With vibecode that question leads nowhere.Which makes me wonder: is devibecoding even the right response in every case? Maybe your instinct is the pragmatic answer — treat vibecode as a disposable draft. Use it to understand the problem space, extract the spec, then write it properly from scratch.That might actually be the most efficient form of devibecoding — not saving the code but saving the knowledge.

@Blf_tpe Totally agree — the intent is real and the community should meet that with openness, not defense. The people coming in through vibecoding are potential long term contributors and supporters. Your mom donating to Debian is living proof of that.The YouTube tutorial idea is exactly right. The technical barrier to contributing is lower than ever thanks to AI. But nobody teaches you how to write a good commit message, how to read contributing guidelines, or when NOT to open a PR. That cultural onboarding is the real gap.Maybe that's actually a community project worth vibecoding — an interactive guide for first time open source contributors.

Generating cryptographically secure random values in C and C++ – what are your options?After writing about how secure random links work, a few people asked about the underlying libraries. So here is a quick overview. libsodium is the easiest and most recommended choice. One function call, cross-platform, and built specifically for cryptography:randombytes_buf(buffer, size);That is really all there is to it. libsodium picks the best available entropy source on the OS automatically. OpenSSL / LibreSSL is the classic option. RAND_bytes() does the job and is available almost everywhere. Worth using if you already have OpenSSL as a dependency – otherwise libsodium is cleaner.️ If you want no external dependency at all, go directly to the OS:Linux: getrandom() – available since kernel 3.17macOS / BSD: arc4random_buf() – even simpler, no error handling neededBoth are solid choices for system-level code.️ What about std::random_device in C++? It looks convenient but the standard does not guarantee cryptographic security. On some platforms it falls back to a predictable seed. Fine for games or simulations – not for security-critical code.So for anything security-related: libsodium or the OS primitives directly. std::random_device is a trap if you care about real randomness.What do you use in your projects for secure randomness? Still rolling your own or already on libsodium? #CPlusPlus #C #Security #Cryptography #libsodium #Infosec #SystemsProgramming

🫀 SO_KEEPALIVE — How your server detects dead connections before the client knowsA client connects to your server. Then their laptop lid closes. WiFi drops. Router reboots.The TCP connection is dead — but your server has no idea. It just sits there. Holding a socket. Waiting forever. This is called a half-open connection — one of TCP’s most silent failure modes. The fix — one line: setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &flag, sizeof(flag));The kernel now sends small probe packets on idle connections. No response after a few tries? Connection gets cleaned up automatically.️ Three knobs you control:→ tcp_keepalive_time — idle time before first probe (default: 2h )→ tcp_keepalive_intvl — time between probes (default: 75s)→ tcp_keepalive_probes — failures before giving up (default: 9)The defaults are hilariously conservative. For a real server you want minutes, not hours. Without it you risk:→ File descriptor leaks→ Thread pool exhaustion→ Memory piling up for connections that died hours ago Who needs it most:→ WebSockets & long-lived connections→ Servers behind NAT — routers silently drop idle mappings→ Any server where clients disappear without sending FIN Your server shouldn’t mourn connections that are already gone.#Linux #Networking #SystemsProgramming #ServerDevelopment

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually changed for the user?The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code. But here's where it gets tricky for B2B software: Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align. You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used. Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step. Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.So the question is: how do you build an outcome-oriented culture when the outcome is invisible to you? Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2B

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually *changed* for the user?The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code. But here's where it gets tricky for B2B software: Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align. You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used. Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step. Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.So the question is: **how do you build an outcome-oriented culture when the outcome is invisible to you?** Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2Bhttps://www.heise.de/hintergrund/Von-Output-zu-Outcome-Entwickler-als-Produktgestalter-11204293.html?seite=all

spdlog — Logging for C++ that actually gets out of your wayWhen you’re writing a Linux server in C++ close to the hardware, the last thing you want is a logging library that slows you down — at build time, at runtime, or when reading the code.That’s exactly where spdlog shines. Header-only — zero build ceremonyDrop the headers into your project, #include "spdlog/spdlog.h" and you’re done. No linking against extra libraries, no CMake gymnastics, no ABI headaches. For embedded systems or minimal server builds this alone is worth a lot.And because spdlog supports C++11 and up, it runs happily on older GCC toolchains — exactly the kind you find in Linux BSP environments and long-lived server codebases. Logging should be fast AND readablespdlog uses the {fmt} library under the hood, which means your log messages are formatted at compile time where possible. Instead of stringing together cout-style streams, you write:spdlog::info("Connection from {} on port {}", client_ip, port);Clean, readable, and significantly faster than printf or std::cout at runtime.🪣 The Sink System — one logger, many destinationsThe real power comes from sinks. A sink is simply a destination for log output — and you can attach as many as you want to a single logger.→ stdout_sink for live debugging in the terminal→ rotating_file_sink to write to disk with automatic file rotation→ syslog_sink to feed directly into the Linux system journalIn a hardware-near server this means you can log to syslog for production monitoring AND to a rotating file for post-mortem debugging — with a single log call in your code. No duplication, no extra logic. Log levels keep noise under controlspdlog supports the classic hierarchy — trace, debug, info, warn, error, critical. You set the minimum level per sink, so your rotating file might catch everything from debug upwards while syslog only sees warn and above. Perfect for production servers where log volume matters. For C++ server development on Linux, spdlog hits a rare sweet spot: trivial to integrate, fast enough for hot paths, and flexible enough for real production setups.#Cpp #Linux #SystemsProgramming #ServerDevelopment

@ammarfaizi2@gnuweeb.org @Suiseiseki@freesoftwareextremist.com @marcelschmall@infosec.exchange the retval from poll can help optimize the traversal as it indicates the number of ready file descriptors. I know it is still not as efficient as epoll, but if you find all ready fds earlier, you can break the iteration earlier too: ready_fds = poll(fds, 10000, -1); if (ready_fds < 0) { handle_error(ready_fds); return; } for (i = 0; i < 10000; i++) { if (ready_fds == 0) { // All ready fds have been handled. // Break out of the loop early to // avoid unnecessary iterations. break; } if (fds[i].revents & (POLLIN|POLLOUT)) { handle_events(i, fds[i]); ready_fds--; } } If you are lucky: that one client is not in the last index, you can break earlier.

The Prefork server model gets dismissed as “old school”. I think that’s wrong – especially on Linux.With SO_REUSEPORT, the kernel distributes incoming connections across multiple pre-forked worker processes natively. No thread contention. No shared memory complexity. Each worker is an isolated process – a crash stays contained.What you get:– True process isolation per connection– Kernel-level load balancing, no userspace overhead– Predictable memory footprint– Simpler security boundaries between workersIn a world obsessed with async event loops, we forget that prefork scales surprisingly well for workloads with high per-connection compute and where isolation actually matters – think security-sensitive services.SO_REUSEPORT didn’t just fix the thundering herd problem. It quietly gave prefork a second life.More on this soon.#linux #infosec #networking #serversecurity #prefork