csense

> "Subject to orders 12 and 13, [Apple] must do all things necessary (including procuring any act of any related corporation) to ensure that users of iOS devices can discover, obtain and update iOS apps, including alternative app stores, via distribution channels other than the App Store (including via direct download and alternative app stores)..."

Good. Apple can't say "I don't like your app because [vague reasons], it's not allowed on the App Store so nobody can use it".

> "...provided those iOS apps have undergone an automated scan for genuine security and/or privacy reasons and been notarised by Apple or a suitably qualified third party (Alternative Distribution Channels)..."

Seems bad, can't Apple say "I refuse to notarise your app for 'security' [vague reasons]"?

Or does the cryptographic signatures Apple presumably gives an app uploaded to the App Store count as "notarised"? I'm picturing the following situation:

- January: Alice uploads to App Store, Apple produces a signature S of H(app), Alice downloads the bytes of S

- February: Apple says "Alice we're kicking your app out of the App Store for [vague reasons]"

- March: Alice says "Fine, then I'll put it on Bob's Alternate Appstore." Apple says "I refuse to 'notarise' your app for 'security' [vague reasons]". Alice then uploads her app to Bob's Alternate Appstore along with Apple's cryptographic signature S that Bob authenticates against a known Apple public key.

Now there are two contradictory narratives about whether Alice is notarised.

- (a) Apple says "I refuse to notarise Alice, therefore she's not notarised."

- (b) Alice says "S exists, here are its bytes, the hash and signature validate, therefore I'm notarised."

Presumably if (a) wins, Apple would be within its legal rights to block Bob's Alternate Appstore because it allowed Alice to upload an un-notarised app. This would make the whole ruling effectively toothless, because Apple still gets a veto, the veto is just renamed to "notarisation."

If (b) wins, it provides clarity for developers. In this world signing an app is effectively a no-takesies-backsies moment: Once S is published, Alice knows for sure she's notarised forever. Apple won't later be able to block Alice on a whim by hiding behind a vague "security" excuse.

Which narrative wins?

If (b) wins it seems like there's an opportunity here to create tooling for Alice to pull the S for her app on the app store as soon as it's approved. Maybe someone should spin up an observatory to constantly download S for every app as it's uploaded to the app store -- the observatory would be able to rescue Alice if she didn't have the foresight to download S herself before Apple banned her app.

(Lines starting with > are quotes from OP PDF)

Amazon reports finding evidence of an exploit attempt in logs from Saturday October 17, four days before public disclosure [1].

[1] https://news.ycombinator.com/item?id=50194070

> Californians will vote early next month on Proposition 40, a one-off 5% tax on the roughly 250 billionaires who live in the state.

If you have $1 billion and you're going to get taxed $50 million in California, why not spend $1 million to buy a house in some other state and move there on paper before the tax goes into effect?

Alice User goes to Bob's Website on the wifi at Eve's Coffeeshop. Can Eve read or inject sensitive information into Alice's browsing session?

Normally Eve's attempts fail because Alice requires a message to be signed with the private key matching the public key in a certificate for bob.example.com signed by a legitimate CA.

Unfortunately Bob bought his CA from Mal's Domains, and Mal is working with Eve for some reason (for example, Mal has been bribed, hacked, intimidated, legally pressured, etc.)

So in addition to Bob's regular on-the-books cert, Mal issues a second off-the-books cert for bob.example.com and gives it to Eve.

With CT, Alice's browser doesn't just require the cert's pubkey, it requires the server to provide a Merkle proof it was included in a CT log.

The CT log puts Eve and Mal on the horns of a dilemma: If they keep their new cert out of the CT logs, Alice's browser won't accept it. If they put it in the CT logs, Bob can read the log himself (it's public) and Bob can say "Hold it! I didn't order this!"

Bob will switch away from Mal as a TLS provider and complain "Hey everybody, Mal issued this cert I didn't order, customers should stop using him and the people who create CA lists for browsers and OS's should closely investigate whether Mal's CA activities are legitimate." Mal can't deny issuing the questionable certificate, the evidence is in public append-only CT logs for everyone to see.

Interestingly, Ethiopia wasn't always poor and backward. Back in the classical era, Ethiopia (then known as Axum or Aksum) was a major power [1].

[1] https://en.wikipedia.org/wiki/Kingdom_of_Aksum

> I would expect they would turn the criminal over to the US.

This expectation seems...poorly calibrated.

Pakistan didn't arrest Osama bin Laden, the terrorist mastermind behind an attack that killed thousands of innocent people and significantly altered the trajectory of world history. In what universe do you think they would deport a humble counterfeiter of stamps?

Reinventing the wheel is not always to be avoided. Finding an interesting wheel and trying to build your own equivalent can be an excellent way to improve your skills as a programmer [1].

"Feed it to SAT solver" is a super useful technique every seasoned programmer should have in their toolbelt.

If you want to improve your programming skill, I suggest implementing your own version of these two interesting, satisfying algorithms:

- DPLL, the classic general-purpose SAT solving algorithm [3].

- Algorithm X (aka Dancing Links), Knuth's super elegant search algorithm for solving exact cover problems [4] [5].

You're not going to build something that beats CaDiCaL [6] in an afternoon, but writing your own implementation of these algorithms will teach you a lot, and a reasonable time investment will get you to a pretty satisfying endpoint of having a practical solver for your favorite application (Sudoku, polyomino packing, etc.)

[1] Reinventing wheels is not a bad way to spend your days at a retreat focusing on one's personal growth as a programmer. "I think I'll learn a lot and get some good practice at programming and algorithmic thinking" is an easy bar to meet.

In a professional context, telling your company or client they should commit scarce, expensive engineering resources (e.g. your time) to creating and maintaining their own wheel design requires justification [2].

[2] "Don't reinvent wheels" is good general advice for junior developers. Senior developers know that sometimes there are specific situations where this general advice doesn't apply. For example, if no existing wheels meet your application's requirements, or if you have ideas for proprietary features that give you a competitive advantage. Even in a professional setting, reinventing the wheel isn't always a bad idea; you just need to meet a much higher bar to justify the commitment of resources.

[3] https://en.wikipedia.org/wiki/DPLL_algorithm

[4] https://arxiv.org/abs/cs/0011047

[5] https://en.wikipedia.org/wiki/Knuth%27s_Algorithm_X

[6] https://github.com/arminbiere/cadical

A worker is compensated in two ways: They get paid money, and they get the joy and fulfillment from doing their jobs.

A lot of artists are passionate about art [citation needed]. So the average individual with enough skill to make a career in an artistic field, faced with a choice between art and some other career -- accounting, say -- will almost always choose art if the salaries are equal; the joy and fulfillment tips the scale. But the scales balance over time; if artists are paid as well as accountants, there will be too many artists for economic demand and not enough accountants.

The pay for artists will go down and the pay for accountants will go up, until the average artist's joy and fulfillment gets balanced out by the lower pay.

This assumes art is fungible; the argument applies more to people working as artists for hire, and less to artists who cultivate a style, brand and unique audience.

IMO the best way to escape the "starving artist" trap is to embrace your individuality. There are a lot of ways for artists to connect directly to fans. Kickstarter. Patreon. Self-publishing with fulfillment-on-demand. Etsy. Anime conventions (if you're working in that art style).

For example, one artistic niche with very interesting economics is designing 3D printed miniatures for tabletop gaming [1].

As a consumer, be aware of the economics of the art you consume. Try to support artists directly instead of giving your entertainment dollars to giant megacorps.

[1] https://www.bitsaboutmoney.com/archive/payments-and-plastic-...

One of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true.

The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it."

You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator).

That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language.

(Also, what do monads have to do with it?)

The Canadian government froze the bank accounts of truckers involved in a protest [1] [2] [3].

If a government is willing to go after the property of its own citizens without due process, foreign investors have to think: "What's to stop the same from happening to me?" Even if that foreign investor's a central bank.

[1] https://www.bitsaboutmoney.com/archive/debanking-and-debunki...

[2] Maybe the truckers' protest went too far; they were blocking roads. The point isn't whether they deserved to be punished; the point is that their accounts were frozen without going through the laws and court system.

[3] This was in 2022, so it has nothing to do with the current US administration.

So...what happens to the money in the account? AFAIK normally when your account is closed, your bank gives you a cashier's check which you can use to open an account at another bank. But given that they're in OFAC, what if no other bank will have them?

Does someone who works for A/I have to drive to Italy and pick up a briefcase full of cash? Or does the money stay in the bank, inaccessible to A/I, until A/I proves they aren't terrorists? Which could be...forever, since it's basically impossible to improve you're not a terrorist once you're formally included on The Big List Of Terrorists? How do you hire a lawyer to argue your case if the money you would use to pay them has already been taken away?

A complex application process is basically a proof-of-human-work to rate-limit processing costs (for all applications, successful or not) and benefits cost (for successful applications).

In 2026, you can ask an LLM to fill out the application, reducing the expensive proof-of-human-work to a free or cheap machine proof-of-work.

I can immediately think of three different user stories for LLM-generated applications for, without loss of generality, government benefits:

- Alice is honest and likely eligible but didn't apply because the application process was too time-consuming / complex. With LLM assistance, Alice can now complete the process.

- Bob is honest and likely ineligible but didn't apply because he realized he's probably not eligible. With LLM assistance, Bob can now apply anyway -- "Throw spaghetti at the wall and see what sticks."

- Eve is dishonest and ineligible. Eve wants to make money by lying on her application to defraud the government into paying her benefits. With LLM assistance, Eve can more easily make more convincing applications to more agencies.

An interesting question that doesn't seem to be addressed by the paper is how much of the cost is driven by Alice vs. Bob vs. Eve. We can tell very different stories depending on which is the case:

- Mostly Alice: Our current taxes / budget / etc. can only pay for half of what it would cost to pay everyone entitled to benefits under the law. We quietly disenfranchise citizens of their legal right to receive benefits with a bureaucratic process that half of eligible applicants can't complete, but whoops! now a lot more people can complete it with LLM assistance and we're approving most of them because they're legitimately completing the application process and legitimately entitled to benefits. Financially it's killing us to pay what the government promised to all those people to whom it was promised.

- Mostly Bob: A lot more people are applying because LLM's make it super easy for anyone to apply. We don't approve many more applications than we did before -- but each year has about 1,000,000 more applications and 990,000 more denials than the previous year for three years running. Financially it's killing us to pay the processing costs for all those unsuccessful applications.

- Mostly Eve: We're seeing an uptick in applications that are immediately denied, or approved but later revoked, because of fraud. LLM's are making it easier for criminals to defraud the government. Financially it's killing us because we pay those fraudulent benefits before we know they're fraudulent; recovery of funds is slow and uncertain once the fraud is discovered; and fraud imposes additional costs of investigation, prosecution, and punishment.

"Bosom peril" sounds like what someone in the 1800s would write in a spicy novel describing a character's experience being unable to breathe while being hugged by a well-endowed lady.

I'm sorry, MASM? All the cool kids use NASM or YASM.

This is technical writing for kernel developers who already know how memory management works. If you want to understand it better, you should study up on the x86 MMU and the kernel memory management subsystem. I'm not a kernel expert but I found it pretty understandable, so I'll try to explain it.

MMU: The memory management unit, part of the CPU designed to allow an OS kernel to flexibly control how memory addresses used by a program map to physical RAM.

Page: A 4k region of memory addresses.

Anonymous: The page is just regular old memory used by a single process for general purposes, it's not part of e.g. a memory-mapped file.

Backing: The memory corresponding to a page. The kernel can direct the MMU to map any page to any part of RAM, or delete the mapping entirely.

Zero page: The kernel keeps a single 4 KB page filled with zeros (the "zero page").

Page fault: An error that occurs when you try to write a page that's not present, or write to a read-only page. Some page faults are normal and expected by the kernel, they support features like swapping, memory-mapped files, etc. Such "expected" page faults are invisible to your program. (On the other hand, an unexpected page fault occurs when your program just straight-up accesses an address it's not supposed to, which will end your program with a SIGSEGV signal -- an all-too-familiar experience for a C programmer.)

When you allocate say 4 MB of memory, the kernel simply sets it to 1k read-only copies of the 4 KB zero page. Then when your program tries to write to a page, it faults. The kernel handles this expected fault by assigning that page an individualized memory region. If a program allocates a lot of memory, it's only assigned memory for what it actually uses, when it first uses it. This is an optimization: Every program that allocates more memory than it needs is wasteful, but the kernel can recover that waste by not backing the allocation with memory -- the program has to prove each page is needed by writing to it.

Store to a freshly-faulted anonymous page: The program stored data to its own memory, which caused an expected page fault.

> becomes invisible to that same thread's reload ~10 instructions later

The thread fairly quickly tried to read the data from the same place in memory it had just written to. It doesn't get the same data back. This is a major problem that causes the program to malfunction and crash.

> A pagemap read at the instant of the fault shows the backing is the kernel's zero page

The expected fault occurred because the program tried to write to an address that was mapped to the zero page, probably because it's the first write to freshly allocated memory. (This rules out other reasons it might be faulted, e.g. the page had been swapped to disk.)

> concurrent munmap's TLB shootdown

The page table is big and slow so the CPU caches parts of it in an area called the TLB (translation lookaside buffer). munmap is a kernel function that removes the backing for an address region. Since munmap changes the mapping, it has to inform the MMU the relevant part of the TLB is no longer valid.

> per-VMA-lock anonymous-fault fast path

This is what the kernel does when the program first writes to a zero page. Saying it's the "fast path" implies there's some (slow) special case handling in the kernel code, but the bug doesn't trigger any of the special cases, we're in the most common case, which the kernel code tries to handle as quickly as possible because it has measurable impact on performance. I would guess per-VMA-lock has to do with how the kernel synchronizes this code (a "lock" is a basic synchronization primitive, you should be familiar with it if you do any kind of multithreaded programming).

> The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown. A source-level review of Linux 7.0.12 identifies a specific race in that interaction

The mechanism: What's actually happening to cause the program not to be able to load data it just stored in memory.

Localizes: The cause of a problem like this is a needle in a haystack -- it could be caused by the program, the kernel or the hardware. The analysis has narrowed down the haystack to a specific part of the kernel code.

Race in that interaction: Two parts of the kernel code, (1) The kernel code for munmap and (2) the kernel code to handle a program's first write to the read-only zero page for a fresh allocation. These two parts work fine individually but the problem occurs when they both try to change the page tables / TLB at exactly the same time. This is quite a small, specific haystack compared to "somewhere in the program, kernel or hardware" we started with.

Jeff Bezos is probably calling everyone he knows in Washington right now. The big question is, does he say "End this war immediately to stop them from bombing my datacenters" or "Escalate this war immediately to get revenge for them bombing my datacenters"?

It's obvious to me that writing "Give me a confidence score from 1-5" in your prompt will have disappointing results if you use that score directly. If you want self-reported confidence scores that are at all useful, you need to think about statistics and score calibration regardless of whether those scores are produced by an LLM or a human.

Take a corpus of problems you know the answers to, but the AI sometimes gets wrong [1]. Have the AI try to solve each problem and give you a 1-5 integer confidence score. The known proportion of correct answers in each bucket gives you a mapping from scores to probabilities [2].

[1] One possible corpus creation strategy might be math problems that you really need to run a program to solve. You can run the program to generate the correct answer key, but disallow tool calling for the AI.

[2] I'm pretty sure there's some stats wizardry that will let you put error bars on each bucket's probability based on the number of problems that end up in each bucket.

Was this a jury trial?

Perfect attendance is not a good goal to aspire to. Kids force themselves (or get forced by parents) to go to school while sick, which is probably bad for their health and also risks everybody else's health.

This is a great link. The most interesting feature of the solar graph is the amplitude of the seasonal variations. It looks like we typically generating ~100% more solar power in July than December.

If "we need to store solar energy from summer to winter" is indeed a significant issue, maybe you could use the extra power in summertime to make natural gas [1] and then store the gas until you need it in the winter.

[1] https://www.terraformindustries.com/ is a startup working on turning solar power into natural gas

> they shouldn't be allowed to?

Anthropic addresses this head-on in the final section of the paper titled "What should we do?" If you convince the US government to slow AI development, you have to convince China too, otherwise you're not stopping self-improving AI at all, you're just throwing away the lead to China. If you convince China too, China or the US or both might go back on their word and build self-improving AI secretly, for greed of the benefits it could bring or fear the other will go back on their word.

What you really need is a non-proliferation regime like the one for nuclear weapons, where every country makes potentially dangerous AI illegal and lets foreign or international inspectors monitor to check that nobody's building illegal AI in secret. But monitoring seems hard; it's general-purpose computation. How do you check whether a given datacenter is training an illegal AI and not just serving websites, running detailed protein folding simulations, or mining crypto? For that matter, how do you know that a nondescript industrial facility hasn't been repurposed into a hidden datacenter for training illegal AI?

Central control of heat pumps sounds like a dystopian nightmare. I don't want to give somebody outside my house the ability to shut off my heating or cooling.

The real problem is that the price of electricity isn't high enough. When supply is running out, raise the price so supply and demand can find equilibrium, then invest the new revenue into increasing capacity.

Let's be honest. If someone did send in the troops to restore order, people would be screaming "How dare you invade a sovereign country" or "You're only doing this because you want oil" or "The President wants to make Sudan the 51st state" or "You're wasting money and soldiers' lives messing around in a place most of us can't even put on a map" or "You're just doing whatever the Jews tell you to do."

Miller-Rabin primality test immediately came to mind. But apparently he improved Berlekamp's algorithm, and is responsible for the pumping lemma [1] as well.

I agree with other posters; Rabin deserves an HN black bar.

[1] Basically, the pumping lemma says if you feed a finite state machine a long enough input, the FSM must loop. You can delete the looping part of the input or insert extra copies of it; the FSM can't tell the difference, it has to give the same output. In theoretical computer science, the pumping lemma is usually introduced early, as the simplest example of a theorem that proves there are things that cannot be computed by a certain class of computing machines (FSMs).

"It’s not a safety movement. It’s a priesthood with an origin story written in fanfiction." Is that the opinion of the author, or an LLM?

I feel like this is one topic where using an LLM detracts from the author's thesis; doubly so if they don't disclose it.

From a layman's point of view antimatter seems like an ideal spacecraft fuel. It's as energy dense as E = mc^2 allows, and if you have infrastructure to make it, the only input you need to produce it is electricity.

Being able to transport it seems like an important piece of that puzzle.

Production and storage would need to be scaled by many orders of magnitude, but that's merely an engineering problem...right?

We used to believe in freedom of speech and freedom of association.

Since the dawn of the Internet era, we've had a legal principle that platforms are relatively shielded from liability for what their users do.

It's the Internet. There's sexual content and sketchy characters on it. Occasionally people will encounter them -- even if they're under 18.

Anyone who grew up in the mid-1990s or later, think back to your own Internet usage when you were under 18. You probably found something NSFW or NSFL, dealt with it, and came out basically OK after applying your common sense. Maybe it was shocking and mildly traumatizing -- but having negative experience is how we grow. Part of growing up is honing one's sense of "that link is staying blue" or "I'm not comfortable with this, it's time to GTFO". And it seems a lot safer if you encounter the sketchy side of humanity from the other side of a screen. Think about how a young person's exposure to the underbelly of humanity might have gone in pre-Internet times: Get invited to a party, find out it's in the bad part of town and there are a bunch of sketchy people there -- well, you're exposed to all kinds of physical risks. You can't leave the party as easily as you can put your phone down.

I stopped logging onto Facebook regularly around 2009; I only log in a couple times a year. I hate what Facebook has become in the past decade and a half.

But giving a site with millions of users a multi-hundred-million-dollar fine because some of those users behave badly seems...asinine.

If your kid is old enough and responsible enough to be given unsupervised Internet access, you'd better teach them how to deal with the skeevy stuff they might encounter.

I'm pretty sure you can get rid of the 0xFFFFFFFF / p and get some more speedup by manually implementing the bitarray ops. You can get another boost by using BSF instruction [1] to quickly scan for the next set bit. And you really only need to store odd numbers; storing the even numbers is just wasteful.

You can get even more speedup by taking into account cache effects. When you cross out all the multiples of 3 you use 512MB of bandwidth. Then when you cross out all multiples of 5 you use 512MB more. Then 512MB again when you cross out all multiples of 7. The fundamental problem is that you have many partially generated cache-sized chunks and you cycle through them in order with each prime. I'm pretty sure it's faster if you instead fully generate each chunk and then never access it again. So e.g. if your cache is 128k you create a 128k chunk and cross out multiples of 3, 5, 7, etc. for that 128k chunk. Then you do the next 128k chunk again crossing out multiples of 3, 5, 7, etc. That way you only use ~512MB of memory bandwidth in total instead of 512MB per prime number. (Actually it's only really that high for small primes, it starts becoming less once your primes get bigger than the number of bits in a cache line.)

[1] https://en.wikipedia.org/wiki/Find_first_set

Just in case your answers to the parent post's three questions were "Yes, yes and yes" here are some additional questions:

- Have you ever uploaded a container to Dockerhub or Quay.io?

- Does that container have an OS inside it that has user accounts?

- Before you answered parent post's questions, did it occur to you that you might have to update your Docker images to comply?

- Did you remember on your own that you also have to delete or update older Docker images to comply, or did you not think of that until you read this question?

After you've answered these questions, please re-answer the parent post's questions.

A lot of people people contributing to FOSS are volunteers. The calculus of working on stuff for free involves an assumption that your worst-case outcome is you make $0. This act's punitive fines change the worst-case outcome to somewhere around -$9999999 or more.

If you work on any programming project at all in any capacity:

- Are you confident your work doesn't fall afoul of this?

- Are you confident they won't decide to come after you anyway for insane political, bureaucratic or "seeing-like-a-state" dysfunctions?

- Are you willing to bet millions of dollars in potential fines that your answers to the previous two questions are correct?