Linkblog

Datatype — variable font that turns text into charts

Tue, 28 Jul 2026 05:47:01 +0000

A variable font that turns text into charts.

{b:20,55,40,80,65} {l:10,40,25,70,50,90} {p:73} {b:85,30,60,10,45} {l:50,20,80,35,65,10} {p:41}

Datatype is data as type

Datatype is an OpenType variable font that turns simple text expressions into inline charts. No JavaScript, no images, no rendering library — just type the syntax and Datatype's ligature substitution does the rest.

{b:30,70,50,90}

{b:30,70,50,90}

Bar chart

{l:10,50,30,80,20}

{l:10,50,30,80,20}

Sparkline

Datatype is a variable font

Two axes give you control over chart density and weight. Drag the sliders to see charts respond in real time.

{b:15,45,80,30,60,90,20} {l:5,35,20,70,45,85,30,60} {p:52}

Datatype at different sizes

The same expressions rendered from 14px to 64px.

14px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

18px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

24px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

36px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

48px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

64px {b:30,70,20,90} {l:20,50,30,80,10} {p:65}

Datatype in context

Datatype charts work anywhere text does — tables, dashboards, reports. Here's a stock watchlist with sparklines rendered entirely in Datatype.

Stock	30d trend	Price	Change
AAPLApple	{l:40,25,1,0,34,73,93,100,85,26}	$255.78	-2.27%
MSFTMicrosoft	{l:86,86,75,100,52,39,0,26,14,10}	$401.32	-0.13%
NVDANvidia	{l:55,70,63,71,100,67,0,88,88,53}	$182.81	-2.21%
TSLATesla	{l:81,77,100,73,37,47,0,39,60,39}	$417.44	+0.09%
AMZNAmazon	{l:86,91,81,90,97,100,54,23,12,0}	$198.79	-0.41%

Charts sit naturally within running prose, matching the surrounding typeface's metrics.

Merriweather (Serif)

Revenue grew steadily through Q3 {l:15,28,40,52,63,78,88,95,74,58} before a seasonal dip. Market share {p:34} held firm against competitors, and our product mix {b:60,45,80,30} shifted toward higher margins.

IBM Plex Sans (Sans-serif)

The patient's heart rate {l:68,82,55,90,42,78,60,85} remained within normal range. Blood oxygen {p:97} was excellent, and the weekly activity breakdown {b:25,40,55,75,90} showed consistent improvement.

Fira Code (Monospace)

cpu_load {l:15,45,90,30,75,20,85,95} spiking mem_used {p:78} req/s by endpoint {b:90,35,70,15,60}

How to use Datatype

Add Datatype to your CSS, then just type chart expressions in your HTML.

@font-face { font-family: 'Datatype'; src: url('Datatype.woff2') format('woff2'); font-display: swap; } .chart { font-family: 'Datatype', sans-serif; font-variation-settings: 'wdth' 15; font-weight: 400; }

Sales {l:20,40,70,50,90} are up. Budget {p:73} utilized. Results {b:30,70,20,90} by quarter.

It's easy to use Datatype on the web. See the integration guide for setup instructions.

Bar charts `{b:values}`

Comma-separated values, each 0–100. Up to 20 bars.

{b:15,45,80,30,60}

{b:15,45,80,30,60}

5 bars — values set bar height as a percentage

Sparklines `{l:values}`

Comma-separated values, each 0–100. Up to 20 points.

{l:10,40,25,70,50,90,35}

{l:10,40,25,70,50,90,35}

7 points — values set point height as a percentage

Pie charts `{p:value}`

A single value, 0–100, representing the percentage filled.

Being Linux Torvalds - <antirez>

Mon, 27 Jul 2026 09:42:49 +0000

"Now, when we program with the artificial intelligences, we are exactly that same thing. We are Linus Torvalds, not always with the talent that he has, but the role we should assume"

antirez 2 days ago. 39022 views.

(This blog post was adapted from the transcription obtained from my YouTube video at https://www.youtube.com/watch?v=l6lxgYeVZqs)

When Linus Torvalds developed the first Linux kernel, he had studied the Minix sources, he had studied computer architecture, he had the base knowledge needed, and he was obviously a very brilliant programmer. But that operation of writing a minimal yet working Unix kernel for the 386 (at the beginning Linux was, let's say, mono-architecture) was something within the reach of many other programmers and students. Many in the sense of, I don't know, 0.1%, one in a thousand, one in ten thousand. Obviously most people are not able to do this kind of feat, but a lot of people are. If you look at Hacker News in the latest years, you'll see how many projects of kernels written in C, microkernels implemented from scratch, kernels written in Rust, kernels made in all sauces and manners, small Unix systems created vertically for the Raspberry Pi, operating systems for the ESP32 and so forth. Writing a kernel is not something within everybody's reach, but it is something that many can complete, if they put enough effort into it. Then, of course, not everybody will do it well. He is a genius programmer, without any doubt, so he did it better.

And yet, of Linus there is only one. This implementative capacity of his, in fact, would not tell us much about him: what we should focus on, instead, is what happened later.

## He stopped writing code

Among the maintainers of the famous open source projects, he was one of the very few that, very early in the history of the development of Linux, almost completely stopped writing code in order to concentrate on the leading of the project. On being the leader, the coordinator, the single mind holding the clarity about what the goals of the project must be, and so on. And this is a rare thing. Many maintainers (myself included, for a long time) continue instead to implement things directly, to not delegate much, and so forth.

This also starts from a different idea of software. Linux, necessarily, had to grow immeasurably: it is in the quality itself of a kernel that wants to embrace many devices, platforms, subsystems, and to continuously adapt to the times, to the needs of the new software, to the hardware that comes out little by little. So this was not a mistake. Redis, on the contrary, could remain something self contained. The other day I received a pull request on linenoise from Dr. Richard Hipp of SQLite: he too aimed at stability, at minimalism, at performances, but always keeping the code base very small, and he continued to write code for a very long time. Linus, instead, no. He understood immediately that he had to donate his time to something that was more important, for a project destined to become very big compared to what is the implementative capacity of a single person.

So he became the project leader, the one that owns the ideas, the direction. And what is it that Linus does, then? He does not look at every patch line by line, every time. Of course it also happens to him to look deeply into a single implementation, in order to understand what is going on. It happened to him, over the years, to write some new subsystem, or even to rewrite one: I think he did it once with the USB layer, many years ago, and he did it with the virtual file system, that at some point I believe he reimplemented, changing the structure of the inodes and of the inode cache, and he did it for several other reasons. From time to time he continued to program, when he created Git, and so forth. But for the most part he does not look at the patches singularly, in detail, line after line: he communicates with the maintainers of the subsections, and understands if a given feature or a given direction is, or is not, a road to take.

So, to say it in Brooks' terms, in Mythical Man Month terms, Linus holds the design concepts of the kernel, and continues to dialogue with everybody below him in the hierarchy of the kernel so that the kernel goes towards a certain direction. So that the developments go towards a certain direction, both from the implementative point of view (how these developments are implemented, what is the quality, what is the implementative idea in the very way the code is written), and from the design point of view: what is it that we want to do, what we don't want, what is the best strategy for the modules, for the scheduler, for the hardware support, for the integration of Rust or not. All this stuff here.

Now, I believe that this was the real genius of Linus. He is not just a very brilliant programmer: there are others. He is also a maintainer, an incredible designer, and one capable of handling a huge project ideas and structure in a coherent way, dialoguing with many other people. This thing is not for everybody.

## We are Linus, now

Now, when we program with the artificial intelligences, we are exactly that same thing. We are Linus Torvalds, not always with the talent that he has, but the role we should assume, in the projects where we don't do the review of every line of the code, is exactly of that type. It is exactly the role that he has.

Only, the thing is simpler to dominate: unless we use a lot of agents in parallel, it is substantially simpler to dominate than a multitude of patches arriving from different ways. But it is much faster. It is as if, instead of interacting with a team composed of many people at human speed, we interacted with a team composed of one, two, three people, based on how many parallel branches of our project we are developing in that moment, but that are much faster, so they give us immediately a much faster feedback. This slightly changes the modality of the work, but in my opinion for the better: it is easier, less context switching, fewer people to deal with, many fewer problems due to the character, the attitude, and so forth.

So, if we think that this role is important, we must not think that automatic programming is "I put the prompt, and the thing writes". Vibe coding is a wrong idea of what automatic programming is, and of what automatic programming will be for the majority of people. Vibe coding is a very interesting thing for who does not have technological abilities and wants anyway to have an impact on the construction of their own tools, and so forth: so, welcome, because it democratizes the possibilities. But it is not that.

Automatic programming, instead, in the hands of people that are expert technicians, or expert programmers, expert designers, expert software architects, is to assume the role of Linus, with the agents and the LLMs assuming the role of the different maintainers of the different subsystems. And since not everybody is able to do it so well, automatic programming as well has need of talents that talk with the agents, that check the ideas, that know which are the implementations to do and the ones not to do, the way of communicating with the agents in order to make them do the best work, putting there those design hints that a great programmer intuits, that a good programmer intuits and manages to precompute.

So automatic programming, when it is done well, means to assume the role of Linus. And this thing can be done well, it can be done badly, it can be understood, or it can instead be debased. And it is also something that needs training, that needs to be learned, exactly as Linus had to learn it: he surely had an innate talent for this, but he passed from "I implement everything" to that capability of handling a symphony, of being the orchestra director.

That, for me, is the lesson of Linus, and it is one that should immediately be used as an argument of contrast for those that say that, well, with the LLMs programming is easy for everybody.

Faulty Towers, vibe sickness, and the vibe bobsled

Sat, 18 Jul 2026 04:44:14 +0000

I know. As if what the world needed was yet another blogpost about LLMs and AI tech. Yet there is a pile of things which have been on my mind, and I haven't seen them laid out elsewhere in the way I'm going to write them, and so here we go.

I still don't use genAI to write my articles, fwiw. Here or anywhere else. These rambly words are my own.

The tower tilts

I read The Tower Keeps Rising recently, and it has stuck in my mind.

The piece is an observation, and according to Armin on lobste.rs, it is not an advocacy for the state of affairs (though by running a vibecoding company, Armin is part of advancing this direction):

For context: I'm the author. I intentionally did not make a judgement if this is a good or bad thing, or if this is going to continue working. It's primarily an observation that with agents you can continue to make progress even when people on the team maneuvered themselves into situations where previously they would have needed to talk to each other.

The summary of Armin's post is effectively that vibecoded systems keep piling code on top of code, but in many systems things seem to keep building, but the abstractions keep piling on, but eventually no human can understand the codebase. But this is a new way of operating, because LLMs can "explain" a part of the codebase that no human can make sense of, and so continue building.

Even if such systems continue to work, I find two things: 1) that now advocates for this state of affairs have pivoted into acknowledging that this is the end state of their systems and 2) they seem to be accepting it as the way forward.

Regarding the first, I think it's very important to note that this is a shift. Simon Willison, probably the best pro-genAI writer on the internet (sometimes, I think, giving cover for a lot of weaker writers, but is that Simon's fault?), at one point coined the term "agentic engineering" and was very clear to draw a line in the sand between agentic engineering and vibecoding:

We also need to read the code. My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else.
If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development. The usage of an LLM to support that activity is immaterial.

In an incredibly short period of time, basically a year, Simon published a fairly honest article titled Vibe coding and agentic engineering are getting closer than I’d like:

The problem is that as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff.
I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right. It’s not going to mess that up. You have it add automated tests, you have it add documentation, you know it’s going to be good.
But I’m not reviewing that code. And now I’ve got that feeling of guilt: if I haven’t reviewed the code, is it really responsible for me to use this in production?

It's a great read, and what I will say is that I applaud Simon's honesty and willingness to self-reflect and challenge prior statements.

But the gap of time between the former and latter articles are stunningly short, just slightly over a year.

And Simon isn't alone. Just a year ago, I think the memetic shape was by and large that something along the lines of "agentic engineering" is what people could or should do, and, though I think many people are hesitant to admit it, I think most people using these tools are tending towards vibecoding and not agentic engineering, just as Simon himself found himself pulled.

Before we look at the consequences to this, I think we should look at why it's happening.

The vibe bobsled

As far as I know I'm the only person who uses the term "vibe bobsled" and, well, I doubt it's a term that's particularly likely to catch on, but I find it personally useful.

Bobsledding, if you are unaware, is a particularly strange and interesting sport. It's a lot of fun, but you don't have a lot of agency in it. You sit in a bobsled, you go down an icy track, and really, there is only one way to go. But people can become experts in it, and can indeed measure themselves against each others skills; it's an olympic sport, and I remember my own first encounters with bobsledding as a child, when my father and uncle and aunts took me, and it was thrilling like a roller coaster and intoxicating upon my first encounter.

But again, ultimately, there's only one place to go.

The vehicle is the LLM, you are the passenger. And I think the amount of agency people have over their journey is greatly reduced from what they feel like it is. More than just a slippery slope, it is a pre-crafted journey.

At the top of the chute, people tell themselves they're going to use these tools as a kind of fancy autocomplete. As they descend, they say they'll spin up some agents to explore ideas, but they'll write the code themselves. Next their agents are generating the code for them, but don't worry, but they'll review all the output. Soon they're plummeting downward and well, they don't actually review the code being spat out much anymore, but they trust the agents, heck maybe the agents are actually better coders than they are they say. And where does it go from there? From "I don't even code anymore" to "I don't even prompt anymore"?

At every stage of the process, the coder in question removes themselves from the process of producing code, and gives in towards a faith-based initiative of code production, that the LLM knows and does a good job of what it's doing. But what is the source of gravity pulling the sled along this icy chute?

It's simple. Generation is not the slow part of coding. Theory-building and review are. And plausible-enough things are extremely hard to debug and understand. But the machines are so fast at producing things. If you are going to review their work, you aren't really taking advantage of their most powerful property, which is speed. But theory-building and review are also the programmer's most important role.

To illustrate just how hard it is to detect and review problems with something which appears plausible, let's look at Ka-Ping Yee's remarkable dissertation, Building Reliable Voting Machine Software. It is a wonderful read, and highly approachable.

In the section "What makes software hard to verify?", Ka-Ping recognizes several major reasons why software is hard to verify: number of components, complex interactions, far-reaching effects, and nonlinearity. Notably, all of these problems are exacerbated by the patterns of code generation by LLMs. Still, let us leave that aside.

Ka-Ping constructs a model voting machine, and decides to see how hard it would be to verify that we know it behaves correctly. To push that exploration to its furthest, Ka-Ping Yee and David Wagner try an interesting experiment:

David Wagner and I decided to insert three bugs into Pvote to see if the reviewers would find them. We inserted what we thought would be an “easy” bug, a “medium” bug, and a “hard bug” to find, and chose each bug individually in such a way that an insider could conceivably exploit the bug to influence the results of an election. [...]
We decided to insert all of these bugs in a 100-line region of a single file, lines 11 to 109 of Navigator.py, and told the reviewers to look in this region. We did this both because the navigator was the most interesting in terms of the program logic and because we knew the reviewers would have limited time. The new version of the code that we gave the reviewers contained all three bugs, but we did not tell the reviewers how many bugs there were.
Yoshi Kohno, Mark Miller, and Dan Sandler participated as reviewers on the third day of the review. Dan was very familiar with Python and found the “easy” and “medium” bugs quickly, within about 70 minutes. Yoshi Kohno and Mark Miller found the “easy” bug after about four hours of reviewing. None of the reviewers found the “hard” bug.
Ian Goldberg and Yoshi Kohno participated as reviewers on the fourth day of the review. Ian Goldberg also found the “easy” bug within about two hours; none of the other bugs were found on the fourth day.
The reviewers spent a total of about 20 reviewer-hours focused on the task of finding the bugs in this 100-line section of Navigator.py.

Ka-Ping chose from a highly seasoned group of reviewers who were even deeply familiar with security threats. Mark S. Miller has been a personal mentor to me throughout my career, and is one of the programmers I have learned most from and studied the work of most closely. I talked with him about the experience at one point. He remarked on how it took a significant amount of time to find the easy bug, hours to find the medium bug, and that nobody could find the hard bug... but the big observation (which was said to me personally, and is not recorded in the dissertation) was that "the astounding thing is that once the bugs were pointed out, we all agreed that they were retroactively obvious, and that we should have been able to find them!"

If some of the best programmers in the world struggle to find bugs they even know must be there within a 100 line program, there is simply no hope for humans to review the volume of output from LLMs.

And so there is only one thing to do: don't bother. At each step, remove yourself. You tell yourself you won't, but you do. You give in to the chute and the shape of the vibe tunnel, and down you go.

Vibe sickness and the colonial settlers of the uncanny valley

The term "AI psychosis" is thrown around a lot these days to describe anyone or any state of poor behavior or outcomes due to genAI usage. But the original description of "AI psychosis" was closer to something clinical, a description of people quite literally experiencing psychosis from encounters with chatbots which reaffirm far too much of the user, spinning them into spaces of delusional detachment from reality.

But we should have something to describe the general sense of unwellness that seems to be befalling this world, and the best phrase of which I first saw in a post from Glyph:

On the way home from #PyConUS 2026. Quite an experience this year; very intense. No point in sugar-coating the part where there is a pervasive vibe-sickness, open source is suffering a massive sustainability crisis, slop security PRs are overwhelming everyone (etc etc). But there was a lot of hope, a lot of energy, a lot of effort toward mutual understanding, and (surprising to me) a lot of appreciation. Including for my own work, both writing and coding.

I like the phrase "vibe sickness", and if you aren't speaking of a form of literal psychosis, I think it's a better phrase.

Vibe sickness is everywhere... heck, perhaps we are on the verge of, if not experiencing, a vibe epidemic. Everyone complains of slop, and yet nobody using these tools wants to self-describe their outputs as slop. Yet slop seems to be everywhere, and infecting one's everyday experience: posters of food at your local restaurant that have plausible and yet incomprehensible designs, the helpdesk support chatbot you wish you could make physically manifest so you could throw it off the edge of a cliff, age verification code, and if you're a maintainer of an open source project, slop issues and pull requests.

The thing is that all of this tooling is useful for some things, but the term "genAI" points at exactly what it's worst at: generating things. If we want to talk about finding problems, it's a different story. But even leaving aside the quality issues of the growing and wavering tower, there comes the problem of lack of understanding of how it is built, constructed, and maintained.

The worst part of all this is you can't opt out. A colleague or an open source contributor sends you a "generous contribution" that is absolutely slop and certainly not understood by the person who submitted it. You're left sitting there, parsing whether or not you're going to be rude even to ask if this is LLM generated, or to unwittingly become a user of vibecoding workflows yourself by indirectly interacting with the agent through trying to respond to the issue/PR.

You can't escape.

To quote Glyph again:

Protesting LLMs by refusing to use any software that includes them feels like attempting to protest the introduction of tetraethyl lead into gasoline by refusing to breathe until everyone stops putting it in their cars. So I am drawing my personal moral lines in such a way that I will probably accept this.
But please don't mistake this for excitement about huffing a bunch of vaporized lead.

Well put. In the meanwhile, the uncanny valley colonizes our world and transforms it into its own.

But there is a rot growing beneath our feet and within our walls as our world is swapped out with systems nobody understands. And I fear what it's going to be like to recover from this all, the price we do not even yet realize we are going to have to pay. For this reason, any project that chooses not to engage with current genAI stuff, I tend to gain respect for.

But perhaps you can't opt out from aiding the problem. Your work won't let you, you're stuck in some situation... I don't mean to judge, but I do mean to end with a perspective.

Sometimes I sit as the passenger of a car and watch the driver of said car get angry at someone biking on the road. It feels bad, because sometimes I bike on the road, and without sufficient infrastructure, bicyclists risk getting hit by car doors parked on the side of the road, squeezed out by impatient drivers, etc.

I also drive. When I do, and there's a bicycle in front of me, I pause, and as the world broils to death, I take a moment to be thankful for their presence, and to think about how we could change the shape of the terrain to allow bicyclists to participate more safely (which would also help me drive more easily too, or choose to bike when I can).

May we not give up on ourselves, and not lose faith in our ability to participate towards building a better world.

Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

Mon, 13 Jul 2026 09:29:25 +0000

"In the AI bubble, we are pressured to build things nobody wants, poorly. Pop the bubble."

Redirecting from /post/zed-creator-calls-spade-a-spade/ to /post/zig-creator-calls-spade-a-spade

Garbage for humans

Sat, 11 Jul 2026 06:31:20 +0000

unstory

If this is the solution, I want my problem back.

2026-06-29 01:49

Few months ago Cloudflare introduced Markdown for machines:

As a business, to continue to stay ahead, now is the time to consider not just human visitors, or traditional wisdom for SEO-optimization, but start to treat agents as first-class citizens.

Feeding raw HTML to an AI is like paying by the word to read packaging instead of the letter inside.

You get HTML, trackers, cookie banners, popups, and JavaScript. This needs a browser built by thousands of engineers just to show you a paragraph.

Machines get the clean version.