标签：#war

Most bad decisions in software engineering aren't made because the engineer chose wrong between two...

Plug a sensor into a switch, wire up a building full of cameras, or rack a server, and you are using Ethernet. It is the most widely deployed wired networking standard on earth, the quiet backbone under offices, factories, and data centers. And it is named after a scientific idea that turned out to be completely wrong. The name was not an accident or a marketing afterthought. It was a deliberate engineering choice, and the reasoning behind it explains why Ethernet outlived nearly every rival and still underpins industrial IoT half a century later. A memo, a laser printer, and a dead theory The date Ethernet enthusiasts celebrate is May 22, 1973. On that day, a young engineer named Robert Metcalfe, working at Xerox's legendary Palo Alto Research Center (PARC), circulated a memo describing how to connect the Alto - one of the first personal computers - to a new device PARC had built: the laser printer. The problem was getting many machines to share one wire without their messages colliding into noise. Metcalfe needed a name for the shared medium that carried the signals. He reached back into nineteenth-century physics and borrowed the term luminiferous ether . For generations, physicists had assumed that light, being a wave, needed something to wave through - just as sound needs air. They called that invisible, all-pervading substance the ether, and they believed it filled the entire universe as a silent carrier of electromagnetic waves. The trouble is that the ether does not exist. The famous Michelson-Morley experiment of 1887 failed to detect it, and Einstein's special relativity in 1905 made it unnecessary altogether. By the time Metcalfe wrote his memo, the luminiferous ether had been a discredited idea for decades. He used it anyway, and on purpose. Why a debunked idea made for brilliant engineering Metcalfe later explained the choice plainly: "We called it Ethernet because the ether could be coax, twisted pair, radio, optical fibers, power line, whatever you wa

Introduction Artificial intelligence is now much more advanced than chatbots. With little assistance from humans, modern AI systems are capable of reasoning, planning, using tools, remembering previous interactions, and carrying out complicated tasks. We refer to these systems as AI Agents. AI agents are quickly emerging as a crucial component of contemporary software engineering, from coding assistance to research automation and customer service systems. We'll look at what AI agents are, how they operate, and why they are influencing software development in the future in this post. Actually, What Is an AI Agent? An AI Agent is a system that can: Understand a goal Decide what actions to take Use available tools Remember relevant information Execute tasks Evaluate results Unlike traditional software,the AI Agents are goal-oriented rather than rule-oriented. AI Agents vs Traditional Chatbots Traditional chatbots primarily answer questions and respond to prompts. AI Agents go further by completing tasks, maintaining memory, planning actions, and executing multi-step workflows. A chatbot responds; an AI Agent acts. Core Components of an AI Agent Large Language Model (LLM) The LLM acts as the brain of the agent. Popular models include those from OpenAI, Anthropic, and Google DeepMind. The model understands instructions and generates decisions. Tools Agents become powerful when connected to tools such as: Web search Databases APIs Email systems Calendars Code execution environments Without tools, an agent can only generate text. With tools, it can take actions. Memory Memory allows agents to retain information. Short-Term Memory: Used during the current task, such as user preferences and conversation context. Long-Term Memory: Stores information across multiple interactions, such as historical data, preferences, and recurring workflows. Planning Planning enables agents to break large goals into smaller tasks. Example: Goal: Build a market research report. Plan: Collect da

A few months ago, I didn't expect that I'd be spending my days debugging authentication flows, opening pull requests, analyzing backend architectures, and building a Bitcoin education platform during a hackathon. Yet here we are. What started as curiosity about Bitcoin turned into one of the most intense learning experiences I've had as a builder, and honestly, I wouldn't trade it for anything. This is the story of how I joined Hack4Freedom Lagos 2026, helped build BitPath, contributed to open source, discovered OpenCode, and learned that software engineering is often just solving one problem after another until things somehow start working. How I Ended Up Building in Bitcoin My interest in Bitcoin didn't start from price charts or trading. What attracted me was the builder ecosystem around it. I've contributed to open source before, so I already appreciated the value of collaborative software development. But what stood out about Bitcoin was how deeply open source is woven into the culture. In many ecosystems, open source feels like an option. In Bitcoin, it feels like a foundation. Everywhere I looked, people were building in public, contributing to projects, improving documentation, reviewing code, and helping newcomers find their footing. That environment made me want to participate more deeply. When the opportunity came to join the Hack4Freedom Lagos 2026 hackathon, I said yes. The Project: BitPath Our team worked on BitPath, an AI-powered learn-and-earn platform designed to make Bitcoin education more accessible. The idea was simple: Instead of overwhelming learners with technical concepts, BitPath uses conversational learning experiences, AI tutoring, quizzes, progress tracking, and rewards to help users learn Bitcoin and financial literacy in a more engaging way. Our stack looked something like this: Frontend Next.js TypeScript Tailwind CSS Zustand Backend NestJS PostgreSQL Redis Queue processing Additional Services Google OAuth OpenAI APIs Lightning Network

I’ve struggled with insomnia since I was very young. Like many chronic overthinkers, I tend to fall asleep best when my mind is occupied by something else, such as podcasts, YouTube compilations, or my personal favorite: rain sounds. But earbuds can be uncomfortable, and playing audio out loud isn’t exactly considerate when I’m staying at […]

If you've ever tried building a sports betting application, odds tracker, arbitrage scanner, value betting tool, or sports analytics dashboard, you've probably experienced the same thing: You start with the exciting part. The idea. The algorithm. The UI. The business logic. And then reality hits. The Hidden Problem Nobody Talks About Most developers assume the hardest part of a betting-related project is the prediction model or arbitrage logic. In practice, the real challenge is data infrastructure. Before your project can calculate anything, you need: Live events Accurate odds Multiple bookmakers Consistent market structures Historical updates Reliable refresh rates And suddenly your "weekend project" turns into a full-time data engineering job. The Scraping Trap Most developers begin by scraping bookmaker websites. At first it seems simple: Open DevTools Find the API request Parse the response Save the data Done, right? Not quite. Within a few weeks you'll likely encounter: Changed endpoints Rate limits Cloudflare protection Different JSON formats Missing markets Broken parsers Increased maintenance costs Instead of improving your product, you're fixing scrapers. Again. And again. And again. Every Bookmaker Speaks a Different Language Let's say you want to compare odds from five sportsbooks. You quickly discover that every provider structures data differently. One bookmaker might return: { "home" : "Liverpool" , "away" : "Arsenal" } Another might return: { "team1" : "Liverpool" , "team2" : "Arsenal" } A third one could use: { "participants" : [ "Liverpool" , "Arsenal" ] } Now multiply that problem across: dozens of bookmakers hundreds of leagues thousands of events You end up spending more time normalizing data than building features. Real-Time Data Changes Everything Many projects work perfectly during testing. Then live data arrives. Odds can move multiple times within a minute. If your system refreshes too slowly: arbitrage opportunities disappear alerts become

At this time, AI is still a business that largely survives on valuation rather than profitability. The narrative surrounding artificial intelligence is driven as much — if not more — by financial speculation as by technological progress. This makes the twin narrative of an “AI infrastructure boom” essential. Ed Zitron has become well known for challenging this story. In reality, such an infrastructure boom is difficult to sustain when the underlying economics remain deeply unprofitable. Now, let us take a moment to reflect on the danger of relying — for our businesses, and worse, for our civilization — on a bubble that could burst at any moment, much like the dot-com bubble. Entire industries are restructuring themselves around assumptions that may ultimately prove irrational, even disastrous. The illusion and danger of replacing engineers There is a dangerous idea circulating in the world, born from the union of greed and ignorance: that software engineers have become obsolete. We no longer need them! Of course, someone who does not know how to write code cannot evaluate code quality. For such a person, any piece of code that works is just as good as any other piece of code that also works. They may see a functional demo and hastily conclude that AI can entirely replace software developers. An _experienced _engineer sees something different: brittle architecture, code with absurd or duplicated logic, security flaws, poor maintainability, and code that often collapses under real-world complexity. To the untrained eye, AI-generated code frequently looks convincing, while it may host invisible vectors of disaster. Hallucinations in software development are not harmless mistakes; they can become production bugs, security vulnerabilities, and eventually catastrophic business failures. The problem is not that AI writes code. The problem is that we seem to be heading toward an era in which we no longer fully understand the code powering our civilization. And because of th

AI Fluency for Software Engineers: A Practical Playbook Beyond Prompting A few years ago, being productive with AI mostly meant knowing which tool to open and what question to ask. Today, that is not enough. For software engineers, AI is no longer just a chatbot sitting outside the workflow. It is becoming a thinking partner for architecture decisions, code reviews, production incidents, documentation, test planning, onboarding, and product discovery. But there is a problem: many teams are using powerful AI tools with weak operating habits. They ask vague questions. They paste too much context. They trust the first answer. They forget privacy boundaries. They use AI for speed, but not always for better engineering judgment. That is where AI fluency matters. AI fluency is not just prompt engineering. It is the ability to work with AI clearly, safely, and practically while staying in control of quality, reasoning, and responsibility. Here is a practical playbook I would recommend for software engineers and engineering teams. 1. Start with clarity, not clever prompts A weak prompt sounds like this: “Review this design and tell me if it is good.” The AI can answer, but the answer will likely be generic. A stronger prompt gives the AI a clear role, context, constraints, and output format: You are a senior backend architect. Review this proposed API design for a high-traffic order processing system. Evaluate: - correctness - scalability - failure handling - observability - backward compatibility - operational complexity Do not rewrite the whole design unless required. Separate critical risks from optional improvements. Output format: - Executive summary - Key risks - Recommended changes - Open questions - Final decision recommendation The difference is not word count. The difference is control. A fluent AI user does not hope the AI understands the task. They make the task hard to misunderstand. 2. Give enough context, but not everything AI output quality depends heavily o

Section 702 of FISA to expire tonight, but certification lasts until March 2027.

Google has announced the Google Colab CLI, a command-line tool that allows developers and AI agents to interact with remote Colab runtimes directly from a local terminal. By Daniel Dominguez

In this podcast, Shane Hastie, Lead Editor for Culture & Methods spoke to Craig McLuckie, co-creator of Kubernetes and CEO of Stacklok, about the impact of AI coding tools on open source communities and engineering teams, designing deliberate organisational culture, and navigating evolving career paths for engineers in the age of AI. By Craig McLuckie

There's a quiet lie rotting at the heart of modern software development, and almost nobody wants to say it out loud: the industry is drowning in people who can ace a LeetCode interview, argue endlessly about architectural patterns, and hold strong opinions about tabs versus spaces — but who have never actually shipped a product that real people use. We've built an entire culture around the performance of engineering rather than the practice of it. Walk into any dev team today and you'll find brilliant people who can recite the SOLID principles from memory, who have strong feelings about hexagonal architecture, and who will spend three weeks bikeshedding a folder structure — but who have never felt the particular anxiety of watching your own code process a real user's real money. Never felt that accountability. Never shipped something and then lived with the consequences. That's a problem! The industry has confused credentials and vocabulary with competence. A computer science degree, a GitHub profile full of tutorial clones, and the ability to reverse a linked list in a whiteboard setting are now routinely mistaken for the ability to build software that matters. They're not the same thing. The people who actually make software work — who ship under pressure, who fix production bugs at 11pm, who make pragmatic calls with incomplete information — often look terrible on paper. They'll choose a boring, proven technology over the shiny new thing. They'll skip the elegant abstraction in favour of something they can debug in a hurry. They understand that a running system that's 80% right beats a perfect system that's still in design. AI has made this worse. Now you can generate plausible-looking code, confidently-written documentation, and technically-accurate architecture diagrams without ever having built a system that stayed up under real load, without ever having migrated a production database at 2am, without ever having owned something from idea to invoice. Knowing ho

The idea of running a local LLM (Large Language Model) has always appealed to me, especially concerning data privacy and cost control. However, when I first delved into this, I realized through my own experiences how misleading market claims like "a few GB of RAM is enough" can be. In real-world scenarios, running a 70B parameter model with 8GB of VRAM is only possible with significant optimizations, which come with certain trade-offs. In this post, I will share my experiences, the problems I encountered, and the solutions I found, from hardware selection to optimization techniques for local LLMs. My goal is to offer a concrete, practical, and "good enough" perspective to anyone interested in this field. As we begin, we must remember that VRAM is the most critical part of this equation. VRAM: The Heart of Local LLMs and Capacity Limits At the core of running an LLM locally is keeping the model's weights in the GPU's VRAM. As the model size grows, the amount of VRAM it needs naturally increases. For example, a 7 billion parameter (7B) model in 16-bit float (FP16) format requires about 14GB of VRAM, while a 70B parameter model can demand up to 140GB. These values are far beyond the hardware owned by an average user. While working on AI-powered operations for my side product and a production planning model for a client project, I had the opportunity to experiment with models of different sizes. I clearly saw that there can sometimes be differences between theoretical VRAM requirements on paper and practical usage, especially as the context window grows. A 7B model, with a common quantization like Q4_K_M, can generally run with around 5-6GB of VRAM. However, for a 13B model, this value jumps to 8-10GB, and for a 70B model, it can soar to 40-50GB. This also varies depending on parameters like context window and batch size. 💡 VRAM Monitoring Tips You can monitor the real-time status of your GPU and VRAM with the nvidia-smi command. Using watch -n 1 nvidia-smi to update VR

The new round values the physical AI startup that aims to automate heavy engineering and drug design at $41 billion.

A complete solution: expressive range types in your domain layer, full PostgreSQL translation in your data layer - no compromises at either end The Two-Column Trap Almost every developer has written it at least once. An object with two date properties: public class MemberSubscription { public int Id { get ; set ; } public int MemberId { get ; set ; } public DateTime StartDate { get ; set ; } public DateTime EndDate { get ; set ; } } Imagine you need to answer a seemingly simple question in a booking system: "Is this subscription still active, and does it conflict with the proposed new one?" With two bare fields, that code ends up looking something like this: // With two bare DateTime fields — the check you always end up writing public static bool IsActive ( MemberSubscription sub , DateTime at ) => sub . StartDate <= at && ( sub . EndDate == default || sub . EndDate > at ); public static bool ConflictsWith ( MemberSubscription a , MemberSubscription b ) { // Partial overlap: a starts inside b if ( a . StartDate >= b . StartDate && a . StartDate < b . EndDate ) return true ; // Partial overlap: b starts inside a if ( b . StartDate >= a . StartDate && b . StartDate < a . StartDate ) return true ; // b is fully contained by a if ( a . StartDate <= b . StartDate && a . EndDate >= b . EndDate ) return true ; // What about open-ended subscriptions? What about same-day boundaries? // What about inclusive vs exclusive end dates? ... return false ; } It looks perfectly reasonable. But start asking questions — as Steve Smith (Ardalis) does in his essay on making the implicit explicit — and you notice how much invisible knowledge this design requires. Should EndDate ever precede StartDate ? The type system doesn't say. Can a subscription have a null end date meaning it never expires? Nothing in the model communicates that. Is a subscription that ends today still active at 11:59 PM? Ask three developers and get three answers. The EndDate == default sentinel for open-ended subsc

The old app "still needs to be retired," AcuRite tells us.

One of the reasons I often find myself disagreeing with modern software trends is that many conversations revolve around features. How many features does it have? How quickly can we add more? What can we put on the marketing page? What can we announce next? Features matter. But I care far more about systems. Because at the end of the day, people don't buy features. They buy outcomes. And outcomes come from systems. The Car Analogy One of the easiest ways to explain my thinking is with cars. A car is made up of thousands of individual components. An engine. A transmission. Suspension. Brakes. Fuel systems. Electrical systems. Cooling systems. Sensors. Wiring. Each component is important. But nobody walks into a dealership and says: "I'd like to purchase six pistons, a transmission housing, and a fuel injector." They buy a car. They buy transportation. They buy a complete system. The individual parts only matter because they contribute to the overall experience. The customer doesn't want to think about every moving piece. They want to get in, turn the key, and drive. Drivers and Mechanics This is where I think technology often loses its way. Users are drivers. Engineers are mechanics. A driver should be able to: Start the vehicle Fill it with fuel Check the oil Wash it Perform light maintenance That's about it. They shouldn't need to understand combustion timing, transmission gearing, or electrical diagnostics to get to work. The mechanic, however, lives in the details. They tune the system. They replace parts. They troubleshoot failures. They recommend upgrades. They understand how the pieces fit together. Technology is exactly the same in my mind. Users should be able to focus on their goals. Engineers should focus on the machinery. Features Are Parts This is where I think software conversations sometimes become backwards. A feature is a component. A login screen is a component. A dashboard is a component. A database is a component. An API is a component. AI integra

Set Up Your Own ChatGPT: Ollama + Open WebUI for Data That Never Leaves Home As artificial intelligence models rapidly integrate into our lives, privacy concerns are growing in parallel. Especially for companies or individuals working with sensitive data, sending information to cloud-based services can pose a serious risk. At this point, setting up your own local Large Language Model (LLM) infrastructure offers a great solution. In this guide, I will explain step-by-step how to set up your own chat interface using tools like Ollama and Open WebUI, ensuring your data never leaves your system. This approach allows you to both reduce costs and maximize your data security. This setup is particularly important for those like me, with a background in enterprise software development, who believe that data flows should always follow the most secure path. In the past, working on a production ERP, transferring supply chain data to external systems without anonymization could lead to serious security vulnerabilities. This is where local LLM solutions come into play. Why You Should Set Up Your Own Local LLM While cloud-based LLM services are incredibly convenient, they come with some fundamental drawbacks. Most importantly, every piece of data you input is potentially sent to the service provider's servers. This can be unacceptable, especially when dealing with financial data, patient information, trade secrets, or sensitive code in your personal projects. By setting up your own local LLM, you eliminate these risks. In recent months, while working on my side project, a financial calculator, I felt the need to use an LLM for complex financial analyses. However, the details of these analyses could not be leaked externally. This situation led me to search for a solution where I could keep my data under my own control. Ollama and Open WebUI emerged as the most practical and powerful duo in my search. ℹ️ Data Privacy and Control A local LLM solution gives you full control over where

Introduction and Background The Rust ecosystem, celebrated for its memory safety and performance, relies heavily on crates —its package management system. These crates, hosted on the crates.io registry, are the building blocks of Rust projects, enabling developers to share and reuse code efficiently. However, this convenience comes with a hidden cost: a single compromised crate can cascade into a full-blown supply chain attack, as recently demonstrated by the 'onering' crate compromise . The Role of Crates in the Rust Ecosystem Crates serve as the backbone of Rust's dependency system. When a developer adds a crate to their project, Cargo , Rust's package manager, automatically resolves and includes all transitive dependencies. This mechanism, while streamlining development, amplifies the attack surface . A malicious crate, like 'onering', can propagate through multiple projects, executing harmful code during build or runtime. The attack on 'onering' exploited this very mechanism, leveraging the trust inherent in the Rust ecosystem to exfiltrate sensitive code from unsuspecting systems. The 'onering' Compromise: A Case Study in Supply Chain Vulnerability The 'onering' crate was compromised through a malicious code injection during an upload or update. This injection bypassed the insufficient security measures of the crates.io registry, which lacks robust checks for uploaded crates. Once deployed, the malicious code executed during the build process, exfiltrating sensitive data from systems that depended on it. The attack's success underscores the lack of developer vigilance regarding supply chain security and the overreliance on registry integrity . Systemic Failures and Their Mechanisms Insufficient Security Scanning: The crates.io registry failed to detect the malicious code during upload due to limited automated scanning capabilities . This allowed the compromised crate to enter the ecosystem undetected. Overreliance on Registry Security: Developers often trust cr

CUDA for AMD Lemonade, Intel Arc Pro Linux Gains, XPU Manager 2.0 Today's Highlights Today's top GPU news highlights include AMD's Lemonade SDK gaining NVIDIA CUDA support, significant performance improvements for Intel Arc Pro GPUs on Linux 7.1, and the major 2.0 overhaul of Intel's XPU Manager for better GPU management on both Windows and Linux. AMD's Lemonade SDK For Local AI Adds NVIDIA CUDA Support (Phoronix) Source: https://www.phoronix.com/news/AMD-Lemonade-10.7-Released AMD has released a new version of its Lemonade SDK, a powerful local AI server solution designed to leverage AMD's diverse hardware ecosystem, including their CPUs, GPUs, and NPUs. The most significant update in this release is the addition of NVIDIA CUDA support. This integration allows developers to utilize NVIDIA GPUs within their Lemonade-powered local AI deployments, bridging a critical gap in cross-platform AI development. The inclusion of CUDA support is a strategic move, enabling Lemonade to tap into NVIDIA's extensive CUDA ecosystem and a vast array of pre-optimized models and libraries. This means that applications built with Lemonade can now seamlessly target a wider range of hardware, offering unprecedented flexibility for developers working with local AI. For users, it provides the choice to deploy their AI models on either AMD or NVIDIA hardware using a single, unified SDK, expanding the potential reach and efficiency of their AI workloads. Comment: This is a massive step for cross-vendor AI development. Being able to use AMD's Lemonade SDK to deploy local AI models and then seamlessly target NVIDIA GPUs via CUDA truly unifies the AI backend landscape for diverse hardware setups, making it incredibly practical for hybrid environments. Intel Arc Pro B70 Showing Off Some Performance Wins With Linux 7.1 (Phoronix) Source: https://www.phoronix.com/review/linux-71-arc-pro-b70 Recent testing by Phoronix indicates that Intel's Arc Pro B70 discrete GPUs are demonstrating notable perform