rfoo

Is there really something to lose? How often do we see "stackless coroutine" listed as advantage in Rust vs Go for network programming flamewars?

You are right. It's just that multithreading before free-threading was too broken and too slow to the point that very few people use them for high-traffic production things. And people decided to write it like NodeJS to further handwave the problem.

Zhipu is the most Chinese company out there. Almost all of their fund is from state-owned entities now.

The project states that:

> LLM & AI-Native: Its structured, tokenizable nature makes it powerful primitive for time-based reasoning, prompt engineering, and log analysis in AI systems.

Being significantly OOD usually does not help in this case, did I miss something here?

> Calyx would be better than nothing.

Depends on your threat model. If Google, low-effort scam apps or being profiled by apps are your only adversary, then that's true. If random threats on Internet or APTs pwning your phone, or being forensic-proof are part of your threat model, then Calyx is strictly worse than stock.

Mainly open source stuff. Chromium, Android, etc.

The problem is worktrees in this case.

And threads are just 100x better than stackless coroutines, period.

Especially when we have actual threads with UMCG.

Wikipedia listed a FAIR alumni as cofounder for this "Moonshot AI". Make it funnier probably.

TBH I'm tired of only the "Ah, an excellent follow-up! You are absolutely right <...> My apologies" part.

> the speed at which the GPUs can communicate is key

Guess what a telco equipment company is good at :p

Yes. And those random Internet chatter almost certainly doesn't know what they are talking about at all.

First, nobody is training on H20s, it's absurd. Then their logic was, because of high inference demand of DeepSeek models there are high demand of H20 chips, and H20s were banned so better not release new model weights now, otherwise people would want H20s harder.

Which is... even more absurd. The reasoning itself doesn't make any sense. And the technical part is just wrong, too. Using H20 to serve DeepSeek V3 / R1 is just SUPER inefficient. Like, R1 is the most anti-H20 model released ever.

The entire thing makes no sense at all and it's a pity that Reuters fall for that bullshit.

Contrary to common belief, it's fine to say negative things about the government in this case, as long as you are not Chinese. They may argue with you (or laugh at you for some even weirder reasons) and you both may have an unpleasant conversation, but that's it.

Apple pushes a narrative that their devices are secure (not private, but secure). And my less tech-savvy friends sincerely believe that it's due to it being a walled garden, with curated software only.

Apple made no attempt clarifying this.

What source do you want? I have a few friends who work for them and they all live in either Shanghai (most) or Beijing. And I've never seen anyone who claimed they are based in Singapore or anywhere else before. Does this work?

> A Singapore based company, according to LinkedIn

Nah, this is a Shanghai-based company.

Pretty sure it's C++.

inb4 someone yells Rust. No, your `.unwrap()` happily panics in Rust too.

Thanks for the clarification. Yeah, that's pretty frustrating.

Now I'm curious why grpc, webrtc and some other Chromium repos were set up like this. Google projects which started in google3 and later exported as an open source project don't have this defect, for example tensorflow, abseil etc. They all had a top-level directory containing all their codes so it becomes `#include "tensorflow/...`.

Feels like a weird collision of coding style and starting a project outside of their monorepo

Dunno why you got downvoted, but I've also tried to let Claude translate a bunch of BUILD files to equivalent CMakeLists.txt. It worked. The resulting CMakeLists.txt looks super terrible, but so is 95% of CMakeLists.txt in this world, so why bother, it's doomed anyway.

> they make no effort what so ever to distinguish between public header files and their source code

They did, in a different way. The world is used to distinguish by convention, putting them in different directory hierarchy (src/, include/). google3 depends on the build system to do so, "which header file is public" is documented in BUILD files. You are then required to use their build system to grasp the difference :(

> And their public headers tend to do idiotic stuff like `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.

I have to disagree on this one. Relying on relative include paths suck. Just having one `-I/project/root` is the way to go.

> graphene is a major player?

No. It is not. Lineage and a lot of others are major players.

They just have different focus. GrapheneOS cares about being secure. Others cares about being, well, custom, and "privacy", "privacy" as in "noooooooooo I don't want to install google stuff jfc", instead of being secure against random threat actors.

IIUC, GrapheneOS cares about being forensics-proof very much. And for Android phone forensics without consent, almost 0% of work are done after the boot chain ends. So it's all about firmware.

Non-Pixel devices usually require you to just give up secure boot, in this case a GrapheneOS install could be even worse than stock Android.

An (arbitrarily) quantized model is a totally different model, compared to the original.

I don't work for OAI so obviously I can't say for them. But we don't do this.

We don't make hobbyist mistakes of randomly YOLO trying various "quantization" methods that only happen after all training and claim it a day, at all. Quantization was done before it went live.

The advantage is, now there's an Apple team working on it. They will be bothered by their own bugs and hopefully get them fixed.

Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support.

Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.

This does not support memory ballooning yet. But they have documented custom kernel support, so, goodbye OrbStack.

All system programming languages mentioned by GP share the same set of debuggers and profilers, though. It's not very language specific.

> mandating network kill switches

It's really funny that China made non-trivial amount of strategic decisions on the assumption that US tech do have network kill switches [0], including using it solely to justify protectionism, while nobody on the earth are crazy enough to do this, we all just call them out, "just an excuse to justify protectionism", then all at a sudden here we are, trying to say "mandating network kill switches" could be a good idea.

[0] Use OpenAI Deep Research or rivals and investigate the word "自主可控".

Yeah, and it's stupid that I still have to pay $20/mo just for Cursor Tab.

I think the correct benchmark is `len()`. Give me your prompts or your output, whichever is shorter.