As an outsider looking in, it looks like it's a bit of a wipe the slate clean governance and moderation wise as voted on by the community.

So, now over the coming days the community will in essence vote on whether they will allow sponsorships from the military industrial complex.

Luckily for you, there's not a vaccine for stupidity.

There's a reason Teams is/was shit.

The first teams was written in AngularJS (which is a slow to run resource hog, but fast to develop) wrapped in Electron. It was kind of a minimum viable product, just to build something quickly to get some feedback and stats on what people needed.

The plan was to build a new native version of teams and build it into the next windows while having an web fallback (built on react) for everyone else.

They stopped working on the original teams and started working on the new versions.

They got half-way through working on the native and react versions when suddenly, covid happened.

They couldn't keep working on the new versions because they wouldn't be ready for a while, so they had to go back and resume development on the old one, introducing patch after patch to quickly get more features in there (like more than 2 webcam streams per call).

Eventually covid subsided and they were able to resume development on the new teams versions.

Windows 11 launched with a native teams version (which has less features but runs super quick), and the new react based teams (which can now be downloaded in a webview2 wrapper) has been in open beta since late last year (if you've seen the "Try the new Teams" toggle, then you've seen this). The React+Webview2 teams will replace the AngularJS+Electron version as the default on July 7th.

The solution is simple: Remove the dagger mid-combat.

You could make the dagger too hot to hold and it falls out of reach (off a mountain, into rushing water, etc...)

You could make the dagger dissolve away (through lava, acid, being eaten, etc...)

You could make something take the dagger (disarming, stealing, etc...)

A hag/genie/etc could place a curse on the PC (holding anything makes them experience immense pain and drop what they're holding, anything dagger they hold is turned into a spoon, etc...)

That's not pro, that's just reckless gambling.

"the means" in this case would be authoritarian repression.

"The means" always has to be something bad for the "ends" to try and justify reaching for "the means".

It depends what you need your configuration file to be:

Need a well defined easy to understand concrete configuration file?

• Use .toml. It was made to be both human and computer friendly while taking special attention to avoid the pitfalls commonly found in other configuration files by explicitly stating expected types around commonly confused areas.

Need a simple to implement configuration file?

• Use .json. It's famous for being so simple it's ~~creator~~ "discoverer" could define it on a business card.

Need an abstract configuration file for more complicated setups?

• Use .ncl. Nickle allows you to define functions so that you can generate/compute the correct configuration by changing a few variables/flags.

Github has always had being a job site be it's secondary feature.

Except that it has a slightly higher bar of entry to recruiters and recruitment bots spreading toxic positivity, and anyone asking for a job is able to prove (at least some of) their value by showing off their code and how they participate publically in other repos (if at all).

And yet people will blindly trust AI ~~hallucinated~~ generated results...

It's not rebase vs merge, it's rebase AND merge.

Commit your changes into logical commits as you go.

Then just before submitting a pull request, review your own code. That includes reviewing your own commits too, not just the code diff.

Use rebase to:

• Swap commits so that related changes are together
• Edit your commit messages if you find a mistake or now have a better idea of what to put in your messages
• Drop any useless commits that you just end up reverting later
• Squash any two commits together where the first was the meat of desired change and the second was the one thing that you forgot to add to that commit so you immediately followed it up with another commit for that one missing thing.

Then, and only then, after you have reviewed your own code and used rebase to make the git history easier to read (and thus make it easier to review), then you can submit a pull request.

The CommunityFactory is coming next week, and the CommunityFactoryFactory the following week :p

cURL was one of these for a while (according to my limited understanding)

It was made in the 90s and it didn't get commercial support until a few years ago.