General Development Archive

It’s a bit of a silly post, because syntax is the least interesting d detail about the language, but, still, I can’t stop thinking how Zig gets this detail just right for the class of curly-braced languages, and, well, now you’ll have to think about that too. On the first glance, Zig looks almost exactly like Rust, because Zig borrows from Rust liberally. And I think that Rust has great syntax, considering all the semantics it needs to express (see “Rust’s Ugly Syntax”). But Zig improves on that, mostly by leveraging simpler language semantics, but also through some purely syntactical tasteful decisions. ↫ Alex Kladov Y’all know full well I know very little about programming, so there’s much interesting stuff I can add here. The only slightly related frame of reference I have is how some languages – as in, the ones we speak – have a pleasing grammar or spelling, and how even when you can’t actually speak a language, some of them intrinsically look attractive and pleasing when you see them in written form. I mean, you can’t look at Scottisch Gaelic and not notice it just looks pleasing: Dh’ éirich mi moch air mhaduinn an-dé‘S gun ghearr mi’n ear-thalmhainn do bhrìgh mo sgéilAn dùil gu ‘m faicinn fhéin rùn mo chléibhOch òin gu ‘m faca ‘s a cùl rium féin. ↫ Mo Shùil Ad Dhèidh by Donald MacNicol I have no idea if programmers can look at programming languages the same way, but I’ve often been told there’s more overlap between programming languages and regular language than many people think. As such, it wouldn’t surprise me if some programming languages look really pleasing to programmers, even if they can’t use them because they haven’t really learned them yet.

Claude Code has considerably changed my relationship to writing and maintaining code at scale. I still write code at the same level of quality, but I feel like I have a new freedom of expression which is hard to fully articulate. Claude Code has decoupled myself from writing every line of code, I still consider myself fully responsible for everything I ship to Puzzmo, but the ability to instantly create a whole scene instead of going line by line, word by word is incredibly powerful. ↫ Orta Therox Oh sweet Summer child. As a former translator, I can tell you that’s how it starts. As time goes on, your clients or your manager will demand more and more code from you. You will stop checking every line to meet the deadlines. Maybe you just stop checking the boilerplate at first, but it won’t stay that way. As pressure to be more “productive” mounts, you’ll start checking fewer and fewer lines. Before you know it, your client or manager will just give you entire autogenerated swaths of code, and your job will be to just go over it, making sure it kind of works. Before long, you realise there are fewer and fewer of you. Younger and less-skilled “developers” can quickly go over autogenerated code just as well as you do – but they’re way cheaper. You see the quality of the code you sign off on deteriorate rapidly, but you have no time, and not enough pay, to rewrite the autogenerated code. It works, kind of, and that will have to be enough. The autogenerated codebases you’re supposed to be checking and fixing are so large now, you’re no longer even really checking anything anymore. Quick, cursory glances, that’s all you have time for and can afford. Documentation and commenting code went out the window a long time ago, and every line of code scrolling across your screen is more tech debt you don’t care about, because it’s not your code anyway. And then it hits you. There’s no skill here. There’s no art here. You’re no longer a programmer. There’s no career prospects. Scrolling past shitty autogenerated code day in, day out, without the time or pay to wrangle it into something to be proud of, is the end of the line for you. Speak up about it, and you’ll be replaced by someone cheaper. The first time I was given a massive pile of autotranslated text to revise, without enough time and pay to ensure I was delivering a quality product, I quit and left the translation industry instantly. Like programming, translating is part skill, part art, and I didn’t get two university degrees in language and translation just to deliver barely passable trash. I took pride in my work, and I wasn’t going to let anyone put my name under a garbage product. Programmers, you’re next. Will you have the stones to stand by your art?

Did you know that in 2023, a single malicious email could trick an AI-powered personal assistant into spamming thousands of users from a victim’s inbox? This isn’t science fiction, it’s a real-world exploit from the OWASP Top 10 for LLM Applications, proving Large Language Models can be played like a fiddle if you skimp on security. Since 2022, LLMs powering chatbots, code generators, and virtual sidekicks are reshaping our daily grind. But here’s the kicker. Their meteoric rise made us almost completely forgetting about security. This guide hands you the keys to outsmart the biggest LLM security traps, straight from the OWASP Top 10, a battle-tested playbook forged by 500 AI experts. Understanding the OWASP Top 10 for LLM Applications The OWASP Top 10 for LLM Applications, updated in 2025, guides you through AI-specific security risks. Over 500 experts from AI firms, cloud providers, and universities identified 43 vulnerabilities, then narrowed them to the 10 most severe through voting and public review. This guide helps developers coding apps, data scientists training models, and security teams protecting systems. It addresses LLM-unique threats like prompt injection and unbounded consumption, overlooked by traditional security. With 70+ percent of organizations using LLMs in 2025, this list is your defense against attackers. Prompt Injection: Stop Hackers from Hijacking Your AI Prompt injection is the LLM equivalent of SQL injection. A manipulated input that alters the system’s behavior. Attackers can craft inputs that hijack the context of an AI conversation and trigger actions the developer never intended. Here’s an example: A resume contains hidden instructions that make the AI declare the candidate as “excellent.” When an HR bot summarizes it, the manipulation passes through unnoticed. Bad news is you can’t completely prevent it. It exploits the very nature of LLMs and how they work. You can however enforce strict privilege boundaries, introduce user confirmations for sensitive actions, and isolate external content from internal prompts. Basically, treat your LLM like an untrusted user. Insecure Output Handling: Don’t Let AI Outputs Run Wild LLMs don’t just respond in text, they can also write SQL, HTML, JavaScript. If that output flows unfiltered into a backend system or browser, you’ve got a serious vulnerability. For example, a user prompt leads an LLM to generate JavaScript that, when rendered, exfiltrates session tokens from the browser. To mitigate it, Sanitize all output. Use encoding techniques. Never allow LLM output to directly invoke privileged system calls or script execution. Apply zero-trust principles. Training Data Poisoning: Clean Your Data Because LLMs learn from vast datasets, poisoning can when attackers insert malicious, biased, or false data into these datasets during pre-training or fine-tuning. For example, a competitor floods public forums with biased content targeting a niche domain. That poisoned data gets scraped and used in model training, subtly altering the model’s behavior in the competitor’s favor. To combat this, vet your data sources, enforce sandboxing during data collection, and apply anomaly detection. Maintain a “Machine Learning Bill of Materials” (ML-BOM) to audit data provenance. Model Denial of Service: Prevent Overloads Hackers love overwhelming your LLM with complex inputs, spiking cloud bills or crashing systems. It’s a denial-of-service attack that hits your budget or uptime hard. Imagine recursive prompts grinding a chatbot to a halt, racking up $10,000 in cloud fees overnight. In 2025, 60% of LLM attacks exploit unchecked resource use. The solution is to set strict input size limits, throttle API requests, and monitor for anomalous usage. Cap resource usage per session or user to avoid runaway costs or exhaustion. Supply Chain Vulnerabilities: Secure Your Sources In traditional software, the supply chain refers to libraries and dependencies. In LLMs, it includes models, datasets, plugins, and infrastructure components, many of which come from third parties. An example would be if a plugin from an unverified source gets installed to extend chatbot functionality. Hidden in its dependencies is code that exfiltrates user queries to a remote server. The solution? Apply rigorous review to models, datasets, and plugins. Use signed components, vulnerability scanning, and SBOM tools. Audit vendor privacy policies, especially if they retrain on your users’ data. Sensitive Information Disclosure: Protect Secrets Your LLM might blab PII or trade secrets without a second thought which means one loose output can break privacy laws or spill your company’s playbook. In 2023, a prompt tricked an LLM into coughing up health records from training data, landing a firm in hot water. Don’t let your AI be a gossip. For example, user queries a model and receives PII (personally identifiable information) from another user’s past interaction, accidentally retained during training. The solution would be to sanitize training data, restrict what gets logged, and don’t feed sensitive information into models. Implement clear user policies and opt-out clauses. Fine-tune models with minimal privilege scope. Insecure Plugin Design: Tighten Plugin Security Sloppy plugins are like open windows for hackers, letting malicious inputs waltz in. They can swipe data or jack up privileges in a snap. A 2024 case saw a plugin eat unverified URLs, letting attackers inject code like it’s happy hour. A good example would be a weather plugin accepting a free-form URL. A malicious user redirects it to their own domain, planting instructions that manipulate the system or exfiltrate data. The solution is to test plugins with SAST/DAST tools to root out flaws. Slap on OAuth2 authentication to keep things legit. Restrict plugin permissions to the bare minimum. Don’t let your AI’s sidekick turn traitor. Lock down those plugins before they burn you. Excessive Agency: Control AI Actions Your LLM or plugins with too much freedom can act like rogue agents, making moves without oversight. Unchecked, they’ll delete data or approve sketchy deals. Here’s an example. A customer service bot has access to delete accounts. A hallucinated or malicious prompt causes it to wipe legitimate user records. Mitigation? Limit plugin capabilities. Use minimal permission scopes. Implement human-in-the-loop approval for destructive or financial operations. Build narrow, purpose-built tools—not generic ones that “do everything.” Apply least-privilege access to keep your AI on

Accessibility is something that doesn’t get nearly enough attention, especially considering because not only will we need accessibility features eventually as we grow older, but also because a lot of accessibility features are just helpful even if you don’t technically need them. Given these facts, it’s a shame that accessibility is usually an afterthought, doubly so on open source desktops, a problem we recently talked about. But what if you don’t just need to use a few applications as, say, a blind person, but also actually program as a blind person? Acidic Light, accessibility engineer at KDE e.V., has published a blog post about how screen readers actually work, and what it’s like to program while blind, and the conclusions are not exactly great. I truly feel that, based on my experience with KDE and my experience actually delving into the weeds with AccessKit in a custom UI system, that accessibility programming just isn’t accessible. Unless you happen to already understand the way each platform works, trying to find resources on how to actually let a screen reader know your UI exists is just painful. It’s going to involve reading code other people have already written. It’s going to involve hours, if not days, if not weeks of research and painful debugging. You likely won’t be able to ask many people for help, because they’ll know as much as you do. ↫ Acidic Light If the people who know most what is needed to make a program accessible have so many problems actually making programs accessible, because the tooling, documentation, and institutional knowledge just isn’t there, what hope do other programmers have to make their code accessible? If a blind programmer can’t scratch their own itch, so to speak, we’re never going to reach a point where accessibility becomes a given. I’m very happy awareness of accessibility is growing, but I feel like this isn’t the first time we’ve seen an increase in accessibility awareness only for it to eventually fizzle out without meaningful improvements for those that need it the most. I really hope it sticks this time.

The team that makes Cockpit, the popular server dashboard software, decided to see if they could improve their PR review processes by adding “AI” into the mix. They decided to test both sourcey.ai and GitHub Copilot PR reviews, and their conclusions are damning. About half of the AI reviews were noise, a quarter bikeshedding. The rest consisted of about 50% useful little hints and 50% outright wrong comments. Last week we reviewed all our experiences in the team and eventually decided to switch off sourcery.ai again. Instead, we will explicitly ask for Copilot reviews for PRs where the human deems it potentially useful. This outcome reflects my personal experience with using GitHub Copilot in vim for about 1.5 years – it’s a poisoned gift. Most often it just figured out the correct sequence of ), ], and } to close, or automatically generating debug print statements – for that “typing helper” work it was actually quite nice. But for anything more nontrivial, I found it took me more time to validate the code and fix the numerous big and subtle errors than it saved me. ↫ Martin Pitt “AI” companies and other proponents of “AI” keep telling us that these tools will save us time and makes things easier, but every time someone actually sits down and does the work of testing “AI” tools out in the field, the end results are almost always the same: they just don’t deliver the time savings and other advantages we’re being promised, and more often than not, they just create more work for people instead of less. Add in the financial costs of using and running these tools, as well as the energy they consume, and the conclusion is clear. When the lack of effectiveness of “AI” tools our in the real world is brought up, proponents inevitably resort to “yes it sucks now, but just you wait on the next version!” Then that next version comes, people test it out in the field again, and it’s still useless, and those same proponents again resort to “yes it sucks now, but just you wait on the next version!”, like a broken record. We’re several years into the hype, and that mythical “next version” still isn’t here. We’re several years into the “AI” hype, and I still have seen no evidence it’s not a dead end and a massive con.

This is a follow-up to the Samsung NX mini (M7MU) firmware reverse-engineering series. This part is about the proprietary LZSS compression used for the code sections in the firmware of Samsung NX mini, NX3000/NX3300 and Galaxy K Zoom. The post is documenting the step-by-step discovery process, in order to show how an unknown compression algorithm can be analyzed. The discovery process was supported by Igor Skochinsky and Tedd Sterr, and by writing the ideas out on encode.su. ↫ Georg Lukas It’s not weekend quite yet, but here’s some light reading ahead of time.

One thing I love about Python is how it comes with its very own built-in zen. In moments of tribulations, when I am wrestling with crooked code and tangled thoughts, I often find solace in its timeless wisdom. ↫ Susam Pal I can’t program and know nothing about Python, but this still made me laugh.

Software gets more complicated. All of this complexity is there for a reason. But what happened to specializing? When a house is being built, tons of people are involved: architects, civil engineers, plumbers, electricians, bricklayers, interior designers, roofers, surveyors, pavers, you name it. You don’t expect a single person, or even a whole single company, to be able to do all of those. ↫ Vitor M. de Sousa Pereira I’ve always found that software development gets a ton of special treatment and leeway in quality expectations, and this has allowed the kind of stuff the linked article is writing about to become the norm. Corporations can demand so much from developers and programmers to the point where expecting quality is wholly unreasonable, because there’s basically no consequences for delivering a shit product. Bugs, crashes, security issues, lack of documentation, horrid localisation – it’s all par for the course in software, yet we would not tolerate any of that in almost any other type of product. While I’m sure some of this can be attributed to developers themselves, most of it seems to stem from incompetent managers imposing impossible deadlines downwards and setting unrealistic expectations upwards – you know, kick down, lick up – creating a perfect storm of incompetence. We all know it, we all experience it every day, and we all hate it – but we’ve just accepted it. As consumers, as developers, as regulatory bodies. It’s too late to fix this now. Software development will forever exist as a sort of no man’s land of quality expectations, free from regulations, warranties, and consumer protections, and imposing them now after the fact is never going to be accepted by the industry and won’t ever make it through any lawmaking process of any country, and we all suffer from it, both as users of software and as makers of it.

Bjarne Stroustrup, creator of C++, has issued a call for the C++ community to defend the programming language, which has been shunned by cybersecurity agencies and technical experts in recent years for its memory safety shortcomings. C and C++ are built around manual memory management, which can result in memory safety errors, such as out of bounds reads and writes, though both languages can be written and combined with tools and libraries to help minimize that risk. These sorts of bugs, when they do crop up, represent the majority of vulnerabilities in large codebases. ↫ Thomas Claburn at The Register I mean, it makes sense to me that those responsible for new code to use programming languages that more or less remove the most common class of vulnerabilities. With memory-safe languages like Rust having been around for quite a while now, it’s almost wilful negligence to write new code where security is a priority in anything but such memory-safe languages. Of course, this doesn’t mean you delete any and all existing code – it just means you really need to start writing any new code in safer languages. After all, research shows that even when you only write new code in memory-safe languages, the reduction in vulnerabilities is massive. This reminds me a lot of those old videos of people responding to then-new laws mandating the use of seat belts in cars. A lot of people didn’t want to put them on, saying things to the tune of “I don’t need one because I’m a good driver”. Even if you are a good driver – which statistically you aren’t – everyone else on the road isn’t. When we see those old videos now, they feel quaint, archaic, and dumb – of course you wear a seat belt, you’d be an irresponsible idiot not to! – but only a few decades ago, those arguments made perfect sense to people. It won’t be long before the same will apply to people doggedly refusing to use memory-safe languages or libraries/extensions that introduce such safety to existing languages, and Bjarne Stroustrup seems to understand that. Are you really smarter than Bjarne Stroustrup?

I’m sure we can all have a calm, rational discussion about this, so here it goes: zlib-rs, the Rust re-implementation of the zlib library, is now faster than its C counterparts in both decompression and compression. We’ve released version 0.4.2 of zlib-rs, featuring a number of substantial performance improvements. We are now (to our knowledge) the fastest api-compatible zlib implementation for decompression, and beat the competition in the most important compression cases too. ↫ Folkert de Vries As someone who isn’t a programmer, looking at all the controversies and fallout around anything related to Rust is both fascinating and worrying. Fascinating because Rust clearly brings a whole slew of improvements over established and older languages, and worrying because the backlash from the establishment has been wildly irrational and bordering on the childish, complete with tamper tantrums and the taking of balls and going home. It shouldn’t surprise me that people get attached to programming languages the same way people get attached to operating systems, but surprisingly, it still does. If Rust not only provides certain valuable benefits like memory safety, but can also be used to create implementations that are faster than those created in, say, C, it’s really only going to be a matter of time before it simply becomes an untenable position to block Rust from, say, the Linux kernel. Progress has a tendency to find a way, especially the more substantial the benefits get, and as studies show, even only writing new code in memory-safe languages provides substantial benefits. In other words, more and more projects will simply switch over to Rust for new code where it makes sense, whether Rust haters want it or not. There will be enough non-Rust code to write and maintain, though, so I don’t think people will be out of a job any time soon because they refuse to learn Rust, but to me as an outsider, the Rust hate seems to grow more and more irrational by the day.

Now, if you have been following the development of EndBASIC, this is not surprising. The defining characteristic of the EndBASIC console is that it’s hybrid as the video shows. What’s newsworthy, however, is that the EndBASIC console can now run directly on a framebuffer exposed by the kernel. No X11 nor Wayland in the picture (pun intended). But how? The answer lies in NetBSD’s flexible wscons framework, and this article dives into what it takes to render graphics on a standard Unix system. I’ve found this exercise exciting because, in the old days, graphics were trivial (mode 13h, anyone?) and, for many years now, computers use framebuffer-backed textual consoles. The kernel is obviously rendering “graphics” by drawing individual letters; so why can’t you, a user of the system, do so too? ↫ Julio Merino This opens up a lot of interesting use cases and fun hacks for developers to implement in their CLI applications. All the code in the article is – as usual – way over my head, but will be trivial for quite a few of you. The mentioned EndBASIC project, created by the author, Julio Merino, is fascinating too: EndBASIC is an interpreter for a BASIC-like language and is inspired by Amstrad’s Locomotive BASIC 1.1 and Microsoft’s QuickBASIC 4.5. Like the former, EndBASIC intends to provide an interactive environment that seamlessly merges coding with immediate visual feedback. Like the latter, EndBASIC offers higher-level programming constructs and strong typing. EndBASIC’s primary goal is to offer a simplified and restricted DOS-like environment to learn the foundations of programming and computing, and focuses on features that quickly reward the learner. These include a built-in text editor, commands to manipulate the screen, commands to interact with shared files, and even commands to interact with the hardware of a Raspberry Pi. ↫ EndBASIC website Being able to run this on a machine without having to load either X or Wayland is a huge boon, and makes it accessible fast on quite a lot of hardware on which a full X or Wayland setup would be cumbersome or slow.

Hey there! In this book, we’re going to build a small operating system from scratch, step by step. You might get intimidated when you hear OS or kernel development, the basic functions of an OS (especially the kernel) are surprisingly simple. Even Linux, which is often cited as a huge open-source software, was only 8,413 lines in version 0.01. Today’s Linux kernel is overwhelmingly large, but it started with a tiny codebase, just like your hobby project. We’ll implement basic context switching, paging, user mode, a command-line shell, a disk device driver, and file read/write operations in C. Sounds like a lot, however, it’s only 1,000 lines of code! ↫ Seiya Nuta It’s exactly what it says on the tin.

Rejecting an engrained practice of bullshitting does not come easily. Frameworkism preaches that the way to improve user experiences is to adopt more (or different) tooling from the framework’s ecosystem. This provides adherents with something to do that looks plausibly like engineering, except it isn’t. It can even become a totalising commitment; solutions to user problems outside the framework’s expanded cinematic universe are unavailable to the frameworkist. Non-idiomatic patterns that unlock significant wins for users are bugs to be squashed. And without data or evidence to counterbalance bullshit artists’s assertions, who’s to say they’re wrong? Orthodoxy unmoored from measurements of user outcomes predictably spins into abstruse absurdities. Heresy, eventually, is perceived to carry heavy sanctions. It’s all nonsense. ↫ Alex Russell I’m not a developer, but any application that uses frameworks like React that I’ve ever used tend to be absolute trainwrecks when it comes to performance, usability, consistency, and platform integration. When someone claims to have an application available for a platform I use, but it’s using React or Electron or whatever, they’re lying in my eyes – what they really have is a website running in a window frame, which may or may not even be a native window frame. Developing using these tools indicates to me a lack of care, a lack of respect for the users of your product. I am militantly native. I’d rather use a less functional application than a Chrome web application cosplaying as a real application, and I will most likely not even consider using your service if all you have is a website-in-a-box. If you don’t respect me, I see no need to respect you. If you want an application on a specific platform, use that platform’s native tools and APIs to build it. Anything else tells me all I need to know about how much you truly care about the product you’re building.

This is the first post in what will hopefully become a series of posts about a virtual machine I’m developing as a hobby project called Bismuth. This post will touch on some of the design fundamentals and goals, with future posts going into more detail on each. But to explain how I got here I first have to tell you about Bismuth, the kernel. ↫ Eniko Fox It’s not every day the a developer of an awesome video game details a project they’re working on that also happens to be excellent material for OSNews. Eniko Fox, one of the developers of the recently released Kitsune Tails, has also been working on an operating system and virtual machine in her spare time, and has recently been detailing the experience in, well, more detail. This one here is the first article in the series, and a few days ago she published the second part about memory safety in the VM. The first article goes into the origins of the project, as well as the design goals for the virtual machine. It started out as an operating systems development side project, but once it was time to develop things like the MMU and virtual memory mapping, Fox started wondering if programs couldn’t simply run inside a virtual machine atop the kernel instead. This is how the actual Bismuth virtual machine was conceived. Fox wants the virtual machine to care about memory safety, and that’s what the second article goes into. Since the VM is written in C, which is anything but memory-safe, she’s opting for implementing a form of sandboxing – which also happens to be the point in the development story where my limited knowledge starts to fail me and things get a little too complicated for me. I can’t even internalise how links work in Markdown, after all (square or regular brackets first? Also Markdown sucks as a writing tool but that’s a story for another time). For those of you more capable than me – so basically most of you – Fox’ series is a great series to follow along as she further develops the Bismuth VM.