ethmarks

It is

> Ironically, this project was built with AI coding and uses AI to filter out articles about AI. Go figure.

https://github.com/leiDnedyA/hn-without-ai

> i wouldn't expect css gaussian blur of all things to cause slowdowns in some browsers

Gaussian blurs are extremely performance intensive. They need to be calculated for every individual pixel, and the per-pixel computation involves averaging the colors of dozens or hundreds of adjacent pixels. This site applies it to the entire <main>, which spans the entire screen's width and height on mobile, which means that it has several million pixels. That's fine if the browser only has to calculate it once, but when you're scrolling the browser has to perform those calculations for every single pixel on every single frame.

Apparently Chromium and Safari downscale the sampled texture which makes it less accurate but more performant, but Firefox doesn't do that because it prioritizes accuracy over performance, which explains why it only stutters on Firefox.

I'm pretty sure that's because the entire <main> of the site has an 8px Gaussian blur on it:

  .site-main[data-astro-cid-bpoqdqeq] { 
    backdrop-filter:blur(8px); 
  }

Why, exactly? The page looks visually identical when I disable that rule, but the performance skyrockets. I realize that it's probably vibecoded, but come on.

> they accept money and direct deposit still with no KYC. But to get the money out? Oh no! We need a picture of your face!

Unauthorized deposits aren't nearly as much of a concern as unauthorized withdrawals, right? I'd imagine that there are far fewer malicious actors that try to deposit money into random bank accounts than there are ones that try to withdraw money from random bank accounts.

> And there’s no option for going in person.

Won't an in-person bank also take pictures of you via security cameras? I don't really understand your objection here, could you elaborate?

> when they bought the successful ads company

Could you elaborate on this? What ad company did Google buy?

Does the pitch describe the distance between the edges of the pixels or between the centers?

> the size of the rust binary

The `render` binary weighed 4.0 MB on disk when I compiled it a few minutes ago. Not sure if that's what you were looking for, but just in case it is, there you go.

Here's the logs, if you want: https://gist.github.com/ethmarks/8df92a68c3076ea2f4a5aedba9f...

The source for the site is here: https://github.com/dyne/cjit/tree/main/docs. It's a VitePress site with a custom theme. Glancing through the code, I don't see any obvious signs of LLM coding. It also definitely wasn't created with Codex specifically, because according to the commit history, the first version of the site was in late 2024, months before Codex even released.

I don't think that complaining about things necessitates believing that you're entitled to them. I agree that complaining about things you received for free is in rather poor taste, but I don't think that it's morally wrong in the way that you seem to think it is. If an article you read for free had a pop-up ad on it, you have not been wronged in any way and do not have grounds to sue them, but you should be permitted to voice your complaint, so long as it's of the form "I don't like this" and not "look what they subjected me to, those monsters".

Pardon my ignorance, but why does the "447 TB/cm^2" density value use square centimeters instead of a volume unit? Does the information capacity of this material really scale in proportion to area? How? Or is it just a typo?

The Copilot in Visual Studio (Code) is not the same as Microsoft's Copilot. The former is GitHub's AI product and the latter is Microsoft's AI product. You can tell them apart because GitHub Copilot's icon is a helmet with goggles and Microsoft Copilot's icon is a colourful swirl thing.

It's wildly confusing branding not only because they're identically-named things that both repackage OpenAI's LLMs, but also because they're both ultimately owned by the same company.

I can only assume that the conflicting naming convention was either due to sheer incompetence or because they decided that confusing users was advantageous to them.

Kurzgesagt didn't invent the concept of disassembling Mercury to build a Dyson swarm. Stuart Armstrong proposed it in a lecture in 2012[0].

[0]: https://youtu.be/zQTfuI-9jIo?si=3jwmhoB7zx6rclhb

There are other substances that can be used for reactor coolant. Molten salt reactors are actually substantially more efficient than water-cooled reactors because they have a higher operating temperature. You can also use liquid metal as coolant, such as lead or bismuth.

Could you elaborate? Why would being deep in the gravity well be a non-starter? I thought Mercury's proximity to Sol was a huge advantage because of the ample solar power which would make planet-side manufacturing easier.

They asked if the astronauts "want to risk it", not if it was actually safe. Those are very different questions. The astronauts are, in fact, the world's leading experts on whether or not they personally want to risk it, so it's not entirely unreasonable to think that they could answer that question.

It just depends on whether you think that the fact that they accept the risks is reason enough to let them fly a potentially-dangerous spacecraft.

The semantics that make sense to me is that "DDoS" describes the symptom/effect irrespective of intent, and "DDoS attack" describes the malicious crime. But the terms are frequently used interchangeably.

Project Hail Mary. It's a sci-fi novel by Andy Weir (author of The Martian) that was adapted into a movie that released in theaters a couple weeks ago. It's fantastic and you should totally read/watch it.

Firstly, since this argument is about semantic pedantry anyways, it's just denial-of-service, not distributed denial-of-service. AI scraper requests come from centralized servers, not a botnet.

Secondly, denial-of-service implies intentionality and malice that I don't think is present from AI scrapers. They cause huge problems, but only as a negligent byproduct of other goals. I think that the tragedy of the commons framing is more accurate.

EDIT: my first point was arguably incorrect because some scrapers do use decentralized infrastructure and my second point was clearly incorrect because "denial-of-service" describes the effect, not the intention. I retract both points and apologize.

Unintentional denial-of-service attacks from AI scrapers are definitely a problem, I just don't know if "theft" is the right way to classify them. They shouldn't get lumped in with intellectual property concerns, which are a different matter. AI scrapers are a tragedy of the commons problem kind of like Kessler syndrome: a few bad actors can ruin low Earth orbit for everyone via space pollution, which is definitely a problem, but saying that they "stole" LEO from humanity doesn't feel like the right terminology. Maybe the problem with AI scrapers could be better described as "bandwidth pollution" or "network overfishing" or something.

In a similar vein, I want a text editor where pasting from an external source isn't allowed. If you try, it should instantly remove the pasted text. Copy-pasting from inside the document would still be allowed (it could detect this by keeping track of every string in the document that has been selected by the cursor and allowing pastes that match one of those strings).

It wouldn't work in every use case (what if you need to include a verbatim quote and don't want to make typos by manually typing it?), but it'd be useful when everything in the document should be your words and you want to remove the temptation to use LLMs.

Which is especially odd because the author (Sam Hughes) lives in the UK and wrote the original in UK English, but apparently wrote the rewrite in US English. For example, a chapter in the original was titled "Case Colourless Green", but in the US edition of the rewrite that chapter is "Case Colorless Green" (without the 'u'). So Hughes, a native UK English speaker, wrote the rewrite in a non-native (to him) dialect, then had it (lazily) translated into his native dialect.

> The only way text can become communication is when the writer has intents

I'm curious as to what you mean by this. I assume you don't mean it literally, as that would be trivially falsifiable (for example, the text readout on a digital caliper doesn't have "intents", yet it absolutely communicates meaning), but I can't think of another way that you might have meant it. Could you elaborate?

Counterpoint: a major use case for this technology would be to experiment on human brain structures to research and hopefully cure neurological diseases like Alzheimer's. If you want to cure Alzheimer's in humans, you might as well use human brain cells from the start.

But yes, I agree that they're likely using human brain cells mainly because it's attention-getting.

Is there a reason they're using human brain cells specifically? This seems like it would also work with neurons from other creatures.

I was under the impression that the relative intelligence of humans versus other animals was largely a function of brain cell quantity, not quality. Can 200k human brain cells really learn faster than 200k mouse brain cells?

A more cynical take is that they're just using human brain cells for shock value. They chose DOOM because of the "can it run DOOM" meme, so they clearly value publicity a lot.

> Here's the thing, people make casual remarks, they use imprecise non technical colloquillisms.

I think that you're completely misunderstanding my objection here. I'm not in the least bit upset by people using "zip" casually to mean something other than formal ZIP files. I personally use "zip" as a verb to describe compressing to a tarball, for example. This is a technically incorrect usage, but it's okay for things not to be absolutely technically correct.

My objection is to \3, both to your summary of it and to the actual message content. godelski did not "indicate that they had used zip colloquially"; they accused sweetjuly (who fully understood that godelski was using the term colloquially and was simply making a humorous, playful, and lighthearted correction that didn't warrant further reply) of hyperfixating on the colloquial usage of zip. This is not only technically wrong (sweetjuly was "hyperfixated" on the technical definition, not the colloquial usage), but it's also accusatory and mean-spirited.

> Do you believe it served a useful purpose to double down and restate something that was very likely well known to both parties over a week ago?

Not in a strictly pragmatic sense, no. I intended to set the record straight by clarifying the factually accurate statement that ZIP is not a lossy format, which seemed to be contested. I didn't expect anybody to read my comment to an 8-day-old threat, nor did I expect anyone to reply to it barely 3 minutes later, nor did I expect to be drawn into a 7-reply-long debate about this.

Isn't it delightful how well we've proved godelski's original point about how fraught natural language is?

Putting aside both my age and the latency of my initial response, all that I was trying to do was correct godelski's erroneous attempted correction of sweetjuly's lighthearted joke. The "colloquial usage of zip" that godelski was chiding sweetjuly for "hyperfixating" on is exactly the usage that godelski was using in their original reply. I did not misunderstand godelski's intended use: they were using "zip" to refer to "any compression format whatsoever, be it lossy or lossless". This is a technically incorrect usage, which would be fine if not for the snarky chiding. I think that misusing a term and then accusing people of "hyperfixating" when they lightheartedly correct you isn't a particularly nice thing to do.

> Did you hyperfixate on the colloquial usage of zip?

No? I am not hyperfixating on the colloquial usage of ZIP. The colloquial usage of "zip" would be "any compression container", which is not what I'm talking about. I'm talking about the technical definition of ZIP: the lossless container format specified by PKWARE. I thought that would be obvious by my reference to the PKWARE specification.

> You do realize there is both lossy and lossless compression, right?

This is simply wrong. There is no lossy compression for ZIP.

DEFLATE, by far the most common ZIP compression method, uses LZ77 and Huffman Coding, both of which are lossless. There are other methods compatible with ZIP containers as specified by PKWARE (e.g. BZIP2, LZMA, Zstandard, PPMd, etc), but all of them are lossless. According to both the official ZIP specification and every ZIP implementation on Earth, you cannot have a lossy ZIP unless it is corrupted.

There do exist lossy data formats (e.g. JPEG), but if you put those in a ZIP file it'll still encode and decode it losslessly.

Apparently the site itself is written in Loon. The HTML is just a static shell that loads a `boot.js` script[1] that runs some WASM that compiles and evals the Loon source files. I found the source code here[2].

Definitely cool in concept, but very performance-intensive and slow.

[1]: https://loonlang.com/boot.js

[2]: https://github.com/ecto/loon/tree/main/web

Because we don't know if this would scale well to high-quality frontier models. If you need to manufacture dedicated hardware for each new model, that adds a lot of expense and causes a lot of e-waste once the next model releases. In contrast, even this current iteration seems like it would be fantastic for low-grade LLM work.

For example, searching a database of tens of millions of text files. Very little "intelligence" is required, but cost and speed are very important. If you want to know something specific on Wikipedia but don't want to figure out which article to search for, you can just have an LLM read the entire English Wikipedia (7,140,211 articles) and compile a report. Doing that would be prohibitively expensive and glacially slow with standard LLM providers, but Taalas could probably do it in a few minutes or even seconds, and it would probably be pretty cheap.