By the end of June 2026? Old news.

This doesn’t seem Linux related.

Data storage: you can do pretty much whatever, they won’t look at your stuff unless you do something that attracts attention. Of course encrypt it anyway.

Streaming: yes that attracts attention if you stream to the public. If it’s edgy or pirated content you can’t use the big providers. If it’s your private collection that only a few people know about, it’s like the situation with storage.

If no database, how is revision history maintained? Of course while there’s nothing wrong with someone deciding to write yet another self-hosted wiki, is there anything special about this one? “apt install gitit” has worked ok for me when I’ve wanted a low hassle wiki.

Yeah use less -r. You can set that in your environment

export LESS=“-EX -r”

is what I use.

You can self host Jitsi and it’s nice. I haven’t done it yet though.

I was never able to get it to work reliably. For those mentioning XMPP, Jami uses a serverless approach with a distributed hash table instead. In principle it has better privacy but in reality it’s flaky. IDK for sure if the flakiness comes from the DHT but either way I gave up. I might try again sometime.

I’m sorry but this is kind of a wtf to me. What’s wrong with a text file? I thought I was being fancy by using org mode, which is just a text file with some markup. If you want to be really fancy you could use a bug tracker. fossil-scm.org has a built in one that I might try sometime.

Maybe you’re right and you could implement something like MLS in JS and/or WASM. I don’t know if those can open raw socket connections instead of using websockets. You’d need a raw socket connection to interoperate with other apps like Signal, but with websockets you could implement similar functionality non-interoperably, maybe even using a server side proxy to route to a Signal server (the proxy would never see plaintext).

There’s still the matter of making sure that the JS or WASM download isn’t tampered with. You have to trust the server that send it to you, which is in conflict with the E2EE notion of not trusting the server. There could possibly be a MITM attack by someone with a signed TLS certificate. Worst is if it’s served from a CDN. CDN’s have alway seemed to me like supply chain attacks waiting to happen.

Mxroute.com .

Yeah it kind of sucks but it exists. I’ve used it for a very small server, like 3 users. I won’t say “avoid” but unless it’s gotten a lot better since I tried it, you probably should look elsewhere for a long term solution.

E2EE with large groups is a hassle because you have to do messy key changing protocols every time somene leaves the chat (since you want to invalidate their keys when they leave). If you don’t mind the server (self hosted) seeing the plaintext that’s a lot simpler. Tbh I’ve simply used nextcloud chat or irc for stuff like this. I can’t really recommend nextcloud for various reasons but it was easy for me to set up a chat when I wanted one, since I already had a nextcloud server. Matrix is supposed to be the post-IRC IRC so I’d check into it, but I haven’t used it so far. I’m of the impression that Matrix isn’t E2EE (the server can see the private stuff) but maybe I’m wrong. I think Signal tries to be E2EE but has other problems, including that MLS (the E2EE mechanism) inherently requires a client app instead of being usable with just a browser.

Shorter version: instead of wiki software, use a static site generated from a git repo. It’s a valid approach. I think emacswiki may have once worked that way. Note that Gitit uses git for version management, so among other things you can copy your whole wiki with git clone. But it also has a built in web editor instead of just relying on git push.

You might try Fossil then. It uses something like 2MB of server ram instead of gigabytes. It makes me wonder where we all went wrong.

Is it public facing in the sense that randos will edit it? If not, the simplest thing is probably fossil-scm.org which is very light weight, but it’s actually a version control system with a built in wiki, so its editing interface is a bit weird compared with Wikipedia. It is pretty fast though I’ve only played with it, not run anything public facing from it.

Setting up Mediawiki is more complicated but it does have a familiar interface. I don’t know how much tuning and configuration you have to do to allow it to handle a lot of traffic, but obviously with enough caching and stuff, it scales all the way up to Wikipedia level.

I’ve also used Gitit and I think MoinMoin but not with any significant amount of traffic. Gitit looks like Mediawiki while MoinMoin is retro, like 1990s style.

It sounds like for this thing to be really useful, you have to replace the whole application ecosystem. Sounds like the basis of a new mobile OS or something. Capability based OS’s have been written before, though IDK if any have gotten any traction.

Guile is supposed to be embeddable in C so I’d hope it’s also embeddable in Rust, or at most needs some Rust bindings. That would be a good thing to write if it hasn’t already been done.

Yeah I don’t know the situation with Guile and threading, but is there really a serious performance bottleneck? What is going on that is slow? If it’s something like cryptographic signatures, it’s presumably using a fast library, so calling the same library from Rust wouldn’t give much of a speedup. If the Guile version is basically fast enough, running it in a single thread could be a decent workaround. Do applications really have to present capabilities millions of times? I’d think it’s something they’d do once at program startup, or maybe occasionally where the user would invoke some protected operation and the capability would temporarily be enabled. In fact maybe you don’t even need language bindings instead of a local socket to pass capabilities through. Then if you really needed parallelism in Guile, you could run multiple processes listening on the socket, instead of multiple threads.

I’ll look at that section of the whitepaper. I’m still a bit puzzled by this whole thing.

The white paper is 98 pages lolwut. Is there a maybe 5 page document explaining what this is and why you’d want to use it? Are there existing applications that use the current Racket/Scheme implementation? Why do you want to reimplement it in Rust? I had thought that Racket handled multi-threading, and of course Racket and Scheme are already memory safe (in the sense that C is unsafe). Are there significant performance problems in real use of the existing implementation?

Overall this seems like a rewrite project that should first get some sober thought to convince yourself that it’s worthwhile, unless you’re already convinced. Otherwise why not use your creativity to do something that hasn’t already been done?

I think that isn’t really a thing. Usually you would have a tape drive in a backup server for a network, and the backup server would have its own HDD, so you’d back up over the network to the HDD and then dump HDD to tape locally at close to the transfer speed of the disk. Higher capacity tapes have fast transfer and if your data source can’t kee up, the tape has to start and stop all the time, which slows everything down and wears everything out.

“Some TB’s” = single digits? Probably just back up to remote storage if you have enough network speed.

Keep it spinning and put stuff on it, or sell it, probably for more than you paid for it. Drives on the shelf tend to fail.

10K POH is a little more than a year, so it may still be under warranty.

“Anxious to use it” in colloquial English means that you are eager or in a hurry to use it, btw. The opposite of being afraid to use it, which might be what you intended to say.

amixer -q set Master playback 75%

Or whatever percentage you want.