"If I asked you to calculate the inverse square root of 26 without a calculator, you’d probably be stuck for a while—and honestly, so would I."

Um, 5*2 is 25 and 6*2 is 36 so we know the square root of 26 is between thos two and likely a lot closer to 5.1.

And 1/5 = 0.2. The correct answer is .196 plus a few irrelevant digits.

A lot of the credit goes to Laura Waller, a professor at UC Berkeley who has been really innovative in this area and trains a bunch of really smart students. She has a great Optics Fun page, https://www.laurawaller.com/optics-fun/

Although, IIUC, Cerebras expects some amount of imperfection and can adjust the hardware (or maybe the software) to avoid those components after they're detected. https://www.cerebras.ai/blog/100x-defect-tolerance-how-cereb...

Managers and security team at google do not have access to your personal phone's data. A number of things in this article simply do not match my previous experience there. This has nothing to do with Epstein at all.

You weren't in the know then. But it's encouraging to know that this is not widespread.

I think all the TinyMUDs I used (CMU and whatever the one in OK was), listened on nonstandard ports.

I had to use a VMS system which had different telnet behavior (staircasing due to CR/LF mismatch) and originally used a locally developed client (TINT mentioned here https://www.linnaean.org/~lpb/muddex/clients.html) then learned C to write a subsequent client (DINK) which supported macros and "portals"- an early way to transit across different MUDs. A few years ago I learned that DINK was forked and improved- my early C code was awfully bad. It's still bad, but it was awfully bad then.

The one funny bit is that I copied TINT's exit command (Control-Y) instead of using /quit which led to several years of email complaints form folks who couldn't exit the mud (in those days, you usually just had one terminal connection, and if you couldn't exit a program, you had to forcibly disconnect the modem).

There's one thing I haven't figured out with netcat- how do you know it connected? (I just looked it up, after many years: the -v flag. Which makes sense because netcat is supposed to be "transparent").

Good stuff- I had to learn most of this on my own.

Pro-tip: most of what you describe and document is already built into Qt, in the Graphics View Framework. It handles all the gunk around coordinate systems, canvas, zoom, scrollbars, and scaling, along with item groups, hit testing, multiple views of the same model, and extensive performance optimizations.

I have recently used Gemini to write an entire 2D CAD system based on this and it worked pretty well (I've already written one by hand).

Much of this stems from Google's original design for its search engine, and borg. Borg was not a batch scheduler, it was a service-keeper-upper with loose relationships between individual containers. Google's design was never friendly to MPI-style jobs (which long ago tended to be highly synchronous, with distributed processes that were extremely long-lived, and servers did not just "come and go").

There are a number of properties of SLURM and other batch systems that are far more convenient for users. Typically a SLURM system will have a large distributed filesystem that can be accessed from all the nodes using normal UNIX commands (GFS and Colossus aren't mountable filesystems and the UNIX tools do not really work against them natively). Reading output logs is often much easier (tail -f, less, etc) but the cost of the filesystem (per byte) goes up exponentially as the number of nodes increases.

I have extensive experience with both systems. My experience with SLURM is that the system is highly predictable, slowly changing, and I can get my work done. Whereas on Google systems, everything was breaking constantly and I had to focus on making my systems resilient to noise. On the other hand, the Google system scaled far larger, for cheaper.

When I joined Google I asked Jeff Dean how page rank was computed and he said it was an iterative mapreduce- I was assuming it was some sort of tightly coupled supercomputer-style job, but for the size of the web, and the link structure, MR made much more sense.

I didn't learn about this trick (deconvolution) until grad school and even then it seemed like spooky mystery to me.

MUDs were my introduction to telnet- I grew up a university kid and had access to Wesleyan's minicomputer EAGLE.WESLEYAN.EDU running OpenVMS. I used it to telnet to CMU's TinyMUD and later other TinyMUDs around the country. I recall OpenVMS's telnet had a problem with newlines/carriage returns so all the text was staircased, so I ended up learning C and writing a MUD client. I still habitually use telnet today even if netcat and many other tools have replaced it.

All of that was foundational for my career and I still look back fondly on the technology of the time, which tended to be fairly "open" to exploration by curious-minded teenagers.

For a few weeks I ran a MUD over AX.25 for a couple of my friends.

Because on their own, MUDs aren't nerdy enough, amateur radio isn't nerdy enough, and indeed packet radio isn't nerdy enough.

Eventually we decided we'd had our fun and now I needed to the TNC for something else.

Ah, my grandfather was a ham (N4MDB) and he always tried to get me interested in it, but I had to tell him I preferred the internet (this was late 80's, so few people actually had internet). Later when I read Stevens networking books I learned there was a whole Hawaii-based packet radio (ALOHAnet) , and the UC campuses had intercampus microwave networking for a while as well. I actually still remember him telling me about bouncing radio waves off the atmosphere which seemed like magic to me at the time.