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.
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:
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.
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.
> 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.”
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. :)
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.
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?"