On the Road
1 points • 0 comments
@kwindla
From 5/27/2012, 7:21:57 PM till now, @kwindla has achieved 2240 Karma Points with the contribution count of 347.
Recent @kwindla Activity
FWIW we did two pretty extensive proof-of-concept prototypes (one in pure C++ and one in Rust) before choosing Rust for this project. I, personally, thought that we would choose C++. I'm a big "choose boring technology" advocate. [1]
In other words, we tried hard to document a lot of before-the-fact rationalizations to go with the inevitable after-the-fact rationalizations. :-)
I would say that both the client and the media server (SFU) side of the work are challenging in their own ways, if you are trying to support a large variety of use cases, features, and sessions with large numbers of participants.
The client-side and server-side code end up being tightly coupled and you end up having a lot more client-side code than maybe is obvious if you're building an application that uses WebRTC in one specific way. For example, handling fast subscription to and un-subscription from batches of tracks is non-trivial, but important if you're implementing "grid mode" client views.
The goal of the approach we're taking here is to be able to support a bunch of different platforms at the same level of performance, stability, and feature parity. Web, iOS, and Android are the three most important platforms. But people are also using WebRTC on Flutter, native Linux, macOS, Windows, Unreal, Unity, and various embedded platforms.
We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now.
`daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.
Are Apple AirTags Being Used to Track People and Steal Cars?
8 points • 1 comments
Archbishop Emeritus of Cape Town and Nobel Peace Laureate Dies at 90
2 points • 0 comments
Silbo Gomero: ‘Special and Beautiful’ Whistled Language
45 points • 13 comments
Mastering the Glyphs
1 points • 0 comments
Ancient History Shows How We Can Create a More Equal World
1 points • 1 comments
I'm genuinely interested in the reasoning behind this:
> The honor system is fine for a fun game with friends, but not fine in anything "competitive".
Is the honor system "not fine" in competitive situations because you have a deontological view that the only rules that matter are rules that are mechanistically enforceable, or is it not fine because you have a consequentialist view that competitive situations will usually devolve into something messy and unfair if all rules are not mechanistically enforceable?
I see the logic and appeal of both lines of reasoning, but they're quite different and people might easily disagree (for different reasons) with each.
See also my comment about ultimate frisbee, elsewhere in this discussion.
There are both "norms" and "rules" at play, here. Reading this article made me think about watching high-level ultimate frisbee transition from everybody calling their own fouls to having referees.
I mostly watched this happen on usenet, and I haven't paid any attention to this in years, so I may be getting some of this wrong. But my understanding is that for a long time everybody was (mostly) happy with the honor system of players calling fouls. Then one guy forced that to change by aggressively abusing the honor system, with the explicit goal of making everyone else to decide that adding referees to the game would be the best solution to him being a jerk.
In the case of Bridge, it sounds like a really interesting case of an extensive system of rules, with a complicated and somewhat opaque system of norms overlaying that. So, sort of like real life.
After a year of ‘rampant’ cheating, elite bridge tries to clean up
65 points • 106 comments
The Future Is Electric
1 points • 0 comments
The Sky Ranches of Baja California
2 points • 0 comments
> There’s also fly doing userland tcp over userland wireguard because peeps might not have a local wireguard client.
Oh, yeah! That whole thing [0], up through the integration with flyctl, is fire.
Sure. We [0] make APIs for live video and audio, so we do a lot of different kinds of network testing. Over time, we had cobbled together a variety of tools to support load/scaling testing, CI/CD, testing during development, and helping our customers debug and test their applications. For all of these, some ability to simulate packet loss, latency, jitter, and other network realities is somewhere between helpful and critical.
I'm a big fan of Snabb, and had a few conversations with Max Rottenkolber, one of the Snabb authors, about how we might tackle building a common network-simulation framework that we could use across all the different kinds of testing we do. Max suggested more or less the approach that you can see in the synthetic-network repo. (He wrote a series of documents during implementation that are really fun reading. They are in the /doc directory.)
Since we increasingly use Rust in various places, and our use case was a bit different than the core use cases for Snabb, Max took a swing at porting parts of Snabb to Rust for the synthetic-network project. That worked out really well, and that Snabb-implemented-in-Rust is now Rush!
So much interesting stuff happening in userspace networking these days. It really feels like the pieces are almost there to treat the network as just another part of the stack that you're programming. (Albeit a pretty low-level part!)
If you're interested in Google Snap, you might also want to take a look at Snabb [0], and Rush (Snabb in Rust) [1].
For an example of how this stuff is useful at sub-Google scale, we just open-sourced the Rush-based tools we use to test our WebRTC code [2]
[0] https://blogs.igalia.com/dpino/2017/11/13/snabb-network-tool...
The Case for Location-Independent Salaries
29 points • 7 comments
Tips to improve WebRTC video call browser performance
7 points • 0 comments
Similar experience going to a French school for the equivalent of 10th grade, after attending US schools until then. My first math test grade was very low, mostly because I didn't write things in the correct colors. That was quite a shock.
site design / logo © 2022 Box Piper