andrewfong

My understanding is that it's also a legal CYA. If you have SLAs in place, outages might mean you owe money. So companies tend to err on the side of underreporting.

Someone's also purchased setwitter.com to prevent the same attack on another obvious domain

My understanding of this tech is pretty minimal, so please bear with me, but is the basic idea is something like this?

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 more subtle aspect of customer service here is that, as the dev or PM responding to the customer, you have a lot more power to give the customer what they want.

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".

I tried that but it's just really hard to keep up over time -- e.g. I used a rule based on the domain name but domain names change somewhere often. Toss in things like "ugh, which of my three emails did I use on this site" or "which high school teacher did I say was my favorite for this site" and it ends up being a big hairy mess that screams for an encrypted place to stick my notes.

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.

Eh, I'm not sure that follows.

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.

Even if the AI didn't make stuff up, it's unclear to me what value it adds over...

- 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!

I think this is Supabase's whole schtick, right? It's an open source, optionally self hosted Firebase alternative.

If you're going to use an ML model, you might as well use an existing language translation model rather than asking ChatGPT or the like to convert words one by one. You'd probably get better results treating American English and British English as entirely different languages rather than assuming one is the same as the other but with a handful of different words.

I'm still annoyed they got rid of the ultrasonic sensors on the latest model. I test drove a 2022 (or maybe a 2021) and the park assist was pretty good. And then I get the 2023 delivered and there's no park assist for the first 6 months because they removed the ultrasonics but the vision-only software wasn't ready yet. A vision-based park assist finally came in via an OTA update but it's nowhere near as precise as the ultrasonic version was. Like, the estimates of how much distance is in front of me seem to jump around a lot more than I'm actually moving, and it sometimes reports it's degraded when trying to pull out of a tight spot.

Well, it sort of is OpenAI's fault that it presented the interface as a chat bot though.

> 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.

By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.

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:

  <span bind-var="variableName" bind-gen="functionName">
    Default Value
  </span>

Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`

At this point, I feel like the party best equipped to reduce JavaScript bloat are the web browsers themselves.

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.