Hacker Newsnew | past | comments | ask | show | jobs | submit | comex's commentslogin

They probably aren’t affected because the buggy code was only added in macOS 26:

https://github.com/apple-oss-distributions/xnu/blame/f6217f8...


Ouch - "every Mac" from the original post is a hallucination then.

I can live with the writing style when the topic is interesting (here it was for me) but complete untruths are much worse.


The bug was introduced only last year in macOS 26:

https://github.com/apple-oss-distributions/xnu/blame/f6217f8...


> Apple Community #250867747: macOS Catalina — "New TCP connections can not establish." New connections enter SYN_SENT then immediately close. Existing connections unaffected. Only a reboot fixes it.

This is a weird thing to cite if it's a macOS 26 bug. I quite regularly go over 50 days of uptime without issues so it makes sense for it to be a new bug, and maybe they had different bugs in the past with similar symptoms.


Interesting. The article mentions complaints on the forums running Catalina, so that must be something else.

As someone who also operates fleets of Macs, for years now, there is no possible way this bug predates macOS 26. If the bug description is correct, it must be a new one.

The article is written using AI, so unless you verified the complaints, the safe default assumption is that they don't exist.

It definitely exists, but it could be a completely unrelated issue.

https://discussions.apple.com/thread/250867747


It definitely would be unwelcome for EU authorities in cases like the recent US sanctions against ICC officials.

Not to mention the German debanking and account closing of a few middle eastern journalists living in Germany, their spouses and in one case their children.

Fair... they should think about this then

From some skimming of the code, it seems like a nightmare quality-wise. But if it works, it works. I wonder what makes it faster.


Primarily that it doesn't work


Well, it sounds like a real issue, but the diagnosis is AI slop. You can see, for example, how it takes the paragraph quoted from waydabber (attributing the issue to dynamic resource allocation) and expands it into a whole section without really understanding it. The section is in fact self-contradictory: it first claims that the DCP firmware implements framebuffer allocation, then almost immediately goes on to say it's actually the GPU driver and "the DCP itself is not the bottleneck". Similar confusion throughout the rest of the post.


Agree. I started reading the article until I realized it wasn’t even self-coherent. Then I got to the classic two-column table setup and realized I was just reading straight LLM output.

There might be a problem but it’s hard to know what to trust with these LLM generated reports.

I might be jaded from reading one too many Claude-generated GitHub issues that look exactly like this that turned out to be something else.


Parts of it were pasted from my Claude Code Logs, Parts were written by me - and the table - that was me!


I think you are probably right--it's a real problem.

As an article, it is not 100% coherent, but there is a valid data and a real problem that is clear.


It does in Rust: assert is always enabled, whereas the debug-only version is called debug_assert.

But yes, “assert” in most languages is debug-only.


He said

> some people would expect it to enforce that the pointer is non-null, then proceed

No language magically makes the pointer non-null and then continues. I don't even know what that would mean.


If you don't even know what that would mean then it's premature to declare that nothing works that way. Understanding the meaning is a prerequisite for that.

In this case, it may help to understand that e.g. border control enforces a traveler's permission to cross the border, then lets them proceed.


Some of what you said is true, but you definitely can’t call close multiple times on the same file descriptor. close always immediately drops the file descriptor and isn’t like non-blocking socket operations that you have to try repeatedly until they succeed. You could, however, create multiple file descriptors pointing to the same socket with dup or other methods, in which case you’d need to close all of them to disconnect the socket.


Bah, I was thinking of shutdown


That was a very different case.

Out of the two claims, the only one that made it to appeals court was about whether it was fair use for Bleem to use screenshots of PS1 games to advertise its emulator (which was compatible with those games). The Ninth Circuit decided it was. But that's not relevant here.

The other claim was more relevant, as it was an unfair competition claim that apparently had something to do with Bleem's reimplementation of the PS1 BIOS. But the district court's record of the case doesn't seem to be available online, and the information I was able to find online was vague, so I don't know what exactly the facts or legal arguments were on that claim. Without an appeal it also doesn't set precedent.

If there were a lawsuit over OpenTTD, it would probably be for copyright infringement rather than unfair competition, and it would probably focus more on fair use and copyrightability. For fair use, it matters how much something is functional versus creative. The PS1 BIOS is relatively functional, but a game design and implementation are highly creative. On the other hand, despite being creative, game mechanics by themselves are not copyrightable. So it might come down to the extent to which OpenTTD's code was based on the reverse-engineered original code, as opposed to being a truly from-scratch reimplementation of the same mechanics. Visual appearance would also be relevant. Oracle v. Google would be an important precedent.


FreeBSD, NetBSD and OpenBSD at first when every BSD OS was just part of 386BSD it used to have AT&T code. That code was rewritten replacing every propietary part and after that (and noticing BSD 4.4 was incomplete) we got clean FreeBSD, NetBSD and OpenBSD from a NetBSD fork.

Another similar case with exact grounds was GNU which with Linux it completed an OS albeit in a hacky way, because the original OS would have been GNU+Hurd, but both are reimplementing Unix. Same SH derived shell, but extended. Kinda like OpenTTD. We have GNU Coreutils, Findutils, GNU AWK reimplementing and extending AWK (even when AWK was propietary), GNU Zip, Tar... the list goes on and on.

Oh, another one: Lesstif vs Motif. Same UI, if not very, very close to Motif 1.2 in order to be interoperable. Today it doesn't matter because nearly a decade a go Motif was relicensed into the GPL, but tons of libre software depending on propietary Motif was just seamlessly running with LessTIF libraries except for some rough edges/bugs. One of the most known example was DDD, a GUI for GDB.


> Unless they're also implying that the US government should be allowed to go after UK companies that don't follow it's free speech regulations because American citizens can access them.

Precedent in the US is that courts do in fact have jurisdiction over a foreign website's owner if the owner "purposefully availed itself of the U.S. forum or purposefully directed its activities toward it", a test which is less demanding than it sounds. [1]

And US has taken advantage of this to go after foreign websites such as Megaupload, BTC-e, Liberty Reserve, etc.

Therefore, if there were a US law requiring companies to follow free speech rules, it could potentially be enforced against foreign website owners. But no such law currently exists. The First Amendment itself only applies to the US government (and to companies working on behalf of the US government). There is also the SPEECH Act, which, among other provisions, creates a cause of action where if someone sues a US person in a foreign court over their speech, they can sue back in US court. But only for declaratory judgement, not damages or an injunction. The goal is mainly just to prevent US courts from enforcing judgements from the foreign court in such cases.

[1] https://tlblog.org/how-to-find-personal-jurisdiction-over-fo...


Typically, it doesn't have the ability to deal with a full 64 bits of memory, but it does have the ability to deal with more than 32 bits of memory, and all pointers are 64 bits long for alignment reasons.

It's possible but rare for systems to have 64-bit GPRs but a 32-bit address space. Examples I can think of include the Nintendo 64 (MIPS; apparently commercial games rarely actually used the 64-bit instructions, so the console's name was pretty much a misnomer), some Apple Watch models (standard 64-bit ARM but with a compiler ABI that made pointers 32 bits to save memory), and the ill-fated x32 ABI on Linux (same thing but on x86-64).

That said, even "32-bit" CPUs usually have some kind of support for 64-bit floats (except for tiny embedded CPUs).


The 360 and PS3 also ran like the N64. On PowerPC, 32 bit mode on a 64 bit processor just enables a 32 bit mask on effective addresses. All of the rest is still there line the upper halves of GPRs and the instructions like ldd.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: