It's the opposite for me for one reason: hashtag follows!

There are very few people I want to follow for everything they have to say. I am interested in subjects, topics. Mastodon's hashtag follow feature gives me this. It's not perfect, you need to be on a relatively large instance to take full advantage of it (since it only picks up toots that make it to the instance) but it's still much, much better than no hashtag follow at all.

The extensive IRCv3 support for one thing. chathistory support in particular is a big one for me since we rely on it on my personal server.

If you scroll down to the Features section on the linked page that gives a good overview.

Hi, I'm used to save locally chat history of channels I'm listening to.

In hexchat GUI client chat history is locally found in a simple text file, one line per message in .config/hexchat/logs/irc.libera.chat/xxx.log

However I've found no option to create such a log with halloy, am I missing something in the documentation?

Found https://github.com/squidowl/halloy/issues/91

Not even that, Postfix didn't exist in 1994. This is a 2025 mail server setup and about as vanilla as it gets.

Easy to see for yourself using the throttling option in the developer tools of popular browsers.

Datahand user, for me switching back and forth between the DH and a regular keyboard (a Thinkpad for the most part) is not a problem at all. It doesn't even feel particularly annoying, I think it's because it almost feels like a different input device category. Kind of like playing the same game on the Steamdeck with controller input and then later on the desktop with keyboard and mouse. I might prefer one but I am fine with the other too.

BTW, I've played about 15K matches of my favorite MOBA on the Datahand, works surprisingly well for that, I imagine the Svalboard would too.

I am a longtime (25+ years) Datahand user. I have converted my units to a USB capable controller long ago and I have some extra ones as spares/parts but it might be difficult to get another 25 years out of them.

Haven't tried the Svalboard yet but it's the only obvious way forward that I know of so happy to see any new information about it. I'd be especially interested in the opinion of other Datahand users regarding the Svalboard, specifically the hardware, the switches and overall feel.

Ex-Datahand user, current Svalboard user: (Disclaimer, I work on their firmware as a volunteer, they send me hardware.)

The designer was 100% dependent on his Datahand, now he uses a Svalboard.

When I got sent my first Svalboard, it was so close feel wise that my old muscle memory came back instantly and I started complaining that the layout wasn't the same as the old Datahand Dvorak layout. I ended up doing a faithful port of that layout, then ever time evolved it to the layout I use today.

If you doubt, order a test cluster. You'll see how close it comes.

On the discord some users are willing to meet-up with people to let them try a board in real life.

The Go toolchain is a nice illustration of this approach working in practice. It fully bootstraps in 90 seconds on my aging laptop and since it's fully self-hosted it doesn't even need a C compiler unless you want cgo support.

LLVM takes 2 hours to build on the same host and zig (with the LLVM backend) is another 20 minutes. It will be awesome if that can be brought down to 2 minutes or less.

Is that building Go with Go? Or actual bootstrapping? Check this out...

Building Zig with Zig:

    andy@bark ~/s/zig (master)> time zig build
    
    ________________________________________________________
    Executed in   11.67 secs    fish           external

Bootstrapping with only a C compiler dependency (not even make or shell!):

    andy@bark ~/s/zig (master)> time cc -o bootstrap bootstrap.c; and time ./bootstrap
    
    ________________________________________________________
    Executed in   55.10 millis    fish           external
    
    gcc -o zig-wasm2c stage1/wasm2c.c -O2 -std=c99
    ./zig-wasm2c stage1/zig1.wasm zig1.c
    gcc -o zig1 zig1.c stage1/wasi.c -std=c99 -Os -lm
    ./zig1 lib build-exe -ofmt=c -lc -OReleaseSmall --name zig2 -femit-bin=zig2.c -target x86_64-linux --dep build_options --dep aro -Mroot=src/main.zig -Mbuild_options=config.zig -Maro=lib/compiler/aro/aro.zig
    ./zig1 lib build-obj -ofmt=c -OReleaseSmall --name compiler_rt -femit-bin=compiler_rt.c -target x86_64-linux -Mroot=lib/compiler_rt.zig
    gcc -o zig2 zig2.c compiler_rt.c -std=c99 -O2 -fno-stack-protector -Istage1 -Wl,-z,stack-size=0x10000000 -pthread
    
    ________________________________________________________
    Executed in  305.06 secs    fish           external

> Is that building Go with Go? Or actual bootstrapping?

Normally it's just Go with Go. Besides the Go compiler you need bash if you want to use the normal bootstrap script but not much else. You can build your way up from C by building an old enough version of Go that was still C based but that's not usually done these days.

> Executed in 11.67 secs

Nice!

Sometime after Minix 3 but before it had attained the critical mass for a self-sustaining community, compilation times went from 10 minutes on low-end hardware to ~3 hours, and the answer to the question "Why?" was "LLVM/clang".

And a decent tiramisu.

> Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase.

That's true but worth noting that "optimize" here doesn't necessarily refer to performance.

I've been using Gentoo for 20 years and performance was never the reason. Gentoo is great if you know how you want things to work. Gentoo helps you get there.

If it wasn't for performance, what was gained in using it over something like Slackware and building only the packages you needed to?

USE flags. You can build packages with specific features enabled or disabled, which can further reduce your dependency tree.

Reducing the dependency tree gets a bit more complicated once you consider that now you have to satisfy not only runtime dependencies for all packages but also build-time dependencies. There may be ways of cleaning that up after a build, but next time you want to emerge a new package you'll just end up having to re-build the build-time dependencies, so in practice you'll just end up leaving them there. There is an ability to emerge packages to a separate part of the filesystem tree (ROOT="/my/chroot" emerge bla), so that you have one build-time system act as a kind of incubator for a runtime system that gets to be minimal. But you'll end up encountering problems that most other Gentoo users wouldn't encounter, having to do with the separation between build-time dependencies and runtime dependencies not being correctly made in the recipes. Personally, I had been relying on this feature for roughly the last 10 years, but there has been steady deterioration there over the years and I eventually gave up late last year.

This is a good point. I've been using Gentoo since early 2004 (the dreaded Pentium IV era, Lol). Lately, I run into this with dev-lang/tcl only being need to build dev-db/sqlite. I actually think it's pretty weird that software intended to be as widely used as sqlite with as much of a free base of supporting devs doesn't just do the extra effort to use a Makefile.

For building specific packages with particular flags, wouldn't slackbuilds have been sufficient?

Long time ago when I was using it I preferred Gentoo because of ergonomics and better exposition to supply chain.

Slackware was very manual and some bits were drowned in its low level and long command chains. Gentoo felt easy but highlighted dependencies with a hard cost associated with compilation times.

Being a newb back then I enjoyed user friendliness with access to the machinery beneath. Satisfaction of a 1s boot time speedu, a result of 48h+ compilation, was unparalleled, too ;)

> If it wasn't for performance, what was gained

A new hobby

That's very fair, I've certainly tinkered with stuff for the fun of it when there were easier or more suitable alternatives.

  curl -s https://rdap.verisign.com/com/v1/domain/example.com|jq -r '.events[] | select(.eventAction == "expiration") | .eventDate'

And https://data.iana.org/rdap/dns.json to find the endpoints for TLDs.