wky

“Rogue uranium escapes from Chornobyl reactors.”

GitHub is pretty good about editing on the web. Markdown files can be edited straight from github.com. On desktop you can hit the period key to directly open the repo in vscode.dev. Technically on mobile you can change github.com to github.dev to do the same, though the editing experience is worse than directly editing on GitHub.

You can control this in the settings:

    - Learn from chats in Smart Window
    - Learn from browsing in Classic and Smart Windows

Edit^2: On triple reread it sounds like the first pass ("Image Capture") sends the image metadata hash to be timestamped, whereas the second pass (Reference Image Development) sends the image itself but is not what actually creates the timestamp attestation. According to Apple[0][1] it sounds like the second pass (development) only happens when the reference image is actually viewed, which means that your image isn't sent if you never view the reference image?

[0] https://support.apple.com/guide/iphone/view-reference-images...

[1] https://www.apple.com/legal/privacy/data/en/reference-image/

> When you take a photo in Reference mode after tapping Reference Mode, your device will include reference image information in the photo’s metadata. If you then view that photo and tap the Reference badge on your iOS device or click it on your Mac, the device will send the raw photograph, metadata about the photograph like the sensor’s signatures and the time frame in which the photo was captured, as well as the sensor’s unique hardware identifiers to Private Cloud Compute.

Edit: On reread it seems they do in fact send the actual photographic data to PCC, which I presume has some reason over signing metadata on-device? Original mistaken post is below for transparency.

You can always not use the reference image mode, and according to the article you send a hash of the signature of the photograph, so all they would know is you took a photograph in reference image mode at some point in time before the request.

The timestamp system seems like it provides more benefit than signing the image data itself, at least in terms of difficulty to fake. As long as rolling back the stored timestamp token is prevented, I would have to find a phone that never updated its timestamp after the time I want to fake. Of course you could potentially find a phone that last connected to Apple's servers with a plausible timestamp. Even then the upper bound of when it signs the photo after reconnecting to the internet will raise eyebrows if you take too long to find the phone and fake the photo, so it effectively raises the bar to having to take the fake photo roughly simultaneously with the time the event purportedly took place anyway.

This reminded me of such good memories of playing with http://weavesilk.com/. Nice to see someone with a similar concept.

A mentally simpler, though slightly biased algorithm is for each item, randomly generate a uint64 (arbitrary bit size) and switch to the new item if and only if the number generated is greater than or equal to all previously seen numbers. The end result is equivalent to randomly generating a number for each item and picking the item with the largest associated number.

Is there an advantage over just --guest?

What I find strange about RFC2119 is technically RFC8174 amends it, yet the amended text never seems to be used.

It wouldn’t surprise me if AISLE uses many different providers’ models, and what’s holding back OpenAI and Anthropic is only using first-party models. Just because OpenAI and Anthropic have arguably the strongest models overall doesn’t mean their models are the strongest at finding any given class of vulnerability or lead to follow.

> If supported by a user agent, this event MUST be dispatched when a key is pressed down [...]

https://w3c.github.io/uievents/#event-type-keypress

This raises the question of why real life buttons and virtual buttons behave differently. My unsubstantiated guess is that clicks act on release to give the opportunity to slide off the button to abort, and/or because the button would disappear while pressing if it ex. submits a form.

Holding a key would indeed require both on key down and up. I'd still argue that handling rerender on key down (or to fully match whatever OS/browser semantics, oninput) makes more sense than key up. Pressing Ctrl+V for example produces feedback as soon as "V" is pressed, not when Ctrl and/or V is released.

Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.

They do that, yet proceed to kneecap the perceived latency by delaying the render.

> And on keyUp (the user releases the key), we render the suggestions.

The perceived latency starts from keydown, not keyup. Redefining latency to start at keyup reduces measured latency, not perceived latency, and delaying the visual display to keyup makes perceived latency strictly worse, not better. Even sticking with the keyup definition, just displaying the result as soon as it is available gives the possibility of negative (defined) latency.

Specifying units seems to be unreliable; I tried adding a description to the set_thermostat temperature:

    "temperature": {
      "type": "number",
      "description": "degrees Fahrenheit"
    },

Set the living room temperature to 70 degrees Celsius

    {
      "function_calls": [
        {
          "name": "set_thermostat",
          "arguments": {
            "room": "living room",
            "temperature": 70,
            "mode": "cool"
          }
        }
      ],
      "confidence": 0.6045
    }

Set the living room temperature to 70 degrees Fahrenheit

    {
      "function_calls": [
        {
          "name": "set_thermostat",
          "arguments": {
            "room": "living room",
            "temperature": 70,
            "mode": "heat"
          }
        }
      ],
      "confidence": 0.4536
    }

Set the living room temperature to 70 degrees

    {
      "function_calls": [
        {
          "name": "set_thermostat",
          "arguments": {
            "room": "living room",
            "temperature": 70
          }
        }
      ],
      "confidence": 0.8517
    }

Trying "in degrees Fahrenheit" for the tool description had similarly counterintuitive confidences.

Edit: to be clear, the counterintuitive behavior is that the confidence ended up higher for the wrong units.

Considering it as a classification problem, you could use a representative set of example queries, feed them to this model, then ask a "smart" language model to assess each query + result for whether the result is actually correct. Then you have a dataset you can compute FPR and FNR for any given threshold, and score based on the context, ex. turning the lights on or off is a lot less important if it is right compared to whether your door is locked. You could even pick it based on the tool call itself: Low threshold for locking the door, high threshold for unlocking the door.

The main thing that helps with lead breakage is a mechanical pencil with a sliding nose cone/tip. Even finer lead becomes fairly reliable as long as it is protected against sideways pressure. My personal favorite is the Kuru Toga Advance 0.3mm, though a larger lead size and a model purpose-built for break-resistance would be better if tip breakage is the main concern.

Additionally, the proposal of button actions is for the opposite purpose, when you want to avoid sending the form data when the button is pressed.

The link to Architectural Decision Records is empty, but they're present in the repo to look at[0]. Curiously the decision with the most deciders is the implementation of JavaScript bindings[1].

[0] https://github.com/EpicGames/lore/tree/main/docs/developing/...

[1] https://github.com/EpicGames/lore/blob/main/docs/developing/...

Zoom's filter applies before Color Filters, so a workaround is to toggle on zoom, set it to greyscale, then use the 3 finger gesture to zoom out to 100%.

From the comparison image it looks like the goal is functional compatibility, not render compatibility. The table borders change and the layout changes.

There are countries that require published material to be submitted to a national archive[0]. A similar system could be done for software source code and made public on expiry.

[0] https://youtu.be/ZNVuIU6UUiM

The closest thing would be our showcase poster[0], at some point I might write about the thought/development process (both for my sake and whoever picks up the project in the future)

[0] https://docs.google.com/presentation/d/1jsJ5euZ4VXcwL4fbgJKM...

This is neat. This group’s approach of treating the devices as many weaker servers (basically a raspberry pi cluster) sounds like the most realistic way to reuse phone hardware at scale, especially with the backing of the actual hardware vendor.

It’s a genuine shame how locked down iPhones are compared to even Android. Hypothetically you could run Linux inside UTM[0] but outside the EU Apple makes it intentionally difficult, and there’s still memory restrictions and performance penalties.

My group’s senior year project was a computing cluster on phones (specifically targetting LLM inference) [1]. Instead of installing a new OS we built separate apps per OS. Our devices were older, so the Android phones had worse hardware and the iPhones had more software restraints.

[0] https://getutm.app/ [1] https://github.com/orgs/rmcluster/repositories

It doesn't even need to represent intervals. A 13 inch ruler with 13 markings at 0.5, 1.5, etc inches is still a valid ruler, albeit an odd construction.

Golang has the golang.org/x packages, which avoids too much stdlib bloat while still providing the niceties of “pre-vetted” packages that don’t pull in a massive dependency tree.

It's possible that Instructure's servers got compromised:

dig canvas.ucdavis.edu

    [...]
    
    ;; ANSWER SECTION:
    canvas.ucdavis.edu. 1974 IN CNAME ucdavis-vanity.instructure.com.
    ucdavis-vanity.instructure.com. 60 IN A 18.173.121.125
    ucdavis-vanity.instructure.com. 60 IN A 18.173.121.103
    ucdavis-vanity.instructure.com. 60 IN A 18.173.121.15
    ucdavis-vanity.instructure.com. 60 IN A 18.173.121.18

dig canvas.duke.edu

    ;; ANSWER SECTION:
    canvas.duke.edu. 300 IN CNAME duke-vanity.instructure.com.
    duke-vanity.instructure.com. 60 IN A 18.173.121.125
    duke-vanity.instructure.com. 60 IN A 18.173.121.18
    duke-vanity.instructure.com. 60 IN A 18.173.121.103
    duke-vanity.instructure.com. 60 IN A 18.173.121.15

As a heads up, NHK tends to remove videos from their site, probably due to contract stuff. It seems Texico starts expiring next year. Sometimes they “rebroadcast,” but for peace of mind make sure to download a personal copy.

This post has managed to “confuse” Google about the reverse question as well (“who named teresa t whale”):

The humpback whale known as "Teresa T" was named by Simon Willison in September 2024. Background: The juvenile humpback whale was frequently spotted in Pillar Point Harbor near Half Moon Bay, California. Method: Willison gave the whale its name through a blog entry and a YouTube video caption. Significance: The naming was a playful act, which Willison described as a way to create a "championship that doesn't exist" through online documentation.

[…]

Even with no context most humans would see that the quoted significance makes no sense.