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.

Imagine you walk up to a shelf and all the prices reconfigure based on a model of the most you would be willing to spend for each item, including putting fake "normal" prices so that the "sale" price you are shown is whatever percentage markdown makes you likely enough to buy.

There's no advertising here, there's just aggressively trying to drain each person's wallet as much as possible and seeing how far you can get before they change behaviour.

One example: my friend and I both requested rides using the same app, standing next to each other to the same street in the same neighborhood 3-4 miles away. He owns a car and rarely uses car services, I do not and it's my primary transportation. The quoted cost of his ride was half mine. It was shocking.

Baked model hardware is not the next step in the chain here, in the next 2-3 years we might hopefully see some HBF (high bandwidth flash) hardware to try and get at same memory bandwidth today at a somewhat lower price point and much lower power dissipation.

Something like the next iteration of Cerebras hardware paired with HBM for KV cache + HBF for weights could be incredibly strong here and much more likely to see away to make into a product with some lifetime compared to "let's bake a old model into a very, very large number of custom chips, design all the interconnects from scratch, and pray". Maybe in 10-15 years once this all matures.

Now if that works out that means in '29/'30 we could easily see a run on NAND that's even worse than the current DRAM price issues, on top of the current increases. Fun times if that happens.

Keep in mind that what previous work has done on a single chip with weights baked in was on a 8b parameter model. Sol is likely something in the 5T parameter range, perhaps higher. Serving the whole thing at BF16 is on the order of $3m in hardware just to serve it at all, and closer to $1-1.5m of hardware if it was being served as NVFP4. And power draw starting at high tens to low hundreds of kilowatts.

Let's say a magic set of chips comes along to host this. Maybe it's 2-3x more efficient in size and power. You're still talking a form factor that's a good chunk of a rack, draws tens of kilowatts, and could actually be sold at a similar if not higher price point because the OPEX is so much lower.

It may be useful but it's certainly uneconomic to spend >$1m to self host the model, plus ongoing power and maintenance costs, plus the cost to adapt whatever building you're in to be able to power it.

The five year project likely represents a bunch of engineers that are stuck in meetings and coordination for 75% of their time, then you staff the project with more people (because you need four times as many) then they all need more meetings to coordinate too. And then they need to write a lot more documentation in the process because in that five years the people working on the project will all turn over at least once if not 2-3 times. Never mind critical people getting pulled off the project to work on other more important things on a monthly basis as is common at large firms.

It's entirely possible for a 2-3 month project if one senior person was left the hell alone to do it to take a dozen people five years.

This is starting to be done for very high value plants (think chip fabs, large datacenters, that kind of thing. When the infrastructure is a $10b expense it's worth it).

Small plants in the middle of nowhere, especially municipal ones? You're lucky if it was designed this century and not 50-100 years ago. Everyone's just trying to keep old stuff running at absolute minimum cost.

I've seen similar things in this decade. Lots of stuff still running where the last change in design was 20+ years ago, the current team knows how to keep the lights on and replace parts, and calls a vendor if something goes end of life and asks for a replacement part, then configures it the same way that the older one was.

It's quite reliable, and does not require paying for a team of people who wants to try new things. Once this happens for a long while there's no one in the building left who's going to advocate for change, since the only thing all that fancy new technology brings is the next 5 years of nobody getting a bonus because operational metrics weren't being met anymore.

You have to try really hard to convince these people that the thing that they have seen on a daily basis to work just fine for the past twenty years is no longer good enough, because all their evidence says that it is. And you should also listen to them much more than people who just want to use the latest thing typically do, because they do have the decades of experience seeing how things actually fail.

We currently use a small US contract manufacturer that works pretty much as you say. The turn times are terrible (7+ weeks, not 7 days), and this is a major issue, but there are exactly two reasons we continue to use them:

1. Line of credit - we are not billed until we take delivery of tested product. 2. Willingness to handle high mix, low volume products. One product line example: a dozen SKUs with 95-98% parts in common on 2 PCBs, a single set of parts (that we aren't billed for up front) and quoting to build 20 of SKU 1, 50 of SKU 2, 10 of SKU 3, etc. without charging 2-3x the price.

We manufacture in the research / test equipment / defense space and I've heard similar things from other small hardware companies that are like us.

The improvements were for things governments (fuel/pollution efficiency) and insurers (safety) wanted, not necessarily you.

A new 2010 Toyota likely wouldn't even be legal to sell today in many jurisdictions, and this is in fact one part of the problem.

Another part of the problem is that all the big automakers need to design a new car roughly every 5 years in order to keep from losing the ability to design one at all, as people age and retire. What's really been settled on is that "minor updates every year and a major update every 5-6 years" actually does work in terms of keeping know-how to design these things, as well as handle supply chain problems.

For example, if a chip you need goes EOL and you have to redesign around that, it's much better to have that happen in the last 1-2 years of your manufacturing, you do a last time buy to get through that last year, and move on. Much harder to do on a longer lifecycle: that 2010 design, sold new in 2026, and operated until 2040+. How many suppliers go out of business over 30 years, or stop making a critical component?

Run on server, chroot into target environment, configure compiler flags for eventual target, done. It's really just an afternoon of setup and then the problem is solved.

Who actually pays for what and how is so mangled that if you want to reallocate someone to another project (or even just pay them out of a different pool of funds!) often the easiest approach is to rehire them through a contractor, or a different contractor.

This is especially useful when projects are wound down. Let's say you've contracted to an org for support or management on a project that you want to kill, you've already obligated some amount of funds, and you don't really want to make that organization angry by ripping millions away from them (the pool of contractors is not large). What to do? Well, you could take Joe and give him a raise by suggesting he work for the contractor instead of you directly. Money's already spent, anyways. So you save your own money that you can use for your pet projects or whatever, Joe gets a raise, the contractor doesn't get a termination that pisses everyone off. Everyone happy, right? Smh.

There's likely always going to be value in limiting the number of $200k+ SWEs you have to pay. But that's not the interesting case.

What about the $10k/year offshored employees that are getting replaced by AI call centers? If that were the break even, then once you close down the whole building and develop the systems to not need them, then how much would inference costs have to go up before all that gets unwound and handed back to humans? It's more than you think - there's real margin there.

There's a lot of maintenance that is much easier/cheaper to do when the apartment is unoccupied, so the default is "do nothing, then when the tenant moves out in a year or two, do a couple years of maintenance much more affordably."

With your gym, for example, when it's new, you can do all the work you want. Once people are using it every day (especially if it's a 24/7 facility!) how exactly do you get in to do major work without making a bunch of people annoyed that half the gym is out of service for three weeks? You don't, until it gets to the point that people would prefer the downtime ... and this takes a surprising amount of grime.

Uber's situation is exactly the same. OpenAI is offering inference for a bunch of industries at prices that make it more competitive than hiring humans to do the same work.

If the break-even price to actually provide the service wasn't actually economic compared to humans, would there be nearly as much of a market? That's the real question. OpenAI is basically betting that they can live long enough that AI systems get built around them, which creates enough of a lock-in that they still have customers when prices increase by a lot.

One heuristic I use to avoid this exact problem is "minimize the number of places that the next poor soul has to look in order to understand how this code works", where place is loosely defined as about the number of lines of code that fit on a screen or two.

This has given really good results in terms of helping decide whether to extract these helper functions or not - they have to both be memorable enough in name and arguments that the code calling them can understand what's going on without always having to dive in, and also provide a meaningful compression of the logic above so that it can be comprehended without having to jump across many hundreds of lines.

Mobile users (or other locked down devices where adblockers are forbidden) are still a decent chunk of traffic. It's much easier to just read the overview and not click through to the ad infestation, or even use a chatbot of choice as the search engine instead of going to Google, because "websites is how you get spammed with ads".