cap10morgan

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.

Humbug: https://humbughq.com/signup/

Still pretty new, and in closed beta. But it adds an interesting threading/topic model onto the typically chaotic stream of most group chat apps.

There's a common fallacious argument in here:

A. The corporations that have the most power in this industry have lobbied for and gotten a consumer-hostile regulatory regime. B. It's the government's fault that the regulations are less than ideal. Therefore the consumer would be best served by getting the government out of it.

This is like saying, "The problem with being stranded in the desert is the lack of water. Therefore water is the problem. Therefore we should remove all the water from the desert."

Yeah, it changes the game when you need to fill out a pre-existing PDF form with user-supplied data (as opposed to free form PDF generation). In my experience, you pretty much have to use a Java library (such as iText) for this. So for a Rails app, that means JRuby, queue to a Java daemon processor, or something along those lines.

Though I see they're using the prawn gem to do it here: https://github.com/democrats/voter-registration/blob/master/...

Last time I checked, prawn wasn't quite powerful enough for this use case. I'll have to revisit that approach.

I worked as a Rails dev at the DNC in 2010-2011. I pushed for open-sourcing our fully-featured voter reg. Rails app back then, but didn't find much support for the idea. The political world is pretty wary of "giving code away" because the opposition will use it, etc. So, progress?

We were allowed to open-source some infrastructure code back then: https://github.com/dnclabs

Hopefully they'll continue working on this tool and make it something worth using and contributing to. I've tried to convince several political orgs. I worked for in the past to do this, but so far none have bitten.

I'm not claiming it did. I'm saying that a very different PC desktop / laptop OS and software ecosystem back in the mid-nineties would have ripple effects on PCs, phones, and tablets today.

This article misses the forest for the trees. During the height of Microsoft's monopoly, consumers were very much limited in their choices. MS did everything they could to keep the likes of OS/2 and BeOS off of new PCs, and that means no one ran other OS's, so no one wrote apps for them. Had that not been the case, the PCs, phones, and tablets we use today would be very different. I daresay they'd be better, for having arrived at many current innovations sooner due to the more robust level of competition and potentially having more viable options in the market today.

Just because MS lost its monopoly on its own does not mean that we, as consumers, would not have benefitted--and would still be benefitting--from breaking up that monopoly when it was more dominant.

Instead of doing the "guy*" thing where you point out that you're just as excited to work with women as men, I would remove the gender-specific language altogether. Then it's a non-issue. If you don't exclude female co-founders right off the bat, they will most likely assume you're just as excited to work with them.

The difference between MongoDB and many of the other popular persistent data stores (relational or not) is one of degree, not of kind.

MongoDB isn't a fundamentally flawed system. It's just that the distance between what 10gen (and many of its defenders) claim and what it delivers is much greater than most other data storage systems. This is a subtle thing.

Many people have attempted to use MongoDB for serious, production applications. The first few times they encounter problems, they assume it's their fault and go RTFM, ask for help, and exercise their support contract if they're lucky enough to have one. Eventually it dawns on them that they shouldn't have to be jumping through these hoops, and that somewhere along the way they have been misled.

So it's not like anyone is misinterpreting the purpose and/or problem domain of MongoDB. It's more that they are exploring the available options, reading what's out there about MongoDB, and thinking, "Gosh, that sounds awfully cool. It fits what I'm trying to build, and it doesn't seem to have many obvious drawbacks. I think I'll give that a try." And then they get burned miles further down the road.

If MongoDB were presented as more of an experimental direction in rearranging the priorities for a persistent data store, then that would be fine. That's what it is, and that's great! We should have more of those. But when it's marketed by 10gen (and others) as a one-size-fits-all, this-should-be-the-new-default-for-everything drop-in replacement for relational databases, then it's going to fall short. Far short.

That's a lot of hand-wavy claims. Care to back some of it up with data? Especially the part about China's economic growth being slower if they'd had stricter building codes. Absent any real data, it's equally intuitive to say that it wouldn't have been slower because [insert natural disaster here] would have been a big setback as often as [same natural disaster] occurs on average.

Plus, you know, lots of people would have died who could have been saved by stricter building codes. I'd rather be alive than have a couple more percentage points of economic growth every year.

No. That's all it ever was. You get a "basic critical thinking" merit badge for realizing it.