As a newsletter company, we've dealt with this for over a decade now since we do the right thing and do double opt-in which involves sending the subscriber an email on signup.
Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs, so many legitimate users appear to come from low reputation IPs.
Turnstile is a reasonable solution in its normal form, though the 'invisible' option still lets a lot of them through. Another thing that works, surprisingly, is looking for "webdriver" usage. Despite being easy to strip out webdriver fingerprints, we find that the majority of automated attempts do not bother to do this. Adding more steps, honeypots (with an immediate short term IP ban), etc. also have an impact. It becomes a game of piling up numerous defences in a sort of "Swiss cheese model".
That's a fun cobra effect. Age verification ("intended" to make children safer online, if you take the most charitable view) forces more and more people to use VPNs, which overall degrades the value of IP reputation as a signal, forcing providers to accept less reputable IPs because real customers come from them, which means that providers are more vulnerable to attacks that can be used to target children.
The point isn't protection from attacks that target children, it's gatekeeping content to keep it away from children. Providers are more vulnerable to attacks, overall, because of that gatekeeping, because of ht inevitable use of tools like VPNs and proxies to bypass the mechanisms being used. This sort of anti-anonymity is specifically and precisely targeted at decreasing the security of individuals, subjecting them to surveillance and control by the state. It has nothing to do with "protecting the children" and never did.
The four horsemen of the infocalypse are always about power grabs, they're never about actually protecting citizens, or children, or securing a country or region.
We also believe that, generally, the community have been indicating that, by and large, they aren't interested in this content.
How can that be true? Reddit is vote-based. So if people weren't interested, they wouldn't vote it up and it wouldn't appear on the front page. Hacker News has no rule banning posts about Barbie and yet, amazingly, Barbie rarely makes it to the front page, because that's how upvotes work.
People clearly are interested enough to vote LLM related posts up, but a bunch of mods who don't like AI are upset enough to want to dictate what others can find interesting. Which is not unusual for Reddit.
Unlike Hacker News, Reddit's new Best algorithm often surfaces newly posted post (which is a good idea that help mitigate the cold start problem), but that means people who are subscribed to /r/programming will see posts about LLMs and typically downvote them.
From the user responses to the linked ban, said ban was a positive decision for that community.
TruffleRuby is very capable and deserves to be promoted more. I recently made a JPEG encoder/decoder in Ruby and it's 2-3x times quicker on Truffle. Native dependencies is where you can get caught out, but for pure Ruby, TruffleRuby is fantastic and worth including in your test matrix. (More broadly I think Ruby performance is reaching a point where we should be spinning up pure Ruby alternatives to native libraries, but that's a story for another day.)
I'd imagine you don't want to look like you're self-promoting, but I'd really love to read more about the JPEG project. I think it could be quite good for the community. As a whole, I believe Rubyists need to stop reaching for native extensions so quickly. Whether on YJIT, ZJIT, JRuby, or TruffleRuby, all of them will benefit from having more code in Ruby. Incidentally, Chris's final conference talk¹ made the case for moving to a Ruby-based implementation for the Ruby core library.
For those cases where you're writing a native extension to primary bridge over to a native library, you may find either FFI or Fiddle handle your use case quite well.
It's at https://github.com/peterc/pure_jpeg .. and a lot of the recent speedups actually came from contributions by Ufuk/paracycle who, I'm guessing from your bio, you possibly work with? :-)
But yeah, I agree with your point about native extensions. Ruby has gotten so much faster in every form in the past couple of years that I think we could bring a lot more "in house". I think there have been some efforts with this regarding Psych in core as well?
I'm surprised it's only 2-3x times quicker w/Truffle? Is that because it only encodes/decodes a single image at the time and incurs higher startup costs? Or do you mean 2-3x vs. an MRI alternative that calls into a native extension?
I'm curious whether this reflects MRI's improvements closing some of the gap or something else.
I've not got the numbers to hand between versions, but YJIT in Ruby 4.0 did shift the needle a bit, so yes, some gap closing. I also forget what the warmup was like, but to get 2-3x somewhat more was needed than with YJIT.
(Both running identical pure Ruby code, no extensions, in a long-running test scenario, no setup each time.)
That is broadly my experience with pure Ruby, yes. In terms of C extensions, I know they were doing some work on this but it was a WIP last time I looked, although maybe I should refresh my knowledge on this if it's now all good to go!
Many native extensions just work with TruffleRuby, I'd estimate even the majority of the popular native extensions just work.
Performance of native extensions is not always good, especially if they do a lot of back and forth between Ruby and native.
That's awesome news, and I can't get a more authoritative source than you! I'll do some tests and update my assumptions :-) I really do wish I saw more blog posts and things about TruffleRuby, but maybe that is just a sign I should make the effort myself.
Since I have you, if you could humor me at all, what do you think the biggest current sticking point to average Rubyists just flat out switching to TruffleRuby is nowadays? Or isn't there one?
Quite, I threw a so-so photo of an old, long receipt at Qwen 3.5 0.8MB (runs in <2GB) and it nailed spitting 20+ items out in under a second. AI is good at many things, but picking modern dependencies not so much.
Upon seeing the entry for Marie-Antoinette’s private theater, I felt an urge to proclaim the Amargosa Opera House as Death Valley's "Mona Lisa". I was lucky enough to get a private tour and it was like stepping into one of the world's greatest works of art in the most bizarre of locations. The pictures don't do it justice but https://lenspire.zeiss.com/photo/en/article/mario-basner-cap...
I think the (OP) article has screwed up here. The article, and I think its original source, name a particular set from the theater as the palace's Mona Lisa. But the article has a picture of the theater itself, and even misnames the theater after the set.
Tatler source: "This includes machinery that causes a tree to rise from a trapdoor and three sets – a simple interior, a forest and a temple of Minerva – the latter being the oldest intact decor in the world, dating back to 1754 – ‘our own Mona Lisa,’ said Masson."
OP article: "What is it? The Temple of Minerva theater set (c.1754) from Marie-Antoinette’s private theater."
OP caption on picture of theater: "Temple of Minerva theater (c. 1754)"
I feel some "commoditize your complements" (Spolsky) vibes hearing about these acquisitions. Or, potentially, "control your complements"?
If you find your popular, expensive tool leans heavily upon third party tools, it doesn't seem a crazy idea to purchase them for peanuts (compared to your overall worth) to both optimize your tool to use them better and, maybe, reduce the efficacy of how your competitors use them (like changing the API over time, controlling the feature roadmap, etc.) Or maybe I'm being paranoid :-)
Not allowing AI assistance on PRs will likely decimate the project in the future,
I can't help but wonder if this matter could result in an io.js-like fork, splitting Node into two safe-but-slow-moving and AI-all-the-things worlds. It would be historically interesting as the GP poster was, I seem to recall, the initial creator of the io.js fork.
Context is important, but isn’t HN’s social context, in particular, that the site is entirely public, easily crawled through its API (which apparently has next to no rate limits) and/or Algolial, and has been archived and mirrored in numerous places for years already?
I don’t know how their behavior differs but I live in a country with patchy mobile coverage and Spotify and Apple Music are night and day with how they cope with this. Spotify is far more robust and I assume prefetches more aggressively.
I've been working on a pure Ruby JPEG encoder and a bug led me to an effect I wanted. The output looked just like the "crunchy" JPEGs my 2000-era Kodak digital camera used to put out, but it turns out the encoder wasn't following the zig-zag pattern properly but just going in raster order. I'm now on a quest to figure out if some early digital cameras had similar encoding bugs because their JPEG output was often horrendous compared to what you'd expect for the filesize.
The interesting thing about the situation I mentioned is that while the encoding algorithm was wrong, the actual output was valid JPEG that simply didn't look quite visually correct. But you're right, invalid encoding can be a problem too, and I have noticed during testing that a lot of decoders are quite forgiving of it.
Ah yeah that is an interesting case. In my situation, a thermal camera I got was inserting an invalid frame at the start which likely got used by their proprietary program to store data. VLC would view it but most of Mac/iOS would refuse to play the video until I used ffmpeg to delete the invalid frame.
Yes. The size is slightly different here to show it off better, but compare left and right in https://peterc.org/misc/queen.png (both are the same "quality" and file size but the right hand one has incorrect quantization ordering)
Also it turns out it wasn't a Kodak camera, but a Casio QV 10 I had much earlier. You can sorta see what I meant here: https://medium.com/people-gadgets/the-gadget-we-miss-the-cas... .. though the resolution is far lower too. The weird blocky color aberrations aren't just JPEG artefacts but related to the same quantization ordering issue I think.
My assumption also, but once this thing spat out those images by accident, I started to wonder if maybe broken code ended up in the firmware of these cameras and just.. stayed there :-D Might be a fun project one day if I can get hold of one and rip out the firmware!
Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs, so many legitimate users appear to come from low reputation IPs.
Turnstile is a reasonable solution in its normal form, though the 'invisible' option still lets a lot of them through. Another thing that works, surprisingly, is looking for "webdriver" usage. Despite being easy to strip out webdriver fingerprints, we find that the majority of automated attempts do not bother to do this. Adding more steps, honeypots (with an immediate short term IP ban), etc. also have an impact. It becomes a game of piling up numerous defences in a sort of "Swiss cheese model".
reply