raggi

Want a big name? RedHat.

Tides have shifted somewhat, but I suspect this may still be rejected.

Unfortunately a lot of people’s experience with such proposals was also historically getting gaslit by a brigade, so a lot of folks moved on and won’t bother trying again.

Go/GC are mostly fine for medium frequency medium scale mid stack problems.

It’s bad for high frequency computing. It’s bad for very small targets, for very large targets, and by association software that lives at the very bottom of the stack.

Go is a high efficiency framework for writing mid sized servers, not a systems language. The runtimes hard opinions and closed interface are the reason for this enclosing definition and the GC is one part of that.

The second reason appeared to be simply "because we chose not to". The post seems to be pretty much content-less in any practical sense. I clicked on it because I do quite like this models average performance and I was hoping to see some kind of review content.

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.

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

    ~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

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

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 :'(

> 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.

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.

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.

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.

When I last harassed Crawshaw about this and we discussed bits, he submitted https://github.com/C2SP/C2SP/blob/main/well-known-ssh-hosts....

Unfortunately neither of us has taken time (AFAIK) to go back and implement it anywhere.

webpki is on by default.

on terminal.shop, steal credit cards on jobs endpoints, perform identity theft on exe.dev, whatever you put on there