cap10morgan's comments

I am already using Claude in Xcode 26.2. What did they change / add specifically in 26.3? It's not super clear behind the marketing haze.

This highlights a common pitfall: If you “solve” a problem with a “temporary” solution, you lower the priority of the better solution below every unsolved problem. And there are always enough of those to ensure no one ever revisits the temporary solutions.

Important caveat with Firefox: You can run your own Firefox Account server (see https://mozilla-services.readthedocs.io/en/latest/howtos/run...) and then e.g. connect to it over a VPN to mitigate a lot of this.

I would encourage folks to listen to this podcast episode from April 2020 for some background on how the virus itself can carry detectable earmarks of being natural or lab-grown and what we see in SARS-CoV-2 based on that:

https://gimletmedia.com/shows/science-vs/dvheexn/coronavirus...

Gives you some good additional questions to ask when reports like this come out.

They think they aren’t, but it’s yet another thing they’re confused about.

Peter Thiel almost certainly didn’t invent this. The idea that our decisions are heavily influenced by those around us is one of those things that’s been well-established in the relevant scientific communities for some time but has a hard time breaking into the popular consciousness because we don’t want it to be true.

In my experience "Does your company measure the long term benefit of X?" is 99.99999% "no" for any X.

I'm hoping this leads to an announcement of some kind of hypervisor support in iPadOS 15. I would imagine that would come at WWDC if it's coming. Seems like it would allow software development on the iPad while retaining app sandboxing.

That's a fair question and something I should have clarified in my comment (though I have a feeling it is likely addressed in the blog post I linked to).

It gets into the deeper motivation behind not breaking backwards compatibility within the same-named module. There are two bad extremes here:

1. Never update dependency versions for fear of breakage. This leaves you open to security vulnerabilities (that are easy to exploit because they are often thoroughly documented in the fixed version's changelog / code). And/or you're stuck with other bugs / missing features the upstream maintainer has already addressed.

2. Always just updating all deps to latest and hoping things don't break, maybe running the test suite and doing a "smoke test" build and run if you're lucky. Often a user becomes the first to find a broken corner case that you didn't think to check but they rely on.

The approach outlined by Rich Hickey in that Spec-ulation talk I linked to allows you to be (relatively) confident that a package with the same name will always be backwards-compatible and you can track the latest release and find a happy middle ground between those two extremes.

Go's approach is one of the few (only?) first-class implementations of this idea in a language's package system (in Clojure, perhaps ironically, this is merely a suggested convention). The Go modules system has its fair share of confusing idiosyncrasies, but this is one of my favorite features of it and I hope they stick to their guns.

I see a lot of comments in here about the v2+ rule’s reason for existing being to allow importing multiple major versions of a module. That’s not it at all. As the blog post (which was easily Googled by me and explains things quite well IMO) states: “If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.”

They’re trying not to break compatibility until a downstream developer explicitly opts in to that breakage. The simplest way to do that is to give the module a new name. And the simplest way to do that is append the major version to the name.

Here is the post: https://blog.golang.org/v2-go-modules

For more background on this principle, I recommend Rich Hickey’s Clojure/conj keynote “Spec-ulation” from 2016: http://blog.ezyang.com/2016/12/thoughts-about-spec-ulation-r...

> During a brownout, password authentication will temporarily fail to alert users who haven't migrated their authentication calls.

This took me a second to correctly parse. Would have been better written as: “During a brownout, password authentication will temporarily fail. This is to alert users who haven't migrated their authentication calls.”

It is free for the time being. But you point out a good reason why we built dgit to support other storage backends.

Totally fair. We definitely want to make that install process very simple and fast for as many people as we can. And it only needs to be done once per machine. :)

Cool! We'll look into that.

Our setup process is a much lighter lift than standing up a server and installing gitolite on it.

But yes, if GitHub is down, then your workflow is going to change. We're hoping to close that gap down the road, but having a way to continue pushing and pulling with collaborators with a very quick setup seemed compelling to us. Not to mention the benefits that decentralization itself brings.

The vast majority of git users tend to agree on one "origin" remote and 99-100% of their pushes and pulls are to/from that remote. So git, in practice, tends to be centralized when it comes time to collaborate with others. We're trying to re-decentralize that aspect while accommodating the convenient workflows we're all used to.

Absolutely. Our strategy is to give you a decentralized on-ramp by starting with GitHub's central value proposition of the "one true git remote" that everyone can share. We made a GitHub action (https://github.com/quorumcontrol/dgit-github-action) to automatically mirror GitHub pushes on dgit so you can continue using GitHub's other tools (like issues and wikis) until dgit offers a compelling alternative for those.

dgit dev here. Good question. For starters, dgit is not 100% tied to Sia, it's just a great decentralized file hosting service so we started with it as the first default.

But to answer your question, anyone can host Sia nodes. Here are their docs on that: https://support.sia.tech/category/0OpBuOHIVD-hosting

Straw man alert. I've never heard a YIMBY argue for "build anything, anywhere." I've only ever heard them argue for exactly what the article proposes, i.e. smart, context-aware density.

So all of the corporate breaches show that the entire private sector is irresponsible with data too? Maybe the problem is a little deeper than "government is irresponsible?"

Does anyone know if there is an implementation of the key-press-light-flash-delay temporal illusion anywhere online? I'd love to try that out and experience the light flash "before" the key press after conditioning my brain to integrate the 200ms delay.

If there isn't one, I may have to write it. It sounds really trippy.