MurphyA/hacker-news huggingface dataset:
by MindSpunk | 2025-10-20 05:01:12+00:00
Not saying it's what's happened here, but it's very easy for someone to post any image and claim it's from the same incident. Get the post enough attention and if it seems genuine enough other people will share and repost without fact checking, then people will share and reposts the reposts, and so on.

Professional outlets do this all the time, and they're _paid_ not to mess this up. Copying other outlet's bad reporting without fact checking, then once a couple more "corroborating" articles come up (or one from a reputable outlet) and it'll just be repeated as fact, they can't all be wrong right?
by hhutw | 2025-10-20 05:04:59+00:00
For anyone who is interested, the author of this diagram also made a Linux disk I/O diagram (https://zenodo.org/records/15234151). These diagrams are from his book Operativni sustavi i računalne mreže - Linux u primjeni (https://zenodo.org/records/17371946)

Shout out to the brilliant and generous work of the author!
by AlotOfReading | 2025-10-20 05:05:52+00:00
Perhaps, but I'll note that the pictures in the article show the region as being easily that extreme, and the words say this

It's not. The Gobi is filled with marginal seasonal grazing lands, though certain areas are more valuable than others. It's undergone additional desertification in recent centuries as well.

That's different in no way from what I stated above. If you want to tax people crossing the desert, you station the tax collectors at the oases all travelers must visit.

People in the Gobi, particularly the northern Gobi, don't always (or even usually) travel by way of journeys between oases. That style of travel is more characteristic of silk roads and the deserts to the southwest like the Taklamakan.

If you want to tax nomads showing up to buy tools, you station the tax collectors in the markets they must visit.

This wall doesn't run through market areas. The markets involved would have been farther south in the tangut heartland, southwest in the hexi corridor, or north in Mongolia proper. "Markets" is also a bit of a misleading term here because the Mongolian side of this trade would have been a diffuse network of nomadic groups rather than people inhabiting fixed cities on a landscape.

I'm not emphasizing this for pedantic reasons. This wall is generally thought to have been intended as a very literal manifestation of the boundaries of the state and this whole area is what we call a borderlands. Western xia itself is a bit of a borderland in its entirety, and probably found it pretty useful to lay out a very physical manifestation of their power everyone could see. That's not the only reason something like this would have been built, but it's a relevant one.

Medieval states were constantly negotiating the boundaries of power before everyone accepted the modern notion of statehood. Physical walls were a particularly popular way to make that point in what's now China.

And in both cases, there's not an alternative. You can't direct the people to go visit the tax collector; they won't follow your instructions. What would be in it for them?

The parts you're responding to were speaking more specifically about the mongol period, which I know more about. This particular borderland is a somewhat different place a couple centuries earlier.

But anyway, the mistake here is thinking in a modern transactional framework. That's not how (mongol-era) Mongolia worked. Hierarchy was based on personal loyalty networks. A vassal provided loyalty, which could include taxes. Disloyalty was swiftly punished if the lord could, or the loyalty arrangement was renegotiated to something more agreeable. If it sounds like a fragile way to run a continent-spanning empire, you've identified one of the issues the Mongols faced

Similar things existed outside Mongolia as well, but Wikipedia's going to be as good or better than what I know on the subject.
by Animats | 2025-10-20 05:06:48+00:00
I think that's right. The ENIAC people were working on ballistics for large guns, and needed to crunch numbers and create printed tables. The Turing team was working on key-testing, like a Bitcoin miner. Colossus was a key tester, trying patterns zipping by on endless loops of tape, and recording matches. Any general purpose machine today can do both, but the early machines were specialized.

What general purpose architecture should roughly look like was known all the way back to Babbage. Some kind of long list of instructions, with unconditional and conditional branches. Zuse and Atanasoff both got there before WWII.

The big hangup was memory. All early computing struggled with memory limitations, as I mention occasionally. CPUs and instruction decoding came long before enough memory to store programs. Memory was still a million dollars a megabyte in the mid-1970s.
by imiric | 2025-10-20 05:06:55+00:00
What an arrogant, wordy, and partly wrong take on this matter.

No, LoC is not a dumb metric. In the same way that cognitive complexity, code coverage, and similar metrics aren't. CC is definitely not "superior" to LoC, it's just different.

These are all signals that point to a piece of code that might need further attention. It is then up to the developer to decide whether to do something about it, or not.

You know what's dumb? Being dogmatic, one way or the other. There are very few hard rules in software development—they're mostly tradeoffs. So whenever I hear someone claiming that X is always bad or always good, I try to poke holes in their argument, or just steer clear from their opinion.
by RHSeeger | 2025-10-20 05:08:20+00:00
> If you never do that computation a second time anywhere else, I would argue that a new function is worse because you can't just scan in it quickly top to bottom.

I feel exactly the opposite. By moving "self contained" code out of a method, and replacing it with a call, you make it easier to see what the calling location is doing. Ie, you can have a method that says very clearly and concisely what it does... vs making the reader scan through dozens or hundreds of lines of code to understand it all.

Chapter 12 of Kent Beck's book Tidy First? is about exactly this.
by dlcarrier | 2025-10-20 05:10:20+00:00
US residential power distribution transformers are 240 V, with a center tap. There are sometimes 240 V plugs, when high-current appliances aren't hard wired. Usually that's clothes driers and ovens/ranges. Water heaters and central HVAC systems are usually hard wired to 240 VAC.

For everything else, where more than a KW or two is overkill, the plugs connect between the center tap and one output of the transformer, for 120 V. It gives the advantage of high power where it's needed, up to 12 KW peak or 9.6 continuous, without dangerous voltages where the power isn't needed.

Modern outlets do have all of the modern safety features, like shutters and arc or ground fault detection, but the more appropriate voltage means that when they aren't available, it's still safe. There's kind of a running joke for DIYers that everyone claims to turn the power off before rewiring outlets, but no one really does, unless it's a 240 V outlet.
Show HN: I built a friend app after watching Twitter/X tear itself apart
by abilafredkb | 2025-10-20 05:10:25+00:00
A month ago, I was doom-scrolling Twitter at 2am in Accra and got hit with post after post of people tearing each other apart. I closed the app thinking "we have such a long way to go." Then I remembered something: a few years back, I hesitated for 48 hours before messaging someone on Facebook who would become my mentor. I was scared—previous scammers had burned me. But I gave myself that window to decide. I messaged him. He changed my life. That night, I thought: what if that 48-hour window could work for everyone? So I built Eintercon.

How it works: You match with someone internationally based on shared interests (sci-fi books, indie music, whatever you're genuinely into) You have exactly 48 hours to chat and see if the connection is real After 48 hours, you both decide: keep going or move on No ghosting. No guilt. No conversations dying in your inbox.

Why 48 hours? Because it creates urgency without pressure. It's long enough to have real conversations, short enough that you can't procrastinate forever. Either the friendship sparks, or you both deserve better matches. Every other friend app lets you match with 50 people and message none of them. We force a decision. It's uncomfortable, but it works. Why international? Because you can't hate someone whose story you know. Because the person who gets your weird obsessions might be in South Korea, not your city. Because division thrives in bubbles, and I'm tired of bubbles. One month in:

200 users across 30+ countries Zero marketing budget (just word of mouth) People telling me they made their first real friend in years A user in Ghana and a user in Seoul are now best friends over sci-fi books

The tech: React Native, Node.js, Firebase, PostgreSQL. Nothing fancy. I'm a student splitting time between classes and coding. It's scrappy but it works. What I'm struggling with:

Keeping international matches feeling balanced (timezone challenges)

Building safety features without killing spontaneity

Figuring out monetization that doesn't feel gross

What I learned:

People are desperate for genuine connection Urgency > features for engagement Emotional intelligence beats algorithms You don't need funding to validate an idea

Why I'm posting here:

I want to hear from people who've tried to solve loneliness with tech. What worked? What didn't?

Honestly? I'm hoping some of you try it and tell me what's broken.

The bigger question: Can software actually fix loneliness? Or are we just creating better ways to be alone together? I don't know yet. But 200 people have real friends now who didn't a month ago. That feels like something.
by somenameforme | 2025-10-20 05:11:07+00:00
Yes, he did reject it, completely. In his own words:

----

"We have become Antipodean in our scientific expectations. You believe in the God who plays dice, and I in complete law and order in a world which objectively exists, and which I, in a wildly speculative way, am trying to capture. I firmly BELIEVE [emphasis original], but I hope that someone will discover a more realistic way, or rather a more tangible basis than it has been my lot to find. Even the great initial success of the quantum theory does not make me believe in the fundamental dice-game, although I am well aware that our younger colleagues interpret this as a consequence of senility. No doubt the day will come when we will see whose instinctive attitude was the correct one."

Einstein, 1944

----

He rejected it based on his instincts. He felt it was wrong. Einstein in general poses a major problem to many of those of a certain mindset of what drives success in science and academia, because he was arguably the greatest scientist to have ever lived, yet he was no less possessed of the demons of bias, prejudice, and 'feels' than anyone else - if anything he seems to have suffered them perhaps even more greatly than average. As you can see in his own words, not only did he reject it - but he actively mocked the entire idea, repeatedly.

There's no nuance to be had there. The only issue is that Einstein's behavior, character, and even history largely contradicts the idealized view of science and scientists that many like to try to imagine, or push, now a days. It also again largely contradicts the ideal that science, in and of itself, is what drove such rapid progress. I think the truth is that we don't know what drove such rapid progress, but we can use people like Einstein (and many other great scientists it turns out...) to falsify most hypotheses.
by thaumasiotes | 2025-10-20 05:12:23+00:00
> The article mentions there were frequent wells and encampments

They aren't arguing that wells were dug to support the wall garrison. They're arguing that, because the wall needed to be garrisoned, it could only visit places where there were or could be wells:

>> our spatial and ecological analysis demonstrates that the distribution of local resources, such as water and wood, was critical in determining the route of the wall and the placement of associated garrisons and forts.

( https://www.mdpi.com/2073-445X/14/5/1087 )
by johnnyApplePRNG | 2025-10-20 05:12:30+00:00
>assuming that it doesn’t break down.

Ha! Good luck with that.

The last time I bought a brand new freezer... it died in under 5 years... can't remember the brand... some asian import to Canada here.

I went out and bought a used kenmore I think it was off of Marketplace... >15 years old and it lasted longer than the brand new one did... at 1/4 the price!

These were both chest freezers and besides it's compressor being slightly louder, I doubt it used much more energy at all. If anything, it was probably insulated better, and used less I would imagine. It was much heavier, at least.
by Maxatar | 2025-10-20 05:16:26+00:00
When someone says "I don't understand why FOO matters so much..." it's usually understood that the author is trying to say "FOO doesn't matter". When the author then follows up with "It's sad that FOO is seen as so important." it kind of makes it clear what the author really intended to say.

I'm sorry if this doesn't make sense to you but the intent here is quite unambiguous. It's nothing more than an attempt at moral posturing without a basic understanding of how culture propagates.

Like it doesn't take a genius to understand that one of the most widely consumed cultural product in history is going to influence who the public recognizes and pretending otherwise is just performative ignorance.
by codery | 2025-10-20 05:20:02+00:00
This looks great, I'm still learning Janet and couldn't write it myself.

I only know about: https://github.com/Engelberg/better-cond in clojure which is different it adds syntax enhancement + control flow convenience.

Similar better-cond can be written in clojure too:

(defn better-cond [& clauses] (fn [& args] (some (fn [[pred result]] (when (apply pred args) (if (fn? result) (apply result args) result))) (partition 2 clauses))))

But it's not composable as Janet's version, it will fail when mapped over, because it may return a plain value instead of a callable one. In Janet, all values can naturally participate in higher-order contexts due to its uniform treatment of callables, while in Clojure, only actual functions can be composed or mapped.
by gizmo686 | 2025-10-20 05:20:38+00:00
The solution I've seen employed is to prevent the build environment from reaching outside.

Setup a mirror of all the repositories you care about; then configure the network so your build system can reach the mirrors; but not the general Internet.

Of course, once you do this, you eventually create a cron job on mirrors to blindly update themselves...

This setup does at least prevent an old version of a dependency from silently changing, so projects that pin their dependencies can be confident in that. But even in those cases, you end up with a periodic "update all dependencies" ticket, that just blindly takes the new version.
by coliveira | 2025-10-20 05:22:08+00:00
This is not a real issue, because the same thing can be said about C. No two C projects are the same, each has its own set of libraries, macros, types, etc.

I think the main problem is that Forth systems don't have a standard way of creating interfaces like C and other languages have. So the diversity of environments becomes a big issue because it's difficult to combine libraries from different sources.
by sriku | 2025-10-20 05:22:42+00:00
I've had a soft spot for Forth and am toying with a silly Forth-like interpreter for web programming ... if not for actual use, at least for some fun time. One concept it adds is the notion of a "current selection" which can define the available vocabulary to use and is used to select and work with DOM elements. Just experimenting.

https://github.com/srikumarks/pjs

Edit: As a kid, I disliked BASIC as a language though it let me do fun stuff. So I made an interpreter in BASIC for a language I'd like and it turned out Forth-like (and I didn't know about Forth at that time). I guess I'm still that kid some 35 years later.
by elevation | 2025-10-20 05:26:49+00:00
Eventually I used more detailed diagrams, but this one was like a lightbulb going off:

https://www.frozentux.net/iptables-tutorial/images/tables_tr...

I couldn’t find one that annotated where sysctl configurable were shown. But this is a useful annotation, even if it’s an exercise for the reader.
by toast0 | 2025-10-20 05:28:19+00:00
> IMHO the actor model is great until you need to share something across processes, then you have a distributed computing problem inside your program.

I'm sorry, but your multicore computer (and most single core computers, too) are a distributed system, regardless of if you acknowledge it.

Shared memory concurrency use implicit communicatiom between threads, but it's still communicating processes, you just don't have the same level of control and isolation. That said, of course there are situations where you can have better results with shared memory and there are situations where message passing is better. You can do shared memory in BEAM with ets, and if that doesn't meet your needs, with NIFs ... you likely lose out on some isolation, etc, and it won't always be a good fit.

> Plus the JVM software ecosystem and runtime observability / battle-testedness is far better than BEAM.

Maybe battle tested (although, I've certainly battle tested BEAM more than I've tested JVM; but I'll grant that many more people have done battle with the JVM)... but BEAM has quite extensive observability. You can see all sorts of stuff about every process, you can add tracing at run time. You can change the code at run time if you need to add more stuff; and runtime code changing is just in the normal setup, it's not exotic (although many people eschew it)
by 0x073 | 2025-10-20 05:29:59+00:00
I tried to love the Linux file manager, but it's a mess with current fedora kde dolphin crashes randomly, mounted nas storage with smb or NFS (synology nas) is slower and depending on how you mount the storage some apps can't open the files.

Maybe the crashes could be solved with a more stable os like debian, but the explorer shell integration is on windows on another level with network storage.
by _DeadFred_ | 2025-10-20 05:32:09+00:00
I like the Chinese people, Chinese history, and loved visiting. My dad was a hippie with lots of books in the house in support of China's communist revolution.

That said I think the big one is that China did not keep their word to the UK regarding Hong Kong. So that moves them to 'suspect' as far as trust goes with Western nations.

I think their secret police stations imbedded/hidden in western nations and their supposed use for secret forced repatriation of people really soured a lot of people/nations on trusting China's behavior.

They are doing a lot of saber rattling regarding Taiwan. Lots of flights as well as naval movements that have raised concerns.

People really don't like what they believe has been happening in Xinjiang.
by thaumasiotes | 2025-10-20 05:32:58+00:00
> I'm not emphasizing this for pedantic reasons. This wall is generally thought to have been intended as a very literal manifestation of the boundaries of the state and this whole area is what we call a borderlands. Western xia itself is a bit of a borderland in its entirety, and probably found it pretty useful to lay out a very physical manifestation of their power everyone could see. That's not the only reason something like this would have been built, but it's the most relevant one.

I have no problem with that. But it's unrelated to the idea I criticized, that the purpose of a wall like this is to funnel travelers with carts into a taxable chokepoint. A wall is not useful for that purpose. This wall is even less useful for that purpose than average.

I will note that the paper seems to disagree with you on what is generally thought of the wall:

>> This study challenges the perception of such structures as being purely defensive, revealing the Gobi Wall’s multifunctional role as an imperial tool for demarcating boundaries

But in this case, I'm inclined to believe you over the paper.

(I am curious about the fact that the wall was manned. That has to have been really expensive; it seems like it wouldn't be worth it for a mostly symbolic wall?)

> It's not [that extreme]. The Gobi is filled with marginal seasonal grazing lands

That doesn't really matter to the question of whether travelers attempting to cross it risk getting lost and dying if they go offroad. They're not traveling with a herd of sheep. They can't eat the odd patch of dusty grass, or find water.

And when the article notes that the wall seems to have been constructed in a way that specifically takes advantage of local sand dunes, that also suggests an inhospitable environment to me.
by mikepurvis | 2025-10-20 05:33:30+00:00
Most monitors and TVs do buffer at least a whole frame because of the processing, scaling, etc that they're doing: https://www.rtings.com/monitor/tests/inputs/input-lag

That said, yeah, in the special case of an HDMI-driven CRT that was specifically designed with ultra low latency in mind, you could buffer way less than a frame— though I imagine you'd probably want to buffer at least a line at a time just for sanity with the timing of driving the electron gun. And obviously this would depend on the HDMI picture resolution exactly matching that of the CRT.
by mirekrusin | 2025-10-20 05:34:35+00:00
Worth noting that "cognitive complexity" may mean SonarQube metric – a metric that is not widely recognized by industry, created by SonarQube employee as (imho failed) attempt to address "issues" with "cyclomatic complexity" (principled, intdustry recognised metric). It'll count things like nullish coalescing and optional chaning as +1 on your complexity which makes it unusable with jsx or ts code.

With low thresholds ("clean code" like low) both LoC and "cognitive complexity" (as in SQ) are bad measures that lit up in red large percentage of otherwise correct code in complex projects. The way people usually "solve" them is through naive copy pasting which doesn't reduce any cognitive load - it just scatters complexity around making it harder to reason about and modify in the future.
by dagss | 2025-10-20 05:34:46+00:00
I am very interested in event sourcing DBs, having spent a fair amount of my career with event sourcing in both SQL and NoSQL databases.

I miss easy access to the actual technical details of https://www.thenativeweb.io/products/eventsourcingdb . In what ways is it technically different from schemas and patterns you do yourself with SQL databases to support event sourcing? Is it similar to Materialize and in what ways? Etc.

There is documentation from a high level users perspective, the "what". But I cannot find a description of the technology, the "how". I can (and have several times) implemented the same thing on top of SQL databases; and in that case I get a very good handle on the scalability, redundancy, backups, etc..

To know if it is worth adopting I really need to be able to see some technical platform details to evaluate it myself. If all you can say is "trust us it will work" I will have to go other places that actually publish details.
by troupo | 2025-10-20 05:36:06+00:00
> I think I'm better off using a functional effects system with software transactional memory like Scala/ZIO than Gleam/OTP

Translation: I think I'm better off using needlessly complex overengineered monstrosity that takes insane effort to do even the simplest of things, and that still gives me no actual guarantees, than a simple system that has been battle tested over decades of actual hardcore industrial use.