Computer Science and Programming

Mozilla is rolling out a major Firefox redesign codenamed Project Nova, focused on making the browser feel cleaner, warmer, and faster. Key changes include updated tab shapes with subtle gradients, a refreshed color palette inspired by fire, more rounded and consistent UI components, rebalanced spacing, and updated icons. Privacy features are being surfaced more prominently, including easier access to the built-in VPN, private browsing, and redesigned Settings with plainer language. Performance improvements include a 9% reduction in key page content load times. Productivity features like tab groups, split view, and vertical tabs are more accessible, and compact mode is returning by popular demand. The redesign extends to mobile for cross-device consistency, and new themes and wallpapers are being added. Accessibility — contrast, readability, keyboard behavior, and dark mode — is a core design consideration throughout.

Storybook 10.4 ships several notable features: AI agents can now automatically configure Storybook in complex apps by analyzing project structure, generating mocks, and writing stories; a new sidebar change detection filter highlights stories affected by recent code changes; a quick-share button publishes Storybook to Chromatic for instant teammate review without needing a PR or CI run. The release also adds first-class TanStack React framework support via @storybook/tanstack-react with zero-config routing and server functions, an improved opinionated React Native setup using a standalone entry point, and an experimental react-component-meta docgen analyzer powered by Volar and the TypeScript Language Server for faster, higher-quality MCP metadata.

But still, I did not expect a text editor to knock down my system like that. I still do not know exactly what happened. Maybe it was a Zed issue. Maybe it was a Linux graphics issue. Maybe it was related to the editor trying to index or analyze the project. Maybe it was some unlucky combination of my system, drivers, and the application. But from a user’s perspective, the result was simple: I clicked something in a text editor, my laptop froze, restarted, and then failed to boot normally. That is enough for me. Reliability beats speed After that experience, I uninstalled Zed. This is not a statement that Zed is a bad editor. Many developers clearly like it. Maybe on another machine, another OS, or another project, it works beautifully. But for me, the trust was gone. A developer tool can be experimental. It can have a different interface. It can require some learning. I am fine with that. But it cannot make me worry about whether my operating system will boot after using it. That is where I draw the line. The irony is that one of the arguments against VS Code is often that it uses Chromium. And yes, Chromium is not the lightest possible foundation. It may not be the fastest choice in every benchmark. But Chromium is battle-tested. It is used everywhere, on many systems, by many users, every day. It may have overhead, but it is reliable. And for my day-to-day work, I choose reliability over speed every time. A fast editor that I cannot trust is not faster in practice. What I learned This short experiment reminded me that developer tools are not only about speed. For me, a good editor needs to be: fast enough stable predictable easy to navigate comfortable with large codebases reliable when jumping through functions and files VS Code may not be perfect, and it may not be the most lightweight editor in the world, but it gives me a workflow I can trust. Zed may be faster in some benchmarks, and the Rust/native approach is interesting. But in my real-world test, it did not give me enough benefit to justify the friction. And after the system freeze, the decision was easy. Final thought Trying new tools is important. I installed Zed with genuine curiosity, not with the intention to criticize it. I wanted to see whether the hype around a fast, Rust-based, non-Chromium editor would translate into a better real-world workflow for me. It did not. But the bigger lesson for me was not only about Zed. This experience also made me question Ubuntu on my laptop. I am still a relatively new Linux user, but I have already experienced system crashes more often than I used to on Windows. That surprised me, because I expected Ubuntu to feel more stable and more secure. Maybe the issue was Zed. Maybe it was Ubuntu. Maybe it was a graphics driver, hardware compatibility, or some unlucky combination of all of them. I do not know yet. What I do know is that I do not want to judge the whole Linux experience from one installation. So I will probably create another partition, install another Linux distro, and make Zed one of the first applications I test there. Then I will see how it behaves in a different environment.

I installed Zed because it had been on my radar for a while. There is a lot of hype around it, especially around performance. Zed is supposed to be special because it is written in Rust and does not use Chromium. That sounds attractive, especially when compared with Electron-based editors like VS Code. In theory, it should mean lower overhead, better responsiveness, and a cleaner native experience. So when I came across a larger codebase that I wanted to skim through quickly, I thought this was the right moment to give Zed a try. I was not planning to replace VS Code immediately. I just wanted to test whether Zed could give me a noticeably better experience when browsing through unfamiliar code. After about 20 minutes, I uninstalled it.First impression: yes, it felt fast To be fair, Zed did feel quite fast. I was running my laptop in power saver mode, so I was not even using the full performance my machine could offer. Even then, the editor felt responsive enough. But I did not see any dramatic improvement compared to VS Code Studio. That was my first small disappointment. Not because Zed was slow, but because the performance difference was not big enough to justify the change in workflow. When a tool is promoted heavily around speed, I expect that speed to be obvious immediately. In my case, it was not.I struggled to orient myself The next issue was navigation. When I opened the project, I expected the file structure to be visible and immediately usable. In VS Code, I am used to seeing the project tree clearly, opening files quickly, and understanding where I am in the codebase. In Zed, individual files were not available to me right away in the way I expected. I had to scan the interface and search for where the files were. Eventually, I found a very small icon in the corner that revealed the file view. Maybe this is just a matter of getting used to Zed’s interface, but for me, that first moment matters. When I open a code editor, especially for a large codebase, I want orientation to be instant. I do not want to hunt for the file explorer. Jumping through code did not work Once I managed to open some files, I wanted to move through the codebase. In VS Code, I often use F12 to jump to a function definition. This is one of those basic developer features that becomes part of muscle memory. When you are exploring a large project, this matters a lot. In Zed, I right-clicked on a function and saw the option to go to definition. The menu even displayed F12 as the shortcut for that action. But it never worked. This was not a case where I expected a feature that was not visible. Zed itself showed me that the feature existed and that F12 was the right key to use. But when I tried it, nothing useful happened. Maybe it required additional configuration. Maybe the language server was not ready. Maybe something about the project was not detected correctly. But from my perspective, I installed the editor, opened a codebase, saw the correct command in the menu, pressed the shortcut Zed showed me, and it did not work At that point, the editor was already slowing me down instead of helping me. Then my computer froze After that, I started looking through the menus to understand what else was available. I noticed something that looked related to agentic or AI-assisted work. I clicked on one file, and at that moment my computer froze. Not just Zed. The whole computer froze. I am using Ubuntu 24.04, and the system stayed frozen for around two or three minutes. I could not do anything. Then the computer restarted itself. After the restart, Ubuntu did not boot properly. It started booting, but it never reached the password screen. I had to physically power off the laptop and turn it back on again. Only after that did Ubuntu finally boot. That shocked me. I am a relatively new Ubuntu and Linux user. Coming from Windows, I had assumed Linux would be more stable in this kind of situation. Maybe that assumption was too optimistic.

A veteran software engineer draws parallels between the Extreme Programming movement of the late 1990s and today's generative AI era, arguing that both represent 'rigor relocation' rather than loss of discipline. Just as XP replaced heavyweight processes with tighter feedback loops, and dynamic languages replaced static types with test-enforced correctness, AI-assisted development demands stricter specification of intent and ruthless evaluation of outputs. The core thesis: probabilistic code generation only works when deterministic constraints exist at the edges. Engineers who thrive will treat generation as a capability requiring more precision in specification, not less, and will build evaluation systems that fail loudly when code drifts from intent.

A practical guide on when to use CSS shorthand properties versus longhand equivalents. The core argument is that readability and intent should drive the decision, not brevity. Covers specific properties like background, padding, margin, animation, transition, grid, border, font, and text-decoration, with concrete examples showing when shorthand helps versus when it obscures meaning. Also introduces CSS logical properties as a more resilient alternative to directional shorthands for internationalization support.

A developer explains their migration from GitHub to a self-hosted Forgejo instance, driven by concerns about digital sovereignty rather than reliability. Key reasons include GitHub's absorption into Microsoft's CoreAI division (losing independent leadership), the April 2026 opt-out flip for Copilot training data, and unresolvable US jurisdictional risk under FISA 702 and the CLOUD Act. The post details the technical architecture: Forgejo v15 LTS on a single NUC with Postgres and Traefik, plus a hardened CI runner using KVM isolation, gVisor, weekly destructive rebuilds, nftables egress filtering, and scope-bound tokens. The Dutch government's choice of Forgejo for code.overheid.nl is cited as institutional validation. Honest trade-offs are covered: loss of GitHub's social graph, Actions ecosystem friction, no Dependabot (replaced by Renovate), and lack of enterprise support.

Microsoft has released the May 2026 servicing updates for .NET and .NET Framework, dated May 12, 2026. The update includes security and non-security fixes, addressing three CVEs (CVE-2026-35433, CVE-2026-32175, CVE-2026-42899). Updated versions include .NET 10.0.8, .NET 9.0.16, and .NET 8.0.27, with corresponding container images and Linux install instructions also refreshed.

A developer spent 7 months vibe-coding a GPU-aware Kubernetes TUI (k10s) with Claude, then archived it after the codebase collapsed under its own weight. The post dissects five concrete failure patterns that emerge from AI-assisted coding without architectural guardrails: AI builds features not architecture (leading to god objects), the god object as default AI artifact, velocity illusion causing scope creep, positional data as a time bomb, and AI mishandling state transitions causing data races. Each tenet includes real code examples from the failed codebase and specific CLAUDE.md/AGENTS.md directives to prevent the same mistakes. The author is rewriting from scratch in Rust, doing architecture design by hand before any AI-generated code.