rfoo

The point here is not who first added the feature to Linux kernel. The point is Android cared about security, built a CFI implementation, started shipping it back in 2018, while Linux had other priorities and didn't have it until 2021. And even then almost nobody adopted it.

Well, I don't know kCFI being enabled on any distro besides Android, cause it requires building the kernel with Clang.

The previous in-kernel CFI implementation (before the kinda joint effort - kCFI) was upstreamed by Google, too: https://www.phoronix.com/news/Clang-CFI-Linux-Patches and https://www.phoronix.com/news/Linux-Kernel-Clang-LTO-Patches. Pixel devices also had this long before. Given that the entire Linux kernel feature was developed out of Android I find it a little bit unfair to call it "using a vanilla kernel feature".

So, here is a tweet from Eduardo highlighting that they got a lot of 0day submissions immediately after they launched the promotion: https://x.com/sirdarckcat/status/1681491274489282565

And the spreadsheet is public [0], I counted 7 unique hoarded bugs (submitted immediately after launch) after deduplicating by patch commit hash. Then in the month following, another 9 unique bugs were submitted.

As for how much paid, I don't remember. Could be around $200~300k in total.

[0] https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJ...

Not all. For example kCFI is kernel space.

Also, attack surface reduction is a very valid strategy, so it may seem like about the userspace (sandbox for every apps etc) but it could make a big different in how much of the kernel attack surface is exposed.

I thought when people say "Linux security is a myth" they were comparing it to FreeBSD / OpenBSD. So it's revealing that most are comparing Linux to Windows here.

That would be a different meta-game and while I didn't think deep into it, I believe the likely outcome is - people are just discouraged and won't consider submitting to kernelCTF.

Boss want a strictly fixed budget for running those cool programs. The rationale behind these programs (at least partially) is about measuring exploits and mitigations dynamics, not buying bugs. And, Linux is just too buggy that if you pay for every 0-day it's basically out of control. Google tried to do so (and to drain people's hoarded bugs) once, ran a limited time promotion with no race, every 0 day counts, got flooded.

And at the same time you don't want to piss the community, so here we go.

No. Like "master" as a branch name, even if it's perfectly fine in this context, as long as it could be suggesting the word use in a problematic context, it should be banned. That's how we banned "master" as a branch name, so why not MCP?

Yes, I mean we should ban all abbrev with M in it /s

As secure as all MCP servers!

Right, the problem is when I amended one of my patches there's no way for the reviewer to look at a diff between current and previous versions.

The "cursed multidimensional index rearrangement" is mostly for doing inner product in the weird way demonstrated. Granted, it proves author's point - you need to be fluent in NumPy to write this and can't take the Go approach of "I refuse to learn anything you better make me up to speed in 5 minutes".

The code could be just:

    AiX = np.linalg.solve(A, X[:, np.newaxis, :, np.newaxis]).squeeze()
    Z = np.vecdot(Y, AiX)

Or if you don't like NumPy 2.0:

    AiX = np.linalg.solve(A, X[:, np.newaxis, :])
    Z = np.einsum("jk,ijk->ij", Y, AiX)

The NumPy 1.x code is very intuitive, you have A[i, j, n] and X[i, n] and you want to use the same X[i] for all A[i, j], so just add an axis in the middle. Broadcast, which the author very strongly refuse to understand, deals with all the messy parts.

Alternatively, if you hate `[:, np.newaxis, :]` syntax, you may do:

    I, J, K, K = A.shape
    AiX = np.linalg.solve(A, X.reshape(I, 1, K, 1)).squeeze()
    Z = np.vecdot(Y, AiX)

I can read this faster than nested for-loops. YMMV.

There's a very large gap between being super nice to a human and being a jerk.

I don't think it benefits me much by very politely suggesting that its approach may not work and emphasize on the good part of the idea it generates and it would be better if it could try to push in another direction for example X. Like I do when talking to junior engineers.

I usually just say, "This does not work because of ..., Y is good though, change your mind and assess X now". I can also say this when I'm not actually sure whether X works or not, without worrying about my words sending an intern / a junior engineer into days of struggling on a deadend.

I think you always can. In the past you may lose some features / have some bugs. For recent kernel versions (>= 6.6) the only patches WSL kernels have is dxgkrnl + some hacky fixes for clock sync. Others are all in upstream already. So you'll just lose WSLg / CUDA passthrough and nothing else now.

Of course, there might be some regressions. They are usually only fixed (upstream) after WSL kernel gets upgraded and it starts to repro in WSL.

Nah, the closest thing to WSL on macOS is OrbStack.

Exactly same experience to WSL - great out of the box experience, easy to use, and insist on using their own patched kernel.

Okay. Then you had a Mac. Then you need to run Linux in a VM anyway because similar to Windows, macOS is also a dumpster fire. Then why bother? You are going to have a Linux VM anyway. I usually just sync my VM disk between all my laptops & desktops, no matter what host OS it runs.

You don't need to be nice to your virtual junior devs. Saves quite a lot time too.

As long as I spend less time reviewing and guiding than doing it myself it's a win for me. I don't have any fun doing these things and I'd rather yelling at a bunch of "agents". For those who enjoy doing bunch of small edits I guess it's the opposite.

That's the mindset that leads to the funny result that `uv pip` is like 10x faster than `pip`.

Is it because Rust is just fast? Nope. For anything after resolving dependency versions raw CPU performance doesn't matter at all. It's writing concurrent PLUS parallel code in Rust is easier, doesn't need to spawn a few processes and wait for the interpreter to start in each, doesn't need to serialize whatever shit you want to run constantly. So, someone did it!

Yet, there's a pip maintainer who actively sabotages free-threading work. Nice.

> Does free-threaded Python provide the same guarantees

Mostly. Some of the "can be pre-empted on the boundary between any two bytecode instructions" bugs are really hard to hit without free-threading, though. And without free-threading people don't use as much threading stuff. So by nature it exposes more bugs.

Now, my rants:

> have any other effects on multi-threaded Python code

It stops people from using multi-process workarounds. Hence, it simplifies user-code. IMO totally worth it to make the interpreter more complex.

> Complicates C extensions

The alternative (sub-interpreters) complicates C extensions more than free-threading and the top one most important C extension in the entire ecosystem, numpy, stated that they can't and they don't want to support sub-interpreters. On contrary, they already support free-threading today and are actively sorting out remaining bugs.

> Causes single-threaded code to run slower

That's the trade-off. Personally I think a single digit percentage slow-down of single-threaded code worth it.

mid/post training does not cost that much, except maybe large scale RL, but even this is more of an infra problem. If anything, the cost is mostly in running various experiments (i.e. the process of doing research).

It is very puzzling why "wrapper" companies don't (and religiously say they won't ever) do something on this front. The only barrier is talents.

> Tons of training data (benefiting from all the JS examples as well)

More != better.

> the fastest completion since it would run locally

We are living in a strange age that local is slower than the cloud. Due to the sheer amount of compute we need to do. Compute takes hundreds of milliseconds (if not seconds) on local hardware, making 100ms of network latency irrelevant.

Even for a 7B model your expensive Mac or 4090 can't beat, for example, a box with 8x A100s running FOSS serving stack (sglang) with TP=8, in latency.

You know, sometimes I really wonder, if Uyghurs aren't white, are US/EU still going to make stretch to call the human right abuse during China's version of "counter-terrorism war" in Xinjiang "genocide" or not.

It's not something you should talk to. In concept it's more like AlphaProof, just with some of their research artifacts (and probably a paper / tech report later) shared with the community.

Yeah, I'm sure killing a major revenue stream helps an organization to focus on keeping its cost center going and get rid of other shots trying to bring in more revenue /s

It could be as simple as something like, someone previously at Instagram decided to join OpenAI and turns out nobody stopped him. Or even, Sam liked the idea.

If you want a dick move like this it's better to do so after. OpenAI consistently pull this trick on Google.

It's interesting that the release happened at 5am in China. Quite unusual.

The model does have some bias builtin, but it's lighter than expected. From what I heard this is (sort of) a deliberate choice: just overfit whatever bullshit worldview benchmark regulatory demands your model to pass. Don't actually try to be better at it.

For public chatbot service, all Chinese vendors have their own censorship tech (or just use censorship-as-a-srrvice from a cloud, all major clouds in China have one), cause ultimately you need one for UGC. So why not just censor LLM output with the same stack, too.

> flawed enough starting premise

That's where we start to disagree what future looks like, then.

It's not there yet, in that the LLM-clone isn't good enough. But amusingly a not nearly good enough clone of me already made me more productive, in that I'm able to deliver more while maintaining the same level of personal satisfaction with my code.

This is great idea! But it's more about having LLMs to give function & variables names, instead of having LLM to deobfuscate. The (traditional) deobfuscations (e.g. unpack, de-flatten, de-virtualization etc) were done by 100% precise human made Babel plugins and is totally unrelated to a LLM.