htunnicliff

    I'm not sure we need put more effort into the "legacy" XMLHttpRequest, WebSocket, and EventSource networking APIs.

I wish I knew the answer to this question: What shape would organized resistance have in this day and age, especially with the fragmentation of reality caused by social media?

Myself and almost everyone in my social circles under the age of 50 seem well-primed to participate in such organized resistance, were it to come to life.

  - Satisfactory
  - Trine 2
  - Minecraft

  - Super Mario Galaxy

>

> In defense, the substitute was the peace dividend. In software, it’s AI.

It would be neat to see those editions show up in when browsing collections in apps like Libby or Overdrive (at least in the U.S.).

    I also modified a script I've been using for a few years to patch pylsp so it can now see uv script envs using the "uv sync --dry-run --script <path>" hack.

> The pattern is clear: The more we go online, the less we show up in person. And the less we show up, the less likely our physical realm will offer experiences that can compete.

    ref as a prop: Refs can now be used as props, removing the need for forwardRef.

UUIDv5 is meant for generating UUIDs from "names" that are drawn from, and unique within, some "namespace" as per Section 6.5.

UUIDv6 is a field-compatible version of UUIDv1 (Section 5.1), reordered for improved DB locality. It is expected that UUIDv6 will primarily be implemented in contexts where UUIDv1 is used.

UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded. Generally, UUIDv7 has improved entropy characteristics over UUIDv1 (Section 5.1) or UUIDv6 (Section 5.6).

UUIDv8 provides a format for experimental or vendor-specific use cases. The only requirement is that the variant and version bits MUST be set as defined in Sections 4.1 and 4.2. UUIDv8's uniqueness will be implementation specific and MUST NOT be assumed.

The only explicitly defined bits are those of the version and variant fields, leaving 122 bits for implementation-specific UUIDs. To be clear, UUIDv8 is not a replacement for UUIDv4 (Section 5.4) where all 122 extra bits are filled with random data.

Background for the changes:

Many things have changed in the time since UUIDs were originally created. Modern applications have a need to create and utilize UUIDs as the primary identifier for a variety of different items in complex computational systems, including but not limited to database keys, file names, machine or system names, and identifiers for event-driven transactions.

It seems harder to tell whether any apparent bias in ChatGPT was intentionally programed or unintentionally learned. I’m not sure if there is a way to learn the reason for the answers aside from the OpenAI folks chiming in.

I often read about nostalgia for the days of mailing lists and IRC but have struggled to understand the appeal since I never experienced those forms communication myself. This analysis really opened a window into that world for me, and I now find myself in agreement with Michael that GitHub has not made discoverability and community engagement a priority.

GitHub has the ability to restore the soul of open source and make things much more exciting for 100,000 projects out there without an audience. It should do everything in it’s power to cultivate that excitement for everyone, not just a few lucky people.

I agree wholeheartedly and would love to see GitHub take steps in this direction.

It would have been nice to see the author address that possibility, but it seems fingerprinting is not mentioned.