jbstack

There's definitely appeal in key-driven window managers in general. Projects like i3 and Niri are popular. But you can get that with any Linux distro (albeit not many have it set up that way by default). You don't generally choose a distro just for whatever DE/WM it happens to start with.

As someone who uses Signal and WhatsApp, I would be extremely happy if those companies blocked access in my jurisdiction if such laws are implemented. In fact, if they agreed to insert backdoor access I would never trust them again, even if they subsequently reversed it.

We have to be willing to suffer personal inconveniences to stand up to these types of policies.

With all the current concerns about rogue and mis-aligned AI, and about how we've made essentially zero progress on making sure that AI is safe and trustworthy, NOW you want to put backdoors in encryption algorithms? We should be doing everything we possibly can to make our systems more secure, not less.

This type of policy was terrible when they first thought of it. Now it's outright negligent and dangerous.

I do something similar. I have a base NixOS image in Incus, with whatever tools apply to every project (e.g. Git, OpenCode) already installed. When I work on a project, I spin up a VM instance, use nix shell to add any project-specific tools, then share only the project folder from the host to the guest. This way, the worst the agent can do is destroy my project folder, and I can always restore that from another clone of the repo.

I know a lot of people are using containers for sandboxing, but given how capable the latest models have shown themselves to be for breaking out of sandboxes, I prefer the extra isolation of VMs for this.

I do all this locally - it's an interesting point to able to turn the laptop off but keep the agents running. I might consider running some of these on my homelab server just for that.

> Permits

Obtained by your AI agent, granted by another AI agent.

> Materials, trucks, equipment etc.

Ordered by your AI agent, delivered by a self-driving truck or drone, loaded/unloaded by robots to/from the warehouse/site.

Most of this stuff can already be done today in some form, so its just about improving the autonomy and integrations along the supply chain.

> Xephyr

Given that X11 is becoming more and more obsolete over time, what's the Wayland option?

There's a lot of middle ground between doom-scrolling type content and a 10 hour block of non-stop immersion. It doesn't have to be one or the other.

Many factories in China now already have 90% of their work being done by robots. Is it really so hard to imagine that we reach a point where they can be prompted?

You're assuming a handover happens in a single definable moment. More realistically it will be one small decision making power at a time, so that at any given moment it never really feels like control is being given up. Boiled frog.

> in Germany people are reluctant to give their IBAN to others

Are they worried people might send them money without their permission?

Doesn't matter if you aren't asking the type of questions where hallucinations are relevant e.g. you're seeking pure reasoning rather than factual information.

> I thought the supreme court said the tariffs are illegal without congressional approval

The ruling wasn't as generalised as that. What it said was that the president doesn't have the authority to impose tariffs under the provisions of the International Emergency Economic Powers Act, which Trump had cited as the basis for some tariffs. That made those tariffs effectively illegal, but the ruling said nothing about tariffs which had other legislative provisions as their legal basis. The tariffs that you see today cite some other rule as their basis rather than the IEEPA.

You want both. The harness and the sandbox do different things.

The harness says "You have access to tool X, Y, and Z, but not A, B, C".

The sandbox says "If you try to use X to access a forbidden resource, I'll prevent you from reaching it".

You've selectively quoted the article. The full quote (emphasis added):

"When Moore’s Law slowed in the mid-2000s (specifically, single-threaded performance stagnated), we suddenly had to think about parallelization, architecture, memory locality, etc."

Your link is talking about transistor count. The article is talking about single-threaded performance. Today's CPUs are faster in large part because they have more and more cores.

In my case, it's not so much that I find it childish, it's that I find it incredibly distracting which means I can't focus as easily on the content. Instead of "oh, now I understand how that equation works" I catch myself thinking "why is he repeating the same word over and over - that's so annoying!". Then my brain starts obsessing over "when is he going to do it again?", even though I don't want it to. It's a bit like trying to deliberately ignore something. It becomes all you can think about.

Side note, but much as I like Khan Academy overall, I've always struggled with Sal's slow and repetitive speaking style in the videos.

"Now you add the five ... [pause] ... add the five ... add the five to the seven ... to the seven..."

Running them at 1.5 - 2x helps a bit, but it's still annoying to the point that I find it very distracting.

> one thing is pretty clear: the act of familiarizing yourself with a language no longer matters

I completely disagree with this statement as a premise to the article.

Sure, if you have zero care about whether the agent's work is reliable or not, then there's no need to learn a language. But if you're a developer who cares about their work and isn't just outputting 100% vibe code, then at a minimum you should be familiar enough with the language that you can review the agent's output ,follow along with the code, and make an informed decision about whether to commit.

Interestingly, I've found that my approach to learning languages has fundamentally changed. Before, I'd study a book on the one or two languages which were important to me at that time. The goal was to become proficient. Now I choose to read about a variety languages simply because they demonstrate some interesting paradigm that is new to me (e.g. Haskell -> functional, Elixir -> concurrency). I read a programming book like I'd read an engaging narrative non-fiction book: cover to cover relatively quickly, then I'm done. This gives me that "familiarity" which is useful for agentic coding, without bothering to learn every obscure bit of syntax or library call. My priority has become breadth (get an overview of many languages and paradigms) rather than depth (learn a language or two really well).

Actually the main thing I want is to be able to use my phone however I like, and install whatever I want, without Google telling me whether I have their permission to do so or not.

> My partner got the Moto G Stylus 2025 after we swore off Samsung last year.

I've been wanting to get away from Samsung for years, but keep coming back because of the s-pen. I've yet to find another manufacturer that makes a decent phone with a proper stylus. As in, a stylus which the device recognises as being something different to your finger. Most styluses use the same technology as the cheap ones you can buy on Amazon and use on any phone: all they do is imitate the finger. As far as I know, the Moto stylus phones are like that, right? That makes them very awkward to use for many things e.g.:

S-pen -> scroll down a PDF with my finger -> highlight with the pen

Regular stylus -> scroll down a PDF with my finger -> select highlight option in app -> highlight with stylus, being very careful not to touch the screen anywhere with my finger -> select browse option in app

With the latter, you have to specifically tell the app every time you are switching to/from finger and stylus. With the former, the app knows the difference.

If you give me a high end phone with a proper stylus and GrapheneOS, I'd probably never look back.

> Did you read it all the way to the end? It's coherent ...

I prefer my articles to be coherent without having to wade through pages worth of irrelevant material.

Except there was nothing "cool" about them. Vibe-coding ugly looking GUIs with slop-code backends is not interesting or impressive in 2026. Literally anyone can do it, and I'm pretty sure 90% of HN readers are aware that it's possible. Plus it did nothing to further the claimed purpose of the article, which was to explain why you shouldn't make TUIs.

I found most of the article completely unreadable. I was actually beginning to wonder if the HN post had linked to the wrong article, as it had nothing to do with TUIs until the very end. It was just a long list of "look at this slop code I made" and "look, here's another one!".

A lot of vibe-coded GUIs aren't fast, so this particular issue changes nothing. You're describing a property of the software development method, not TUIs vs GUIs.

I like TUIs for largely the same reasons as you, but I don't think this is actually a valid criticism of the article. It specifically addresses this by pointing out that you can make your GUI keyboard driven if you want to, so this isn't really an advantage of TUIs per se. It just happens that TUIs tend to be keyboard focussed while GUIs tend to be mouse focussed. But that's a design choice rather than an inherent property of TUIs vs GUIs.

I agree that I found the article to be poorly written. Mainly because it takes a long time to make its point. I didn't really need to see a million examples of the author's vibe coded slop before getting to the topic which the title suggested the article would be about.

If your app absolutely must rely on the cloud for every one of its interactions, then fine. If not, you're just applying band-aids to a problem of your own making. Many apps could easily be local only, or local first. If you're not constantly accessing the network for information which could be stored locally, then you don't need to hide your app's slowness behind animations.

(1) Keep manufacturer's Android plus some plausible apps and data in a reserved part of the drive. (2) GrapheneOS runs from the other part of the drive. (3) Make sure PIN screen designed to not give away the OS. (4) When duress PIN is entered, erase GrapheneOS and restore manufacturer's Android. (5) Now you won't be charged for having GrapheneOS because they won't know you had it.

The important thing is that I could learn to use a flint and steel pretty easily if I wanted to. I don't need to carry out that particular task, but my ability to adapt to new problems means I can carry out more relevant tasks when needed. The most useful part of school and university for me wasn't that I learned the difference between a cirrocumulus and a cirrostratus cloud in geography class. It's that I learned how to learn.

If we let children cheat their way through school and justify it by saying they don't really need to think for themselves anymore, then we're going to end up with a generation of adults who struggle to take on any difficult tasks at all. I suppose your counter-argument to that will be "but we can just hand over everything to the AI" but that's an essentially an argument that humans should be considered obsolete altogether. I sincerely hope that that's not a path we end up going down (although I'm genuinely scared that it is).

> they’re too slow to work with interactively for many use cases

This just demonstrates how much we already take for granted the LLMs that we have now. If you compare it to what we had before (hand the task off to a junior dev and wait for them to complete the work) then it doesn't seem slow at all.

Not if it's the Da Vinci Code. But there are reports of bookshops getting large orders that include rare books.

You could just as easily say that before LLMs code was the artifact, the spec was the code, and humans were the compilers. All that LLMs change is speed.