structural

Have you considered using GStreamer pipelines for this? And taking it one step further, if you want to use OBS generally, there's a plugin for OBS that allows you to integrate pipelines too.

The common case for the plugin is to do some preprocessing before importing the video into OBS, but you can also use the pipeline as a video filter, which is really powerful, because you can inject a filter into not only a single source, but also at any level of a nested scene. So you can scale/composite several inputs together and then the video filter can copy the source stream and encode/tee it to a file output. Might still be considered a hack of sorts.

Except it's really designed to composite video from a bunch of different places and broadcast the result, whether they are windows, screens, cameras, etc. And a rather lot of people don't want every screen to be captured, just the ones that they have selected. It's not a "screen recorder" program, really. And it's explicitly designed with an API to be remote controlled if hardware changes out from under it, so you can encode exactly your own policy logic on what to do. (External display plugged in? Disable my laptop source at full resolution and enable my laptop and monitor sources, side by side, with one scaled as necessary, and in this layout. But if I'm currently recording or streaming, don't do anything. - this is user-specific logic)

This could probably be automated using either an OBS plugin (if you really want deep integration and not running another program) or a standalone program (written in whatever language you want) that listens for display changes and pokes OBS using its websocket API. The hooks are definitely there to update source configs.

I (briefly) worked as a test engineer on a similar kind of contract. To meet the UX requirements for the system we were building, it had to be reliably operable in sea state 7+. The customer wanted touch screen interfaces. I exited that project when they were looking for volunteers to go spend time offshore in the Gulf of Alaska in bad weather, because that was the test environment they could find that met the requirements. Insanity.

The center is mostly offline, thinks both extremes are very small portions of the population, and doesn't post on social media. So they seem small but really there are a lot of people like this who aren't shouting into the internet 24/7, so you just remember that what you hear is all the extremists shouting, not the people you saw during the course of a week who weren't.

People really did that regularly. It does seem to be economically related, for a lot of reasons.

One aspect is that a single income really was enough to not feel extravagant to have a home, a family, and afford to go to the bar a few nights a week. (Part of this was there wasn't as much random other stuff to buy, it wasn't being marketed to you nearly as aggressively either.)

I certainly did this quite a bit in the 1990's, and in the early 1980's I definitely remember my father going out at least twice a week and then the weekends also being for going out and doing something as a family at least 2/3 weekends per month - like trips to a nearby city, or to a sports game, or visit other family, or whatnot.

I agree, which is why I used numbers from 2025 in my assessment, it's too soon to know if inflated 2026 numbers are a new normal or a one time bump. I think calling enterprise 5x larger than consumer based on 2024-2025 numbers is defensible, saying that enterprise was 10-15x consumer market just based on 2026 is yet unproven.

Once you remove laptops from the picture, the consumer market is small in dollars compared to enterprise and has been for awhile. This didn't used to be the case, but here we are.

Best estimates from last year are on the order of 50 million discrete consumer GPUs vs 7-10 million datacenter/enterprise GPUs. Sounds like the PC market is huge! but with average sales costs of well under 1k USD (a lot of the PC cards are budget variety, included with prebuilt computers, etc). it's only a $30-40b business. Those datacenter GPUs are averaging $50k each before the supply issues with HBM started to inflate everything greatly. But using that as a benchmark, that enterprise business looks like several hundred billions.

NVIDIA's latest filing reported $162b in revenue for datacenter compute in the last FY, so we know it's at least that large. Now add AMD, Intel, and everything going on in China that we don't have great numbers for. We can very conservatively say that the enterprise GPU market is currently >5x larger than consumer, in dollars, and it may be quite a bit larger than that.

The equivalent bike repair to software would be if the bike shop had to fabricate a new part for each repair, down to inventing the metallurgy itself. Would you trust your life to it immediately after that? Or would you make sure it was strong enough first?

In the simple case, the shop isn't really repairing your bike, it's deploying a fix (a new part) that has already been designed and manufactured. This is a much different and easier thing to do.

In the case of new features, let's say you wanted your bike to also attach a kite, so it went faster on a windy day. The bike shop proposes to do this by attaching the kite to a bolt that they want to put in the frame by drilling a hole all the way through this frame. Is this acceptable to do? Maybe, but who knows, really? How much testing do you want to happen before you trust your life that the frame won't collapse?

There's a lot of effort put into engineering things we take for granted every day. The upside to software is we think we can change it to easily do anything. The downside is if you care about reliability then that ten minute / one line change has hundreds to thousands of hours of test program behind it that we collectively pretend doesn't exist.

The way to prevent pileups is not to assume that everything will work correctly, including every system on every car.

It's to assume that every single thing that could break, will break, and design enough resiliency in that you have to stack up as many failures as possible before things truly go off the rails.

So to do this without killing people, you add the new systems with the same safety thresholds, then gather quite a few years of statistics, then, slowly let things become more efficient if that's both warranted by data and also warranted by simulation of events that you do not yet have data for.

Skipping steps in this because you want to put more cars on the road immediately is foolish and dangerous.

Many bus routes are designed with stopping/break points, including limiting route lengths so that operators aren't stuck in these conditions.

Yes, at 5pm in a major city, a bus driver might pull up next to a convenience stop, stop the bus, go pee, and come back. Does it happen often? Not that often, because of the aforementioned "we design routes so people aren't trapped for multiple hours" concept.

Great, so when a deer jumps into the middle of the highway the size of the ensuing pileup is twenty times larger. I don't particularly think we should use technology to push efficiency to the point where a mechanical failure, a material failure, or an unexpected object cause much larger scale catastrophes than exist today.

Why not aim for the same distance between cars and twenty times more safety instead?

At a systems level, transportation is something we have to be very, very careful about, because if you get it wrong, you start excluding entire groups of people from being a functional part of your society just because they are different from you in where and how they live.

"When that happens, choosing to drive yourself will be a selfish act, just like exposing people to secondhand smoke is now." Really? I drive on logging roads a few times a month to get to some property. This is pretty sketchy even in good conditions and there's always the chance of getting stuck and having to hike a mile or two the rest of the way up to go get the tractor and sort it out. I'm probably not buying a self-driving car any time soon, if ever.

Now, is having self driving taxis a fantastic idea in a very dense city? Of course. There's huge benefits in keeping the average car as safe, efficient in both energy and pollution, and highly utilized as possible. Are these also a good retrofit to dense-ish suburbs where a bus/rail network isn't quite enough (and the costs to build it in already-developed land are unpalatable)? Also yes. But that's not ubiquitous, that's just part of a larger system that needs to be able to serve all users.

And if your point is that "move out of the mountains and into a city because that's the less-selfish option"... that's a certain kind of political statement, I guess.

The way this is typically handled is through compartmentalization, where no one working has enough of a global view to be able to claim that the behaviour is problematic.

There's a lot that's problematic that we suspect that is going on but don't have firm proof, because the organization actually is pretty good at keeping it secret enough. There's some exceptions where things do get leaked/revealed, but how would you know if this was 99% of wrongdoing, or 0.99% of it?

There's no requirement that the mesh be IP-based or function as a layer-3 router...

Even if it were IP-bsaed, it would be extremely straightforward for one box to send a UDP message to another, and receive and retransmit at the application layer. No TTL nonsense, No multiple IPs showing up communicating upstream.