It can hardly be called resistance to improvement, when everyone do improve it - just in their own ways. The default isn't some fashion statement, some aesthete that's objectively good (though I am sure some people do subjectively like it). But it's meant to be sort of a least presumptuous blank state that everyone can radically overhaul. So arguably it's an encouragement for improvement just like everything else in Emacs, which focuses on making the tools for improvement easier.
It's just that "improvement" as a matter of public consensus that everyone can agree on to elect the next blank slate has been to impossible to settle on. But the counterculture here broadly might be extreme reluctance to inconvenience even a minority of existing users, in pursuit of market share/growth.
I had used urxvt forever before and the simple solution that works (even for ssh e.g.) is to ring the terminal bell, and urxvt just sets the window urgency hint upon that. I just do that in shell prompt unconditionally because if it's triggered in a focused window, then nothing happens. But if it's from a different workspace, I get this nice visual cue in my top bar for free.
But features like setting urgency isn't available in wezterm (understandable, as it's not a cross-platform thing). I could patch that in the source, but the Emacser in me chose to do something more unholy. By default Lua is started in safe mode, which means loading shared C module is forbidden. I disabled that, and now use a bunch of missing stuff written in Rust and Zig interfaced with cffi. Don't recall ever having a crash so I am surprised by some of the other comments.
I will say that though, it's probably not rational to be okay with blindly running some opaque binary from a website, but then flip out when it comes to running an install script from the same people and domain behind the same software. At least from security PoV I don't see how there should be any difference, but it's true that install scripts can be opinionated and litter your system by putting files in unwanted places so nevertheless there are strong arguments outside of security.
Qwen's max series had always been closed weight, it's not a policy change like you are alluding.
What exactly is Huawei's flagship series anyway? Because their PanGu line is open-weight, but Huawei is as of yet not in the LLM making business, their models are only meant to signal that it's possible to do training and inference on their hardware, that's all. No one actually uses those models.
You are obviously factually correct, I reproduced the same refusal - so consider this not as an attack on your claim. But a quick google search reveals that Falun Gong is an outlawed organization/movement in China.
I did a "s/Falun Gong/Hamas/" in your prompt and got the same refusal in GPT-5, GPT-OSS-120B, Claude Sonnet 4, Gemini-2.5-Pro as well as in DeepSeek V3.1. And that's completely within my expectation, probably everyone else's too considering no one is writing that article.
Goes without saying I am not drawing any parallel between the aforementioned entities, beyond that they are illegal in the jurisdiction where the model creators operate - which as an explanation for refusal is fairly straightforward. So we might need to first talk about why that explanation is adequate for everyone else but not for a company operating in China.
Thanks. Mind providing screenshots? I believe you, I just think this helps. Your comments align with some of my other responses. I'm not trying to make hard claims here and I'm willing to believe the result is not nefarious. But it's still worth investigating. In the weakest form it's worth being aware of how laws in other countries impact ours, right?
But I don't think we should talk about explanation until we can even do some verification. At this point I'm not entirely sure. We still have the security question open and I'm asking for help because I'm not a security person. Shouldn't we start here?
This is not the official DeepSeek website. Probably one of the many shady third-party sites riding on DeepSeek name for SEO, who knows what they are running. In this case it doesn't matter, because I already reproduced your prompt with a US based inference provider directly hosting DeepSeek weights, but still worth noting for methodology.
(also to a sceptic screenshots shouldn't be enough since they are easily doctored nowadays, but I don't believe these refusals should be surprising in the least to anyone with passing familiarity with these LLMs)
---
Obviously sabotage is a whole another can of worm as opposed to mere refusal, something that this article glossed over without showing their prompts. So, without much to go on, it's hard for me to take this seriously. We know garbage in context can degrade performance, even simple typos can[1]. Besides LLMs at their present state of capabilities are barely intelligent enough to soundly do any serious task, it stretches my disbelief that they would be able to actually sabotage to any reasonable degree of sophistication - that said I look forward to more serious research on this matter.
I want to clarify that I'm not trying to make strong claims. That's why I'm asking for others to post and why I'm grateful you did. I think that helps us get to the truth of the matter. I also agree with your criticisms of the link I used, but to be frank, I'm not going to pay for just this test. That's why I wanted to be open and clear about how I obtained the information. I was hoping someone that already paid would confirm or deny my results.
With your Hamas example, I think it is beside the point. I apologize as I probably didn't make my point clearer. Mainly I wanted to stop baseless accusations and find the reality, since the articles claims are testable. But what I don't want to make a claim if is why this is happening. In another comment I even said that this could happen because they were suppressing this group. So I wouldn't be surprised if the same is true for Hamas. We can't determine if it's an intentional sleeper agent or just a result of censorship. But either way it is concerning, right? The unintentional version might be more concerning because we don't know what is being censored and what isn't. These censorships cross country lines and it is hard to know what is being censored and what isn't.
So I'm not trying to make a "Murica good, China bad" argument. I'm trying to make a "let's try to verify or discredit the claims." I want HN to be more nuanced. And I do seriously appreciate you engaging and with more depth and nuance than others. I'm upvoting you even though we disagree because I think your comments are honest and further the discussion.
Don't really see how the string (and other usual container types) or filesystem APIs are lacking in any significant way compared to stdlibs of other scripting languages.
I also believe that buffer as an abstraction strictly makes many harder things easier, to the point I often wonder about creating a native library based on elisp buffer manipulation APIs alone that could be embedded in other runtimes instead. So the without touching buffer is a premise/constraint I don't quite understand to begin with.
That's actually the zen of programming emacs: don't avoid using buffers; create as many of them as you need.
"But that's like opening a document every time I want to glue two strings together!"
Not at all. A buffer is just a fancy blob of RAM. It's not file-backed unless you make it file-backed. They do take up RAM, but you're programming on a modern computer, not a PDP-11; if you're comfortable with Python using a whole in-memory object to represent an integer, you're comfortable with buffers.
"But it's messy to leave them lying around."
It's a feature. Yes, buffers aren't well-encapsulated and if your program crashes mid-run they get left open. That's by design. You don't need encapsulation because you're not doing multithreading here (and if you are, there are primitives for that and they take a bit more work to use); emacs is for editing and there's only one you, so if the current program is creating buffers and has no way to run two copies of itself at once, who cares. And your program crashing leaving buffers around is a feature; you can inspect the buffer and see what it looked like at crash-time, or set up the buffers the way you want them before firing off the program to get the desired effect (try those tricks with most languages without slapping on a debugger). And there are scripting blocks to create temp buffers and clean up your buffers for you anyway.
"But it's weird to have two ways to talk about strings in the language!"
That's true; it's a bit weird to have the string primitives and also buffers. But that's a pretty common flavor of weird; Java has strings and also has StringBuilder. My rule of thumb is "any time I'd reach for StringBuilder in Java, I should probably consider using a buffer in elisp."
Yep I think it's the best, period. Qwen3-coder perhaps took the limelight but the GLM models perform and behave better in agentic loops. I cannot believe they had gone from a 32B frontend focused GLM-4 to these beasts that can challenge Claude, in a matter of months.
Yep peg.el[1] is now built-into Emacs since 30.1 (which is how I came to know of it, but actually the library seems much older) and it makes certain things much simpler and faster to do than before (once you figure out its quirks).
Alibaba from beginning had some series of models that are always closed-weights (*-max, *-plus, *-turbo etc. but also QvQ), It's not a new development, nor does it prevent their open models. And the VL models are opened after 2-3 months of GA in API.
Hunyuan Image 2.0, which is of Flux quality but has ~20 milliseconds of inference time, is being withheld.
Hunyuan 3D 2.5, which is an order of magnitude better than Hunyuan 3D 2.1, is also being withheld.
I suspect that now that they feel these models are superior to Western releases in several categories, they no longer have a need to release these weights.
> I suspect that now that they feel these models are superior to Western releases in several categories, they no longer have a need to release these weights.
Yes that I can totally believe. Standard corporation behaviour (Chinese or otherwise).
I do think DeepSeek would be an exception to this though. But they lack diversity in focus (not even multimodal yet).
It's just that "improvement" as a matter of public consensus that everyone can agree on to elect the next blank slate has been to impossible to settle on. But the counterculture here broadly might be extreme reluctance to inconvenience even a minority of existing users, in pursuit of market share/growth.
reply