GrantMoyer

I think one of the primary motivations for cryptocurrency was that legal ≠ moral. Therefore, I think cryptocurrency's best use cases are all explicitly illegal.

For example, you can donate to Sci-Hub with cryptocurrency. Sci-Hub has an ideological mission which is widely supported, but it runs afoul of copyright law and is illegal in nearly every country and sanctioned in many. You cannot donate to Sci-Hub with fiat currency.

Unfortunately, I agree that in practice >99% of cryptocurrency's use is for scams.

Firstly, TFA has a bright red banner describing the opt-out mechanism. It's probably the second most attention-grabbing element on the page, after the countdown. Secondly, initially Google didn't mention any plans for an opt-out at all[1]. That was was only ceded after pushback[2].

[1]: https://web.archive.org/web/20260312134021/https://developer...

[2]: https://web.archive.org/web/20260328133800/https://developer...

> Somewhere, that line exists where the company would financially benefit, I just wish they'd actually define it.

The line doesn't exists. It's most profitable for the company to repeatedly:

1. Have an ad-supported tier and a no-ads tier

2. Wait for most people to move to the no-ads tier

3. Introduce ads into the no-ads tier

4. Wait for people to get sick of ads

5. Introduce a new, higher cost no ads tier

There is no threshold where it's more profitable for the company to never introduce ads at that price point.

The benchmark[1] (HN discussion [2]) I read from about 2.5 years ago came to roughly the opposite conclusion. JPEG XL dominated practically all other image formats on compressed size and encoding time.

Superficially, that benchmark and this one seem to be taking similar measurements. They both measure encoded size versus encoding time versus perceptual quality metrics, although they present the data on plots with different axes. I haven't tried to reproduce the results of either, but I have no reason to doubt either benchmark.

I wonder what accounts for the difference. Maybe the libavif encoder got a lot better in the last 2.5 years. The older benchmark uses libjxl v0.10.0 and libavif v1.0.3, while the newer one uses libjxl v0.12.0 and libavif v1.4.2. Or maybe it's the set of images used. The older benchmarks aggregates results for small test sets of images, while the newer benchmark tests individual images. The newer benchmark does find an image where libjxl wins on file size (the weasel), but it still loses on encoding time, whereas in the older benchmark libjxl almost always won on both. Or maybe it's the hardware (M3 Pro vs. M4 Pro).

[1]: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

[2]: https://news.ycombinator.com/item?id=39559281

I regularly fully read and try to understand paper contracts before signing them. Every time, it's clear that no time was set aside for me to read the contract, and the other party expected me to sign the contract within a few seconds of first receiving it. Often, I get the sense that the other party is annoyed or frustrated that I take time to read the contract before agreeing to it.

I've read that contracts fundamentally require a "meeting of the minds", where two parties come to a mutual understanding of an agreement. At the same time, overwhelming people are expected to not read and understand contracts they agree to. I don't understand how these two facts don't combine to mean the vast majority of written contracts are not legally binding, but apparently judges don't share my confusion.

It alienates me, because I cannot relate to it. To me, it reads like the author is going around, running some sort of flowchart for every woman they briefly interact with, like:

  [Are they hot?] -No> <Ignore>
         |
        Yes
         v
  [Are they wearing a ring?] -Yes> <Ignore>
         |
         No
         v
         …

I don't even know what that last step would be. It's not going to be sex. The woman is at work and the two don't even know each other.

Maybe that's not what the author is thinking. I don't know, because I can't understand what the author is thinking. I'm alienated.

The comments on women's bodies are not relevant to the narrative, and they alienate readers (women and men). It's bad writing.

And even if the theorem prover has no errors, the math behind the theorem prover could be inconsistent according to Gödel's incompleteness theorem. So even in principle, we can never be completely certain about the soundness of Rust, though the more theoretical concerns tend to be dwarfed by basic human error.

I think it's a good thing to keep in mind, that the actual implementation of Rust almost certainly isn't sound. Even an "ideal Rust" still has unsafe, which can affect the soundness of even faraway safe code. But I don't think it's nessesarily wrong to talk about Rust as if it were safe. Much of our communication has implicit assumptions, and the way we talk about Rust is no different. It would be exhausting to qualify every discussion of saftey with "assuming the compiler has no bugs", "assuming all unsafe code follows the (not fully specified!) rules", etc.

Ultimately it's like any other implementation of theory into practice. The theoretical model of Rust lets us reason about and design an implementation to achieve certain practical goals even though the model is a simplification of reality. In Rust's case, practical use has demonstrated it achieves design goals like reducing bugs and reducing development time (compared to peers like C++) to a substantial degree.

It's surprising this bug went unnoticed for so long, but at least it's easy to fix, since it's not a bug with the type system itself; it's just a bug in the compiler. The compiler should always have been rejecting that code according to lifetime rules of Rust's type system, so the fix is to just make it reject the code, rather than having to change the fundamental rules of lifetimes.

Let's take a simple example: writing past the end of an array. Allow me to argue with myself for a moment.

> Surely the compiler can just check if each access is valid.

Well, sometimes it can, but sometimes it doesn't know how long the array is. What if the array is passed as a pointer?

> Maybe each array could be annotated with its size at runtime, and accesses could be checked at runtime too.

That works, but it adds runtime cost that may legitimately be too much for some applications, for example, a Gameboy game (set aside that many Gameboy games were written in assembly).

> Fine, so we'll make the programmer promise to ensure array accesses are always valid. Maybe they'll make a mistake sometimes, but what's the worst that could happen? Throwing your hands in the air and saying the compiler is allowed to do anything, that's just stupid.

Well, maybe it's stupid, but this is one thing that could happen if you accidentally write past the end of an array: https://www.youtube.com/watch?v=Vjm8P8utT5g. I'm sure neither the programmers nor compiler writers intended that.

Ultimately, the compiler can't guarantee any behavior if its assumptions are violated. The example may seem contrived, but it demonstrates that, given the right circumstances, the results of the logical contradiction are unbounded. This is a direct consequence of the "Principle of explosion": https://en.wikipedia.org/wiki/Principle_of_explosion. On second thought, maybe the runtime costs of array bounds checking are an acceptable trade-off after all.

Windows has, for a while, had Windows Imaging Component for images (https://learn.microsoft.com/en-us/windows/win32/wic/-wic-lh) and Microsoft Media Foundation for video (https://learn.microsoft.com/en-us/windows/win32/medfound/mic...). Not sure how widespread actual use is though.

With or without a comma, without a conjunction like "and" the example is a run on sentence and is ungrammatical. You should join the clauses with a conjunction, and including a comma before the conjunction is a common style.

There's a caveat where some style guides permit using a comma without a conjunction in specific contexts, but most don't.

English has no central authority, so the lines between grammar and style can get fuzzy. Most guides would say you need an "and" after the second comma, but some make an exception if the clauses are "very short and alike in form". See Wikipedia's article Comma splice if you are interested in the pedantics. https://en.wikipedia.org/wiki/Comma_splice

Informally, commas are "misused" regularly even by native writers, and almost no one notices or cares unless the misuse is frequent and egregious.

Formally, most comma use is an issue of style, not grammar, and style guides differ on when they should and shouldn't be used. The main rule that's actually a matter of grammar is this: commas cannot be used to join two "clauses" (phrases which could be independent sentences) without a conjunction.

Depending on the shell, `somedir/*` excludes files whose names start with "." and may expand to a literal "*" if there are no file names to expand to. Basically, globbing has more edge cases to deal with.

I really like this feature of rsync (trailing "/" means copy the directory contents to the dest, no trailing "/" means copy the directory itself). Other tools, like cp, don't have any way at all to say copy the directory contents to the dest, and for those tools the result depends on whether or not the destination already exists and is a directory (you might end up with a duplicate nested directory). Rsync produces the same result whether the destination already exists or not.

Ah, the plan is to eventually completely ditch SHA-1, but only after "everyone" has already converted to SHA-256, which is hopefully before SHA-1′ is broken. See sections Object names on the command line and Transition plan from the link in my top-level comment.

Git moved to a modified SHA-1 (let's call it SHA-1′) back in 2017 which prevents the particular attack described in SHAttered, so the SHA-1′ object names and signatures can be trusted for now. But the known collision attack on the underlying algorithm makes it more likely for SHA-1′ to be broken in the future too. Researchers could find variations or improvements of the weaknesses used in SHAttered to attack SHA-1′ as well. In other words, there are no known practical collision attacks, but there are known avenues of reasearch that could lead to practical collision or second-preimage attacks being discovered.

The idea, then, is to migrate all git history to a stronger hash before that happens. If we waited until an attack was found, it'd be too late; all git history would be suspect forever into the future (disregarding extensive auditing), even if a stronger hash was used retroactively. Full SHA-256 doesn't have known practical collision attacks, and it doesn't even have known research avenues likely to lead to practical collision attacks, so is considered more future-proof than SHA-1′.

This idea of future-proofing is common in cryptography. For example RSA-1024 keys are now considered practical to factorize (with a supercomputing cluster and a few months), but that's okay, because, foreseeing the possibility, "everyone" switched to RSA-2048 or stronger a decade ago. Now we're adopting new key algorithms to protect against possible quantum computing attacks in the future.

The third-party tooling concerns seem plausible. For example, it seems like the intension for Git hosting is:

1. Git users all transition to SHA-256 while git hosts stay on SHA-1.

2. Once almost all Git users are on SHA-256, Git hosts flip a switch and convert all hosted repos to SHA-256. Git users on SHA-256 don't notice anything, because the only thing that changes is how the client and server negotiate which objects to send.

3. Git hosts disable SHA-1 support. Git users on ancient clients need to upgrade or switch hosts.

Instead, by the author's account, Git hosts are deciding to convert repos to SHA-256 individually and placing the decision of when to do each conversion upon their users, who may not be informed about the situation. To me, that seems like the wrong decision, but then I don't run a Git hosting service.

No doubt other tools will take some time to catch up too. For example, libgit2 is perhaps the most popular third-party Git client, and it still doesn't support newer Git features like reftables (circa 2020). Though libgit2 does appear to implement SHA-256.

For reference: https://git-scm.com/docs/hash-function-transition

Notably, a few of the featured author's reservations appear to be addressed. According to the Git docs:

- Objects can be referred to by their old, SHA-1 name or their new, SHA-256 name. This means old refs in docs and comments and such remain valid. The mapping between SHA-1 representations and SHA-256 representations appears to be intentionally bijective a.k.a. 1-to-1 (assuming no hash collisions), so that it could be re-computed on demand. The constraint of bijectivity appears to be the source of some limitations, ex. no mixed repos and submodules needing to match hash algroithm, but also bijectivity has strong benefits like the following items.

- A bi-directional dictionary is maitained from SHA-1 to SHA-256 names so translations between the two don't required re-hashing objects. This table could be recomputed on demand due to the bijection between names; it's only a performance optimization.

- A local SHA-256 converted repo (including an SHA-256 converted submodule) can interoperate with an SHA-1 only remote transparently to the remote server by translating names using the lookup table.

- SHA-1 based GPG signatures will be preserved. A commit can be signed based on its SHA-1 representation, its SHA-256 representation, both, or neither. The bijection means the two types of signatures are in a sense interchangeable, or in other words the bijection between object representations implies an equivalence relation on signatures. An SHA-256 converted repo can quickly validate an SHA-1 based gpg signature using the lookup table.

Then `git fsck` wouldn't be able to tell if an object uses the sha1 scheme or the sha1∘sha256 scheme, so it may need to compute the both hashes to check an object's integrity. Also, an object name alone wouldn't indicate that the weak scheme shouldn't be used to check integrity, so a malicious sha1 object could be swapped in in place of an sha1∘sha256 object (if second-preimage is found).

On a biological level, there'd be no problem providing a vegetarian diet for everyone. A healthful vegetarian diet is not hard to achieve, at least no harder than a healthful non-vegetarian diet.

From an infrastructure point of view, providing everyone vegetarian food sources overnight would not be possible, but that's not a realistic scenario. With a gradual transition, the transition would reduce overall resource use on basically all fronts, so there's no reason to expect extraordinary problems.

Of course, this is all theoretical unless people care enough to change their lifestyles.

People need to eat, but they don't need to eat meat.

I'm not familiar with patent legalese, but from my layman skimming of the patent application, I think you're right.

Instead, the patent would cover running object detection/classification ML models — optionally on remote servers — on screen and audio output and user input of specific applications (particularly videogames), without requiring cooperation from the application, to target ads based on what's happening in the application and to decide when to interrupt the application with an ad.

To hazard a guess: Microsoft or part of Microsoft is planning to include pervasive targeted advertising in the next Xbox console OS, including during gameplay of any game.

I'm not too familiar with the CPU world of performance measurement, but in GPU land, and I suspect for CPUs too, there are a slew of hardware "performance counters" which are registers that increment every time the event they measure happens.

So there could be a "instructions completed" counter and a "cycle" counter, and before starting the benchmark, you record the current value of both counters, then after the benchmark, record the final values, and compute the Instructions Per Cycle (IPC) as the difference in instructions completed over the difference in cycle count.

As for optimization, at a high level it's about minimizing the amount of time any part of the CPU is waiting for other parts of the CPU. The specifics require a lot of background knowledge about how modern CPUs work, more than can fit in a post, but if you're interested, topics to read about include:

### CPU cache hierarchy

CPUs store copies of data from RAM in smaller, faster memory physically closer to where the computation happens, so it's available more quickly. The CPU decides what values to store in the cache, and gives only limited control to the program, so an optimal program needs to be careful to not make the CPU make bad caching decisions (including for synchronizing the cache between multiple threads of execution).

### Instruction pipelining and out-of-order execution (a.k.a. "superscalar" execution)

Modern CPUs operate like an assembly line. A new instruction can start executing before the previous instruction(s) finishes. CPUs also have redundant hardware, so multiple instructions can be in progress at the same step of the pipeline. But there are limitations; sometimes the input to one instruction depends on the output of the previous instruction, so the whole pipeline stalls until the result is ready. An optimal program orders its operations to avoid these stalls as much as possible.

### Branch predicition

When the code to execute depends on the result of a computation, like in an `if` statement, we call it a branch. Branches can stall the pipeline, because the CPU doesn't know what instructions to execute next until the current result is ready. However, to mitigate this, modern CPUs predict which code-path will be taken when a branch is reached and begin executing the associated instructions immediately. If the prediction is right, the pipeline stall is avoided, but if it's wrong the pipeline state has to be restored to what it was before the wrong branch started executing, which is even more expensive than a stall. Usually, the CPU predicts branches correctly, so branch prediction is a net gain. Optimal programs need to understand how the CPU makes these predictions and make their branches as predictable as possible.

### Single Instruction, Multiple Data (SIMD)

Some programs do the same operations to each item of a set of data. CPUs have so-called SIMD instructions to accelerate this by, unsurprisingly, performing the same operation to multiple items at once. For example, they could add 4, 8, or even up to 64 pairs of numbers at once, depending on the instruction set and the range of the inputs. Suitable programs are optimized by arranging their inputs and operations so that SIMD instructions can be used — either directly or by being written in a way that a compiler can translate individual operations to SIMD operations.

The idea is that NPUs are more power efficient for convolutional neural network operations. I don't know whether they actually are more power efficent, but it'd be wrong to dismiss them just because they don't unlock new capabilties or perform well for very large models. For smaller ML applications like blurring backgrounds, object detection, or OCR, they could be beneficial for battery life.

Even with modern digital codecs and streaming, there's usually chroma subsampling[1], so the color channels may have non-square "pixels" even if overall pixels are nominally square. I most often see 4:2:0 subsampling, which still has square pixels, but at half resolution in each dimension. However 4:2:2 is also fairly common, and it has half resolution in only one dimension, so the pixels are 2:1. You'd have trouble getting a video decoding library to mess this up though.

[1]: https://en.wikipedia.org/wiki/Chroma_subsampling

> This metalanguage must have some kind of constructs to describe unknown things, or things that are deliberately simplified in favor of exposition.

Perhaps you're thinking of mathematics.

If you have to be able to represent arbitrary abstract logical constructs, I don't think you can formalized the whole language ahead of time. I think the best you can do is allow for ad-hoc formalization of notation while trying to keep any newly introduced notation reasonably consitent with previously introduced notation.

Linux supports per-process namespaces too, and has tools like firejail to use them for sandboxing, but nonetheless sandboxing is not widely used.

> if digital painting were solved not by a machine learning model, but human-readable code, it would be an even more bleak and cruel joke, isn't it?

On the contrary, I'm certain such a program would be filled with fascinating techniques, and I have no dread for the idea that humans aren't special.