> Author talks about 4k video, but AI tells me that for "4K production mastering (ProRes 422 HQ, 4:2:2, 10-bit)" the rate is under 2Gbps.
That'd be the rate for 1 stream at 1x playback. Multiple streams because of overlays/crossfades/etc... along with playback at >1x (such as during rendering in particular) will change that significantly.
Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0). Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1) And without developers pouring tens of thousands of work hours into making projects such as GrapheneOS viable despite Google, you wouldn't even be able to do much that requires anything to do with SafetyNet and all successors delivered through Google Play Services, which is functionally the core component of any Android device for the near entirety of typical use-cases. And I'm not excusing OEMs, but they did not build their market share off of being "open" then start to close every door and trap you in it.
> Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0)
oookay? Hardly seems like a big deal? It would indeed be nice if the unlocked phones were set from the factory as such instead of all being the same system image as the ones that locked carriers use, sure, but hardly significant since it's not like you have to sign in or anything?
> Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Why are you even asking Google at all? Just use Firefox? Don't even need to root or use a custom ROM for that, even.
So the risk is the plug for that being yanked in the ~2-5 days between ordering it and unlocking it? So... not a big deal at all. Not even slightly lol.
>Not before connecting it to the internet, even Pixels will go through hundreds of megabytes of data before allowing you to unlock them (see 0).
What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough?
>Also, will Google let me browse the web with "my own OS" without their proprietary services installed on it? (see 1)
Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
>What's the problem here? Are you roaming all the time and that imposes a unreasonable cost on you? You want to stay totally off the grid and using VPN/tor isn't enough?
It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future. It is functionally asking for permission to another party to unlock it, and that would not fall under the umbrella of ownership through being able to install "my own OS" on it, at least for me. And a simple OTA update is all it takes to add multiple verification steps to it, such as providing your ID/using your verified Google account, or just take it out.
Practically speaking none of what you brought up are actually issues because once the phone connects to the internet once, it's unlocked forever, including after relocks/flashing. It's like saying you don't "own" the stuff you bought on bandcamp, because there's a split second between when you bought the song and when you could download it, therefore "It depends on a remote endpoint that can go down at any point, and depends on the company's policies present and future" and "It is functionally asking for permission to another party".
I don't think the bandcamp analogy applies. I may purchase a device with the intent of eventually unlocking the bootloader, but not doing so immediately for whatever reason, such as it still being supported by official updates, or the nth feature not being yet removed. Then the possibility of the option being taken away before you've exercised it remains.
1. It's unclear whether the online check is done when you tap the oem unlocking option, or it's done asynchronously in the background. If it's the latter, then it doesn't really matter because it'll get unlocked anyways.
2. There's no real disadvantage to leaving your bootloader in "locked (unlockable)"[1] state, because you can continue using stock rom and avb is enforced, but you can unlock it at any point using fastboot.
3. The Bandcamp analogy still applies because it offers streaming too (ie. web player), which means you could be happily streaming (ie. not downloading) and then one day they shut down, denying you access to all your music.
> Having control of something isn't the same as third party services granting you access. Many online games only supports windows with secureboot and TPM enabled, but that would be a silly excuse to say that you don't really "own" your PC.
Your example is about one developer's decision, which is not really what we're talking about. The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store? We're talking about restrictions laid down by the OS developer and for iding all applications outside of their crappy walled garden, which is very different. Also, you don't actually think Google is going to stop there do you? They will certainly turn it off one day of they think they can get away with it, because it is in their financial self-interests to do so.
>Your example is about one developer's decision, which is not really what we're talking about.
Is it? Many games outsource their anticheat to a third party developer, similar to how many apps outsource their app security to play integrity.
>The damage goes way up when you start talking about an arbitrary number of applications. A more apt analogy is, what if you couldn't install any applications except through the Windows Store?
What about (nearly) all the games that only support windows, and worse yet, are exclusives on one distribution platform? Yes, there's wine/proton and cracks, but that's a "solution" in the same way that using a modded apk to get past the play integrity requirements is a "solution".
Forza Horizon 6 and Assassin's Creed Black Flag Resync'd are both listed, and both are very recent, major AAA game launches. With top-tier Linux compatibility.
It is staggering how different the situation is now as compared to just a couple years ago. Steam Deck (and associated investments by Valve) are damn near a revolution. It's a perfect storm of the incumbent turning to shit at the same time the underdog really got its act together.
If you or your friend group is really into a game that doesn't have Linux support yeah that's a bummer, especially when it's just because of the kernel level anticheat that's horrifying in its own right (triply so when it's for a PVE game, cough cough, helldivers 2, cough cough). But I don't think that's most people anymore. The more casual and indie game scene these days is huge, and of course single player games in general continue to be super popular.
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.
I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)
Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.
I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.
A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification.
Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.
It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.
And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.
All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.
Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated.
I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could actually run or not vs crashing out part way through.
Andrew Kelleys original motivation for creating Zig was language that allowed precise low-level control for real-time audio processing.
"Kelley describes why he created Zig, when other options including C, C++, Rust, and Go already exist. He said he set out to develop a digital audio workstation. He tried Go, but found interoperability with C libraries difficult, and said the garbage collector caused audio delays. He tried C++, or coding C-style using a C++ compiler, but found that small mistakes led to memory corruption bugs that took weeks to fix. He tried Rust but "really struggled to write code that would satisfy Rust's rules," and spent a month trying to make font rendering work."
I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)
I do this in Unity because allocations/GC cause hitches.
it's pretty normal thing to do there's even the built in pooling libraries so you can pre-allocate 10,000 gameobjects when the game starts.
I haven't played with ECS/DOTS yet but I assume it does something similar.
I do. The only thing I need dynamic allocations for is queues of asynchronous events, and that's just because I'm too lazy to calculate an upper bound for how many there may be.
> Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs.
Give it a few years! I've noticed an explosion in interest in formal verification recently, especially since nowadays the bar to entry is so low: just ask your LLM agent to give it a go.
Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.
Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.
Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.
The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.
Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.
Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA
the buffer managemnt is just different pattern and style of code thats more low level. when you care about performance and cpu cache, you have to make sure that actual physical memory gets computed at same time as other memory near it so there is less latency.
the primary motivation isn't latency but complexity. People do in some applications free or allocate collectively because they have interrupt times in mind, but most of the time when you manually manage memory the issue is mental overhead, so people gravitate towards models they can keep in their head.
Allocating in large chunks is often not very performant which is why people came up with tools like the borrow checker, you often want to allocate and deallocate dynamically on a need-basis but that's exactly where bugs occur.
you only malloc only once at boot in that pattern, its not about performance at that point. after that you need a strict api and patterns to control and process the data that is where the performance matters...but its niche just like you couldn't want to code a ui from scratch in rust when u could just do a web ui w/ typescript,react tailwind or whatever
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?
I asked you what's wrong with pool destructor function pointers. You gave a reason what's wrong and I refuted it. So no, I'm not saying that storing a function pointer is special, just that nothing's wrong with it. (And implying that since there's nothing wrong and it's probably the most straightforward thing to do, it's also probably the right thing).
Or they just don't actually have any compute access restrictions of significance? Chinese companies can just go use those GPUs in neighboring countries that aren't export-restricted, like Malaysia. Like ByteDance openly did: https://www.tomshardware.com/pc-components/gpus/chinas-byted...
And that's not even considering just smuggling the GPUs in by eg buying them in Singapore.
AI-specific chips also seem to be on the easier side to design & create relative to high performance CPUs & GPUs, so there's no particular reason to expect Chinese domestic designs to continuously lag behind. They have access to the same fabs, after all
Even ignoring chip export ban, Chinese companies have way less funding than American counterparts, maybe 1 or 2 orders of magnitude less depending on which company you look at. Deepseek’s recent big funding round being “only” a couple billion $ at $50B valuation, for example. Bytedance and Tencent are tech giants for sure, nonetheless they’re not Google kind of giant.
> Bytedance and Tencent are tech giants for sure, nonetheless they’re not Google kind of giant.
$186 billion and $105 billion revenue in 2025 respectively vs. $402 billion? Yes, Google is larger, but they're all in that same ballpark?
ByteDance's 2025 net income isn't that different from Anthropic's Series H funding even ($50bn vs $65bn respectively).
But this is all also ignoring how much of China is state owned (25% of the GDP!), so the available resource pool is dramatically larger than it would appear depending on what the government decides is important
That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating.
What is useful is the state machine aspects of things like coroutines or async/await, but those aren't quite fibers and very much aren't M:N threading. A major use of them is in UI where they have strict thread requirements even.
Exactly. When I started getting into go 15 years ago, and 10 years ago or so into elixir, I loved the easy concurrency and tried to use it to the maximum possible. What I discovered is that they're just aren't that many things that you can do concurrently.
Reading many different files or servicing many different network sockets being the exception, but realistically that isn't done very often relative to single threaded stuff.
State machine/management is really what is most useful
you can implent something like futures on top of cml and use it as async. then you get async for stuff where async is useful and a proper way to write parallel programs for when async would lead to all the bad stuff async leads to.
i rarely write gui stuff and I find async is rarely what I need. in f# I at least have the option to use hopac.
that is one of the reasons async is everywhere. proper threads are not enough. 2 threads are great at doing 2 things at once, but unless you have the hardware 1000 threads scale very badly at doing 1000 dings at once.
That'd be the rate for 1 stream at 1x playback. Multiple streams because of overlays/crossfades/etc... along with playback at >1x (such as during rendering in particular) will change that significantly.
reply