vitus

> The merchants think so, too, or they wouldn’t accept the processors that let their banks hand out these cards.

Visa / Mastercard / American Express all have lines of premium credit cards (Visa Infinite, World Elite Mastercard, Amex Platinum), and they're very much too big to ban. You'd just be left with one processor in the US (Discover, now owned by Capital One).

IIRC the block was on archive.today's side as a protest against 1.1.1.1 intentionally not supporting ECS.

https://news.ycombinator.com/item?id=36971650

https://news.ycombinator.com/item?id=19828702

Best I can tell, it's originally from Heguanzi: https://ctext.org/he-guan-zi/shi-xian

I have evidence that it's not AI. It's just a regex.

https://github.com/elijah-potter/blog/blob/master/pages/hnsa...

Shockley? The guy whose employees hated him so much they went and founded a rival company which then gave rise to Silicon Valley?

https://en.wikipedia.org/wiki/Traitorous_eight

Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.

If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.

We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.

Agreed. That said, FDIC would have not been able to cover all $150 billion or so of uninsured SVB deposits directly from the insurance fund, so had that been the only available option for making depositors whole, then FDIC would have had to pass.

Indeed; most personal banking customers can fall back on FDIC insurance ($250k should be more than enough to cover your emergency fund). This isn't the 1920s.

> I didn’t know about the term happy eyeball to signify that all requests fire at the same time.

It's not quite the same. Usually with Happy Eyeballs, you want to try multiple protocols (e.g. QUIC vs TCP, or IPv6 vs IPv4), and you have a preference for one over the other. As such, you try to establish your connection via IPv6, wait something like 30ms, then try to establish via IPv4. Whichever mechanism completes channel setup first wins, and you can cancel the other one.

It's a mechanism used to drive adoption of newer protocols while limiting the impact on end users.

> magic eyeballs

https://en.wikipedia.org/wiki/Happy_Eyeballs is the usual name. It's not quite identical, since you often want to give your preferred transport a nominal headstart so it usually succeeds. But yes, there are some similarities -- you race during connection setup so that you don't have to wait for a connection timeout (on the order of seconds) if the preferred mechanism doesn't work for some reason.

The main term I've seen for this particular approach is "request hedging" (https://grpc.io/docs/guides/request-hedging/, which links to the paper by Dean and Barroso).

This is approximately the section in the video titled "Memory controllers hate you" (https://www.youtube.com/watch?v=KKbgulTp3FE&t=1399s), combined with the following section.

The actual explanation starts a couple minutes later, around https://youtu.be/KKbgulTp3FE?t=1553. The short explanation is performance (essentially load balancing against multiple RAM banks for large sequential RAM accesses), combined with a security-via-obscurity layer of defense against rowhammer.

Eh. It depends what your bottleneck is. If the bottleneck is now, say, CPU cache contention because you've doubled your thread count, it's entirely possible that FL1 running on the new server generation is operating in a different regime than on the previous generation. You can see some hints of that happening, since doubling thread count didn't result in a doubling of throughput.

In fact, I suspect based on the throughput doubling with FL2, we're back in the same regime as the baseline.

It would be useful to see what the latency is of FL2 on Gen12 compared to baseline (FL1 on Gen12), just to confirm.

It depends what dates you're looking at, but energy (gas prices and more) and food (including eggs) are generally recognized as way more volatile than the rest of the CPI.

Eggs were actually quite stable for the 20 years prior to 2001, so maybe don't put your life savings into egg futures...

Egg prices: https://fred.stlouisfed.org/series/APU0000708111

CPI: https://fred.stlouisfed.org/series/CPIAUCSL

Core CPI (without food + energy prices): https://fred.stlouisfed.org/series/CPILFESL

> Kaeshibashi

The preference is to use a separate pair of communal chopsticks that is not used directly for eating.

> Kosuribashi

I have heard that this one is because it's considered to be an insult implying that the chopsticks are low-quality. (That said, if your chopsticks are indeed low-quality, then avoiding splinters is probably preferable to then visibly plucking splinters out of your fingers.)

Agreed on all those fronts. I'm just dismayed by all the comments suggesting that maintainers just merged PRs with this trojan, when the attack vector implies a more mundane form of credential compromise (and not, as the article implies, AI being used to sneak malicious changes past code review at scale).

Looks like the repo owner force-pushed a bad commit to replace an existing one. But then, why not forge it to maintain the existing timestamp + author, e.g. via `git commit --amend -C df8c18`?

Innocuous PR (but do note the line about "pedronauck pushed a commit that referenced this pull request last week"): https://github.com/pedronauck/reworm/pull/28

Original commit: https://github.com/pedronauck/reworm/commit/df8c18

Amended commit: https://github.com/pedronauck/reworm/commit/d50cd8

Either way, pretty clear sign that the owner's creds (and possibly an entire machine) are compromised.

> if indeed he went all-in on AI in 2015, that seems to me like a damn near prophetic vision.

Also note that 7 years later, when ChatGPT came out, built on top of Google Brain research (transformers), Google was caught flat-footed.

Even supposing that Pichai really had the right vision a decade ago, he completely failed in leading its execution until a serious threat to the company's core business model materialized.

> That’s PCIe 3.0 x4 or PCIe 4.0 x2, which a decent commodity M.2 NVMe SSD can use and can possibly saturate, at least for reads.

Given that there's a separate item for sequential disk reads vs SSD reads, I think it's pretty clear that particular item meant hard drives specifically. Agreed that modern SSDs should be able to pull that off.

> That being said, all the connections over 100Gbps are currently multi-lane AFAIK, and the heroic efforts and multiplexing needed to exceed 100Gbps at any distance are a bit in excess of the very simple technology that got us to 100Mbps “fast Ethernet”.

Yeah. Terabit networking is not here yet, and it's certainly not "commodity network"-grade. We can LACP a bunch of 100G optics together, but we're probably 5-10 years out for 800G ethernet to become widely adopted and for 1600G to even be developed.

Well, it shouldn't be slower than "Read 1,000,000 bytes sequentially from memory" (741ns) which in turn shouldn't be slower than "Read 1,000,000 bytes sequentially from disk" (359 us).

That said, all those numbers feel a bit off by 1.5-2 orders of magnitude -- that disk read speed translates to about 3 GB/s which is well outside the range of what HDDs can achieve.

https://brenocon.com/dean_perf.html indicates the original set of numbers were more like 10us, 250us, and 30ms.

And it links to https://github.com/colin-scott/interactive_latencies which seems like it extrapolates progress from 14 years ago:

        // NIC bandwidth doubles every 2 years
        // [source: http://ampcamp.berkeley.edu/wp-content/uploads/2012/06/Ion-stoica-amp-camp-21012-warehouse-scale-computing-intro-final.pdf]
        // TODO: should really be a step function
        // 1Gb/s = 125MB/s = 125*10^6 B/s in 2003

which means that in 2026 we'll have seen 11 doublings since gigabit speeds in 2003, so we'll all have > terabit speeds available to us.

You probably meant to say oversubscribing, not overprovisioning.

Oversubscription is expected to a certain degree (this is fundamentally the same concept as "statistical multiplexing"). But even oversubscription in itself is not guaranteed to result in bufferbloat -- appropriate traffic shaping (especially to "encourage" congestion control algorithms to back off sooner) can mitigate a lot of those issues. And, it can be hard to differentiate between bufferbloat at the last mile vs within the ISP's backbone.

We do; most people don't just write eBPF by hand.

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

std::ignore's behavior outside of use with std::tie is not specified in any finalized standard.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29... aims to address that, but that won't be included until C++26 (which also includes _ as a sibling commenter mentions).

> This is incorrect, the correct strategy is mostly to check the most probable match (the exception being if the people in that match has less possible pairings remaining than the next most probable match).

Do you have any hard evidence, or just basing this on vibes? Because your proposed strategy is emphatically not how you maximize information gain.

Scaling up the problem to larger sizes, is it worth explicitly spending an action to confirm a match that has 99% probability? Is it worth it to (most likely) eliminate 1% of the space of outcomes (by probability)? Or would you rather halve your space?

This isn't purely hypothetical, either. The match-ups skew your probabilities such that your individual outcomes cease to be equally probable, so just looking at raw cardinalities is insufficient.

If you have a single match out of 10 pairings, and you've ruled out 8 of them directly, then if you target one of the two remaining pairs, you nominally have a 50/50 chance of getting a match (or no match!).

Meanwhile, you could have another match-up where you got 6 out of 10 pairings, and you've ruled out 2 of them (thus you have 8 remaining pairs to check, 6 of which are definitely matches). Do you spend your truth booth on the 50/50 shot (which actually will always reveal a match), or the 75/25 shot?

(I can construct examples where you have a 50/50 shot but without the guarantee on whether you reveal a match. Your information gain will still be the same.)

So, for 10 pairs, 45 guesses (9 + 8 + 7 + 6 + 5 + 4 + 3 + 2 + 1) in the worst case, and roughly half that on average?

It's interesting how close 22.5 is to the 21.8 bits of entropy for 10!, and that has me wondering how often you would win if you followed this strategy with 18 truth booths followed by one match up (to maintain the same total number of queries).

Simulation suggests about 24% chance of winning with that strategy, with 100k samples. (I simplified each run to "shuffle [0..n), find index of 0".)

It should be easier to understand the optimal truth booth strategy. Since this is a yes/no type of question, the maximum entropy is 1 bit, as noted by yourself and others. As such, you want to pick a pair where the odds are as close to 50/50 as possible.

> Employing that approach alone performed worse than the contestants did in real life, so didn't think it was worth mentioning!

Yeah, this alone should not be sufficient. At the extreme of getting a score of 0, you also need the constraint that you're not repeating known-bad pairs. The same applies for pairs ruled out (or in!) from truth booths.

Further, if your score goes down, you need to use that as a signal that one (or more) of the pairs you swapped out was actually correct, and you need to cycle those back in.

I don't know what a human approximation of the entropy-minimization approach looks like in full. Good luck!

It's way more lopsided than your example would suggest.

My understanding is that Netflix can stream 100 Gbps from a 100W server footprint (slide 17 of [0]). Even if you assume every stream is 4k and uses 25 Mbps, that's still thousands of streams. I would guess that the bulk of the power consumption from streaming video is probably from the end-user devices -- a backbone router might consume a couple of kilowatts of power, but it's also moving terabits of traffic.

[0] https://people.freebsd.org/~gallatin/talks/OpenFest2023.pdf

To add to this: rough consensus is defined in BCP 25 / RFC 2418 (https://datatracker.ietf.org/doc/html/rfc2418#section-3.3):

   IETF consensus does not require that all participants agree although
   this is, of course, preferred.  In general, the dominant view of the
   working group shall prevail.  (However, it must be noted that
   "dominance" is not to be determined on the basis of volume or
   persistence, but rather a more general sense of agreement.) Consensus
   can be determined by a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.

The goal has never been 100%, but it is not enough to merely have a majority opinion.

I get that it's satisfying to tell them to go away because they're being unreasonable. But what's the legal strategy here? Piss off the regulators such that they really won't drop this case, and give them fodder to be able to paint the lawyer and his client as uncooperative?

Is the strategy really just "get new federal laws passed so UK can't shove these regulations down our throats"? Is that going to happen on a timeline that makes sense for this specific case?

The combative stance that he's taking really doesn't do him any favors in resolving the issue.

Lawyer: "I've confirmed that at least one UK IP address is blocked."

Regulators: "We've confirmed that at least one UK IP address is not blocked."

In what world is the correct response "Dear regulators, you're incompetent. Pound sand." instead of "Can you share the IP address you used so my client can address this in their geoblock?"

China is much more smartphone-centric than the US. QR codes are universal, WeChat and AliPay are the most common form of payments (online or in person).