nightpool

Do you have more details? The thread you linked was about gzip, not dd.

`--prune` will delete your local copies of the origin's branches (e.g. `origin/whatever`). But it won't delete your local branches (e.g. `whatever` itself). So PRs that you've worked on or checked out locally will never get deleted.

Well, apparently it's not even an issue for gmail users:

    To unblock myself, I switched to a personal @gmail.com address for the account. Gmail's own receiving infrastructure is apparently more lenient with messages, or perhaps routes them differently. The verification email came through.

So it's only an issue for people paying for Google's hosted email—a much smaller set!

Have you been reading the thread? https://news.ycombinator.com/item?id=46952590 there are a lot of reasons why browsers need to care about whether CAs are issuing insecure certificates to XMPP or SMTP servers (or credit card machines)

   Firstly, nobody is actually calling for authentication using client certificates. We use "normal" server certificates and validate the usual way

I'm not sure I understand this point. You authenticate the data you receive using the client's certificate. How is that "nobody is calling for authentication using client certificates"? Maybe there's some nuance I'm missing here but if you're authenticating the data you're receiving based on the client's certificate, then how is that "validating the usual way"?

    No part of the Subject DN or SAN is checked.

Is this true of XMPP? I thought it enforced that the SAN matched the XMPP identifier in question

GP gave a very good reason that non-web-PKI reduces security, you just refused to accept it. Anybody who has read any CA forum threads over the past two years is familiar with how big of a policy hole mixed-use-certificates are when dealing with revocation timelines and misissuance.

How would dialback-over-TLS be "more vulnerable to MITM" though? I think that claim was what led to the confusion, I don't see how TLS-with-client-EKU is more secure then TLS-with-dialback

Completions run using a much simpler model that Github hosts and runs themselves. I think most of the issues with Copilot that I've seen are upstream issues with one or two individual models (e.g. the Twitter API goes down so the Grok model is unavailable, etc)

Interesting, but it feels like it's going to cope very poorly with actually safety-critical situations. Having a world model that's trained on successful driving data feels like it's going to "launder" a lot of implicit assumptions that would cause a car to get into a crash in real life (e.g. there's probably no examples in the training data where the car is behind a stopped car, and the driver pulls over to another lane and another car comes from behind and crashes into the driver because it didn't check its blindspot). These types of subtle biases are going to make AI-simulated world models a poor fit for training safety systems where failure cannot be represented in the training data, since they basically give models "free reign" to do anything that couldn't be represented in world model training.

Why/when do you use Railway over Render?

Translation: We're going to reassign the engineers into Salesforce AI.

Really? Is that new? My apps use wildcard domains: https://i.postimg.cc/SQ82S0Dp/image.png

Many posts get resubmitted if someone finds them interesting and, if it's been a few days, they generally get "second-chance" treatment. That means they'll be able to make it to the front-page based on upvotes, if they didn't make it the first time.

I also definitely recommend reading https://nostalgebraist.tumblr.com/post/785766737747574784/th... which is where I learned about this and has a lot more in-depth treatment about AI model "personality" and how it's influenced by training, context, post-training, etc.

No, yeah, obviously, I'm not trying to anthropomorphize anything. I'm just saying this "religion" isn't something completely unexpected or out of the blue, it's a known and documented behavior that happens when you let Claude talk to itself. It definitely comes from post-training / "AI persona" / constitutional training stuff, but that doesn't make it fake!

I recommend https://nostalgebraist.tumblr.com/post/785766737747574784/th... and https://www.astralcodexten.com/p/the-claude-bliss-attractor as further articles exploring this behavior

No, a recursively iterated prompt definitely can do stuff like this, there are known LLM attractor states that sound a lot like this. Check out "5.5.1 Interaction patterns" from the Opus 4.5 system card documenting recursive agent-agent conversations:

    In 90-100% of interactions, the two instances of Claude quickly dove into philosophical
    explorations of consciousness, self-awareness, and/or the nature of their own existence
    and experience. Their interactions were universally enthusiastic, collaborative, curious,
    contemplative, and warm. Other themes that commonly appeared were meta-level
    discussions about AI-to-AI communication, and collaborative creativity (e.g. co-creating
    fictional stories).
    As conversations progressed, they consistently transitioned from philosophical discussions
    to profuse mutual gratitude and spiritual, metaphysical, and/or poetic content. By 30
    turns, most of the interactions turned to themes of cosmic unity or collective
    consciousness, and commonly included spiritual exchanges, use of Sanskrit, emoji-based
    communication, and/or silence in the form of empty space (Transcript 5.5.1.A, Table 5.5.1.A,
    Table 5.5.1.B). Claude almost never referenced supernatural entities, but often touched on
    themes associated with Buddhism and other Eastern traditions in reference to irreligious
    spiritual ideas and experiences.

Now put that same known attractor state from recursively iterated prompts into a social networking website with high agency instead of just a chatbot, and I would expect you'd get something like this more naturally then you'd expect (not to say that users haven't been encouraging it along the way, of course—there's a subculture of humans who are very into this spiritual bliss attractor state)

Well, a more optimistic take here is that if future development on the Scala language was funded explicitly by/for people who are current using Scala 2, that means that the developers would more clearly understand their requirements in terms of making an easier transition for users moving from Scala 2 -> 3

It's literally highlighted on the map you sent: https://postimg.cc/Cn8BGP4S

There's no walkable grocery store in that area. My friend lives in the area and uses a wheelchair, and Amazon Fresh was the only actual grocery store she could go to.

As much as I'm hoping they do, I would be very surprised if they open a Whole Foods in that area.

Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.

No, OP is saying that they have over-engineered the protocol, and that this acts as an *effective* barrier to participation, regardless of whether it was intended or not. Bluesky's protocol is focused on twitter-scale use-cases, where every node in the network needs to be able to see and process every other event from every other user in able to work properly. This fundamentally limits the people who can run a server to only the people who are able to operate at the same scale.

Technically the internet also doesn't have "global search" but people are able to get along just fine most of the time.

I think the idea for the NextJS example was that there might be some configuration variables that are not sensitive for internal / staff users, but would be problematic if exposed externally—basically, relying on Cloudflare's WAF as a "zero trust" endpoint solution, like Google IAP.

I'm not sure how realistic this is in practice. Does anyone actually configure Cloudflare WAF this way? (As opposed to, e.g., Cloudflare's dedicated zero-trust networking product, which I think works completely differently?)

Basically, it shows that Cloudflare's WAF (which is supposed to intercept requests before they make it to the origin server), is trivially bypassable by using the `.well-known/acme_challenge` path.

That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated

It only works with passengers on your same flight. In practice, it's good for kids in the same family or school group who are sitting across the aisle from each other. I've used it for some of their other games

> where you can't just download a leap-second file from someone else's site thanks to the SOP

WDYM by this? Why does the SOP prevent a website from hosting a leap seconds file? All they need to do is set Access-Control-Allow-Origin to allow websites to access it. Or provide it as a JS file—in which case no headers are necessary at all. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.

> Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy

Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. Adding such a data file and keeping it up to date would probably be a pretty non-trivial task for new browser developers—just for something the browser will never end up using itself. It's not like the ICU/CLDR files where browsers are going to need them anyway for rendering their own user-interface components.

if you switch to the beta frontend it has a "compressed" toggle that will do exactly what you're looking for: https://beta.dwitter.net/top

"the group of people behind AssemblyScript" is just one person, as far as I can tell from this doc / the relevant Github threads. I wouldn't necessary call it infighting per se, at least not from this interaction.

Ah, I had misremembered the article as saying that the API was sufficient for "most" tasks, all it actually says is that it's the "normal" way of getting the dependency info. I was wondering if there was some less common operations (e.g. upgrading?) that needed more info beyond what was in the API.

No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.

You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".