HN user

basro

32 karma
Posts1
Comments22
View on HN
Iroh 1.0 1 month ago

I wish it had support for a system similar to webrtc's offer and answer SDP messages.

From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.

This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure. For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.

For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.

I would be personally a little disappointed if Typst replaced LaTeX, but until that happens, I definitely hope that it continues to do well.

I'm curious about why you'd be disappointed. Is it because you think typst is an irremediably inferior technology to you or is it because you are invested in LaTex?

I do not mean to ask this in accusatory way. I'm not very well informed about typst or tex (I've only used typst once and I thought it was easy and nice).

I'm just curious about what is worse about typst that would make someone disappointed if that was the reason why you would be.

They differ in a similar way to how React differs from SolidJS.

In react when state changes the component functions that depended on that state are rerun to compute what the component should now look like. Then react diffs the new output with the previous to touch only the parts that changed in the DOM.

In solidjs the component function runs only once (when the component is instantiated), when state changes signals will trigger and cause the specific parts of the DOM that depended on them to change. This is generally more efficient.

I think I agree that it's akin to organized crime, it's a case of "the goal justifies the means".

You see the goal of forcing union usage as a noble thing so you agree with these means. If the goal was one that you don't see as noble you'd definitely agree that it's very organized crime like.

Thread-per-core 3 years ago

No, performance and power consumption should go hand in hand in this case. If you are strongly IO bound, paying for the synchronization is not really going to matter much I believe.

There are cases where you can be CPU bound and using the share nothing model would work out to your advantage. There's also the case where you only have one cpu core anyway (for example if you want to get all the juice out of a cheap single core VPS)

Thread-per-core 3 years ago

This is true but the rest of the ecosystem is not built for it.

If you try to use axum in this way you'd still need to use send and sync all over the place.

Thread-per-core 3 years ago

Instead of Arc and Mutex you'd be using Rc and RefCell. Wouldn't it be just as complex and verbose code-wise?

I understand that it is less efficient but in the case you describe wouldn't paying for a few extra atomics be negligible anyway?

So, how do you suggest a company would make profit while also not limiting to people who can afford paying for the product?

If you are thinking of the free to play model with microtransactions, I do not think that it would work as well for single player games.

Thanks, for the compliment. I'll consider writing a blog post in the future.

It's actually kind of playable on android at the moment, but only if you have a keyboard or gamepad plugged into the device.

I'm not really into mobile games and find touch screen controls a bit annoying to use so I haven't considered adding support for it yet.