Comments URL: https://news.ycombinator.com/item?id=40496967

Points: 333

# Comments: 296

Before: Evaluate the image in a little region around each pixel against the prompt as a whole -- e.g. how well does a little 10x10 chunk of pixels map to a prompt about a "red sphere and blue cube". This is problematic because maybe all the pixels are red but you can't "see" whether it's the sphere or the cube.

After: Evaluate the image as a whole against chunks of the prompt. So now we're looking at a room, and then we patch in (layer?) a "red sphere" and then do it again with a "blue cube".

Is that roughly the idea?

A BigCo can hire a lot of CS people but the best they can do sometimes is "we hear you and we'll pass along your feedback".

Also, what I consider "non obvious" isn't that non-obvious. Given enough of a sample size, a committed attacker can guess a lot of rules. And if the prize (a crypto wallet) is big enough, they might be motivated enough to give it a go.

So under U.S. law, the more "transformative" something is (as opposed to "derivative"), the more likely it is to be deemed fair use. The line between derivative and transformative is fuzzy but generally, something like a movie adaptation of a book is derivative whereas parody is transformative.

Given that, suppose I have a cat pic. Google creates a thumbnail of that cat pic, which is, by itself, obviously derivative. But Google includes my cat pic alongside many other cat pics in response to a query for cats, the thing as a whole starts looking more transformative.

Now suppose my cat pic gets sucked into a generative AI. I suppose it could be used to create a merely derivative copy of the original cat pic, albeit with reduced quality, like a thumbnail. But the whole point of these models is to recombine features from millions of images to create something unique. That is, if I tell the model to draw a cat, it combines features from thousands of other cat pics. Which seems at least as transformative as simply showing the same cat pics in a grid.

From an ethics standpoint, the main difference between Image Search and a generative AI is attribution. Google Image Search is just links whereas Stable Diffusion is sort of opaque about its sources. But attribution isn't one of the factors of fair use -- a parody which makes fun of the original without ever directly identifying the original is still parody.

That said, I suppose you could argue it affects the economic impact of the copying, one of the other fair use factors -- it seems plausible to me that AI generated images impacts the market for, say, Getty images in a way that does image search does not. But it's anyone's guess how a court would balance those two things -- courts very often pretend all of the fair use point one way to discussing how factors are balanced.

- The existing human edited text already on the page

- The playground to run the code in question

- One of the many existing autocomplete / static analysis tools for HTML / CSS / JS out there. If you want a tooltip explaining what the second argument to a built in JS function in a code snippet does, this is a solved problem!

> It was given a sequence of words and tasked with producing a subsequent sequence of words that satisfy with high probability the constraints of the model.

This is just autocorrect / autocomplete. And people are pretty good at understanding the limitations of generative text in that context (enough that "damn you autocorrect" is a thing). But for whatever reason, people assign more trust to conversational interfaces.

It would not be as efficient as Svelte and Solid since those can use the compiler to further optimize code, but having the framework-less version of JS be "as good as" a framework like Vue or React would be a big plus for moving away from frameworks generally.

Apart from that, the general problem of reactivity boils down to "map this DOM element to this variable, and if the variable changes, update the DOM element". You could imagine an API sort of like this:

  
    Default Value
  

There's the obvious stuff, like simply blocking third party tracking JS.

There's some small quality of life bits -- a non-trivial number of websites load JS to make prettier UI elements (like a nicer date picker) because the defaults are so ugly (on desktop at least -- mobile tends to be better). If browsers shippednicer default UI elements, folks would be be less inclined to write their own using JS.

And then there's larger fundamental changes to the API themselves. If HTML6 included virtual DOMs or reactive primitives, that might reduce the inclination towards framework bloat.

My understanding is that the container is lifted and placed on top of a typical container vessel. And containers do fall off ships from time to time. Adding a very large sail to the container makes it easier to blow off. Is whatever the standard mechanism is for securing containers to ships sufficient here?

Single droplet in the right spot => furious wiping. 100 droplets in the wrong spots => no wipe.

Climate - My preferred mode is to have the A/C on but not actually directed straight at me (so through the windshield vents), but auto also blasts through the front.

But I think it's probably economically sound in the long-term as well. That is, asking every depositor with $250K+ to assess the financial health of each bank they use and maybe buy insurance is collectively more expensive than just having the FDIC implicitly insure all deposits.

That's different than asking if it's "fair". But I would wager it's probably more efficient.

IIRC, SimCity 4 didn't have this issue but it sort of cheats by chopping the map up into multiple tiles in a region and only simulating a subset of your population. Which honestly seems acceptable to me.

I'm coming at this from a "how would I integrate this into my existing corporate setup" perspective. I'm concerned less about UX and more just how it works.

If I interact with Touca via a local client that doesn't to the Internet, and the actual data points are exchanged entirely via Git, that's a much easier sell than another server that I have to ask SREs to maintain. And being able to say "it's just Git + a local client" makes it easier to reason about concerns like "what if we switch to GitLab" or "how would this integrate into our own bespoke CI/deploy pipeline".