Definitely in the "they didn't stop to think if they should" category.

They probably did, and just determined that it would be fun.

The other week I had a fun project to implement IPv6 support in TempleOS. I did stop to think whether I should, and determined that absolutely not.

I asked Claude to start planning on doing it. It started referencing ZealOS, which is a fork of TempleOS and already has a functioning TCP stack.

That's when I determined that it would no longer even be fun, because someone else had already done all the heavy lifting, and gave up.

wasn't a lack of networking what made it a temple, untouched by the influences of the corrupt internet or something like that? idk I'm not like a Terry Davis scholar by any means but I always figured he did that limitation with some kind of reason in mind

Me and some friends of mine thought it would simply be funny if we gave the temple just IPv6 (no v4) support.

About 15 years ago I gave some networking courses at a local education center, it was all young kids (18-20 years old). When I told them that the speed we got back in the day was 4 kilobytes per second (56k on a good day), they didn't believe me at all.

I remember using a “high-speed” 14.4 kbps modem. I mean, these were thousands of bits per second, really insane. Faster than many LLMs.

At 2400, you could watch the characters from the BBS come up on your screen, but at 14.4 practically the whole page came up at once!

Forged under blue moon light for perfect electron alignment inside the wires.

Don't forget to use the full moon to recharge the quartz crystals in that analog gear

Ah, that's why Paix Dieu is such good beer. The electrons are aligned.

I remember Technics used to advertise with amplifiers that used bamboo somewhere in the capacitors? Always wondered if there was actual bamboo in there somewhere and what the electrical effects were...

they use bamboo in the production of special carbons used in capacitors in a lot of devices.

it's sustainable, apparently. I don't know anything about it really.

Hey guess what forum flagged this story.

money is on the line

Short term gain for long term loss

Short term gain of money in exchange for for short term loss of democracy.

Wouldn't show that create vitality and more money? Or it's more of fear, I think the spineless adjective stands

I'm really missing something like Cisco DMVPN. A VPN mesh between different routers where all routers have a connection to each other, so that all traffic doesn't have to pass through the hub. And that runs on a router, because all these solutions only run on a regular computer with a complete OS.

Check https://tinc-vpn.org/ it may run on your router if you're running openwrt or similar

Out of curiosity, why? Because you dont want to run software on users devices?

points finger you son of a bitch, I'm in.

I'm a big fan of Guava's EventBus. Easy to implement and straightforward to understand. This library does seem to require more setup and I don't see the immediate advantages, also why does it require an instanceProvider? I don't understand what that does.

Emissary really shines if performance is a top priority.

The setup is more or less similar, you register a bunch of event handlers when initializing the library. The main difference is that, in addition to events, Emissary also supports "request" messages. Requests enforce the invariant that only one handler should handle it - if there are multiple handlers registered for a given request, Emissary will throw an error. That, and some extension points which is only needed for more advance use cases.

The InstanceProvider allows users to let the dependency injection (DI) framework of their choice instantiate the request/event handler classes (see https://github.com/joel-jeremy/emissary?tab=readme-ov-file#e...). This is in contrast to the way EventBus does it where subscribers need to be instantiated at startup time. By leveraging the DI framework, additional services can be injected to the handler's constructor.

The point is to not take the whole server down with it. Keeps the other applications working.

Even on desktop it's terrible, I wanted to protect some private keys of a Java application but there is no way to talk to a TPM using Java so handsandshouldersup gesture.

The TPM needs a way to authenticate your Java application, since the TPM otherwise does not know whether it's actually talking to your application or something pretending to be it.

This means you generally need an authenticated boot chain (via PCR measurements) and then have your Java app "seal" the key material to that.

It's not a problem with the TPM per-se, it's no different if you were using an external smartcard or HSM - the HSM still needs to ensure it's talking to the right app and not an impersonator (and if you use keypair authentication for that, then your app must store the keypair somewhere - you've just moved the authentication problem elsewhere).