Looking at the site it seems to be a (static?) HTML and shared "main.css" and "main.js" files. Both files can be cached by the browser, so it only needs to download a few KB of compressed HTML for each page. I don't think we would notice much of a difference in the navigation from one page to another if they used content preloading
It's how we used to make websites before SPA, and it's refreshing to see that it still makes a noticeable difference even on today's powerful CPUs and high speed networks.
What if FTL is not possible? In that case the attack will take a long time to reach us, and in the meantime we will be much more advanced technologically and could potentially defend ourselves.
In sci-fi we see warp drives, worm hole travel, phasers, photon torpedos and energy shields around ships. But what if none of that is possible? In that case, we might even have the technology to defend ourselves today if we manage to detect the attack in time.
It's a huge risk for a civilization to attack us. Even if they have capabilities that are beyond our technology, there might still be limitations based on the laws of physics. And if they attack us, they risk a response.
Originally, the "o" on top of the letter "Å" was a lower case "a", because the sound could be written as "AA". Over time it transformed into a circle.
Some names today still use the double a, like the Norwegian football player Martin Ødegaard. In that case it is pronounced the same as the "å" sound. (not too far from how an American might pronounce the "o" sound in "for")
> The Ship of Theseus, also known as Theseus's Paradox, is a paradox and a common thought experiment about whether an object is the same object after having all of its original components replaced over time, typically one after the other.
> The client then searches through the list to see if the desired email is in the list or not.
The initial prefix check would probably reduce the amount of lookups necessary, as it would only be necessary to do a deeper search if the prefix matches.
>only be necessary to do a deeper search if the prefix matches
There are 5 billion emails in at least 1 breach and 16 million prefixes. Almost all if not all prefixes have at least 1 email in a breach. So almost all prefixes match. I don't see why it's useful to spend a bunch of effort optimizing the very rare case of a prefix not matching.
Now, if the bloom filter checked emails instead of checking prefixes, that would be useful. However, a bloom filter of 5B elements with a 10% false positive rate would be 2.8 GB, which is prohibitively large.
Yeah that was my point, you can get rid of a significant portion of requests at the edge with a bloom filter, and there's no reason you have to build the bloom filter locally as requests come in. Instead, it can be created ahead of time, when the dataset is updated.
Also regarding "you can get rid of a significant portion of requests at the edge with a bloom filter", Troy's existing design already gets rid of a significant portion of requests at the edge. That's why he says
>The response from each search was coming back so quickly that the user wasn’t sure if it was legitimately checking subsequent addresses they entered or if there was a glitch.
It is my recollection as well. Most applications used VB, Delphi, MFC etc. that all had the "native" OS look and feel. There were some exceptions like WinAmp and others, but from what I can remember most applications were more consistent than today.
Those toolkits would usually reimplement the "native" look and feel from scratch, or nearly so. It was uncommon to rely directly on the basic OS widgets.
MFC was Microsoft, so that was definitely native, and I think a lot of stuff used native even just for performance reasons. I remember getting very frustrated around then when something would want me to install the JVM and I knew I was in for a laggy mess of an application that would have bad font rendering, strange little buttons, and its own file picker.
Don't modern versions of Windows contain at least 5 different widget frameworks? Like, Win32, Ribbon (I think engineered for Office as you said), WinForms, WPF, WinUI 1/2/3... I think Apple just has Cocoa (Carbon is long gone), AppKit, UIKit, and SwiftUI.
MFC is a thin wrapper around Win32. Delphi's VCL is a much thicker wrapper but still using (mostly) native widgets; ditto for VB6.
So, no, it was quite the opposite - it was uncommon to not rely directly on the basic OS widgets. Off the top of my head, the two toolkits that I remember that didn't do that were Borland's OWL (which quickly died out in post-Win16 era, since Delphi/VCL was strictly better), and Qt, which while not using native widgets tried to approximate that look and feel as much as possible.
Even in Java land, their first take - AWT - wrapped native widgets. It wasn't until Swing that they moved on to rendering their own, and it was widely derided as looking inconsistent with other apps as a result of that.
My guess is that he wants to be compensated for the time he spent. There's a lot of content on that site, and making a bit of money is a good motivation to keep updating the site
It's how we used to make websites before SPA, and it's refreshing to see that it still makes a noticeable difference even on today's powerful CPUs and high speed networks.