donio

Yep, both are by the same author (emersion) and there is definitely a running theme in the project names.

Yes, they just download the app and enter the server name, username and pw. It's a private server and I manage the accounts so there is no registration step. And they only need to worry about any of this when they get a new phone.

I've been running Ergo for the past year for my friends/family chat. I went this route because of the ease of hosting, very low resource requirements and a protocol and codebase that I feel I can understand and debug if needed.

The v3 chathistory support and the always-on[1] multi-client[2] features paired with modern clients (like Goguma) go a long way at providing a modern chat environment. Most others on the server don't even know that they are using IRC.

The built-in websocket support is another key feature for me since it lets me to provide a web client just by serving some static files (I use Gamja for this).

[1] always-on: https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....

[2] multiclient: https://github.com/ergochat/ergo/blob/master/docs/USERGUIDE....

> Bluesky is NNTP, that is different servers have the same data.

Yes but with only one real server which has 99%+ of the users and the rest on single user Leafnode instances.

> It was Cyberspace and the Information Superhighway.

Regular people almost never used those words. Only the media did.

> (or very long lines)

Long line handling has greatly improved in emacs-29. Multi-megabyte lines are not a problem anymore.

xdiskusage is an FLTK program I use regularly. It's still one of my favorite ways to analyze disk usage. A nice feature is that it can take a du output file so it's easy use it with filtered du outputs, du runs from other machines or du-like output produced by other means.

https://xdiskusage.sourceforge.net/

For a site that claims to be minimalist/brutalist and has lynx in its name I was hoping that it would work without JS. But the edit/create page doesn't.

Other than the theme the two have very little in common. Memoir 44 is card-driven and uses dice for combat resolution so there is a lot of randomness. GHQ is a pure abstract with no randomness at all. On the gameplay side GHQ is much closer to chess than to M44.

BGG entry: https://boardgamegeek.com/boardgame/422478/ghq

How-to play video: https://www.youtube.com/watch?v=zfXPIhvFPjw

Space-Biff review: https://spacebiff.com/2024/09/25/ghq/

I always use my kindles in fully offline, sideload-only. My current one hasn't left airplane mode since I got it in 2018.

For most people the whole reason to do the exercise is to understand what is involved in a bootstrap process. When you don't understand something you stop and figure out what is going on. There is not much point in blindly running commands that you don't understand.

Depending on your preferred workflow you would typically have a tiny loader stub in a .lua file that you never need to touch and all of your code in Fennel. You can still add third party Lua libraries if you desire and seamlessly call back and forth between these and your Fennel code. You can even have a live REPL to eval code in your running Löve session.

> I actually get a lot of utility out of eww

I do too. And the underlying shr rendering library is invaluable when so much of email traffic is text/html. A bunch of other stuff like mastodon.el and devdoc.el rely on it too.

> It is getting increasingly difficult to use;

In my experience it's not that much worse than it was 10 years ago. By the time eww came about the JS-less browsing ship has long sailed. The sort of stuff that was working back then still tends to work now. We lost some good sites like the BBC text-only mode but also gained some nice text proxies like 68k.news and brutalist.report.

For GMail sync someone else has already mentioned Lieer which is an excellent tool for robust two-way syncing of emails and tags/labels between Notmuch (and anything that uses it) and GMail. It uses the GMail API so it doesn't rely on IMAP.

https://github.com/gauteh/lieer

If your PDFs have Author properties then you might be able to do "author:Heidegger" too. The Recoll PDF filter extracts some of these fields and if I remember right it can be configured to extract additional custom properties too.

A lot more than a decade. I've been using it for 15 years at it was a very mature project even then. Repo history goes back to 1999 and according to the history page the project's roots go back to the 80s. A bit like Postgres in this respect.

https://xapian.org/history https://sigir.org/files/forum/S2000/MUSCAT_note.pdf

Love Xapian, been using it for many years via notmuch (mail) and recoll (document indexing, mainly PDFs in my case).

It's been trouble free and very performant, a real workhorse.

https://notmuchmail.org/

https://www.recoll.org/

I remember this too. Very early on there were both proc and a /dev/kmem versions of ps and maybe top too.

Yep, found it: https://www.ibiblio.org/pub/historic-linux/ftp-archives/suns...

And the Linux kernel CREDITS file has an entry mentioning it too:

    N: Rick Sladkey
    D: utility hacker: Emacs, NFS server, mount, kmem-ps, UPS debugger, strace, GDB
    [...]

Not parent but keybindings are fully configurable. For example to scroll up with Shift-Pgup:

    bind -n S-PPage copy-mode -u
    bind -T copy-mode S-PPage send -X page-up
    bind -T copy-mode S-NPage send -X page-down

The first line is a top-level binding to enter copy-mode and immediately scroll up one page. The other two add bindings within copy-mode so you can continue to scroll up or down with those keys.

I also have a small hack in my .zshrc to start scrolling up with `M-v` (like in Emacs) while at a shell prompt:

    tmuxup(){tmux copy-mode -u}
    zle -N tmuxup
    bindkey '^[v' tmuxup

> seamless scrollback and push notifications

Both are doable with modern servers and clients thanks to v3 chathistory. Ergo (server) and Goguma (mobile client) in particular make this work very nicely.

IRC buries yet another contender. This one has hung on longer than most.

> this was filed against Netscape Navigator

Mozilla Suite rather than Netscape Navigator. This is from 2000 which was well into the Mozilla era and I don't think that Netscape bugs made it into Bugzilla anyway.

glibc won't be used at all.

With Go on Linux libc is only needed when the libc DNS resolver is used (instead of Go's built-in one) or if C libraries are used. superfile doesn't need either of these so it's very simple to build it as a pure Go executable which will be statically linked and contain no C code at all.

You are talking about backward compatibility, the parent thread is about forward compatibility. You won't have much luck running a modern executable on XP unless the vendor went out of their way to make that happen.

> What's worse is that you can't even really statically link it without herculean effort.

The program we are discussing happens to be written in Go so it's trivial to build a statically linked executable.

The WITH_XC_NETWORKING build option is off by default so the developers have obviously intended this to be a valid build configuration.

You can survives disconnects even with xlib, I think the abort is just the default behavior.

Emacs is the one program I know of that can actually do this. It can pop up frames (Emacs lingo for windows) on multiple displays at the same time and even mix tty and X11 frames. The Emacs session survives connection loss fine, frames on other displays continue working and you can reconnect if desired.

The one caveat is that Gtk used to have a bug that caused it to uncontrollably abort on connection loss but I build my Emacs with --without-x-toolkit (so it uses raw xlib, no toolkit) and that configuration has always been robust and performant. If I remember correctly the Gtk bug might be fixed now too.

That greatly depends on the type of applications you run and the toolkits and font rendering they use. My most commonly used applications (terminal emulator, Emacs) do their font rendering using the the glyph compositing functionality of the RENDER extension. Server side glyphs are created when a font is loaded and all the compositing is done on the server side based on the client's CompositeGlyphs requests. Same for images (in Emacs) using CreatePixmap and CopyArea.

Working with X11 client libraries written in other languages is a revelation in how much nicer an X11 client can be. CLX (Common Lisp) or xgb (Go) are some good examples.

(Talking about native implementations here not xlib bindings).

With the huge limitation of not being able to manage the windows of Wayland clients. This tool is an excellent solution for exactly that.