I was confused by this because pi is not between 1 and sqrt(1/2). But I found https://www.cs.miami.edu/home/burt/manuscripts/gaussagm/agma... and it clarifies that this AGM is used in the course of approximating pi not that it’s sufficient on its own to do so.
Don't forget about entropy! You've just created two identical copies of all of your random number generators, which could be very very bad for security.
The firecracker team wrote a very good paper about addressing this when they added snapshot support.
Good callout. We seed entropy before snapshot to unblock getrandom(), but forks still share CSPRNG state. The proper fix per Firecracker’s docs is RNDADDENTROPY + RNDRESEEDCRNG after each fork, plus reseeding userspace PRNGs like numpy separately. On the roadmap. https://github.com/firecracker-microvm/firecracker/blob/main...
Off the cuff, the first step to ASLR is don’t publish your images and to rotate your snapshots regularly.
The old fastCGI trick is to buffer the forking by idling a half a dozen or ten copies of the process and initialize new instances in the background while the existing pool is servicing new requests. By my count we are reinventing fastCGI for at least the fourth time.
Long running tasks are less sensitive to the startup delays because we care a lot about a 4 second task taking an extra five seconds and we care much less about a 1 minute task taking 1:05. It amortizes out even in Little’s Law.
Re-seeding is easy. The hard parts are (a) finding everything which needs to be reseeded -- not just explicit RNGs but also things like keys used to pick outgoing port numbers in a pseudorandom order -- and (b) making sure that all the relevant code becomes aware that it was just forked -- not necessarily trivial given that there's no standard "you just got restarted from a snapshot" signal in UNIX.
RFCs may say that simultaneous connect must be allowed, but that doesn't mean that firewalls can't block it. Plenty of setups block incoming SYN,!ACK packets, and if both sides do that, the connection is never getting established.
In my experience most consumer routers are dumber than you're assuming they are, and will DNAT any inbound TCP packet that matches the 4-tuple after seeing the initial outbound SYN, including an inbound SYN. But yes, it doesn't work everywhere.
I wrote little paper on this technique in school and did some practical tests, at the time I was actually unable to find an example of consumer grade router that it didn't work on! But my resources were rather limited, they certainly do exist.
It's not uncommon with routable internal networks to only drop inbound SYN,!ACK to disallow inbound connections while permitting outbound ones, since it doesn't require connection tracking (which can be resource intensive).
I can't really imagine why you would do it for NAT'd v4 since you can't avoid the connection tracking overhead, but you certainly could, and I don't doubt OP has run into it in the wild. I've seen much weirder firewall rules :)
What are the obvious reasons? If you're protecting a client system, you don't want to allow in any bare SYNs. (And for that matter, if you're protecting a server, you probably want to discard ill-targeted bare SYNs without consulting conntrack anyway, just as a matter of avoiding extra CPU work.)
Does this mean by establishing a new connection with a SYN,ACK bypasses some firewalls? I expect at least one OS out there ignores the extraneous ACK flag and proceeds to establish a new connection.
All inbound packets are matched against existing sessions. In this case none will turn up, so the packet will go through the "new session" flow and be subject to the same filtering as a bare SYN. Look up how connection tracking works, e.g. in the Linux kernel, it's rather simple and logical.
Yeah but nobody else has as many a FreeBSD developers on staff to fix stuff when it breaks. Or, you know, to run monthly stabilization weeks and extensively QA before deploying to a herd of cattle.
There are so many factors in favour of Netflix running 16.0 which don't apply elsewhere.
14.4 is a maintenance release. If you're installing FreeBSD today, use 15.0
This is not the recommendation of the FreeBSD project. (I would know, because I'm the person in the project who makes that recommendation where appropriate.)
Once X.1-RELEASE ships, (X-1).* is considered "legacy" and we recommend that it is used primarily for maintaining existing systems and that new systems are deployed with the newer major version. But at when it comes to 14.4 vs 15.0 we're not there yet; .0 releases are always a bit bumpy and it's very much a judgement call at this point about how much risk people want to take.
By the way - does 32bit packages 'problem' for WINE has been resolved on 15.x series?
On 14.x and older versions WINE brings `/usr/local/share/wine/pkg32.sh` to keep 32bit packages for WINE32 ... but 15.x does not build 32bit packages anymore ...
Writing the release announcement for FreeBSD 14.4! The release is ready (aside from propagating to mirrors and clouds) but I have until 2026-03-10 00:00 UTC to get the announcement email ready to go out.
Yeah, I would definitely characterize it as an instruction following problem. After a few more round trips I got it to admit that "my earlier passes leaned heavily on build/tests + targeted reads, which can miss many “deep” bugs that only show up under specific conditions or with careful semantic review" and then asking it to "Please do a careful semantic review of files, one by one." started it on actually reviewing code.
Mind you, the bugs it reported were mostly bogus. But at least I was eventually able to convince it to try.
In the same vein, algebraic irrationals (e.g., √2) all have an irrationality measure of two, but the proof of this is fiendishly difficult and netted its discoverer the Fields Medal back in 1958.
It's worth noting that this is a standard method of proving that a value is transcendental -- just show that it has better rational approximations than any algebraic number can have.
It's a standard way of proving that transcendental numbers exist, because it's easy to construct very well-approximable numbers, but so far as I know it isn't a common way to prove that a number you were already interested in is transcendental. For pretty much every number you might be interested in, the best-known lower bound on that exponent is 2, which of course isn't good enough to prove transcendence.
At least, that's my understanding of where things stand, but I'm not an expert. Do you have counterexamples?
The Champernowne numbers were already known to be irrational, but this makes the proof much easier!
(But to clarify: When I said "proving that a value is transcendental", I was thinking of numbers specifically constructed for that purpose, not of other numbers more generally. 100% of transcendental numbers have irrationally measure 2.)
Related: In FreeBSD we used to talk often about the Wemm Field. Peter Wemm was one of the early FreeBSD developers and responsible for most of the early project server cluster, and hardware had a phenomenal habit of breaking in his vicinity. One notable story I heard involved transporting servers between data centers and hitting a Christmas tree in the middle of a highway... in March.
reply