I think I should write more about but I have been feeling very similar. I've been recently exploring using claude code/codex recently as the "default", so I've decided to implement a side project.
My gripe with AI tools in the past is that the kind of work I do is large and complex and with previous models it just wasn't efficient to either provide enough context or deal with context rot when working on a large application - especially when that application doesn't have a million examples online.
I've been trying to implement a multiplayer game with server authoritative networking in Rust with Bevy. I specifically chose Bevy as the latest version was after Claude's cut off, it had a number of breaking changes, and there aren't a lot of deep examples online.
Overall it's going well, but one downside is that I don't really understand the code "in my bones". If you told me tomorrow that I had optimize latency or if there was a 1 in 100 edge case, not only would I not know where to look, I don't think I could tell you how the game engine works.
In the past, I could not have ever gotten this far without really understanding my tools. Today, I have a semi functional game and, truth be told, I don't even know what an ECS is and what advantages it provides. I really consider this a huge problem: if I had to maintain this in production, if there was a SEV0 bug, am I confident enough I could fix it? Or am I confident the model could figure it out? Or is the model good enough that it could scan the entire code base and intuit a solution? One of these three questions have to be answered or else brain atrophy is a real risk.
People not only tolerate, but I'd argue most people prefer it. I think, unlike Singapore or Tokyo, Americans, in cities, largely prefer a little lived in grime.
The Mission Bay is a relatively new neighborhood in San Francisco - mostly free of graffiti and is pretty much sterile, and most people would prefer to live in the Mission rather than Mission Bay. OpenAI likely pays a huge premium to HQ in the mission rather than settling in the more corporate offices of Mission Bay or even the Financial District.
I also noticed the same in Berlin - Kreuzberg, Neukolln, and other neighborhoods in East Berlin attract the most people, despite being drenched in graffiti.
If ever move to a city in America and tell people you live in the generally clean, spick and span, neighborhood in that city, half the people will look at you like you have 3 heads or simply assume you have no personality. Graffiti has largely become an accepted, or even valued, feature of a neighborhood. I believe internally it separates the "cool" city inhabitants from the "losers" out in the suburbs.
Edit: I just looked through all the images in the OP and one of them is a banksy. It's been there for over a decade. Graffiti isn't just tolerated, its practically protected.
Can someone explain how protobuf ended up in the middle here? I'm just totally confused; the C ABI exists in almost every language, why did they need protobuf here?
I don't know, but I have a guess. Someone didn't want to deal with unsafety of dealing with memory allocated in C code. Serialize/deserialize makes it easy, no need for unsafe, no need to learn all the quirks of the C-library allocating the memory.
I had experience with writing safe bindings to structures created in C library, and it is a real pain. You spend a lot of times reverse engineering C code to get an idea of the intent of those who had wrote the code. You need to know which pointers can address the same memory. You need to know which pointers can be NULL or just plain invalid. You need to know which pointers you get from C code or pass to it along with ownership, and which are just borrowed. It maybe (and often is) unclear from the documentation, so you are going to read a lot of C code, trying to guess what the authors were thinking when writing it. Generating hypotheses about the library behavior (like 'library never does THIS with the pointer') and trying to prove them by finding all the code dealing with the pointer.
It can be easy in easy situations, or it can be really tricky and time consuming. So it can make sense to just insert serialization/deserialization to avoid dealing with C code.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that.
Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point with layer 3 routing and NAT. If you chose to "bridge" a device (like those internet exposed laptops) or port-forward, it will just work (even with ISP routers!!) there is no firewall rule change required.
I've worked in this space supporting consumer grade routers, and then worked in enterprise networking. But don't take my word for it, you all can take a trip to shodansafari, how many devices are listening port 3389 and 445 with consumer grade laptop names?
But it isn't a popular thing to say for whatever reason. I guess IPv6 is a political ideology now lol.
>Many get just a modem and buy a cheap router which may not have a firewall
What cheap router are you buying that doesn't have a firewall. I think the problem is when people hear "firewall" they think the router is running pfSense or something. Even cheap routers will have a basic, non-configurable, firewall that will block inbound connections. That is separate from NAT and has nothing to do with IPv4/IPv6.
It's an AP that serves DHCP addresses on the lan port. that's it. It has some port forwarding too if you set it up, no firewalling there. For modems, most cable ISPs let you buy a DOCSIS modem, there is no router, whatever device you connect gets a DHCP lease right on the internet (and ipv6), most people buy cheap "routers" like that one to add "wifi" to it, and it works great for the money. And honestly, I have yet to see one that does have a firewall, but then again I've never tried the $500 router options or seen someone who did.
These devices are not meant to firewall, they have no need to firewall. if you do "bridge" or "portforward" they assume you want everything forwarded, they don't let you configure any firewalling by design, and they don't have any firewalling because it isn't needed. They have a dedicated WAN port, the management interface doesn't listen on that port and LAN devices are NAT'ed with IPv4 so there is no need to firewall anything even behind the scenes. Their main use is to either extend wifi coverage or add wifi capability to modems.
Most people with fiber or *DSL get an ISP provided gateway which has a firewall,that's not the same as what I'm talking about.
I hate to complain about downvotes, but you all need to realize that it is the poorest and most vulnerable around the world that get hurt over this stuff. yes, ipv6 can cause unintended internet exposure of internal devices. period. that's not a dismissal or disapproval of ipv6, it is what it is, and that needs to be considered when deploying it. It assumes you'll configure your network properly, unfortunately the people who made ipv6 didn't consider consumers or people who screw up, they wanted to force people to configure firewalls, that works for corporations (until it doesn't) but not for most regular internet users.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
The trigger architecture is actually quite interesting, especially because cleanup is relatively cheap. As far as compliance goes, it's also simply to declare that "after 45 days, deletions are permanent" as a catch all, and then you get to keep restores. For example, I think (IANAL), the CCPA gives you a 45 day buffer for right to erasure requests.
Now instead of chasing down different systems and backups, you can simply set ensure your archival process runs regularly and you should be good.
The subcommunity that would have tweets on HN has stayed on Twitter. There are entire separate subcommunities on Twitter that have just died in the past year.
It's like saying you don't see any Instagram posts on HN, so Instagram must be tiny. Its more likely the subcommunities that post on Threads don't have overlap with HN.
>We don't have to wait for singular companies or foundations to fix ecosystem problems.
Geohot has been working on this for about a year, and every roadblock he's encountered he has had to damn near pester Lisa Su about getting drivers fixed. If you want the CUDA replacement that would work on AMD, you need to wait on AMD. If there is a bug in the AMD microcode, you are effectively "stopped by AMD".
We have to platform and organize people, not rely on lone individuals. If there is a deep well of aligned interest, that interest needs a way to represent itself so that AMD has something to talk to, on a similar footing as a B2B relationship. When you work with other companies with hundreds and thousands of employees, it's natural that emails from individuals get drowned out or misunderstood as circulated around.
You can see in his table he calls out his AMD system as having "Good" GPU support, vs. "Great" for nvidia. So, yes, I would argue he is doing the work to platform and organize people, on a professional level to sell AMD systems in a sustainable manner - everything you claim that needs to be done and he is still bottlenecked by AMD.
A single early-stage company is not ecosystem-scale organization. It is instead the legacy benchmark to beat. This is what we do today because the best tools in our toolbox are a corporation or a foundation.
Whether AMD stands to benefit from doing more or less, we are likely in agreement that Tinygrad is a small fraction of the exposed interest and that if AMD were in conversation with a more organized, larger fraction of that interest, that AMD would do more.
I'm not defending AMD doing less. I am insisting that ecosystems can do more and that the only reason they don't is because we didn't properly analyze the problems or develop the tools.
I'm very familiar with the stack and the pain of trying to livestream video to a browser. If JPEG screenshots work for your clients, then I would just stick with that.
The problem with wolf, gstreamer, moonlight, $third party, is you need to be familiar with how the underlying stack handles backpressure and error propagation, or else things will just "not work" and you will have no idea why. I've worked on 3 projects in the last 3 years where I started with gstreamer, got up and running - and while things worked in the happy path, the unhappy path was incredibly brittle and painful to debug. All 3 times I opted to just use the lower level libraries myself.
Given all of OPs requirements, I think something like NVIDIA Video Codec SDK to a websocket to MediaSource Extensions.
However, given that even this post seems to be LLM generated, I don't think the author would care to learn about the actual internals. I don't think this is a solution that could be vibe coded.
This is where LLMs shine, where you need to dip your toes into really complex systems but basically just to do one thing with pretty straightforward requirements.
The peak of irony, because you know how these people arrived at their 40 Mbit bitrate H264 and their ineffective tinkering with the same in the first place is guaranteed to be some LLMs expert suggestions. As is often the case, because they had no understanding of the really complex system subject matter whatsoever, they were unable to guide the LLM and ended up with .. slop. Which then turned into a slop blog post.
God knows what process led them to do video streaming for showing their AI agent work in the first place. Some fool must have put "I want to see video of the agent working" in.. and well, the LLM obliged!
>As is often the case, because they had no understanding of the really complex system subject matter whatsoever
Something I want to harp on because people keep saying this:
Video streaming is not complicated. Every youtuber and twitch streamer and influencer can manage it. By this I mean the actual act of tweaking your encoding settings to get good quality for low bitrate.
In 3 months with an LLM, they learned less about video streaming than you can learn from a 12 year old's 10 minute youtube video about how to set up Hypercam2
Millions and millions of literal children figured this out.
Keep this in mind next time anyone says LLMs are good for learning new things!
Video Streaming has surprising little overlap with Video Codecs. Once you choose input/output options, then there's little to change about the codec. The vast majority of options available to ffmpeg aren't supported in the browser. Streamers don't have options for precisely the same reason OP doesn't have options - you are limited entirely into what the browser supports.
I've built the exact pipeline OP has done - Video, over TCP, over Websockets, precisely because I had to deliver video to through a corporate firewall. Wolf, Moonlight and maybe even gstreamer just shows they didn't even try to understand what they were doing, and just threw every buzzword into an LLM.
To give you some perspective 40Mbps is an incredible amount of bandwidth. Blu ray is 40mbps. This video, in 8K on Youtube is 20Mbps: https://www.youtube.com/watch?v=1La4QzGeaaQ
I have done a bit with ffmpeg and video encoding. I've been encoding videos using ffmpeg (from a GUI) since I was a child. I hate ffmpeg though, the UX is just insane, so I tend more towards tools that produce the arcane command structures for me.
I had a situation where I wanted to chop one encoded video into multiple parts without re-encoding (I had a deadline) and the difficulty getting ffmpeg to do sensible things in that context was insane. One way of splitting the video without re-encoding just left the first GOP without a I frame, so the first seconds of video were broken. Then another attempt left me with video that just got re-timed, and the audio was desynced entirely. I know encoding some frames will be necessary to fix where cuts would break P and B frames, but why is it so hard to get it to "smartly" encode only those broken GOPs when trying to splice and cut video? Clearly I was missing some other parameters or knowledge or incantation that would have done exactly that.
The few knobs that actual video encoder users need to tweak are clearly exposed and usable in every application I have ever used.
>twitch et al give you about three total choices
You don't configure your video encoding through twitch, you do it in OBS. OBS has a lot of configuration available. Also, those three options (bitrate type, bitrate value, profile, "how much encoding time to take" and """quality""" magic number) are the exact knobs they should have been tweaking to come up with an intuition about what was happening.
Regardless, my entire point is that they were screwing around with video encoding pipelines despite having absolutely no intuition at all about video encoding.
They weren't even using FFMPEG. They were using an open source implementation of a video game streaming encoder. Again, they demonstrably have no freaking clue even the basics of the space. Even that encoder should be capable of better than what they ended up with.
We've been doing this exact thing for decades. None of this is new. None of this is novel. There's immense literature and expertise and tons of entry level content to build up intuition and experience with what you should expect encoded video to take bandwidth wise. Worse, Microsoft RDP and old fashioned X apps were doing this over shitty dial up connections decades ago, mostly by avoiding video encoding entirely. Like, we made video with readable text work off CDs in a 2x drive!
Again, Twitch has a max bandwidth much lower than 40mb/s and people stream coding on it all the time with no issue. That they never noticed how obscenely off the mark they are is sad.
It would be like if a car company wrote a blog post about how "We replaced tires on our car with legs and it works so much better" and they mention all the trouble they had with their glass tires in the blog.
They are charging people money for this, and don't seem to have any desire to fix massive gaps in their knowledge, or even wonder if someone else has done this before. It's lame. At any point, did they even say "Okay, we did some research and in the market we are targeting we should expect a bandwidth budget of X mb/s"?
"AI" people often say they are super helpful for research, and then stuff like this shows up.
...and apparently waste 3 months doing it wrong thanks to it without doing anything as basic as "maybe fix your bitrate, it's far higher than any gameplay streaming site and that's for video game, stuff with more movement"
My gripe with AI tools in the past is that the kind of work I do is large and complex and with previous models it just wasn't efficient to either provide enough context or deal with context rot when working on a large application - especially when that application doesn't have a million examples online.
I've been trying to implement a multiplayer game with server authoritative networking in Rust with Bevy. I specifically chose Bevy as the latest version was after Claude's cut off, it had a number of breaking changes, and there aren't a lot of deep examples online.
Overall it's going well, but one downside is that I don't really understand the code "in my bones". If you told me tomorrow that I had optimize latency or if there was a 1 in 100 edge case, not only would I not know where to look, I don't think I could tell you how the game engine works.
In the past, I could not have ever gotten this far without really understanding my tools. Today, I have a semi functional game and, truth be told, I don't even know what an ECS is and what advantages it provides. I really consider this a huge problem: if I had to maintain this in production, if there was a SEV0 bug, am I confident enough I could fix it? Or am I confident the model could figure it out? Or is the model good enough that it could scan the entire code base and intuit a solution? One of these three questions have to be answered or else brain atrophy is a real risk.
reply