Better title: Reproducible builds are hard
Could have sworn the author was a nix(os) user already. I know it’s a meme but what all the problems they’re describing literally is solved by nix. The nix sandbox even catches calls for time for example to replace it with 0 for determinism.
So to avoid those energy-hungry LLM companies from scraping your website, you force each browser to compute a lot of hashes in a necessarily energy-hungry loop, creating, at the same time, all the kind of accessibility problems?
I don’t get how people believe there’s a PoW function that both:<p>1. Allows access in reasonable time/battery use to me on my phone<p>2. Poses any meaningful challenge to the most compute-resourced organizations on the planet<p>I wonder how many cumulative hours of human life have been wasted waiting on Anubis.
There are a lot of people writing really bad scrapers and running them on far from high compute power systems. This is the prevent DoS because of those. The big companies are often far more clever and know they are traversing the whole internet and can come back later.
> I wonder how many cumulative hours of human life have been wasted waiting on writing comments on creamsicle reddit.<p>I disagree with a lot of the decisions around the design of Anubis... but resisting the current drive of the industry to ruin as much of the good faith resource donations from others is an admirable objective.<p>The point isn't to increase the amount of work required to the point of exhaustion, it's to require that scripts be able to offer the exact same feature set that browsers offer. The point isn't to make it impossible, it's too make it more expensive than free.<p>Anubis isn't trying to prevent all scraping, it's trying to reduce the abuse just enough that real requests get their fair share. You don't need to outcompute the botnet just slow them down a little.<p>I hate seeing the Anubis interstitial too, I've complained about it publicly already too. But it doesn't come close to the frustration of waiting 10s for an SPA to load all of the routes it'll never use before the first redraw. Clearly our industry has also decided latency is a good thing.
The vast majority of that compute is locked in AI accelerators that do the inference. Those hardwares are bad at doing anything other than that---in fact crawlers would need more residential proxies than more computes in that regard.
Not just LLM companies, but bots in general. They were a big problem even before LLMs.
Reading this, I think low level engineering is actually more dependent on specific environments. Hardware also has its own points of change. Usually, when you think at a high level, environmental changes are less significant than you might expect. But low level thinking tends to be tied to specific environments, which is what makes it difficult. The reason low level is hard is that even if the code itself is short, the hidden assumptions inside it are difficult and place a heavy cognitive load on the programmer. For example, even a short snippet in C like
`int value = <i>(int</i>)buffer`
requires a lot of implicit knowledge about the 4 byte alignment of the buffer, or whether int is exactly 32 bits. LLMs do not seem to be very good at knowing these things. Rather, they are strong at high level wrapping, but at the low level, they seem surprisingly difficult and somewhat useless. Hardware has CPU generation changes, and in the case of PLCs, where I mainly work, the protocol differences between vendors are far too severe. There does not seem to be any technology with a very long lifecycle.
Depends on what you mean by low level I guess. Compared to web application framework churn rate, simple procedural programming without many dependencies is remarkably stable. You tend to program in a way that works for most platforms (all targetted platforms). How to best do that you learn over the years. To me personally it's very refreshing if the environment around you does not constantly change. That affords learning a bag of tricks and a list of gotchas to avoid.
> You tend to program in a way that works for most platforms (all targetted platforms).<p>Isn't that true for web frameworks too? Usually they'll only target unix, but if they target windows and macos, then they work on those platforms too? Or am I misunderstanding what you're trying to say here?
This is how I mean it: In case of low level programming, the "platform" is the hardware/OS/compiler. In case of web programming, the "platform" is the web framework.<p>If you update the OS, hardware, or compiler, you will see only few changes. If you update the web framework, you may see breakages, API deprecations or whatever. You may want to move to a different web framework entirely. TBH I don't really know, I don't know web programming beyond basic HTML/Javascript. That's what they say, though.
Well I mean you're comparing two different solutions at different layers here.<p>In the case of an desktop application, unless you build things against OS libraries, your "platform" is also typically a framework, like QT or AppKit or whatever you end up using. That's the equivalent of the "web framework" in the web world.<p>Basically, it goes "Your app > GUI framework > other/OS libraries" for desktop apps, "Your app > web framework > other/OS libraries" for web applications.<p>Then in both approaches you can of course skip the framework if you want, no one is forcing you to use those in either of the cases.<p>Edit: I realize now we might be talking past each other, I was under the understanding that "web framework" is about backend web frameworks, but maybe you actually meant frontend frameworks running client-side. If so, replace "other/OS libraries" with "browser runtime" and my comment more or less still makes sense :)
> your "platform" is also typically a framework, like QT or AppKit or whatever you end up using<p>That's not what I consider "low level programming". I don't use any of these.<p>Yes you can do try and do plain Javascript. Honestly Javascript is a much less pleasurable environment than a compiled statically typed procedural language. The main advantage of the browser is you get a viewport, you get font rendering etc. with almost no setup required at all.
> That's not what I consider "low level programming". I don't use any of these.<p>So say C linking to Xorg-libraries and drawing GUI that way isn't low level programming, then what is? Only assembly is "low level programming" or what?<p>Meh, JavaScript is fine, like most dynamic Algol/C-like languages. Could be worse, could be TypeScript :)<p>But personally, browser environment is a hell of a lot easier to target than doing cross-platform native application development, but I'm a web developer who started doing native apps, not the other way around, might be why.
More: If you upgrade the hardware or the compiler, <i>you</i> upgrade them. If you're doing web programming, you have to worry about the <i>user</i> upgrading their browser.
I think you're right too. So I also think that maybe I'm viewing the changes as bigger than they actually are, based on my own standards
Looks like the formatting ate your asterisks at *(int*)buffer. Use \* to get an asterisk.
Nix also needs the build output to be deterministic to calculate the hash. It also has the problems of timestamps etc. The build environment tries to be hermetic by setting the time to be epoch among other things.
Yes, reading this I was thinking about how many of these problems go away with a nix environment. Certainly not all of them, but it’s a great way to get a reproducible build environment that includes direct specification of system dependencies.
SOURCE_DATE_EPOCH is not a Nix thing<p><a href="https://reproducible-builds.org/docs/source-date-epoch/" rel="nofollow">https://reproducible-builds.org/docs/source-date-epoch/</a><p>(although Nix sets it as a default)
Nix hashes the build inputs, for which deterministic builds are not required, only desirable.
These seem very reasonable, the workarounds used are natural, and overall the article is not at all congruous with the conclusion in the (clickbait?) title?<p>Compilers literally made your project possible!
> What do you do when the client has WebAssembly disabled?<p>Do people really do that? -- disable, not just using old browsers with no wasm.<p>Disabling wasm while keeping js enabled is a configuration i can't understand
Time date env variables and random address... Is also input data, maybe not as a flag but still
Time and date are... tolerable. There's SOURCE_DATE_EPOCH which should always be set to whack it into submission when used. ASLR of the _compiler being invoked_ resulting in a difference in the _program being compiled_ is nuts and would break any self-hosting compiler with consistency checks.
Explicit is Better than Implicit.
I've seen posts by this author before and did not understand if the commentary characters were referential or a creation of the author. Turns out its the latter. I dismissed the underlined names as just styling, not hyperlinks.<p><a href="https://xeiaso.net/characters/" rel="nofollow">https://xeiaso.net/characters/</a>
The Birth and Death of Javascript really had the gift of prophecy, eh
I’m still surprised by Anubis’ decision not to make the PoW have a useful output, for example a crypto, protein-folding like, or something else.<p>And I speak as being generally very critical of cryptos, but here rewarding the website owner with some cents to have access seems fair, and resolves the traditional issues about micro-payments.
A better solution might be to use <a href="https://github.com/evanw/polywasm" rel="nofollow">https://github.com/evanw/polywasm</a> to run the original wasm in place.
If Clang generated non-deterministic output due to pointer addresses then that's a bug (happens regularly) that should be fixed. The most common way this happens if it some code path is iterating over a DenseMap which is non-deterministic. Sometimes that's fine and sometimes that's not depending on how that map is used. The common way to fix that is to switch to a MapVector which pays some additional runtime/memory cost to guarantee deterministic iteration order.
I hate proof of work code running on my machine for the benefit of someone else. It's like planting a crypto miner.
The "benefit of someone else" in this scenario is the site operator not having their website down or their hosting bills unsustainable because of misbehaving (which are 99% of current) web scrapers from AI companies.<p>The README itselfs admit that this is an nuclear option.
<a href="https://github.com/TecharoHQ/anubis" rel="nofollow">https://github.com/TecharoHQ/anubis</a>
Do proof-of-work pages actually stop AI bots? Big AI companies have enough compute to solve these challenges at scale. And if their bots are already doing much heavier work to fetch, read and process each page, then solving a small challenge first seems unlikely to be a serious barrier. Who are these proof-of-work challenges actually helping?
I believe poisonous loops of non-sense text are the best choice in terms of LLM capabilities and human distinguishing potential; the next iteration could be non-sense with reasonably intact grammar and content. At the very least, show some content whilst doing the PoW (isn't the point rising computational costs? Give me something like YouTube video decryption instead of having me wait at least) OR use the PoW for some useful protein-folding, finding the next prime, or an alternative monetization scheme.
Yup, and I suspect that even if OP is honest in this respect, if proof-of-work gets established as a normal practice for web pages, it's going to be used this way.<p>But just taking this as-is, what is the environmental impact likely to be when multiplied up by the number of users? Proof of work is a bad idea.
Yes, all these kind of bot checks are essentially malware.
> What do you do when the client has WebAssembly disabled?<p>> I decided to take inspiration from the legendary talk The Birth and Death of JavaScript and just recompile the WebAssembly to JavaScript.<p>So what do you do when the client has Javascript disabled ?
To avoid all those grotesque and absurd compilers and runtimes, more for those of computer languages with a ultra-complex syntax (c++ and similar), I now design "binary specifications" which I "design" and "validate" with RISC-V assembly coding.<p>Here, since any whatwg cartel web engine is an issue, the author should not bother.
[flagged]
Tell me the flags I'm missing then: <a href="https://github.com/TecharoHQ/anubis/blob/Xe/wasm4/utils/wasm/wasm2js/build.sh" rel="nofollow">https://github.com/TecharoHQ/anubis/blob/Xe/wasm4/utils/wasm...</a>
> This is the goofiest I've seen written unironically in quite a long - the C preprocessor is not part of the compiler. The pre in preprocessor should probably give it away.<p>This is true but doesn't seem relevant; does replacing the word "compiler" with "build chain" change anything? Because that seems like the clear meaning.
Re: source code producing different binaries: things like ASLR, stack canaries, optimization levels, linking, etc all lead to different binaries.
[flagged]
As long as the program is equivalent there isn't an actual problem here. Requiring the output to always be the same is an arbitrary restriction.<p>If you want to have users trust that someone else hasn't modified it, then sign it with your identity.
LLMs should be trained on and directly output binary.
On the off chance that you’re serious, that would result in disastrously bad output. The difference between “jmp $+15” and “jmp $+16” is inscrutable and the LLM would not be able to pick the right one without tooling.<p>That tooling is a compiler. The higher level, the better chance the LLM can be steered to good output. Machine code is hopeless, don’t bother.
That compiler does wonders with languages that have UB on their specs, especially when having optimizations passes with heuristics.<p>Also there are dynamic compilers were the shape of machine code changes as the code executes, and each single execution will certainly generate different sequences, depending on the program execution and where it is running.<p>Deterministic JIT compiler code generation, at least on optimising ones, is not a solved problem.
What about AOT optimization? whuch brings aot closer to JITs performance? Isn't that something LLM + Harness can easily do?
I think the idea that AOT is inherently faster than JIT, or vice versa, is a thoroughly debunked idea.<p>You can have LLMs help you optimize code but I don’t think you can do this unattended for non-trivial code.
> The difference between “jmp $+15” and “jmp $+16” is inscrutable<p>I don't see why that's the case.
LLM trained on binary would totally see it, not?<p>Also the tool can also be running the test and a debugger.
> I don't see why that's the case. LLM trained on binary would totally see it, not?<p>It would not. You find the correct version by counting the number of bytes to the destination. LLMs are famously bad at this kind of problem (counting).<p>> Also the tool can also be running the test and a debugger.<p>The test needs to provide a good amount of signal. That’s too hard if you are throwing machine code at the wall.<p>In order for debuggers to work, you need some kind of model that describes what the code should do and what state the computer should be in after each instruction. That model is high-level code.<p>I can understand the intuitive appeal of training LLMs with machine code, but all of my experience with LLMs suggest that they are incredibly ill-suited to the task, and we just don’t have the capacity to train them to make useful machine code.
Even if it could, it would be ridiculously token inefficient to update huge amount of addresses instead when some small change is done to the middle of a binary
It should not. Abstraction in software engineering brings intelligence. (compression correlates to intelligence)
runApp()<p>Done! Excellent abstraction. High intelligence.
people don't get this
Why? I mean this is all emergent, right? And it’s not like humans ever work at this level. It would be very interesting to see what sort of outputs and abstractions an LLM comes up with.
Generative algorithms have been studied for decades now and while they have led to some interesting results they're a bad fit for LLMs because there's no such thing as a "plausible" binary: a small perturbation yields an unusable result.
Technically they are, just a subset. But still a practical one, they're frequently used to produce executable files.
I think you forgot the "/s"
[flagged]
[flagged]