jorams

I agree and none of the other passages people are quoting from the paper (which I admittedly haven't read yet) seem at all controversial. She's saying OpenAI's messaging about AI safety is not landing because it's simultaneously launching products that are taking the spotlight, and Anthropic is doing a better job at signaling their commitment to safety. That's true, obvious, and entirely in line with the charter she's supposed to uphold.

> I imagine you're referring to the "hg book"[1] ?

No, I mean when you go to the site and click the second item in the menu, Guide[1].

[1]: https://mercurial-scm.org/guide

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial

This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely.

About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already using git branches a lot, so this was definitely not a good first impression.

I might be missing something here, but this doesn't seem compatible with the bazaar model at all. You say

> It also enables contributions by the community for the latest version and not old source code.

But you will not be able to accept such contributions without an additional license, because you yourself would be unable to use them for a Competing Use (running your service). This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation". Sure, your work will be publicly visible, but that's it.

For a paid font $75 for an unlimited lifetime license is not at all expensive. I suspect the difficulty isn't so much getting people to pay $75 for a font, but getting people to pay for a font in the first place. The font market is essentially split between free fonts and expensive fonts. The people willing to pay for fonts are not particularly price sensitive, because if they were they would just be using a free font.

package-list-packages does not do network operations in the foreground unless package-menu-async is nil. It's t by default. package-refresh-contents does, but I've always been able to C-g to abort at any time.

I hate to have to bring this up, but please don't advertise source available software as being open source. You have a cool product and making the source available is a good thing, you don't need to lie about the extent to which you're opening it up.

That's a good thing, because that final edit is a discrete event. At some point this ongoing process will end and the edits will stop. The people engaged in the process will likely forget or not be available to add a final timestamp, but an aging edit timestamp will automatically indicate this moment in time.

I agree with this. There are cases where it produces good results, but there are also cases where it produces bs, and it's not always obvious. I find it to work fine for cases where I know what I want but could use a starting point, but it often invents or misunderstands all kinds of things.

The most frustrating situations are those where it invents a function that would miraculously do what's necessary, I tell it that function does not exist, it apologizes, shuffles the code around a bit and invents a different function, etc. It's the most annoying kind of debugging there is.

We need IPv6 because we're out of IPv4 addresses. When you launch a new ISP and knock on the door of a RIR like RIPE, they don't have any IPv4 addresses left to allocate and so you're put on a waiting list. The solution is IPv6. Even without allocating an address per device, without IPv6 just the status quo of every customer having an IP address is no longer possible.

The predecessor of my ISP introduced full IPv6 support for all customers 15 years ago. The only argument against at this point is inertia.

> How do you deal with the fact that there are people willing to work for less?

The answer in the Netherlands is that for most industries that have one the collective agreement has been declared universally binding. It applies to everyone in that industry, whether they're a member of one of the bargaining organizations or not, and if a company ignores it they're breaking the law.

> Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.

It won't ever be perfect, but that doesn't mean we shouldn't strive to get as close as possible.

> Source control is the wrong tool for this job, that's what comments and tickets are for.

I agree that code comments play an important part in explaining why something is the way it is. Code comments and commit messages play a different role there, but they overlap and it can be tough to balance. Roughly: commits explain changes and the decisions made to arrive at that set of changes. Comments explain the end result and the decisions relevant to explain that end result.

I disagree that tickets are a better way to convey this information. Embedding references to tickets is not necessarily a bad thing, but the lifetimes of issue trackers and source code history tends to be different, so all relevant information from such references should be in the comments or commit messages.

I find this take interesting, and I agree with a lot of it. There are also a few things I don't agree with.

Points 1 to 4 argue against the idea of rebasing as an alternative to merging. I agree with this to some extent, but in practice I notice that the exact point at which a branch began is rarely important. A very rough heuristic for this is "can it be rebased non-interactively?". This effectively means I like "cherry-pick merges", and it would be cool if Git remembered more about the origins of them. Rebases that do require manual adjustment are far more error-prone than merges, and I try to avoid those.

Point 5 and 6.0 are the primary reason I edit history. I want my history to tell a coherent story, not just in commit messages but also in the changes themselves, and that story often doesn't perfectly match the actual road traveled to get to the end. I don't much value mistakes where I forgot to implement half a change while tired at the end of a long workday, or an ill-considered false start. Where such information is valuable I'll write it down in the commit messages of changes that implement what did end up happening.

That brings me to the other points. I very much agree with 6.1 and beyond. Squashing branches removes a lot of valuable information, and it removes the ability to tell that coherent story. In particular:

- There are often small changes or bug fixes that aren't really part of the set of changes, but that just happen to become most relevant while developing this feature. Depending on the specifics these could be merged separately, and I keep them separate.

- Nuances discovered later in the development of a set of changes tend to offer valuable insight, so I want to keep them separate from the rest.

It would be cool if Git remembered more of the specifics of how the end result was reached, but I'm not sure if I would use it much in practice.

I completely agree, which is why I'm not a fan of squash merges that remove such nuance. In practice a feature branch often ends up with roughly three sets of changes:

1. Some small commits in preparation for the bigger change, that are also desirable should the rest never end up being merged

2. The big set of changes, either in one big commit or in a handful of smaller, independent commits

3. Some (usually smaller) commits that reflect nuances thought of or discovered after the biggest batch of changes was made

Most of my history cleanup serves to separate part 1 and 2 and to turn part 2 into a set of coherent steps.

Depending on how things go each of these might be merged independently or all at once.

> I've never understood this impulse to do "branch cleanup". Why are you adding unnecessary work? Is the source repository for tracking a history of changes or is it an art exhibition?

The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps. Often my first attempt at a change does something in an illogical order, or I make related changes that later end up in a separate merge. In the short term that change in thinking is somewhat interesting. In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

The stronger version of this completely discards any history when merging a feature, but I often find that to get rid of useful information.

The combination of "newer products" and then having "our Stream service" as the only named service in the post-mortem is very odd, since Stream is hardly a "newer product". It was launched in 2017 and went GA in 2018[2]. If after 5 years it still didn't have a disaster recovery procedure I find it hard to believe they even considered it.

[1]: https://blog.cloudflare.com/introducing-cloudflare-stream/ [2]: https://www.cloudflare.com/press-releases/2018/cloudflare-st...

> Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record.

In my experience this is not at all common. I think I know of 3 that do, and I've used many more that don't.

> No, it isn't, and I've already outlined the reasons why.

The only argument in favor of imperial measurements you've given is that humans have two feet, which isn't much of an argument given the variation in sizes of those physical feet.

From what I understand ImageMagick's vulnerability management involves updating to newer versions, so this is specifically about distributions that don't. Ubuntu chooses to distribute older versions with their own patches, but require Pro for you to get them.

With that said, the mentioned vulnerability is an odd one. A CVE published in 2023 with a CVE number for 2022 for a bug that was found and fixed in 2020. The bug in question is a memory leak when passing -help.[1]

[1]: https://github.com/ImageMagick/ImageMagick/issues/2889

What you describe is the explicit grant flow and the exchange of the code for an access token automatically protects against this vulnerability. The bugs here are in the implicit grant flow where the redirect doesn't include an opaque code but an actual access token. There the application is responsible for validating that the token is for that application, but there's nothing that requires it to do that.

> But then I eventually understood that you're talking about latency between viewers

The latency between streamer and viewer on Twitch (in low-latency mode, which is the default) is normally less than 5 seconds and often between 1 and 2 seconds. The player actually slightly speeds up the video if it exceeds 5 seconds.

This is essential for interactivity, because the streamer can ask a question and get a response without constant awkward pauses.

> I think the large streamers are a loss leader for Twitch. Delivering thousands of extremely high resolution, high frame rate, high bit rate streams costs a fortune. Plus those big streamers love to monetize their users through other means: Patreon, Onlyfans, sponsorships, merchandise sales, and even direct PayPal donations. They tend to try to steer their users away from large donations of Twitch subscriptions due to the large cut that goes to Twitch.

I don't think they are. Given the same size total audience it's much cheaper for Twitch to distribute one stream around the world a million times than it is to distribute thousands of streams around the world a few times each. Transcoding only has to happen once, each segment only has to be distributed to each area of the world once, etc. This gets more nuanced when you include things like chat, which gets harder as you scale up, but I highly doubt that cost is significant compared to the video feed.

Those large streamers may be monetizing their viewers through other means, but as long as they're not actively pulling them away from Twitch those viewers are still either watching ads or subscribing. And based on anecdotes shared by some of those big streamers Twitch ads have gotten more and more profitable.

One of the things they do is have the number of trackers on a website affect its ranking (negatively). I imagine that is an effective signal in cases like this.

FUTO is funded by billionaire Eron Wolf. There's an interview[1] with him on their YouTube.

[1]: https://www.youtube.com/watch?v=5UHF84gyVWg

Oof, that's frustrating and a recent change. There used to be a quality selection at the top and a "Download all" button that would download an archive of the entire purchase.

Fastmail is very good and has been running for 24 years, with good deliverability. Migadu I hear is good. There's quite a few email providers that aren't Microsoft or Google that have their shit together.

For an online music store with DRM free downloads I like Qobuz. Available quality depends on the album/song, but if something is not on Bandcamp it's a good, no-nonsense alternative.

> such Nutritional Facts labelling didn't start being required on packaging in Europe until the late 90's

Do you or someone else happen to know which directive made it mandatory? I found Council Directive 90/496/EEC of 24 September 1990[1] which harmonised labeling, but only made it mandatory when there's a nutrition claim on the label/advertised. Otherwise it was still optional.

[1]: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:31...

The link to Quora is not a problem, it's the faulty interpretation of the content of the page. In fact, Kagi's Quick Answer says this:

> You cannot melt whole eggs like you would melt ice or cheese. However, you can soften the proteins in eggs through heating.[1][2]

Reference 1 is to the Quora page, reference 2 is another Quora page.

It should work without JS. It even works in eww (in Emacs). Looking at the source of the page, there's a redirect (meta http-equiv="refresh") wrapped in a <noscript>-tag to the same URL but with "/html" before the path.[1]. It seems the browser you tried doesn't handle that.

[1]: https://kagi.com/html/search?q=what+is+%25&r=no_region&sh=Qd...