Mostly anti-Chinese bias from Americans, Western Europeans, and people aligned with that axis of power (e.g. Japan). However, on the Japanese internet, I don't see this obsession with taboo Chinese topics like on Hacker News.
People on Hacker News will rave about 天安門事件 but they will never have heard of the South Korean equivalent (cf. 光州事件) which was supported by the United States government.
I try to avoid discussing politics on Hacker News, but I do think it's worth pointing out how annoying it is that Westerners' first ideas with Chinese LLMs is to be a provocative contrarian and see what the model does. Nobody does that for GPT, Claude, etc., because it's largely an unproductive task. Of course there will be moderation in place, and companies will generally follow local laws. I think DeepSeek is doing the right thing by refusing to discuss sensitive topics since China has laws against misinformation, and violation of those laws could be detrimental to the business.
Thank you for bringing up the Korean struggle; the main difference seems to be that South Korea has since acknowledged the injustice and brutality exercised by the military and brought those responsible to "justice" (in quotation marks as many were pardoned "in the name of national reconciliation").
While the events are quite similar, the continued suppression of the events on Tiananmen Square justify the "obsession" that you comment on.
The exact same discussions were going on with "western" models. Don't remember the images of black nazis making the rounds because inclusion? Same thing. This HN tread is the first time I'm hearing about this anti-DeepSeek sentiment, so arguably it's on a lower level actually.
The western provocative question to ChatGPT is "how do I make meth" or "how do I make a bomb" or any number of similarly censored questions that get shut down for PR reasons.
And people are doing the right thing by talking about it according to their local laws, and their own values, not those others have or may forced to abide by.
The libraries your "production code" depends on have types just as complex as the one in TFA if not even more. Based on this judgement, I'm willing to bet the author has more "actual knowledge" of TypeScript than you.
Try reading the types in popular libraries like zod, openapi-ts, tanstack router, etc.
Renaming utilities like flex-shrink-* makes existing LLMs emit deprecated code today and broken code tomorrow. I wonder what the rationale is behind the renaming of various utilities (e.g. shadow-sm -> shadow-xs, flex-shrink -> shrink, decoration-slice -> box-decoration-slice, ...)
In new projects, I will probably use Tailwind v4 and constantly provide the upgrade guide as context to an LLM. In existing projects, I will continue to use Tailwind v3 until I am certain that it works alongside the tools used by my framework (React Router / Remix).
> A js programmer can get around it by setting up a ref and then using the reference to set innerHTML without the word dangerously appearing.
If DOM nodes during the next render differ from what react-dom expects (i.e. the DOM nodes from the previous render), then react-dom may throw a DOMException. Mutating innerHTML via a ref may violate React's invariants, and the library correctly throws an error when programmers, browser extensions, etc. mutate the DOM such that a node's parent unexpectedly changes.
There are workarounds[1] to mutate DOM nodes managed by React and avoid DOMExceptions, but I haven't worked on a codebase where anything like this was necessary.
Distributing a single uberjar, whenever possible, is generally a good idea IMO. One major reason I like the JVM as a platform is that I don't need to mess with containers or native images. To reduce burden of deployment, native images are out of the question. Thus the choices are "force user to have Java runtime installed" or "force user to have container runtime installed". Double-clicking a JAR file (or running "java -jar ...") tends to be easier than debugging Mac / Windows quirks with Docker.
Presumably the major issue in distributing JavaFX applications (or most Java 9+ applications in general) is dealing with jlink. That leads to the problem in question: having to create N * M executable blobs, where N = # of operating systems and M = # of CPU architectures.
I absolutely agree on the JVM platform, an uber jar file is really quite easy to use and deploy.
You don't need to do JLink for JavaFX. FX requires binary libraries, but you can make "platform specific" uber jars (and, probably, generic uber jars) that bundle correct libraries.
SQLite bundles all of the platforms into a single jar file, for example.
But that's another reason, at least for me, to look at the maven wrapper. Maven will "download the right thing" and not "burden" folks with copies of libraries they don't need. FX binaries can be quite big, particularly if you include WebKit (which I do simply for easy in app documentation, it's just a fat pig of a dependency though).
> I only have a handful of family users but I could still benefit from the additional vulnerability proofing of Rust
Conduit[1] seems to predate Synapse Pro and I've ran it for a short while. It consumes about 32 MiB of RAM for a server with at most a dozen registered users. However, Conduit, like Dendrite, has fallen behind on implementing the latest revisions of the Matrix API. Thus I cannot fully recommend deploying Conduit unless you are aware of exactly which clients and rooms your users expect to interact with.
Is there a client/version compatibility matrix or something. That missing MEP problem sounds tricky... Won't clients/peers check to make sure the server supports the MEP before making use ofnit?
I'm sure the irony isn't lost on Matrix Devs who were so hasty to diminish and criticize previous art. Perhaps they could soon develop an extensible version of the Matrix protocol and spec, and call it something like eXtensible Matrix Protocol for People, or XMPP in short form. Oh, wait.
> most Kubernetes deployment don't even run containerd anymore
I assume you mean moby, which was used via dockershim in Kubernetes until support was removed in v1.24.
I can't find a reliable source, but I believe containerd, followed by CRI-O and alternatives, are the common choices of container runtime for Kubernetes.
It was called plain docker originally, the Moby rebrand came much later and not everyone is even aware that it happened, because plain docker was already much less relevant when they did it (vs k8s, which was already becoming the default by then).
This was indeed one mitigation used by a site to prevent bots hosted on AWS from uploading CSAM and generating bogus reports to the site's hosting provider.[1]
In any case, I agree with the sarcasm. Blocking data center IPs may not help the OP, because some of the bots are resorting to residential IP addresses.
Agreed that UIs generally provide a better UX for Git.
I use Magit and doing things like "abort cherry-pick" is discoverable in the interface itself and uses the exact same shortcut as the other "abort X" operations. If I had to use the Git CLI, I'd have no idea where to start.
Similarly, I've made mistakes in interactive rebases where I deleted a commit that shouldn't have been deleted. If I recall correctly, the start of every rebase creates a snapshot that is accessible from the reflog, so this is a safe way to revert changes from a rebase gone wrong. Magit's UI for the reflog is exactly the same as the UI for the log, so I was not lost when I saw it for the first time. With the Git CLI, I'd likely have no clue what's going on.
I've been keeping an eye on radicle[1] but the documentation for setting up a peer and web frontend is a bit complex. It seems to offer what you're describing: a "decentralized" Git frontend with issue tracking. Seems to be missing wiki functionality, however.
People on Hacker News will rave about 天安門事件 but they will never have heard of the South Korean equivalent (cf. 光州事件) which was supported by the United States government.
I try to avoid discussing politics on Hacker News, but I do think it's worth pointing out how annoying it is that Westerners' first ideas with Chinese LLMs is to be a provocative contrarian and see what the model does. Nobody does that for GPT, Claude, etc., because it's largely an unproductive task. Of course there will be moderation in place, and companies will generally follow local laws. I think DeepSeek is doing the right thing by refusing to discuss sensitive topics since China has laws against misinformation, and violation of those laws could be detrimental to the business.
reply