The build time claim in the blog post is dubious, part of the problem is CGO isn't fast, but also if build time was really a motivator the null build path is entirely unoptimized for objects with long build times:
cached null (no changes) build:
~github/unstablebuild/rune % make
pre-commit not installed; skipping git hook setup
cd cmd/buildstamp && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/buildstamp
cd cmd/extension_chaos && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_chaos
cd cmd/extension_color_palette && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_color_palette
cd cmd/extension_fuzzy_search && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_fuzzy_search
cd cmd/extension_go && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_go
cd cmd/extension_python && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_python
cd cmd/extension_rtc && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_rtc
cd cmd/extension_rust && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_rust
cd cmd/extension_zig && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/extension_zig
cd cmd/runefox && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/runefox
cd cmd/sshshop && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/sshshop
cd cmd/walkbench && CGO_ENABLED=1 go build -ldflags="-X unstable.build/rune/internal/debug.Tag=$(git describe --tags) -X unstable.build/rune/internal/debug.Commit=$(git rev-parse --short HEAD) -X unstable.build/rune/internal/debug.BuildDate=2026-09-11T20:16:22Z -X unstable.build/rune/internal/debug.Package=six" -o ../../bin/walkbench
make 35.90s user 5.88s system 191% cpu 21.846 total 1975848 rss
vs. cached non-null (changed) build:
~github/zed-industries/zed % touch crates/zed/src/zed.rs
~github/zed-industries/zed % cargo build
Compiling zed v1.18.0 (/home/raggi/src/github.com/zed-industries/zed/crates/zed)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.42s
cargo build 10.15s user 9.34s system 228% cpu 8.531 total 7930312 rss
Build times are a valid thing to care about and talk about, but the claims implied don't stand up to scrutiny.
Similar reflection, I ran `kitten __benchmark__ --render` in rune, the CPU time spent was 1:55. I ran the same in a libghostty based terminal emulator and spent 0:44 on CPU.
I say this only because yes you can do engineering to meet the benchmark without dropping to deeper systems layers, but closing the gap on efficiency is hard. I'm not saying this to be a downer on your project - an IDE and VTE in Go are a fun project to have around, but the blog post makes implied claims of equivalence with moderate investment - but I think that's limited to single benchmark chasing. I say this as a polyglot who's day job is a Go based program that would be far easier to optimize in a systems language.
If you're going to run a benchmark, at least post the results. I was planning on writing up a different blog post about the terminal optimization journey, but I actually used `kitten __benchmark__ --render` quite a lot to optimize it:
rune --version
Rune v1.2.1 (HEAD is 40bf9cc1)
Results:
Only ASCII chars : 1.13s @ 177.2 MB/s
Unicode chars : 1.44s @ 123.2 MB/s
CSI codes with few chars : 2.95s @ 33.9 MB/s
Long escape codes : 6.25s @ 125.5 MB/s
Images : 2.76s @ 193.1 MB/s
You just compiled 9 extensions, a purpose built benchmark program, a toy ssh shop I built, a toy TUI browser and Rune, in serial. It's right there in the output. Try `go build ./cmd/rune` for a fair comparison.
I have a friend whose wife has strong sight challenges. He once swapped a much newer and more powerful card with me for my last matrox card, iirc it was a millennium ii. The matrox utilities included with the drivers had one of the best desktop zoom systems ever delivered on windows and this was worth more to them than anything else.
always have! our darwin and windows clients are closed source, but they wrap the oss implementation in github.com/tailscale/tailscale and you can see and even use all the same hooks yourself.
the control plane is closed source, but headscale is an open source alternative that we embrace and encourage people to use if it meets their needs/desires
> But, at the same time. A design that requires everyone to implement their own protocols and everyone to refix the same bugs in their own compositor is inherintly bad.
Consider that if every DE wrote their own Xorg implementation the story would be the same.
A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
I spent some time in the last week fixing lowdpi font rendering in cosmic, enabling me to switch to it. I then discovered that cosmic-comp's VRR had a terrible feedback path causing conformant applications to stutter badly, so I have large patch stack rewiring full screen feedback, tranche compatibility, fence timing and so on (it's fucking buttery now though, which is nice). That then showed up some input processing bugs becoming visible via playing videos in firefox, leading further to me discovering that cross-plane locking was causing frame drops too. Now I've got a giant stack of shit I need to cleanup and upstream - but the end result (along with the freetype render patches I got into Firefox a while back) is a better DE than I've had on Linux in decades. Maybe if upstreaming goes well I'll do MPO for an encore.
> In X, if the WM crashes, X is still running, and you can just restart the WM. In Wayland, if you hit a bug it takes everything down with it.
See above, the WM did not need to embed the compositor. That's not a protocol requirement, it's and implementer choice. I actually really wish it didn't. Of all the aforementioned patches only two are in Smithay. As I was actually fixing compositing for the workflow I just had to suffer through I would have had to restart pretty much the whole session anyway - though in fact the later stages of my workflow I was only directly killing cosmic-comp and cosmic-session was automatically restarting it all. No really good way to recover the surfaces though, so apps still need to restart.
This is not unlike the _another_ bug stream I tracked down this evening, where cosmic-applets would fail to display tray icons on both displays correctly - that turned out to be a bug where one icon provider was unresponsive to part of the protocol, coupled with a synchronous dispatch from the event handle into that blocking return call. Perhaps more interestingly though that manifest during diagnosis something I've seen a lot in other DE chains where tray icons for auto-started electron apps were highly sketchy - well a common electron wrapper gives up entirely on the first whiff of an error with the dbus interface and doesn't retry.
Years ago I gave up on Linux DE's because reconfiguring xft, gnome, etc was too much of a time sink. How far I've come, now I'm back :'(
> A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
Dude, because that is how wayland is designed. X is a display server. Wayland is a protocol with implementation. If you want tiling, you have to roll your own, with ALL the protocols that are needed. It's up to clients to render. It was one of the fundamental critiques people had of the whole thing. 15 years in, and it's still the same. Need Vulkan rendering? See you in two years. And then every single WM has to implement it. Not even the basic premise of fractional scaling is solved properly, except in the one use case which is single monitor usage.
It's not about collaboration. wlroots was an attempt at having a standardized layer, and many protocols made it back into upstream actually. But even there, no two wlroots compositors are the same. We used to call these WMs, because the compositor layer could be separate on X. Anyway, bugs persist for years, some parts are never fixed, lots of basic features that existed in X for decades needed people to implement in their own compositor report back and then create a standardized protocol. So KDE has their own, gnome has their own, Hyprland recently rolled their own, etc.
And then there is of course gnome, which seems to want to break random basic functionality for no good reason(hello tray icons). Gnome of course didn't use to be like that.
But a plug, the absolute best wlroots based compositor I have used is mangowm[1][2]. You report a bug in the morning and in the afternoon dreammaomao has a solution for it. Of course I'm exaggerating a bit, but I think I've used pretty much every major Wayland compositor extensively so far.
Hopefully forever tbh until a proper alternative to XWayland arrives:
XWayland is essentially the missing mid-level "Wayland client library" which fills the feature gaps caused by missing extensions of the underlying Wayland implementation and it provides a common and fully featured GTK/KDE-agnostic window managemnt layer. Until the Wayland project releases a client library 'for the rest of us' with a similar intent, XWayland is still very much needed for applications that don't want to or cannot link against GTK or KDE for various reasons.
Agree. It sometimes feels like it gets forgotten in the wayland vs xorg divide.
One of the nice things about flatpak (another contentious topic), is that for GUI apps where it matters I can trivially set whether I want to prefer xwayland vs wayland, and keep compatibility. It's very nice for the few apps that are still xorg hardcoded and with flatseal, or KDE app settings I don't need to mess with setting the environment variables myself.
> Fourth, there is a bandwidth concern. FHE encryption schemes generally increase the size of the data being encrypted, and the user must send the server a special set of encryption keys to enable the computation, which are relatively large as well. The special keys need only be generated and sent once and can be used for all future computations, but they can easily be gigabytes in size. In one example FHE scheme with lightweight keys, a ciphertext encrypting a single integer is on the order of 25 KB, and the special keys are about 0.5 GB. In others, 16,000 or more integers are packed into a single ciphertext of similar size, but the keys can be 10s of GiBs.
I'm still a bit skeptic - 1000x sounds overly optimistic and only looking at encryption transformation without any operation is already at least 10000x with scheme mentioned in that quote.
Sibling comment estimates lower bounds of current research at minimun 10^6 overhead which sounds more realistic.
We have very good reasons for our checkpointing model, related to our backup + disaster recover strategy, along with resource cost. It might be worth writing about one day, so I'll not give away all the details, but in very short form, we organize a backup strategy that has minimal pause time, avoids doubling the page cache cost of the database, and enables extremely fast byte-copy restores in disaster recovery.
SQLite has an online backup API as well, but it is slower and requires a significant additional page cache cost.
The team chose SQLite early on (there are some blog posts about this) and then we vertically scaled against the SQLite architecture. There are subtle ways you come to depend on the proximity/latency when you scale with local storage that mean switching requires a lot of non-obvious work - it’s probably the largest hazard for embracing SQLite in a growing saas - but at the same time you can push the vertical scale pretty far, which has great margins.
Had we scaled a different architecture of database there’s little reason to believe it would have been plain sailing as seems to be implied here.
One of the strongest teams I worked with, working on an extremely large and ambitious project used to answer a lot of product/executive type questions regarding missing areas that we knew how to author and could safely assume general design consensus “it’s just typing”.
It was a very useful contraction in the right senior circles where there was a pretty good understanding of the meaning and decently reliable assumed consensus.
I eventually stoped using the phrase because it had started leaking deeper into the team and the impact on earlier career or less confident programmers was often no longer positive, it could be misinterpreted in lots of different ways but the most harmful was when it would further decimate confidence and discourage requests for help when something wasn’t obvious to the ultimate author.
As with almost every attempt to generalize in software engineering the repetition or extrapolation beyond the context in which it was intended can have negative side effects, it doesn’t matter if it’s a simple notion like “dry”, or a comment like “code was never the hard part”. None of these phrases survive context loss and still retain efficacy at general receivers.
Next step the ads become increasingly sophisticated prompt injection to ensure they make it to the user, but the prices plummet in the meantime because the ads have low efficacy. They get purchased mostly by the scammers and by the time they start showing up in user chats they’ll be full on LLM assisted interactive user manipulation campaigns with far worse outcomes than the worst of YouTube and social media ads.
I understand that most people don't use it and indeed rely on tofu, but the statement is not absolutely correct.
ssh server keys can be authenticated using (the DNSSEC "CA" system and) SSHFP, and it's possible to setup a signing CA for the host key (similar to ssh certificates, however not applicable for foreign servers).
And of course, the fingerprint could be advertised out of band e.g. on the homepage with tls
sshfp is not PKI. It's an option and it is off by default in ssh(1). In practice no one actually deploys it, exe.dev, terminal.shop, jobs.{whoever.com}, etc. I've yet to see an in the wild deployment. The aforementioned sites let you perform electronic payment transactions over ssh without it, which is probably a PCI violation tbh, but auditors aren't good enough.
Agreed. Amid all this hype, once again we continue to see such disregard for basic security implications and using ssh outside it's intended use-case; especially sshing into random servers.
Now we wait for the discovery of an RCE, key leakage vulnerability or a security bypass that leads to a trivial mitm attack to magnify why ssh apps make no sense security wise.
SSH does in fact have a PKI, just not a global one. Large-fleet SSH installs all tend to use certificate authorities, for this reason (and to simplify SSO).
I don't understand the impulse behind these things --- this is a bootstrap mechanism for a global PKI for SSH. But cold introductions to SSH hosts (that is, first connections to hosts you have no business or technical relationship with) virtually never happen. What problem does it solve?
When you see people advertising a coffee shop at a conference and people TOFU'ing on conference wifi then plugging in credit card numbers, the picture gets a little more clear.
So really the trend I'm talking about here is people turning SSH into a browser, hosting apps behind SSH that expect a much higher volume of TOFU happening, which is a departure from the "first time i setup my vps" kind of case.
Honestly at this point I'd be kind of happy if we could just use an x.509 cert from a webpki acme provider in the sshd and be done with it, for the host identity part.
cached null (no changes) build:
vs. cached non-null (changed) build: Build times are a valid thing to care about and talk about, but the claims implied don't stand up to scrutiny.reply