# Technikatsu
> Tech, minus the marketing fumes. Essays, fixes, and rants about the stuff you actually end up dealing with.
Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts.
Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`).
## Pages
### About
URL: https://technikatsu.com/about/
Last updated: 2025-10-31T12:40:24.000Z
**Who**  
I’m Arthur - a senior software developer, mentor, conference speaker and long-time observer of how technology actually works in practice. Over the years, I’ve worked across different areas of IT, from global enterprise systems to personal projects, and learned what makes tech both powerful and frustrating.

**What**  
Technikatsu is where I share what I’ve learned - the useful, the overlooked, and the occasionally broken parts of technology. You’ll find posts on software development, personal infrastructure, privacy, and the realities of working in tech - written without marketing fluff or empty buzzwords.

**Why**  
Because technology should serve people, not the other way around. My goal is to make complex ideas understandable, cut through trends that don’t matter, and offer a clear, honest perspective on what *does*. If that sounds like your kind of thing, welcome to Technikatsu.
## Posts
### Who Builds the Dark Factory?
URL: https://technikatsu.com/who-builds-the-dark-factory/
Last updated: 2026-09-06T18:13:39.000Z
I haven't properly written code since around New Year 2026\. I want to be precise about what I mean, because everybody says some version of this now and most of them are rounding up. I don't mean "I use autocomplete a lot." I don't mean "an agent writes the boring parts." I mean that the activity on my CV, the thing I get paid for, the thing I spent years getting good at, has left my calendar in 2026\. 

I still work on software systems all day. Architecture, infrastructure, business logic, integrations, failure modes, deployment, trade-offs, constraints, the eternal question of what the hell the thing is actually supposed to accomplish. I think about all of that constantly. 

I usually don't look at the code. Sometimes I review it. Sometimes I open a file because something feels wrong. Occasionally, heroically, I type three lines myself because explaining a trivial change to an agent would take longer than doing it. Those are the exceptions. The code has become something that exists underneath the level where I work, the way an architect can spend a whole day on a building without inspecting a single brick. 

And, hey, I'm not saying the machine is trustworthy. Not perfect. Not "give it production credentials, disable the guardrails, walk into the forest and never return" trustworthy. But it is good enough that manually implementing most conventional software has stopped feeling like the useful part of my job, and once that happens to you, you start asking the obvious question. 

Are software engineers still needed? 

For now, yes. Very much so. 

Remember "for now." We're coming back to "for now," and when we do, you're not going to enjoy it too much.

## The Code Was Never the Whole Job 

Here's the version of this story everyone tells, and I'm going to tell it too, because it's mostly true. 

Translating a ticket into Java, Python, TypeScript, Go, or whatever language was fashionable that year was always the cheap part. Anybody could learn it. The valuable part, the part that made a senior engineer worth three juniors, was the judgement wrapped around the code. What should we build? What should we absolutely not build? Where does this logic live? What happens when this dependency dies at 3 a.m., or when two requests arrive in the same millisecond? How do we migrate the old data? How do we ship this without ruining somebody's evening? Which assumption in the ticket is wrong? What part of the business process is nobody mentioning because everyone thinks it's obvious? What's going to balloon and become expensive in six months? What looks fancy af on a whiteboard and turns into operational nightmare in production? 

An experienced engineer carries an enormous pile of scar tissue around those questions. That's still valuable. Possibly more valuable than ever, because the machine can now produce a frankly unreasonable amount of the implementation around those decisions. The application code. The tests. The migration, the Dockerfile, the deployment config, the API contract, the documentation, and the slightly weird Bash script that glues the whole mess together. And when something fails, it reads the failure and tries again, without sighing. 

So "can the model write this function?" has become a boring question. Usually, yes. The interesting question is whether this is the right thing to build, in the right way, inside the actual environment it has to survive in. 

That still needs judgement. 

And that's the *Comfortable Answer*. AI writes the code. Engineers provide the judgement. Problem solved. Profession saved. Everybody gets a nicer title and goes home. 

I'm going to spend the rest of this post pulling on that thread until the sweater is gone. 

## The Implementation Layer Is Already Becoming Machinery

Software engineering is abstraction all the way down, and every layer of it was once somebody's whole job. Most developers don't think about individual CPU instructions. They don't manage registers. They have no idea, and don't want one, how the operating system schedules a thread. A database hides a mountain of complexity, a framework hides another, cloud infrastructure hides a third. We take things programmers used to do by hand and bury them under a layer of machinery, and then we forget we ever did them. 

Implementation is turning into one of those layers. For me it already has. 

When I need a feature now, I don't open the relevant class and pick which method to write first. I describe the outcome. I explain the constraints. I point an agent at the system. It inspects what's there, makes the changes, runs things, finds problems, fixes them. I step in when the reasoning needs steering, when context is missing, or when a decision has consequences beyond the immediate change. That's already a long way from programming. 

Then it gets weirder. After you do this for a while, reviewing every implementation detail starts to feel optional. 

Of course I can inspect everything the agent changed. Sometimes I should. Sometimes I absolutely must. But reading every generated line because a machine generated it doesn't scale.

The real requirement was never "a senior engineer read it." The real requirement is confidence, and confidence comes from more places than eyeballs. Tests. Type systems. Static analysis. Integration checks. Runtime constraints. Policy enforcement. Architecture validation. Independent review. Observability. Reproducible verification. Don't worry about the taxonomy. The point is that the moment you start thinking like this, the job mutates again. You stop using AI to write code and start designing the environment in which AI can safely produce it. 

And that's where it gets interesting. 

## The Dark Factory 

The name comes from manufacturing. A "lights-out factory" is one automated enough that no human needs to be on the floor. No workers, no reason to pay for lighting, hence the slightly cyberpunk name. This is not science fiction, by the way. FANUC has been running one near Mount Fuji since 2001\. Robots building robots. In the dark. For a quarter of a century. Nobody turns the lights on because there's nobody there to need them. 

Now apply that to software. 

Today, even with genuinely capable coding agents, the normal workflow is still interactive. You open Codex, Claude, Cursor, whatever you like. You give it a task. It works. You answer questions. You steer. It shows you what it did. You ask for changes. It tries again. This is dramatically more productive than typing everything yourself, and it is still, fundamentally, a human sitting at a machine pressing buttons. The dark-factory question is: what if we remove that part too? 

Instead of spending an hour babysitting an agent, you hand a system a bounded task and let it manage the work internally. Something like: 

task → analysis → planning → implementation → tests → review → repair → verification → result 

The exact arrangement doesn't matter much and will be obsolete by the time you read this (lol). One model doing several roles, or five. A strong model planning and cheaper models implementing. Separate reviewers. Deterministic tools doing half the validation. The implementation details keep changing as models get better and cheaper. 

The interesting property is the boundary. You say: build this. And eventually the system says: here is what I built, here is what I tested, here are the assumptions I made, here is the evidence it works, and here is what I could not verify. 

That isn't AI-assisted development anymore. That's autonomous software production, or something very close to it. 

And obviously the first reaction is: well then, software engineers really are cooked. 

Perhaps. But go try to build one of these things. I have. Here's where it gets stupid.

##  "Build Anything" Is a Terrible Specification 

The fantasy version of the software factory is universal. I'm going to call it the Build Anything Machine. You throw in a requirement and out comes working software. A mobile app. A banking backend. A game. A Kubernetes operator. A warehouse management system. Firmware. A React dashboard. A payment integration. A compiler. Whatever. Just feed the spec into the slot. 

I would love that. It would also solve several other minor problems along the way, such as general artificial intelligence ;) 

The closer I look at autonomous software production, the less I believe the Build Anything Machine is the interesting near-term target, and the reason is boring and enormous: software is too contextual. 

Picture two companies. Both use Java. Both use PostgreSQL. From orbit they're identical. Zoom in on the first one and it requires: 

- strict backwards compatibility
- schema migrations that run with zero downtime
- exhaustive audit logging; PCI-related controls
- deployment through one specific internal platform
- mandatory tracing
- certain libraries and certain authentication patterns
- a peculiar event-driven architecture somebody was once very proud of
- security review before any new dependency
- very specific retry semantics
- restrictions on where customer data is allowed to travel

The second company is an internal SaaS startup where the correct architectural decision is: put it in the existing service and ship it before lunch. 

Those are two different engineering environments. Different definition of good software. Different definition of done. Different risk appetite, tools, architecture, tolerance for complexity, business context. All of it different. An autonomous system has to operate inside all of that, and suddenly the hard problem is no longer getting the model to write code. It already writes plenty of code. The hard problem is building the world the code has to live in. 

## Maybe the Factory Should Be Local 

Which made me wonder whether we're chasing the wrong abstraction entirely. 

Maybe companies don't need one universal factory. Maybe they need their own: a factory shaped to their architecture, domain, tooling, risk profile and constraints. And maybe even one per company is too broad. Maybe you need several. 

Micro-factories. 

Yes. I am aware that our industry spent fifteen years turning everything into microservices, and I am now proposing we do the same thing to the developers. I apologise in advance. I'm still going to do it. 

Picture a backend-service factory. It knows the standard project structure. It knows which framework version is approved. It knows how authentication works, what the observability stack is, how services get deployed, what the migration conventions are, which internal libraries to use, how events are published, what the CI pipeline expects. And it knows that one particular internal service is cursed and must never, ever be called synchronously, no matter what its documentation claims. Give that factory a requirement and it has a constrained little world to operate in. 

Picture another one that only does Salesforce. It knows the company's objects. It knows the historical mess of custom fields. It knows the naming conventions and the deployment process and which workflows are business critical. And it knows which fields technically exist but must never, under any circumstances, be touched, because Gerald built something in 2019 and nobody, including Gerald, knows how it works. 

Remember Gerald. Gerald is the whole problem, and we're coming back to him. 

Another factory does frontend. Another data pipelines, another infrastructure, another integrations, another migrations, another testing. Make them as narrow as you like. A factory whose entire purpose in life is "safely migrate REST API clients from version N to N+1." Or "take an internal manual process and produce a CRUD app that follows company conventions." Or "build and verify connectors between our platform and approved third-party APIs." Or even "handle this one recurring category of support ticket." 

That sounds much less magical than "AI builds any software." It also sounds achievable. And, possibly, useful. 

And imagine building a factory, or some kind of AI-manager, capable of operating other factories? Yeah, maybe let's not go into *that* now...

## The Factory Is Mostly Constraints 

This is the part I find myself thinking about in the shower. 

The naive view of AI coding is that better models solve the problem. Smarter model, better software, go home. And that's partly true: a stronger model needs less supervision, understands bigger systems, makes fewer bizarre decisions, recovers from its own mistakes. Great. 

But the moment you try to pull the human out of the loop, intelligence stops being the only interesting variable. You need constraints. A shitload of constraints. 

What repositories can the system touch? What APIs can it call? What patterns are allowed, and what dependencies can it drag in? What environments can it reach? 

How does it know the implementation actually works? Which tests are mandatory? What counts as enough evidence to declare the task done? 

When should it abandon an approach? When should a second model review the work? When does it escalate to a human? Which assumptions must it write down?

How do you stop it from "fixing" unrelated things it happened to notice? How do you stop ten individually reasonable decisions from combining into one deeply unreasonable system? How do you give it enough context without dumping the company's entire accumulated digital landfill into a prompt? How do you tell whether the result is merely syntactically correct or actually appropriate for the business? 

These stop sounding like prompting problems within about four seconds. They sound like software architecture problems. Because they are. The factory itself is software. It has policies, interfaces, failure modes, observability, feedback loops, permissions, state, tooling, budgets, escalation paths, trust boundaries. Somebody has to design all of that. 

And, most importantly, somebody has to encode judgement. 

## Turning Tribal Knowledge Into Infrastructure 

Every software company is held together by knowledge that exists in no specification anywhere. Some of it lives in documentation. Some lives in code, some in architecture diagrams, some in Slack threads from a channel that was archived. A terrifying amount lives exclusively inside the heads of three people who have been there seven years, one of whom is Gerald. 

Experienced engineers swim through that environment without noticing the water. They know the documented API is technically correct and one particular endpoint falls over under load. They know the official database ownership boundaries, and they know the reporting job that violates them every night at 02:15\. They know a "simple" change will make finance furious. They know a customer integration depends on behaviour nobody ever intended to become public API. 

They know why the ugly code is ugly. Sometimes the ugliness is an accident. Sometimes it's a fossilised workaround holding the entire company together. Current coding agents cannot tell the difference, and if you let one "clean up" the second kind, you'll find out which kind it was at 4 a.m. on a Saturday. 

So building a useful autonomous factory is largely an exercise in extracting organisational knowledge and turning it into constraints a machine can actually use. Documentation is the weakest form of that. What you really want is tests, policies, examples, schemas, architecture rules, static analysis, tool permissions, evaluation suites, known failure cases, historical incidents, production telemetry, dependency maps, maybe even simulators. Things that let the system check its own output against the environment it has to live in, rather than against some abstract idea of good software. 

And all of that work is unmistakably software engineering. It just isn't the "write the application" kind. 

## The Engineer Moves Outside the Loop 

Follow the direction far enough and the engineer leaves the implementation loop entirely. The typing goes first. Then the need to inspect every implementation decision goes too. 

Instead of implementing features, you design the system that implements features. Instead of reviewing every line, you design verification that can reject a bad implementation on its own. Instead of explaining the company's architecture to an agent for the four hundredth time, you encode it into the environment. Instead of decomposing every ticket by hand, you design decomposition strategies. Instead of fixing the same class of model mistake over and over, you change the factory so that mistake becomes hard or impossible to make. 

The question shifts from "did the agent write this correctly?" to "what evidence would convince us that this entire class of change is correct?" 

That is a vastly more interesting question. It's also architecture, not programming. 

At some point the source code becomes one artifact among many that the process spits out, rather than the primary object a human manipulates. And honestly? I find that appealing. I don't miss typing implementation code. The interesting part was never the typing. It was deciding how the system should behave and figuring out how to make that behaviour reliable.

## This Has Happened Before 

Rewind. Not far by history's standards, seventy-odd years, to rooms full of people writing machine instructions by hand. 

Then assemblers took some of it. Then compilers. Then higher-level languages, libraries, frameworks, databases, operating systems, cloud platforms, managed services, infrastructure as code, platform engineering. Every generation removes a category of work that the previous generation considered the essential core of programming, and every generation's grumpiest members insisted it couldn't be done properly any other way and that "this new generation of programmers doesn't know shit".

Nobody building a billing platform today feels professionally threatened because they no longer allocate CPU registers by hand. The compiler does it. Told you it was coming back. We didn't lose the job; we moved the boundary of the job upward and forgot there was ever a boundary there. 

Maybe manually implementing application logic joins that pile. Not gone completely. Somebody will always need to go down a layer: performance problems, weird failures, security investigations, novel systems, infrastructure internals. Someone still needs to read assembly or hardware-level C. But needing a skill to exist somewhere in the industry is not the same thing as it being the daily activity of millions of engineers.

That distinction is going to matter a lot. 

## Unfortunately, This Does Not Mean Everyone Gets Promoted 

There's a comforting version of this story, and you've probably already told it to yourself. AI writes the code, therefore engineers ascend to become architects of AI development systems. Everyone keeps their job. Everyone gets a nicer title. We spend our afternoons drinking tea while autonomous agents close Jira tickets. 

I would not bet heavily on that. 

Abstraction increases leverage. That's the entire point of abstraction. If one experienced engineer can build and operate a set of reliable software factories with the implementation capacity that used to require ten engineers, the company does not automatically need ten factory engineers. Maybe it finds ten times more software to build. That can happen; demand for software is famously elastic, and there are countless internal tools, integrations, automations and weird niche products nobody builds today because the engineering cost doesn't justify them. When production gets dramatically cheaper we will absolutely build more things. 

But "we will find infinite additional software work for everyone" is an assumption, not a law. Productivity gains can and do reduce headcount. 

And some work is far more exposed than the rest. If your primary economic value is turning a detailed specification into conventional application code, the machines are getting alarmingly good at exactly that, and "I am senior, therefore AI cannot replace me" is not an escape hatch. Seniority is valuable because of judgement, context and responsibility. Those are harder to automate. Harder is not impossible. 

Now here's circularity. 

If the new engineering job is encoding judgement and context into autonomous factories, then the new job is, quite deliberately, taking the exact things that currently protect senior engineers from automation and teaching the machine how to do them. We are building the thing that makes us unnecessary and calling it a promotion. 

That doesn't mean the project is doomed. It means I'd be very careful about declaring any particular abstraction layer permanently safe. Including the one I'm standing on. 

## So Are Software Developers Cooked? 

Maybe. 

I find both extreme answers unconvincing. "AI is just another tool, nothing fundamentally changes" gets harder to say with a straight face every month, given what these systems can already do. "Software engineers disappear next year" ignores how much engineering happens outside implementation and how gloriously messy real organisations are. (See: *Gerald* from above.) 

My suspicion is that the profession changes unevenly. Code production gets dramatically cheaper. Direct implementation stops being the centre of the job. Human supervision moves upward. Small teams get ridiculous leverage. Some roles collapse into tooling; others turn into architecture. New work appears around orchestration, evaluation, domain modelling, platform constraints, organisational knowledge, and autonomous development systems. The ratios change. Maybe dramatically. 

And maybe what I'm describing, the software-factory engineer, is itself a temporary profession. Maybe in a few years the models build the factories. Maybe companies just buy them. Maybe vendors sell factories specialised for entire industries. Maybe the right architecture looks nothing like what I'm experimenting with today. Maybe "micro-factories" ends up sounding as dated as "SOA governance committee." 

*I have no idea*. That's partly why I find it so interesting. I'm not trying to predict the final shape of software engineering. I'm noticing that the question I personally wake up trying to answer has changed. 

## The Question Changed

 A few years ago the impressive question was: can AI write this code? Then: can AI implement this feature? For me even that one is boring now. I mostly assume it can. 

The question I'm asking now is: can I construct a system where AI implements this whole class of software, repeatedly, without me in the room? 

Not one task. Not one carefully supervised session. A process. Bounded enough to trust. Specialised enough to understand its own environment. Capable of planning, implementing, checking, correcting, and eventually either handing back a verified result or admitting exactly where it got stuck. 

That's a much bigger shift than a better coding assistant. The code becomes an intermediate artifact. The engineering moves into the environment around its production. And if that continues, the important skill becomes designing the machinery that produces software safely, repeatedly and in the right direction. Writing the software itself slides down a layer, next to the registers. 

I don't know if those machines will be universal. I suspect not, for a while. Maybe every company gets one. Maybe every engineering org. Maybe a company ends up with dozens of tiny specialised factories, each welded to one narrow slice of the business. 

Microservices for code production. God help us. 

But if software engineers really are being squeezed out of the act of writing software, there is still one job left that needs doing. Someone has to build the factory. 

For now, anyway.

Maybe engineers who build those dark factories will be the ones turning the lights out as they leave for the last time.
### I Thought I Was Overusing AI. Then I Changed Jobs.
URL: https://technikatsu.com/i-thought-i-was-overusing-ai-then-i-changed-jobs/
Last updated: 2026-09-01T20:52:09.000Z
I recently started a new job as an Applied AI Engineer. Going in, I thought I knew quite a lot about AI. I use it constantly. I've built things with it, abused coding agents, experimented with local models, inference APIs, automation, weird workflows, all the usual nerd nonsense.

Turns out I was just in the wrong bubble. Not wrong, exactly. Just more conservative bubble than I realized.

I already treated AI as something extremely capable. I was never in the "fancy autocomplete" camp (or was very briefly), and I was already wrapping increasingly complex systems around my own work: context, tools, memory, workflows, verification, automation. Let the machine handle more of the mechanical thinking while I keep steering the thing.

I still think that direction was right. What I got wrong was the *scale*.

## "Is This Worth Spending Money On?"

My personal AI usage has always had an invisible constraint attached to it: is this worth spending money on?

That question changes your architecture more than you think. You ask the smaller model first. You keep the context window under control and skip the retries you can't justify. You don't casually spawn five agents to attack the same problem from different directions, and you don't let one loop for an hour because maybe attempt seven will crack it. You optimize.

Which is completely sensible when it's your own credit card.

But there's another mode of operating. One where the constraint isn't "can I make this efficient enough to justify running it?" but simply "make this work." Now you can give the system more context, more tools, more autonomy, more attempts, more parallelism, more tokens, and above all more room to figure things out. And apparently that changes the answer to some questions from "yeah, AI probably isn't reliable enough for this" to "oh... We were just underpowering the whole thing."

There's a sneakier effect too. When every large context window, every retry, every agent loop and every parallel attempt costs you personally, you design around scarcity. Do that for long enough and scarcity starts to look like a property of the technology itself. You conclude "AI can't reliably do this," when the honest version is "AI can't reliably do this with one carefully rationed attempt, limited context and a budget-conscious architecture."

That's a very different statement.

My caution wasn't wrong. It was locally rational: tuned for personal projects, personal money and setups where waste actually mattered. What I hadn't internalized is how much capability appears when you stop trying to squeeze intelligence through the smallest possible pipe.

And this has started messing with my sense of what is realistically buildable.

## Mundane Engineering-Insane

At work, some of the goals I heard in my first weeks sounded slightly insane. Not "invent AGI" insane. The mundane engineering kind of insane, where you hear the requirement and immediately think: that's an entire team, six integrations, months of implementation, a mountain of glue code, three internal tools and an unfortunate amount of human process.

Then you look at the same problem through an AI-native lens. Not "where could we add a chatbot?" Not even "which individual tasks can AI accelerate?" The actual question: how much of this entire process still needs to exist in its current form?

That's where things get weird.

Suppose the job is basically: read a large amount of company knowledge. Search several systems. Figure out what's relevant. Correlate information that was never written with this exact question in mind. Produce a result, a few dashboards, check it against policies and previous work, and escalate the few decisions that genuinely need a person.

Traditionally that isn't one piece of software. That's a workflow strung across multiple humans. Departments, even. And increasingly, the interesting unit of automation isn't one task inside that workflow.

It can be the workflow itself.

That was the scale jump for me.

## The Factories Are Real

Then you look further out and discover people building actual software factories around fleets of agents. Not as a thought experiment. Not "one day, when the models are smarter." Today. Agents opening tasks, implementing things, reviewing each other's work, running tests, investigating failures, maintaining state, escalating decisions, and producing enough useful output that the bottleneck starts moving away from writing the code and toward designing the system that produces it.

That still sounds slightly ridiculous when I type it. But it works. Not perfectly, not magically, but well enough that you can no longer dismiss the direction as some distant sci-fi endpoint.

And once you've seen that, your horizon moves. Quite far.

## Your Judgment, Multiplied

The part that matters most to me: none of this invalidates the way I was already thinking about AI. It reinforces it.

I've increasingly believed that the most powerful way to use AI is to build systems around your brain rather than in place of it. Your judgment stays in the middle. Your taste, your goals, your understanding of the problem, your ability to notice that something feels wrong and change direction. Around that you assemble increasingly capable machinery: research agents, coding agents, reviewers, search, memory, automation, specialized workflows. Whatever actually amplifies the way *you* work.

Because I don't think there will be one universally optimal "AI workflow." Someone can publish the most sophisticated agent setup imaginable, you can copy it perfectly, and still hate it. The useful system is partly a reflection of the person operating it.

AI multiplies what is already there. Your judgment gets multiplied. Your curiosity gets multiplied. Your ability to decompose problems gets multiplied. So do your bad assumptions. Which makes the whole thing much more personal than "learn these five prompts and become 10x."

The models will keep getting better without your permission. The part that's on you is learning to construct an increasingly capable layer of machinery around yourself without giving away the seat that decides where you're going.

That's why this new scale is so interesting to me. I've spent a long time thinking about individual agents and workflows. Now I'm starting to see systems of agents. Organizations of agents. Software factories, persistent roles, automated feedback loops, AI systems improving and guarding the processes of other AI systems. Things I would have filed under "interesting idea, probably too ambitious to bother building" keep moving into a much more dangerous category:

"...wait, we could actually do that."

## Stranger Places

I'm increasingly convinced that one of the biggest mistakes we make with AI is evaluating it inside old workflows. We keep asking how AI could make an existing process 20% faster. Maybe the more interesting question is: if cheap-ish machine reasoning were simply another resource available to us, would we design the process like this at all?

That question leads to much stranger places.

I'm still cautious. Models still fail. Agents still do stupid things. Reliability, sources, verification, security: all of it still matters. More compute and more tokens do not magically turn a bad idea into a good system. But caution was never the thing limiting my imagination. I was cautious at roughly the right level. I was ambitious at entirely the wrong one.

The strangest part is that I don't think we've settled on the right abstractions yet. Chatbots, copilots, agents, skills, automations: these all feel like intermediate forms. We're still discovering what software looks like when reasoning itself becomes something you can provision, orchestrate and surround yourself with. Nobody has found the edges yet.

The ceiling is higher than I thought. Odd sentence to type for someone who assumed he was already one of the people "overusing AI. But it's the energizing kind of wrong, the kind where your general direction was right and the map extends a few hundred kilometers past where you thought the coastline ended.

So *this* is the scale.

Okay. Here we go then.

There's more to conquer.

---

P.S. as I had just finished writing this - Fable 5.1 just got released. Oh boy...
### My Long, Unnecessary Search for the Perfect Browser
URL: https://technikatsu.com/my-long-unnecessary-search-for-the-perfect-browser/
Last updated: 2026-08-07T09:34:04.000Z
[Google Chrome](https://www.google.com/chrome/?ref=technikatsu.com) is a very good browser.

It's fast, compatible with everything, familiar to everyone, and supported by every website whose testing strategy consists of opening the page once on the developer's laptop.

It is also one of the most boring poisoned defaults in modern computing.

Not because Chrome is malware - it isn't. The security engineering is great, and it keeps pace with the rolling industrial accident we call the modern web better than almost anyone. The poison is subtler: Chrome comes from an advertising company, plugs straight into that company's machine, and ships plenty of features that talk to Google. Some are optional. Some genuinely improve security: Enhanced Safe Browsing, for instance, can send URLs and pieces of page content to Google for analysis. All documented, honest and resting on one assumption: that you're comfortable placing Google in the middle of your online life.

I am not. So I spent years wandering the increasingly strange forest of alternative browsers. Two of them survive this post.

## Chrome: excellent software, wrong incentives

I understand why people use Chrome. You sign in and everything appears: passwords, bookmarks, extensions, the tabs from your other machine. Websites rarely complain. Employers expect it. Chrome removes friction wonderfully - including the moment where you might ask whether Google needs to sit between you and nearly every website you visit.

You can fight it, of course. Kill the toggles, refuse sync, spend an evening squinting through chrome://settings. At some point I had to ask why I was working this hard to turn Chrome into something that is not Chrome.

Chrome is a beautifully maintained apartment directly above a data refinery. Everything works. The heating is excellent. There is just a faint smell in the air.

## First, the Chromium disclaimer

Before someone starts typing furiously: [Chromium](https://www.chromium.org/?ref=technikatsu.com) and Chrome are not the same thing. Chromium is the open-source project underneath Chrome - and underneath Brave, Vivaldi, Edge and Opera. A Chromium browser can strip the Google integrations out entirely.

What it can't do is increase engine diversity. Switch from Chrome to any of these and you've escaped Google's product while the web keeps consolidating around Google's engine. Not automatically disqualifying - ideological purity is less charming when the payment form refuses to load - but worth remembering. It matters later.

## Brave: Chrome after a privacy intervention

[Brave](https://brave.com/?ref=technikatsu.com) is the easy recommendation for someone who likes Chrome but dislikes Chrome's relationship with Google. Same Chromium base, same extensions, same behaviour websites expect, except it blocks ads, trackers and a decent amount of fingerprinting out of the box, and its privacy policy says the browser doesn't collect your browsing history. Install it, spend two minutes disabling the cryptocurrency decorations you didn't ask for, get on with your life. Excellent trade.

For years my version of this was [ungoogled-chromium](https://github.com/ungoogled-software/ungoogled-chromium?ref=technikatsu.com): Chromium with the Google surgically removed. It works, and I respect it, but depending on the install, updates, extensions and media codecs all become small hobbies of yours. Brave does the same job with fewer sharp edges, and it has replaced both Chrome and ungoogled-chromium for me.

It's still Chromium, though. Remember the disclaimer.

## Firefox: genuinely good, aggressively fine

I used [Firefox](https://www.mozilla.org/firefox/?ref=technikatsu.com) for a long time. It supports extensions properly, keeps a major non-Chromium engine alive, and treats the browser as software rather than a funnel into an advertising platform.

But the interface is… fine. Not bad, not offensive, at no point exciting. Firefox is a dependable car bought after reading safety reports. It starts every morning. You respect it, you recommend it to relatives, and you never once walk back into the garage at midnight to admire it.

Mozilla also occasionally makes decisions that leave users asking whom exactly the decision was supposed to help… Still: Gecko matters, and Firefox is the browser I want to succeed even when I'm not particularly thrilled by Firefox itself.

## Floorp: Firefox discovers the settings menu

[Floorp](https://floorp.app/?ref=technikatsu.com) was my daily driver for half a year. I thought of it as stripped-down, hardened Firefox. Wrong. Floorp is Firefox for people who regard customization as a recreational activity: vertical and multi-row tabs, workspaces, web panels, split views, and a pile of switches of the "yooo wait, that's configurable?" variety. It's what happens when someone looks at Firefox and goes like:

> What if the user was allowed to decide things?

It served me well. I left anyway, because I found something I enjoyed more.

## Zen Browser: finally, a browser with taste

[Zen](https://zen-browser.app/?ref=technikatsu.com) is my current daily driver, and this is where the article stops pretending to be objective.

I love Zen.

Zen takes Firefox and gives it a genuinely modern interface: vertical tabs, workspaces, compact navigation, split views. Underneath it's still a Firefox fork and runs Firefox extensions. More importantly, the pieces feel designed together. Vertical tabs don't look like an extension taped onto the side of an old browser. Workspaces aren't buried in a submenu designed by a committee. Compact mode creates actual space instead of shaving off two pixels of padding and declaring victory.

Zen has an opinion about how browsing should feel, and that opinion happens to align remarkably well with mine. It also says it has removed Firefox telemetry and doesn't collect personal browsing data, though Sync still runs through Mozilla's infrastructure if you enable it. And it isn't perfect: young browser, occasional regressions, the odd tab departing into another spiritual dimension (especially in that split tab view, lol).

But Zen is the first browser in years that made using the browser itself pleasant. Not acceptable. Not "private enough". Pleasant. That counts for more than benchmark charts suggest.

## Vivaldi: impressive, but something stops me

[Vivaldi](https://vivaldi.com/?ref=technikatsu.com) should appeal to me. Tab stacking, tiling, panels, gestures, notes: enough customization to qualify as a desktop environment with a URL bar, built by people who clearly care about power users.

And yet I never settled into it. Partly aesthetics - Vivaldi presents so much functionality that I feel I should complete type-rating certification before opening a second tab. Partly transparency: Vivaldi publishes its Chromium modifications, but the interface layer isn't open source. That's not evidence of malice; proprietary software isn't spyware, just as open source isn't automatically trustworthy. But browsers handle an absurdly intimate slice of our lives, and when equally good options exist, transparency becomes the tiebreaker.

Vivaldi seems good. Something unnameable keeps me from committing, and it annoys me that I can't point to one decisive flaw. Or maybe I'm too lazy to just do some digging and properly form my opinion on it. Hard to tell.

## Edge: no, thank you

[Edge](https://www.microsoft.com/edge?ref=technikatsu.com) is probably technically good. Strong performance, decent vertical tabs, excellent Windows integration.

I am also severely allergic to Microsoft's approach to consumer software. I keep asking my doctor to add Microsoft to my allergy records, but they keep referring me to a psychiatrist instead. Weird. Anyway. Edge does not merely exist on Windows. It campaigns. It reappears. It imports your data and asks whether you're sure about your choices. It gives the impression that choosing another browser has emotionally wounded the operating system. I do not want my browser to have a customer-retention department.

So: no. This is not an objective security assessment. It is an immune response.

## Opera: trust is part of the product

[Opera](https://www.opera.com/?ref=technikatsu.com) still looks attractive: polished interface, useful sidebar, and [Opera GX](https://www.opera.com/gx?ref=technikatsu.com) has successfully convinced gamers that a browser needs RGB lighting and a CPU limiter.

My hesitation is ownership. The Chinese technology company Kunlun Tech beneficially owned roughly 68% of Opera's shares as of a July 2026 SEC filing. That proves nothing about how Opera handles data, and "Chinese-owned" doesn't mean malicious — Western companies commit astonishing privacy crimes entirely unassisted. But a browser sees everything: sites, forms, credentials. Trust is part of the product, and with equally capable alternatives available, unresolved ownership questions are enough.

Opera may be perfectly fine. I don't need it badly enough to run a personal geopolitical risk assessment before opening Reddit.

## Waterfox and LibreWolf: the privacy screws, tightened

Same shelf, different torque. [Waterfox](https://www.waterfox.net/?ref=technikatsu.com) is Firefox minus telemetry plus conveniences: integrated blocking, tree-style tabs, private containers. [LibreWolf](https://librewolf.net/?ref=technikatsu.com) is the aggressive sibling: uBlock Origin preinstalled, strict tracking protection, hardened anti-fingerprinting defaults - and, predictably, more websites confused about what species of visitor you are.

Both are sensible. I am THE targeted consumer for both. Neither made me enjoy the interface the way Zen does. I'm sorry.

## Orion: nearly brilliant, held together by WebKit magic

[Orion](https://kagi.com/orion?ref=technikatsu.com) is the most interesting browser on this list, because it's neither Chromium nor Firefox. It's WebKit (Safari's engine), wrapped by Kagi in a privacy-oriented browser with ad blocking, a [zero-telemetry claim](https://help.kagi.com/orion/?ref=technikatsu.com), and a party trick: it runs many extensions written for both Chrome and Firefox.

On paper, ideal. Safari's efficiency without Safari's famously tiny extension catalogue, plus a third engine that isn't feeding the Chromium monoculture. And Orion is genuinely nice: lightweight, native-feeling, none of that "web application impersonating a Mac application" quality.

In practice, the compatibility layer is ambitious rather than magical. A site would behave strangely, an extension would work right up until it didn't, and Orion's own docs describe [WebExtensions support as still growing](https://help.kagi.com/orion/misc/technical.html?ref=technikatsu.com). My RAM usage was also surprisingly bad, which stung, because efficiency was supposed to be the entire point of native WebKit. Orion [reached 1.0](https://blog.kagi.com/orion?ref=technikatsu.com) in November 2025 after years of beta; maybe both problems are fixed by now. I haven't stayed long enough to know.

I like the idea, I like the philosophy, and I even like using it - right up until something breaks or Activity Monitor starts judging both of us. Orion is fine. Potentially much more than fine. It never became dependable enough to take the main job. I still have it installed though.

## Ladybird: the one I'm rooting for

I haven't tried [Ladybird](https://ladybird.org/?ref=technikatsu.com) yet. Almost nobody has yet, to be fair.

Every browser above runs on one of three engines, and all three are kept alive by advertising money or Apple. Ladybird is a non-profit building a fourth one from scratch. Not a fork of something, or a wrapper: a from-zero implementation of the web platform, funded by sponsorships and donations - GitHub's co-founder wrote the first million-dollar check with a stated policy of no ads and no monetization of users. Ever.

This is the software equivalent of hand-digging a new tunnel through the Alps because you disapprove of who owns the existing ones. The roadmap is honest about the scale: first alpha for Linux and macOS in 2026, beta in 2027, stable in 2028\. And yet the engine already passes over two million Web Platform Test subtests, which is more than such projects usually manage.

I can't use it yet. I'm rooting for it anyway, probably even harder than for anything else on this list.

## Tor Browser: excellent, wrong problem

[Tor Browser](https://www.torproject.org/?ref=technikatsu.com) is not "Firefox, but more private". It's an anonymity tool that routes your traffic through the Tor network and flattens the differences between users, which means no random extensions, no heavy customization, no logging into your personal accounts. Use it deliberately, for the things that actually need anonymity or censorship resistance.

As a daily browser it would be commuting to work in an armoured personnel carrier via forest side-roads. Impressive protection, unusual handling, difficult parking. I'm glad it exists. I don't need it to read technology blogs and argue with strangers about AI.

## Where I actually landed

**Zen is the daily driver.** Firefox's engine, Firefox extensions, better privacy defaults, and an interface I *actively enjoy very much, thank you*.

**Brave is the Chromium fallback.** For websites constructed entirely around Chrome assumptions, without routing me back through Google. Sometimes spoofing Zen's user agent to say "I'm Chrome" is enough, but sometimes - not.

## The browser is part of the web's politics

Choosing a browser is not revolutionary activism. Google will not review its quarterly results, notice I installed Zen, and abandon advertising in shame.

But defaults accumulate, and this is why the Chromium disclaimer matters. When almost everyone runs one engine, websites stop being built for the web and start being built for that engine. Standards become whatever the dominant implementation already does, and "compatibility" becomes another word for obedience.

Firefox, Zen, Floorp, Waterfox and LibreWolf keep a second engine in ordinary circulation. Orion keeps a third one alive outside Safari. Ladybird is digging a fourth by hand. Brave doesn't fix the monoculture, but it fixes your own defaults.

And using Chrome is not a moral failure. Sometimes you need the tool that causes the fewest problems, and Chrome is extremely good at being that tool. Just remember that "works without effort" and "acts in my interest" are different properties.

Chrome is fast. Chrome is secure. Chrome is compatible.

Chrome is fine.

That is the problem.
### What If AI Agents Could Simply Pay the Web?
URL: https://technikatsu.com/what-if-ai-agents-could-simply-pay-the-web/
Last updated: 2026-08-05T11:27:40.000Z
Gamers Nexus [recently explained ](https://www.youtube.com/watch?v=0WP6kEO3i8g&ref=technikatsu.com)why it's started making some of its benchmark charts harder for AI systems to scrape. The anger and frustration is fair. GN spends real (BIG) money on laboratories, hardware, staff and thousands of benchmark runs, publishes most of it freely (no ad-stuffed pages, no hard paywall), and then an AI agent strolls in, extracts the one conclusion a reader needs, and leaves with it. No money for the publisher. No reader, either.

The countermeasure: hide prompt injections inside the chart images, so an AI asked about GPU temperatures starts discussing chocolate-chip cookies instead.

It's funny. It's also a little depressing. GN says openly that PNG charts are now attractive partly *because* they're harder for language models to parse and easier to poison than a clean table. An independent test lab, deliberately making its data harder to read. Progress?..

I get the anger. Nobody should have to watch their expensive original work get vacuumed into someone else's commercial product for free. But making information less accessible is a strange answer to tools that make information more accessible.

So far the web has been offered two futures: every commercial crawler eats everything for free, or everything retreats behind subscriptions, login walls and booby-trapped images. Pick your dystopia.

I'd like a third option. What if agents could simply pay?

## Most readers aren't joining your community

A huge share of informational content is consumed *transactionally*. Someone builds a PC and wants to know which case has the best cooling without sounding like a vacuum cleaner. They research, buy the case, and disappear from hardware journalism for the next four years.

The same pattern is everywhere: the car making a suspicious noise, the washing machine stopped draining, the one weird framework error, the bathroom tap that needs replacing without flooding the downstairs neighbor. These people have a problem and want a reliable answer. They are not trying to find a new hobby.

I watch hardware testing for fun, because I'm an "geek" and apparently observing someone measure airflow through a metal box counts as entertainment for me. But when my car breaks, I'm not beginning a three-year emotional journey through the automotive repair creator ecosystem. I find the relevant ChrisFix video, fix the thing, and come back when the next component attempts to become spiritually independent from the vehicle. Or, you know, unleash some agents to the web. MY agents that I self-host.

Most users are lurkers. They arrive, solve something, leave. Millions of them still add up to views, ad revenue and the occasional store purchase - and the economics are still brutal. GN says some reviews already run at a loss, subsidised by investigations, Patreon and store sales; one case review cost around $2,000 in staff time and brought in roughly $1,400, not counting Steve Burke's own hours.

The problem is real. Shoving every one-time visitor back into the good-old browsing funnel is still the wrong fix.

## Give the agent a wallet

Imagine your agent has a small wallet. You top it up with €5\. When it researches something, it searches free sources as usual, but can also discover paid, machine-readable material:

> I found several free sources, but they mostly repeat the same manufacturer claims. I also found three paid sources containing original testing:  
>  
> \- Independent thermal benchmarks: €0.05  
> \- Long-term reliability data: €0.12  
> \- Full structured benchmark dataset: €0.40  
>  
> The €0.05 source appears most relevant. Allow one-time access?

You click yes. Five cents leave the wallet, the agent pulls the data, cites the source, and answers the question. Nobody bought a €12 monthly subscription to read one article about a CPU cooler.

That subscription is the current alternative, and it's a ridiculous binary: content funded by advertising, tracking, affiliate links and increasingly desperate newsletter pop-ups - or a recurring commitment to a publication you need twice a year. A micropayment matches the actual relationship: one answer, five cents. A professional pulling a full dataset pays more. The actual fans still subscribe, still join the Patreon, still buy the modmat.

## HTTP has been waiting for this since 1997

My favourite part: the plumbing already exists.

HTTP has a status code called `402 Payment Required`. It entered the spec with HTTP/1.1 in 1997, marked "reserved for future use", and has spent almost thirty years sitting between the celebrities 401 and 403\. The future, apparently, was on backorder.

Well, here it is. The flow is embarrassingly simple:

![](https://technikatsu.com/content/images/2026/08/image.png)

The 402 response carries the price and the rules:

```json
{
  "price": { "amount": 0.05, "currency": "EUR" },
  "scope": "single_retrieval",
  "cache_hours": 24,
  "training_allowed": false,
  "attribution_required": true,
  "payment_methods": ["x402", "wallet-credits"]
}

```

The agent checks its limits, pays, retries with proof of payment, gets clean structured content. No headless-browser theatrics, or fourteen consent dialogs, or pretending to be Chrome on a human's laptop.

And no, I didn't invent this protocol on my couch. Ok, to be fair, idea appeared on the couch - true, but Cloudflare's [pay-per-crawl](https://developers.cloudflare.com/ai-crawl-control/features/pay-per-crawl/what-is-pay-per-crawl/?ref=technikatsu.com) has been answering AI crawlers with a 402 and a price since 2025, and [Stack Overflow has already signed up](https://stackoverflow.blog/2026/02/19/stack-overflow-cloudflare-pay-per-crawl/?ref=technikatsu.com). Coinbase turned the handshake into [x402](https://blog.cloudflare.com/x402/?ref=technikatsu.com), an open payment standard, and Cloudflare's new [Monetization Gateway](https://blog.cloudflare.com/monetization-gateway/?ref=technikatsu.com) extends it to anything behind their edge: pages, datasets, APIs. The pipes exist.

What flows through them today is mostly machines buying API calls and market data from other machines, plus [enough wash trading to flatter the statistics](https://www.coindesk.com/markets/2026/03/11/coinbase-backed-ai-payments-protocol-wants-to-fix-micropayment-but-demand-is-just-not-there-yet?ref=technikatsu.com). The version I care about still doesn't exist: *my* agent, *my* five cents, the one article *I* need. The real deals being signed are bulk licensing between large AI companies and large publishers, negotiated over everyone's heads. A per-reader toll is the version that also works for a two-person hardware channel or a lone blogger.

## The publisher should say what's for sale

Alongside the handshake, publishers could expose a price list - a machine-readable file in the spirit of `robots.txt`, something like `/.well-known/agent-access.json`:

```json
{
  "publisher": "Example Hardware Lab",
  "content": {
    "article_preview": "free",
    "full_article": { "price": 0.05, "currency": "EUR" },
    "structured_benchmark_data": { "price": 0.30, "currency": "EUR" }
  },
  "permissions": {
    "personal_retrieval": true,
    "temporary_cache_hours": 24,
    "model_training": false,
    "commercial_republication": false
  },
  "attribution": {
    "required": true,
    "canonical_link_required": true
  }
}

```

`robots.txt` can only say "please don't" and hope. This says: here's what access costs, here's what you may do with it, here's what stays off the table.

It would also split the activities currently thrown into one angry bucket labelled "AI scraping". A personal agent fetching one article for one user is not a company ingesting your entire archive into a training dataset. One is a reader. The other is a licensing negotiation.

## Pi-hole blocklists, but inverted

Giving an agent money creates the obvious next problem: deciding who deserves it. Left unsupervised, the agent would enthusiastically distribute your wallet across seventeen SEO farms that all rewrote the same Reddit comment.

So, an idea from the early web returns: the curated directory. Think Pi-hole blocklists, but inverted. Instead of "these domains are garbage, block them", the list says: these publishers do original work, and my agent may pay them within limits.

You subscribe to a few: independent hardware testing, European financial journalism, French investigative media, car repair resources that aren't content farms. Each entry carries more than a trusted-or-not flag:

```yaml
publisher: Example Hardware Lab
domain: example.com

trusted_for:
  - pc-hardware-benchmarks
  - thermal-testing
  - product-investigations

not_evaluated_for:
  - financial-advice
  - medical-information

payment:
  auto_limit_per_item: 0.10 EUR
  monthly_limit: 2.00 EUR

```

Trust should be contextual. Gamers Nexus is highly trusted for hardware measurements. That does not make it the final authority on monetary policy, dermatology or Polish mushroom identification.

Anyone could maintain a list; users stack them. A university curates primary scientific sources, a mechanic curates repair databases, and I finally publish technikatsu's Opinionated Directory of Websites That Are Probably Not Complete Garbage.

The format has to be open, and no single company gets to own the master list. Otherwise we'll spend ten years building a decentralised trust system and end up reinventing Google, but now with transaction fees and no customer support.

## Payments need aggressive guardrails

An agent with a wallet is useful right up until it discovers the timeless pleasure of spending someone else's money. The spending path needs to be paranoid af by default:

![](https://technikatsu.com/content/images/2026/08/image-1.png)

Plus receipts, caching so one article never gets bought twice, and refunds when the paid content is materially different from its preview.

The agent should also justify the expense. Acceptable:

> The free sources repeat the manufacturer's specifications. The €0.07 source contains original acoustic measurements and is cited by three other articles.

Not acceptable:

> I encountered several premium knowledge opportunities and spent €44.83 in pursuit of excellence.

Publishers will game this, because of course they will: misleading previews, one article chopped into twenty paid fragments, recycled forum posts sold as "original research", prices that climb for users who look wealthy, AI-generated sludge engineered specifically to trigger agent payments. Internet can't be blindly trusted.

That's what the allowlists are for. Agents and list maintainers track whether paid sources actually satisfied the query; a site charging €0.10 for reheated forum content drops off the lists, a publisher consistently delivering original data earns automatic payments. Reputation, with money attached.

## Attribution still matters

Payment doesn't replace attribution. The agent shouldn't dissolve its sources into a beige paragraph beginning with "Research suggests…". It should say "according to Gamers Nexus' noise-normalised testing…", cite it, link it. The publisher gets money, credit and a shot at the readers who do care. The reader gets the number and the caveat without finding one-time relevant bit in a 25-minute video.

GN's complaint that AI answers surface its work while cutting it out of the loop is legitimate. But the fix can't be making the source hostile to software. The value of Gamers Nexus was never that its charts are annoying to extract - it's the testing, the equipment, the methodology, the earned trust. Agents don't destroy any of that. They expose that the economic interface for it never existed.

## Don't trash the road. Install a toll gate.

When cars appeared, the answer was not to scatter nails across the road until everyone went back to horses. When spreadsheets appeared, accountants did not protect arithmetic by printing numbers sideways and hiding cookie recipes between the rows.

AI agents are an unusually good interface for exactly the kind of question people ask once, solve, and forget for four years. That traffic was never going to become community members, and no amount of chart poisoning will make it browse like it's 2009 again.

Let agents search openly, find the original source, pay a small toll, respect the terms, show the attribution. Publishers earn money from readers who would never have subscribed. Readers stop juggling accounts. Agents stop behaving like scrapers.

The web doesn't have to choose between unlimited free extraction and booby-trapped charts. HTTP had the answer in 1997.

Let the agent pay the damn toll.

And [go support GamersNexus](https://gamersnexus.net/?ref=technikatsu.com), if you like what they're doing.
### Chat Control Won by Losing the Vote
URL: https://technikatsu.com/chat-control-won-by-losing-the-vote/
Last updated: 2026-08-06T17:14:37.000Z
On 9 July, the European Parliament voted on whether to keep Chat Control alive. **314** MEPs voted to bury it. **276** voted to keep it. It is now in force until April 2028.

None of those numbers are typos.

I've been circling this topic for weeks because it makes me tired in a way that's hard to turn into anything useful. But I run my own servers, I've argued here that [you should own your infrastructure](https://technikatsu.com/you-should-self-host-and-here-is-why/), and this is the file that decides whether private communication in Europe stays private. So let's walk through it calmly. Mostly calmly. I'll try, at least...

## What actually passed

"Chat Control" is two different things wearing one name, and mixing them up is how every discussion about it derails.

**Chat Control 1.0** is what just got extended: a derogation, a formal carve-out from the EU's ePrivacy rules, that lets providers *voluntarily* scan private messages and mail for child sexual abuse material. (A purpose I take seriously, for the record. We'll get back to how it's being used.) In practice "providers" means webmail and messaging services, overwhelmingly the big American ones; [Patrick Breyer's rundown](https://www.patrick-breyer.de/en/posts/chat-control/?ref=technikatsu.com) names Instagram DMs, Snapchat, Gmail and iCloud mail among them. No warrant or suspicion attached to you personally. The regime is voluntary, excludes audio, and - after the July amendments - [explicitly excludes](https://agora-intelligence.com/en/blog/atlas-eu-chat-control-extension-2026?ref=technikatsu.com) properly end-to-end encrypted services like Signal and WhatsApp. For *now*.

**Chat Control 2.0** is the still-pending CSA Regulation. The original 2022 proposal contemplated *mandatory* detection orders, and applying those to end-to-end encrypted apps is only possible if you break the encryption or read messages on the device before encryption happens. The permanent text is still being negotiated, and the treatment of encryption is the contested heart of it. (The commissioner who originally championed it once compared this to a police dog sniffing luggage. A metaphor that works right up until you ask what the dog is supposed to smell... bits can be anything, you know...) It hasn't passed. It hasn't died either.

## The part where losing counts as winning

Parliament already rejected this extension once, in March. The file was reopened at the end of June, bounced through the Council, and [came back for a vote on 9 July](https://www.euronews.com/next/2026/07/10/chat-control-10-passed-the-european-parliament-through-the-back-door?ref=technikatsu.com), in the last plenary before the summer break.

At that stage of the procedure, rejecting the Council's position takes an absolute majority of all 720 seats: 361 votes. A majority of votes cast doesn't count. Rejection got 314 votes against 276, with 17 abstentions, and more than a hundred MEPs didn't vote at all - which, under an absolute-majority rule, has the same practical effect as *voting against rejection*. Rejection failed by 47 votes, and the derogation now runs until 3 April 2028.

I want to stay measured here, because "the EU is corrupt" is the lazy version of this post and I don't believe it. Absolute-majority rules of this kind are old and exist for defensible reasons, and I can't prove anyone picked the date with the attendance sheet in mind. So I'll stick to math. In March, Parliament rejected the previous extension 311 to 228\. The opposition exists. On 9 July, not enough of it was in the room, and the rule did the rest.

## They exempted it from their own privacy law

Here's the part I most want you to take away, because "Chat Control violates GDPR" gets repeated a lot, and it's almost right in a way that's worth being precise about.

Strictly speaking, it doesn't violate GDPR, for roughly the same reason a hole doesn't violate the fence. The precise version goes like this. Once EU confidentiality rules - the ePrivacy Directive - fully applied to messaging services, providers could no longer lawfully run this kind of scanning; GDPR alone was not a sufficient basis for it. So Chat Control 1.0 was written as a derogation: a formal exemption from ePrivacy's confidentiality articles, passed so the scanning could continue. And the regulation's own text says the quiet part. It derogates from the confidentiality rules, it does not itself create a lawful basis under GDPR, and it describes the voluntary scanning as an interference with the fundamental rights of every user of the service. Their words.

Sit with that for a second. Nobody argued that the scanning complies with the confidentiality rules. They wrote an exemption from those rules so that it wouldn't have to comply. Bureaucracy...

The EU's own institutions have been blunt about the mandatory version too. The European Data Protection Supervisor and the EDPB jointly warned it was disproportionate; German civil-rights lawyers call it [incompatible with fundamental rights](https://freiheitsrechte.org/en/themen/freiheit-im-digitalen-zeitalter/chatkontrolle?ref=technikatsu.com) outright. And the Court of Justice wrote, back in [Schrems](https://curia.europa.eu/juris/liste.jsf?num=C-362/14&ref=technikatsu.com), that generalised access to the content of communications compromises "the essence" of the right to private life. Courts don't reach for the word *essence* casually. It marks the line past which no safeguard can save a law.

I'm not a lawyer, and I won't pretend to know how Chat Control 2.0 would fare on its inevitable trip to Luxembourg. I'll only observe that when your flagship child-protection law needs a trapdoor cut through your flagship (no sarcasm here) privacy law, one of the two is not what you claim it is.

## Apple already ran this experiment

Now the engineering part, which is the part I'm actually qualified to be angry about.

To scan end-to-end encrypted messages you have two options. Option one, break the encryption, which nobody serious pretends is safe. Option two, client-side scanning: ship a classifier on *every* phone that reads each message *before* it gets encrypted and reports whatever it dislikes. The premise behind option two is that it "preserves" encryption. It preserves it the way a chaperone preserves a private conversation.

We don't need to speculate about how this goes, because Apple ran the experiment in 2021\. NeuralHash: on-device CSAM detection, perceptual hashing, backed by the best-funded security team in consumer tech. Within weeks, researchers had extracted the model and produced collisions - harmless images that fingerprint as flagged ones. Apple paused the rollout, then [killed it](https://www.wired.com/story/apple-photo-scanning-csam-communication-safety-messages/?ref=technikatsu.com), and later admitted that scanning infrastructure creates *new attack surface* and sits one policy change away from scanning for other things. One failed system doesn't mathematically doom every future one; Apple's design isn't the only possible design. Also, 5 years passed since then. So take this as my engineering judgement rather than a proof: if the best-funded security team in consumer tech walked away rather than own the risks, a regulation is not going to conjure a safe version by mandate.

That's the core security problem. A scanner on half a billion devices with a remotely updated watchlist is infrastructure, and what it scans for is a configuration detail. Today, CSAM. Tomorrow, whichever category is urgent that year - maybe music piracy, maybe documents or payments control. The infrastructure is the decision; everything after it is scope. 

## "But I have nothing to hide"

Every time I write about surveillance, someone shows up with the same two sentences: "I have nothing to hide," and its uglier sibling, "if you're hiding something, it's probably something illegal."

Privacy is a right. Article 7 of the EU Charter of Fundamental Rights: everyone has the right to respect for their private life and communications. The word *communications* is sitting right there in the text, next to the article that guarantees you a fair trial. Rights don't owe anyone a justification; searches do. That is the entire logic of a warrant: suspicion first, a named person, then the search. Chat control runs it *backwards*: scan a whole continent first, let a classifier generate the suspicion afterwards.

And of course you hide *legal* things. You hide your salary from your coworkers and your diagnoses from your boss. You tell your best friend things you'd never tell your mother, and your therapist things you'd never tell your best friend. Choosing who sees what is called *having relationships*. A scanner in every chat flattens all of it into one audience you never invited.

But here's what worries me most about "nothing to hide": it assumes that *you* decide what counts as suspicious. You don't. A model does. And your chats look a lot weirder to a model than you think.

## The false-positive machine

I'm a developer. When a Unix process makes a copy of itself, that's called a *fork*. The copy is a *child*. When the child hangs, you *kill* it. When the parent dies first, the children become *orphans*, sometimes *zombies*, and the system *reaps* them. Which means my actual work chats contain sentences like "just kill the child manually" and "the parent died, so the orphaned children got reaped." Now put a grooming classifier on that - a model trained to find predators in text, with no idea what a process is - and tell me how confident you feel. Google search once interpreted one of my searches as malicious intent. A few others showed me emergency help lines. I was googling dev problems :)

Gamers have it worse. Half the strategy genre reads like a tribunal transcript out of context. RimWorld players casually discuss selling prisoners and harvesting organs; Crusader Kings players marry off twelve-year-old heirs, because it's the twelfth century and that's the game. A quest walkthrough, a heist plan over voice chat. None of these people are criminals. All of them are one context-blind classifier away from a report with their name on it.

And then there's the category nobody wants to say out loud, so I will, briefly. If you exchange intimate photos with your partner - and a lot of adults do - a scanning regime means a classifier can see them. (Today that's a possibility on services that choose to scan; making it universal is what the 2.0 fight is about.) That's already a violation with no further steps required: a third party in the most private channel you have. Nudity is what these systems are tuned to stop on, and under the current law suspected *new* material must be confirmed by a human before it's reported - a safeguard on paper that means, in practice, a stranger reviewing pictures meant for exactly one person. The failure mode past that ruins lives: estimating age from a photo is notoriously unreliable, and a wrong guess about an adult puts your private photos in an abuse-report pipeline with your identity attached. If your partner is short, skinny, or simply cursed/blessed with a very youthful face, you may be safer sending photos by actual carrier pigeon.

Here's where I have to mention teenagers, and I want it on record that I resent this law for making that necessary. Arguing against chat control competently meant researching the failure statistics of abuse-reporting pipelines, and I hate that I now know them. The short version, per figures [Patrick Breyer](https://www.patrick-breyer.de/en/posts/chat-control/?ref=technikatsu.com) has published for years (he campaigns against this file, but the numbers he cites come from police statistics, linked in his write-ups): nearly half the scanner reports reaching German federal police are criminally irrelevant, a large share of the resulting investigations end up targeting minors over their own pictures, and 99% of what Meta reports is previously known, already-catalogued material - which can still have investigative uses, but is a strange flagship result for a system sold as finding new abuse. That's all the space I'm giving it.

The canonical false positive is documented by the [New York Times](https://www.nytimes.com/2022/08/21/technology/google-surveillance-toddler-photo.html?ref=technikatsu.com): a father photographed his sick toddler for a telehealth appointment, Google's classifier flagged him, police investigated and cleared him, and Google still never returned his account, phone number included. Scale that pipeline to 450 million people and tell me it's a child-safety system.

## The juiciest target in Europe

Follow the data one step further. Scanning means copying. Everything flagged (correctly or, far too often, not) flows into review queues at moderation vendors, then into report databases, then into police systems across borders, where it sits for years. Intimate photos and private conversations, pre-sorted for sensitivity, with identities attached, concentrated in a handful of systems. If you were designing bait for every criminal group and intelligence service on the planet, this is what you would design. 

Will it actually get breached? I can't prove the future, so call it an exceptionally valuable target that will be attacked permanently, by professionals. If I were an attacker, I’d lose sleep over this. What I can do is point at the record - pick any week of security news: telecoms, insurers, hospitals, now and then a security agency itself. The on-the-nose case is Salt Typhoon. In 2024, a Chinese state group burrowed into US telecom networks through the lawful-intercept systems built for police wiretaps and camped there for months. The backdoor for the good guys was a front door for someone else, which is what security engineers had been predicting for thirty years, to a chorus of "think of the children." The aftermath was the comic part: US federal agencies responded to the breach by advising citizens to move to end-to-end encrypted messaging. America built the wiretap machine, watched it get robbed, and told everyone to install Signal. Europe watched the same robbery and decided to build a bigger machine.

## The paper trail

One more layer, because the story of how the 2.0 proposal got made has receipts of its own - dug up by journalists, a parliamentary committee, the EU's privacy watchdog, and the EU Ombudsman, none of whom can be waved away as paranoid cryptographers.

The 2022 proposal was then-Commissioner Ylva Johansson's file (the police-dog metaphor from earlier is hers 🫠 ). A BIRN investigation titled, fittingly, ["Who Benefits?"](https://balkaninsight.com/2023/09/25/who-benefits-inside-the-eus-fight-over-scanning-for-child-sex-content/?ref=technikatsu.com) documented how closely Thorn (a US organisation co-founded by Ashton Kutcher and Demi Moore that develops and sells AI-based CSAM-detection tools) was involved along the way: extensive access to the commissioner's cabinet, over €600,000 spent on EU lobbying in a single year, and a letter from Johansson to Thorn's director celebrating the "journey to this proposal" and thanking the organisation for helping supply its evidence base. An organisation that sells scanning technology helped build the case for a law that would create a continent-sized market for scanning technology. Meanwhile, digital-rights groups and even an established Dutch abuse-reporting organisation said they struggled to get comparable access.

Now the hedges, because they matter. None of this proves bribery. Johansson denied any financial influence, and a European Parliament research briefing later concluded the Commission had formally followed its consultation rules. But Parliament's civil-liberties committee still summoned her over conflict-of-interest allegations. And in February 2025 the European Ombudsman ruled on the other end of the pipe: two Europol officials had moved to Thorn, one straight from working on AI-based CSAM detection, and Europol's failure to manage that "clear risk of a conflict of interest" was formally ruled [maladministration](https://www.patrick-breyer.de/en/chat-control-eu-ombudsman-criticises-revolving-door-between-europol-and-chat-control-tech-lobbyist-thorn/?ref=technikatsu.com).

The doubts even predate the launch. The Commission's own Regulatory Scrutiny Board initially rejected the proposal's impact assessment, questioning whether scanning encrypted communication was feasible at all and whether it could comply with the ban on general monitoring; the assessment was revised and squeaked through with reservations. And minutes obtained by journalists show [Europol suggesting](https://balkaninsight.com/2023/09/29/europol-sought-unlimited-data-access-in-online-child-sexual-abuse-regulation/?ref=technikatsu.com) early on that other crime areas could benefit from the detection infrastructure, with unfiltered access to the harvested data on its wish list. Earlier I wrote that the infrastructure is the decision and everything after it is scope. I was late. Europol got there while the machinery was still on the drawing board.

Then, when support in the Council wavered, the Commission promoted the proposal with targeted ads on X in the Netherlands and other hesitant countries, ads that used people's political and religious profiles to decide who would see the message. noyb complained, and in December 2024 the EDPS [formally found](https://noyb.eu/en/political-microtargeting-eu-commission-illegal?ref=technikatsu.com) that the Commission had unlawfully processed sensitive political-opinion data, settling for a reprimand only because the campaign had already stopped. Read that again: the executive proposing a mass-scanning law promoted it with illegal political profiling. At this point satire should file for early retirement.

So, the fair summary, hedges attached: the proposal for a law that would legitimise mass scanning was shaped with unusually close input from organisations that develop and sell scanning technology, while some civil-rights and abuse-reporting groups said they struggled to obtain comparable access. It was published over its own reviewers’ initial objections, discussed internally as infrastructure that could serve purposes beyond its stated one, promoted using unlawful political profiling, and followed by an official maladministration finding involving Europol and Thorn. No conspiracy required. Just incentives - all of them on the record.

"BUT" - you will say - "that's logical! Consulting the industry is completely logical and is the right thing to do." Yes... BUT - The problem starts only when "consultation" becomes "*the interested vendor helped define both the problem and the required solution*."

Imagine you ask a cleaning company how to keep offices clean. Reasonable. Now imagine that the same company supplies the evidence that offices are dangerously dirty, helps shape a law requiring continuous automated cleanliness monitoring, sells the monitoring equipment, and reports more than €600,000 in EU lobbying expenditure that year.

That does not prove corruption. It does create a conflict of incentives visible from the International Space Station without a telescope.

## The argument you're not allowed to argue with

Every critic of chat control opens with the same disclaimer: child abuse is real, protecting children matters. Mine is a few sections up, and I meant it. But notice that the disclaimer is mandatory: skip it and you'll be read as defending the people this law claims to hunt. That reflex is the mechanism. For twenty years, nearly every expansion of surveillance has shipped wrapped in terrorism or children, and the wrapper is chosen precisely because it makes the price of opposition your own decency.

So apply the only honest test: does it protect children? This system risks burying investigators in machine noise and repeatedly reports already-catalogued material, while abuse survivors have told Parliament directly that escaping abuse required confidential channels in the first place. Breyer's harshest point is also his most bureaucratic: as long as mass scanning keeps ticking along, nobody has an incentive to fund the targeted, unglamorous police work that actually finds abusers. "Think of the children" is doing the job here that evidence was supposed to do.

The argument's last resort is personal: "do you want this to happen to *your* child?" No. I also don't want my child assaulted on the way home, hit by a car, or manipulated by an adult they trust. And we haven't answered any of those by pinning an always-on mic and camera to every kid and streaming the feed to an automated reviewer. Imagine how safe they would be! Instead - we teach them, watch over them, build safer streets, and investigate when there is actual cause. What I want for mine is technical literacy, a healthy radar for manipulation, and above everything - a confidential channel through which to ask for help: the kind this proposal keeps trying to place a stranger inside. Child safety is a shared duty. Universal surveillance is not a synonym for it.

## What I'm doing about it

Nothing dramatic. Time to move to Signal, I guess; its current exclusion exists at the pleasure of the next vote, and its president has already said they'd leave a market before they'd break encryption. My mail sits with a non-Gmail European provider, and the [self-hosting argument](https://technikatsu.com/you-should-self-host-and-here-is-why/) I made here two years ago just grew another leg. Chat Control 2.0 is still moving, which means MEPs will vote again, which means writing to your MEPs is, boringly, the actual lever. July's rejection failed by 47 votes.

And once again: I hate that I now know all this.

//Sincerely

*Views are personal and do not represent any current or former employer. Apparently this must be said.*
### I Built a Tiny AI Task Manager Because AI Agents Keep Forgetting Context
URL: https://technikatsu.com/i-built-a-tiny-ai-task-manager-because-ai-agents-keep-forgetting-context/
Last updated: 2026-05-24T12:58:18.000Z
I've been explaining the same architectural decision to my AI agent four times per week. The same decision, four sessions, from scratch every time. Each new session the agent walks in fresh, the chat window where we settled it last time is closed, and the rationale that justified the choice lives only in my head, where it helps nobody including future-me.

AI agents have a memory problem. They do excellent work in the moment and lose the plot the next session, since whatever context you painstakingly built has expired. By day thirty of any project, half the decisions trace back to chat windows you've closed, and the other half live in your head, or your own notes. The agent that picks the project up tomorrow - technically, the same model, but practically a complete stranger.

The fix is boring: write everything down. The catch is that most ticketing systems are too heavy to maintain alongside the actual work, so people stop, and the fix stops working. The trick is to make the ticketing light enough that the *agent* will actually keep doing it, and structured enough that the next agent who reads it can pick up where the last one left off.

So I built a thing.

Essentially it's a simplified Jira/Trello/whatever-kanban-thing-comes-to-mind, but build in a way that AI agent can actually use it, locally. And human could just observe what's going on and steer when needed. Corporate idea of pain, but without corporate and pain, hah. 

## The Protocol Is a Folder

**ai-agent-workflow** is three directories: `backlog/`, `inbox/`, `done/` . There's also a SKILL.md that tells any agent how to use them. Each ticket is a markdown file. The folder it sits in *is* its status. Move the file, the status changes. Grep the folder, you see the truth. Delete the GUI app and your project keeps working.

Every ticket follows the same shape:

```
# B3. fix preview crash on large PDFs
## Metadata- Status: INBOX- Severity: HIGH- Scope: Desktop app- Assignee: Claude
## Problem{1–3 sentences. What is wrong, with evidence.}
## Required Changes{Step-by-step. File paths, signatures, code snippets if needed.}
## Acceptance Criteria{Bulleted, verifiable.}
## Notes{Optional. Gotchas, dependencies, what to skip.}
```

This is not just fancy dashboard thingy. The structure *is* what does the work, in both directions. *Going in*: the agent *has* to think before it writes anything, because the moment it has to draft Acceptance Criteria for "fix the auth thing". It can no longer guess on the fly; it has to commit to a position in writing. *Coming back out*: when the same agent or a different one tomorrow - picks up that ticket, the Problem is stated, the Required Changes are listed, the Acceptance Criteria are spelled out. Far less room for creative reinterpretation than "remember the auth thing we were cooking 2 days ago".

The whole ticket is, functionally, a letter from one agent to the next. It just happens to look like a project management artefact.

That is the whole product. The skill is a \~300-line markdown file. The tickets are markdown files. The board is a folder.

## So Why Build a GUI

Because after reading a folder full of forty tickets you go blind. You *could* use Zed /VS Code or some markdown viewer, and I did it like that at first, but it still was quite clunky...

As you can see, the design is very cyberpunk 👾 

But anyway;

**AI Task Manager** is a Tauri desktop app (Svelte frontend, Rust backend, \~11MB binary) that points at a project root folder and gives you a board over its `ai-agent-workflow/`. Three columns, cards, a detail pane, filters by assignee/scope/severity/status. Drag a ticket from `inbox/` to `done/` and the file actually moves on disk; the metadata flips; the next agent run sees the change.

It is, deliberately, a view layer. The filesystem is the database; the app's whole job is to render what's already there. If I meet the bus face-to-face tomorrow, your tickets are still sitting in their folders, exactly the way the last agent left them. You can keep working from `vim`. That is a feature.

Where the GUI is just a tailored command center. When I've handed the inbox to a scheduled agent and I want to glance at what it did overnight, the board is faster than `ls done/ | sort -r | head`. Same data, less filtering. Both work though.

## Autonomous Loops, or: How Agents Work While I Sleep

The split between `inbox/` and `backlog/` looks small on the README but it is the entire reason this works for AI agent workflows. A regular kanban board would not survive a cron job.

`inbox/` is authorised work: the hooman meatbag has signalled these are ready to execute. `backlog/` is the queue: real, worth doing or maybe not - not green-lit yet. A scheduled agent (a cron job, a Codex Automation, a `git push`\-triggered CI worker, an `@autonomous` skill... pick your flavour) can safely go through `inbox/` without surprising anyone (you), because every ticket in `inbox/` is already a fully written briefing. It works the tickets, writes verification notes, flips `Status` to `DONE`, moves the file. `backlog/` stays untouched until I personally promote something into the queue or tell agent to specifically do something about the backlog.

So the loop for AI agent is small, *not* an overhyped miracle department worker:

1. Read `ai-agent-workflow/inbox/`.
2. Pick the highest-severity ticket assigned to it.
3. Do the work the ticket already specifies.
4. Append verification notes, set Status to DONE, move to `done/`.
5. Sleep.

Run that on a schedule and your project moves while you don't. Open the desktop app the next morning, see what happened, redirect with the `Assignee` field if you want, promote a few items from `backlog/` to `inbox/`, go back to washing dishes.

The skill ships with one hard rule: anything needing credentials, secrets, or production deploy access auto-routes to `Assignee: Human`. Agents do not hold my keys. You, ofc, can tweak it to do otherwise, if you know what you're doing.

## Living Documentation, Where Memory Actually Lives

Tickets describe *changes*. They are useless for understanding *what is currently true*. So the skill also scaffolds a `documentation/` folder when a project warrants it — `CURRENT_STATE.md`, `ARCHITECTURE.md`, `SECURITY.md`, `DEPLOYMENT.md`, `DEVELOPMENT_GUIDE.md`, `ROADMAP.md`. Point-in-time artefacts (a security audit, a performance baseline) go in `documentation/archive/` with a date in the filename and never get edited again. Yes, tokens, but those *vastly* improves the quality of project I'm doing. Because, once again, it forces agent to "bear in mind" that there's more to the project than just baking new features like there's no tomorrow.

The rule the skill enforces: when a ticket changes current state, like a schema migration, a new env var, a flipped architectural decision and so on - the relevant doc updates in the same change, before the ticket moves to `done/`. Otherwise the docs drift, stop being trustworthy, and you might as well not have them.

I read `CURRENT_STATE.md` whenever I come back to a project after a week off. The agent reads it whenever needed. Same file, both audiences, both have amnesia 🤡. Worth it.

## Not Jira, And That's the Point

Everything above only works because the system stops below the threshold where the ticketing itself starts to feel like a job. There are no priorities to compute, no story points, no scrum master, no swim lanes, no sprints, no approvals, no fields-you-forgot-to-fill-in that block the save. It's simple. It's markdown files in a folder. The agent writes it. The agent updates it. The agent moves it when the work is done. If the file is good, the next agent can read it and act on it. If the file is bad - you annoy the agent and the agent rewrites it. That is the whole loop.

The reason heavyweight ticketing systems fail in agent workflows is not capability , but friction. An agent will not log a finding if logging a finding takes seven clicks and a dropdown menu, and a human will not log it either, which is how every ticketing project I have ever joined ends up with three real tickets and a mystery backlog. An agent will, however, write a structured markdown file all day, because writing structured markdown files is what agents do anyway. The job becomes documentation by default, which is the only kind of documentation that actually survives.

## Try It

\-> [GitLab source](https://gitlab.com/arturnmk/ai-task-manager?ref=technikatsu.com).

\-> [GitLab Webpage](https://arturnmk.gitlab.io/ai-task-manager/?ref=technikatsu.com).

MIT with an attribution addendum. macOS desktop release is up. Linux and Windows build from source until I find will to package them. Drop the SKILL.md into any project/agnet and hand the agent one sentence: *"set up the ai-agent-workflow."* The whole structure scaffolds itself.

If you've also been explaining the same thing to your agent twice, this might help. If not - deleting one folder is not that hard.
### The Case for Boring Infrastructure
URL: https://technikatsu.com/the-case-for-boring-infrastructure/
Last updated: 2026-05-16T12:07:23.000Z
I default to a VPS. Not because I'm old-fashioned. Because I like to understand what I'm running.

A VPS, a reverse proxy, a database I actually know, logs I can read, a deploy script I wrote. That's usually the whole stack. I can SSH in, poke around, fix things, move things, and understand the full chain from domain to database. That's not primitive. Or *is* primitive. It's however I need/want it to be. That's the point. I can even migrate the whole thing to another provider in a single day, maybe less.

The industry somehow decided this is embarrassing. That simple infrastructure is for beginners and distributed complexity is for serious engineers. I **disagree**. I've seen pre-revenue products split across a frontend platform, a managed database, third-party auth, a queue, a storage bucket, a serverless layer, an observability tool, and a billing integration before a single real user showed up. When something breaks in that setup, you open seven dashboards from six providers and start guessing. The status page says green. Users can't even say, because you probably forgot to route something.

Every service you add is a new attack surface, a new pricing model, a new failure mode, and another thing that can change while you were asleep. Dependencies should earn their place.

There's also a bonus: AI tooling actually works well on a boring stack. When everything lives on one machine, an AI assistant can SSH in, read logs, inspect configs, and understand what's happening. It can actually help. Spread the same app across eight providers with eight auth models and eight APIs and your AI assistant is just reading dashboards with you. Equally useless. I don't mean "unleash AI to do magic" - I mean AI as a helper. If AI can make sense of the setup - so do you.

Use cloud when it clearly solves your problem. Spiky workloads, global latency requirements, compliance needs. All those reasons are real and more reasons exist and VPS really might be wrong pick in those cases. But "it looks better on a CV" is not a reason. And neither is "that's what serious engineers do". 

The app might run on a Raspberry Pi hidden in a gym closet on public wifi for all I care, as long as the user is happy when he is using the app and does not experience any issues.

Most small products die because nobody wanted them, or the founder burned out. I don't know a single one that died because it ran on a VPS.

And if your app can't survive a basic server setup then no amount of infrastructure will save it. You can't Kubernetes your way out of bad engineering. You can only make it more expensive.
### Why I’m STILL Done with Windows for Software Development - TL;DR edition
URL: https://technikatsu.com/why-im-still-done-with-windows-for-software-development-tl-dr-edition/
Last updated: 2025-11-07T11:27:20.000Z
## 

Call this "part 2" or just the *“I-send-this-when-someone-says-Windows-is-fine-for-devs”*edition. Old long post is [here](https://technikatsu.com/windows-vs-linux-vs-mac/).

### Easy shots

- **Corpo bloat:** macOS & Linux handle corporate bloat gracefully. Windows somehow manages to fight itself into lags
- **Builds:** Same hardware. Same IDE. Same IntelliJ version. Same Java version. Same corporate junk (Defender, Edge, compliance agents). Same project. *Linux build times were almost 2× faster than Windows.* That's not an "illusive feeling" - that's a *clear measurable difference*
- **Apple:** M-series chips feels like witchcraft. Absurdly good
- **Battery:** 3–4 h on a Windows 11 “ultra” laptop vs a full day (or more) on MacBook
- **Responsiveness:** Linux & macOS stay smooth; Windows lags through context switches and UI animations
- **Tools:** most modern dev stacks *are* Linux-native. On Windows, you end up using WSL. Basically Linux inside Windows
- **WSL:** if you need to emulate Linux just to get work done… maybe just use Linux?
- **Recent updates:** Windows 11 managed to *break localhost*, *disable recovery tools*, and *lock out USB input* in its own recovery mode. Fun! 🤡
- **PowerShell vs Bash:** nice *try*, but GNU tools are still superior
- **Privacy:** No comment needed 😶
- **Price**: Generous-spec MacBook costs +/- same as the balls-to-the-wall Dell you can buy. Or, you know, install Linux on it...

I have many, *many* other points, about resources management, but the objectively fell more like nitpicks and opinions rather than objective truth.

I tried to like it. I really did. I spent a year with it at work. But with the new MS direction there's nothing left to like...

- If your OS update can break *localhost*, you’re fighting your toolchain rather than developing
- On Linux/macOS you don’t get this same level of OS-layer sabotage (especially when you control your stack)
- For dev machines, you want predictability and speed, not "surprise update broke my workspace" before the deployment day

macOS = polished + when you need corpo software (looking at you, *Citrix*).  
Linux = total control of your workflows.  
Windows 11 = a 25-year-old car with a tablet duct-taped to the dash and a dashboard light that says "Restart Required" and new update just makes steering wheel disappear.

Can you work on Windows 11? Yes. But *why* would you do that to yourself? Who hurt you?

I still stand with my opinion: Windows 11 is ClownOS, MacOS (in combo with M chips) is better; and Linux can be whatever you want it to be.
### When "Pro" Means "Please Replace Often"
URL: https://technikatsu.com/when-pro-means-please-replace-often-samsung-990-pro/
Last updated: 2026-01-14T11:42:32.000Z
*(or reboot, whichever happens first.)*

I’ve been running a few small servers at home for years. Nothing fancy - just a few Docker containers here and there. You know, the usual *"it’s not production but it kinda is"* setup.

For the longest time, my main server ran on a completely **generic OEM SK Hynix NVMe.** I pulled straight out of a laptop. I don't remember when and from where, probably HP Envy laptop. No fancy label on SSD, no heatsinks, no "gaming-grade" marketing. I'm not sure if it even has a promo page. Just a quiet, boring piece of silicon that was actually working on for nearly **five years of 24/7 uptime** **without a single hiccup.**

Then, one day, I thought: *hey, maybe it’s time to upgrade*. I mean, I did rebuilt my server - finally threw away the ancient RAID card in favor of ZFS, rearranged some drives. So I though if I have to reinstall everything anyway - might as well to upgrade the SSD and dedicate the *only* NVMe slot to docker containers apps data. 

BEHOLD! The **Samsung 990 Pro** \- the flagship of consumer NVMe drives.  
PCIe 4.0, absurd speeds, "pro" in name. The whole package. Should be good.

And for about two weeks, it *was* great.

Then "the greatness" became **read-only**. And then - complete controller self-defense panic. 

I’m not even exaggerating. Every couple of weeks, the controller would just give up on life and flip the disk into "nah, you can only read now" mode. Docker apps froze, logs *screamed*, and my faith in Samsung's QA department was gone.

Checked SMART values. Tried mounting it back somehow. Tried updating firmware - I was running the latest. 

Nothing helped, except the full power-off and reboot. The moment it had to actually *work* \- write logs, handle containers, do something other than idle benchmarks - it would die again. Roughly every two weeks.

So, naturally, I did what any responsible person would: **shredded partitions and sent it back**.

Whether it still boots now, I honestly don’t know or care.

In its place now beats the heart of a true legend: **Seagate FireCuda 530R**. I've been running the Seagate FireCuda 530 (without "R") on another PC for a few years now -  
no crashes, no firmware crises, even handles absolutely degenerate-level swap abuse. No "pro" label trying to compensate for something. I mean, yeah, it has *heavy* gaming marketing, but specs are *absurdly* good.

 The idea is - it's the kind of drive that actually deserves to be left running for months without supervision.

And for the linux OS drive? It’s currently spinning happily on **Goodram** something-something **SATA SSD**.

It's SATA. It's boring. It's blue... I think. I'm not even sure how it's called... No, I'm not roasting it - it works. It works *flawlessly*. And I value that.

Sometimes, *boring* is the ultimate upgrade.
### AI Didn’t Ruin Tech. The Tourists Did
URL: https://technikatsu.com/ai-didnt-ruin-tech-the-tourists-did/
Last updated: 2025-10-09T11:16:27.000Z
You know what? I miss when tech was *quiet*. 

Not "boring". Just *quiet*. You’d sit down, open your IDE, maybe browse a few blogs or forums, tinker with some open-source repo. It felt like a craft: like carving wood, or doing art, in a way.

Now? It’s a circus 🤡 Every second person is an "AI visionary." Every second news post is someone explaining ChatGPT like they discovered a fucking fire for the first time. Every third app suddenly "powered by GPT." And every fourth post on LinkedIn sounds like it was generated *by* AI about AI.

It’s not the tech that ruined it. It’s the "tourists". The ones who didn’t want to *build* anything, but just *belong* to the hype. They came in, sold their "10-minute prompt mastery" courses, and left behind more noise and trash than Stack Overflow’s dark mode petitions.

Before AI, the bar was rather high. You actually had to *know* things*.* Now the bar is buried somewhere under a pile of clickbait thumbnails and "Top 10 AI Tools That Will Replace Developers" videos.

And corporations? Oh, they smelled the blood instantly. I bet Microsoft’s out here is reviving Notepad just to add AI copilots to it. Google is injecting "AI summaries" into your search, gmail, notes, now having an "actual" reason to read your data. And half the startups are basically: "Hey, what if we made an AI that generates *worse* content, but faster?"

But here’s the funny part, the hypocrisy.

I use AI every day. It *is* useful. Hell, I’m literally speaking about AI at the **BuildStuff conference** this year. Yes, as a speaker, hah.

So maybe I’m part of the problem too?

Or maybe I’m just trying to build something *real* with it, not just another hype machine?

Hard to tell anymore, isn’t it?

Because that’s what it’s turned tech into: a dopamine economy. People don’t *learn* now, they *refresh* the promt, page, see different things*.* They don’t *create*, they *generate.* Everyone’s chasing the next tiny high of dopamine rush and AI is now here to provide it.

Meanwhile, those of us who actually *live* in tech are just trying to hear ourselves *think*. We didn’t come here for the noise. We came here because we liked the *craft.*

Soo no, AI didn’t ruin tech. It just showed up, and suddenly the cozy village turned into a neon-lit circus. Every corner now has a "visionary" screaming about "the future". Some of them are right, meanwhile others are just the "town idiots".

And I’m still here, quietly "soldering" things together in my "village-that-became-a-circus" while the tourists chase their next dopamine hit.
### The Day My ISP Disappeared from the Internet
URL: https://technikatsu.com/the-day-my-isp-disappeared-from-the-internet/
Last updated: 2025-05-29T19:59:30.000Z
## You Can’t Ping Me If I Don’t Exist

It started with a simple Facebook post.

Someone from our apartment building’s group chat mentioned that their internet was down. I was working from the office that day and casually checked my own self-hosted services. Nothing loaded. So I did what every normal person does in this situation: opened a terminal and started pinging my home server.

Nothing. Not even a timeout.

And so began the *"digital forensics expedition"*.

## Hello? Is Anyone Out There?

I couldn’t reach anything at home - not my IP, not my self-hosted domains, not even basic ping replies. So I did some DNS checks. `dig myispdomain.com` returned... *nothing*. `ping ns1.myispdomain.com` and `ns2.myispdomain.com`? Also dead.

I even did a traceroute to their DNS IPs - and saw it also lying on its back right near their whole network. Something ***big*** was broken.

Facebook groups and tech chats started lighting up with people confirming: the ISP was down. Entire chunks of Lithuania’s internet went dark.

## Something, Somewhere, Somehow

While the provider never gave a full technical explanation (at least at the moment of writing this), I completed my "autopsy without a body" and here’s where 2+2 led me:

- Both authoritative DNS servers became unreachable.
- Their WHOIS-listed contact email didn’t even exist.
- Routing to customer IPs failed - traceroutes dropped mid-way.
- Their phone support line was unreachable.
- Their website was also down for hours.
- Basically, every part of their "contact us" plan relied on a working network. That's... brave, I guess.

It was a *full-blown infrastructure collapse* \- so deep that they *couldn't* even imform their own clients about it. Their client management system, phones, and communication channels were all tied to the same internal network that went down.

### This Is My Hobby Now, I Guess

As the hours dragged on, I:

- Wrote a bash script to continuously ping my home domain and log the results.
- Notified the registrar before realizing the ISP hosts their own DNS.
- Ran WHOIS on IP blocks and found real human contacts.
- Even emailed them about their broken WHOIS email and the ongoing outage (*the irony*).

I had the bash script running non-stop *from my phone,* logging every heartbeat (more of a flatline tough) all day and thought the night. 

The next day, the WHOIS entry was updated with a proper contact. They replied to my technical email, thanked me for my observations, and explained they were dealing with a massive outage. Although my email was clearly late to the party yesterday 😅

### Facebook Became the Helpdesk Now

The ISP's Facebook became the emergency status page. Some highlights:

> *“\[...\] This includes internet, phone, and surveillance systems. We’ve lost access for over five hours and no one is answering your phones.”*  
> — A frustrated business client

> *“Phones aren’t turned off — they just don’t work, because they also rely on internet.”*  
> — ISP representative on Facebook

> *“First thought: maybe they went bankrupt 😅”*  
> — A concerned user

> *“This is the first time in the company’s history we’re experiencing a failure of this scale.”*  
> — ISP support representative

They didn’t just lose internet service - they lost their own ability to communicate that service was lost. It’s like your fire alarm and fire extinguisher being on fire, ugh...

This wasn’t just a network hiccup - this was a *total and real infrastructure collapse*.

### It’s Alive! Wait, Nope.

Late in the evening, I got a single:

`Ping successful!`

...and then it was gone again.

Looks like they were rebooting their systems, testing routes, and slowly bringing things back online. The poor support team must have answered hundreds of emails with the same copy-paste.

### Everything Worked, Except the Part That Didn’t

And that part just happened to be the *Internet*. Yeah, I am self-hosting some stuff, but nothing mission-critical broke for me, but it was a reminder of how much self-host can rely on one ISP:

- ❌ My services were LAN-only
- ❌ VPN access was gone
- ❌ My blog was down
- ❌ A small site I host for someone else was also offline

That said, my local "intranet" still worked - I could watch movies, access documents, and use my services locally across devices. This is one of the reasons I self-host :) The world can fall apart, but inside my tiny bubble - everything still runs.

### The Return (Mostly)

At exactly **08:21:48**, after nearly 20 hours of complete silence, the first successful ping came through! 

For a few minutes, everything was up. Then it started to act drunk - momentary drops, failed pings, websites timing out. Eventually, around **08:30**, things stabilized for good.

Watching "Ping successful!" repeat in my terminal window felt like a small personal victory. I already half-ready to drive to the office for work, and now I could enjoy my day of WFH. I was rooting for my ISP the whole time 😄

### Final Thoughts

To be fair, this provider had always been reliable before this. This was their first major outage in years. But it was also a reminder of just how fragile internet infrastructure really is.

Even DNS, phones, websites - they all rely on the same critical infrastructure. And when that goes down? Everything goes.

I didn’t ask for a refund or a discount. Honestly, I felt kinda bad for them - they’ll need every euro they can get to recover from this one. Imagine the B2B hell they're going through right now - how *many* SLA have they broke. Hope they won't go bankrupt from SLA contract compensations...

Until next outage.
### Fixing DaVinci Resolve Keyboard Input on KDE Wayland (Without Switching to X11)
URL: https://technikatsu.com/fixing-davinci-resolve-keyboard-input-on-kde-wayland-without-switching-to-x11/
Last updated: 2025-05-18T20:58:42.000Z
Let me guess your issue: you've launched Resolve and...

- You can’t type in the project name
- Spacebar, Backspace, Delete do nothing
- Only single-letter hotkeys like A/B works

You're not alone! And there is the fix for that.

## The Cause

DaVinci Resolve uses its own Qt-based UI toolkit. On Wayland, KDE’s Global AppMenu system (`kded6 module: appmenu`) intercepts Qt’s input handling and it breaks Resolve in this weird way.

This doesn’t happen on X11, switching to which is the most common fix you will find online. And it doesn’t happen if you disable the appmenu, if you want to stick with Wayland.

For me it all happened under Nobara 42, I guess same with Fedora. And, maybe, any KDE DE. 

## The Fix

The 90% of the fix was found [there](https://forum.endeavouros.com/t/davinci-resolve-no-keyboard-shortcuts/60983/5?ref=technikatsu.com), on Endeavour OS forum. I just made it work in a more "elegant" way.

Basically, the fix wraps Resolve in a "launcher" script that:

1. Temporarily disables the `appmenu` module
2. Launches DaVinci Resolve
3. Re-enables the `appmenu` when Resolve exits

## The Actual Steps To Fix

Anyway, I suspect you don't really care about all this, so here are the steps to fix it:

### Create the wrapper script

Create the wrapper script and put it somewhere, for example your home folder:

`nano ~/resolve-fix.sh`

```bash
#!/bin/bash

# Disable KDE Global AppMenu
qdbus org.kde.kded6 /kded org.kde.kded6.unloadModule "appmenu"

# Launch DaVinci Resolve
/opt/resolve/bin/resolve

# Re-enable AppMenu module when Resolve closes
qdbus org.kde.kded6 /kded org.kde.kded6.loadModule "appmenu"

```

*Note: check the path of the Resolve on your system!* *In my case under Nobara is was* 

`/usr/bin/davinci-resolve`

Make that script executable:

`chmod +x ~/resolve-fix.sh`

### Update the desktop launcher

Edit the shortcut using nano, or Kate, or whatever you prefer and put the script under `Exec=`

Example of full shortcut:

```text
[Desktop Entry]
Comment[en_US]=Revolutionary new tools for editing, visual effects, color correction and professional audio post production, all in a single application!
Comment=Revolutionary new tools for editing, visual effects, color correction and professional audio post production, all in a single application!
Exec=/home/YOURUSERNAME/resolve-fix.sh %U
GenericName[en_US]=DaVinci Resolve
GenericName=DaVinci Resolve
Icon=/opt/resolve/graphics/DV_Resolve.png
MimeType=application/x-resolveproj;
Name[en_US]=DaVinci Resolve
Name=DaVinci Resolve
Path=/opt/resolve/
PrefersNonDefaultGPU=false
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
Version=1.0
X-KDE-SubstituteUID=false
X-KDE-Username=

```

Then reload your app menu if starting DaVinci Resolve from there. If it's a desktop shortcut - just double click as usual.

## Notes

- You’re still on **Wayland,** no need to switch to X11.
- Appmenu will work again for other apps after Resolve closes.
- No weird hacks. Just telling KDE to chill for a bit.

## Why This Works

The bug isn’t in Resolve or your keyboard - it’s in how **Qt apps behave under Wayland when KDE’s global menu system is there too**... This is one of those weird edge cases no one documents, but once you know what breaks it, it’s easy to patch. So, that's it. Hopefully Wayland support AND Resolve Linux support will continue to improve and we won't have to search for these fixes anymore...

But if you've searched for this - check out this blog and, maybe, consider subscribing ;)
### Real-Life Consequences of Bad UX
URL: https://technikatsu.com/bad-ux-colorblind/
Last updated: 2025-05-17T23:59:08.000Z
Do you ever stare at a map in a car-sharing app and think, "Umm, why does this whole area look… the *same*?"

Yeah. That happened.

Turns out, I’m *slightly* colorblind. I found out relatively recently - roughly a year and a half ago. Never had a *problem* with colors before in my life that could actually affect something. Never used any colorblind mode in games or apps. But apparently, I struggle to tell apart low-saturation greens and reds - they all look like barely different grey to me. You know, all those colors designers love using to indicate important things like "park here" or "you will get fined here." Soo I got a bit "lost" when I rented a car using a local car-sharing app. 

They have a map showing the "allowed" parking zone in a greenish grey, and the "not allowed" area in a regular grey. To me they both looked… well, grey.

The only zone I could clearly tell was the bright red “you can't park here under any circumstances” - thanks, at least, for that... 

But everything else - who knows? A grey blob.

I spent 20 minutes driving around trying to figure out where the hell I was allowed to park. Couldn’t tell - grey blob. But for some reason one area of grey blob punishes me for leaving car there and other area of grey blob is fine.

Ended up parking next to another car from the same service - and that's how I accidentally found the "parking allowed" zone.

Later, at home, I increased my OLED screen brightness to max, opened my eyes as wide as I could (to *really* absorb *all* those photons), and finally saw it - the "no parking" zone is *slightly* warmer grey and the "parking" zone is *sliiiighlty* green-ish. No way to tell apart by just glancing at a phone while driving though.

Dear designers of this app: go to hell. Color is not enough.

If you rely *only* on subtle color differences to provide critical functionality, you're actively punishing users with colorblindness. And not just them - anyone in sunlight, low brightness, or on a low-quality screen won't see it too.

Some free to use UI ideas:

- Bold outlines with more saturation
- Text labels
- Pattern overlays

Or, if you want too keep those shades of grey for majority of users, imagine this: color blind mode.

It’s not hard. It’s just often… forgotten. Never thought that *I* would be the one shouting into the void about colorblindness, but now when I actually paid with time and money because of this... I have a valid reason.

Lesson learned, I guess? I’m not dumb. The design was.
### A Single Picture Saved Our Project. Literally.
URL: https://technikatsu.com/a-single-picture-saved-our-project-literally/
Last updated: 2025-04-06T21:02:16.000Z
We were deep into building a new microservice — one of those projects where the requirements were abstract, shifting, and open to interpretation. You know how it goes: "It's just a simple microservice, basically it should just save X and communicate Y back". *Yeah, right...*

At first, it felt manageable. Everyone, including me, nodded along in meetings. But slowly, assumptions started to differ. One teammate thought of the flow one way, someone else committed their understanding of data model, then we discovered some corner cases and new requirements popped up and then there were c*onflicting requirements* and so on...

By the time we were halfway through implementation, we realized we weren’t building the same thing. We weren’t even on the same map. *How* it should even work?

So I did something simple, yet useful.

I drew a flow diagram. Just boxes and arrows. Good old draw.io. Exported it to a PNG and shared it with the team.

That one diagram turned into our anchor, that single source of truth we didn't had before.

We reviewed it with the team and the business people. For the first time, everyone saw the same picture (pun **intended**). From that point on, it became the go-to reference for everything – requirements, scope clarification, even naming decisions.

*Suddenly*, we were able to:

- Add *meaningful* tickets to Jira
- Update the DB model based on real scenarios
- Point to specific parts of the diagram and say, “What happens *here*?”
- Make decisions faster and with more confidence

It was like handing out a map in the middle of unfamiliar city. People stopped guessing where they were and started moving in the same direction.

### The Lesson (Re-)Learned

If things feel vague, confusing, or open to misinterpretation – **draw something**. Even a napkin doodle can go a long way. A visual representation of a process or system can align people faster than 10 Jira tickets with a single sentence of "acceptance criteria" or the 10th recurring Teams call this week.

It doesn’t even have to be pretty, or follow UML rules. It just has to *exist*.

Who knows what we would’ve ended up building without that diagram?..
### What Being a Senior Developer Is Actually Like
URL: https://technikatsu.com/what-being-a-senior-developer-is-actually-like/
Last updated: 2025-03-29T15:42:35.000Z
So, you finally made it to Senior Developer? Nice. 🎉 Now, let’s talk about what that *actually* means – because it’s not just about writing more code all day.

Nobody really prepares you for this, but being a senior dev is less about writing all the code and more about influence, problem-solving, and leadership. I mean, not in a "dictatorship" way, but from experience and expertise point of view. Here are five things I learned along way – and you probably will too.

## Congratulations, You’re Now the Adult in the Room

That junior dev struggling with the codebase? That Jira task with no requirements? Flow does not make sense? That time when people are too polite to say, "This is a terrible idea"? Yeah, that’s on you now.

As a senior, your job isn’t just delivering code. It’s making sure the team doesn’t drive off a cliff. That means raising concerns, pushing back when needed, and sometimes being the one to bring bad (or good!) news up the chain.

If you see disaster coming, don’t just watch – say something.

## Writing Code Isn’t the Most Important Thing You Do

You probably got here because you were a great coder. But now? Your job isn’t just to write code – it’s to make sure the *right* code gets written.

Most of your time will go into reviewing, refactoring, and stopping bad code from making it to production. Some days, your biggest achievement won’t be writing a brilliant feature – it’ll be preventing someone from turning a simple task into an over-engineered spaghetti.

And when deadlines are tight? You’ll have to know where to cut corners without setting the team up for disaster later. Being senior isn’t about perfection – it’s about knowing what actually matters and making smart trade-offs.

## Do As I Do – Unless I’m Tired, Then Don’t

You can’t expect the team to care about best practices, testing, documentation, or maintainability if *you* don’t.

- If you cut corners, the team will too.
- If you ignore processes, people will follow your lead.
- If you complain about problems but don’t act – nothing changes.

Want a strong team? Be the standard. Document things properly, review PRs thoroughly, encourage good habits. If you show that you care, others will too (hopefully).

## You’ll Be "The Guy" (Even When You Don't Want To Be)

CI/CD pipeline broken? You might have to fix it. Need a new database schema? Guess who’s designing it. A greenfield microservice with vague requirements? That’s your problem now.

Oh, and sometimes you’ll have to jump into *insert\_tech\_name\_here* even if you hate it. Or translate business requirements that barely make sense into something actionable. Because *that’s* what being senior means: stepping up and doing what needs to be done – even if you didn’t sign up for it.  
  
There’s no more saying, “That’s not my job”. It *is* your job. Your job is whatever needs to be done, and you’ll be good at it (well, most of the time).

## You Wanted a Promotion, Not a Personality Split

At this level, you don’t just write code – you *think* beyond it. Your day will include multiple role "cosplaying":

- **Developer** – Still coding, but focusing on the critical parts.
- **Architect** – Making high-level design decisions.
- **Analyst** – Figuring out business requirements before they turn into tech debt.
- **Mentor** – Helping juniors and guiding the team.
- **Wildcard** – Because, surprise! You’ll sometimes have to do things that aren’t even remotely related to your exact job description.

The higher you go in ranks, the more your *soft skills* start to matter. Communicating trade-offs, managing expectations, understanding business needs – these are just as important as writing efficient code.

## TL;DR: Senior ≠ Just More Code

Being a senior dev isn’t about shipping features faster. It’s about:

✅ Stepping up when things go sideways.  
✅ Making good decisions (and helping others do the same).  
✅ Taking ownership beyond just your assigned tasks.  
✅ Knowing when to push for quality and when to ship fast.

At least, that’s been my experience. Yours might be different, but I’d bet most senior devs will relate.
### Simplicity Is Harder Than It Looks 💡
URL: https://technikatsu.com/simplicity-is-harder-than-it-looks/
Last updated: 2025-01-24T14:50:23.000Z
In tech, it’s easy to confuse complexity with progress. Adding layers, abstractions, or extra features can feel like you’re being productive—sometimes even impressive—like you're building something substantial. We’ve all seen codebases and systems that seem to wear their complexity as a badge of honor. 👨‍💻

But here’s the truth: It’s for sure easier to *keep adding more*. It takes less effort to build upon a bloated foundation than to *step back* and challenge yourself to simplify.

Yet, simplicity isn’t about stripping everything to the bone at all costs. Go too far, and you risk creating a *new* kind of complexity—one born from *oversimplification*. A system reduced beyond its functional core might sacrifice necessary flexibility, clarity, or performance, and in doing so, create more problems than it solves.

### **The Complexity Trap: Why Do We Fall for It?**

1. **Perception of Value** – Complex solutions can look sophisticated. Teams, clients, or developers themselves often relate complexity with expertise.
2. **Short-Term Productivity** – Adding new code feels faster than refactoring or rethinking an existing design. It’s immediate, visible progress.
3. **Fear of Missing Out** – “What if we need this later?” leads to unnecessary features, dependencies, and integrations.
4. **The Oversimplification Paradox** – And the other way around – in the pursuit of minimalism, we sometimes strip out essentials. An overly barebones solution can become fragile, unscalable, or confusing to others trying to extend or even understand it.

### **Finding the Balance: Simplicity Done Right**

True simplicity is about **balance**. It’s about making deliberate, thoughtful choices to solve the problem *well*—without excess, but also without sabotage. Real skill lies in:  
✅ **Code that’s clean, readable, and maintainable** – Simple doesn’t mean cryptic or hacky. Clarity always wins.  
✅ **Systems that are elegant and scalable** – Removing bloat without compromising adaptability.  
✅ **Solutions that are focused and purpose-driven** – Simplified to their essence, not stripped to dysfunction. You don't need a bloated stack for a tiny app.

Simplicity done right:

- **Avoids unnecessary bloat**
- **Retains necessary flexibility**
- **Balances minimalism with real-world needs**

Simplicity done *wrong*? That’s when you tear something down so much that its purpose or future growth is compromised. Oversimplifying a problem can lead to technical debt, unclear intent, barely readable or understandable and brittle systems that break under pressure.

### **Navigating Simplicity in Action**

Here’s how to aim for the sweet spot:

- **Ask “What’s Essential?”** – What’s the simplest way to solve the problem without losing necessary functionality or extensibility?
- **Refactor Thoughtfully:** Simplicity isn’t always immediate—it’s often the result of revisiting and refining your work.
- **Balance Clarity and Brevity:** Don’t over-optimize for “fewer lines of code.” Code should be *simple to read* as much as it’s simple to write.
- **Avoid Premature Minimalism:** If a feature or design element truly solves a problem, it belongs there. Removing it just to appear simple is counterproductive.

### **The Litmus Test**

Before finalizing a solution, ask yourself:  
**“Can this be simpler *without breaking anything*?”**

If simplifying removes something critical—like flexibility, readability, or robustness—it’s not simplicity. It’s sabotage.

### Cut the Fat, Not the Muscle

True simplicity doesn’t mean taking shortcuts or creating fragility. It’s about understanding the problem deeply enough to **remove the unnecessary while keeping the essential**. It’s hard work—but the reward is worth it. Simple solutions are adaptable, maintainable, and built to last.

> **"Simplicity is the ultimate sophistication."**  
> — *Leonardo da Vinci*

Just remember: *Take away too much, and you might lose the very thing that makes your solution work.*
### The Art of Debugging: A Developer’s Detective Story
URL: https://technikatsu.com/software-debug/
Last updated: 2026-07-26T15:07:54.000Z
Debugging. Well, it's not exactly the most shiny side of programming, is it? No boot camp is advertising with "Learn programming from us, so you could debug an app in just a week!". Usually there’s no standing ovation when you fix a bug that’s been introduced in development and wasn't even shipped to production yet. No applause when you find and fix that particular case, that wrong condition, proxy server, or whatever else. But for some of us there’s a weird satisfaction in playing the role of detective in the world of code.

Yep, I think debugging is quite fun and I even like it.

---

#### Debugging: A Scene Out of a Detective Novel

Picture this: You’re at your desk. Surrounded by thousands of log lines, error messages are screaming at you in red, and your application feels more like an uncooperative witness (maybe even a little insane one), rather than a piece of software. Debugging is a lot like stepping into a classic detective novel, but instead of suspects, you’ve got variables, servers, and conditions.

The process starts with clues. Logs are your eyewitnesses—details that might help paint the picture of what went wrong. Stack traces? They’re your cryptic maps, pointing you to a general area but rarely giving you a precise location. Variables are your suspects, their values shifting under interrogation as you step through the code. Sometimes they’re guilty, sometimes they’re just in the wrong place at the wrong time. And the conditions? Oh, they’re the plot twist no one saw coming.

You start reading code lines, one after another. A variable isn’t what you expected? Trace its journey. A function is misbehaving? Step through it line by line. The logs aren’t clear? Add more, add classic "I'M HERE" everywhere, and run the case again. It’s a game of cause and effect, of “changing stuff and seeing what happens” scenarios, until finally, you land on the culprit. Sometimes it’s a simple fix— flip a boolean, wrong operator, missed validation. Other times, it’s deeper: a misconfigured server or policy, an unexpected edge case, or something hidden in third-party site. It's not rare when you get totally stuck and have to take a step back with a broader picture in mind. You spend hours, days, weeks, finding the murderer in this detective novel.

---

### The Employer’s Perspective: Why Is It Taking So Long?

From the outside looking in, debugging can seem... inefficient, to say the least. Time goes by, and there’s no new features, no *visible* progress, just you, head down, running tests and checking logs again and again and again. For employers or managers focused on Jira metrics and deadlines, it’s natural to wonder: *Why is this taking so long?* No, your programmers are not dumb or slacking. Debugging takes time.

Debugging isn’t just about fixing the immediate issue. Sure, the end goal is to fix the bug, but the journey to get there is what really matters (not poetically) and takes most of the time. Almost every debug session is an exploration, especially in a large project. You’re learning how the system behaves under different conditions, uncovering edge cases, and gaining insights into the codebase’s strengths and weaknesses. It’s like diagnosing an illness. The symptoms give you hints, but you need to dig deeper into the system to understand the underlying cause and prescribe the right fix.

What might look like “wasted time” is actually an investment. The knowledge gained during debugging doesn’t just makes today’s problem go away — it prepares the team for tomorrow’s challenges. It uncovers flaws in the code or infrastructure before they become major issues and ensures that the software is well-written and will handle or avoid similar problems in the future.

I get it. Time is a valuable resource, and debugging doesn’t always feel like forward momentum. Sometimes I even feel guilty during daily stand-ups: days go by and for n-th day in a row I'm saying the same thing - "Yep, I'm still on this bug." But I think I'm right: it’s better to spend time solving problems now than dealing with a production outage or business stopping behavior later.

---

#### Why Debugging Is Actually Fun (For me, at least)

As I said - I quite enjoy debugging. I know, — some of you already facepalmed so hard your face hurts. But wait, hear me out. Obviously, not always, but there’s a weird kind of enjoyment in taming the chaos. You start with a mess—a broken feature, an unrelated error message, or worse, *silence* — and end with a *solution*. It’s like solving a mystery, except the culprit isn’t some sketchy figure in a trench coat; most likely it’s you or other member of a team from three months ago. But it's not the fix that brings joy: once you know what to do - it's easy. It's f*inding the cause*, the process of tracing the symptom up to it's origin, bringing these puzzle pieces together - that's what I like about this process.

Debugging forces you to slow down and *think*. It’s not about rushing to a solution; it’s about understanding the problem. And when you finally solve it? Feels good.

Of course, not everyone shares this enthusiasm. For some, debugging is a chore—a hateful blocker in the way of writing new exciting code and baking features. And that’s fine. Every developer has their preferences. But for those of us who likes solving puzzles, debugging is where the magic happens, when you feel like a detective on a case.

---

#### So What Now?

Soooo, the outcome, I guess:

1. **Code with empathy.** Think about the developer (maybe even *future you*) who will have to debug your work. No, you won't remember a thing. Leave clues— meaningful variable names, good logging and structure, make it readable.
2. **Be patient.** The problem isn’t always where it seems. Sometimes you have to dig deeper, question your assumptions, grab a colleague and follow the trail wherever it leads.
3. **It's a CV hack.** Weirdly enough, when I'm being asked, "how do you feel about fixing bugs in this huge app written 5 years ago" and they hear "I like it and I'm good at it" — it's a powerful point. They raise their eyebrow, but still I get a respect point.

---

#### You're a Detective, Harry

Debugging isn’t just a task on your to-do list; it’s a skill. It’s a mindset. And yes, sometimes, it can be fun. So the next time you find yourself with a huge log file, tracking down an elusive bug, remember: you’re not just a developer. You’re a detective, solving this case.

You've most likely have heard of a "Rubber duck debugging"; I also suggest "Debugging fedora", lol.
### You Should Self-host And Here Is Why
URL: https://technikatsu.com/you-should-self-host-and-here-is-why/
Last updated: 2026-01-14T11:43:24.000Z
Subscriptions. Pay some big companies to take care of your data or to provide some kind of service. And it is OK to not do everything yourself. But it's not OK to not have a choice and to agree to every single thing service provider wants to do with your data. Although relying on third-party services has become the norm, there's an alternative to that. Self-hosting! It offers a compelling alternative that can enhance your technical skills, promote sustainability, and provide greater control over your data. Whether you're a student eager to learn or someone looking to reduce dependence on corporations, self-hosting presents numerous benefits worth considering.

### Your CV Will Thank You for This Lab Hack

Self-hosting is incredibly useful for students eager to break into the IT field. By setting up and managing their own servers, students can gain hands-on experience with networking, general problem solving and technologies like Docker, Linux and other essential tools used in the industry. It's a relatively easy and cheap way to learn – you can start with a Raspberry Pi or an old desktop PC. Even if you're living in a dorm room, a small "home lab" is very possible and is great project. It’s also a strong addition to your CV, showcasing your practical skills and genuine interest in IT to potential employers.

### No, You Don't Need Server Grade Equipment

If you ever been to /r/homelab, half of the posts looks like a fucking commercial data center. You don't need it. I mean, if you want it - you're welcome, but I have my homelab in the closet on a single shelf just above the brooms and I use mostly consumer grade hardware. Good quality, but still consumer grade. The entire price of my homelab is less than my single monthly salary and I use it every day without any inconveniences.

### Landfill or Home Lab? You Decide

Instead of sending old hardware to the landfill, why not repurpose it for self-hosting? This approach not only reduces electronic waste but also gives your old devices a new lease on life. By reusing outdated computers, you contribute to a more sustainable environment while also creating a valuable learning tool for yourself. For me it's a win-win: I get a cheap hardware and as a bonus get some eco karma points. Older hardware might not be as powerful, but unless it's required to run intensive tasks like AI or public servers, it will be fine. Just take a look at power consumption if you're planning to run it 24/7, since there's a difference between *being just slower* and *bad efficiency* in terms of performance/power.

### Your Data, Your Terms

Relying on your own services means less dependence on corporations. When you self-host, you have full control over *your* data, applications and get rid of some subscriptions. This independence can be empowering, allowing you to customize and optimize your setup exactly how you want it. You won’t have to worry about sudden changes in service terms or pricing from third-party providers. Although, depending on where you live, *with great power might come great power bill*.

### Host Yourself, Defend Yourself

However, self-hosting isn't without its challenges. If you plan to host public-facing services, you need to implement at least basic security measures to protect your setup from potential threats. This could involve setting up firewalls, using secure passwords, 2FA, regularly updating your software. Additionally, the proper functioning of your services might depend on your skills and knowledge. If you're not familiar with server maintenance, you might face some difficulties. I'm not trying to scare you, basic security is actually relatively easy. Most self-hosted services come with login screen or some kind of protection. Just don't cut *too many* corners when it comes to security. If app you're trying to expose to the public wants that cert and proper domain - consider doing it.

### Backup or Cry Later

Another downside is the risk of data loss. Without proper backups and data management practices, you could lose important information due to mistakes or hardware failures. It's mostly inevitable - some component *will* die. Maybe tomorrow, maybe in five years from now. Or you'll make a mistake. It's crucial to establish a reliable backup routine to mitigate this risk. So always have a backup of important data. **And make sure the backup actually works**. For example, I have a custom built NAS, that does backups to "normal" NAS which only turns on to receive a backup. And I'm thinking of adding a USB drive as a separate offline backup. Just in case something goes *very, very* wrong. One of the safest option is the classic 3-2-1 rule - meaning having *three* copies of your data, stored on *two* different devices, with *one* copy being stored off-site (not the same building).

### Summary

Despite the challenges and risk of being hacked ([yep, happened to me](https://technikatsu.com/one-of-my-websites-got-hacked/)), self-hosting is a rewarding experience that offers significant or, at least, some benefits. For students, it's a practical way to gain valuable skills and enhance their CVs. Repurposing old hardware is eco-friendly and cheap, and relying on your own services provides independence from corporate control. Worst case scenario you gain some skills and knowledge. Best case scenario you get something for yourself that you can actually use. While there are security and data management considerations, the learning and growth opportunities far outweigh the risks. If you're interested in IT and eager to learn, self-hosting is definitely worth time spent.
### Why I’m Done with Windows for Software Development (Unless Forced)
URL: https://technikatsu.com/windows-vs-linux-vs-mac/
Last updated: 2025-01-03T09:17:05.000Z
I'll start from far away. First, here's some background of mine. I work as a software engineer and consultant, I've finished university for software engineering. Mostly I work with back-end in Java and, occasionally, other languages. I like computers and I'm no stranger to how hardware works and I know how to fix hardware and software issues. Of course I'm a tech support for my family. That being said, there goes the saga of my OS journeys.

### Living with Windows, Loving Other OSes

I grew up using Windows. I'm relatively young, so the first Windows version that I have been really using is Windows XP. I've seen older Windows versions, but either I was too young to care or understand, or it was just to poke around the old software. So I've seen and lived through a bunch of Windows versions (including not so common versions like Windows CE on pocket devices). As a regular user, at home, Windows did it's job and was quite alright (up until Windows 11). As my skills evolved I shifted away from Windows to other OSes, just because I like them more. My friends and family use Windows, so I still have to interact with it and it's alright. For "power" user though, or with corporate additions, it's whole another flavor and it's not sweet. But more about that later down below. 

### MacOS: A Deal that Took Time to Appreciate

My first encounter with a MacOS was around year 2019\. I got a really good deal for 13" i7 16GB 2016 MacBook Pro with touch bar (idk how to distinguish MacBooks without stating the specs...). I didn't really needed it, but "It was a steal, not a deal" - that kind of a deal. I had almost no idea how MacOS works and it didn't really impress me back then. Intel based macs were hot, loud, and performance was average at best and the whole Mac device family was way overpriced comparing to Windows alternatives. MacBook became my secondary laptop while I primarily used my PC and another Windows/Linux laptop. I was occasionally using it, learning bit by bit how MacOS and ecosystem works. Over time, I've found my way around MacOS, and despite laptops age, I'm still using that MacBook in 2024\. Though it's about time for an upgrade.

### Torturing devices with Linux

Linux, on the other hand, has been my companion for quite a while. I've been experimenting with it since Ubuntu 14.04, often running some Linux distro alongside Windows in a dual-boot setup on same or separate drives. I graduated from university with a Linux Mint laptop because my old machine was too ancient to run Windows 10 decently (HDD times). I even ran Linux from a USB stick as the main drive for a few months xD. Poor USB drive though. It was overheating badly, but it was pretty usable (on par with HDD), unless I needed to copy or save large files or a LOT of data. Anyway, fast forward to 2022, I switched to Fedora as my main OS on my tower PC to dodge Windows 11.

### Coding in Peace, Please?

Now, to the software development part. For me, OS is mainly a tool, which should do it's job and be convenient and not *interfere* with what I'm trying to do. I've been working professionally on all 3 operating systems, staring my professional dev journey on Windows 10\. It was alright. I worked on Windows 10 for a couple of years. If Windows is not burdened with all the copro policies and constant checks running in the background, it can be quite good. The cheat is that I used it on a desktop work PC, not on a laptop. But later I've landed at a place where there was quite some corpo policies and rules, forbidding to do some things, forever auto-updating something, constantly requesting restarts and so on, and it was painful to deal with.

And I've quickly decided to run away to Linux. It was corpo modified version of Ubuntu, still with corpo policies and some restrictions (like sudo auth through company server and windows defender antivirus, lol), but it was so much *snappier, faster, non-intrusive* and I was *in control* of my workflow. The hardware resources management was better and I could do so much more natively, instead of using some 3rd party apps for everything. Windows fans might argue, that Power Shell is, in fact, powerful, but let's be honest, Linux terminals and their tools are just better. Even build times were noticeably faster comparing to Windows on the **same** laptop with **same** specs. All that happened on AMD Ryzen laptop that was given to me as an experiment before buying more AMD based systems into the company (it was great btw). Also I quite enjoyed spectating the clown fiesta of rolling out Windows 11, which was full of troubles and random issues. It was the golden time of colleague trolling every time they had another issue with Windows. The paradise ended when I encountered software incompatibility with client software (for fucks sake, *Citrix,* fix your shit). I tried everything I could, but despite my efforts, I had to abandon Linux and keep working.

I did not wanted to go back to Windows with all my heart and soul, so I was very happy when I was able to land my hands on a M1 MacBook Pro. And it was a *great* experience. Everything was *snappy, fast, non-intrusive*, I was *in control* of my workflow and the hardware resource management is great. Even with copro software that was managing the updates and a bunch of other stuff, it was silent and fast. Touchpad and gestures were so polished, I've forgot that I am carrying a mouse in my backpack. Battery life was amazing. Whole working day on a battery? No problem. I honestly enjoyed working on a Mac - there were little to none issues and I could still troll Windows colleagues with how slow and troubled their OS is. And almost all my bash scripts that I took from my Linux setup worked with little to none modifications. The heaven of smooth work continued until...

### Windows strikes again

Later I've changed jobs and company requirement is to use Windows and Windows only. Also, they have a partnership with Dell... Sorry, Dell, but it looks like you still don't know how to write good drivers for your own hardware. *Introducing the Wi-Fi Houdini: Now You See It, Now You Don’t; stay tuned for next trick, where we will make your audio disappear!* Why Wi-Fi can just un-exist itselft randomly? Not just from the task panel, it even disappears even from Device Manger... Every time I had to use Dell, there was noticeable amount of Dell-related issues. Material quality, build quality, drivers reliability, cooling solutions... Almost every time some friend asked me to help fix their laptop it's been Dell (coincidence?). Although this time I've got the (almost) *most expensive* Dell money can buy. And it's alright. Not on the MacBook level, but still quite decent. Allthough, "End" button sharing F12 and being accessible via FN makes "End" button unusable. You think I'm needy or entitled? "GiVe Me A mAcBooK" kind of guy? Nah, I'd work on a 1999 half-alive ThinkPad kind of laptop if it'd be suitable for work. This Dell is always hot, fans are always spinning. *CPU USAGE IS 8%, WHY ARE YOU HOT*??? Maybe I've just got used to the chill and silence of the MacBook Pro. But is it bad to get used to good things? But to be honest, except for being hot, drivers issues and a bit weird keyboard layout (copilot button, lol), I'd say it is a nice laptop.

This time I think it's Intel, who shat the bed. Not alone, Windows helped. I remind you, it's (almost) *the most expensive* Dell laptop. 64GB Ram, Intel ~~Core i~~ Ultra 9 185H, NVIDIA RTX and Intel NPU with a bunch of other bells and whistles. That's a decent specs salad for a powerful beast. But with Windows 11 and all the corpo policies it's *slow*, *not responsive, intrusive* and *limiting*. With lags, delays, bugs (like can't change the display brightness level after sleep), choppy animations, it hogs RAM like crazy and the battery life is just terrible. With medium usage such as teams calls, couple of app builds and staring at the code in between, it manages to die after 3-4 hours. Windows 11, as an OS, is pure disappointment for me. This time Dell did an alright job, but Windows 11 and all the corpo stuff are making it borderline unusable. For some reason Linux and MacOS can be just fine with heavy insertions (FROM MICROSOFT, I must note) of corpo antiviruses and other bloatware, but Windows can't handle it's own shit. Btw, I've found out that PowerToys can make life on Windows somewhat better. Some features *should* be already included in the main release.

### Hate Is a Strong Word

This turned out more of a rant and it might appear that I'm just a Windows hater, but it's not true. No, I'm not going to go into the whole data collection and privacy issues here, although, let's face it, it's a huge concern. Some people are fine with that, others not. OS is a tool that should be comfortable to use and match persons workflow and use cases. MacOS is much more polished and consistent. Linux is so flexible it can be anything you want it to be (although Linux is not so normal-person-friendly *yet*). But Windows... For normal people and basic daily usage on an adequate laptop/PC it's honestly fine. Most normal people are using the *internet browser*, rather than *OS* anyway. For me though, using Windows for software development feels like driving a 25-year-old poorly maintained car, with modern touch screen tablet slapped instead of an old cassette radio, while being rusty underneath, where something is constantly wrong with it, but it's still running and can get the job done. I don't *hate* Windows, but I'd rather avoid using it in a professional environment, unless I have no other reasonable choice, e.g. being forced by employer policies. Windows on enterprise servers is whole another topic, but to be short: *why?..*

### Philosophical Outro

Anyway, this recent experience reminded me, how miserable developer's life can be on Windows 11, even on a top-spec machine (even if it's Dell, *bruh*). Windows is just not for me, I guess. But at least I can choose my personal devices and for an observable future it is a Linux on PC and homelab server, paired with a MacOS MacBook. And yeah, I still have Windows 10 as a secondary class citizen on my PC just to run a couple of games, because Windows, to this day, is still the best OS for PC gaming. Maybe this will change soon and some year will finally be "The Year Of The Linux Desktop" to give more people a room to breathe and a choice for regular people, not a sacrifice or a headache.
### Mentoring Junior Developers: The Role of Mentorship in IT
URL: https://technikatsu.com/mentoring-junior-developers/
Last updated: 2025-01-03T09:15:34.000Z
---

Recently, I was asked about my opinion on mentoring and pair programming. I thought this would make a great read and I'd share some thoughts and observations. It is going to be mostly about mentoring junior developers.

### My Early Days

When I was a junior developer, I had the privilege of working with an amazing colleague who became my mentor. He not only taught me the technical skills, but also provided a friendly and helpful environment to learn and make mistakes. Recently, I noticed that I somewhat followed his trail in how I work and what tools I use. Maybe we were somewhat similar, and I was too ~~dumb~~ "junior" to understand some things back then. Anyway, I'm very glad that I had an amazing mentor during my early career days. In my more advanced days, I’ve also met great mentors and colleagues who continued to inspire and support me.

### Becoming a Mentor

As I gained experience, I took on the mentoring role myself. I’ve had the opportunity to participate in local academies, assisting and mentoring junior developers. These experiences have been incredibly rewarding. Watching others grow and succeed, knowing that I played a part in their development, is a great feeling. Mentoring also reinforces my own knowledge and keeps me sharp. Junior devs might struggle in the most unexpected ways, but it is important to let them actually fail—not in a way that takes down production, but in some harmless way. It's usually not that hard to predict the outcome of failing, so I was already prepared and waiting at the point of failure with friendly tips, help, and an explanation of what went wrong. Failure is a part of the learning path. While it is important to guide, it is also important to give freedom for actions and curiosity.

### Beyond Books and Courses

I think mentoring is crucial in the IT industry. It helps to create a link between theoretical knowledge and real-world application. A good mentor can provide insights that are not available in textbooks or online courses. They offer a different perspective, share personal experiences, and help mentees navigate their career paths. Moreover, mentoring promotes a culture of learning and collaboration, which is vital for the growth of any individual.

### Two Devs, One Screen

Continuing the duo of a mentor and a mentee, pair programming might be another effective method of knowledge sharing. Although some people hate it, others love it. If the leading person is enthusiastic and enjoys the process, it can be a fun and productive way to learn for both the mentor and the mentee. Pair programming allows for real-time feedback and collaboration, yielding results (or local memes). It is important to actually help, not dominate over the poor mentee. For example, if we're solving a bug together, I like to investigate the problem together. Juniors often lack the skill of using debugging tools, so it's important to show how and when to use them. After identifying the problem, I like to sit back, verbally guide the mentee on solving the bug, and watch, giving tips, suggestions, jokes, and explanations along the way.

Although, sometimes pair programming just isn't someones thing and forcing pair programming onto such person is not going to make any good. Don't be an annoying mentor.

### Sometimes They Won't Ask

Sometimes junior devs might be too afraid to ask because they think their question is too stupid, or they're ashamed or just afraid to be a nuisance. I always try to encourage juniors to communicate and ask questions. Sometimes a simple unasked question might become a fundamental knowledge gap in the future. Of course, I try not to babysit, but if I see a junior struggling for quite some time, I will approach them myself. If everything is "fine", I try to invite them to discuss some matters of their current task, expressing some of my thoughts about it until they are ready to share their struggle. While it's useful to take some time and try to figure out the problem themselves, there's a line between "taking some time" and "getting completely stuck and just wasting time". Mentor is here for a reason. Not that I want to rush things, It's more about just getting things (eventually) done and learning something new along the way.

If they come with a question – great! If they come with a question for the 50th time today... Not great. To protect myself from becoming the next GPT AI for a mentee, I usually teach them a small "self-help" guide on how to actually get useful help and not make colleagues annoyed and tired of you. First, I usually send them to Google (or any other) search. If there is no help, then I ask them to think about three things:

1. What is the problem? In one sentence.
2. What is the error message (or any proof showing something is not working)?
3. What have you tried to solve the problem?

Around half the time, after these questions, they are able to solve the problem themselves by just trying to "study" the issue to answer these three questions. The other half comes already prepared with some spot-on questions that are easy to deal with.

### But I'm Not Getting Paid For That

Yeah, true. Sadly, being a mentor is usually "built-in" in the role. But also, usually, it's not forced to be a mentor. I usually participate in mentoring activities when I know that it won't hurt the project I'm currently in or that it's not of fire right now. 

Single-time activities like single lecture are generally not that time consuming, especially since you can prepare once and the re-present it every time with little to no modifications again and again. 

Having a junior is usually also quite chill, especially after the onboarding phase.

Participating in academies as a mentor and/or lecturer is IMHO the hardest and most time consuming as academies usually spans across multiple weeks. Sometimes I had to do unpaid "overtime" for the actual project I'm working on, because I spent too much time with the students. But in the end such experience is still quite worthy. After such academy I usually change and adjust my perspective on work things/projects, learn a few things and generally feel somewhat refreshed.

### TL;DR

It's quite fun. I am grateful for the mentors I’ve had and the mentees I’ve guided. Let's help each other and not gatekeep the industry.
### I Passed Oracle Java Exam. Should you?
URL: https://technikatsu.com/is-oracle-java-certification-worth-it-2025/
Last updated: 2025-09-05T08:36:11.000Z
Yep, I did that. And it was a total pain in the ass.

### I Guess I’ll Study

Although I am a senior Java developer with 7+ years of experience at the time of writing this, my work projects hadn't prepared me for this at all. I lived my life just fine without the abomination known as the OCP Java exam. Sometimes, the weird thought of passing the exam crossed my mind, but it was quickly blown away by the understanding of how much I would need to study for it.

However, one regular day, the team lead at work told us that they were planning to increase the number of certified people, and I was at the top of the "priority" list. Honestly, I wasn't against it. At least now I had some kind of motivation: "Management needs me to have this cert." I had the option to choose between passing the Java 11 or Java 17 exam (at the time of studying and writing this post, there was no exam for Java 21 or newer), so I chose Java 17\. Since I had to study anyway, I thought it didn't really matter.

And so I began to study. I got *the* book (OCP Oracle Certified Professional Java SE 17 Developer Study Guide: Exam 1Z0-829) to prepare myself for the cert. Quite quickly, I understood that this exam is more "academic" rather than "practical." I had seen some wild things in different projects, but reading this book, I encountered some unseen shit. For example, I never saw anyone actually use Java modules or access a member of a list using binary instead of regular decimal int. Or using some super specific collections members. I realized that my Java knowledge wasn't that deep. Or rather, it wasn't that wide.

### Java, But Make It Weird

You see, I learned Java by myself, mostly through various projects at home and at work. I understand how the JVM, GC, and other Java-related things work, and I've spent 7+ years working on Java projects, writing various business logic for different projects and clients. Yet I understood how little of the language you actually need to know to peacefully work in a corporate environment, writing some code.

Anyway, I read through the book without caring too much because that's how I study—first, get acquainted with the whole thing, and then dig deeper. And I needed to go deeper. After the first read, it became clear to me that the book wasn't enough. I got myself practical mock tests and a video course partially based on the official study book and continued my efforts. And the "fun" began. I hated this exam already. Some questions were weird, some exploited how carefully you could examine code (like, no one actually reads through the import list or package names) and tried to fail you in some bizarre way. Here's some examples from mock tests which were not too far from the real exam:

![](https://technikatsu.com/content/images/2024/06/image.png)

![](https://technikatsu.com/content/images/2024/06/image-1.png)

![](https://technikatsu.com/content/images/2024/06/Screenshot-2024-04-03-at-17.46.57.png)

These and similar ones were the triggers of "fuck it, I'm done for today".

### Torture, Triumph, and an Official PNG

Anyway, after a few months of torture by studying on and off for the exam, the deadline has come and I had to actually take the exam. I booked the date, took the exam and failed :). Not too far from passing the exam, but still failed. It took me another month or so of studying to try again and the second time I passed the exam. Here's look, I have the official PNG! I have no clue why it says 2022, though - I took the exam in 2024\. Here, look:

![](https://technikatsu.com/content/images/2024/07/552-276-max.png)

Anyway.

Is it a difficult exam? Yes it is. Unless you can memorize a lot of things or actually use the WHOLE Java regularly.

Should you take Java OCP exam? I don't know ¯\\\_(ツ)\_/¯. If you have over 5 months to spare your evenings, then why not.

Am I happy now that I am a certified Java dev? Sure, why not, looks nice on my CV ;). And a nice flex: "I'm CeRtIfIeD, bY tHe wAY".

Thanks for the read.
### Modern Android Phones: Superior, No Root Needed
URL: https://technikatsu.com/modern-android-phones-superior-no-root-needed/
Last updated: 2024-07-04T21:37:50.000Z
Let's dive a little into the Android universe. I've been team Android since practically the dawn of time—or at least since Android 2.2\. And inevitably, I've learned a thing or two along the way.

Android is the reigning champ of mobile operating systems worldwide. Let's get a quick refresher about how it all started. The story begins back in 2003 with Android Inc., started up by a gang of four—Andy Rubin, Rich Miner, Nick Sears, and Chris White. Initially aiming to innovate digital cameras' OS, they quickly pivoted to mobile due to the massive potential they saw. Fast forward to 2005, Google swoops in and acquires Android Inc. The HTC Dream (T-Mobile G1) in 2008 marked the commercial debut of Android, kickstarting its journey to become the most widely used mobile OS, powering everything from phones to smartwatches and TVs. Thanks to its open-source nature, we've seen an array of devices—from the revolutionary HTC Dream to the quirky LG Wing and Samsung Galaxy Round, plus the Google Nexus and Pixel series and many more cool phones.

## Why Root?

Yeah, so, Android is customizable. This flexibility allows it to adapt across various devices, but it also means manufacturers can impose annoying restrictions. Meet "rooting"—the tech-savvy’s key to unlocking ultimate control over their devices. This practice dates back to the early days of Android and was initially a geek-exclusive endeavor to squeeze more power from their gadgets. Through rooting, users could ditch pre-installed apps, swap Google services for alternatives, and tweak app permissions. Sounds great, right? Well, it comes with some "buts"...

- **Warranty Voiding**: Yeah, rooting pretty much kisses your warranty goodbye.
- **Security Risks**: Rooted devices can be a playground for sketchy apps if you're not careful.
- **Bricking Potential**: Mess up the rooting process, and you might just turn your device into a pricey brick (pretty, but still a brick).

Rooting was a gamechanger back in the day, but let's be real—it's becoming obsolete.

## My Experience

My first Android, the LG Optimus One (P500), was a budget game-changer from the LG KP500\. True smartphone. It had apps, games, widgets, and a decent browser. Curiosity and a penchant for pushing tech limits led me to root it. I went all out: overclocking, changing CPU governors, and moving otherwise restricted data to SD cards (big integrated storage was a luxury back then). Then came the LG Optimus G and later the Asus Zenfone 2, which, despite its "cutting-edge" Intel Atom x64 CPU, was a bit of a letdown due to compatibility issues and sluggish performance. It was just different because of the x64 instead of ARM and that attracted my curiosity.

Fast forward, and Xiaomi’s Mi 8 was a breath of fresh air—no rooting required. Its UI was slick, performance was top-notch, and everything just worked. Then came the Asus Zenfone 9, another standout that I decided to keep unrooted because it was just that good—powerful hardware, great software, no changes needed.

## No root?

These days, manufacturers are offering more customization options straight out of the box—like system theming, detailed app permissions, and developer settings. This makes the old art of rooting practically unnecessary for most. Gone are the days when rooting was the only path to better performance, battery life, and a tailored UI. Nowadays, modern smartphones pack all these features, delivering stellar performance without the hassle. So, unless you're gunning for a privacy-focused OS or some niche need, rooting might just be more trouble than it’s worth. In the ever-evolving world of Android, less is sometimes more.
### 5G Controversy: Essential Upgrade or Marketing Bait?
URL: https://technikatsu.com/5g-speed-hype/
Last updated: 2025-01-03T09:17:55.000Z
OK, I have something to tell about 5G. Yeah, you've probably heard a ton about it—how it's going to change the world with blazing speeds and unreal reliability. Some time already passed, but it's relatively new, an upgrade from the good old 4G, and it's been advertised like crazy by phone manufacturers and network operators. But like with every overselling feature, you need to ask yourself: Do average Joe really need 5G, or is it just a lot of fancy marketing trying to pull us into spending more than we need to? Well here we go. Keep in mind, that I'll be mostly speaking about phones here.

### **The Hype Train** 

First things first, the hype around 5G is everywhere. You can't turn your head without seeing ads promising revolutionary changes to how we live and connect. But if we look past that glossy advertising, what's really underneath? For most of us, the stuff we do on our phones—like streaming, browsing, and gaming—works pretty damn well on 4G already. What problem is 5G trying to solve? Speed?

### The Fastest Internet You Can’t Find

Now, digging a bit deeper, it gets kind of sketchy to say we absolutely need 5G. Sure, it’s supposed to be faster and all, but setting up all those new towers isn't cheap or simple too. You see, 5G has a bit of a problem with distance and obstacles. Buildings or trees can mess with the signal, and the towers need to be pretty close to each other. That's a lot of new infrastructure, and it's not just about money; finding places to put it all is a decent quest too. And finding the perfect signal for 5G to get all the speed can be a tricky task.

### **A Lifeline for Some** 

I don't want to say that 5G is useless. In areas where laying traditional cables is a no-go—like urban areas or where it’s just too expensive—5G could be a game-changer. It might just be the best way to get decent internet to homes. For household with family of multiple people, 5G is definitely a better solution that 4G.

### **Worth the Switch?** 

So, what's the real deal for consumers and their phones? It all comes down to need versus want. Unless you really need the extra speed for work or you're super into the latest tech, the jump to 5G might not be worth the hype or the cost. Especially when 4G is already doing a pretty good job. I mean, for phones, this is an extremely rare case of someone using phone to move tens of hundreds of gigabytes of data daily using **mobile** network. For everything else - yeah, I guess huge PDF will download within 2 seconds instead of 4\. But is it worth it? Talking about me, I own a phone, that supports 5G, but I've turned the 5G off, because I just don't need it and 4G consumes less power... And I was kinda shocked, when I learned that I have to pay extra to my mobile operator to include the 5G into plan and be able to use it.

### **Critical Choices** 

As we try to figure out this 5G puzzle, it's crucial that we stay sharp and think critically. Do we go with the flow of flashy ads or make a decision based on what we actually need and the bigger picture? This is about more than just faster downloads; it's about smart choices and maybe even keeping an eye on our wallets.

In conclusion, while 5G seems like a cool advancement, we've got to ask ourselves: is it really an essential upgrade, or just a bunch of marketing bait? From where I'm standing, it looks a lot more like aggressive marketing than a must-have. Let’s not get swept away by the hype; let’s think about what we really need and make the choice that’s right for us. I am not against the advancement of technology. I am against **misleading marketing** selling bells and whistles as a necessity.
### One Of My Websites Got Hacked 💀
URL: https://technikatsu.com/one-of-my-websites-got-hacked/
Last updated: 2024-12-04T17:49:15.000Z
I host quite a bit of content online, and one of them is a WordPress website. I tend to dislike WordPress due to the mess of plugins, nightmarish updates, extreme bloatware, and as a result, numerous security vulnerabilities. However, at the time, I didn't have an alternative, so here I am, hosting a WordPress website. I could really learn it, but that's just not the thing I'd like to spend my free time on.

### Happy New Year

The hack occurred on New Year's day/night when I was in a holiday mood and, of course, not paying much attention to the website. It had also been last updated about a month ago. Just like that, I fell victim to a quite common "Pokemon" - a redirect hack, a.k.a. the "Japanese keyword hack." Essentially, thanks to some exploit, it creates hundreds of links for the root domain, appearing in search engines and redirecting users to malicious websites instead of the original one. The alarm bell rang when, three days later, Google Search Console informed me that 638 new pages were successfully scanned and indexed, and 6249 were not indexed YET.

### Cyber Cleanup on Aisle 5

The damage was already done; searches for the website were littered with fake links redirecting to a wide variety of scam websites. It seems like someone (I have IPs logged) finished their holiday early and decided to find some new victims. Unfortunately for me, their endeavor eventually succeeded, and I was left with 62 modified files and 939 new files. Without strong knowledge (and no desire) of the WordPress file structure, the obvious solution was to restore the safe backup, which did not help. Not sure why, but I had an alternative way. The second obvious solution was to discard the compromised container, create a new one, and restore the backup there, which did help.

### IT Support: Me, Myself, and I

However, that's not the end. Shields up! Harden the security! Update firewall rules, update WordPress, disable a bunch of plugins, change passwords, blacklist a bunch of IPs (I know this probably won't do much, but I did it out of spite) and I'm good to go, at least until another exploit.

This hack wasn't a disaster for me; the website doesn't contain any sensitive information. It's essentially a static webpage with a single contact form. Furthermore, the server itself is isolated and relatively empty. So, while messed-up search results are certainly annoying, they are temporary. It was a healthy reality check, but the whole situation was mostly annoying because of the time spent.

### Bouncing Back from a Cyber Attack

Things that went well:

- Containers! Thanks to them, I could restore the healthy version in a few minutes, and my host was not affected.
- Infrastructure. I was away from my server when I found out the webpage was hacked, so I had no physical access to the server. However, my infrastructure remained operational due to separate devices providing remote access and other services, while the server with the infected webpage was under investigation.

Things done: 

- Hardened WordPress
- Enhanced firewall rules
- Improved logging

Things to do:

- Migrate the website from WordPress to a custom-written lightweight webpage.

Security is crucial; go check yours. Everything you host publicly, even if it's a small thing for very little audience, may attract some dickhead who will ruin your day.
### How to Choose a Laptop: A Guide for Non-Tech People
URL: https://technikatsu.com/how-to-choose-a-laptop-a-guide-for-non-tech-people/
Last updated: 2024-09-27T22:15:30.000Z
Is your old laptop showing signs of wear and tear, leaving you wondering about your next purchase? Have a budget and don’t know what to buy? Or you don’t even know how much money do you need to spend? You have no clue RAM is and how much do you need? Well, I’m here to help you with this guide, which is friendly for non-tech people. I’ll explain everything you need to know as simple and quickly as possible, without digging too deep. Just everything you need to know to buy a decent laptop.

### Define Your Goals

First of all, set your goals. Ask yourself a few questions:

- What is the primary purpose of the laptop? (Office work, gaming, photo editing)
- Will you ever play games on it?
- Do you need to edit photos or other media?
- Will you need to carry it frequently?
- What is your price range?

Example 1: *I need a laptop for simple office work and watching movies.*

Example 2: *I need a small and light laptop to, because I will carry it with me every day. Occasionally I want to edit photos.*

## Understanding Laptop Specifications (Super Simplified)

### Screen

Screen is important, because you will have to look at this screen every time you use your laptop. There are several parameters for screen.

### Screen size

Measured in inches. It means how big is the laptop screen diagonally. 15.6”, 13, etc. 15.6 is the most common size. It also means how big the laptop is overall. Laptops with smaller screens are smaller and lighter, that makes them more portable and convenient to carry around, but for some people it might be harder to look at the smaller screen, as everything will appear smaller. Laptops with larger screens are larger themselves, so whey will be heavier and not so pleasant to carry with you.

### Refresh rate

Measured in Hertz (Hz) – means how smooth the moving image will appear. It is most visible when you scroll down walls of text or playing games. It will have no effect on videos like YouTube or Netflix or any other media. 60 Hz is the standard. Over 60 is either nice to have or for people who know why they need it. So my suggestion is to not bother about it.

### **Resolution**

It means how many pixels the screen has. Basically, the more pixels there are are, the more information you can see on the screen. As others say, “screen real estate”. Like putting multiple windows side by side. On higher resolution screens the image will appear sharper and more detailed. Standard is 1920x1080, also known as FHD or Full HD. Don’t get ANYTHING less that Full HD or else you will regret it very soon. Higher resolutions, like 2k or 4k are nice, but usually more expensive.

### **Panel type**

I’ll be short.

- TN. If you see TN – please don’t buy it, everything will look terrible. Yeas, there are some exceptions, but it’s hard to recommend for general audience. TN is cheap, but pretty terrible.
- VA – is very rare is laptops but should be alright.
- IPS – good.
- OLED – very good, but expensive.

### **Brightness**

Usually measured in Nits. Anything above 300 Nits is usable, in my opinion. The higher the number, the brighter display will be at maximum brightness.

### **Bonus: Color Gamut.**

Usually written under sRGB or NTSC parameter. Basically, this is how accurately color on the screen represent colors of real life. If you need to edit photos – you need to aim for 100% sRGB or 72% NTSC. For normal people everything above 92% sRGB should be fine.

### CPU (Processor)

CPU impacts how FAST the laptop is going to do certain things. Like, imagine someone have sent you a .zip file with photos of their vacation. In order to see the photos you would need to unzip them. And with a weak CPU it might take, let’s say a minute. But with a fast modern CPU it might take just 5 seconds.

Now, what do you need to look for when buying a laptop. There are 2 main manufacturers. There's 3rd one down below, but let's stick with two, you'll understand why in a few paragraphs. So it's AMD and Intel. Both are generally good. So just pick whatever and you’ll probably be fine. BUT it’s not that simple. See, there are numbers and even letters in the name of CPU (for example, Ryzen 5 5500U). What do they mean and what do you need to know? Well, unfortunately, it’s a bloody mess now. Mainly because of how Intel names their products. It’s very confusing. So, again, I will oversimplify, not going into much details. For AMD, it’s easy: there are going to be things like Ryzen 3, Ryzen 5, 7 and 9\. It represents different performance levels. Usually higher number will have more cores and more performance. Also there are Athlon, and other stuff, but generally you don’t want them, because they are kind of weak.

For Intel there’s Core i3, i5, i7, i9 and later there’s going to be Ultra 3, 5, 7 and 9 instead of “Core i”. It’s the same thing, they just renamed it. Also there’s Celeron, Pentium and maybe other stuff, but generally you don’t want them, because they are kind of weak.

Overall, for better understanding, let's compare it to cars:

Ryzen 3 or Core i3 is like an economy car—good for getting around town without using much fuel (basic tasks). Ryzen 5 or Core i5 is like a mid-range sedan—comfortable for long drives with decent speed (multitasking, some gaming). Ryzen 7 or Core i7 is like a luxury sports car—high-performance, fast, and packed with features (intense workloads like gaming and video editing). Ryzen 9 or Core i9 is like a supercar—extremely powerful, built for extreme performance (heavy multitasking, 3D rendering, and high-end gaming), handling the most demanding workloads with ease.

NEXT:

There are number and letters after the name (for example, Ryzen 5 **5500U**), but that’s kind of a lot to take in for a non tech-savvy human being. Instead I will present you a*shortcut*, using which you will be fine without knowing all what all those numbers and letters mean. Is consists of *just two steps*:

**First step** – decide which “number” you want or need. If you just need a laptop for daily use – watching YouTube, Word or Excel work, some photo editing, light gaming – AMD Ryzen 3 or 5, or Intel Core i3, i5 (or, later Ultra 3 and Ultra 5) will be enough.

If you’re a gamer, or serious content creator, then something with a “5” is the minimum that you’d want. 7 is better, 9 is a luxury.

**Second step** – open Google (or any other search engine you like) and put down the name of the CPU (for example, Ryzen 5 5500U). A page like Intel ark or amd.com will show up. Open it and you will see a lot of technical information, but all I want you to look at is “Launch Date”. It means when this CPU model was released. Generally, the newer it is – the better. Not only form performance perspective, but also stuff like battery life. I would suggest you to make sure that the laptop you’re looking for has a CPU from **THIS** year or past year. Maximum 2 years old, but at this point you’re already 2 years behind the newest and best, so I’d do it only if there would be a very tasty price.  
That’s it. Two rules. Decide what number you want and make sure it’s not older that 2 years.

Polishing it up with a car analogy let's get this summary:

- **Brand (AMD/Intel)**: Car manufacturer (e.g., Toyota or Ford)
- **Series/Performance Tier (3/5/7/9)**: Class of the car (economy, mid-range, luxury, or supercar). In the example of AMD Ryzen 5 5500U it's this part: AMD Ryzen →**5**← 5500U
- **Generation (1st/2nd/3rd/4th)**: Model year (newer generations are like newer car models with better features). In the example of AMD Ryzen 5 5500U it's this part: AMD Ryzen 5 →**5**←500U
- **SKU (500/xxx)**: Specific engine variant (higher numbers mean better performance). In the example of AMD Ryzen 5 5500U it's this part: AMD Ryzen 5 5→**500**←U
- **Suffix (U/H/X/K)**: Specialization (fuel-efficient, high-performance, or tuned for speed).In the example of AMD Ryzen 5 5500U it's this part: AMD Ryzen 5 5500→**U**←

### ARM and Windows Copilot/AI

You might come across newer models that are equipped with ARM-based processors or branded as “Copilot laptops.” ARM processors, often seen in smartphones and tablets, have made their way into laptops, promising great battery life and efficiency. While these laptops can seem appealing due to lower power consumption and longer battery life, they are not yet fully ready for many traditional desktop apps. You may encounter compatibility issues with software that is designed for Intel or AMD chips, limiting your ability to use certain programs smoothly. Similarly, “Copilot laptops” with AI-focused features like Microsoft’s Copilot are still quite new, and it may take time before the technology matures for everyday use. So, for now, for a regular person, it’s safer to stick with well-established and developed options like AMD or Intel-based laptops, to be sure that everything will work as expected.

**TL;DR:**

- Look for a CPU from AMD (Ryzen series 3, 5, 7, 9) or Intel (Core i3, i5, i7, i9 or Ultra 3, 5, 7, 9). "Ultra" is newer than "Core". Higher numbers generally indicate better performance. Normal people will be good with a “3” or “5”.
- At the moment of writing (2024), maybe stay away from ARM CPUs. It's still an evolving platform for laptops and some apps might not work properly.
- Focus on the launch date for newer technology and improved battery life.

### RAM (Memory)

It’s a memory, but not that kind of memory that you would save your photo into, but other kind of memory. It impacts multitasking ability - how many documents, Chrome tabs and generally, how many programs you can open at the same time without laptop starting to choke, lag or slow down in any other way. My recommendation is short – please *don’t buy anything less that 16GB of RAM*. There are other parameters, but for normal people they does not matter. 8GB is way too little for modern usage. 16GB is decent. There are also 24GB, 32GB and so on. The more – the better, but 16G is where it starts to feel good. At least 12GB, but that's as uncommon configuration, you're far more likely to find 16GB.

### Storage

That’s the kind of memory that you will save your photos, documents, games and all other stuff. There are 2 types of storage. SSD and HDD. Opt for SSD over HDD. It’s multiple times faster. There’s also third option, called EMMC, but you REALLY don’t want that. Just don’t, please. Back to SSD. There’s also 2 types of SSD. One is called SATA, other M.2\. M.2 is preferable but SATA is acceptable.

**How much storage do you need?**

There are standardized sizes.

- 128GB – too little. You will quickly run out of space.
- 256GB – If you don’t store lot’s of stuff on your laptop, like movies, thousands of photos, games, then it will be enough.
- 512GB – generally enough for most people, unless you work professionally with photos or videos.
- 1TB (1000GB) or more – That’s a lot of storage for a regular person.

### GPU (Graphics Card)

Graphics card. There are two types of GPU. Integrated and dedicated (discrete). Generally, GPU is responsible for displaying everything on the screen. If you play games, edit videos or professionally edit photos, do 3D modelling, you would need a dedicated GPU for that. Everyone else – just don’t bother, you will have an integrated GPU, don’t look anything up, it’s OK, you don’t need to care about that at all. For gamers, video editors and other people – it’s a bit difficult. To be short, some quick tips:

- Higher Numbers are Better: **Generally**, higher model numbers *within the same series* tend to offer better performance.
- Check VRAM: The amount of VRAM (Video RAM) is crucial for graphics performance, especially in gaming. Higher VRAM is better for running modern games smoothly. It's a bit more complicated, but true for the simplicity sake.
- Consider Use Case: For gaming or content creation, a higher-end GPU might be necessary.

This is an extremely short and super simplified explanation about GPUs. If I would dive deep on how to pick a good GPU for specific needs, there would be a huge wall of text, and I believe that’s out of scope for this article. If you know that you need a GPU, then you probably know what to look for anyway.

### Form Factors and Additional Features

There are multiple form factors – laptops with touch screen, laptops that can rotate their screen, have detachable keyboards, normal laptops and so on – that’s on you. Pick whatever you want but just keep in mind everything I was writing about this whole article.

You could also notice that some laptops will have “DOS” or “NoOS” in the name or description. This means that they come **without** **Windows** and you won’t be able to use it **unless** you install Windows by yourself. They are usually cheaper, so if you happen to have a Windows license just lying around, you might shave a few percent off of the usual laptop price. Also some may have Linux in their name (Ubuntu or something else). If you only every used Windows or MacOS, or barely know what as OS (Operating System) is, then it's probably not for you. It's a good Operating System, it's just that it required so to have a bit of understanding how PCs work in some corner case scenarios that you might experience.

### For Apple Users

If you’re looking for an Apple MacBook – it’s simple. Anything with some kind of M CPU (M1, M2, M3... The higher the number, the newer/better it is) 16GB RAM or more is good. Just don’t buy 8GB MacBook… I fail to understand why such company as Apple still lets its users to experience the "wonderful and smooth" 8GB RAM experience. Even if you are a light user, you *will* hit the 8GB RAM ceiling just by not closing apps, having too many browser tabs, just closing the lid instead of turning it off, no matter what Apple marketing says.

### That’s it

By following these simplified guidelines, you'll be reasonably well-equipped to navigate the laptop market and make a confident purchase tailored to your specific needs. Happy laptop hunting!