fanf2

As well as NIST there is Schriever spave force base https://en.m.wikipedia.org/wiki/Schriever_Space_Force_Base which is the ground operations centre for GPS. They have the USNO alternate master clock, which maintains a copy of the USNO time scale based on caesium beam and rubidium fountain clocks.

Sadly the cache files don’t record enough about the environment to be usable if you change configure options. They are generally unreliable.

The NASA page does not make the false equal time assumption.

You are thinking of John Meacham’s winning entry in the 2008 underhanded C contest https://www.underhanded-c.org/_page_id_17.html

Portable clocks are not better than static caesium clocks, and optical clocks which are better than caesium clocks are not portable.

Also very good is “The Scariest Library” https://www.exurbe.com/the-scariest-library/

I hate to helk, it’s a G-noo. https://youtu.be/j53z6RfFb7U

The incorrect results are far more important than the times!

Cloudflare provides free hosting to booters and stressers.

The article is deeply confused.

It’s true that optical clocks will improve the accuracy of our measurement of time, and it’s true that GPS depends on time, but there are several steps between primary frequency standards (ie, optical clocks) and GPS, and several more steps between GPS and navigation applications.

So optical clocks cannot, in fact, have any effect on the end-user perceived reliability of GPS.

For that, the best solution is to revive LORAN which is much less susceptible to jamming. (And would also benefit from better atomic clocks.)

Lemire’s algorithm rejects the fewest possible samples from the random number generator, so it’s generally the fastest. The multiplication costs very little compared to the RNG.

What do you mean by “regular” rejection sampling?

Fastrange is slightly biased because, as Steve Canon observes in that Swift PR, it is just Knuth’s multiplicative reduction. The point of this post is that it’s possible to simplify Lemire’s nearly-divisionless debiasing when the limit is known at compile time.

I previously experimented with really-divisionless debiasing but I was underwhelmed with the results https://dotat.at/@/2022-04-20-really-divisionless.html

I can zoom out.

I prefer zooming for reading code. Horizontal scrolling divs are horrible.

You don’t need continuations to implement resumable errors. The trick is simply to not unwind the stack when an error happens.

http://axisofeval.blogspot.com/2011/04/whats-condition-syste...

They repeat roughly every year. 1,000,000 periods of 30 seconds is just less than 350 days.

Build systems often make it a huge pain to get the right rpath. The chrpath tool makes it easy to fix the rpath after libtool got it wrong.

This is right next to Leadenhall Market, which dates from the 14th century. I wonder if there were other markets on the same-ish site between the Roman forum and Leadenhall.

You can get Marcin Wichary’s version from https://shifthappens.site/store/

Routed Gothic is a fairly good free version https://webonastick.com/fonts/routed-gothic/

The national park typeface is another pantograph router style font https://nationalparktypeface.com/

Oh yes, also => Lar => Larkin, Larkins

The author and editor should be ashamed for leaving out O’Neill from the title.

But that’s likely to be very unsafe, especially in a multithreaded program, or if it relies on stack unwinding for RAII.

Yeah if you chdir() in a multithreaded program, all cwd-relative file accesses in other threads are fucked.

As well as absolute paths, it’s ok to work with descriptor-relative paths using openat() and friends.

^ for start of line predates the ADM3a

ASCII 1963 was the first version of the standard and it had ← https://dl.acm.org/doi/10.1145/366707.367524

The 1965 draft had _ instead https://dl.acm.org/doi/10.1145/363831.363839

The first standard edition with _ was 1968 https://www.rfc-editor.org/info/rfc20

The 1977 version is also available https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub1-2-197...

Xerox PARC used ASCII 1963 (for reasons I have yet to unearth) so its programming languages Mesa and SmallTalk used ← for assignment and camelCase to separate words in identifiers. This stylistic quirk was carried over to later object-oriented programming languages.

WRT modern tooling, I was thinking more in terms of languages like Haskell that don’t constrain the order of presentation so much, or tools like rustdoc that embrace hypertext and allow the reader to choose their own adventure.

There are at least two aspects to literate programming.

Knuth wrote TeX in Pascal, which has a couple of limitations that annoyed him:

- Pascal has no module system: you can’t break a program up into multiple files

- The order of presentation of a program is dictated by the needs of a single-pass compiler

The tooling that supports literate programming is mostly about overcoming these problems with Pascal. (Knuth also uses it to split up larger procedures in a manner that makes me think of very un-structured C macros.) Most other languages are more flexible so they have much less need for a technology like tangle/weave.

The opposite extreme is Literate Haskell, which doesn’t need any preprocessor. You just feed your TeX document to ghc and it picks the code out of the \begin{code} blocks. Or instead of Knuth style you can write in Bird style, where the file is a plain text document with code marked by > quote blocks.

The other aspect of literate programming is organizing the code like a book. This is very difficult to do well. When I think of how I approach a codebase, it reminds me of textbooks that have a complicated diagram describing multiple suggested orders of reading (a chapter per module?), or the informal introduction to Algol 68 with its orthogonal table of contents. Ideally a program’s commentary should span both the explanatory and reference documentation quadrants.

What strikes me about Knuth’s literate programming is how hypertextual it is, albeit using printed cross-references and indexes. It seems to be in desperate need of interactive pixels. And an underlying programming language that has better support for Knuth’s preferred size of code fragment.

On balance I think modern tools achieve Knuth’s goals better than tangle/weave. Modern languages let you organize code much closer to its narrative structure, without WEB’s unhygienic scoping. Editors and IDEs and documentation browsers give you hyperlinks everywhere.

It’s then “just” a matter of writing the exposition. Less literate programming, more literate programmer.

Not as far as I know.

The cosine adjustment that Google originally used is not the best: NTP aims to measure the difference in rate between the client’s hardware clock and real time, and it works best if the rates are fairly constant. With the cosine smear, the rate changes continuously! If you use a simple linear smear, NTP just has to cope with two small rate changes at the start and end of the smear.

The smear needs to be slow enough that NTP’s algorithms have time to react without overshooting; 24 hours is a reasonable choice tho you can go a bit faster. There’s some disagreement about when the smear occurs relative to the leap second; if the leap is in the middle of the smear the max offset is 0.5 seconds, but if the leap is at the end of the smear the offset is always slow. They were able to test the up-to-one-second-slow scenario in a system-wide live trial, whereas they could not do the same for the sign flip. I think if you can cope with a 0.5 second offset from real time then a 1.0 second offset should not be much more troublesome.

Original ARM (ARM1 and ARM2) were cacheless; ARM3 was the first with a cache.

The CPU’s 26 bit address space was split into virtually mapped RAM in the bottom half, and the machine’s physical addresses in the top half. The physical address space had the RAM in the lowest addresses, with other stuff such as ROMs, memory-mapped IO, etc. higher up. The virtual memory hardware was pretty limited: it could not map a page more than once. But you could see both the virtually mapped and physically addressed versions of the same page.

RISC OS used this by placing the video memory in the lowest physical addresses in RAM, and also mapping it into the highest virtual addresses, so there were two copies of video memory next to each other in the middle of the 26 bit address space. The video hardware accessed memory using the same address space as the CPU, so it could do fast full-screen scrolling by adjusting the start address, using exactly the same trick as in the article.